From mailman-bounces@ietf.org Tue Jun 1 08:04:56 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21613 for ; Tue, 1 Jun 2004 08:04:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BV5ei-0000n5-HD for megaco-archive@lists.ietf.org; Tue, 01 Jun 2004 05:34:00 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: megaco-archive@ietf.org X-No-Archive: yes Message-ID: Date: Tue, 01 Jun 2004 05:06:10 -0400 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org Content-Transfer-Encoding: 7bit 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, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@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 mailman-admin@ietf.org Tue Jun 1 12:26:01 2004 Received: from optimus.ietf.org ([132.151.1.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21252 for ; Tue, 1 Jun 2004 12:26: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 1BV98K-0001hH-SQ for megaco-archive@lists.ietf.org; Tue, 01 Jun 2004 09:16:48 -0400 Date: Tue, 01 Jun 2004 09:16:48 -0400 Message-ID: <20040601131648.26555.1438.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-bounces@ietf.org Tue Jun 1 17:48:55 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27382 for ; Tue, 1 Jun 2004 17:48:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVGtb-0006Fe-0b; Tue, 01 Jun 2004 17:34:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BTiCH-0004zV-6c for megaco@megatron.ietf.org; Fri, 28 May 2004 10:18: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 KAA04056 for ; Fri, 28 May 2004 10:18:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BTiCG-0005Wr-3s for megaco@ietf.org; Fri, 28 May 2004 10:18:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BTiBS-00058m-00 for megaco@ietf.org; Fri, 28 May 2004 10:18:06 -0400 Received: from togw.navtelcom.com ([199.166.16.39]) by ietf-mx with smtp (Exim 4.12) id 1BTiAm-0004kZ-00 for megaco@ietf.org; Fri, 28 May 2004 10:17:24 -0400 Received: from no.name.available by [199.166.16.39] via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; Fri, 28 May 2004 10:19:27 -0400 content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Fri, 28 May 2004 10:18:28 -0400 Message-ID: <643EEBE928088B40B806F4FE42DA2BBC035283@toexh1w2.navtelcom.com> Thread-Topic: Megaco TCP Support - Doubts Thread-Index: AcREvqVylKgYQ5NhTLeo4W/KvZeR+Q== From: "Shenbaga Nathan" To: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=HTML_50_60,HTML_MESSAGE autolearn=no version=2.60 X-Mailman-Approved-At: Tue, 01 Jun 2004 14:44:34 -0400 Subject: [Megaco] Megaco TCP Support - Doubts X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1325166267==" Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org This is a multi-part message in MIME format. --===============1325166267== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C444BE.A573A5CD" This is a multi-part message in MIME format. ------_=_NextPart_001_01C444BE.A573A5CD Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 I am working on providing TCP transport support for MEGACO implementation (both MG and MGC). I have some doubts. =20 1. Should we have ONE TCP connection per gateway? =20 =20 For example, if the MG (Media Gateway) sends a Service Change to the MGC (gateway Controller) it initiates a TCP connection from that gateway. The MGC replies to the Service Change using the same connection. However, if the MGC wants to send a command (say Modify) should it use the same connection or should it try to initiate a new TCP connection to the MG's default port 2944. =20 2. Once a TCP connection is established between MG and MGC, how long does this connection hold good?. In other words, under what circumstances the MG or MGC closes an existing TCP connection and tries to initiate a new connection. =20 It would be of great help, if some one could clarify these issues. =20 Thanks. =20 Regards, Nathan =20 =20 ------_=_NextPart_001_01C444BE.A573A5CD Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I am working on providing TCP transport support for = MEGACO implementation (both MG and MGC). I have some doubts.

 

1. Should we have ONE TCP connection per gateway? =  

 

For example, if the MG = (Media Gateway) sends a Service Change to the MGC (gateway Controller) it = initiates a TCP connection from that gateway. The MGC replies to the Service Change = using the same connection. However, if the MGC wants to send a command (say = Modify) should it use the same connection or should it try to initiate a new TCP connection to the MG’s default port 2944.

 

2.  Once a TCP connection is established between = MG and MGC, how long does this connection hold good?. In other =     words, under what circumstances the MG or MGC closes an existing TCP connection = and tries to initiate a new connection.

 

It would be of great help, if some one could clarify = these issues.

 

Thanks.

 

Regards,

Nathan

 

    

=00 ------_=_NextPart_001_01C444BE.A573A5CD-- --===============1325166267== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============1325166267==-- From megaco-bounces@ietf.org Tue Jun 1 17:49:13 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27409 for ; Tue, 1 Jun 2004 17:49:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVGtb-0006Fk-Ga; Tue, 01 Jun 2004 17:34:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BV5AS-0000RV-Kb for megaco@megatron.ietf.org; Tue, 01 Jun 2004 05:02: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 FAA07257 for ; Tue, 1 Jun 2004 05:02:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BV5AQ-00001r-As for megaco@ietf.org; Tue, 01 Jun 2004 05:02:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BV59S-0007P8-00 for megaco@ietf.org; Tue, 01 Jun 2004 05:01:43 -0400 Received: from mta2.huawei.com ([61.144.161.24] helo=huawei.com) by ietf-mx with esmtp (Exim 4.12) id 1BV58T-0005iw-00 for megaco@ietf.org; Tue, 01 Jun 2004 05:00:42 -0400 Received: from huawei.com (huawei.com [172.17.1.61]) by mta2.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.7 (built Jun 26 2002)) with ESMTP id <0HYM00LFQGXXEF@mta2.huawei.com> for megaco@ietf.org; Tue, 01 Jun 2004 16:58:46 +0800 (CST) Received: from huawei.com ([172.17.1.58]) by mta2.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.7 (built Jun 26 2002)) with ESMTP id <0HYM00LZ6GXXFE@mta2.huawei.com> for megaco@ietf.org; Tue, 01 Jun 2004 16:58:45 +0800 (CST) Received: from [10.70.0.82] by maila.huawei.com (mshttpd); Tue, 01 Jun 2004 16:52:00 +0800 Date: Tue, 01 Jun 2004 16:52:00 +0800 From: zhuning 17035 To: megaco@ietf.org Message-id: <5ed6c62305.623055ed6c@huawei.com> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 0.7 (built Jun 26 2002) Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: zh-CN Priority: normal X-imss-version: 2.5 X-imss-result: Passed X-imss-scores: Clean:22.11317 C:21 M:2 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:3 R:3 (0.0000 0.0000) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=UPPERCASE_25_50 autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT X-Mailman-Approved-At: Tue, 01 Jun 2004 14:44:34 -0400 Subject: [Megaco] a doubt about sdp in h248 message X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org Content-Transfer-Encoding: 7BIT Hi, after a rtp termination is added to a context and ip ,port and codec is reported to mgc ,if mgc wants to just change the codec but the ip and port will not be change .can mgc use '-' as ip and port in sdp of local? 1. MGC->MGW MEGACO/1 [182.20.20.1]:2944 T=369361149{C=${A=A1{M{O{MO=SR,RV=OFF,RG=OFF}},E=369100037{al/*},SG{}},A=${M{O{MO=IN,RV=OFF,RG=OFF,nt/jit=40},L{v=0c=IN IP4 $m=audio $ RTP/AVP 8}}}}} 2.MGW->MGC MEGACO/1 [182.020.020.050]:2944 P=369361149{C=116{A=A1,A=A100000039{M{O{MO=IN,RV=OFF,RG=OFF,nt/jit=40},L{v=0c=IN IP4 182.20.20.50m=audio 16856 RTP/AVP 8}}}}} . . . . . . if mgc wants to change the codec of A100000039 to 18 ,can mgc use MEGACO/1 [182.20.20.1]:2944 T=370278656{C=116{MF=A1{M{O{RV=OFF,RG=OFF,tdmc/ec=ON}},E=369100040{al/*},SG{}},MF=A100000039{M{O{MO=SR,RV=OFF,RG=OFF,tdmc/ec=ON},L{v=0c=IN IP4 -m=audio - RTP/AVP 18},R{v=0c=IN IP4 182.20.20.50m=audio 16860 RTP/AVP 18}}}}} to change it ? (in the local sdp ,mgc use '-' ,the real ip and port is not sent ) Best Regards, Neal _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Wed Jun 2 02:23:56 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23180 for ; Wed, 2 Jun 2004 02:23:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVOjX-0007F9-L8; Wed, 02 Jun 2004 01:56:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVN9C-0006kB-Oo for megaco@megatron.ietf.org; Wed, 02 Jun 2004 00:14:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22490 for ; Wed, 2 Jun 2004 00:14:36 -0400 (EDT) From: sreeram.kanumuri@wipro.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BVN9A-0003EB-Nt for megaco@ietf.org; Wed, 02 Jun 2004 00:14:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BVN81-0002hW-00 for megaco@ietf.org; Wed, 02 Jun 2004 00:13:26 -0400 Received: from wiproecmx2.wipro.com ([164.164.31.6]) by ietf-mx with esmtp (Exim 4.12) id 1BVN6v-0001jC-00 for megaco@ietf.org; Wed, 02 Jun 2004 00:12:18 -0400 Received: from ec-vwall-wd (ec-vwall-wd.wipro.com [10.200.52.125]) by wiproecmx2.wipro.com (8.12.9-20031013/8.12.9) with SMTP id i524BRlG014690 for ; Wed, 2 Jun 2004 09:41:27 +0530 (IST) Received: from blr-ec-bh1.wipro.com ([10.200.50.91]) by ec-vwall-wd with InterScan Messaging Security Suite; Wed, 02 Jun 2004 09:41:26 +0530 Received: from blr-ec-msg04.wipro.com ([10.200.53.99]) by blr-ec-bh1.wipro.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 2 Jun 2004 09:41:26 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.0.6521.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Megaco] a doubt about sdp in h248 message Date: Wed, 2 Jun 2004 09:41:23 +0530 Message-ID: <72001BBBF6CB124BA1C40E415914E213447B98@blr-ec-msg04.wipro.com> Thread-Topic: [Megaco] a doubt about sdp in h248 message Thread-Index: AcRIIlO4v8RPublYTyKv67c5AYqYbQAMW9zQ To: , X-OriginalArrivalTime: 02 Jun 2004 04:11:26.0149 (UTC) FILETIME=[AC316750:01C44857] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL, NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org Content-Transfer-Encoding: quoted-printable MGC should not use "-" for only ip and port number in C field of SDP. "C" field is optional in SDP and when you do not want to change the connection parameters better not to use this variable again. -SReeram -----Original Message----- From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf Of zhuning 17035 Sent: Tuesday, June 01, 2004 2:22 PM To: megaco@ietf.org Subject: [Megaco] a doubt about sdp in h248 message Hi, after a rtp termination is added to a context and ip ,port and codec is reported to mgc ,if mgc wants to just change the codec but the ip and port will not be change .can mgc use '-' as ip and port in sdp of local? 1. MGC->MGW MEGACO/1 [182.20.20.1]:2944 T=3D369361149{C=3D${A=3DA1{M{O{MO=3DSR,RV=3DOFF,RG=3DOFF}},E=3D369100037{= al/*},SG{}},A =3D${M{O{MO=3DIN,RV=3DOFF,RG=3DOFF,nt/jit=3D40},L{v=3D0c=3DIN IP4 = $m=3Daudio $ RTP/AVP 8}}}}} 2.MGW->MGC MEGACO/1 [182.020.020.050]:2944 P=3D369361149{C=3D116{A=3DA1,A=3DA100000039{M{O{MO=3DIN,RV=3DOFF,RG=3DOFF= ,nt/jit=3D40},L {v=3D0c=3DIN IP4 182.20.20.50m=3Daudio 16856 RTP/AVP 8}}}}} . . . . . . if mgc wants to change the codec of A100000039 to 18 ,can mgc use=20 MEGACO/1 [182.20.20.1]:2944 T=3D370278656{C=3D116{MF=3DA1{M{O{RV=3DOFF,RG=3DOFF,tdmc/ec=3DON}},E=3D36= 9100040{al/*} ,SG{}},MF=3DA100000039{M{O{MO=3DSR,RV=3DOFF,RG=3DOFF,tdmc/ec=3DON},L{v=3D= 0c=3DIN IP4 -m=3Daudio - RTP/AVP 18},R{v=3D0c=3DIN IP4 182.20.20.50m=3Daudio 16860 = RTP/AVP 18}}}}} to change it ? (in the local sdp ,mgc use '-' ,the real ip and port is not sent ) Best Regards, Neal _______________________________________________ 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-bounces@ietf.org Wed Jun 2 03:22:57 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04518 for ; Wed, 2 Jun 2004 03:22:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVPpZ-00014p-Tx; Wed, 02 Jun 2004 03:06:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVPCC-00028i-1Y for megaco@megatron.ietf.org; Wed, 02 Jun 2004 02:25:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25159 for ; Wed, 2 Jun 2004 02:25:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BVPC9-00065T-GJ for megaco@ietf.org; Wed, 02 Jun 2004 02:25:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BVP9u-00051X-00 for megaco@ietf.org; Wed, 02 Jun 2004 02:23:31 -0400 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1BVP7U-0004H1-00 for megaco@ietf.org; Wed, 02 Jun 2004 02:21:00 -0400 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i526KvAh032518 for ; Wed, 2 Jun 2004 08:21:00 +0200 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 2 Jun 2004 08:20:57 +0200 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Wed, 2 Jun 2004 08:20:57 +0200 Message-ID: From: "Christer Holmberg (JO/LMF)" To: "'zhuning 17035'" , megaco@ietf.org Subject: RE: [Megaco] a doubt about sdp in h248 message Date: Wed, 2 Jun 2004 08:20:55 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 02 Jun 2004 06:20:57.0627 (UTC) FILETIME=[C45AD6B0:01C44869] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi, Why not use the previously assigned IP address and port in the modified = SDP, instead of "-"? Regards, Christer Holmberg Ericsson Finland > -----Original Message----- > From: megaco-bounces@ietf.org=20 > [mailto:megaco-bounces@ietf.org]On Behalf > Of zhuning 17035 > Sent: 1. kes=E4kuuta 2004 11:52 > To: megaco@ietf.org > Subject: [Megaco] a doubt about sdp in h248 message >=20 >=20 > Hi, > after a rtp termination is added to a context and ip=20 > ,port and codec is reported to mgc ,if mgc wants to just=20 > change the codec but the ip and port will not be change .can=20 > mgc use '-' as ip and port in sdp of local? >=20 > 1. MGC->MGW > MEGACO/1 [182.20.20.1]:2944=20 > = T=3D369361149{C=3D${A=3DA1{M{O{MO=3DSR,RV=3DOFF,RG=3DOFF}},E=3D369100037= {al/ > = *},SG{}},A=3D${M{O{MO=3DIN,RV=3DOFF,RG=3DOFF,nt/jit=3D40},L{v=3D0c=3DIN = IP4=20 > $m=3Daudio $ RTP/AVP 8}}}}} >=20 > 2.MGW->MGC > MEGACO/1 [182.020.020.050]:2944=20 > = P=3D369361149{C=3D116{A=3DA1,A=3DA100000039{M{O{MO=3DIN,RV=3DOFF,RG=3DOF= F,nt > /jit=3D40},L{v=3D0c=3DIN IP4 182.20.20.50m=3Daudio 16856 RTP/AVP = 8}}}}} >=20 > . > . > . > . > . > . > if mgc wants to change the codec of A100000039 to 18 ,can mgc use=20 > MEGACO/1 [182.20.20.1]:2944=20 > = T=3D370278656{C=3D116{MF=3DA1{M{O{RV=3DOFF,RG=3DOFF,tdmc/ec=3DON}},E=3D3= 6910 > = 0040{al/*},SG{}},MF=3DA100000039{M{O{MO=3DSR,RV=3DOFF,RG=3DOFF,tdmc/ec > =3DON},L{v=3D0c=3DIN IP4 -m=3Daudio - RTP/AVP 18},R{v=3D0c=3DIN IP4=20 > 182.20.20.50m=3Daudio 16860 RTP/AVP 18}}}}} >=20 > to change it ? > (in the local sdp ,mgc use '-' ,the real ip and port is not sent ) >=20 > Best Regards, > Neal >=20 >=20 >=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-bounces@ietf.org Wed Jun 2 03:27:02 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04865 for ; Wed, 2 Jun 2004 03:27:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVPt4-0002aq-0Q; Wed, 02 Jun 2004 03:10:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVPS1-0000sX-Ka for megaco@megatron.ietf.org; Wed, 02 Jun 2004 02:42: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 CAA02334 for ; Wed, 2 Jun 2004 02:42:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BVPRy-00066D-LN for megaco@ietf.org; Wed, 02 Jun 2004 02:42:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BVPQo-0005YV-00 for megaco@ietf.org; Wed, 02 Jun 2004 02:40:58 -0400 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1BVPPa-0004yt-00 for megaco@ietf.org; Wed, 02 Jun 2004 02:39:42 -0400 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i526dhAh003458 for ; Wed, 2 Jun 2004 08:39:43 +0200 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 2 Jun 2004 08:39:43 +0200 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Wed, 2 Jun 2004 08:39:43 +0200 Message-ID: From: "Christer Holmberg (JO/LMF)" To: "'sreeram.kanumuri@wipro.com'" , zhuning@huawei.com, megaco@ietf.org Subject: RE: [Megaco] a doubt about sdp in h248 message Date: Wed, 2 Jun 2004 08:39:41 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-OriginalArrivalTime: 02 Jun 2004 06:39:43.0904 (UTC) FILETIME=[63AB1200:01C4486C] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org Hi, >MGC should not use "-" for only ip and port number in C field of SDP. > >"C" field is optional in SDP and when you do not want to change the >connection parameters better not to use this variable again. The c= (connection) field is MANDATORY in SDP. It must be present either on the session- or media level. In my opinion, like I said earlier, the best way is to use the IP address and port value that you already have, that was assigned to you when the termination was added. Regards, Christer Holmberg Ericsson Finland > > -SReeram > > > > -----Original Message----- > From: megaco-bounces@ietf.org > [mailto:megaco-bounces@ietf.org] On Behalf > Of zhuning 17035 > Sent: Tuesday, June 01, 2004 2:22 PM > To: megaco@ietf.org > Subject: [Megaco] a doubt about sdp in h248 message > > > Hi, > after a rtp termination is added to a context and ip ,port and > codec is reported to mgc ,if mgc wants to just change the > codec but the > ip and port will not be change .can mgc use '-' as ip and > port in sdp of > local? > > 1. MGC->MGW > MEGACO/1 [182.20.20.1]:2944 > T=369361149{C=${A=A1{M{O{MO=SR,RV=OFF,RG=OFF}},E=369100037{al/ > *},SG{}},A > =${M{O{MO=IN,RV=OFF,RG=OFF,nt/jit=40},L{v=0c=IN IP4 $m=audio $ RTP/AVP > 8}}}}} > > 2.MGW->MGC > MEGACO/1 [182.020.020.050]:2944 > P=369361149{C=116{A=A1,A=A100000039{M{O{MO=IN,RV=OFF,RG=OFF,nt > /jit=40},L > {v=0c=IN IP4 182.20.20.50m=audio 16856 RTP/AVP 8}}}}} > > . > . > . > . > . > . > if mgc wants to change the codec of A100000039 to 18 ,can mgc use > MEGACO/1 [182.20.20.1]:2944 > T=370278656{C=116{MF=A1{M{O{RV=OFF,RG=OFF,tdmc/ec=ON}},E=36910 > 0040{al/*} > ,SG{}},MF=A100000039{M{O{MO=SR,RV=OFF,RG=OFF,tdmc/ec=ON},L{v=0c=IN IP4 > -m=audio - RTP/AVP 18},R{v=0c=IN IP4 182.20.20.50m=audio 16860 RTP/AVP > 18}}}}} > > to change it ? > (in the local sdp ,mgc use '-' ,the real ip and port is not sent ) > > Best Regards, > Neal > > > > > > _______________________________________________ > 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-bounces@ietf.org Thu Jun 3 14:15:14 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00109 for ; Thu, 3 Jun 2004 14:15:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVw7I-0004Zx-Eg; Thu, 03 Jun 2004 13:35:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVtx6-0007kh-5t for megaco@megatron.ietf.org; Thu, 03 Jun 2004 11:16:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19437 for ; Thu, 3 Jun 2004 11:15:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BVtwg-0002Ma-21 for megaco@ietf.org; Thu, 03 Jun 2004 11:15:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BVtvT-0001p2-00 for megaco@ietf.org; Thu, 03 Jun 2004 11:14:39 -0400 Received: from smtp5.wanadoo.fr ([193.252.22.26] helo=mwinf0503.wanadoo.fr) by ietf-mx with esmtp (Exim 4.12) id 1BVttQ-0001Cw-00 for Megaco@ietf.org; Thu, 03 Jun 2004 11:12:32 -0400 Received: from francois (ASte-Genev-Bois-151-1-45-178.w83-114.abo.wanadoo.fr [83.114.155.178]) by mwinf0503.wanadoo.fr (SMTP Server) with SMTP id 612606800240 for ; Thu, 3 Jun 2004 17:11:59 +0200 (CEST) Message-ID: <006e01c4497d$274e5080$1501a8c0@francois> From: "Francois Plagnard" To: Date: Thu, 3 Jun 2004 17:12:14 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Megaco] Ambiguity in ABNF of indAudauditReturnParameter in H.248 v2 X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org Content-Transfer-Encoding: 7bit Hello, In H.248v2, in indAudauditReturnParameter ABNF, according to my understanding, there are several ambiguities. For example, indAudmediaDescriptor = MediaToken LBRKT indAudmediaParm RBRKT means for me that you have only 1 instance of indAudmediaParm. But, its definition is : ; at-most-once per item ; and either streamParm or streamDescriptor but not both indAudmediaParm = (indAudstreamParm / indAudstreamDescriptor / indAudterminationStateDescriptor) which implies that you may have several instances ! You have the same ambiguity with : - indAudlocalParm - indAudterminationStateParm ... May we have 1 or several instances of them ? And, if we may have several instances, how are they separated ? Best regards, =================================================================== Francois Plagnard, Netbricks 31 rue Jean Rostand 91893 ORSAY -- FRANCE Email: francois.plagnard@netbricks.com - WEB : www.netbricks.com Tel: +33 (0)1 69 33 12 57 -- Fax: +33 (0)1 69 85 54 26 =================================================================== _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Sun Jun 6 08:51:15 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29070 for ; Sun, 6 Jun 2004 08:51:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BWx4m-0006yA-OF; Sun, 06 Jun 2004 08:48:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BWx3K-0006fu-MC for megaco@megatron.ietf.org; Sun, 06 Jun 2004 08:47: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 IAA28788 for ; Sun, 6 Jun 2004 08:47:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BWx3J-0004cd-RH for megaco@ietf.org; Sun, 06 Jun 2004 08:47:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BWx2J-0004Ly-00 for megaco@ietf.org; Sun, 06 Jun 2004 08:46:05 -0400 Received: from mail.tdsoft.com ([212.143.64.34] helo=TdSoft.eSafe.com) by ietf-mx with smtp (Exim 4.12) id 1BWx1F-0003sH-00 for megaco@ietf.org; Sun, 06 Jun 2004 08:44:57 -0400 Received: from mailserver.td-soft.co.il ([IP=172.16.1.203]) by eSafe SMTP Relay 1086263786; Sun Jun 06 15:46:09 2004 Received: by MAILSERVER with Internet Mail Service (5.5.2657.72) id ; Sun, 6 Jun 2004 15:43:45 +0200 Message-ID: <9A64A99CD3F2BD4582BE4FB63FC1F3816D0F8A@MAILSERVER> From: Raphael Tryster To: "'megaco@ietf.org'" Subject: RE: [Megaco] Descriptor processing on Termination OOS Date: Sun, 6 Jun 2004 15:43:37 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-eSafe-inspection-result: Mail clean X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE autolearn=no version=2.60 X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2038383916==" Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org 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. --===============2038383916== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C44BCC.44E5A9D0" 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_01C44BCC.44E5A9D0 Content-Type: text/plain; charset="iso-8859-1" Hello Christian, I gather from your reply that in my first question, 6.2.4 overrides 7.1.11, and in my second question, it is the MGC's responsibility to avoid inconsistencies. Does the former mean that even off/on signals terminate on subtraction from a context? Therefore, if the MGC wants something like VMWI to persist, it has to re-issue it on every subtract? Raphael Tryster -----Original Message----- From: Christian Groves [SMTP:christian.groves@ericsson.com] Sent: Friday, 28 May 2004 7:09 To: Raphael Tryster Cc: 'Kevin Boyle'; bvswamy@hss.hns.com; anilj@cisco.com; Tom-PT Taylor; megaco@ietf.org Subject: Re: [Megaco] Descriptor processing on Termination OOS Hello Raphael, Please see my comments below. Regards, Christian Raphael Tryster wrote: > Two questions related to the discussion below: > > Firstly, the quote below from H.248.1 6.2.4 seems to contradict section > 7.1.11, which states: > > "Production of a Signal on a Termination is stopped by application of a > new SignalsDescriptor, or detection of an Event on the Termination". > > What about returning to the null context? According to 6.2.4, the > signal should stop, whereas according to 7.1.11, it should not stop. > Unless the resetting of descriptors to default values when returning to > the null context is considered to be a case of application of a new > SignalsDescriptor? But then what do we do about on/off type signals, > e.g. visual message waiting indicator? Surely they are meant to survive > subtraction from a context? [CHG] I would assume that by returning a termination to the NULL context via a subtract results in a signal being stopped. 6.2.4 says, "If not provisioned otherwise, the properties in all descriptors except TerminationState and LocalControl default to empty/"no value" when a Termination is first created or returned to the null Context. The default contents of the two exceptions are described in 7.1.5 and 7.1.7." 7.1.11 talks about replacement SignalDescriptor which is effectively what happens when you return to the NULL context. The current descriptors are replaced by the provisioned descriptors. Also 7.1.11 is not mentioned as an exception. > > My second question concerns the requirement that the MG maintain > terminations in contexts until the MGC explicitly subtracts them. > Consider a distributed MG, in which the part that talks to the MGC does > not completely control the part that allocates resources such as IP > address and UDP port for local descriptors. Suppose some administrative > action or fault causes these resources to become physically unavailable > to the termination with which they were associated. The MG informs the > MGC (or fails to do so if the MGC didn't request the event), but for > some reason the MGC does not issue a Subtract. The front end of the MG > has no problem complying with Megaco rules: it will accept any commands > it can on that context, and send a proper rejection if the cleanup that > has taken place in the back end makes it impossible to comply with a > request. However, if the MGC audits the local descriptor, the MG front > end will send an IP address and UDP port that the back end may already > be reusing for another call. The MGC can then presumably do bad things > with this outdated information. Which of the following are legitimate > solutions to this problem? > > 1. The MGC is at fault for ignoring indications from the MG that > something went wrong. > > 2. The MG is at fault for being schizophrenic. It must prevent reuse > of all resources associated with the context until it receives > Subtract. > > 3. The MG can sidestep the problem. It is only required to keep the > termination in the context, but it can clear the local > descriptor. (And what if the MGC doesn't audit but relies on its > memory?) > > 4. There is no problem. The MGC cannot do anything bad with the > information. [CHG] I would suggest that if the MG has experienced a problem with the termination that it send a generic cause event indicating failure. It the MGC doesn't request this event then the designers must understand the consequences. Also if there is a more terminal failure a servicechange could be sent. > > Raphael Tryster ------_=_NextPart_001_01C44BCC.44E5A9D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Megaco] Descriptor processing on Termination OOS

    Hello Christian,

    I gather from your reply that in my firs= t question, 6.2.4 overrides 7.1.11, and in my second question, it is the = MGC's responsibility to avoid inconsistencies.  Does the former mean= that even off/on signals terminate on subtraction from a context?  = Therefore, if the MGC wants something like VMWI to persist, it has to re-= issue it on every subtract?

    Raphael Tryster


      -----Original Message-----
      From:   Christian Groves [= SMTP:christian.groves@ericsson.com]
      Sent:   Friday, 28 May 2004 7:09
      To:     Raphael Tryster
      Cc:     'Kevin Boyle'; bvswamy@hss.hns.com; anil= j@cisco.com; Tom-PT Taylor; megaco@ietf.org
      Subject:    &nbs= p;   Re: [Megaco] Desc= riptor processing on Termination OOS

      Hello Raphael,

      Please see my comments below.

      Regards, Christian

      Raphael Tryster wrote:

      > Two questions related to the = discussion below:
      >
      > Firstly, the quote below fro= m H.248.1 6.2.4 seems to contradict section
      > 7.1.11, which states:
      >
      > "Production of a Signal= on a Termination is stopped by application of a
      > new SignalsDescriptor, or de= tection of an Event on the Termination".
      >
      > What about returning to the = null context?  According to 6.2.4, the
      > signal should stop, whereas = according to 7.1.11, it should not stop. 
      > Unless the resetting of desc= riptors to default values when returning to
      > the null context is consider= ed to be a case of application of a new
      > SignalsDescriptor?  But= then what do we do about on/off type signals,
      > e.g. visual message waiting = indicator?  Surely they are meant to survive
      > subtraction from a context?<= /FONT>

      [CHG] I would assume that by retur= ning a termination to the NULL context via a
      subtract results in a signal bein= g stopped. 6.2.4 says, "If not provisioned
      otherwise, the properties in all = descriptors except TerminationState and
      LocalControl default to empty/&qu= ot;no value" when a Termination is first created or
      returned to the null Context. The= default contents of the two exceptions are
      described in 7.1.5 and 7.1.7.&quo= t; 7.1.11 talks about replacement SignalDescriptor
      which is effectively what happens= when you return to the NULL context. The
      current descriptors are replaced = by the provisioned descriptors. Also 7.1.11 is
      not mentioned as an exception.

      >
      > My second question concerns = the requirement that the MG maintain
      > terminations in contexts unt= il the MGC explicitly subtracts them. 
      > Consider a distributed MG, i= n which the part that talks to the MGC does
      > not completely control the p= art that allocates resources such as IP
      > address and UDP port for loc= al descriptors.  Suppose some administrative
      > action or fault causes these= resources to become physically unavailable
      > to the termination with whic= h they were associated.  The MG informs the
      > MGC (or fails to do so if th= e MGC didn't request the event), but for
      > some reason the MGC does not= issue a Subtract.  The front end of the MG
      > has no problem complying wit= h Megaco rules: it will accept any commands
      > it can on that context, and = send a proper rejection if the cleanup that
      > has taken place in the back = end makes it impossible to comply with a
      > request.  However, if t= he MGC audits the local descriptor, the MG front
      > end will send an IP address = and UDP port that the back end may already
      > be reusing for another call.=   The MGC can then presumably do bad things
      > with this outdated informati= on.  Which of the following are legitimate
      > solutions to this problem?
      >
      >    1. The MGC= is at fault for ignoring indications from the MG that
      >     = ;  something went wrong.
      >
      >    2. The MG = is at fault for being schizophrenic.  It must prevent reuse
      >     = ;  of all resources associated with the context until it receives
      >     = ;  Subtract.
      >
      >    3. The MG = can sidestep the problem.  It is only required to keep the
      >     = ;  termination in the context, but it can clear the local
      >     = ;  descriptor.  (And what if the MGC doesn't audit but relies o= n its
      >     = ;  memory?)
      >
      >    4. There i= s no problem.  The MGC cannot do anything bad with the
      >     = ;  information.

      [CHG] I would suggest that if the = MG has experienced a problem with the
      termination that it send a generi= c cause event indicating failure. It the MGC
      doesn't request this event then t= he designers must understand the consequences.
      Also if there is a more terminal = failure a servicechange could be sent.

      >
      > Raphael Tryster

------_=_NextPart_001_01C44BCC.44E5A9D0-- --===============2038383916== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============2038383916==-- From megaco-bounces@ietf.org Sun Jun 6 20:18:24 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27387 for ; Sun, 6 Jun 2004 20:18:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BX7m2-0002YB-HB; Sun, 06 Jun 2004 20:13:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BX7jn-0001yY-PN for megaco@megatron.ietf.org; Sun, 06 Jun 2004 20:11: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 UAA27251 for ; Sun, 6 Jun 2004 20:11:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BX7jm-0005Kk-34 for megaco@ietf.org; Sun, 06 Jun 2004 20:11:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BX7iq-00054U-00 for megaco@ietf.org; Sun, 06 Jun 2004 20:10:42 -0400 Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1BX7iQ-0004nu-00 for megaco@ietf.org; Sun, 06 Jun 2004 20:10:14 -0400 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i570AEWR002028 for ; Mon, 7 Jun 2004 02:10:14 +0200 (MEST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 7 Jun 2004 02:10:14 +0200 Received: from eaubrnt019.epa.ericsson.se ([146.11.9.165]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id MATK2S2B; Mon, 7 Jun 2004 02:10:13 +0200 Received: from ericsson.com (EG2E500202DSEGL [146.11.22.3]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id LGSR7YQ9; Mon, 7 Jun 2004 10:10:02 +1000 Message-ID: <40C3B26D.9090108@ericsson.com> Date: Mon, 07 Jun 2004 10:10:21 +1000 X-Sybari-Trust: 5121fa35 3becbf40 eceda994 00000139 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Raphael Tryster Subject: Re: [Megaco] Descriptor processing on Termination OOS References: <9A64A99CD3F2BD4582BE4FB63FC1F3816D0F89@MAILSERVER> In-Reply-To: <9A64A99CD3F2BD4582BE4FB63FC1F3816D0F89@MAILSERVER> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Jun 2004 00:10:14.0730 (UTC) FILETIME=[CE9EDAA0:01C44C23] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cc: Tom-PT Taylor , anilj@cisco.com, megaco@ietf.org, bvswamy@hss.hns.com, "'Kevin Boyle'" X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org Content-Transfer-Encoding: 7bit Hello Raphael, A signal's descriptor cannot be sent in a subtract command. It would have to be modified in the NULL context. Regards, Christian Raphael Tryster wrote: > Hello Christian, > > I gather from your reply that in my first question, 6.2.4 overrides > 7.1.11, and in my second question, it is the MGC's responsibility to > avoid inconsistencies. Does the former mean that even off/on signals > terminate on subtraction from a context? Therefore, if the MGC wants > something like VMWI to persist, it has to re-issue it on every subtract? > > Raphael Tryster > > > -----Original Message----- > From: Christian Groves [SMTP:christian.groves@ericsson.com] > Sent: Friday, 28 May 2004 7:09 > To: Raphael Tryster > Cc: 'Kevin Boyle'; bvswamy@hss.hns.com; anilj@cisco.com; > Tom-PT Taylor; megaco@ietf.org > Subject: Re: [Megaco] Descriptor processing on Termination OOS > > Hello Raphael, > > Please see my comments below. > > Regards, Christian > > Raphael Tryster wrote: > > > Two questions related to the discussion below: > > > > Firstly, the quote below from H.248.1 6.2.4 seems to contradict > section > > 7.1.11, which states: > > > > "Production of a Signal on a Termination is stopped by > application of a > > new SignalsDescriptor, or detection of an Event on the > Termination". > > > > What about returning to the null context? According to 6.2.4, the > > signal should stop, whereas according to 7.1.11, it should not > stop. > > Unless the resetting of descriptors to default values when > returning to > > the null context is considered to be a case of application of a > new > > SignalsDescriptor? But then what do we do about on/off type > signals, > > e.g. visual message waiting indicator? Surely they are meant > to survive > > subtraction from a context? > > [CHG] I would assume that by returning a termination to the NULL > context via a > subtract results in a signal being stopped. 6.2.4 says, "If not > provisioned > otherwise, the properties in all descriptors except > TerminationState and > LocalControl default to empty/"no value" when a Termination is > first created or > returned to the null Context. The default contents of the two > exceptions are > described in 7.1.5 and 7.1.7." 7.1.11 talks about replacement > SignalDescriptor > which is effectively what happens when you return to the NULL > context. The > current descriptors are replaced by the provisioned descriptors. > Also 7.1.11 is > not mentioned as an exception. > > > > > My second question concerns the requirement that the MG maintain > > terminations in contexts until the MGC explicitly subtracts them. > > Consider a distributed MG, in which the part that talks to the > MGC does > > not completely control the part that allocates resources such > as IP > > address and UDP port for local descriptors. Suppose some > administrative > > action or fault causes these resources to become physically > unavailable > > to the termination with which they were associated. The MG > informs the > > MGC (or fails to do so if the MGC didn't request the event), > but for > > some reason the MGC does not issue a Subtract. The front end > of the MG > > has no problem complying with Megaco rules: it will accept any > commands > > it can on that context, and send a proper rejection if the > cleanup that > > has taken place in the back end makes it impossible to comply > with a > > request. However, if the MGC audits the local descriptor, the > MG front > > end will send an IP address and UDP port that the back end may > already > > be reusing for another call. The MGC can then presumably do > bad things > > with this outdated information. Which of the following are > legitimate > > solutions to this problem? > > > > 1. The MGC is at fault for ignoring indications from the MG > that > > something went wrong. > > > > 2. The MG is at fault for being schizophrenic. It must > prevent reuse > > of all resources associated with the context until it > receives > > Subtract. > > > > 3. The MG can sidestep the problem. It is only required to > keep the > > termination in the context, but it can clear the local > > descriptor. (And what if the MGC doesn't audit but > relies on its > > memory?) > > > > 4. There is no problem. The MGC cannot do anything bad with > the > > information. > > [CHG] I would suggest that if the MG has experienced a problem > with the > termination that it send a generic cause event indicating failure. > It the MGC > doesn't request this event then the designers must understand the > consequences. > Also if there is a more terminal failure a servicechange could be > sent. > > > > > Raphael Tryster > > > > > > -----Original Message----- > > From: Kevin Boyle [SMTP:kboyle@nortelnetworks.com] > > Sent: Wednesday, 17 December 2003 18:19 > > To: Christian Groves; bvswamy@hss.hns.com; > anilj@cisco.com > > Cc: megaco_maillist@hss.hns.com; Tom-PT Taylor; > megaco@ietf.org > > Subject: RE: [Megaco] Descriptor processing on > Termination OOS > > > > Right. I just wanted to ensure that everyone understands > that the > > reset of the descriptors is a result of the SUBTRACT, and > not a > > result of the SERVICECHANGE. > > > > Subtle, but important, difference. > > > > Kevin > > > > -----Original Message----- > > From: Christian Groves [ > mailto:Christian.Groves@ericsson.com] > > Sent: Tuesday, December 16, 2003 6:05 PM > > To: Boyle, Kevin [NCRTP:3Z40:EXCH]; bvswamy@hss.hns.com; > > anilj@cisco.com > > Cc: megaco_maillist@hss.hns.com; Taylor, Tom-PT > [CAR:5N00:EXCH]; > > megaco@ietf.org > > Subject: Re: [Megaco] Descriptor processing on > Termination OOS > > > > Hello, > > > > OOS Service by its nature must be reported by a > ServiceChange, > > this can be through Forced which states: At a minimum, the > > Termination shall be subtracted from the Context. > Graceful is > > similar that the MGC is expected to "clean up" the > termination > > ultimately by subtracting the termination. > > > > So for ephemeral terminations there's no discussion as > they'll > > disappear the MGC won't be able to do anything to them. For > > physical terminations the following rule applies: > > > > H.248.1 6.2.4 Termination properties and descriptors .... > > If not provisioned otherwise, the properties in all > descriptors > > except TerminationState and LocalControl default to > empty/"no > > value" when a Termination is first created or returned to > the null > > Context. > > > > ... > > > > This text is very clear when a termination goes back to > the NULL > > context which for TDM terminations is the result of going > "out of > > service" the descriptors ARE changed. > > > > I can remember that this behaviour caused quite a bit of > > discussion at the time (I think Tom drafted the text) and > it was > > felt that this was the best behaviour because it left > terminations > > in a known state both for the MG and MGC. > > > > Regards, Christian > > > > Kevin Boyle wrote: > > > > > Comments inline [KJBII] > > > > > > Kevin > > > > > > -----Original Message----- > > > From: bvswamy@hss.hns.com [ mailto:bvswamy@hss.hns.com] > > > Sent: Tuesday, December 16, 2003 9:03 AM > > > To: anilj@cisco.com > > > Cc: megaco_maillist@hss.hns.com; Taylor, Tom-PT > [CAR:5N00:EXCH]; > > > megaco@ietf.org > > > Subject: RE: [Megaco] Descriptor processing on > Termination OOS > > > > > > > > > > > > > > > > > > Hi > > > Please find my comments embedded.[BVS]. > > > Regards > > > Venkat > > > > > > > > > > > > > > > > > > "Anil Jangam \(anilj\)" @ietf.org on > 12/16/2003 > > > 01:33:27 PM > > > > > > Please respond to > > > > > > Sent by: megaco-admin@ietf.org > > > > > > > > > To: megaco_maillist@HSS, "'Tom Taylor'" > > > > > cc: > > > > > > Subject: RE: [Megaco] Descriptor processing on > Termination OOS > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: megaco-admin@ietf.org [ > mailto:megaco-admin@ietf.org] On > > > Behalf > Of megaco_maillist@hss.hns.com > Sent: > Tuesday, December > > > 16, 2003 11:53 AM > To: Tom Taylor > Cc: > megaco@ietf.org > > > Subject: > > > Re: [Megaco] Descriptor processing on Termination OOS > > > > > > > > > > > > > Hi > > > > In my opinion keeping the descriptors alive and > > enabled for a > > > > termination which is in Out of Service state does > not seems > > to be a > > > > valid behaviour of MG. For example if the card > containing the > > > > termination is jacked out of the chasis then > definately at the > > > > hardware level all the events and signals get > disabled. There > > would > > > > be a major disconnect wrt descriptors state if MGC > does not audit > > > the > termination since if MGC were to audit the > termination then > > > > MG would be returning empty descriptors in this > particular > > > > case. Now in > > > > this condition if the card is jacked-in and > termination is > > made > > > > in-service then the exact state of original > descriptors no more > > holds > > > > good and mgc needs to apply the descriptors again. > > > > > > > > Hence for a termination which is in > Out-of-Service > > state MGC can > > > > fairly assume that all descriptors are no more > valid and > > whenever > > > the > termination comes up will reapply the descriptors > > afresh. This > > > > assumption holds true whether or not termination is > involved > > in a > > > > call. > > > > > > First thing, there is no provision for the MG to > change the > > state of > > > the descriptor by its own. If we see the commands that > can > > change the > > > descriptor state, these are commands which MGC initiate. > > > > > > [BVS] I agree with you from the protocol perspective. > But, if you > > > analyse the actual scenario, service change (to > out-of-service) > > for a > > > termination would mean disabling operations such as > signals/ > > events/ > > > streams. Further, this would mean that MG does take > some action > > on its > > > own when it generates a Service Change (or MGC sends a > service > > change) > > > on the termination. > > > > > > If MG returns the descriptors in Audit response it > would mean > > > incorrect representation of facts to MGC. > > > > > > [KJBII] The MG may not take action on its own, whether > we are > > talking > > > about a hardware failure or some other occurrence. > The text is > > > explicit: the MG may not reset those descriptors. If > the MGC > > wanted > > > to audit, it may very well be to collect diagnostic > data. If > > the MG > > > wipes them out, then that data is lost. > > > > > > In the SVC with SVCMethod = forced, its mentioned that > MGC is > > going to > > > clean up the context, in which case it is to subtract the > > termination > > > from the cotext. At this point MGC can reset the > descriptor > > state to > > > the default if necessary. Same logic can be applied > when the > > SVCMethod > > > is graceful. > > > > > > [BVS] Cleaning up the context using subtract is OK for > > terminations in > > > a valid context. But, what about the terminations > which are > > already in > > > the null context. > > > > > > [KJBII] What about them? Modifies are allowed on OOS > > terminations. > > > The MGC could very well send a modify to empty the > descriptors. > > > > > > > > > In the call flows as well, when the termination is > coming back into > > > the service, normally a Modify is sent to MG > initializing the term. > > > > > > > > > [BVS] Based upon our experience in the interop events, > this > > MODIFY is > > > applicable to only certain call scenarios (e.g. POTS > call) and > > not for > > > other scenarios (like Trunkling). > > > > > > Moreover, it is not used for clean up operations (like > empty Signal > > > descriptor, empty media descriptor etc.), but for the > call > > setup (like > > > event descriptor with OffHook). > > > > > > [KJBII] MGCs that do not reset the state of the > descriptors upon > > > return to service will be subject to its own > problems. It > > seems to me > > > that the MGC would want to make sure the descriptors > are in a > > > particular state by explicitly making them that way. > Further, > > I know > > > of several implementations that send empty descriptors > in Modify > > > commands. Any assumption that they are not used for > normal call > > > processing operations is deficient. > > > > > > > > > So given this, IMO we don't have to make any > assumption about the > > > descriptor state once its taken OOS. > > > > > > > > > > > Regards > > > > Venkat > > > > > > > > > > > > > > > > > > > > > > > > Tom Taylor @ietf.org on > 12/01/2003 > > > > 11:52:03 PM > > > > > Sent by: megaco-admin@ietf.org > > > > > > > > > > > > To: Sampath Komanduri > > > > cc: megaco@ietf.org > > > > > > > > Subject: Re: [Megaco] Descriptor processing on > > Termination OOS > > > > > > > > > > > > The descriptors (aside from TerminationState) > remain unchanged > > > until > either the MGC changes them or the MG > undergoes a cold > > restart. > > > > > > > > Sampath Komanduri wrote: > > > > > > > > > > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Sun Jun 6 20:33:14 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27939 for ; Sun, 6 Jun 2004 20:33:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BX81H-0005Xf-DD; Sun, 06 Jun 2004 20:29:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BX80D-0005EV-6j for megaco@megatron.ietf.org; Sun, 06 Jun 2004 20:28: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 UAA27789 for ; Sun, 6 Jun 2004 20:28:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BX80B-0002Jr-JI for megaco@ietf.org; Sun, 06 Jun 2004 20:28:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BX7zC-00022U-00 for megaco@ietf.org; Sun, 06 Jun 2004 20:27:34 -0400 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1BX7y9-0001aK-00 for Megaco@ietf.org; Sun, 06 Jun 2004 20:26:29 -0400 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i570QTAh016418 for ; Mon, 7 Jun 2004 02:26:29 +0200 Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 7 Jun 2004 02:26:29 +0200 Received: from eaubrnt019.epa.ericsson.se ([146.11.9.165]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id L79P1XVC; Mon, 7 Jun 2004 02:26:29 +0200 Received: from ericsson.com (EG2E500202DSEGL [146.11.22.3]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id LGSR7YY5; Mon, 7 Jun 2004 10:26:26 +1000 Message-ID: <40C3B646.1090104@ericsson.com> Date: Mon, 07 Jun 2004 10:26:46 +1000 X-Sybari-Trust: a374a03f 08d63d2e dfd72bfa 00000138 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francois Plagnard Subject: Re: [Megaco] Ambiguity in ABNF of indAudauditReturnParameter in H.248 v2 References: <006e01c4497d$274e5080$1501a8c0@francois> In-Reply-To: <006e01c4497d$274e5080$1501a8c0@francois> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Jun 2004 00:26:29.0727 (UTC) FILETIME=[13C396F0:01C44C26] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cc: Megaco@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org Content-Transfer-Encoding: 7bit Hello Francois, I'm having some problem understanding what the ambiguity is. Please see my comments below. Regards, Christian Francois Plagnard wrote: > Hello, > > In H.248v2, in indAudauditReturnParameter ABNF, according to my > understanding, there are several ambiguities. > > For example, > indAudmediaDescriptor = MediaToken LBRKT indAudmediaParm RBRKT > means for me that you have only 1 instance of indAudmediaParm. [CHG] Yes I agree. > > But, its definition is : > ; at-most-once per item > ; and either streamParm or streamDescriptor but not both > indAudmediaParm = (indAudstreamParm / indAudstreamDescriptor / > indAudterminationStateDescriptor) > which implies that you may have several instances ! [CHG] Doesn't this imply that you "choose" one instance from the alternatives? > > You have the same ambiguity with : > - indAudlocalParm > - indAudterminationStateParm > ... > > May we have 1 or several instances of them ? > And, if we may have several instances, how are they separated ? > > Best regards, > > =================================================================== > Francois Plagnard, > Netbricks > 31 rue Jean Rostand > 91893 ORSAY -- FRANCE > Email: francois.plagnard@netbricks.com - WEB : www.netbricks.com > Tel: +33 (0)1 69 33 12 57 -- Fax: +33 (0)1 69 85 54 26 > =================================================================== > > > _______________________________________________ > 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-bounces@ietf.org Mon Jun 7 01:07:55 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08983 for ; Mon, 7 Jun 2004 01:07:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXCHR-0000lu-E1; Mon, 07 Jun 2004 01:02:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXCC9-00084V-1c for megaco@megatron.ietf.org; Mon, 07 Jun 2004 00:57: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 AAA08572 for ; Mon, 7 Jun 2004 00:57:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXCC7-0002tQ-04 for megaco@ietf.org; Mon, 07 Jun 2004 00:57:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXCBG-0002X1-00 for megaco@ietf.org; Mon, 07 Jun 2004 00:56:20 -0400 Received: from mail.tdsoft.com ([212.143.64.34] helo=TdSoft.eSafe.com) by ietf-mx with smtp (Exim 4.12) id 1BXCAO-00028V-00 for megaco@ietf.org; Mon, 07 Jun 2004 00:55:25 -0400 Received: from mailserver.td-soft.co.il ([IP=172.16.1.203]) by eSafe SMTP Relay 1086263786; Mon Jun 07 07:56:08 2004 Received: by MAILSERVER with Internet Mail Service (5.5.2657.72) id ; Mon, 7 Jun 2004 07:53:40 +0200 Message-ID: <9A64A99CD3F2BD4582BE4FB63FC1F3816D0F93@MAILSERVER> From: Raphael Tryster To: "'Christian Groves'" Subject: RE: [Megaco] Descriptor processing on Termination OOS Date: Mon, 7 Jun 2004 07:53:12 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-eSafe-inspection-result: Mail clean X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,HTML_40_50,HTML_MESSAGE autolearn=no version=2.60 Cc: Tom-PT Taylor , anilj@cisco.com, megaco@ietf.org, bvswamy@hss.hns.com, "'Kevin Boyle'" X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0390288165==" Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org 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. --===============0390288165== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C44C53.B82B52A0" 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_01C44C53.B82B52A0 Content-Type: text/plain; charset="iso-8859-1" So there would be a discontinuity in the signal. Is that what real MGCs do? Raphael Tryster -----Original Message----- From: Christian Groves [SMTP:christian.groves@ericsson.com] Sent: Monday, 7 June 2004 2:10 To: Raphael Tryster Cc: 'Kevin Boyle'; bvswamy@hss.hns.com; anilj@cisco.com; Tom-PT Taylor; megaco@ietf.org Subject: Re: [Megaco] Descriptor processing on Termination OOS Hello Raphael, A signal's descriptor cannot be sent in a subtract command. It would have to be modified in the NULL context. Regards, Christian Raphael Tryster wrote: > Hello Christian, > > I gather from your reply that in my first question, 6.2.4 overrides > 7.1.11, and in my second question, it is the MGC's responsibility to > avoid inconsistencies. Does the former mean that even off/on signals > terminate on subtraction from a context? Therefore, if the MGC wants > something like VMWI to persist, it has to re-issue it on every subtract? > > Raphael Tryster > > > -----Original Message----- > From: Christian Groves [SMTP:christian.groves@ericsson.com] > Sent: Friday, 28 May 2004 7:09 > To: Raphael Tryster > Cc: 'Kevin Boyle'; bvswamy@hss.hns.com; anilj@cisco.com; > Tom-PT Taylor; megaco@ietf.org > Subject: Re: [Megaco] Descriptor processing on Termination OOS > > Hello Raphael, > > Please see my comments below. > > Regards, Christian > > Raphael Tryster wrote: > > > Two questions related to the discussion below: > > > > Firstly, the quote below from H.248.1 6.2.4 seems to contradict > section > > 7.1.11, which states: > > > > "Production of a Signal on a Termination is stopped by > application of a > > new SignalsDescriptor, or detection of an Event on the > Termination". > > > > What about returning to the null context? According to 6.2.4, the > > signal should stop, whereas according to 7.1.11, it should not > stop. > > Unless the resetting of descriptors to default values when > returning to > > the null context is considered to be a case of application of a > new > > SignalsDescriptor? But then what do we do about on/off type > signals, > > e.g. visual message waiting indicator? Surely they are meant > to survive > > subtraction from a context? > > [CHG] I would assume that by returning a termination to the NULL > context via a > subtract results in a signal being stopped. 6.2.4 says, "If not > provisioned > otherwise, the properties in all descriptors except > TerminationState and > LocalControl default to empty/"no value" when a Termination is > first created or > returned to the null Context. The default contents of the two > exceptions are > described in 7.1.5 and 7.1.7." 7.1.11 talks about replacement > SignalDescriptor > which is effectively what happens when you return to the NULL > context. The > current descriptors are replaced by the provisioned descriptors. > Also 7.1.11 is > not mentioned as an exception. > > > > > My second question concerns the requirement that the MG maintain > > terminations in contexts until the MGC explicitly subtracts them. > > Consider a distributed MG, in which the part that talks to the > MGC does > > not completely control the part that allocates resources such > as IP > > address and UDP port for local descriptors. Suppose some > administrative > > action or fault causes these resources to become physically > unavailable > > to the termination with which they were associated. The MG > informs the > > MGC (or fails to do so if the MGC didn't request the event), > but for > > some reason the MGC does not issue a Subtract. The front end > of the MG > > has no problem complying with Megaco rules: it will accept any > commands > > it can on that context, and send a proper rejection if the > cleanup that > > has taken place in the back end makes it impossible to comply > with a > > request. However, if the MGC audits the local descriptor, the > MG front > > end will send an IP address and UDP port that the back end may > already > > be reusing for another call. The MGC can then presumably do > bad things > > with this outdated information. Which of the following are > legitimate > > solutions to this problem? > > > > 1. The MGC is at fault for ignoring indications from the MG > that > > something went wrong. > > > > 2. The MG is at fault for being schizophrenic. It must > prevent reuse > > of all resources associated with the context until it > receives > > Subtract. > > > > 3. The MG can sidestep the problem. It is only required to > keep the > > termination in the context, but it can clear the local > > descriptor. (And what if the MGC doesn't audit but > relies on its > > memory?) > > > > 4. There is no problem. The MGC cannot do anything bad with > the > > information. > > [CHG] I would suggest that if the MG has experienced a problem > with the > termination that it send a generic cause event indicating failure. > It the MGC > doesn't request this event then the designers must understand the > consequences. > Also if there is a more terminal failure a servicechange could be > sent. > > > > > Raphael Tryster > > ------_=_NextPart_001_01C44C53.B82B52A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Megaco] Descriptor processing on Termination OOS

So there would be a discontinuity in the= signal.  Is that what real MGCs do?

Raphael Tryster


    -----Original Mess= age-----
    From:   Christian Groves [= SMTP:christian.groves@ericsson.com]
    Sent:   Monday, 7 June 2004 2:10
    To:     Raphael Tryster
    Cc:     'Kevin Boyle'; bvswamy@hss.hns.com; anil= j@cisco.com; Tom-PT Taylor; megaco@ietf.org
    Subject:    &nbs= p;   Re: [Megaco] Desc= riptor processing on Termination OOS

    Hello Raphael,

    A signal's descriptor cannot be se= nt in a subtract command. It would have to be
    modified in the NULL context.

    Regards, Christian

    Raphael Tryster wrote:

    > Hello Christian,
    >
    > I gather from your reply tha= t in my first question, 6.2.4 overrides
    > 7.1.11, and in my second que= stion, it is the MGC's responsibility to
    > avoid inconsistencies. = Does the former mean that even off/on signals
    > terminate on subtraction fro= m a context?  Therefore, if the MGC wants
    > something like VMWI to persi= st, it has to re-issue it on every subtract?
    >
    > Raphael Tryster
    >
    >
    >     = ;  -----Original Message-----
    >     = ;  From:   Christian Groves [SMTP:christian.groves@ericsso= n.com]
    >     = ;  Sent:   Friday, 28 May 2004 7:09
    >     = ;  To:     Raphael Tryster
    >     = ;  Cc:     'Kevin Boyle'; bvswamy@hss.hns.com; a= nilj@cisco.com;
    >     = ;  Tom-PT Taylor; megaco@ietf.org
    >     = ;  Subject:        Re: [Megaco] D= escriptor processing on Termination OOS
    >
    >     = ;  Hello Raphael,
    >
    >     = ;  Please see my comments below.
    >
    >     = ;  Regards, Christian
    >
    >     = ;  Raphael Tryster wrote:
    >
    >     = ;   > Two questions related to the discussion below:
    >     = ;   >
    >     = ;   > Firstly, the quote below from H.248.1 6.2.4 seems to c= ontradict
    >     = ;  section
    >     = ;   > 7.1.11, which states:
    >     = ;   >
    >     = ;   > "Production of a Signal on a Termination is stopp= ed by
    >     = ;  application of a
    >     = ;   > new SignalsDescriptor, or detection of an Event on the=
    >     = ;  Termination".
    >     = ;   >
    >     = ;   > What about returning to the null context?  Accord= ing to 6.2.4, the
    >     = ;   > signal should stop, whereas according to 7.1.11, it sh= ould not
    >     = ;  stop.
    >     = ;   > Unless the resetting of descriptors to default values = when
    >     = ;  returning to
    >     = ;   > the null context is considered to be a case of applica= tion of a
    >     = ;  new
    >     = ;   > SignalsDescriptor?  But then what do we do about = on/off type
    >     = ;  signals,
    >     = ;   > e.g. visual message waiting indicator?  Surely th= ey are meant
    >     = ;  to survive
    >     = ;   > subtraction from a context?
    >
    >     = ;  [CHG] I would assume that by returning a termination to the NULL<= /FONT>
    >     = ;  context via a
    >     = ;  subtract results in a signal being stopped. 6.2.4 says, "If = not
    >     = ;  provisioned
    >     = ;  otherwise, the properties in all descriptors except
    >     = ;  TerminationState and
    >     = ;  LocalControl default to empty/"no value" when a Termina= tion is
    >     = ;  first created or
    >     = ;  returned to the null Context. The default contents of the two
    >     = ;  exceptions are
    >     = ;  described in 7.1.5 and 7.1.7." 7.1.11 talks about replacemen= t
    >     = ;  SignalDescriptor
    >     = ;  which is effectively what happens when you return to the NULL
    >     = ;  context. The
    >     = ;  current descriptors are replaced by the provisioned descriptors.<= /FONT>
    >     = ;  Also 7.1.11 is
    >     = ;  not mentioned as an exception.
    >
    >     = ;   >
    >     = ;   > My second question concerns the requirement that the M= G maintain
    >     = ;   > terminations in contexts until the MGC explicitly subt= racts them.
    >     = ;   > Consider a distributed MG, in which the part that talk= s to the
    >     = ;  MGC does
    >     = ;   > not completely control the part that allocates resourc= es such
    >     = ;  as IP
    >     = ;   > address and UDP port for local descriptors.  Supp= ose some
    >     = ;  administrative
    >     = ;   > action or fault causes these resources to become physi= cally
    >     = ;  unavailable
    >     = ;   > to the termination with which they were associated.&nb= sp; The MG
    >     = ;  informs the
    >     = ;   > MGC (or fails to do so if the MGC didn't request the e= vent),
    >     = ;  but for
    >     = ;   > some reason the MGC does not issue a Subtract.  T= he front end
    >     = ;  of the MG
    >     = ;   > has no problem complying with Megaco rules: it will ac= cept any
    >     = ;  commands
    >     = ;   > it can on that context, and send a proper rejection if= the
    >     = ;  cleanup that
    >     = ;   > has taken place in the back end makes it impossible to= comply
    >     = ;  with a
    >     = ;   > request.  However, if the MGC audits the local de= scriptor, the
    >     = ;  MG front
    >     = ;   > end will send an IP address and UDP port that the back= end may
    >     = ;  already
    >     = ;   > be reusing for another call.  The MGC can then pr= esumably do
    >     = ;  bad things
    >     = ;   > with this outdated information.  Which of the fol= lowing are
    >     = ;  legitimate
    >     = ;   > solutions to this problem?
    >     = ;   >
    >     = ;   >    1. The MGC is at fault for ignoring = indications from the MG
    >     = ;  that
    >     = ;   >       something went wro= ng.
    >     = ;   >
    >     = ;   >    2. The MG is at fault for being schi= zophrenic.  It must
    >     = ;  prevent reuse
    >     = ;   >       of all resources a= ssociated with the context until it
    >     = ;  receives
    >     = ;   >       Subtract.
    >     = ;   >
    >     = ;   >    3. The MG can sidestep the problem.&= nbsp; It is only required to
    >     = ;  keep the
    >     = ;   >       termination in the= context, but it can clear the local
    >     = ;   >       descriptor.  = (And what if the MGC doesn't audit but
    >     = ;  relies on its
    >     = ;   >       memory?)
    >     = ;   >
    >     = ;   >    4. There is no problem.  The MG= C cannot do anything bad with
    >     = ;  the
    >     = ;   >       information.
    >
    >     = ;  [CHG] I would suggest that if the MG has experienced a problem
    >     = ;  with the
    >     = ;  termination that it send a generic cause event indicating failure= =2E
    >     = ;  It the MGC
    >     = ;  doesn't request this event then the designers must understand the=
    >     = ;  consequences.
    >     = ;  Also if there is a more terminal failure a servicechange could be=
    >     = ;  sent.
    >
    >     = ;   >
    >     = ;   > Raphael Tryster
    >     = ;   >

------_=_NextPart_001_01C44C53.B82B52A0-- --===============0390288165== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============0390288165==-- From megaco-bounces@ietf.org Tue Jun 8 10:18:08 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29175 for ; Tue, 8 Jun 2004 10:18:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXhMh-0000JJ-VI; Tue, 08 Jun 2004 10:14:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXeLI-0006Jw-FW for megaco@megatron.ietf.org; Tue, 08 Jun 2004 07:00: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 HAA18046 for ; Tue, 8 Jun 2004 07:00:29 -0400 (EDT) From: Eli.Liluz@veraznetworks.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXeLF-0004Hw-TJ for megaco@ietf.org; Tue, 08 Jun 2004 07:00:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXeKG-0003al-00 for megaco@ietf.org; Tue, 08 Jun 2004 06:59:28 -0400 Received: from ilsmtp01.ecitele.com ([147.234.1.11]) by ietf-mx with esmtp (Exim 4.12) id 1BXeJd-0002tB-00 for Megaco@ietf.org; Tue, 08 Jun 2004 06:58:49 -0400 To: Megaco@ietf.org X-Mailer: Lotus Notes Release 5.0.2b (Intl) 16 December 1999 Message-ID: Date: Tue, 8 Jun 2004 13:58:46 +0300 X-MIMETrack: Serialize by Router on ILSMTP01/ECI Telecom(Release 6.5|September 18, 2003) at 06/08/2004 14:01:42 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 X-Mailman-Approved-At: Tue, 08 Jun 2004 10:13:23 -0400 Cc: Ilana.Leibovitch@veraznetworks.com, Izabella.Itskovitch@veraznetworks.com Subject: [Megaco] Announcement in H.248.7. X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org Hi all. My question is about announcement mechanism in H.248. Regarding H.248.7 which is the Generic Announcement Package, the AN parameter that represent the announcement name is an enumeration. In MGCP protocol, the ANN package includes a string that represents the file name. Can anybody explain the logic of working with enumeration instead of string in H.248.7? Thank you, Eli Liluz. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Tue Jun 8 11:04:33 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01312 for ; Tue, 8 Jun 2004 11:04:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXi4X-00036H-28; Tue, 08 Jun 2004 10:59:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXhut-0001Dc-Ic for megaco@megatron.ietf.org; Tue, 08 Jun 2004 10:49:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00708 for ; Tue, 8 Jun 2004 10:49:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXhus-0001Ff-Nb for megaco@ietf.org; Tue, 08 Jun 2004 10:49:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXhtt-0000UN-00 for megaco@ietf.org; Tue, 08 Jun 2004 10:48:30 -0400 Received: from smtp6.wanadoo.fr ([193.252.22.25] helo=mwinf0601.wanadoo.fr) by ietf-mx with esmtp (Exim 4.12) id 1BXhsm-0006lk-00 for Megaco@ietf.org; Tue, 08 Jun 2004 10:47:20 -0400 Received: from francois (ASte-Genev-Bois-151-1-21-45.w83-114.abo.wanadoo.fr [83.114.19.45]) by mwinf0601.wanadoo.fr (SMTP Server) with SMTP id 183833400297; Tue, 8 Jun 2004 16:46:41 +0200 (CEST) Message-ID: <009701c44d67$7954fe40$1501a8c0@francois> From: "Francois Plagnard" To: "Christian Groves" References: <006e01c4497d$274e5080$1501a8c0@francois> <40C3B646.1090104@ericsson.com> Subject: Re: [Megaco] Ambiguity in ABNF of indAudauditReturnParameter in H.248 v2 Date: Tue, 8 Jun 2004 16:47:07 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cc: Megaco@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org Content-Transfer-Encoding: 7bit Christian, I agree with you, but I still don't understand the meaning of the comment ; at-most-once per item ; and either streamParm or streamDescriptor but not both if you can have only one instance. For me, it looks like a too quick "copy and paste" from mediaDescriptor and it is confusing. Best regards, Francois. ----- Original Message ----- From: "Christian Groves" To: "Francois Plagnard" Cc: Sent: Monday, June 07, 2004 2:26 AM Subject: Re: [Megaco] Ambiguity in ABNF of indAudauditReturnParameter in H.248 v2 > Hello Francois, > > I'm having some problem understanding what the ambiguity is. Please see my > comments below. > > Regards, Christian > > Francois Plagnard wrote: > > > Hello, > > > > In H.248v2, in indAudauditReturnParameter ABNF, according to my > > understanding, there are several ambiguities. > > > > For example, > > indAudmediaDescriptor = MediaToken LBRKT indAudmediaParm RBRKT > > means for me that you have only 1 instance of indAudmediaParm. > > [CHG] Yes I agree. > > > > > But, its definition is : > > ; at-most-once per item > > ; and either streamParm or streamDescriptor but not both > > indAudmediaParm = (indAudstreamParm / indAudstreamDescriptor / > > indAudterminationStateDescriptor) > > which implies that you may have several instances ! > > [CHG] Doesn't this imply that you "choose" one instance from the alternatives? > > > > > You have the same ambiguity with : > > - indAudlocalParm > > - indAudterminationStateParm > > ... > > > > May we have 1 or several instances of them ? > > And, if we may have several instances, how are they separated ? > > > > Best regards, > > > > =================================================================== > > Francois Plagnard, > > Netbricks > > 31 rue Jean Rostand > > 91893 ORSAY -- FRANCE > > Email: francois.plagnard@netbricks.com - WEB : www.netbricks.com > > Tel: +33 (0)1 69 33 12 57 -- Fax: +33 (0)1 69 85 54 26 > > =================================================================== > > > > > > _______________________________________________ > > 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-bounces@ietf.org Tue Jun 8 16:17:50 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21408 for ; Tue, 8 Jun 2004 16:17:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXmwK-0005TW-Vt; Tue, 08 Jun 2004 16:11:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXlaZ-00049K-5V for megaco@megatron.ietf.org; Tue, 08 Jun 2004 14:44:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15549 for ; Tue, 8 Jun 2004 14:44:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXlaX-0005yT-Sg for megaco@ietf.org; Tue, 08 Jun 2004 14:44:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXlZc-0005AJ-00 for megaco@ietf.org; Tue, 08 Jun 2004 14:43:49 -0400 Received: from zcars04e.nortelnetworks.com ([47.129.242.56]) by ietf-mx with esmtp (Exim 4.12) id 1BXlYx-00047q-00 for megaco@ietf.org; Tue, 08 Jun 2004 14:43:07 -0400 Received: from zcard303.ca.nortel.com (zcard303.ca.nortel.com [47.129.242.59]) by zcars04e.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i58IgV302362 for ; Tue, 8 Jun 2004 14:42:31 -0400 (EDT) Received: from nortelnetworks.com (acart1ev.ca.nortel.com [47.129.129.137]) by zcard303.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JCP9LQ72; Tue, 8 Jun 2004 14:42:31 -0400 Message-ID: <40C60896.4000806@nortelnetworks.com> Date: Tue, 08 Jun 2004 14:42:30 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: megaco@ietf.org Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [Megaco] [Fwd: FW: MEGACO: Question about the 'addr' event in 'bcasaddr' (H.248.25)] X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Forwarded as requested. -------- Original Message -------- Subject: FW: MEGACO: Question about the 'addr' event in 'bcasaddr' (H.248.25) Date: Sun, 30 May 2004 09:07:36 -0400 From: Nurit Shenhar To: Taylor, Tom-PT [CAR:5N00:EXCH] , Boyle, Kevin [NCRTP:3Z40:EXCH] Hi I sent the below to the list, but it didn=92t seem to make it there. Can you help? Thanks, Nurit -----Original Message----- *From:* Nurit Shenhar *Sent:* Tuesday, May 25, 2004 11:37 AM *To:* 'Megaco_IETF (megaco@ietf.org) *Subject:* MEGACO: Question about the 'addr' event in 'bcasaddr' (H.248.2= 5) Hi While looking at the =91bcas=92 and =91bcasaddr=92 packages, I saw the fo= llowing description for the =91ds=92 parameter in the =91addr=92 event: ------ =93The string of collected digits that matched all or part of the sequence specified in the digit map=94. My question is: Which digit map is referred here? The requested events descriptor does not have parameter. So how should I define which digit map to use? Thanks, */ /* */Nurit Shenhar/* */H.248/MEGACO Architect/* ** E-Mail: nurit.shenhar@audiocodes.com Fax. +972-3-9764223 www.audiocodes.com _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Wed Jun 9 00:34:19 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26477 for ; Wed, 9 Jun 2004 00:34:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXuf2-0007E4-0y; Wed, 09 Jun 2004 00:26:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXuZl-0007hq-4T for megaco@megatron.ietf.org; Wed, 09 Jun 2004 00:20:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25652 for ; Wed, 9 Jun 2004 00:20:15 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXuZT-000316-V1 for megaco@ietf.org; Wed, 09 Jun 2004 00:20:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXuYJ-0002An-00 for megaco@ietf.org; Wed, 09 Jun 2004 00:19:04 -0400 Received: from ind-iport-1-sec.cisco.com ([64.104.129.9] helo=ind-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BXuX6-0000WH-00 for megaco@ietf.org; Wed, 09 Jun 2004 00:17:48 -0400 Received: from india-core-1.cisco.com (64.104.129.221) by ind-iport-1.cisco.com with ESMTP; 09 Jun 2004 15:23:05 +0530 X-BrightmailFiltered: true Received: from cisco.com (samrat.cisco.com [192.135.241.21]) by india-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i594H9JB014971; Tue, 8 Jun 2004 21:17:10 -0700 (PDT) Received: from cisco.com ([10.77.55.110]) by cisco.com (8.11.2/8.8.8) with ESMTP id i594Fuq21053; Wed, 9 Jun 2004 09:45:57 +0530 (IST) Message-ID: <40C68F49.2070302@cisco.com> Date: Wed, 09 Jun 2004 09:47:13 +0530 From: Anil Jangam User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francois Plagnard Subject: Re: [Megaco] Ambiguity in ABNF of indAudauditReturnParameter in H.248 v2 References: <006e01c4497d$274e5080$1501a8c0@francois> <40C3B646.1090104@ericsson.com> <009701c44d67$7954fe40$1501a8c0@francois> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cc: Christian Groves , Megaco@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi Francois, Pls. see marked inline with [AJJ]. /anil. Francois Plagnard wrote: >Christian, > >I agree with you, but I still don't understand the meaning of the comment > ; at-most-once per item > ; and either streamParm or streamDescriptor but not both >if you can have only one instance. > >For me, it looks like a too quick "copy and paste" from mediaDescriptor and >it is confusing. > [AJJ] The "at-most-once per item" means that no item will be repeated, if you have the list of such similar items. indAudmediaDescriptor = MediaToken LBRKT indAudmediaParm RBRKT ; at-most-once per item ; and either streamParm or streamDescriptor but not both indAudmediaParm = (indAudstreamParm / indAudstreamDescriptor / indAudterminationStateDescriptor) In your case, as its a only parameter, it values could either be 'indAudstreamParm' or 'indAudstreamDescriptor' or 'indAudterminationStateDescriptor' ONLY. In addition to this according to the second condition, the 'indAudstreamDescriptor' and 'indAudterminationStateDescriptor' both CAN NOT be present at the same time. I guess your confusion is more because of the 'indAudmediaParm' is a SINGLE item. Just consider the case if you had 'indAudmediaDescriptor' as a LIST instead. You would appriciate the meaning of "at-most-once per item". (See below) > >Best regards, > >Francois. > >----- Original Message ----- >From: "Christian Groves" >To: "Francois Plagnard" >Cc: >Sent: Monday, June 07, 2004 2:26 AM >Subject: Re: [Megaco] Ambiguity in ABNF of indAudauditReturnParameter in >H.248 v2 > > > > >>Hello Francois, >> >>I'm having some problem understanding what the ambiguity is. Please see my >>comments below. >> >>Regards, Christian >> >>Francois Plagnard wrote: >> >> >> >>>Hello, >>> >>>In H.248v2, in indAudauditReturnParameter ABNF, according to my >>>understanding, there are several ambiguities. >>> >>>For example, >>> indAudmediaDescriptor = MediaToken LBRKT indAudmediaParm RBRKT >>>means for me that you have only 1 instance of indAudmediaParm. >>> >>> >>[CHG] Yes I agree. >> >> >> >>>But, its definition is : >>> ; at-most-once per item >>> ; and either streamParm or streamDescriptor but not both >>> indAudmediaParm = (indAudstreamParm / indAudstreamDescriptor / >>> indAudterminationStateDescriptor) >>>which implies that you may have several instances ! >>> >>> >>[CHG] Doesn't this imply that you "choose" one instance from the alternatives? >> >>>You have the same ambiguity with : >>>- indAudlocalParm >>>- indAudterminationStateParm >>>... >>> >>>May we have 1 or several instances of them ? >>> [AJJ] In above case there will be only one instance of "indAudmediaParm". >>>And, if we may have several instances, how are they separated ? >>> [AJJ] If you have several instances of a given item, its seperated by a COMMA. I can give you one example from RFC3525. serviceChangeReplyDescriptor = ServicesToken LBRKT servChgReplyParm *(COMMA servChgReplyParm) RBRKT Hope this resolves your all doubts. :-) Regards, /anil. >>> >>>Best regards, >>> >>>=================================================================== >>>Francois Plagnard, >>>Netbricks >>>31 rue Jean Rostand >>>91893 ORSAY -- FRANCE >>>Email: francois.plagnard@netbricks.com - WEB : www.netbricks.com >>>Tel: +33 (0)1 69 33 12 57 -- Fax: +33 (0)1 69 85 54 26 >>>=================================================================== >>> >>> >>>_______________________________________________ >>>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-bounces@ietf.org Wed Jun 9 00:55:40 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27315 for ; Wed, 9 Jun 2004 00:55:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXv2e-0006Ol-OK; Wed, 09 Jun 2004 00:50:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXuk4-0000ye-Ju for megaco@megatron.ietf.org; Wed, 09 Jun 2004 00:31:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26256 for ; Wed, 9 Jun 2004 00:31:09 -0400 (EDT) From: assingh@hss.hns.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXuk2-0004gm-G5 for megaco@ietf.org; Wed, 09 Jun 2004 00:31:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXuj1-0003qP-00 for megaco@ietf.org; Wed, 09 Jun 2004 00:30:08 -0400 Received: from spark.hss.co.in ([203.200.71.140]) by ietf-mx with esmtp (Exim 4.12) id 1BXui1-0002Az-00 for megaco@ietf.org; Wed, 09 Jun 2004 00:29:06 -0400 Received: from ultra.hss.co.in (ultra [192.168.100.5] (may be forged)) by spark.hss.co.in (8.12.10/8.12.10) with ESMTP id i594QmAM014620; Wed, 9 Jun 2004 09:56:48 +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 i594TBh08380; Wed, 9 Jun 2004 09:59:11 +0530 (IST) In-Reply-To: <40C60896.4000806@nortelnetworks.com> Subject: Re: [Megaco] [Fwd: FW: MEGACO: Question about the 'addr' event in 'bcasaddr' (H.248.25)] To: nurit.shenhar@audiocodes.com X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: Date: Wed, 9 Jun 2004 09:53:26 +0530 X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 09/06/2004 09:46:40 AM MIME-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=3.1 required=5.0 tests=AWL,NO_REAL_NAME, ROUND_THE_WORLD_LOCAL autolearn=no version=2.60 Cc: Tom Taylor , megaco@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0827550275==" Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org --===============0827550275== Content-type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 DQoNCg0KDQpIaSBOdXJpdCwNCg0KQWNjb3JkaW5nIHRvIHNlY3Rpb24gNy4xLjkgRXZlbnRzIGRl c2NyaXB0b3INCiAgICBJZiBhIGRpZ2l0IG1hcCBjb21wbGV0aW9uIGV2ZW50IGlzIHByZXNlbnQg b3IgaW1wbGllZCBpbiB0aGUNCiAgIEV2ZW50c0Rlc2NyaXB0b3IsIHRoZSBFdmVudERNIHBhcmFt ZXRlciBpcyB1c2VkIHRvIGNhcnJ5IGVpdGhlciB0aGUNCiAgIG5hbWUgb3IgdGhlIHZhbHVlIG9m IHRoZSBhc3NvY2lhdGVkIGRpZ2l0IG1hcC4gU2VlIDcuMS4xNCBmb3IgZnVydGhlcg0KICAgZGV0 YWlscy4NCg0KZS5nLiBFdmVudCBEZXNjIHNob3VsZCBsb29rIGxpa2UNCkV2ZW50cyA9IDEge2Jj YXNhZGRyL2FkZHJ7ZGlnaXRtYXAgPSB7MTExMX19fQ0KDQpUaGFua3MNCkFzaGlzaA0Kd3d3Lmhz c3dvcmxkLmNvbQ0KDQoNCg0KDQoNCg0KVG9tIFRheWxvciA8dGF5bG9yQG5vcnRlbG5ldHdvcmtz LmNvbT5AaWV0Zi5vcmcgb24gMDYvMDkvMjAwNCAxMjoxMjozMCBBTQ0KDQpTZW50IGJ5OiAgICBt ZWdhY28tYm91bmNlc0BpZXRmLm9yZw0KDQoNClRvOiAgICBtZWdhY29AaWV0Zi5vcmcNCmNjOg0K DQpTdWJqZWN0OiAgICBbTWVnYWNvXSBbRndkOiBGVzogTUVHQUNPOiBRdWVzdGlvbiBhYm91dCB0 aGUgJ2FkZHInIGV2ZW50IGluDQogICAgICAgJ2JjYXNhZGRyJyAoSC4yNDguMjUpXQ0KDQoNCkZv cndhcmRlZCBhcyByZXF1ZXN0ZWQuDQoNCi0tLS0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0t LS0NClN1YmplY3Q6ICAgIEZXOiBNRUdBQ086IFF1ZXN0aW9uIGFib3V0IHRoZSAnYWRkcicgZXZl bnQgaW4gJ2JjYXNhZGRyJw0KKEguMjQ4LjI1KQ0KRGF0ZTogICAgICAgU3VuLCAzMCBNYXkgMjAw NCAwOTowNzozNiAtMDQwMA0KRnJvbTogICAgICAgTnVyaXQgU2hlbmhhciA8TnVyaXRTQGF1ZGlv Y29kZXMuY29tPg0KVG86ICAgVGF5bG9yLCBUb20tUFQgW0NBUjo1TjAwOkVYQ0hdIDx0YXlsb3JA YW1lcmljYXNtMDEubnQuY29tPiwgQm95bGUsDQpLZXZpbiBbTkNSVFA6M1o0MDpFWENIXSA8a2Jv eWxlQGFtZXJpY2FzbTAxLm50LmNvbT4NCg0KDQoNCkhpDQoNCg0KDQpJIHNlbnQgdGhlIGJlbG93 IHRvIHRoZSBsaXN0LCBidXQgaXQgZGlkbuKAmXQgc2VlbSB0byBtYWtlIGl0IHRoZXJlLiBDYW4N CnlvdSBoZWxwPw0KDQoNCg0KVGhhbmtzLA0KDQoNCg0KTnVyaXQNCg0KDQoNCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQoqRnJvbToqIE51cml0IFNoZW5oYXINCipTZW50OiogVHVlc2RheSwg TWF5IDI1LCAyMDA0IDExOjM3IEFNDQoqVG86KiAnTWVnYWNvX0lFVEYgKG1lZ2Fjb0BpZXRmLm9y ZykNCipTdWJqZWN0OiogTUVHQUNPOiBRdWVzdGlvbiBhYm91dCB0aGUgJ2FkZHInIGV2ZW50IGlu ICdiY2FzYWRkcicgKEguMjQ4LjI1KQ0KDQoNCg0KSGkNCg0KDQoNCldoaWxlIGxvb2tpbmcgYXQg dGhlIOKAmGJjYXPigJkgYW5kIOKAmGJjYXNhZGRy4oCZIHBhY2thZ2VzLCBJIHNhdyB0aGUgZm9s bG93aW5nDQpkZXNjcmlwdGlvbiBmb3IgdGhlIOKAmGRz4oCZIHBhcmFtZXRlciBpbiB0aGUg4oCY YWRkcuKAmSBldmVudDoNCg0KDQoNCi0tLS0tLSDigJxUaGUgc3RyaW5nIG9mIGNvbGxlY3RlZCBk aWdpdHMgdGhhdCBtYXRjaGVkIGFsbCBvciBwYXJ0IG9mIHRoZQ0Kc2VxdWVuY2Ugc3BlY2lmaWVk IGluIHRoZSBkaWdpdCBtYXDigJ0uDQoNCg0KDQpNeSBxdWVzdGlvbiBpczogV2hpY2ggZGlnaXQg bWFwIGlzIHJlZmVycmVkIGhlcmU/IFRoZSByZXF1ZXN0ZWQgZXZlbnRzDQpkZXNjcmlwdG9yIGRv ZXMgbm90IGhhdmUgcGFyYW1ldGVyLiBTbyBob3cgc2hvdWxkIEkgZGVmaW5lIHdoaWNoIGRpZ2l0 DQptYXAgdG8gdXNlPw0KDQoNCg0KVGhhbmtzLA0KDQoNCg0KDQoNCiovIC8qDQoNCiovTnVyaXQg U2hlbmhhci8qDQoNCiovSC4yNDgvTUVHQUNPIEFyY2hpdGVjdC8qDQoNCg0KDQoqKg0KDQpFLU1h aWw6IG51cml0LnNoZW5oYXJAYXVkaW9jb2Rlcy5jb20NCg0KRmF4LiAgICArOTcyLTMtOTc2NDIy Mw0KDQp3d3cuYXVkaW9jb2Rlcy5jb20gPGh0dHA6Ly93d3cuYXVkaW9jb2Rlcy5jb20vPg0KDQoN Cg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpN ZWdhY28gbWFpbGluZyBsaXN0DQpNZWdhY29AaWV0Zi5vcmcNCiBodHRwczovL3d3dzEuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9tZWdhY28NCg== --===============0827550275== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============0827550275==-- From megaco-bounces@ietf.org Wed Jun 9 01:01:30 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27806 for ; Wed, 9 Jun 2004 01:01:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXv55-0008A9-Qk; Wed, 09 Jun 2004 00:52:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXurK-0003FJ-ID for megaco@megatron.ietf.org; Wed, 09 Jun 2004 00:38: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 AAA26543 for ; Wed, 9 Jun 2004 00:38:39 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXurI-00027P-E9 for megaco@ietf.org; Wed, 09 Jun 2004 00:38:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXuol-00019A-00 for megaco@ietf.org; Wed, 09 Jun 2004 00:36:03 -0400 Received: from ind-iport-1-sec.cisco.com ([64.104.129.9] helo=ind-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BXunj-0007H0-00 for megaco@ietf.org; Wed, 09 Jun 2004 00:35:00 -0400 Received: from india-core-1.cisco.com (64.104.129.221) by ind-iport-1.cisco.com with ESMTP; 09 Jun 2004 15:40:17 +0530 X-BrightmailFiltered: true Received: from cisco.com (samrat.cisco.com [192.135.241.21]) by india-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i594YKJB016652; Tue, 8 Jun 2004 21:34:21 -0700 (PDT) Received: from cisco.com ([10.77.55.110]) by cisco.com (8.11.2/8.8.8) with ESMTP id i594X8q25476; Wed, 9 Jun 2004 10:03:08 +0530 (IST) Message-ID: <40C69350.6010108@cisco.com> Date: Wed, 09 Jun 2004 10:04:24 +0530 From: Anil Jangam User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eli.Liluz@veraznetworks.com Subject: Re: [Megaco] Announcement in H.248.7. References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cc: Megaco@ietf.org, Ilana.Leibovitch@veraznetworks.com, Izabella.Itskovitch@veraznetworks.com X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org Content-Transfer-Encoding: 7bit Pls see inline. Eli.Liluz@veraznetworks.com wrote: > > >Hi all. > >My question is about announcement mechanism in H.248. > >Regarding H.248.7 which is the Generic Announcement Package, >the AN parameter that represent the announcement name is >an enumeration. In MGCP protocol, the ANN package includes a >string that represents the file name. > >Can anybody explain the logic of working with enumeration instead >of string in H.248.7? > I see it more as a simplified approach. If you refer to 12.3@RFC3525, its says: 12.3 Lists Possible values for parameters include enumerations. Enumerations may be defined in a list. It is recommended that the list be IANA registered so that packages that extend the list can be defined without concern for conflicting names. In MGCP announcement name (the string), its an URL which requires further parsing to confirm it to the rfc1738 and rfc2326. This certainly adds to the processing time and power. Regards, /anil. > >Thank you, >Eli Liluz. > > >_______________________________________________ >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-bounces@ietf.org Wed Jun 9 20:36:30 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06239 for ; Wed, 9 Jun 2004 20:36:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYDRz-00011w-HF; Wed, 09 Jun 2004 20:29:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYDKn-0006UP-6K for megaco@megatron.ietf.org; Wed, 09 Jun 2004 20:22:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05464 for ; Wed, 9 Jun 2004 20:22:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYDKl-0004oJ-Fa for megaco@ietf.org; Wed, 09 Jun 2004 20:22:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYDJS-0003pt-00 for megaco@ietf.org; Wed, 09 Jun 2004 20:20:59 -0400 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1BYDHc-0001ch-00 for megaco@ietf.org; Wed, 09 Jun 2004 20:19:04 -0400 Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i5A0J4Ah006263 for ; Thu, 10 Jun 2004 02:19:04 +0200 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 10 Jun 2004 02:19:04 +0200 Received: from eaubrnt019.epa.ericsson.se ([146.11.9.165]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id MATLDHS9; Thu, 10 Jun 2004 02:19:04 +0200 Received: from ericsson.com (EG2E500202DSEGL [146.11.22.27]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id LGSR99D8; Thu, 10 Jun 2004 10:18:57 +1000 Message-ID: <40C7A909.2040604@ericsson.com> Date: Thu, 10 Jun 2004 10:19:21 +1000 X-Sybari-Trust: 599d6377 2335e436 6d4e7020 00000139 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Raphael Tryster Subject: Re: [Megaco] Descriptor processing on Termination OOS References: <9A64A99CD3F2BD4582BE4FB63FC1F3816D0F93@MAILSERVER> In-Reply-To: <9A64A99CD3F2BD4582BE4FB63FC1F3816D0F93@MAILSERVER> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Jun 2004 00:19:04.0675 (UTC) FILETIME=[89BB4B30:01C44E80] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cc: Tom-PT Taylor , anilj@cisco.com, megaco@ietf.org, bvswamy@hss.hns.com, "'Kevin Boyle'" X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org Content-Transfer-Encoding: 7bit If you want VMWI to persist why don't you MOV a termination to its own context? Christian Raphael Tryster wrote: > So there would be a discontinuity in the signal. Is that what real MGCs > do? > > Raphael Tryster > > > -----Original Message----- > From: Christian Groves [SMTP:christian.groves@ericsson.com] > Sent: Monday, 7 June 2004 2:10 > To: Raphael Tryster > Cc: 'Kevin Boyle'; bvswamy@hss.hns.com; anilj@cisco.com; > Tom-PT Taylor; megaco@ietf.org > Subject: Re: [Megaco] Descriptor processing on Termination OOS > > Hello Raphael, > > A signal's descriptor cannot be sent in a subtract command. It > would have to be > modified in the NULL context. > > Regards, Christian > > Raphael Tryster wrote: > > > Hello Christian, > > > > I gather from your reply that in my first question, 6.2.4 > overrides > > 7.1.11, and in my second question, it is the MGC's > responsibility to > > avoid inconsistencies. Does the former mean that even off/on > signals > > terminate on subtraction from a context? Therefore, if the MGC > wants > > something like VMWI to persist, it has to re-issue it on every > subtract? > > > > Raphael Tryster > > > > > > -----Original Message----- > > From: Christian Groves > [SMTP:christian.groves@ericsson.com] > > Sent: Friday, 28 May 2004 7:09 > > To: Raphael Tryster > > Cc: 'Kevin Boyle'; bvswamy@hss.hns.com; anilj@cisco.com; > > Tom-PT Taylor; megaco@ietf.org > > Subject: Re: [Megaco] Descriptor processing on > Termination OOS > > > > Hello Raphael, > > > > Please see my comments below. > > > > Regards, Christian > > > > Raphael Tryster wrote: > > > > > Two questions related to the discussion below: > > > > > > Firstly, the quote below from H.248.1 6.2.4 seems to > contradict > > section > > > 7.1.11, which states: > > > > > > "Production of a Signal on a Termination is stopped by > > application of a > > > new SignalsDescriptor, or detection of an Event on the > > Termination". > > > > > > What about returning to the null context? According > to 6.2.4, the > > > signal should stop, whereas according to 7.1.11, it > should not > > stop. > > > Unless the resetting of descriptors to default values > when > > returning to > > > the null context is considered to be a case of > application of a > > new > > > SignalsDescriptor? But then what do we do about > on/off type > > signals, > > > e.g. visual message waiting indicator? Surely they > are meant > > to survive > > > subtraction from a context? > > > > [CHG] I would assume that by returning a termination to > the NULL > > context via a > > subtract results in a signal being stopped. 6.2.4 says, > "If not > > provisioned > > otherwise, the properties in all descriptors except > > TerminationState and > > LocalControl default to empty/"no value" when a > Termination is > > first created or > > returned to the null Context. The default contents of the > two > > exceptions are > > described in 7.1.5 and 7.1.7." 7.1.11 talks about > replacement > > SignalDescriptor > > which is effectively what happens when you return to the > NULL > > context. The > > current descriptors are replaced by the provisioned > descriptors. > > Also 7.1.11 is > > not mentioned as an exception. > > > > > > > > My second question concerns the requirement that the > MG maintain > > > terminations in contexts until the MGC explicitly > subtracts them. > > > Consider a distributed MG, in which the part that > talks to the > > MGC does > > > not completely control the part that allocates > resources such > > as IP > > > address and UDP port for local descriptors. Suppose some > > administrative > > > action or fault causes these resources to become > physically > > unavailable > > > to the termination with which they were associated. > The MG > > informs the > > > MGC (or fails to do so if the MGC didn't request the > event), > > but for > > > some reason the MGC does not issue a Subtract. The > front end > > of the MG > > > has no problem complying with Megaco rules: it will > accept any > > commands > > > it can on that context, and send a proper rejection if > the > > cleanup that > > > has taken place in the back end makes it impossible to > comply > > with a > > > request. However, if the MGC audits the local > descriptor, the > > MG front > > > end will send an IP address and UDP port that the back > end may > > already > > > be reusing for another call. The MGC can then > presumably do > > bad things > > > with this outdated information. Which of the > following are > > legitimate > > > solutions to this problem? > > > > > > 1. The MGC is at fault for ignoring indications > from the MG > > that > > > something went wrong. > > > > > > 2. The MG is at fault for being schizophrenic. It > must > > prevent reuse > > > of all resources associated with the context > until it > > receives > > > Subtract. > > > > > > 3. The MG can sidestep the problem. It is only > required to > > keep the > > > termination in the context, but it can clear the > local > > > descriptor. (And what if the MGC doesn't audit but > > relies on its > > > memory?) > > > > > > 4. There is no problem. The MGC cannot do anything > bad with > > the > > > information. > > > > [CHG] I would suggest that if the MG has experienced a > problem > > with the > > termination that it send a generic cause event indicating > failure. > > It the MGC > > doesn't request this event then the designers must > understand the > > consequences. > > Also if there is a more terminal failure a servicechange > could be > > sent. > > > > > > > > Raphael Tryster > > > > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Thu Jun 10 01:19:01 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20847 for ; Thu, 10 Jun 2004 01:19:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYHql-000806-4U; Thu, 10 Jun 2004 01:11:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYHoO-000721-Ce for megaco@megatron.ietf.org; Thu, 10 Jun 2004 01:09:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20384 for ; Thu, 10 Jun 2004 01:09:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYHoM-0007RV-0b for megaco@ietf.org; Thu, 10 Jun 2004 01:09:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYHnf-0006ZW-00 for megaco@ietf.org; Thu, 10 Jun 2004 01:08:30 -0400 Received: from mail.tdsoft.com ([212.143.64.34] helo=TdSoft.eSafe.com) by ietf-mx with smtp (Exim 4.12) id 1BYHmj-0005gP-00 for megaco@ietf.org; Thu, 10 Jun 2004 01:07:29 -0400 Received: from mailserver.td-soft.co.il ([IP=172.16.1.203]) by eSafe SMTP Relay 1086793587; Thu Jun 10 08:06:43 2004 Received: by MAILSERVER with Internet Mail Service (5.5.2657.72) id ; Thu, 10 Jun 2004 08:04:10 +0200 Message-ID: <9A64A99CD3F2BD4582BE4FB63FC1F3816D0FBF@MAILSERVER> From: Raphael Tryster To: "'Christian Groves'" Subject: RE: [Megaco] Descriptor processing on Termination OOS Date: Thu, 10 Jun 2004 08:03:33 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-eSafe-inspection-result: Mail clean X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_50_60,HTML_MESSAGE autolearn=no version=2.60 Cc: Tom-PT Taylor , anilj@cisco.com, megaco@ietf.org, bvswamy@hss.hns.com, "'Kevin Boyle'" X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1514619983==" Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org 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. --===============1514619983== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C44EB0.A918C540" 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_01C44EB0.A918C540 Content-Type: text/plain; charset="iso-8859-1" Because this termination may wish to be part of many other contexts while the signal persists, i.e. I can make many calls while the light on my phone is on, before checking my voice mail. Raphael Tryster -----Original Message----- From: Christian Groves [SMTP:christian.groves@ericsson.com] Sent: Thursday, 10 June 2004 2:19 To: Raphael Tryster Cc: 'Kevin Boyle'; bvswamy@hss.hns.com; anilj@cisco.com; Tom-PT Taylor; megaco@ietf.org Subject: Re: [Megaco] Descriptor processing on Termination OOS If you want VMWI to persist why don't you MOV a termination to its own context? Christian Raphael Tryster wrote: > So there would be a discontinuity in the signal. Is that what real MGCs > do? > > Raphael Tryster > > > -----Original Message----- > From: Christian Groves [SMTP:christian.groves@ericsson.com] > Sent: Monday, 7 June 2004 2:10 > To: Raphael Tryster > Cc: 'Kevin Boyle'; bvswamy@hss.hns.com; anilj@cisco.com; > Tom-PT Taylor; megaco@ietf.org > Subject: Re: [Megaco] Descriptor processing on Termination OOS > > Hello Raphael, > > A signal's descriptor cannot be sent in a subtract command. It > would have to be > modified in the NULL context. > > Regards, Christian > > Raphael Tryster wrote: > > > Hello Christian, > > > > I gather from your reply that in my first question, 6.2.4 > overrides > > 7.1.11, and in my second question, it is the MGC's > responsibility to > > avoid inconsistencies. Does the former mean that even off/on > signals > > terminate on subtraction from a context? Therefore, if the MGC > wants > > something like VMWI to persist, it has to re-issue it on every > subtract? > > > > Raphael Tryster > > > > > > -----Original Message----- > > From: Christian Groves > [SMTP:christian.groves@ericsson.com] > > Sent: Friday, 28 May 2004 7:09 > > To: Raphael Tryster > > Cc: 'Kevin Boyle'; bvswamy@hss.hns.com; anilj@cisco.com; > > Tom-PT Taylor; megaco@ietf.org > > Subject: Re: [Megaco] Descriptor processing on > Termination OOS > > > > Hello Raphael, > > > > Please see my comments below. > > > > Regards, Christian > > > > Raphael Tryster wrote: > > > > > Two questions related to the discussion below: > > > > > > Firstly, the quote below from H.248.1 6.2.4 seems to > contradict > > section > > > 7.1.11, which states: > > > > > > "Production of a Signal on a Termination is stopped by > > application of a > > > new SignalsDescriptor, or detection of an Event on the > > Termination". > > > > > > What about returning to the null context? According > to 6.2.4, the > > > signal should stop, whereas according to 7.1.11, it > should not > > stop. > > > Unless the resetting of descriptors to default values > when > > returning to > > > the null context is considered to be a case of > application of a > > new > > > SignalsDescriptor? But then what do we do about > on/off type > > signals, > > > e.g. visual message waiting indicator? Surely they > are meant > > to survive > > > subtraction from a context? > > > > [CHG] I would assume that by returning a termination to > the NULL > > context via a > > subtract results in a signal being stopped. 6.2.4 says, > "If not > > provisioned > > otherwise, the properties in all descriptors except > > TerminationState and > > LocalControl default to empty/"no value" when a > Termination is > > first created or > > returned to the null Context. The default contents of the > two > > exceptions are > > described in 7.1.5 and 7.1.7." 7.1.11 talks about > replacement > > SignalDescriptor > > which is effectively what happens when you return to the > NULL > > context. The > > current descriptors are replaced by the provisioned > descriptors. > > Also 7.1.11 is > > not mentioned as an exception. > > > > > > > > My second question concerns the requirement that the > MG maintain > > > terminations in contexts until the MGC explicitly > subtracts them. > > > Consider a distributed MG, in which the part that > talks to the > > MGC does > > > not completely control the part that allocates > resources such > > as IP > > > address and UDP port for local descriptors. Suppose some > > administrative > > > action or fault causes these resources to become > physically > > unavailable > > > to the termination with which they were associated. > The MG > > informs the > > > MGC (or fails to do so if the MGC didn't request the > event), > > but for > > > some reason the MGC does not issue a Subtract. The > front end > > of the MG > > > has no problem complying with Megaco rules: it will > accept any > > commands > > > it can on that context, and send a proper rejection if > the > > cleanup that > > > has taken place in the back end makes it impossible to > comply > > with a > > > request. However, if the MGC audits the local > descriptor, the > > MG front > > > end will send an IP address and UDP port that the back > end may > > already > > > be reusing for another call. The MGC can then > presumably do > > bad things > > > with this outdated information. Which of the > following are > > legitimate > > > solutions to this problem? > > > > > > 1. The MGC is at fault for ignoring indications > from the MG > > that > > > something went wrong. > > > > > > 2. The MG is at fault for being schizophrenic. It > must > > prevent reuse > > > of all resources associated with the context > until it > > receives > > > Subtract. > > > > > > 3. The MG can sidestep the problem. It is only > required to > > keep the > > > termination in the context, but it can clear the > local > > > descriptor. (And what if the MGC doesn't audit but > > relies on its > > > memory?) > > > > > > 4. There is no problem. The MGC cannot do anything > bad with > > the > > > information. > > > > [CHG] I would suggest that if the MG has experienced a > problem > > with the > > termination that it send a generic cause event indicating > failure. > > It the MGC > > doesn't request this event then the designers must > understand the > > consequences. > > Also if there is a more terminal failure a servicechange > could be > > sent. > > > > > > > > Raphael Tryster > > > > ------_=_NextPart_001_01C44EB0.A918C540 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Megaco] Descriptor processing on Termination OOS

Because this termination may wish to be = part of many other contexts while the signal persists, i.e. I can make ma= ny calls while the light on my phone is on, before checking my voice mail= =2E

Raphael Tryster


    -----Original Mess= age-----
    From:   Christian Groves [= SMTP:christian.groves@ericsson.com]
    Sent:   Thursday, 10 June 2004 2:19
    To:     Raphael Tryster
    Cc:     'Kevin Boyle'; bvswamy@hss.hns.com; anil= j@cisco.com; Tom-PT Taylor; megaco@ietf.org
    Subject:    &nbs= p;   Re: [Megaco] Desc= riptor processing on Termination OOS

    If you want VMWI to persist why do= n't you MOV a termination to its own context?

    Christian

    Raphael Tryster wrote:

    > So there would be a discontin= uity in the signal.  Is that what real MGCs
    > do?
    >
    > Raphael Tryster
    >
    >
    >     = ;  -----Original Message-----
    >     = ;  From:   Christian Groves [SMTP:christian.groves@ericsso= n.com]
    >     = ;  Sent:   Monday, 7 June 2004 2:10
    >     = ;  To:     Raphael Tryster
    >     = ;  Cc:     'Kevin Boyle'; bvswamy@hss.hns.com; a= nilj@cisco.com;
    >     = ;  Tom-PT Taylor; megaco@ietf.org
    >     = ;  Subject:        Re: [Megaco] D= escriptor processing on Termination OOS
    >
    >     = ;  Hello Raphael,
    >
    >     = ;  A signal's descriptor cannot be sent in a subtract command. It
    >     = ;  would have to be
    >     = ;  modified in the NULL context.
    >
    >     = ;  Regards, Christian
    >
    >     = ;  Raphael Tryster wrote:
    >
    >     = ;   > Hello Christian,
    >     = ;   >
    >     = ;   > I gather from your reply that in my first question, 6.= 2.4
    >     = ;  overrides
    >     = ;   > 7.1.11, and in my second question, it is the MGC's
    >     = ;  responsibility to
    >     = ;   > avoid inconsistencies.  Does the former mean that= even off/on
    >     = ;  signals
    >     = ;   > terminate on subtraction from a context?  Therefo= re, if the MGC
    >     = ;  wants
    >     = ;   > something like VMWI to persist, it has to re-issue it = on every
    >     = ;  subtract?
    >     = ;   >
    >     = ;   > Raphael Tryster
    >     = ;   >
    >     = ;   >
    >     = ;   >       -----Original Mess= age-----
    >     = ;   >       From:   = Christian Groves
    >     = ;  [SMTP:christian.groves@ericsson.com]
    >     = ;   >       Sent:   = Friday, 28 May 2004 7:09
    >     = ;   >       To:  &nb= sp;  Raphael Tryster
    >     = ;   >       Cc:  &nb= sp;  'Kevin Boyle'; bvswamy@hss.hns.com; anilj@cisco.com;
    >     = ;   >       Tom-PT Taylor; meg= aco@ietf.org
    >     = ;   >       Subject: &nbs= p;      Re: [Megaco] Descriptor processing on
    >     = ;  Termination OOS
    >     = ;   >
    >     = ;   >       Hello Raphael,
    >     = ;   >
    >     = ;   >       Please see my comm= ents below.
    >     = ;   >
    >     = ;   >       Regards, Christian=
    >     = ;   >
    >     = ;   >       Raphael Tryster wr= ote:
    >     = ;   >
    >     = ;   >        > Two que= stions related to the discussion below:
    >     = ;   >        >
    >     = ;   >        > Firstly= , the quote below from H.248.1 6.2.4 seems to
    >     = ;  contradict
    >     = ;   >       section
    >     = ;   >        > 7.1.11,= which states:
    >     = ;   >        >
    >     = ;   >        > "P= roduction of a Signal on a Termination is stopped by
    >     = ;   >       application of a
    >     = ;   >        > new Sig= nalsDescriptor, or detection of an Event on the
    >     = ;   >       Termination".=
    >     = ;   >        >
    >     = ;   >        > What ab= out returning to the null context?  According
    >     = ;  to 6.2.4, the
    >     = ;   >        > signal = should stop, whereas according to 7.1.11, it
    >     = ;  should not
    >     = ;   >       stop.
    >     = ;   >        > Unless = the resetting of descriptors to default values
    >     = ;  when
    >     = ;   >       returning to
    >     = ;   >        > the nul= l context is considered to be a case of
    >     = ;  application of a
    >     = ;   >       new
    >     = ;   >        > Signals= Descriptor?  But then what do we do about
    >     = ;  on/off type
    >     = ;   >       signals,
    >     = ;   >        > e.g. vi= sual message waiting indicator?  Surely they
    >     = ;  are meant
    >     = ;   >       to survive
    >     = ;   >        > subtrac= tion from a context?
    >     = ;   >
    >     = ;   >       [CHG] I would assu= me that by returning a termination to
    >     = ;  the NULL
    >     = ;   >       context via a
    >     = ;   >       subtract results i= n a signal being stopped. 6.2.4 says,
    >     = ;  "If not
    >     = ;   >       provisioned
    >     = ;   >       otherwise, the pro= perties in all descriptors except
    >     = ;   >       TerminationState a= nd
    >     = ;   >       LocalControl defau= lt to empty/"no value" when a
    >     = ;  Termination is
    >     = ;   >       first created or
    >     = ;   >       returned to the nu= ll Context. The default contents of the
    >     = ;  two
    >     = ;   >       exceptions are
    >     = ;   >       described in 7.1.5= and 7.1.7." 7.1.11 talks about
    >     = ;  replacement
    >     = ;   >       SignalDescriptor
    >     = ;   >       which is effective= ly what happens when you return to the
    >     = ;  NULL
    >     = ;   >       context. The
    >     = ;   >       current descriptor= s are replaced by the provisioned
    >     = ;  descriptors.
    >     = ;   >       Also 7.1.11 is
    >     = ;   >       not mentioned as a= n exception.
    >     = ;   >
    >     = ;   >        >
    >     = ;   >        > My seco= nd question concerns the requirement that the
    >     = ;  MG maintain
    >     = ;   >        > termina= tions in contexts until the MGC explicitly
    >     = ;  subtracts them.
    >     = ;   >        > Conside= r a distributed MG, in which the part that
    >     = ;  talks to the
    >     = ;   >       MGC does
    >     = ;   >        > not com= pletely control the part that allocates
    >     = ;  resources such
    >     = ;   >       as IP
    >     = ;   >        > address= and UDP port for local descriptors.  Suppose some
    >     = ;   >       administrative
    >     = ;   >        > action = or fault causes these resources to become
    >     = ;  physically
    >     = ;   >       unavailable
    >     = ;   >        > to the = termination with which they were associated.
    >     = ;  The MG
    >     = ;   >       informs the
    >     = ;   >        > MGC (or= fails to do so if the MGC didn't request the
    >     = ;  event),
    >     = ;   >       but for
    >     = ;   >        > some re= ason the MGC does not issue a Subtract.  The
    >     = ;  front end
    >     = ;   >       of the MG
    >     = ;   >        > has no = problem complying with Megaco rules: it will
    >     = ;  accept any
    >     = ;   >       commands
    >     = ;   >        > it can = on that context, and send a proper rejection if
    >     = ;  the
    >     = ;   >       cleanup that
    >     = ;   >        > has tak= en place in the back end makes it impossible to
    >     = ;  comply
    >     = ;   >       with a
    >     = ;   >        > request= =2E  However, if the MGC audits the local
    >     = ;  descriptor, the
    >     = ;   >       MG front
    >     = ;   >        > end wil= l send an IP address and UDP port that the back
    >     = ;  end may
    >     = ;   >       already
    >     = ;   >        > be reus= ing for another call.  The MGC can then
    >     = ;  presumably do
    >     = ;   >       bad things
    >     = ;   >        > with th= is outdated information.  Which of the
    >     = ;  following are
    >     = ;   >       legitimate
    >     = ;   >        > solutio= ns to this problem?
    >     = ;   >        >
    >     = ;   >        > &n= bsp;  1. The MGC is at fault for ignoring indications
    >     = ;  from the MG
    >     = ;   >       that
    >     = ;   >        > &n= bsp;     something went wrong.
    >     = ;   >        >
    >     = ;   >        > &n= bsp;  2. The MG is at fault for being schizophrenic.  It
    >     = ;  must
    >     = ;   >       prevent reuse
    >     = ;   >        > &n= bsp;     of all resources associated with the context=
    >     = ;  until it
    >     = ;   >       receives
    >     = ;   >        > &n= bsp;     Subtract.
    >     = ;   >        >
    >     = ;   >        > &n= bsp;  3. The MG can sidestep the problem.  It is only
    >     = ;  required to
    >     = ;   >       keep the
    >     = ;   >        > &n= bsp;     termination in the context, but it can clear= the
    >     = ;  local
    >     = ;   >        > &n= bsp;     descriptor.  (And what if the MGC doesn= 't audit but
    >     = ;   >       relies on its
    >     = ;   >        > &n= bsp;     memory?)
    >     = ;   >        >
    >     = ;   >        > &n= bsp;  4. There is no problem.  The MGC cannot do anything
    >     = ;  bad with
    >     = ;   >       the
    >     = ;   >        > &n= bsp;     information.
    >     = ;   >
    >     = ;   >       [CHG] I would sugg= est that if the MG has experienced a
    >     = ;  problem
    >     = ;   >       with the
    >     = ;   >       termination that i= t send a generic cause event indicating
    >     = ;  failure.
    >     = ;   >       It the MGC
    >     = ;   >       doesn't request th= is event then the designers must
    >     = ;  understand the
    >     = ;   >       consequences.
    >     = ;   >       Also if there is a= more terminal failure a servicechange
    >     = ;  could be
    >     = ;   >       sent.
    >     = ;   >
    >     = ;   >        >
    >     = ;   >        > Raphael= Tryster
    >     = ;   >        >
    >

------_=_NextPart_001_01C44EB0.A918C540-- --===============1514619983== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============1514619983==-- From megaco-bounces@ietf.org Thu Jun 10 08:28:13 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28443 for ; Thu, 10 Jun 2004 08:28:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYOX0-0007fj-OR; Thu, 10 Jun 2004 08:19:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYOJO-0005g3-JZ for megaco@megatron.ietf.org; Thu, 10 Jun 2004 08:05: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 IAA27063 for ; Thu, 10 Jun 2004 08:05:36 -0400 (EDT) From: bvswamy@hss.hns.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYOJM-0003tc-Jg for megaco@ietf.org; Thu, 10 Jun 2004 08:05:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYOIW-0003Nx-00 for megaco@ietf.org; Thu, 10 Jun 2004 08:04:45 -0400 Received: from spark.hss.co.in ([203.200.71.140]) by ietf-mx with esmtp (Exim 4.12) id 1BYOGs-0002dQ-00 for megaco@ietf.org; Thu, 10 Jun 2004 08:03:03 -0400 Received: from ultra.hss.co.in (ultra [192.168.100.5] (may be forged)) by spark.hss.co.in (8.12.10/8.12.10) with ESMTP id i5AC0uAM010959 for ; Thu, 10 Jun 2004 17:30:56 +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 i5AC3Lp13655 for ; Thu, 10 Jun 2004 17:33:21 +0530 (IST) To: megaco@ietf.org X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: Date: Thu, 10 Jun 2004 17:28:00 +0530 X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 10/06/2004 05:20:48 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.9 required=5.0 tests=AWL,EXCUSE_16,NO_REAL_NAME, ROUND_THE_WORLD_LOCAL autolearn=no version=2.60 Subject: [Megaco] ServiceChange Address lifetime X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org Hi For the scenario mentioned below what is the lifetime of the ServiceChange Address: 1) Through Management interface MGC is configured for the transport address of the MediaGateway. 2) MG does a registration with MGC using the configured transport address. 3) At the MG end, local transport address is changed through the management interface 4) MG sends ServiceChange with ServiceChangeAddress to the MGC. 5) MGC modifies the remote entity information at its end. Now should this changed address be considered persistent from this point onwards or its validity is only for the time the association is active. What if MGC or MG goes down and comes up again, then what should be the MG address at the MGC end. Regards Venkat "DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Thu Jun 10 12:00:14 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15449 for ; Thu, 10 Jun 2004 12:00:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYRu7-0007vZ-KA; Thu, 10 Jun 2004 11:55:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYPhz-0003Ge-62 for megaco@megatron.ietf.org; Thu, 10 Jun 2004 09:35:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03756 for ; Thu, 10 Jun 2004 09:34:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYPhs-0005Yg-FN for megaco@ietf.org; Thu, 10 Jun 2004 09:35:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYPbl-0003s5-00 for megaco@ietf.org; Thu, 10 Jun 2004 09:28:43 -0400 Received: from www.pspl.co.in ([202.54.11.65] helo=smtp.pspl.co.in) by ietf-mx with esmtp (Exim 4.12) id 1BYPWM-0002A1-00 for megaco@ietf.org; Thu, 10 Jun 2004 09:23:07 -0400 Received: from grandin (austin.pspl.co.in [210.210.81.202]) (authenticated bits=0) by smtp.pspl.co.in (8.12.9/8.12.9) with ESMTP id i5ADMYxJ019484; Thu, 10 Jun 2004 18:52:36 +0530 From: "Umesh Sharma" To: , Subject: RE: [Megaco] ServiceChange Address lifetime Date: Thu, 10 Jun 2004 18:52:24 +0530 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,EXCUSE_16 autolearn=no version=2.60 Content-Transfer-Encoding: 7bit X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi Venkat >From protocol language it looks the changed address is not persistent: >> ServiceChangeAddress provides an address to be used within the >> context of the association currently being negotiated regards Umesh -----Original Message----- From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org]On Behalf Of bvswamy@hss.hns.com Sent: Thursday, June 10, 2004 5:28 PM To: megaco@ietf.org Subject: [Megaco] ServiceChange Address lifetime Hi For the scenario mentioned below what is the lifetime of the ServiceChange Address: 1) Through Management interface MGC is configured for the transport address of the MediaGateway. 2) MG does a registration with MGC using the configured transport address. 3) At the MG end, local transport address is changed through the management interface 4) MG sends ServiceChange with ServiceChangeAddress to the MGC. 5) MGC modifies the remote entity information at its end. Now should this changed address be considered persistent from this point onwards or its validity is only for the time the association is active. What if MGC or MG goes down and comes up again, then what should be the MG address at the MGC end. Regards Venkat "DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Fri Jun 11 07:50:37 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15279 for ; Fri, 11 Jun 2004 07:50:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYkS0-0000US-ID; Fri, 11 Jun 2004 07:44:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BY5SZ-0000cK-Ci for megaco@megatron.ietf.org; Wed, 09 Jun 2004 11:57: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 DAA00547 for ; Wed, 9 Jun 2004 03:22:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXxPp-0002qf-9P for megaco@ietf.org; Wed, 09 Jun 2004 03:22:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXxOk-0001yL-00 for megaco@ietf.org; Wed, 09 Jun 2004 03:21:23 -0400 Received: from mta2.huawei.com ([61.144.161.24] helo=huawei.com) by ietf-mx with esmtp (Exim 4.12) id 1BXxMw-0007iQ-00 for megaco@ietf.org; Wed, 09 Jun 2004 03:19:30 -0400 Received: from huawei.com (huawei.com [172.17.1.61]) by mta2.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0HZ1005D05OHGQ@mta2.huawei.com> for megaco@ietf.org; Wed, 09 Jun 2004 15:19:30 +0800 (CST) Received: from huawei.com ([172.17.1.58]) by mta2.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0HZ1002W95OHEQ@mta2.huawei.com> for megaco@ietf.org; Wed, 09 Jun 2004 15:19:29 +0800 (CST) Received: from [10.70.0.82] by maila.huawei.com (mshttpd); Wed, 09 Jun 2004 15:12:39 +0800 Date: Wed, 09 Jun 2004 15:12:39 +0800 From: zhuning 17035 To: megaco@ietf.org Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 0.7 (built Jun 26 2002) Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: zh-CN Priority: normal X-imss-version: 2.5 X-imss-result: Passed X-imss-scores: Clean:15.42458 C:22 M:2 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:3 R:3 (0.0000 0.0000) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT X-Mailman-Approved-At: Thu, 10 Jun 2004 12:59:01 -0400 Subject: [Megaco] one question X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org Content-Transfer-Encoding: 7BIT can u give me a standard sample of h248 message which brings "Silence Suppression" para? Thanks a lot _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Fri Jun 11 08:22:51 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17536 for ; Fri, 11 Jun 2004 08:22:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYkSn-0000el-1l; Fri, 11 Jun 2004 07:44:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYSlm-0005X6-2A for megaco@megatron.ietf.org; Thu, 10 Jun 2004 12:51: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 MAA18519 for ; Thu, 10 Jun 2004 12:51:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYSlk-0004nF-Rc for megaco@ietf.org; Thu, 10 Jun 2004 12:51:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYSi5-0003di-00 for megaco@ietf.org; Thu, 10 Jun 2004 12:47:26 -0400 Received: from zrtps06s.nortelnetworks.com ([47.140.48.50]) by ietf-mx with esmtp (Exim 4.12) id 1BYSgU-0002d9-00 for megaco@ietf.org; Thu, 10 Jun 2004 12:45:47 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i5AGioO16748; Thu, 10 Jun 2004 12:44:50 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 10 Jun 2004 12:44:49 -0400 Message-ID: From: "Kevin Boyle" To: Umesh Sharma , bvswamy@hss.hns.com, megaco@ietf.org Subject: RE: [Megaco] ServiceChange Address lifetime Date: Thu, 10 Jun 2004 12:44:48 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,EXCUSE_16,HTML_20_30, HTML_MESSAGE autolearn=no version=2.60 X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2132009907==" Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org 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. --===============2132009907== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C44F0A.3E3BB386" 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_01C44F0A.3E3BB386 Content-Type: text/plain Correct. The address only persists for the lifetime of the control association. Kevin -----Original Message----- From: Umesh Sharma [mailto:umesh_sharma@persistent.co.in] Sent: Thursday, June 10, 2004 9:22 AM To: bvswamy@hss.hns.com; megaco@ietf.org Subject: RE: [Megaco] ServiceChange Address lifetime Hi Venkat >From protocol language it looks the changed address is not persistent: >> ServiceChangeAddress provides an address to be used within the >> context of the association currently being negotiated regards Umesh -----Original Message----- From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org]On Behalf Of bvswamy@hss.hns.com Sent: Thursday, June 10, 2004 5:28 PM To: megaco@ietf.org Subject: [Megaco] ServiceChange Address lifetime Hi For the scenario mentioned below what is the lifetime of the ServiceChange Address: 1) Through Management interface MGC is configured for the transport address of the MediaGateway. 2) MG does a registration with MGC using the configured transport address. 3) At the MG end, local transport address is changed through the management interface 4) MG sends ServiceChange with ServiceChangeAddress to the MGC. 5) MGC modifies the remote entity information at its end. Now should this changed address be considered persistent from this point onwards or its validity is only for the time the association is active. What if MGC or MG goes down and comes up again, then what should be the MG address at the MGC end. Regards Venkat "DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco ------_=_NextPart_001_01C44F0A.3E3BB386 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Megaco] ServiceChange Address lifetime

Correct.  The address only persists for the = lifetime of the control association.

Kevin

-----Original Message-----
From: Umesh Sharma [mailto:umesh_sharma@persis= tent.co.in]
Sent: Thursday, June 10, 2004 9:22 AM
To: bvswamy@hss.hns.com; megaco@ietf.org
Subject: RE: [Megaco] ServiceChange Address = lifetime

Hi Venkat

>From protocol language it looks the changed = address is not persistent:

>> ServiceChangeAddress provides an address to = be used within the
>> context of the association currently being = negotiated

regards
Umesh

-----Original Message-----
From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org]On Behalf Of bvswamy@hss.hns.com
Sent: Thursday, June 10, 2004 5:28 PM
To: megaco@ietf.org
Subject: [Megaco] ServiceChange Address = lifetime






Hi
      For the scenario = mentioned below what is the lifetime of the ServiceChange = Address:
1) Through Management interface MGC is configured = for the transport address of the MediaGateway.
2) MG does a registration with MGC using the = configured transport address.
3) At the MG end, local transport address is changed = through the management interface
4) MG sends ServiceChange with ServiceChangeAddress = to the MGC.
5) MGC modifies the remote entity information at its = end.

Now should this changed address be considered = persistent from this point onwards or its validity is only for the time = the association is active.

What if MGC or MG goes down and comes up again, then = what should be the MG address at the MGC end.

Regards
Venkat


"DISCLAIMER: This message is proprietary to = Hughes Software Systems Limited
(HSS) and is intended solely for the use of the = individual to whom it is addressed. It may contain  privileged or = confidential information and should not be circulated or used for any = purpose other than for what it is intended. If you have received this = message in error, please notify the originator immediately. If you are = not the intended recipient, you are notified that you are strictly = prohibited from using, copying, altering, or disclosing the contents of = this message. HSS accepts no responsibility for loss or damage arising = from the use of the information transmitted by this email including = damage from virus."


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

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

------_=_NextPart_001_01C44F0A.3E3BB386-- --===============2132009907== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============2132009907==-- From megaco-bounces@ietf.org Fri Jun 11 09:20:31 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23556 for ; Fri, 11 Jun 2004 09:20:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYkUe-0001B1-8Q; Fri, 11 Jun 2004 07:46:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYfRC-0007lM-F0 for megaco@megatron.ietf.org; Fri, 11 Jun 2004 02:22:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01930 for ; Fri, 11 Jun 2004 02:22:47 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYfR8-0005lp-Ub for megaco@ietf.org; Fri, 11 Jun 2004 02:22:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYfQD-0005Lf-00 for megaco@ietf.org; Fri, 11 Jun 2004 02:21:49 -0400 Received: from web10710.mail.yahoo.com ([216.136.130.75]) by ietf-mx with smtp (Exim 4.12) id 1BYfPh-0004vk-00 for megaco@ietf.org; Fri, 11 Jun 2004 02:21:17 -0400 Message-ID: <20040611062117.23618.qmail@web10710.mail.yahoo.com> Received: from [128.107.253.43] by web10710.mail.yahoo.com via HTTP; Fri, 11 Jun 2004 16:21:17 EST Date: Fri, 11 Jun 2004 16:21:17 +1000 (EST) From: =?iso-8859-1?q?petric=20john?= Subject: Re: [Megaco] ServiceChange Address lifetime To: bvswamy@hss.hns.com, megaco@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 8bit X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org Content-Transfer-Encoding: 8bit >From the protocol perspective, the service change address remains active till the time you send another SVC with SVCAddress. So given this condition, please see my comments below, marked with [PJ]. --- bvswamy@hss.hns.com wrote: > > > > > Hi > For the scenario mentioned below what is the > lifetime of the > ServiceChange Address: > 1) Through Management interface MGC is configured > for the transport address of the MediaGateway. > 3) At the MG end, local transport address is changed > through the management interface > 5) MGC modifies the remote entity information at its > end. [PJ] This scenario, I see as a change in the provisioned information. This may not initiate any SVC procedure during an active assiciation currently being used. > 2) MG does a registration with MGC using the > configured transport address. [PJ] This is more a initial SVC message when MG is coming up. > 4) MG sends ServiceChange with ServiceChangeAddress > to the MGC. > > Now should this changed address be considered > persistent from this point onwards or its validity > is only for the time the association is active. > What if MGC or MG goes down and comes up again, then > what should be the MG address at the MGC end. > [PJ] This is the text from 7.2.8@rfc3525@Page64: ------------------------------------------------ The MG may specify an address in the ServiceChangeAddress parameter of the ServiceChange request, and the MGC may also do so in the ServiceChange reply. In either case, the recipient must use the supplied address as the destination for all subsequent transaction requests within the association. So to answer your question, 1. This changed address should be considered persistent only for the time the association is active. 2. When the either MG or MGC goes down and comes up again, it shall use whatever is configured/provisioned. Hope it helps. Regds, /PJ. > Regards > Venkat > Find local movie times and trailers on Yahoo! Movies. http://au.movies.yahoo.com _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Fri Jun 11 09:20:56 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23612 for ; Fri, 11 Jun 2004 09:20:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYkUe-0001B7-Mz; Fri, 11 Jun 2004 07:46:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYfXx-0001Dw-9l for megaco@megatron.ietf.org; Fri, 11 Jun 2004 02:29:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02318 for ; Fri, 11 Jun 2004 02:29:47 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYfXu-0000ys-Uf for megaco@ietf.org; Fri, 11 Jun 2004 02:29:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYfX0-0000Z6-00 for megaco@ietf.org; Fri, 11 Jun 2004 02:28:50 -0400 Received: from web10709.mail.yahoo.com ([216.136.130.115]) by ietf-mx with smtp (Exim 4.12) id 1BYfWE-00009K-00 for megaco@ietf.org; Fri, 11 Jun 2004 02:28:02 -0400 Message-ID: <20040611062802.50079.qmail@web10709.mail.yahoo.com> Received: from [128.107.253.43] by web10709.mail.yahoo.com via HTTP; Fri, 11 Jun 2004 16:28:02 EST Date: Fri, 11 Jun 2004 16:28:02 +1000 (EST) From: =?iso-8859-1?q?petric=20john?= Subject: Re: [Megaco] ServiceChange Address lifetime To: bvswamy@hss.hns.com, megaco@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 8bit X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org Content-Transfer-Encoding: 8bit >From the protocol perspective, the service change address remains active till the time you send another SVC with SVCAddress. So given this condition, please see my comments below, marked with [PJ]. --- bvswamy@hss.hns.com wrote: > > > > > Hi > For the scenario mentioned below what is the > lifetime of the > ServiceChange Address: > 1) Through Management interface MGC is configured > for the transport address of the MediaGateway. > 3) At the MG end, local transport address is changed > through the management interface > 5) MGC modifies the remote entity information at its > end. [PJ] This scenario, I see as a change in the provisioned information. This may not initiate any SVC procedure during an active assiciation currently being used. > 2) MG does a registration with MGC using the > configured transport address. [PJ] This is more a initial SVC message when MG is coming up. > 4) MG sends ServiceChange with ServiceChangeAddress > to the MGC. > > Now should this changed address be considered > persistent from this point onwards or its validity > is only for the time the association is active. > What if MGC or MG goes down and comes up again, then > what should be the MG address at the MGC end. > [PJ] This is the text from 7.2.8@rfc3525@Page64: ------------------------------------------------ The MG may specify an address in the ServiceChangeAddress parameter of the ServiceChange request, and the MGC may also do so in the ServiceChange reply. In either case, the recipient must use the supplied address as the destination for all subsequent transaction requests within the association. So to answer your question, 1. This changed address should be considered persistent only for the time the association is active. 2. When the either MG or MGC goes down and comes up again, it shall use whatever is configured/provisioned. Hope it helps. Regds, /PJ. > Regards > Venkat > Find local movie times and trailers on Yahoo! Movies. http://au.movies.yahoo.com _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Fri Jun 11 11:06:22 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09729 for ; Fri, 11 Jun 2004 11:06:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYnO5-0002tS-5F; Fri, 11 Jun 2004 10:52:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYSmv-0005jU-3q for megaco@megatron.ietf.org; Thu, 10 Jun 2004 12:52: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 MAA18787 for ; Thu, 10 Jun 2004 12:52:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYSmt-0005Zo-Vw for megaco@ietf.org; Thu, 10 Jun 2004 12:52:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYSjk-0004Gd-00 for megaco@ietf.org; Thu, 10 Jun 2004 12:49:11 -0400 Received: from zrtps06s.nortelnetworks.com ([47.140.48.50]) by ietf-mx with esmtp (Exim 4.12) id 1BYSh6-0002eB-00 for megaco@ietf.org; Thu, 10 Jun 2004 12:46:24 -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 i5AGhiO16620; Thu, 10 Jun 2004 12:43:44 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 10 Jun 2004 12:43:43 -0400 Message-ID: From: "Kevin Boyle" To: Raphael Tryster , "'Christian Groves'" Subject: RE: [Megaco] Descriptor processing on Termination OOS Date: Thu, 10 Jun 2004 12:43:44 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,HTML_50_60,HTML_MESSAGE autolearn=no version=2.60 X-Mailman-Approved-At: Fri, 11 Jun 2004 10:52:08 -0400 Cc: Tom-PT Taylor , anilj@cisco.com, bvswamy@hss.hns.com, megaco@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2059505179==" Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org 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. --===============2059505179== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C44F0A.17A3A2A6" 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_01C44F0A.17A3A2A6 Content-Type: text/plain VMWI, generally speaking, is a CLASS data message that fires and forgets. The switch even refreshes it from time to time. So, one solution is to use andisp to send data without alerting to light the lamp. Kevin _____ From: Raphael Tryster [mailto:raphael@tdsoft.com] Sent: Thursday, June 10, 2004 2:04 AM To: 'Christian Groves' Cc: Boyle, Kevin [NCRTP:3Z40:EXCH]; bvswamy@hss.hns.com; anilj@cisco.com; Taylor, Tom-PT [CAR:5N00:EXCH]; megaco@ietf.org Subject: RE: [Megaco] Descriptor processing on Termination OOS Because this termination may wish to be part of many other contexts while the signal persists, i.e. I can make many calls while the light on my phone is on, before checking my voice mail. Raphael Tryster BM__MailData-----Original Message----- From: Christian Groves [SMTP:christian.groves@ericsson.com] Sent: Thursday, 10 June 2004 2:19 To: Raphael Tryster Cc: 'Kevin Boyle'; bvswamy@hss.hns.com; anilj@cisco.com; Tom-PT Taylor; megaco@ietf.org Subject: Re: [Megaco] Descriptor processing on Termination OOS If you want VMWI to persist why don't you MOV a termination to its own context? Christian Raphael Tryster wrote: > So there would be a discontinuity in the signal. Is that what real MGCs > do? > > Raphael Tryster > > > -----Original Message----- > From: Christian Groves [SMTP:christian.groves@ericsson.com] > Sent: Monday, 7 June 2004 2:10 > To: Raphael Tryster > Cc: 'Kevin Boyle'; bvswamy@hss.hns.com; anilj@cisco.com; > Tom-PT Taylor; megaco@ietf.org > Subject: Re: [Megaco] Descriptor processing on Termination OOS > > Hello Raphael, > > A signal's descriptor cannot be sent in a subtract command. It > would have to be > modified in the NULL context. > > Regards, Christian > > Raphael Tryster wrote: > > > Hello Christian, > > > > I gather from your reply that in my first question, 6.2.4 > overrides > > 7.1.11, and in my second question, it is the MGC's > responsibility to > > avoid inconsistencies. Does the former mean that even off/on > signals > > terminate on subtraction from a context? Therefore, if the MGC > wants > > something like VMWI to persist, it has to re-issue it on every > subtract? > > > > Raphael Tryster > > > > > > -----Original Message----- > > From: Christian Groves > [SMTP:christian.groves@ericsson.com] > > Sent: Friday, 28 May 2004 7:09 > > To: Raphael Tryster > > Cc: 'Kevin Boyle'; bvswamy@hss.hns.com; anilj@cisco.com; > > Tom-PT Taylor; megaco@ietf.org > > Subject: Re: [Megaco] Descriptor processing on > Termination OOS > > > > Hello Raphael, > > > > Please see my comments below. > > > > Regards, Christian > > > > Raphael Tryster wrote: > > > > > Two questions related to the discussion below: > > > > > > Firstly, the quote below from H.248.1 6.2.4 seems to > contradict > > section > > > 7.1.11, which states: > > > > > > "Production of a Signal on a Termination is stopped by > > application of a > > > new SignalsDescriptor, or detection of an Event on the > > Termination". > > > > > > What about returning to the null context? According > to 6.2.4, the > > > signal should stop, whereas according to 7.1.11, it > should not > > stop. > > > Unless the resetting of descriptors to default values > when > > returning to > > > the null context is considered to be a case of > application of a > > new > > > SignalsDescriptor? But then what do we do about > on/off type > > signals, > > > e.g. visual message waiting indicator? Surely they > are meant > > to survive > > > subtraction from a context? > > > > [CHG] I would assume that by returning a termination to > the NULL > > context via a > > subtract results in a signal being stopped. 6.2.4 says, > "If not > > provisioned > > otherwise, the properties in all descriptors except > > TerminationState and > > LocalControl default to empty/"no value" when a > Termination is > > first created or > > returned to the null Context. The default contents of the > two > > exceptions are > > described in 7.1.5 and 7.1.7." 7.1.11 talks about > replacement > > SignalDescriptor > > which is effectively what happens when you return to the > NULL > > context. The > > current descriptors are replaced by the provisioned > descriptors. > > Also 7.1.11 is > > not mentioned as an exception. > > > > > > > > My second question concerns the requirement that the > MG maintain > > > terminations in contexts until the MGC explicitly > subtracts them. > > > Consider a distributed MG, in which the part that > talks to the > > MGC does > > > not completely control the part that allocates > resources such > > as IP > > > address and UDP port for local descriptors. Suppose some > > administrative > > > action or fault causes these resources to become > physically > > unavailable > > > to the termination with which they were associated. > The MG > > informs the > > > MGC (or fails to do so if the MGC didn't request the > event), > > but for > > > some reason the MGC does not issue a Subtract. The > front end > > of the MG > > > has no problem complying with Megaco rules: it will > accept any > > commands > > > it can on that context, and send a proper rejection if > the > > cleanup that > > > has taken place in the back end makes it impossible to > comply > > with a > > > request. However, if the MGC audits the local > descriptor, the > > MG front > > > end will send an IP address and UDP port that the back > end may > > already > > > be reusing for another call. The MGC can then > presumably do > > bad things > > > with this outdated information. Which of the > following are > > legitimate > > > solutions to this problem? > > > > > > 1. The MGC is at fault for ignoring indications > from the MG > > that > > > something went wrong. > > > > > > 2. The MG is at fault for being schizophrenic. It > must > > prevent reuse > > > of all resources associated with the context > until it > > receives > > > Subtract. > > > > > > 3. The MG can sidestep the problem. It is only > required to > > keep the > > > termination in the context, but it can clear the > local > > > descriptor. (And what if the MGC doesn't audit but > > relies on its > > > memory?) > > > > > > 4. There is no problem. The MGC cannot do anything > bad with > > the > > > information. > > > > [CHG] I would suggest that if the MG has experienced a > problem > > with the > > termination that it send a generic cause event indicating > failure. > > It the MGC > > doesn't request this event then the designers must > understand the > > consequences. > > Also if there is a more terminal failure a servicechange > could be > > sent. > > > > > > > > Raphael Tryster > > > > ------_=_NextPart_001_01C44F0A.17A3A2A6 Content-Type: text/html RE: [Megaco] Descriptor processing on Termination OOS
VMWI, generally speaking, is a CLASS data message that fires and forgets.  The switch even refreshes it from time to time.  So, one solution is to use andisp to send data without alerting to light the lamp.
 
Kevin

From: Raphael Tryster [mailto:raphael@tdsoft.com]
Sent: Thursday, June 10, 2004 2:04 AM
To: 'Christian Groves'
Cc: Boyle, Kevin [NCRTP:3Z40:EXCH]; bvswamy@hss.hns.com; anilj@cisco.com; Taylor, Tom-PT [CAR:5N00:EXCH]; megaco@ietf.org
Subject: RE: [Megaco] Descriptor processing on Termination OOS

Because this termination may wish to be part of many other contexts while the signal persists, i.e. I can make many calls while the light on my phone is on, before checking my voice mail.

Raphael Tryster


    -----Original Message-----
    From:   Christian Groves [SMTP:christian.groves@ericsson.com]
    Sent:   Thursday, 10 June 2004 2:19
    To:     Raphael Tryster
    Cc:     'Kevin Boyle'; bvswamy@hss.hns.com; anilj@cisco.com; Tom-PT Taylor; megaco@ietf.org
    Subject:        Re: [Megaco] Descriptor processing on Termination OOS

    If you want VMWI to persist why don't you MOV a termination to its own context?

    Christian

    Raphael Tryster wrote:

    > So there would be a discontinuity in the signal.  Is that what real MGCs
    > do?
    >
    > Raphael Tryster
    >
    >
    >       -----Original Message-----
    >       From:   Christian Groves [SMTP:christian.groves@ericsson.com]
    >       Sent:   Monday, 7 June 2004 2:10
    >       To:     Raphael Tryster
    >       Cc:     'Kevin Boyle'; bvswamy@hss.hns.com; anilj@cisco.com;
    >       Tom-PT Taylor; megaco@ietf.org
    >       Subject:        Re: [Megaco] Descriptor processing on Termination OOS
    >
    >       Hello Raphael,
    >
    >       A signal's descriptor cannot be sent in a subtract command. It
    >       would have to be
    >       modified in the NULL context.
    >
    >       Regards, Christian
    >
    >       Raphael Tryster wrote:
    >
    >        > Hello Christian,
    >        >
    >        > I gather from your reply that in my first question, 6.2.4
    >       overrides
    >        > 7.1.11, and in my second question, it is the MGC's
    >       responsibility to
    >        > avoid inconsistencies.  Does the former mean that even off/on
    >       signals
    >        > terminate on subtraction from a context?  Therefore, if the MGC
    >       wants
    >        > something like VMWI to persist, it has to re-issue it on every
    >       subtract?
    >        >
    >        > Raphael Tryster
    >        >
    >        >
    >        >       -----Original Message-----
    >        >       From:   Christian Groves
    >       [SMTP:christian.groves@ericsson.com]
    >        >       Sent:   Friday, 28 May 2004 7:09
    >        >       To:     Raphael Tryster
    >        >       Cc:     'Kevin Boyle'; bvswamy@hss.hns.com; anilj@cisco.com;
    >        >       Tom-PT Taylor; megaco@ietf.org
    >        >       Subject:        Re: [Megaco] Descriptor processing on
    >       Termination OOS
    >        >
    >        >       Hello Raphael,
    >        >
    >        >       Please see my comments below.
    >        >
    >        >       Regards, Christian
    >        >
    >        >       Raphael Tryster wrote:
    >        >
    >        >        > Two questions related to the discussion below:
    >        >        >
    >        >        > Firstly, the quote below from H.248.1 6.2.4 seems to
    >       contradict
    >        >       section
    >        >        > 7.1.11, which states:
    >        >        >
    >        >        > "Production of a Signal on a Termination is stopped by
    >        >       application of a
    >        >        > new SignalsDescriptor, or detection of an Event on the
    >        >       Termination".
    >        >        >
    >        >        > What about returning to the null context?  According
    >       to 6.2.4, the
    >        >        > signal should stop, whereas according to 7.1.11, it
    >       should not
    >        >       stop.
    >        >        > Unless the resetting of descriptors to default values
    >       when
    >        >       returning to
    >        >        > the null context is considered to be a case of
    >       application of a
    >        >       new
    >        >        > SignalsDescriptor?  But then what do we do about
    >       on/off type
    >        >       signals,
    >        >        > e.g. visual message waiting indicator?  Surely they
    >       are meant
    >        >       to survive
    >        >        > subtraction from a context?
    >        >
    >        >       [CHG] I would assume that by returning a termination to
    >       the NULL
    >        >       context via a
    >        >       subtract results in a signal being stopped. 6.2.4 says,
    >       "If not
    >        >       provisioned
    >        >       otherwise, the properties in all descriptors except
    >        >       TerminationState and
    >        >       LocalControl default to empty/"no value" when a
    >       Termination is
    >        >       first created or
    >        >       returned to the null Context. The default contents of the
    >       two
    >        >       exceptions are
    >        >       described in 7.1.5 and 7.1.7." 7.1.11 talks about
    >       replacement
    >        >       SignalDescriptor
    >        >       which is effectively what happens when you return to the
    >       NULL
    >        >       context. The
    >        >       current descriptors are replaced by the provisioned
    >       descriptors.
    >        >       Also 7.1.11 is
    >        >       not mentioned as an exception.
    >        >
    >        >        >
    >        >        > My second question concerns the requirement that the
    >       MG maintain
    >        >        > terminations in contexts until the MGC explicitly
    >       subtracts them.
    >        >        > Consider a distributed MG, in which the part that
    >       talks to the
    >        >       MGC does
    >        >        > not completely control the part that allocates
    >       resources such
    >        >       as IP
    >        >        > address and UDP port for local descriptors.  Suppose some
    >        >       administrative
    >        >        > action or fault causes these resources to become
    >       physically
    >        >       unavailable
    >        >        > to the termination with which they were associated.
    >       The MG
    >        >       informs the
    >        >        > MGC (or fails to do so if the MGC didn't request the
    >       event),
    >        >       but for
    >        >        > some reason the MGC does not issue a Subtract.  The
    >       front end
    >        >       of the MG
    >        >        > has no problem complying with Megaco rules: it will
    >       accept any
    >        >       commands
    >        >        > it can on that context, and send a proper rejection if
    >       the
    >        >       cleanup that
    >        >        > has taken place in the back end makes it impossible to
    >       comply
    >        >       with a
    >        >        > request.  However, if the MGC audits the local
    >       descriptor, the
    >        >       MG front
    >        >        > end will send an IP address and UDP port that the back
    >       end may
    >        >       already
    >        >        > be reusing for another call.  The MGC can then
    >       presumably do
    >        >       bad things
    >        >        > with this outdated information.  Which of the
    >       following are
    >        >       legitimate
    >        >        > solutions to this problem?
    >        >        >
    >        >        >    1. The MGC is at fault for ignoring indications
    >       from the MG
    >        >       that
    >        >        >       something went wrong.
    >        >        >
    >        >        >    2. The MG is at fault for being schizophrenic.  It
    >       must
    >        >       prevent reuse
    >        >        >       of all resources associated with the context
    >       until it
    >        >       receives
    >        >        >       Subtract.
    >        >        >
    >        >        >    3. The MG can sidestep the problem.  It is only
    >       required to
    >        >       keep the
    >        >        >       termination in the context, but it can clear the
    >       local
    >        >        >       descriptor.  (And what if the MGC doesn't audit but
    >        >       relies on its
    >        >        >       memory?)
    >        >        >
    >        >        >    4. There is no problem.  The MGC cannot do anything
    >       bad with
    >        >       the
    >        >        >       information.
    >        >
    >        >       [CHG] I would suggest that if the MG has experienced a
    >       problem
    >        >       with the
    >        >       termination that it send a generic cause event indicating
    >       failure.
    >        >       It the MGC
    >        >       doesn't request this event then the designers must
    >       understand the
    >        >       consequences.
    >        >       Also if there is a more terminal failure a servicechange
    >       could be
    >        >       sent.
    >        >
    >        >        >
    >        >        > Raphael Tryster
    >        >        >
    >

------_=_NextPart_001_01C44F0A.17A3A2A6-- --===============2059505179== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============2059505179==-- From megaco-bounces@ietf.org Fri Jun 11 11:06:42 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09753 for ; Fri, 11 Jun 2004 11:06:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYnO5-0002ta-QG; Fri, 11 Jun 2004 10:52:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYSpW-0006LS-5K for megaco@megatron.ietf.org; Thu, 10 Jun 2004 12:55: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 MAA19193 for ; Thu, 10 Jun 2004 12:55:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYSpU-0006RZ-Ni for megaco@ietf.org; Thu, 10 Jun 2004 12:55:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYSoD-0005sh-00 for megaco@ietf.org; Thu, 10 Jun 2004 12:53:48 -0400 Received: from mail.tdsoft.com ([212.143.64.34] helo=TdSoft.eSafe.com) by ietf-mx with smtp (Exim 4.12) id 1BYSmJ-0005CC-00 for megaco@ietf.org; Thu, 10 Jun 2004 12:51:48 -0400 Received: from mailserver.td-soft.co.il ([IP=172.16.1.203]) by eSafe SMTP Relay 1086793587; Thu Jun 10 19:51:30 2004 Received: by MAILSERVER with Internet Mail Service (5.5.2657.72) id ; Thu, 10 Jun 2004 19:49:07 +0200 Message-ID: <9A64A99CD3F2BD4582BE4FB63FC1F3816D0FCF@MAILSERVER> From: Raphael Tryster To: "'Kevin Boyle'" , "'Christian Groves'" Subject: RE: [Megaco] Descriptor processing on Termination OOS Date: Thu, 10 Jun 2004 19:48:52 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-eSafe-inspection-result: Mail clean X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,HTML_40_50,HTML_MESSAGE autolearn=no version=2.60 X-Mailman-Approved-At: Fri, 11 Jun 2004 10:52:08 -0400 Cc: Tom-PT Taylor , anilj@cisco.com, bvswamy@hss.hns.com, megaco@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1947851162==" Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org 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. --===============1947851162== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C44F13.317E7300" 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_01C44F13.317E7300 Content-Type: text/plain; charset="iso-8859-1" OK, so perhaps VMWI is a bad example for Megaco (it's type OO in MGCP). But there must be other OO signals that we wouldn't want to Move to a context because they may take part in calls while the signal is on. The sense I am getting is that OO signals are a feature that Megaco claims to support but subverts its operation. Raphael Tryster -----Original Message----- From: Kevin Boyle [SMTP:kboyle@nortelnetworks.com] Sent: Thursday, 10 June 2004 18:44 To: Raphael Tryster; 'Christian Groves' Cc: bvswamy@hss.hns.com; anilj@cisco.com; Tom-PT Taylor; megaco@ietf.org Subject: RE: [Megaco] Descriptor processing on Termination OOS VMWI, generally speaking, is a CLASS data message that fires and forgets. The switch even refreshes it from time to time. So, one solution is to use andisp to send data without alerting to light the lamp. Kevin _____ From: Raphael Tryster [mailto:raphael@tdsoft.com] Sent: Thursday, June 10, 2004 2:04 AM To: 'Christian Groves' Cc: Boyle, Kevin [NCRTP:3Z40:EXCH]; bvswamy@hss.hns.com; anilj@cisco.com; Taylor, Tom-PT [CAR:5N00:EXCH]; megaco@ietf.org Subject: RE: [Megaco] Descriptor processing on Termination OOS Because this termination may wish to be part of many other contexts while the signal persists, i.e. I can make many calls while the light on my phone is on, before checking my voice mail. Raphael Tryster -----Original Message----- From: Christian Groves [SMTP:christian.groves@ericsson.com] Sent: Thursday, 10 June 2004 2:19 To: Raphael Tryster Cc: 'Kevin Boyle'; bvswamy@hss.hns.com; anilj@cisco.com; Tom-PT Taylor; megaco@ietf.org Subject: Re: [Megaco] Descriptor processing on Termination OOS If you want VMWI to persist why don't you MOV a termination to its own context? Christian Raphael Tryster wrote: > So there would be a discontinuity in the signal. Is that what real MGCs > do? > > Raphael Tryster > > > -----Original Message----- > From: Christian Groves [SMTP:christian.groves@ericsson.com] > Sent: Monday, 7 June 2004 2:10 > To: Raphael Tryster > Cc: 'Kevin Boyle'; bvswamy@hss.hns.com; anilj@cisco.com; > Tom-PT Taylor; megaco@ietf.org > Subject: Re: [Megaco] Descriptor processing on Termination OOS > > Hello Raphael, > > A signal's descriptor cannot be sent in a subtract command. It > would have to be > modified in the NULL context. > > Regards, Christian > > Raphael Tryster wrote: > > > Hello Christian, > > > > I gather from your reply that in my first question, 6.2.4 > overrides > > 7.1.11, and in my second question, it is the MGC's > responsibility to > > avoid inconsistencies. Does the former mean that even off/on > signals > > terminate on subtraction from a context? Therefore, if the MGC > wants > > something like VMWI to persist, it has to re-issue it on every > subtract? > > > > Raphael Tryster > > > > > > -----Original Message----- > > From: Christian Groves > [SMTP:christian.groves@ericsson.com] > > Sent: Friday, 28 May 2004 7:09 > > To: Raphael Tryster > > Cc: 'Kevin Boyle'; bvswamy@hss.hns.com; anilj@cisco.com; > > Tom-PT Taylor; megaco@ietf.org > > Subject: Re: [Megaco] Descriptor processing on > Termination OOS > > > > Hello Raphael, > > > > Please see my comments below. > > > > Regards, Christian > > > > Raphael Tryster wrote: > > > > > Two questions related to the discussion below: > > > > > > Firstly, the quote below from H.248.1 6.2.4 seems to > contradict > > section > > > 7.1.11, which states: > > > > > > "Production of a Signal on a Termination is stopped by > > application of a > > > new SignalsDescriptor, or detection of an Event on the > > Termination". > > > > > > What about returning to the null context? According > to 6.2.4, the > > > signal should stop, whereas according to 7.1.11, it > should not > > stop. > > > Unless the resetting of descriptors to default values > when > > returning to > > > the null context is considered to be a case of > application of a > > new > > > SignalsDescriptor? But then what do we do about > on/off type > > signals, > > > e.g. visual message waiting indicator? Surely they > are meant > > to survive > > > subtraction from a context? > > > > [CHG] I would assume that by returning a termination to > the NULL > > context via a > > subtract results in a signal being stopped. 6.2.4 says, > "If not > > provisioned > > otherwise, the properties in all descriptors except > > TerminationState and > > LocalControl default to empty/"no value" when a > Termination is > > first created or > > returned to the null Context. The default contents of the > two > > exceptions are > > described in 7.1.5 and 7.1.7." 7.1.11 talks about > replacement > > SignalDescriptor > > which is effectively what happens when you return to the > NULL > > context. The > > current descriptors are replaced by the provisioned > descriptors. > > Also 7.1.11 is > > not mentioned as an exception. > > > > > > > > My second question concerns the requirement that the > MG maintain > > > terminations in contexts until the MGC explicitly > subtracts them. > > > Consider a distributed MG, in which the part that > talks to the > > MGC does > > > not completely control the part that allocates > resources such > > as IP > > > address and UDP port for local descriptors. Suppose some > > administrative > > > action or fault causes these resources to become > physically > > unavailable > > > to the termination with which they were associated. > The MG > > informs the > > > MGC (or fails to do so if the MGC didn't request the > event), > > but for > > > some reason the MGC does not issue a Subtract. The > front end > > of the MG > > > has no problem complying with Megaco rules: it will > accept any > > commands > > > it can on that context, and send a proper rejection if > the > > cleanup that > > > has taken place in the back end makes it impossible to > comply > > with a > > > request. However, if the MGC audits the local > descriptor, the > > MG front > > > end will send an IP address and UDP port that the back > end may > > already > > > be reusing for another call. The MGC can then > presumably do > > bad things > > > with this outdated information. Which of the > following are > > legitimate > > > solutions to this problem? > > > > > > 1. The MGC is at fault for ignoring indications > from the MG > > that > > > something went wrong. > > > > > > 2. The MG is at fault for being schizophrenic. It > must > > prevent reuse > > > of all resources associated with the context > until it > > receives > > > Subtract. > > > > > > 3. The MG can sidestep the problem. It is only > required to > > keep the > > > termination in the context, but it can clear the > local > > > descriptor. (And what if the MGC doesn't audit but > > relies on its > > > memory?) > > > > > > 4. There is no problem. The MGC cannot do anything > bad with > > the > > > information. > > > > [CHG] I would suggest that if the MG has experienced a > problem > > with the > > termination that it send a generic cause event indicating > failure. > > It the MGC > > doesn't request this event then the designers must > understand the > > consequences. > > Also if there is a more terminal failure a servicechange > could be > > sent. > > > > > > > > Raphael Tryster > > > > ------_=_NextPart_001_01C44F13.317E7300 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Megaco] Descriptor processing on Termination OOS

OK, so perhaps VMWI is a bad example for= Megaco (it's type OO in MGCP).  But there must be other OO signals = that we wouldn't want to Move to a context because they may take part in = calls while the signal is on.  The sense I am getting is that OO sig= nals are a feature that Megaco claims to support but subverts its operati= on.

Raphael Tryster

    -----Original Mess= age-----
    From:   Kevin Boyle [SMTP:= kboyle@nortelnetworks.com]
    Sent:   Thursday, 10 June 2004 18:44
    To:     Raphael Tryster; 'Christian Groves'
    Cc:     bvswamy@hss.hns.com; anilj@cisco.com; To= m-PT Taylor; megaco@ietf.org
    Subject:    &nbs= p;   RE: [Megaco] Desc= riptor processing on Termination OOS

    VMWI, generally speaking, is a CLASS dat= a message that fires and forgets.=A0 The switch even refreshes it from ti= me to time.=A0 So, one solution is to use andisp to send data without ale= rting to light the lamp.

    =A0
    Kevin


    =A0 _____ =A0

      From: Raphael Tryster [mailto:r= aphael@tdsoft.com]
      Sent: Thursday, June 10, 2004 2:04 AM
      To: 'Christian Groves'
      Cc: Boyle, Kevin [NCRTP:3Z40:EXCH]; bvswamy@hss.hns.com; a= nilj@cisco.com; Taylor, Tom-PT [CAR:5N00:EXCH]; megaco@ietf.org
      Subject: RE: [Megaco] Descriptor processing on Terminati= on OOS

      Because this termination may wish to be = part of many other contexts while the signal persists, i.e. I can make ma= ny calls while the light on my phone is on, before checking my voice mail= =2E

      Raphael Tryster


      -----Original M= essage-----
      From:=A0=A0 Christian Groves [SMT= P:christian.groves@ericsson.com]
      Sent:=A0=A0 Thursday, 10 June 2004 2:19=
      To:=A0=A0=A0=A0 Raphael Tryster
      Cc:=A0=A0=A0=A0 'Kevin Boyle'; bvswam= y@hss.hns.com; anilj@cisco.com; Tom-PT Taylor; megaco@ietf.org
      Subject:=A0=A0=A0=A0=A0=A0=A0 Re: [Me= gaco] Descriptor processing on Termination OOS

      If you want VMWI to persist why do= n't you MOV a termination to its own context?=

      Christian

      Raphael Tryster wrote:

      > So there would be a discontin= uity in the signal.=A0 Is that what real MGCs
      > do?<= BR> >
      > Raphael Tryster
      >
      >
      >=A0=A0=A0=A0=A0=A0 -----Original = Message-----
      >=A0=A0=A0=A0=A0=A0 From:=A0= =A0 Christian Groves [SMTP:christian.groves@ericsson.com]
      >=A0=A0=A0=A0=A0=A0 Sent:=A0= =A0 Monday, 7 June 2004 2:10
      >=A0=A0=A0=A0=A0=A0 To:=A0=A0= =A0=A0 Raphael Tryster
      >=A0=A0=A0=A0=A0=A0 Cc:=A0=A0= =A0=A0 'Kevin Boyle'; bvswamy@hss.hns.com; anilj@cisco.com;
      >=A0=A0=A0=A0=A0=A0 Tom-PT = Taylor; megaco@ietf.org
      >=A0=A0=A0=A0=A0=A0 Subject= :=A0=A0=A0=A0=A0=A0=A0 Re: [Megaco] Descriptor processing on Termination = OOS
      >
      >=A0=A0=A0=A0=A0=A0 Hello Raphael,=
      >
      >=A0=A0=A0=A0=A0=A0 A signal's des= criptor cannot be sent in a subtract command. It
      >=A0=A0=A0=A0=A0=A0 would h= ave to be
      >=A0=A0=A0=A0=A0=A0 modifie= d in the NULL context.
      >
      >=A0=A0=A0=A0=A0=A0 Regards, Chris= tian
      >
      >=A0=A0=A0=A0=A0=A0 Raphael Tryste= r wrote:
      >
      >=A0=A0=A0=A0=A0=A0=A0 > Hello = Christian,
      >=A0=A0=A0=A0=A0=A0=A0 >=
      >=A0=A0=A0=A0=A0=A0=A0 >= I gather from your reply that in my first question, 6.2.4
      >=A0=A0=A0=A0=A0=A0 overrid= es
      >=A0=A0=A0=A0=A0=A0=A0 >= 7.1.11, and in my second question, it is the MGC's
      >=A0=A0=A0=A0=A0=A0 respons= ibility to
      >=A0=A0=A0=A0=A0=A0=A0 >= avoid inconsistencies.=A0 Does the former mean that even off/on
      >=A0=A0=A0=A0=A0=A0 signals=
      >=A0=A0=A0=A0=A0=A0=A0 >= terminate on subtraction from a context?=A0 Therefore, if the MGC=
      >=A0=A0=A0=A0=A0=A0 wants
      >=A0=A0=A0=A0=A0=A0=A0 >= something like VMWI to persist, it has to re-issue it on every
      >=A0=A0=A0=A0=A0=A0 subtrac= t?
      >=A0=A0=A0=A0=A0=A0=A0 >=
      >=A0=A0=A0=A0=A0=A0=A0 >= Raphael Tryster
      >=A0=A0=A0=A0=A0=A0=A0 >=
      >=A0=A0=A0=A0=A0=A0=A0 >=
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0 -----Original Message-----=
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0 From:=A0=A0 Christian Groves
      >=A0=A0=A0=A0=A0=A0 [SMTP:c= hristian.groves@ericsson.com]
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0 Sent:=A0=A0 Friday, 28 May 2004 7:09
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0 To:=A0=A0=A0=A0 Raphael Tryster
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0 Cc:=A0=A0=A0=A0 'Kevin Boyle'; bvswamy@hss.hns.com; an= ilj@cisco.com;
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0 Tom-PT Taylor; megaco@ietf.org
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0 Subject:=A0=A0=A0=A0=A0=A0=A0 Re: [Megaco] Descriptor = processing on
      >=A0=A0=A0=A0=A0=A0 Termina= tion OOS
      >=A0=A0=A0=A0=A0=A0=A0 >=
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0 Hello Raphael,
      >=A0=A0=A0=A0=A0=A0=A0 >=
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0 Please see my comments below.
      >=A0=A0=A0=A0=A0=A0=A0 >=
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0 Regards, Christian
      >=A0=A0=A0=A0=A0=A0=A0 >=
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0 Raphael Tryster wrote:
      >=A0=A0=A0=A0=A0=A0=A0 >=
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0=A0 > Two questions related to the discussion below:=
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0=A0 >
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0=A0 > Firstly, the quote below from H.248.1 6.2.4 se= ems to
      >=A0=A0=A0=A0=A0=A0 contrad= ict
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0 section
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0=A0 > 7.1.11, which states:
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0=A0 >
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0=A0 > "Production of a Signal on a Termination = is stopped by
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0 application of a
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0=A0 > new SignalsDescriptor, or detection of an Even= t on the
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0 Termination".
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0=A0 >
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0=A0 > What about returning to the null context?=A0 A= ccording
      >=A0=A0=A0=A0=A0=A0 to 6.2.= 4, the
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0=A0 > signal should stop, whereas according to 7.1.1= 1, it
      >=A0=A0=A0=A0=A0=A0 should = not
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0 stop.
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0=A0 > Unless the resetting of descriptors to default= values
      >=A0=A0=A0=A0=A0=A0 when
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0 returning to
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0=A0 > the null context is considered to be a case of=
      >=A0=A0=A0=A0=A0=A0 applica= tion of a
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0 new
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0=A0 > SignalsDescriptor?=A0 But then what do we do a= bout
      >=A0=A0=A0=A0=A0=A0 on/off = type
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0 signals,
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0=A0 > e.g. visual message waiting indicator?=A0 Sure= ly they
      >=A0=A0=A0=A0=A0=A0 are mea= nt
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0 to survive
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0=A0 > subtraction from a context?
      >=A0=A0=A0=A0=A0=A0=A0 >=
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0 [CHG] I would assume that by returning a termination t= o
      >=A0=A0=A0=A0=A0=A0 the NUL= L
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0 context via a
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0 subtract results in a signal being stopped. 6.2.4 says= ,
      >=A0=A0=A0=A0=A0=A0 "I= f not
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0 provisioned
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0 otherwise, the properties in all descriptors except
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0 TerminationState and
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0 LocalControl default to empty/"no value" whe= n a
      >=A0=A0=A0=A0=A0=A0 Termina= tion is
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0 first created or
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0 returned to the null Context. The default contents of = the
      >=A0=A0=A0=A0=A0=A0 two
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0 exceptions are
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0 described in 7.1.5 and 7.1.7." 7.1.11 talks about=
      >=A0=A0=A0=A0=A0=A0 replace= ment
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0 SignalDescriptor
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0 which is effectively what happens when you return to t= he
      >=A0=A0=A0=A0=A0=A0 NULL
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0 context. The
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0 current descriptors are replaced by the provisioned
      >=A0=A0=A0=A0=A0=A0 descrip= tors.
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0 Also 7.1.11 is
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0 not mentioned as an exception.
      >=A0=A0=A0=A0=A0=A0=A0 >=
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0=A0 >
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0=A0 > My second question concerns the requirement th= at the
      >=A0=A0=A0=A0=A0=A0 MG main= tain
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0=A0 > terminations in contexts until the MGC explici= tly
      >=A0=A0=A0=A0=A0=A0 subtrac= ts them.
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0=A0 > Consider a distributed MG, in which the part t= hat
      >=A0=A0=A0=A0=A0=A0 talks t= o the
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0 MGC does
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0=A0 > not completely control the part that allocates=
      >=A0=A0=A0=A0=A0=A0 resourc= es such
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0 as IP
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0=A0 > address and UDP port for local descriptors.=A0= Suppose some
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0 administrative
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0=A0 > action or fault causes these resources to beco= me
      >=A0=A0=A0=A0=A0=A0 physica= lly
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0 unavailable
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0=A0 > to the termination with which they were associ= ated.
      >=A0=A0=A0=A0=A0=A0 The MG<= FONT FACE=3D"Arial">
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0 informs the
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0=A0 > MGC (or fails to do so if the MGC didn't reque= st the
      >=A0=A0=A0=A0=A0=A0 event),=
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0 but for
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0=A0 > some reason the MGC does not issue a Subtract.= =A0 The
      >=A0=A0=A0=A0=A0=A0 front e= nd
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0 of the MG
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0=A0 > has no problem complying with Megaco rules: it= will
      >=A0=A0=A0=A0=A0=A0 accept = any
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0 commands
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0=A0 > it can on that context, and send a proper reje= ction if
      >=A0=A0=A0=A0=A0=A0 the
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0 cleanup that
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0=A0 > has taken place in the back end makes it impos= sible to
      >=A0=A0=A0=A0=A0=A0 comply<= /FONT>
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0 with a
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0=A0 > request.=A0 However, if the MGC audits the loc= al
      >=A0=A0=A0=A0=A0=A0 descrip= tor, the
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0 MG front
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0=A0 > end will send an IP address and UDP port that = the back
      >=A0=A0=A0=A0=A0=A0 end may=
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0 already
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0=A0 > be reusing for another call.=A0 The MGC can th= en
      >=A0=A0=A0=A0=A0=A0 presuma= bly do
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0 bad things
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0=A0 > with this outdated information.=A0 Which of th= e
      >=A0=A0=A0=A0=A0=A0 followi= ng are
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0 legitimate
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0=A0 > solutions to this problem?
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0=A0 >
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0=A0 >=A0=A0=A0 1. The MGC is at fault for ignoring i= ndications
      >=A0=A0=A0=A0=A0=A0 from th= e MG
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0 that
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0=A0 >=A0=A0=A0=A0=A0=A0 something went wrong.=
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0=A0 >
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0=A0 >=A0=A0=A0 2. The MG is at fault for being schiz= ophrenic.=A0 It
      >=A0=A0=A0=A0=A0=A0 must
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0 prevent reuse
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0=A0 >=A0=A0=A0=A0=A0=A0 of all resources associated = with the context
      >=A0=A0=A0=A0=A0=A0 until i= t
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0 receives
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0=A0 >=A0=A0=A0=A0=A0=A0 Subtract.
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0=A0 >
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0=A0 >=A0=A0=A0 3. The MG can sidestep the problem.=A0= It is only
      >=A0=A0=A0=A0=A0=A0 require= d to
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0 keep the
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0=A0 >=A0=A0=A0=A0=A0=A0 termination in the context, = but it can clear the
      >=A0=A0=A0=A0=A0=A0 local
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0=A0 >=A0=A0=A0=A0=A0=A0 descriptor.=A0 (And what if = the MGC doesn't audit but
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0 relies on its
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0=A0 >=A0=A0=A0=A0=A0=A0 memory?)
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0=A0 >
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0=A0 >=A0=A0=A0 4. There is no problem.=A0 The MGC ca= nnot do anything
      >=A0=A0=A0=A0=A0=A0 bad wit= h
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0 the
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0=A0 >=A0=A0=A0=A0=A0=A0 information.
      >=A0=A0=A0=A0=A0=A0=A0 >=
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0 [CHG] I would suggest that if the MG has experienced a=
      >=A0=A0=A0=A0=A0=A0 problem=
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0 with the
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0 termination that it send a generic cause event indicat= ing
      >=A0=A0=A0=A0=A0=A0 failure= =2E
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0 It the MGC
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0 doesn't request this event then the designers must
      >=A0=A0=A0=A0=A0=A0 underst= and the
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0 consequences.
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0 Also if there is a more terminal failure a servicechan= ge
      >=A0=A0=A0=A0=A0=A0 could b= e
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0 sent.
      >=A0=A0=A0=A0=A0=A0=A0 >=
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0=A0 >
      >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0=A0 > Raphael Tryster >=A0=A0=A0=A0=A0=A0=A0 >= =A0=A0=A0=A0=A0=A0=A0 >
      >=20

------_=_NextPart_001_01C44F13.317E7300-- --===============1947851162== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============1947851162==-- From megaco-bounces@ietf.org Tue Jun 15 00:05:31 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04048 for ; Tue, 15 Jun 2004 00:05:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ba4qx-0002fD-W9; Mon, 14 Jun 2004 23:43:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ba4Qi-0005dy-0P for megaco@megatron.ietf.org; Mon, 14 Jun 2004 23:16: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 XAA28491 for ; Mon, 14 Jun 2004 23:16:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Ba4Qa-0005IG-UB for megaco@ietf.org; Mon, 14 Jun 2004 23:16:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ba47B-00029Q-00 for megaco@ietf.org; Mon, 14 Jun 2004 22:56:00 -0400 Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1Ba3gA-0006FR-00 for megaco@ietf.org; Mon, 14 Jun 2004 22:28:03 -0400 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i5F2RxWR023003 for ; Tue, 15 Jun 2004 04:27:59 +0200 (MEST) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 15 Jun 2004 04:28:30 +0200 Received: from eaubrnt019.epa.ericsson.se ([146.11.9.165]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id MA43S0NF; Tue, 15 Jun 2004 04:27:54 +0200 Received: from ericsson.com (EG2E500202DSEGL [146.11.22.2]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id LGSSB5NF; Tue, 15 Jun 2004 12:27:34 +1000 Message-ID: <40CE5EB8.4040301@ericsson.com> Date: Tue, 15 Jun 2004 12:28:08 +1000 X-Sybari-Trust: 735d2a5c 100f6658 f47d3ac5 00000138 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Raphael Tryster Subject: Re: [Megaco] Descriptor processing on Termination OOS References: <9A64A99CD3F2BD4582BE4FB63FC1F3816D0FCF@MAILSERVER> In-Reply-To: <9A64A99CD3F2BD4582BE4FB63FC1F3816D0FCF@MAILSERVER> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Jun 2004 02:28:30.0044 (UTC) FILETIME=[725151C0:01C45280] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cc: Tom-PT Taylor , anilj@cisco.com, megaco@ietf.org, bvswamy@hss.hns.com, "'Kevin Boyle'" X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org Content-Transfer-Encoding: 7bit Hello Raphael, It sounds to me that you are looking for a mechanism to maintain continuity of signals, events etc when Subtracting a termination back to the NULL context. The behaviour of properties, signals and events etc is to revert to default (unless otherwise provisioned) when going back to the NULL context. A mechanism to override this behaviour would be needed. I could see it taking the form a the capability of carrying local/remote/localcontrol/signals and events descriptors in Subtract in H.248.1v3. I'd still like to see some concrete examples before going down this route. Regards, Christian Raphael Tryster wrote: > OK, so perhaps VMWI is a bad example for Megaco (it's type OO in MGCP). > But there must be other OO signals that we wouldn't want to Move to a > context because they may take part in calls while the signal is on. The > sense I am getting is that OO signals are a feature that Megaco claims > to support but subverts its operation. > > Raphael Tryster > > -----Original Message----- > From: Kevin Boyle [SMTP:kboyle@nortelnetworks.com] > Sent: Thursday, 10 June 2004 18:44 > To: Raphael Tryster; 'Christian Groves' > Cc: bvswamy@hss.hns.com; anilj@cisco.com; Tom-PT Taylor; > megaco@ietf.org > Subject: RE: [Megaco] Descriptor processing on Termination OOS > > VMWI, generally speaking, is a CLASS data message that fires and > forgets. The switch even refreshes it from time to time. So, one > solution is to use andisp to send data without alerting to light > the lamp. > > > Kevin > > > _____ > > From: Raphael Tryster [mailto:raphael@tdsoft.com] > Sent: Thursday, June 10, 2004 2:04 AM > To: 'Christian Groves' > Cc: Boyle, Kevin [NCRTP:3Z40:EXCH]; bvswamy@hss.hns.com; > anilj@cisco.com; Taylor, Tom-PT [CAR:5N00:EXCH]; megaco@ietf.org > Subject: RE: [Megaco] Descriptor processing on Termination OOS > > Because this termination may wish to be part of many other > contexts while the signal persists, i.e. I can make many > calls while the light on my phone is on, before checking my > voice mail. > > Raphael Tryster > > > -----Original Message----- > From: Christian Groves [SMTP:christian.groves@ericsson.com] > Sent: Thursday, 10 June 2004 2:19 > To: Raphael Tryster > Cc: 'Kevin Boyle'; bvswamy@hss.hns.com; anilj@cisco.com; > Tom-PT Taylor; megaco@ietf.org > Subject: Re: [Megaco] Descriptor processing on > Termination OOS > > If you want VMWI to persist why don't you MOV a termination > to its own context? > > Christian > > Raphael Tryster wrote: > > > So there would be a discontinuity in the signal. Is that > what real MGCs > > do? > > > > Raphael Tryster > > > > > > -----Original Message----- > > From: Christian Groves > [SMTP:christian.groves@ericsson.com] > > Sent: Monday, 7 June 2004 2:10 > > To: Raphael Tryster > > Cc: 'Kevin Boyle'; bvswamy@hss.hns.com; > anilj@cisco.com; > > Tom-PT Taylor; megaco@ietf.org > > Subject: Re: [Megaco] Descriptor processing > on Termination OOS > > > > Hello Raphael, > > > > A signal's descriptor cannot be sent in a subtract > command. It > > would have to be > > modified in the NULL context. > > > > Regards, Christian > > > > Raphael Tryster wrote: > > > > > Hello Christian, > > > > > > I gather from your reply that in my first > question, 6.2.4 > > overrides > > > 7.1.11, and in my second question, it is the MGC's > > responsibility to > > > avoid inconsistencies. Does the former mean > that even off/on > > signals > > > terminate on subtraction from a context? > Therefore, if the MGC > > wants > > > something like VMWI to persist, it has to > re-issue it on every > > subtract? > > > > > > Raphael Tryster > > > > > > > > > -----Original Message----- > > > From: Christian Groves > > [SMTP:christian.groves@ericsson.com] > > > Sent: Friday, 28 May 2004 7:09 > > > To: Raphael Tryster > > > Cc: 'Kevin Boyle'; > bvswamy@hss.hns.com; anilj@cisco.com; > > > Tom-PT Taylor; megaco@ietf.org > > > Subject: Re: [Megaco] Descriptor > processing on > > Termination OOS > > > > > > Hello Raphael, > > > > > > Please see my comments below. > > > > > > Regards, Christian > > > > > > Raphael Tryster wrote: > > > > > > > Two questions related to the discussion > below: > > > > > > > > Firstly, the quote below from H.248.1 > 6.2.4 seems to > > contradict > > > section > > > > 7.1.11, which states: > > > > > > > > "Production of a Signal on a > Termination is stopped by > > > application of a > > > > new SignalsDescriptor, or detection of > an Event on the > > > Termination". > > > > > > > > What about returning to the null > context? According > > to 6.2.4, the > > > > signal should stop, whereas according > to 7.1.11, it > > should not > > > stop. > > > > Unless the resetting of descriptors to > default values > > when > > > returning to > > > > the null context is considered to be a > case of > > application of a > > > new > > > > SignalsDescriptor? But then what do we > do about > > on/off type > > > signals, > > > > e.g. visual message waiting indicator? > Surely they > > are meant > > > to survive > > > > subtraction from a context? > > > > > > [CHG] I would assume that by returning a > termination to > > the NULL > > > context via a > > > subtract results in a signal being > stopped. 6.2.4 says, > > "If not > > > provisioned > > > otherwise, the properties in all > descriptors except > > > TerminationState and > > > LocalControl default to empty/"no value" > when a > > Termination is > > > first created or > > > returned to the null Context. The default > contents of the > > two > > > exceptions are > > > described in 7.1.5 and 7.1.7." 7.1.11 > talks about > > replacement > > > SignalDescriptor > > > which is effectively what happens when you > return to the > > NULL > > > context. The > > > current descriptors are replaced by the > provisioned > > descriptors. > > > Also 7.1.11 is > > > not mentioned as an exception. > > > > > > > > > > > My second question concerns the > requirement that the > > MG maintain > > > > terminations in contexts until the MGC > explicitly > > subtracts them. > > > > Consider a distributed MG, in which the > part that > > talks to the > > > MGC does > > > > not completely control the part that > allocates > > resources such > > > as IP > > > > address and UDP port for local > descriptors. Suppose some > > > administrative > > > > action or fault causes these resources > to become > > physically > > > unavailable > > > > to the termination with which they were > associated. > > The MG > > > informs the > > > > MGC (or fails to do so if the MGC > didn't request the > > event), > > > but for > > > > some reason the MGC does not issue a > Subtract. The > > front end > > > of the MG > > > > has no problem complying with Megaco > rules: it will > > accept any > > > commands > > > > it can on that context, and send a > proper rejection if > > the > > > cleanup that > > > > has taken place in the back end makes > it impossible to > > comply > > > with a > > > > request. However, if the MGC audits > the local > > descriptor, the > > > MG front > > > > end will send an IP address and UDP > port that the back > > end may > > > already > > > > be reusing for another call. The MGC > can then > > presumably do > > > bad things > > > > with this outdated information. Which > of the > > following are > > > legitimate > > > > solutions to this problem? > > > > > > > > 1. The MGC is at fault for ignoring > indications > > from the MG > > > that > > > > something went wrong. > > > > > > > > 2. The MG is at fault for being > schizophrenic. It > > must > > > prevent reuse > > > > of all resources associated with > the context > > until it > > > receives > > > > Subtract. > > > > > > > > 3. The MG can sidestep the problem. > It is only > > required to > > > keep the > > > > termination in the context, but > it can clear the > > local > > > > descriptor. (And what if the MGC > doesn't audit but > > > relies on its > > > > memory?) > > > > > > > > 4. There is no problem. The MGC > cannot do anything > > bad with > > > the > > > > information. > > > > > > [CHG] I would suggest that if the MG has > experienced a > > problem > > > with the > > > termination that it send a generic cause > event indicating > > failure. > > > It the MGC > > > doesn't request this event then the > designers must > > understand the > > > consequences. > > > Also if there is a more terminal failure a > servicechange > > could be > > > sent. > > > > > > > > > > > Raphael Tryster > > > > > > > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Thu Jun 17 07:34:32 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20471 for ; Thu, 17 Jun 2004 07:34:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bav4e-0006Fa-QR; Thu, 17 Jun 2004 07:28:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bauxh-00040K-1q for megaco@megatron.ietf.org; Thu, 17 Jun 2004 07:21: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 HAA19759 for ; Thu, 17 Jun 2004 07:21:40 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bauxg-0003zg-FD for megaco@ietf.org; Thu, 17 Jun 2004 07:21:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bauwo-0003e6-00 for megaco@ietf.org; Thu, 17 Jun 2004 07:20:46 -0400 Received: from eins.siemens.at ([193.81.246.11]) by ietf-mx with esmtp (Exim 4.12) id 1Bauvu-0003B9-00 for megaco@ietf.org; Thu, 17 Jun 2004 07:19:50 -0400 Received: from vies1kbx.sie.siemens.at (forix [10.1.140.2]) by eins.siemens.at (8.12.9/8.12.8) with ESMTP id i5HBJJEP028700 for ; Thu, 17 Jun 2004 13:19:19 +0200 Received: from vies194a.sie.siemens.at (vies1kbx [158.226.135.174]) by vies1kbx.sie.siemens.at (8.12.10/8.12.1) with ESMTP id i5HBJJgP006865 for ; Thu, 17 Jun 2004 13:19:19 +0200 Received: by vies194a.sie.siemens.at with Internet Mail Service (5.5.2653.19) id ; Thu, 17 Jun 2004 13:20:56 +0200 Message-ID: From: Kalleitner Franz To: "'megaco@ietf.org'" Date: Thu, 17 Jun 2004 13:20:53 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Megaco] telephony event defintion X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org Hello megaco-list members, I didn't manage to transfer the media description of the telephone-event (defined in RFC 2833) as a media attribute into ASN.1 format. In SDP its easily done via a dynamically payload type definition, plus fmtp,rtpmap for the codec definition Using ASN.1 encoding the payload attribute is defined in H248.1 Annex C. However, an reference pointing to the codec definition is not available, therefore I scanned ITU-T and 3GPP references, but I didn't found any definition for the telephone-event. Probably another had the same problem, with more success than I'm and may send a reply to this threat. Many thanks in advance! Franz _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Thu Jun 17 14:01:49 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28799 for ; Thu, 17 Jun 2004 14:01:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bb0lJ-0004Dh-Ho; Thu, 17 Jun 2004 13:33:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BazxC-0006ns-Qk for megaco@megatron.ietf.org; Thu, 17 Jun 2004 12:41:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18310 for ; Thu, 17 Jun 2004 12:41:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BazxB-0003NV-Fs for megaco@ietf.org; Thu, 17 Jun 2004 12:41:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bazoq-0001Rg-00 for megaco@ietf.org; Thu, 17 Jun 2004 12:32:53 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Bazfs-0006xQ-00 for megaco@ietf.org; Thu, 17 Jun 2004 12:23:37 -0400 Received: from mail.tdsoft.com ([212.143.64.34] helo=TdSoft.eSafe.com) by mx2.foretec.com with smtp (Exim 4.24) id 1BazCY-0008JJ-OO for megaco@ietf.org; Thu, 17 Jun 2004 11:53:20 -0400 Received: from mailserver.td-soft.co.il ([IP=172.16.1.203]) by eSafe SMTP Relay 1087401936; Thu Jun 17 18:54:36 2004 Received: by MAILSERVER with Internet Mail Service (5.5.2657.72) id ; Thu, 17 Jun 2004 18:52:10 +0200 Message-ID: <9A64A99CD3F2BD4582BE4FB63FC1F3816D101D@MAILSERVER> From: Raphael Tryster To: "'megaco@ietf.org'" Subject: RE: [Megaco] Descriptor processing on Termination OOS Date: Thu, 17 Jun 2004 18:51:11 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-eSafe-inspection-result: Mail clean X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE autolearn=no version=2.60 X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0175150509==" Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org 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. --===============0175150509== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4548B.4B817860" 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_01C4548B.4B817860 Content-Type: text/plain; charset="iso-8859-1" Hello Christian, Looking at the OO type signals in MGCP, I can't see any others that one would want to persist past subtraction from a context. So I'll just accept the idea that the OO signal in MGCP has no exact equivalent in Megaco, and that OO and TO signals in Megaco are the same in that both stop on an event or subtract or new signals descriptor, the only difference being that TO signals also stop on timeout. Raphael Tryster -----Original Message----- From: Christian Groves [SMTP:christian.groves@ericsson.com] Sent: Tuesday, 15 June 2004 4:28 To: Raphael Tryster Cc: 'Kevin Boyle'; bvswamy@hss.hns.com; anilj@cisco.com; Tom-PT Taylor; megaco@ietf.org Subject: Re: [Megaco] Descriptor processing on Termination OOS Hello Raphael, It sounds to me that you are looking for a mechanism to maintain continuity of signals, events etc when Subtracting a termination back to the NULL context. The behaviour of properties, signals and events etc is to revert to default (unless otherwise provisioned) when going back to the NULL context. A mechanism to override this behaviour would be needed. I could see it taking the form a the capability of carrying local/remote/localcontrol/signals and events descriptors in Subtract in H.248.1v3. I'd still like to see some concrete examples before going down this route. Regards, Christian Raphael Tryster wrote: > OK, so perhaps VMWI is a bad example for Megaco (it's type OO in MGCP). > But there must be other OO signals that we wouldn't want to Move to a > context because they may take part in calls while the signal is on. The > sense I am getting is that OO signals are a feature that Megaco claims > to support but subverts its operation. > > Raphael Tryster > > -----Original Message----- > From: Kevin Boyle [SMTP:kboyle@nortelnetworks.com] > Sent: Thursday, 10 June 2004 18:44 > To: Raphael Tryster; 'Christian Groves' > Cc: bvswamy@hss.hns.com; anilj@cisco.com; Tom-PT Taylor; > megaco@ietf.org > Subject: RE: [Megaco] Descriptor processing on Termination OOS > > VMWI, generally speaking, is a CLASS data message that fires and > forgets. The switch even refreshes it from time to time. So, one > solution is to use andisp to send data without alerting to light > the lamp. > > > Kevin > Clipped the rest of the thread because it's too long. ------_=_NextPart_001_01C4548B.4B817860 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Megaco] Descriptor processing on Termination OOS

    Hello Christian,

    Looking at the OO type signals in MGCP, = I can't see any others that one would want to persist past subtraction fr= om a context.  So I'll just accept the idea that the OO signal in MG= CP has no exact equivalent in Megaco, and that OO and TO signals in Megac= o are the same in that both stop on an event or subtract or new signals d= escriptor, the only difference being that TO signals also stop on timeout= =2E

    Raphael Tryster

      -----Original Message-----
      From:   Christian Groves [= SMTP:christian.groves@ericsson.com]
      Sent:   Tuesday, 15 June 2004 4:28
      To:     Raphael Tryster
      Cc:     'Kevin Boyle'; bvswamy@hss.hns.com; anil= j@cisco.com; Tom-PT Taylor; megaco@ietf.org
      Subject:    &nbs= p;   Re: [Megaco] Desc= riptor processing on Termination OOS

      Hello Raphael,

      It sounds to me that you are looki= ng for a mechanism to maintain continuity of
      signals, events etc when Subtract= ing a termination back to the NULL context. The
      behaviour of properties, signals = and events etc is to revert to default (unless
      otherwise provisioned) when going= back to the NULL context. A mechanism to
      override this behaviour would be = needed. I could see it taking the form a the
      capability of carrying local/remo= te/localcontrol/signals and events descriptors
      in Subtract in H.248.1v3. I'd sti= ll like to see some concrete examples before
      going down this route.

      Regards, Christian

      Raphael Tryster wrote:

      > OK, so perhaps VMWI is a bad = example for Megaco (it's type OO in MGCP). 
      > But there must be other OO s= ignals that we wouldn't want to Move to a
      > context because they may tak= e part in calls while the signal is on.  The
      > sense I am getting is that O= O signals are a feature that Megaco claims
      > to support but subverts its = operation.
      >
      > Raphael Tryster
      >
      >     = ;  -----Original Message-----
      >     = ;  From:   Kevin Boyle [SMTP:kboyle@nortelnetworks.com]
      >     = ;  Sent:   Thursday, 10 June 2004 18:44
      >     = ;  To:     Raphael Tryster; 'Christian Groves'
      >     = ;  Cc:     bvswamy@hss.hns.com; anilj@cisco.com;= Tom-PT Taylor;
      >     = ;  megaco@ietf.org
      >     = ;  Subject:        RE: [Megaco] D= escriptor processing on Termination OOS
      >
      >     = ;  VMWI, generally speaking, is a CLASS data message that fires and<= /FONT>
      >     = ;  forgets.  The switch even refreshes it from time to time.&nb= sp; So, one
      >     = ;  solution is to use andisp to send data without alerting to light<= /FONT>
      >     = ;  the lamp.
      >
      >     = ;  
      >     = ;  Kevin
      >

      Clipped the rest of the thread = because it's too long.

------_=_NextPart_001_01C4548B.4B817860-- --===============0175150509== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============0175150509==-- From megaco-bounces@ietf.org Mon Jun 21 15:26:09 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19756 for ; Mon, 21 Jun 2004 15:26:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BcUMO-0007jR-KP; Mon, 21 Jun 2004 15:21:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BcSN6-0002lA-7c for megaco@megatron.ietf.org; Mon, 21 Jun 2004 13:14:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06480 for ; Mon, 21 Jun 2004 13:14:15 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BcSN5-00062b-8B for megaco@ietf.org; Mon, 21 Jun 2004 13:14:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BcS4w-0002oL-00 for megaco@ietf.org; Mon, 21 Jun 2004 12:55:31 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1BcRVK-0006D0-00 for megaco@ietf.org; Mon, 21 Jun 2004 12:18:42 -0400 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id i5LGJEJe009072 for ; Mon, 21 Jun 2004 09:19:14 -0700 (MST) Received: from smilevm.motorola.com ([10.14.25.162]) by il06exr03.mot.com (Motorola/il06exr03) with ESMTP id i5LGIY77016260 for ; Mon, 21 Jun 2004 11:18:35 -0500 Message-Id: <5.2.1.1.0.20040621100135.045e8828@IL06EXM13.corp.mot.com> X-Sender: A19776@IL06EXM13.corp.mot.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Mon, 21 Jun 2004 12:13:38 -0400 To: megaco@ietf.org From: Aleksandr Ryabin Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Megaco] H.248.29 ICASC addr sc1/sc2 and cprs X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org Hi, Looking through ICASC package I've noticed that in both signals and events "Calling Subscriber Category 1" (and 2) and "Called Party Reachability Status" are missing mapping for "spare" digits as defined by Q.441 in "Group II forward digits" and "Group B backward signals" respectively. In some R2 variants these spare digits might be mapped/remapped and otherwise used. Can the editor please add the other values similar to the way addr disc defines "other" language digits? Thanks Aleks _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Tue Jun 22 09:23:01 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07592 for ; Tue, 22 Jun 2004 09:23:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bcknd-00024q-Q7; Tue, 22 Jun 2004 08:54:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BcenU-00071d-I4 for megaco@megatron.ietf.org; Tue, 22 Jun 2004 02:30:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10376 for ; Tue, 22 Jun 2004 02:30:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BcenR-0006eO-Td for megaco@ietf.org; Tue, 22 Jun 2004 02:30:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BcemL-0006Br-00 for megaco@ietf.org; Tue, 22 Jun 2004 02:29:10 -0400 Received: from eins.siemens.at ([193.81.246.11]) by ietf-mx with esmtp (Exim 4.12) id 1BcelP-0005b0-00 for megaco@ietf.org; Tue, 22 Jun 2004 02:28:11 -0400 Received: from vies1kbx.sie.siemens.at (forix [10.1.140.2]) by eins.siemens.at (8.12.9/8.12.8) with ESMTP id i5M6RgEP015704 for ; Tue, 22 Jun 2004 08:27:42 +0200 Received: from vies141a.sie.siemens.at (vies1kbx [158.226.135.174]) by vies1kbx.sie.siemens.at (8.12.10/8.12.1) with ESMTP id i5M6RegP016450 for ; Tue, 22 Jun 2004 08:27:41 +0200 Received: by vies141a.sie.siemens.at with Internet Mail Service (5.5.2653.19) id ; Tue, 22 Jun 2004 08:29:18 +0200 Message-ID: From: Kalleitner Franz To: "'megaco@ietf.org'" Subject: AW: [Megaco] telephony event defintion Date: Tue, 22 Jun 2004 08:29:16 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Cc: BELLING THOMAS X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org Content-Transfer-Encoding: quoted-printable I wonder if anybody could respond on that threat! Without a codepoint for DTMF, the functionality of RFC2833 cannot be = applied for=20 network configuration specifing DTMF as an ACodec i.e for codec = negosiation purposes! A solution for text encoded H248 is available but not for binary. Many thanks in advance Franz -----Urspr=FCngliche Nachricht----- Von: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org]Im Auftrag von Kalleitner Franz Gesendet: Donnerstag, 17. Juni 2004 13:21 An: 'megaco@ietf.org' Betreff: [Megaco] telephony event defintion Hello megaco-list members, I didn't manage to transfer the media description of the = telephone-event (defined in RFC 2833) as a media attribute into ASN.1 format. In SDP its easily done via a dynamically payload type definition, plus fmtp,rtpmap for the codec definition Using ASN.1 encoding the payload attribute is defined in H248.1 Annex = C. However, an reference pointing to the codec definition is not = available, therefore I scanned ITU-T and 3GPP references, but I didn't found any definition for the telephone-event. Probably another had the same problem, with more success than I'm and = may send a reply to this threat. Many thanks in advance! Franz _______________________________________________ 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-bounces@ietf.org Tue Jun 22 19:04:30 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07433 for ; Tue, 22 Jun 2004 19:04:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BctmL-0007dA-Tn; Tue, 22 Jun 2004 18:30:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bcpob-00061n-S9 for megaco@megatron.ietf.org; Tue, 22 Jun 2004 14:16: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 OAA11170 for ; Tue, 22 Jun 2004 14:16:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bcpoa-00079K-P4 for megaco@ietf.org; Tue, 22 Jun 2004 14:16:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bcp9d-0007lM-00 for megaco@ietf.org; Tue, 22 Jun 2004 13:33:53 -0400 Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx with esmtp (Exim 4.12) id 1Bcnll-0001iQ-00 for megaco@ietf.org; Tue, 22 Jun 2004 12:05:09 -0400 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id i5MG58Wr025334 for ; Tue, 22 Jun 2004 09:05:08 -0700 (MST) Received: from smilevm.motorola.com ([10.14.25.162]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id i5MG3dGx023518 for ; Tue, 22 Jun 2004 11:03:40 -0500 Message-Id: <5.2.1.1.0.20040622114309.0476bd50@IL06EXM13.corp.mot.com> X-Sender: A19776@IL06EXM13.corp.mot.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Tue, 22 Jun 2004 12:03:38 -0400 To: megaco@ietf.org From: Aleksandr Ryabin Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Megaco] Which error to use for errors in Topology descriptor? X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org Hi, Which error should be used to report errors detected within TopologyDescriptor? If there are none yet, can one be added to H.248.8? Thanks Aleks _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Tue Jun 22 22:52:20 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26163 for ; Tue, 22 Jun 2004 22:52:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bcxph-0002sr-IK; Tue, 22 Jun 2004 22:49:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BcVIu-00062s-Fy for megaco@megatron.ietf.org; Mon, 21 Jun 2004 16:22: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 QAA25194 for ; Mon, 21 Jun 2004 16:22:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BcVIt-0005Mx-81 for megaco@ietf.org; Mon, 21 Jun 2004 16:22:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BcVI0-00055x-00 for megaco@ietf.org; Mon, 21 Jun 2004 16:21:12 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BcVHL-0004n1-00 for megaco@ietf.org; Mon, 21 Jun 2004 16:20:31 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 21 Jun 2004 13:22:05 -0700 Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i5LKJx72017602 for ; Mon, 21 Jun 2004 13:19:59 -0700 (PDT) Received: from cisco.com (dhcp-171-71-9-171.cisco.com [171.71.9.171]) by mira-sjc5-a.cisco.com (MOS 3.4.5-GR) with ESMTP id ARR32541; Mon, 21 Jun 2004 13:19:28 -0700 (PDT) Message-ID: <40D74324.9080508@cisco.com> Date: Mon, 21 Jun 2004 13:20:52 -0700 From: Steve Yeung Organization: Cisco Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7 X-Accept-Language: en-us, en MIME-Version: 1.0 To: megaco@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.7 required=5.0 tests=AWL, DEAR_SOMETHING, HTML_20_30, HTML_MESSAGE,HTML_TAG_EXISTS_TBODY,HTML_TITLE_EMPTY autolearn=no version=2.60 X-Mailman-Approved-At: Tue, 22 Jun 2004 22:48:04 -0400 Subject: [Megaco] [Fwd: Question on signal/event behaviour] X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0316584429==" Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org --===============0316584429== Content-Type: multipart/alternative; boundary="------------030101050200050802060207" --------------030101050200050802060207 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Dear Sir/Madam: I am resending this email. Would you please check to see whether anyone can help me on this? Thank you very much! -------- Original Message -------- Subject: Question on signal/event behaviour Date: Mon, 24 May 2004 12:36:05 -0700 From: Steve Yeung Organization: Cisco Systems To: megaco@ietf.org CC: Steve Yeung Dear Sir/Madam: I want to confirm the following behaviour on Megaco (H.248). The following sequence of operation does not use the KeepActive option. When we have 2 sequences of commands going to MG as follow: 1. event: g/sc signal: cg/dt, duration=60 seconds, notifycompletion = timeout, intbyevent, intbysigdesc, otherreason 2. after 10 seconds 3. event: g/sc signal: cg/bt, duration= 60 seconds, notifycompletion=timeout, intbyevent, intbysigdesc, otherreason Behaviour 1: After received the 2nd signal (i.e. cg/bt), the MG wll sent notify with reason SD, then in a few millisecond, the MG will sent notify with reason EV to MGC. The 2nd signal did not play (or played for a few millisecond only). Behaviour 2: After received the 2nd signal (i.e. cg/bt), MG will sent notify with reason SD, then the 2nd signal will play for 60 seconds. After the 2nd signal timeout, the MG will sent notify with reason TO to MGC. My question is which behaviour is correct? Thank you very much! -- Steve Yeung Software Engineer 408-853-4214 -- Steve Yeung Software Engineer 408-853-4214 --------------030101050200050802060207 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Dear Sir/Madam:

       I am resending this email.  Would you please check to see whether
anyone can help me on this?  Thank you very much!


-------- Original Message --------
Subject: Question on signal/event behaviour
Date: Mon, 24 May 2004 12:36:05 -0700
From: Steve Yeung <skyeung@cisco.com>
Organization: Cisco Systems
To: megaco@ietf.org
CC: Steve Yeung <skyeung@cisco.com> 


Dear Sir/Madam:

       I want to confirm the following behaviour on Megaco (H.248).  The 
following
sequence of operation does not use the KeepActive option.

        When we have 2 sequences of commands going to MG as follow:

1.   event:  g/sc
     signal:  cg/dt, duration=60 seconds, notifycompletion = timeout,
     intbyevent, intbysigdesc, otherreason
2.   after 10 seconds
3.   event:  g/sc
     signal:  cg/bt, duration= 60 seconds, notifycompletion=timeout, 
     intbyevent, intbysigdesc, otherreason

Behaviour 1:
     After received the 2nd signal (i.e. cg/bt), the MG wll sent notify 
     with reason SD, then in a few millisecond, the MG will sent
     notify with reason EV to MGC.  The 2nd signal did not play (or
     played for a few millisecond only).

Behaviour 2:
     After received the 2nd signal (i.e. cg/bt), MG will sent notify 
     with reason SD, then the 2nd signal will play for 60 seconds.
     After the 2nd signal timeout, the MG will sent notify with
     reason TO to MGC.

My question is which behaviour is correct?
Thank you very much!

-- 
Steve Yeung
Software Engineer
408-853-4214





-- 
Steve Yeung
Software Engineer
408-853-4214
--------------030101050200050802060207-- --===============0316584429== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============0316584429==-- From megaco-bounces@ietf.org Thu Jun 24 13:31:08 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02821 for ; Thu, 24 Jun 2004 13:31:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdXJQ-0001ff-Io; Thu, 24 Jun 2004 12:42:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bd3FO-0001OL-Nj for megaco@megatron.ietf.org; Wed, 23 Jun 2004 04:36: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 EAA07377 for ; Wed, 23 Jun 2004 04:36:44 -0400 (EDT) From: prateek.pawar@wipro.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bd3FM-0000Wt-A0 for megaco@ietf.org; Wed, 23 Jun 2004 04:36:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bd3Dd-0007PN-00 for megaco@ietf.org; Wed, 23 Jun 2004 04:34:58 -0400 Received: from wiproecmx1.wipro.com ([164.164.31.5]) by ietf-mx with esmtp (Exim 4.12) id 1Bd3Ay-0006IV-00; Wed, 23 Jun 2004 04:32:13 -0400 Received: from ec-vwall-wd (ec-vwall-wd.wipro.com [10.200.52.125]) by wiproecmx1.wipro.com (8.12.9-20031013/8.12.9) with SMTP id i5N8Vdxx016164; Wed, 23 Jun 2004 14:01:39 +0530 (IST) Received: from blr-ec-bh3.wipro.com ([10.200.50.93]) by ec-vwall-wd with InterScan Messaging Security Suite; Wed, 23 Jun 2004 14:01:38 +0530 Received: from del-ggn-msg.wipro.com ([10.105.50.99]) by blr-ec-bh3.wipro.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 23 Jun 2004 14:01:37 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 23 Jun 2004 14:01:36 +0530 Message-ID: <21C055AE9430084FBBAA04093C7FE57492904F@del-ggn-msg.wipro.com> Thread-Topic: Welcome to the "Megaco" mailing list Thread-Index: AcRY9ZG1T2UBnvOkRQSpBLJGhpFfuwABxiAg To: Cc: X-OriginalArrivalTime: 23 Jun 2004 08:31:37.0358 (UTC) FILETIME=[7FDF9AE0:01C458FC] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL, NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [Megaco] RE: Welcome to the "Megaco" mailing list X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org Content-Transfer-Encoding: quoted-printable -----Original Message----- From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org]On Behalf Of megaco-request@ietf.org Sent: Wednesday, June 23, 2004 1:09 PM To: Prateek Pawar (WT01 - TELECOM & INTER-NETWORKING SOLUTIONS) Subject: Welcome to the "Megaco" mailing list Welcome to the Megaco@ietf.org mailing list! To post to this list, send your email to: megaco@ietf.org General information about the mailing list is at: https://www1.ietf.org/mailman/listinfo/megaco ********************************************************************** Note Well Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, 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=20 working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. *************************************************************************= ****** If you ever want to unsubscribe or change your options (eg, switch to or from digest mode, change your password, etc.), visit your subscription page at: https://www1.ietf.org/mailman/options/megaco/prateek.pawar%40wipro.com You can also make such adjustments via email by sending a message to: Megaco-request@ietf.org with the word `help' in the subject or body (don't include the quotes), and you will get back a message with instructions. You must know your password to change your options (including changing the password, itself) or to unsubscribe. It is: raji5gr8 Normally, Mailman will remind you of your ietf.org mailing list passwords once every month, although you can disable this if you prefer. This reminder will also include instructions on how to unsubscribe or change your account options. There is also a button on your options page that will email your current password to you. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Thu Jun 24 13:42:15 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04576 for ; Thu, 24 Jun 2004 13:42:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdXKW-00024O-6P; Thu, 24 Jun 2004 12:44:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bd8ys-0005Gv-5T for megaco@megatron.ietf.org; Wed, 23 Jun 2004 10:44: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 KAA03874 for ; Wed, 23 Jun 2004 10:44:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bd8yq-0004ZZ-Ih for megaco@ietf.org; Wed, 23 Jun 2004 10:44:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bd8dM-0001Uf-00 for megaco@ietf.org; Wed, 23 Jun 2004 10:21:53 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Bd8ZY-00005Z-00 for megaco@ietf.org; Wed, 23 Jun 2004 10:17:56 -0400 Received: from zcars04e.nortelnetworks.com ([47.129.242.56]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Bd8LQ-0001kB-DT for megaco@ietf.org; Wed, 23 Jun 2004 10:03:20 -0400 Received: from zcard303.ca.nortel.com (zcard303.ca.nortel.com [47.129.242.59]) by zcars04e.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i5NDwWt19383; Wed, 23 Jun 2004 09:58:32 -0400 (EDT) Received: from [47.130.17.100] (acart231.ca.nortel.com [47.130.17.100]) by zcard303.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NALS0J9D; Wed, 23 Jun 2004 09:58:33 -0400 Message-ID: <40D98C87.2070109@nortelnetworks.com> Date: Wed, 23 Jun 2004 09:58:31 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Steve Yeung Subject: Re: [Megaco] [Fwd: Question on signal/event behaviour] References: <40D74324.9080508@cisco.com> In-Reply-To: <40D74324.9080508@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,DEAR_SOMETHING autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cc: megaco@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org Content-Transfer-Encoding: 7bit Behaviour 2 is the one that makes sense, in that it is more likely the desired behaviour. Let's see if we can reason our way to it. The sequence of operations when the new transaction arrives is this: 1) The new Events Descriptor is recognized and installed. 2) The new Signals Descriptor is recognized. 3) This recognition terminates the old signal. 4) The end of the old signal triggers a Signal Completion event. 5) The new Signals Descriptor is installed. So basically you don't start playing the new signal until you clean up all the business associated with the old one. If everyone agrees with that principle, you have your answer. One other thought occurred to me in reading your question: what if g/sc had been absent from the new Events Descriptor? In that case, I believe, based on the sequence of operations above, that no event would be reported. Steve Yeung wrote: > Dear Sir/Madam: > > I am resending this email. Would you please check to see whether > anyone can help me on this? Thank you very much! > > > -------- Original Message -------- > Subject: Question on signal/event behaviour > Date: Mon, 24 May 2004 12:36:05 -0700 > From: Steve Yeung > Organization: Cisco Systems > To: megaco@ietf.org > CC: Steve Yeung > > > > Dear Sir/Madam: > > I want to confirm the following behaviour on Megaco (H.248). The > following > sequence of operation does not use the KeepActive option. > > When we have 2 sequences of commands going to MG as follow: > > 1. event: g/sc > signal: cg/dt, duration=60 seconds, notifycompletion = timeout, > intbyevent, intbysigdesc, otherreason > 2. after 10 seconds > 3. event: g/sc > signal: cg/bt, duration= 60 seconds, notifycompletion=timeout, > intbyevent, intbysigdesc, otherreason > > Behaviour 1: > After received the 2nd signal (i.e. cg/bt), the MG wll sent notify > with reason SD, then in a few millisecond, the MG will sent > notify with reason EV to MGC. The 2nd signal did not play (or > played for a few millisecond only). > > Behaviour 2: > After received the 2nd signal (i.e. cg/bt), MG will sent notify > with reason SD, then the 2nd signal will play for 60 seconds. > After the 2nd signal timeout, the MG will sent notify with > reason TO to MGC. > > My question is which behaviour is correct? > Thank you very much! > > -- > Steve Yeung > Software Engineer > 408-853-4214 > > > > > > -- > Steve Yeung > Software Engineer > 408-853-4214 > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Thu Jun 24 15:09:10 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14529 for ; Thu, 24 Jun 2004 15:09:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdXPE-0003Ou-Dp; Thu, 24 Jun 2004 12:48:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdEi1-0001dq-PL for megaco@megatron.ietf.org; Wed, 23 Jun 2004 16:51: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 QAA16562 for ; Wed, 23 Jun 2004 16:51:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdEhz-0003OX-Bk for megaco@ietf.org; Wed, 23 Jun 2004 16:51:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdEh8-00031a-00 for megaco@ietf.org; Wed, 23 Jun 2004 16:50:11 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1BdEgT-0002bp-00 for megaco@ietf.org; Wed, 23 Jun 2004 16:49:29 -0400 Received: from zcard303.ca.nortel.com (zcard303.ca.nortel.com [47.129.242.59]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i5NKmnV21523; Wed, 23 Jun 2004 16:48:49 -0400 (EDT) Received: from [47.130.17.100] (acart231.ca.nortel.com [47.130.17.100]) by zcard303.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NALS0M74; Wed, 23 Jun 2004 16:48:49 -0400 Message-ID: <40D9ECB0.2070203@nortelnetworks.com> Date: Wed, 23 Jun 2004 16:48:48 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Steve Yeung Subject: Re: [Megaco] [Fwd: Question on signal/event behaviour] References: <40D9D688.2000609@cisco.com> In-Reply-To: <40D9D688.2000609@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.9 required=5.0 tests=AWL,DEAR_SOMETHING autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cc: megaco@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org Content-Transfer-Encoding: 7bit You are right: if no Events Descriptor is specified, the one previously in force continues to apply. Steve Yeung wrote: > Hi Tom: > > Thank you very much for your help! > I just want to confirm the last item you mentioned. When the > 2nd event descriptor is > missing, then the 2nd signal descriptor received, should the MG still > send the notify with TO > after the 2nd signal completed? > > I am thinking the the 1st event descriptor of g/sc should > continue to exist. What do you > think? Thanks! > > > Tom Taylor wrote: > > > Behaviour 2 is the one that makes sense, in that it is more likely the > > desired behaviour. Let's see if we can reason our way to it. > > > > The sequence of operations when the new transaction arrives is this: > > > > 1) The new Events Descriptor is recognized and installed. > > > > 2) The new Signals Descriptor is recognized. > > > > 3) This recognition terminates the old signal. > > > > 4) The end of the old signal triggers a Signal Completion event. > > > > 5) The new Signals Descriptor is installed. > > > > So basically you don't start playing the new signal until you clean up > > all the business associated with the old one. > > > > If everyone agrees with that principle, you have your answer. > > > > One other thought occurred to me in reading your question: what if > > g/sc had been absent from the new Events Descriptor? In that case, I > > believe, based on the sequence of operations above, that no event > > would be reported. > > > > Steve Yeung wrote: > > > >> Dear Sir/Madam: > >> > >> I am resending this email. Would you please check to see > whether > >> anyone can help me on this? Thank you very much! > >> > >> > >> -------- Original Message -------- > >> Subject: Question on signal/event behaviour > >> Date: Mon, 24 May 2004 12:36:05 -0700 > >> From: Steve Yeung > >> Organization: Cisco Systems > >> To: megaco@ietf.org > >> CC: Steve Yeung > >> > >> > >> > >> Dear Sir/Madam: > >> > >> I want to confirm the following behaviour on Megaco (H.248). > >> The following > >> sequence of operation does not use the KeepActive option. > >> > >> When we have 2 sequences of commands going to MG as follow: > >> > >> 1. event: g/sc > >> signal: cg/dt, duration=60 seconds, notifycompletion = timeout, > >> intbyevent, intbysigdesc, otherreason > >> 2. after 10 seconds > >> 3. event: g/sc > >> signal: cg/bt, duration= 60 seconds, notifycompletion=timeout, > >> intbyevent, intbysigdesc, otherreason > >> > >> Behaviour 1: > >> After received the 2nd signal (i.e. cg/bt), the MG wll sent > >> notify with reason SD, then in a few millisecond, the MG will sent > >> notify with reason EV to MGC. The 2nd signal did not play (or > >> played for a few millisecond only). > >> > >> Behaviour 2: > >> After received the 2nd signal (i.e. cg/bt), MG will sent notify > >> with reason SD, then the 2nd signal will play for 60 seconds. > >> After the 2nd signal timeout, the MG will sent notify with > >> reason TO to MGC. > >> > >> My question is which behaviour is correct? > >> Thank you very much! > >> > >> -- > >> Steve Yeung > >> Software Engineer > >> 408-853-4214 > >> > >> > >> > >> > >> > >> -- > >> Steve Yeung > >> Software Engineer > >> 408-853-4214 > >> > > > > -- > Steve Yeung > Software Engineer > 408-853-4214 > > > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Thu Jun 24 15:41:03 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19779 for ; Thu, 24 Jun 2004 15:41:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdXPw-0003di-9d; Thu, 24 Jun 2004 12:49:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdGYB-00024y-7E for megaco@megatron.ietf.org; Wed, 23 Jun 2004 18:49: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 SAA25421 for ; Wed, 23 Jun 2004 18:48:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdGY9-0001vo-BQ for megaco@ietf.org; Wed, 23 Jun 2004 18:49:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdGXC-0001Z7-00 for megaco@ietf.org; Wed, 23 Jun 2004 18:48:02 -0400 Received: from [202.188.224.18] (helo=icemail8.ao.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 1BdGWK-0000qK-00 for megaco@ietf.org; Wed, 23 Jun 2004 18:47:08 -0400 Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by icemail8.ao.ericsson.se (8.12.10/8.12.9) with ESMTP id i5NMmjHW077844; Thu, 24 Jun 2004 06:48:46 +0800 (MYT) (envelope-from christian.groves@ericsson.com) Received: from ericsson.com (EG2E500202DSEGL [146.11.22.79]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id N1L0TMPC; Thu, 24 Jun 2004 08:45:41 +1000 Message-ID: <40DA0848.2010901@ericsson.com> Date: Thu, 24 Jun 2004 08:46:32 +1000 X-Sybari-Trust: c1654783 100f6658 d932ccc5 00000138 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Steve Yeung Subject: Re: [Megaco] [Fwd: Question on signal/event behaviour] References: <40D74324.9080508@cisco.com> In-Reply-To: <40D74324.9080508@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,DEAR_SOMETHING autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cc: megaco@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org Content-Transfer-Encoding: 7bit Hello Steve, The second behaviour is correct the 2nd signal plays for 60 seconds. Regards, Christian Steve Yeung wrote: > Dear Sir/Madam: > > I am resending this email. Would you please check to see whether > anyone can help me on this? Thank you very much! > > > -------- Original Message -------- > Subject: Question on signal/event behaviour > Date: Mon, 24 May 2004 12:36:05 -0700 > From: Steve Yeung > Organization: Cisco Systems > To: megaco@ietf.org > CC: Steve Yeung > > > > Dear Sir/Madam: > > I want to confirm the following behaviour on Megaco (H.248). The > following > sequence of operation does not use the KeepActive option. > > When we have 2 sequences of commands going to MG as follow: > > 1. event: g/sc > signal: cg/dt, duration=60 seconds, notifycompletion = timeout, > intbyevent, intbysigdesc, otherreason > 2. after 10 seconds > 3. event: g/sc > signal: cg/bt, duration= 60 seconds, notifycompletion=timeout, > intbyevent, intbysigdesc, otherreason > > Behaviour 1: > After received the 2nd signal (i.e. cg/bt), the MG wll sent notify > with reason SD, then in a few millisecond, the MG will sent > notify with reason EV to MGC. The 2nd signal did not play (or > played for a few millisecond only). > > Behaviour 2: > After received the 2nd signal (i.e. cg/bt), MG will sent notify > with reason SD, then the 2nd signal will play for 60 seconds. > After the 2nd signal timeout, the MG will sent notify with > reason TO to MGC. > > My question is which behaviour is correct? > Thank you very much! > > -- > Steve Yeung > Software Engineer > 408-853-4214 > > > > > > -- > Steve Yeung > Software Engineer > 408-853-4214 > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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-bounces@ietf.org Thu Jun 24 15:42:01 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19939 for ; Thu, 24 Jun 2004 15:42:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdXPx-0003dt-J9; Thu, 24 Jun 2004 12:49:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdGsW-0004Lk-3x for megaco@megatron.ietf.org; Wed, 23 Jun 2004 19:10: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 TAA26074 for ; Wed, 23 Jun 2004 19:10:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdGsT-0001pd-V2 for megaco@ietf.org; Wed, 23 Jun 2004 19:10:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdGrd-0001Rm-00 for megaco@ietf.org; Wed, 23 Jun 2004 19:09:10 -0400 Received: from [202.188.224.18] (helo=icemail8.ao.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 1BdGqn-0000jg-00 for megaco@ietf.org; Wed, 23 Jun 2004 19:08:17 -0400 Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by icemail8.ao.ericsson.se (8.12.10/8.12.9) with ESMTP id i5NNAlHW078627; Thu, 24 Jun 2004 07:10:48 +0800 (MYT) (envelope-from christian.groves@ericsson.com) Received: from ericsson.com (EG2E500202DSEGL [146.11.22.79]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id N1L0TMZC; Thu, 24 Jun 2004 09:07:44 +1000 Message-ID: <40DA0D74.5040405@ericsson.com> Date: Thu, 24 Jun 2004 09:08:36 +1000 X-Sybari-Trust: ad8bc81e 100f6658 d932ccc5 00000138 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aleksandr Ryabin Subject: Re: [Megaco] Which error to use for errors in Topology descriptor? References: <5.2.1.1.0.20040622114309.0476bd50@IL06EXM13.corp.mot.com> In-Reply-To: <5.2.1.1.0.20040622114309.0476bd50@IL06EXM13.corp.mot.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cc: megaco@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org Content-Transfer-Encoding: 7bit Hello Aleksandr, What sort of error were you thinking about? If there's something wrong with the syntax then this can be covered with 422 syntax error in action. Invalid termination/stream ID can be covered by other errors. Is the error something like "invalid topology" where the MG can't connect terminations according to the MGC's wishes? Regards, Christian Aleksandr Ryabin wrote: > Hi, > > Which error should be used to report errors detected within > TopologyDescriptor? > If there are none yet, can one be added to H.248.8? > > 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-bounces@ietf.org Thu Jun 24 15:42:32 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19980 for ; Thu, 24 Jun 2004 15:42:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdXPy-0003e3-DG; Thu, 24 Jun 2004 12:49:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdHA2-0006II-Fv for megaco@megatron.ietf.org; Wed, 23 Jun 2004 19:28:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27044 for ; Wed, 23 Jun 2004 19:28:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdHA0-0000tz-F2 for megaco@ietf.org; Wed, 23 Jun 2004 19:28:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdH91-0000Wh-00 for megaco@ietf.org; Wed, 23 Jun 2004 19:27:08 -0400 Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx with esmtp (Exim 4.12) id 1BdH8K-00008O-00 for megaco@ietf.org; Wed, 23 Jun 2004 19:26:24 -0400 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id i5NNQNXa019237; Wed, 23 Jun 2004 16:26:23 -0700 (MST) Received: from smilevm.motorola.com ([10.14.25.162]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id i5NNQAsw026066; Wed, 23 Jun 2004 18:26:10 -0500 Message-Id: <5.2.1.1.0.20040623192010.045dda90@IL06EXM13.corp.mot.com> X-Sender: A19776@IL06EXM13.corp.mot.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Wed, 23 Jun 2004 19:23:55 -0400 To: Christian Groves, From: Aleksandr Ryabin Subject: Re: [Megaco] Which error to use for errors in Topology descriptor? In-Reply-To: <40DA0D74.5040405@ericsson.com> References: <5.2.1.1.0.20040622114309.0476bd50@IL06EXM13.corp.mot.com> <5.2.1.1.0.20040622114309.0476bd50@IL06EXM13.corp.mot.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL autolearn=no version=2.60 X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org Hi Christian, Yes, exactly, "invalid topology" or something like "could not apply topology" Regards, Aleks At 07:08 PM 6/23/2004, Christian Groves wrote: >Hello Aleksandr, > >What sort of error were you thinking about? > >If there's something wrong with the syntax then this can be covered with >422 syntax error in action. Invalid termination/stream ID can be covered >by other errors. > >Is the error something like "invalid topology" where the MG can't connect >terminations according to the MGC's wishes? > >Regards, Christian > >Aleksandr Ryabin wrote: > >>Hi, >>Which error should be used to report errors detected within >>TopologyDescriptor? >>If there are none yet, can one be added to H.248.8? >>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-bounces@ietf.org Thu Jun 24 15:53:22 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21511 for ; Thu, 24 Jun 2004 15:53:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdXQc-00040e-89; Thu, 24 Jun 2004 12:50:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdL67-0003qJ-9T for megaco@megatron.ietf.org; Wed, 23 Jun 2004 23:40: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 XAA13651 for ; Wed, 23 Jun 2004 23:40:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdL65-0000H9-1R for megaco@ietf.org; Wed, 23 Jun 2004 23:40:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdL59-0007hG-00 for megaco@ietf.org; Wed, 23 Jun 2004 23:39:24 -0400 Received: from [202.188.224.18] (helo=icemail8.ao.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 1BdL4b-0007I7-00 for megaco@ietf.org; Wed, 23 Jun 2004 23:38:49 -0400 Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by icemail8.ao.ericsson.se (8.12.10/8.12.9) with ESMTP id i5O3euHW003888; Thu, 24 Jun 2004 11:40:57 +0800 (MYT) (envelope-from christian.groves@ericsson.com) Received: from ericsson.com (EG2E500202DSEGL [146.11.22.79]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id N1L0TRQC; Thu, 24 Jun 2004 13:37:53 +1000 Message-ID: <40DA4CC5.2080005@ericsson.com> Date: Thu, 24 Jun 2004 13:38:45 +1000 X-Sybari-Trust: ac5088fc 100f6658 d932ccc5 00000138 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aleksandr Ryabin Subject: Re: [Megaco] Which error to use for errors in Topology descriptor? References: <5.2.1.1.0.20040622114309.0476bd50@IL06EXM13.corp.mot.com> <5.2.1.1.0.20040622114309.0476bd50@IL06EXM13.corp.mot.com> <5.2.1.1.0.20040623192010.045dda90@IL06EXM13.corp.mot.com> In-Reply-To: <5.2.1.1.0.20040623192010.045dda90@IL06EXM13.corp.mot.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cc: megaco@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org Content-Transfer-Encoding: 7bit Hello Aleksandr, Sounds like a reasonable thing to add. Christian Aleksandr Ryabin wrote: > Hi Christian, > > Yes, exactly, "invalid topology" or something like "could not apply > topology" > > Regards, > Aleks > > At 07:08 PM 6/23/2004, Christian Groves wrote: > >> Hello Aleksandr, >> >> What sort of error were you thinking about? >> >> If there's something wrong with the syntax then this can be covered >> with 422 syntax error in action. Invalid termination/stream ID can be >> covered by other errors. >> >> Is the error something like "invalid topology" where the MG can't >> connect terminations according to the MGC's wishes? >> >> Regards, Christian >> >> Aleksandr Ryabin wrote: >> >>> Hi, >>> Which error should be used to report errors detected within >>> TopologyDescriptor? >>> If there are none yet, can one be added to H.248.8? >>> 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-bounces@ietf.org Thu Jun 24 16:20:03 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25133 for ; Thu, 24 Jun 2004 16:20:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdXUB-000529-1E; Thu, 24 Jun 2004 12:54:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdUDa-0006VI-4L for megaco@megatron.ietf.org; Thu, 24 Jun 2004 09:24: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 JAA10766 for ; Thu, 24 Jun 2004 09:24:40 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdUDZ-00008q-FF for megaco@ietf.org; Thu, 24 Jun 2004 09:24:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdUCW-0007YI-00 for megaco@ietf.org; Thu, 24 Jun 2004 09:23:36 -0400 Received: from iproxy2.ericsson.dk ([213.159.160.69]) by ietf-mx with esmtp (Exim 4.12) id 1BdUBZ-0006lw-00 for megaco@ietf.org; Thu, 24 Jun 2004 09:22:37 -0400 Received: from unixmail.ted.dk.eu.ericsson.se (knud.ted.dk.eu.ericsson.se [213.159.188.246]) by iproxy2.ericsson.dk (8.12.9/8.12.9) with ESMTP id i5ODKM37021625 for ; Thu, 24 Jun 2004 15:20:28 +0200 (CEST) Received: from ericsson.com (inb.ted.dk.eu.ericsson.se [213.159.189.57]) by unixmail.ted.dk.eu.ericsson.se (8.10.1/8.10.1/TEDmain-1.0) with ESMTP id i5ODLme06626 for ; Thu, 24 Jun 2004 15:21:50 +0200 (MEST) Message-ID: <40DAD56C.ECA4565C@ericsson.com> Date: Thu, 24 Jun 2004 15:21:48 +0200 From: Inger Bohlbro X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.7-10 i686) X-Accept-Language: en MIME-Version: 1.0 To: megaco@ietf.org Subject: [Megaco] MID used to identify sender Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi I have a question regarding the Message Identifier (MID). H.248.1 states "A H.248.1 entity (MG/MGC) must consistently use the same MID in all messages it originates for the duration of control association with the peer (MGC/MG)". Is it allowed for a MG to use the MID to check if the message is received from the MGC with which contol association is obtained, i.e. compare MID in received messages with the MID received in the ServiceChange response ? This could be especially relevant when running over UDP, in order to discard messages received from "old" associations. It could also be relevant during a failover situation to be able to distinguish between messages from an "old" MGC and messages from the MGC at which a ServiceChange request is outstanding. Requests received from the "new" MGC should be answered with error code 505 if received before the ServiceChange response. However, in draft-ietf-megaco-callflows-03.txt there is an example in section 3.1.1 where the MID used in ServiceChange response is [216.33.33.61]:2944 and in all following messages it is [216.33.33.61]:25000. The ServiceChange response contains the ServiceChangeAddress = 25000 parameter, but never the less the two MID's are not identical. Regards Inger Bohlbro -- Inger Bohlbro System Developer, M. Sc. Ericsson Telebit A/S phone: +45 89 38 52 65 Skanderborgvej 232 fax: +45 89 38 51 01 DK-8260 Viby J, Denmark e-mail: inger.bohlbro@ericsson.com _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Thu Jun 24 16:23:16 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25829 for ; Thu, 24 Jun 2004 16:23:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdXUR-00055F-1t; Thu, 24 Jun 2004 12:54:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdUop-0003Uq-A6 for megaco@megatron.ietf.org; Thu, 24 Jun 2004 10:03: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 KAA13756 for ; Thu, 24 Jun 2004 10:03:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdUon-0006d7-Sz for megaco@ietf.org; Thu, 24 Jun 2004 10:03:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdUmU-0005nI-00 for megaco@ietf.org; Thu, 24 Jun 2004 10:00:47 -0400 Received: from eins.siemens.at ([193.81.246.11]) by ietf-mx with esmtp (Exim 4.12) id 1BdUl1-00059P-00 for megaco@ietf.org; Thu, 24 Jun 2004 09:59:15 -0400 Received: from vies1k7x.sie.siemens.at (forix [10.1.140.2]) by eins.siemens.at (8.12.9/8.12.8) with ESMTP id i5ODwiEP019187 for ; Thu, 24 Jun 2004 15:58:44 +0200 Received: from vies141a.sie.siemens.at (vies1kbx.sie.siemens.at [158.226.135.174]) by vies1k7x.sie.siemens.at (8.12.10/8.12.1) with ESMTP id i5ODwfaC003853 for ; Thu, 24 Jun 2004 15:58:44 +0200 Received: by vies141a.sie.siemens.at with Internet Mail Service (5.5.2653.19) id ; Thu, 24 Jun 2004 16:00:18 +0200 Message-ID: From: Kalleitner Franz To: "'megaco@ietf.org'" Date: Thu, 24 Jun 2004 16:00:16 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Megaco] How to correlate payload types with codeclists X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org Has anybody an idea how to map codec lists and payload types into the localdescriptor using ASN.1 encoding? Lets take the example below, using a SDP m-line with two payload types and lets assume ReserveValue=True, which mean that both codes shall be reserved by the MGW As a reference an cut-out of a well-known SDP media definition: m=audio 5555 RTP/AVP 96 97 a= rtpmap:96 AMR a= fmtp:96 <> a= rtpmap 97 AMR-WB a= fmtp:97 <> In the following three examples I tried to map the SDP example into the ASN.1 format, but it allows a wide range of interpretation. Example 1: localDescriptor { propGrps (1){ PropertyParm (1){ Name (Acodec) Value (AMR,AMR-WB)}, PropertyParm (2){ Name (PayloadType) Value (96) } PropertyParm (3){ Name (PayloadType) Value (97) }}} Since ACodec is defined as "sequence of octects" (Annex C) and because ITU-T has defined ACodec as a list of single codecs its possible to build a codec list. Therefore ReserveValue will work; if ReserveValue=True, both codecs "AMR" and AMR-WB" are selected codecs, and if ReserveValue=False only the first codec "AMR" would be selected. But, how to map the payload types 96 and 97 to the codecs in the codec list ? Payload type is defind in Annex C as integer, therefore only single value could be set, but not a list. A solution could be to list the payload types as a sequence of propertyparm and assume that the first codec in the list is associated with the first payload type definition. Example 2 localDescriptor { propGrps (1){ PropertyParm (1){ Name (Acodec) Value (AMR)}, PropertyParm (2){ Name (PayloadType) Value (96) } PropertyParm (3){ Name (ACodec) Value (AMR-WB) }}} PropertyParm (4){ Name (PayloadType) Value (97) }}} An alternative solution of example 1, working with single codecs instead of a codec list. Again it must be assumed that the codec is associated with the payload definition coming next. Example 3: localDescriptor { propGrps (1){ PropertyParm (1){ Name (Acodec) Value (AMR)}, PropertyParm (2){ Name (PayloadType) Value (96)} propGrps (2){ PropertyParm (1){ Name (Acodec) Value (AMR-WB)}, PropertyParm (2){ Name (PayloadType) Value (97) }}} Witin this example the correlation between codec and payload type can be expressed unique. However, the H248 ReserveValue = True cannot be applied because two property groups are used. It would be necessary to use ReserveGroup instead. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Thu Jun 24 16:24:41 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26090 for ; Thu, 24 Jun 2004 16:24:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdXUV-00056a-05; Thu, 24 Jun 2004 12:54:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdUw3-0005aQ-KZ for megaco@megatron.ietf.org; Thu, 24 Jun 2004 10:10: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 KAA15193 for ; Thu, 24 Jun 2004 10:10:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdUw2-00026I-CN for megaco@ietf.org; Thu, 24 Jun 2004 10:10:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdUv3-0001i8-00 for megaco@ietf.org; Thu, 24 Jun 2004 10:09:37 -0400 Received: from motgate.mot.com ([129.188.136.100]) by ietf-mx with esmtp (Exim 4.12) id 1BdUu1-0001DM-00 for megaco@ietf.org; Thu, 24 Jun 2004 10:08:33 -0400 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate.mot.com (Motorola/Motgate) with ESMTP id i5OE8VD7024561; Thu, 24 Jun 2004 07:08:31 -0700 (MST) Received: from smilevm.motorola.com ([10.14.25.162]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id i5OE8Gsw029680; Thu, 24 Jun 2004 09:08:17 -0500 Message-Id: <5.2.1.1.0.20040624100246.01cc4630@IL06EXM13.corp.mot.com> X-Sender: A19776@IL06EXM13.corp.mot.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Thu, 24 Jun 2004 10:07:03 -0400 To: Christian Groves, From: Aleksandr Ryabin Subject: Re: [Megaco] Which error to use for errors in Topology descriptor? In-Reply-To: <40DA4CC5.2080005@ericsson.com> References: <5.2.1.1.0.20040623192010.045dda90@IL06EXM13.corp.mot.com> <5.2.1.1.0.20040622114309.0476bd50@IL06EXM13.corp.mot.com> <5.2.1.1.0.20040622114309.0476bd50@IL06EXM13.corp.mot.com> <5.2.1.1.0.20040623192010.045dda90@IL06EXM13.corp.mot.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL autolearn=no version=2.60 X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org Hi Christinan, Can we agree on the error code number now and the document this is to added? Can the editor of the appropriate document (i.e. IG, or H.248.8 update) please assign the number? Thanks Aleks At 11:38 PM 6/23/2004, Christian Groves wrote: >Hello Aleksandr, > >Sounds like a reasonable thing to add. > >Christian > >Aleksandr Ryabin wrote: > >>Hi Christian, >>Yes, exactly, "invalid topology" or something like "could not apply topology" >>Regards, >> Aleks >>At 07:08 PM 6/23/2004, Christian Groves wrote: >> >>>Hello Aleksandr, >>> >>>What sort of error were you thinking about? >>> >>>If there's something wrong with the syntax then this can be covered with >>>422 syntax error in action. Invalid termination/stream ID can be covered >>>by other errors. >>> >>>Is the error something like "invalid topology" where the MG can't >>>connect terminations according to the MGC's wishes? >>> >>>Regards, Christian >>> >>>Aleksandr Ryabin wrote: >>> >>>>Hi, >>>>Which error should be used to report errors detected within >>>>TopologyDescriptor? >>>>If there are none yet, can one be added to H.248.8? >>>>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-bounces@ietf.org Thu Jun 24 16:56:44 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08488 for ; Thu, 24 Jun 2004 16:56:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdZ1E-0008Hw-9L; Thu, 24 Jun 2004 14:32:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdDDy-0006mg-Gs for megaco@megatron.ietf.org; Wed, 23 Jun 2004 15:15: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 PAA07560 for ; Wed, 23 Jun 2004 15:15:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdDDw-0004fb-UL for megaco@ietf.org; Wed, 23 Jun 2004 15:15:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdDD2-0004Ek-00 for megaco@ietf.org; Wed, 23 Jun 2004 15:15:00 -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 1BdDBx-0003RX-00 for megaco@ietf.org; Wed, 23 Jun 2004 15:13:53 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 23 Jun 2004 12:16:54 +0000 X-BrightmailFiltered: true Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i5NJDL4N029781; Wed, 23 Jun 2004 12:13:21 -0700 (PDT) Received: from cisco.com (dhcp-171-71-9-171.cisco.com [171.71.9.171]) by mira-sjc5-a.cisco.com (MOS 3.4.5-GR) with ESMTP id ART13556; Wed, 23 Jun 2004 12:12:51 -0700 (PDT) Message-ID: <40D9D688.2000609@cisco.com> Date: Wed, 23 Jun 2004 12:14:16 -0700 From: Steve Yeung Organization: Cisco Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom Taylor Subject: Re: [Megaco] [Fwd: Question on signal/event behaviour] References: <40D74324.9080508@cisco.com> <40D98C87.2070109@nortelnetworks.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.4 required=5.0 tests=AWL,DEAR_SOMETHING autolearn=no version=2.60 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 24 Jun 2004 14:32:15 -0400 Cc: Steve Yeung , megaco@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi Tom: Thank you very much for your help! I just want to confirm the last item you mentioned. When the 2nd event descriptor is missing, then the 2nd signal descriptor received, should the MG still send the notify with TO after the 2nd signal completed? I am thinking the the 1st event descriptor of g/sc should continue to exist. What do you think? Thanks! Tom Taylor wrote: > Behaviour 2 is the one that makes sense, in that it is more likely the > desired behaviour. Let's see if we can reason our way to it. > > The sequence of operations when the new transaction arrives is this: > > 1) The new Events Descriptor is recognized and installed. > > 2) The new Signals Descriptor is recognized. > > 3) This recognition terminates the old signal. > > 4) The end of the old signal triggers a Signal Completion event. > > 5) The new Signals Descriptor is installed. > > So basically you don't start playing the new signal until you clean up > all the business associated with the old one. > > If everyone agrees with that principle, you have your answer. > > One other thought occurred to me in reading your question: what if > g/sc had been absent from the new Events Descriptor? In that case, I > believe, based on the sequence of operations above, that no event > would be reported. > > Steve Yeung wrote: > >> Dear Sir/Madam: >> >> I am resending this email. Would you please check to see whether >> anyone can help me on this? Thank you very much! >> >> >> -------- Original Message -------- >> Subject: Question on signal/event behaviour >> Date: Mon, 24 May 2004 12:36:05 -0700 >> From: Steve Yeung >> Organization: Cisco Systems >> To: megaco@ietf.org >> CC: Steve Yeung >> >> >> >> Dear Sir/Madam: >> >> I want to confirm the following behaviour on Megaco (H.248). >> The following >> sequence of operation does not use the KeepActive option. >> >> When we have 2 sequences of commands going to MG as follow: >> >> 1. event: g/sc >> signal: cg/dt, duration=60 seconds, notifycompletion = timeout, >> intbyevent, intbysigdesc, otherreason >> 2. after 10 seconds >> 3. event: g/sc >> signal: cg/bt, duration= 60 seconds, notifycompletion=timeout, >> intbyevent, intbysigdesc, otherreason >> >> Behaviour 1: >> After received the 2nd signal (i.e. cg/bt), the MG wll sent >> notify with reason SD, then in a few millisecond, the MG will sent >> notify with reason EV to MGC. The 2nd signal did not play (or >> played for a few millisecond only). >> >> Behaviour 2: >> After received the 2nd signal (i.e. cg/bt), MG will sent notify >> with reason SD, then the 2nd signal will play for 60 seconds. >> After the 2nd signal timeout, the MG will sent notify with >> reason TO to MGC. >> >> My question is which behaviour is correct? >> Thank you very much! >> >> -- >> Steve Yeung >> Software Engineer >> 408-853-4214 >> >> >> >> >> >> -- >> Steve Yeung >> Software Engineer >> 408-853-4214 >> > -- Steve Yeung Software Engineer 408-853-4214 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Fri Jun 25 00:18:20 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20454 for ; Fri, 25 Jun 2004 00:18:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bdi03-0000JO-Gq; Fri, 25 Jun 2004 00:07:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdhvB-0006Gf-Dv for megaco@megatron.ietf.org; Fri, 25 Jun 2004 00:02: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 AAA19890 for ; Fri, 25 Jun 2004 00:02:34 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bdhv9-0005WE-Be for megaco@ietf.org; Fri, 25 Jun 2004 00:02:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bdhtf-00053T-00 for megaco@ietf.org; Fri, 25 Jun 2004 00:01:04 -0400 Received: from [202.188.224.18] (helo=icemail8.ao.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 1BdhsL-0004Fg-00 for megaco@ietf.org; Thu, 24 Jun 2004 23:59:41 -0400 Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by icemail8.ao.ericsson.se (8.12.10/8.12.9) with ESMTP id i5P42AHW004998; Fri, 25 Jun 2004 12:02:11 +0800 (MYT) (envelope-from christian.groves@ericsson.com) Received: from ericsson.com (EG2E500202DSEGL [146.11.22.79]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id N1L04HX9; Fri, 25 Jun 2004 13:59:08 +1000 Message-ID: <40DB8B10.60000@ericsson.com> Date: Fri, 25 Jun 2004 12:16:48 +1000 X-Sybari-Trust: 43ce86a3 100f6658 d932ccc5 00000138 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kalleitner Franz Subject: Re: AW: [Megaco] telephony event defintion References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by icemail8.ao.ericsson.se id i5P42AHW004998 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Cc: BELLING THOMAS , "'megaco@ietf.org'" X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hello Franz, For BICC networks (where the Acodec is defined in Q.765.5) sending DTMF a= s per=20 RFC2833 is not needed across Q.1950(H.248). The actual SDP parameters use= d for=20 the connection are transmitted via IPBCP (Q.1970). There is a parameter in H.248.1 annex C 0x100F "Payload Type" that may be= of=20 some use. Regards, Christian Kalleitner Franz wrote: > I wonder if anybody could respond on that threat! > Without a codepoint for DTMF, the functionality of RFC2833 cannot be ap= plied > for=20 > network configuration specifing DTMF as an ACodec i.e for codec negosia= tion > purposes! > A solution for text encoded H248 is available but not for binary. >=20 > Many thanks in advance > Franz >=20 > -----Urspr=FCngliche Nachricht----- > Von: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org]Im Auftrag > von Kalleitner Franz > Gesendet: Donnerstag, 17. Juni 2004 13:21 > An: 'megaco@ietf.org' > Betreff: [Megaco] telephony event defintion >=20 >=20 > Hello megaco-list members, >=20 > I didn't manage to transfer the media description of the telephone-even= t > (defined in RFC 2833) as a media attribute into ASN.1 format. > In SDP its easily done via a dynamically payload type definition, plus > fmtp,rtpmap for the codec definition > Using ASN.1 encoding the payload attribute is defined in H248.1 Annex C. > However, an reference pointing to the codec definition is not available= , > therefore I scanned ITU-T and 3GPP references, but I didn't found any > definition for the telephone-event. >=20 > Probably another had the same problem, with more success than I'm and m= ay > send a reply to this threat. > Many thanks in advance! >=20 > Franz >=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 >=20 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Fri Jun 25 00:20:17 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20531 for ; Fri, 25 Jun 2004 00:20:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bdi04-0000Jh-3r; Fri, 25 Jun 2004 00:07:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdhvB-0006Gh-Qx for megaco@megatron.ietf.org; Fri, 25 Jun 2004 00:02: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 AAA19894 for ; Fri, 25 Jun 2004 00:02:34 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdhvA-0005WK-2l for megaco@ietf.org; Fri, 25 Jun 2004 00:02:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bdhtg-00053n-00 for megaco@ietf.org; Fri, 25 Jun 2004 00:01:06 -0400 Received: from [202.188.224.18] (helo=icemail8.ao.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 1BdhsL-0004Fh-00 for megaco@ietf.org; Thu, 24 Jun 2004 23:59:42 -0400 Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by icemail8.ao.ericsson.se (8.12.10/8.12.9) with ESMTP id i5P42CHW005004; Fri, 25 Jun 2004 12:02:13 +0800 (MYT) (envelope-from christian.groves@ericsson.com) Received: from ericsson.com (EG2E500202DSEGL [146.11.22.79]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id N1L04HYA; Fri, 25 Jun 2004 13:59:09 +1000 Message-ID: <40DB8D43.7050408@ericsson.com> Date: Fri, 25 Jun 2004 12:26:11 +1000 X-Sybari-Trust: 6eab2d4f 100f6658 d932ccc5 00000138 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kalleitner Franz Subject: Re: [Megaco] How to correlate payload types with codeclists References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cc: "'megaco@ietf.org'" X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org Content-Transfer-Encoding: 7bit Hello Franz, Acodec refers (check Q.1950 sect 5.7.3.1) to the "single codec" in Q.765.5 sect 11.1.7 so you can't use sect 11.1.6 for a list of codecs. So if you want a list of codecs you must use reserve value or reserve group as appropriate or the MG will "choose" a value for you. As part of the Acodec there is a configuration field which is effectively the same as the fmtp=. As per my other email in BICC the specific SDP information is exchanged via IPBCP and payloadtype is defined in H.248.1 Annex C. Regards, Christian Kalleitner Franz wrote: > Has anybody an idea how to map codec lists and payload types into the > localdescriptor using ASN.1 encoding? > Lets take the example below, using a SDP m-line with two payload types and > lets assume ReserveValue=True, which mean that both codes shall be reserved > by the MGW > > As a reference an cut-out of a well-known SDP media definition: > > m=audio 5555 RTP/AVP 96 97 > a= rtpmap:96 AMR > a= fmtp:96 <> > a= rtpmap 97 AMR-WB > a= fmtp:97 <> > > In the following three examples I tried to map the SDP example into the > ASN.1 format, but it allows a wide range of interpretation. > > Example 1: > localDescriptor { > propGrps (1){ > PropertyParm (1){ > Name (Acodec) > Value (AMR,AMR-WB)}, > PropertyParm (2){ > Name (PayloadType) > Value (96) } > PropertyParm (3){ > Name (PayloadType) > Value (97) }}} > > Since ACodec is defined as "sequence of octects" (Annex C) and because ITU-T > has defined ACodec as a list of single codecs its possible to build a codec > list. Therefore ReserveValue will work; if ReserveValue=True, both codecs > "AMR" and AMR-WB" are selected codecs, and if ReserveValue=False only the > first codec "AMR" would be selected. > But, how to map the payload types 96 and 97 to the codecs in the codec list > ? Payload type is defind in Annex C as integer, therefore only single value > could be set, but not a list. > A solution could be to list the payload types as a sequence of propertyparm > and assume that the first codec in the list is associated with the first > payload type definition. > > Example 2 > > localDescriptor { > propGrps (1){ > PropertyParm (1){ > Name (Acodec) > Value (AMR)}, > PropertyParm (2){ > Name (PayloadType) > Value (96) } > PropertyParm (3){ > Name (ACodec) > Value (AMR-WB) }}} > PropertyParm (4){ > Name (PayloadType) > Value (97) }}} > > An alternative solution of example 1, working with single codecs instead of > a codec list. Again it must be assumed that the codec is associated with the > payload definition coming next. > > Example 3: > > localDescriptor { > propGrps (1){ > PropertyParm (1){ > Name (Acodec) > Value (AMR)}, > PropertyParm (2){ > Name (PayloadType) > Value (96)} > propGrps (2){ > PropertyParm (1){ > Name (Acodec) > Value (AMR-WB)}, > PropertyParm (2){ > Name (PayloadType) > Value (97) }}} > > Witin this example the correlation between codec and payload type can be > expressed unique. However, the H248 ReserveValue = True cannot be applied > because two property groups are used. It would be necessary to use > ReserveGroup instead. > > > > > > _______________________________________________ > 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-bounces@ietf.org Fri Jun 25 00:25:14 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20854 for ; Fri, 25 Jun 2004 00:25:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bdi04-0000Jo-Jy; Fri, 25 Jun 2004 00:07:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdhvC-0006Gj-L3 for megaco@megatron.ietf.org; Fri, 25 Jun 2004 00:02: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 AAA19899 for ; Fri, 25 Jun 2004 00:02:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdhvA-0005WP-LK for megaco@ietf.org; Fri, 25 Jun 2004 00:02:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bdhti-00053w-00 for megaco@ietf.org; Fri, 25 Jun 2004 00:01:08 -0400 Received: from [202.188.224.18] (helo=icemail8.ao.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 1BdhsO-0004Fj-00 for megaco@ietf.org; Thu, 24 Jun 2004 23:59:45 -0400 Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by icemail8.ao.ericsson.se (8.12.10/8.12.9) with ESMTP id i5P42FHW005014 for ; Fri, 25 Jun 2004 12:02:16 +0800 (MYT) (envelope-from christian.groves@ericsson.com) Received: from ericsson.com (EG2E500202DSEGL [146.11.22.79]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id N1L04HYF; Fri, 25 Jun 2004 13:59:13 +1000 Message-ID: <40DB8EF4.8000104@ericsson.com> Date: Fri, 25 Jun 2004 12:33:24 +1000 X-Sybari-Trust: 1f9078c5 100f6658 d932ccc5 00000138 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Inger Bohlbro Subject: Re: [Megaco] MID used to identify sender References: <40DAD56C.ECA4565C@ericsson.com> In-Reply-To: <40DAD56C.ECA4565C@ericsson.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cc: megaco@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org Content-Transfer-Encoding: 7bit Hello Inger, Where there are differences between the Call Flows and the H.248.1 recommendation, H.248.1 takes precedence. A note for everyone: DO NOT BASE AN IMPLEMENTATION on the draft. These flows have quite a few errors and misassumptions and do not represent a definitive guide to the use of H.248.1. Regards, Christian Inger Bohlbro wrote: > Hi > > I have a question regarding the Message Identifier (MID). > > H.248.1 states > "A H.248.1 entity (MG/MGC) must consistently use the same MID > in all messages it originates for the duration of control > association with the peer (MGC/MG)". > > Is it allowed for a MG to use the MID to check if the message > is received from the MGC with which contol association is > obtained, i.e. compare MID in received messages with the > MID received in the ServiceChange response ? > > This could be especially relevant when running over UDP, in > order to discard messages received from "old" associations. > > It could also be relevant during a failover situation > to be able to distinguish between messages from an "old" > MGC and messages from the MGC at which a ServiceChange request > is outstanding. Requests received from the "new" MGC should > be answered with error code 505 if received before the > ServiceChange response. > > However, in draft-ietf-megaco-callflows-03.txt there is an > example in section 3.1.1 where the MID used in ServiceChange > response is [216.33.33.61]:2944 and in all following messages > it is [216.33.33.61]:25000. The ServiceChange response contains > the ServiceChangeAddress = 25000 parameter, but never the less > the two MID's are not identical. > > > Regards > Inger Bohlbro > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Fri Jun 25 04:16:08 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15977 for ; Fri, 25 Jun 2004 04:16:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdlcG-0007i1-7V; Fri, 25 Jun 2004 03:59:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bdlb4-0006rG-HY for megaco@megatron.ietf.org; Fri, 25 Jun 2004 03:58: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 DAA15362 for ; Fri, 25 Jun 2004 03:58:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bdlb2-0001me-8t for megaco@ietf.org; Fri, 25 Jun 2004 03:58:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdlaF-0001Tm-00 for megaco@ietf.org; Fri, 25 Jun 2004 03:57:16 -0400 Received: from eins.siemens.at ([193.81.246.11]) by ietf-mx with esmtp (Exim 4.12) id 1BdlZZ-00017O-00 for megaco@ietf.org; Fri, 25 Jun 2004 03:56:33 -0400 Received: from vies1k7x.sie.siemens.at (forix [10.1.140.2]) by eins.siemens.at (8.12.9/8.12.8) with ESMTP id i5P7u4EP029448 for ; Fri, 25 Jun 2004 09:56:04 +0200 Received: from vies194a.sie.siemens.at (vies1kbx.sie.siemens.at [158.226.135.174]) by vies1k7x.sie.siemens.at (8.12.10/8.12.1) with ESMTP id i5P7u3aC024747 for ; Fri, 25 Jun 2004 09:56:04 +0200 Received: by vies194a.sie.siemens.at with Internet Mail Service (5.5.2653.19) id ; Fri, 25 Jun 2004 09:57:41 +0200 Message-ID: From: Kalleitner Franz To: "'Christian Groves '" , Kalleitner Franz Subject: AW: AW: [Megaco] telephony event defintion Date: Fri, 25 Jun 2004 09:57:36 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Sybari-Trust: 43ce86a3 100f6658 d932ccc5 00000138 X-Accept-Language: 43ce86a3 100f6658 d932ccc5 00000138 In-Reply-To: 43ce86a3 100f6658 d932ccc5 00000138 X-MIME-Autoconverted: 43ce86a3 100f6658 d932ccc5 00000138 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Cc: BELLING THOMAS , "''megaco@ietf.org' '" X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hello Christian, thanks a lot for you answer. You are right, for BICC networks its possible to use the tunneling = solution. However, we need to find a solution to manage the interworking between = SIP and ISUP networks Q.1912.5 or RFC3398 as well the 3GPP 29.163, = specifying a SIP-BICC interworking as well. As you proposed, for the BICC interface we want to use the methods = defined in Q1950 and Q765.5 but its not possible to use them for the SIP = interface. SIP doesn't offer any tunneling in a similar way. Nevertheless its = necessary to configure an IP termination connected to a SIP network via H248.=20 So that's the background, why I'm asking these questions concerning = DTMF codec and codeclists, because we want to reuse h248 basics as much as possible to implement the interworking between SIP and ISUP/BICC = networks. Do you think there is a chance to solve these two items within H248 standardization? kind regards Franz -----Originalnachricht----- Von: Christian Groves An: Kalleitner Franz Cc: 'megaco@ietf.org'; BELLING THOMAS Gesendet: 25.06.04 04:16 Betreff: Re: AW: [Megaco] telephony event defintion Hello Franz, For BICC networks (where the Acodec is defined in Q.765.5) sending DTMF as per=20 RFC2833 is not needed across Q.1950(H.248). The actual SDP parameters used for=20 the connection are transmitted via IPBCP (Q.1970). There is a parameter in H.248.1 annex C 0x100F "Payload Type" that may be of=20 some use. Regards, Christian Kalleitner Franz wrote: > I wonder if anybody could respond on that threat! > Without a codepoint for DTMF, the functionality of RFC2833 cannot be applied > for=20 > network configuration specifing DTMF as an ACodec i.e for codec negosiation > purposes! > A solution for text encoded H248 is available but not for binary. >=20 > Many thanks in advance > Franz >=20 > -----Urspr=FCngliche Nachricht----- > Von: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org]Im Auftrag > von Kalleitner Franz > Gesendet: Donnerstag, 17. Juni 2004 13:21 > An: 'megaco@ietf.org' > Betreff: [Megaco] telephony event defintion >=20 >=20 > Hello megaco-list members, >=20 > I didn't manage to transfer the media description of the telephone-event > (defined in RFC 2833) as a media attribute into ASN.1 format. > In SDP its easily done via a dynamically payload type definition, = plus > fmtp,rtpmap for the codec definition > Using ASN.1 encoding the payload attribute is defined in H248.1 Annex C. > However, an reference pointing to the codec definition is not available, > therefore I scanned ITU-T and 3GPP references, but I didn't found any > definition for the telephone-event. >=20 > Probably another had the same problem, with more success than I'm and may > send a reply to this threat. > Many thanks in advance! >=20 > Franz >=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 >=20 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Fri Jun 25 05:09:29 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18952 for ; Fri, 25 Jun 2004 05:09:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bdmeb-0000vR-BD; Fri, 25 Jun 2004 05:05:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bdmcr-0000Ao-LD for megaco@megatron.ietf.org; Fri, 25 Jun 2004 05:04:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18711 for ; Fri, 25 Jun 2004 05:03:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bdmcp-00002L-9Y for megaco@ietf.org; Fri, 25 Jun 2004 05:03:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bdmbq-0007Xz-00 for megaco@ietf.org; Fri, 25 Jun 2004 05:02:59 -0400 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx with esmtp (Exim 4.12) id 1Bdmar-0007BM-00 for megaco@ietf.org; Fri, 25 Jun 2004 05:01:57 -0400 Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 25 Jun 2004 11:01:57 +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.5.6944.0 Subject: RE : AW: [Megaco] telephony event defintion Date: Fri, 25 Jun 2004 11:01:00 +0200 Message-ID: <2AF8FF7D89242541B12E7A47F6ECB4BEA2BEDB@ftrdmel3.rd.francetelecom.fr> Thread-Topic: AW: [Megaco] telephony event defintion Thread-Index: AcRajMBC82itO6yYTA2Sl//rN1iGpwAA65aw From: "CHATRAS Bruno FTRD/DAC/ISS" To: "Kalleitner Franz" , "Christian Groves " X-OriginalArrivalTime: 25 Jun 2004 09:01:57.0159 (UTC) FILETIME=[1162B370:01C45A93] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Cc: BELLING THOMAS , megaco@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Why not using the code point for SDP_A defined in Annex C.11 of H.248.1? Is this question related to 3GPP TS 29.332? Regards, Bruno -----Message d'origine----- De : megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] De la part = de Kalleitner Franz Envoy=E9 : vendredi 25 juin 2004 09:58 =C0 : 'Christian Groves '; Kalleitner Franz Cc : BELLING THOMAS; ''megaco@ietf.org' ' Objet : AW: AW: [Megaco] telephony event defintion Hello Christian, thanks a lot for you answer. You are right, for BICC networks its possible to use the tunneling = solution. However, we need to find a solution to manage the interworking = between SIP and ISUP networks Q.1912.5 or RFC3398 as well the 3GPP = 29.163, specifying a SIP-BICC interworking as well. As you proposed, for = the BICC interface we want to use the methods defined in Q1950 and = Q765.5 but its not possible to use them for the SIP interface. SIP = doesn't offer any tunneling in a similar way. Nevertheless its necessary = to configure an IP termination connected to a SIP network via H248.=20 So that's the background, why I'm asking these questions concerning DTMF = codec and codeclists, because we want to reuse h248 basics as much as = possible to implement the interworking between SIP and ISUP/BICC = networks. Do you think there is a chance to solve these two items within H248 = standardization? kind regards Franz -----Originalnachricht----- Von: Christian Groves An: Kalleitner Franz Cc: 'megaco@ietf.org'; BELLING THOMAS Gesendet: 25.06.04 04:16 Betreff: Re: AW: [Megaco] telephony event defintion Hello Franz, For BICC networks (where the Acodec is defined in Q.765.5) sending DTMF = as per=20 RFC2833 is not needed across Q.1950(H.248). The actual SDP parameters = used for=20 the connection are transmitted via IPBCP (Q.1970). There is a parameter in H.248.1 annex C 0x100F "Payload Type" that may = be of=20 some use. Regards, Christian Kalleitner Franz wrote: > I wonder if anybody could respond on that threat! > Without a codepoint for DTMF, the functionality of RFC2833 cannot be applied > for > network configuration specifing DTMF as an ACodec i.e for codec negosiation > purposes! > A solution for text encoded H248 is available but not for binary. >=20 > Many thanks in advance > Franz >=20 > -----Urspr=FCngliche Nachricht----- > Von: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org]Im Auftrag > von Kalleitner Franz > Gesendet: Donnerstag, 17. Juni 2004 13:21 > An: 'megaco@ietf.org' > Betreff: [Megaco] telephony event defintion >=20 >=20 > Hello megaco-list members, >=20 > I didn't manage to transfer the media description of the telephone-event > (defined in RFC 2833) as a media attribute into ASN.1 format. In SDP=20 > its easily done via a dynamically payload type definition, plus=20 > fmtp,rtpmap for the codec definition Using ASN.1 encoding the payload=20 > attribute is defined in H248.1 Annex C. > However, an reference pointing to the codec definition is not available, > therefore I scanned ITU-T and 3GPP references, but I didn't found any=20 > definition for the telephone-event. >=20 > Probably another had the same problem, with more success than I'm and may > send a reply to this threat. > Many thanks in advance! >=20 > Franz >=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 >=20 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Fri Jun 25 05:41:08 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19952 for ; Fri, 25 Jun 2004 05:41:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bdn7I-000779-QR; Fri, 25 Jun 2004 05:35:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bdn06-0005c9-9Q for megaco@megatron.ietf.org; Fri, 25 Jun 2004 05:28: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 FAA19559 for ; Fri, 25 Jun 2004 05:27:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bdn04-0007cq-2c for megaco@ietf.org; Fri, 25 Jun 2004 05:28:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bdmz6-0007KT-00 for megaco@ietf.org; Fri, 25 Jun 2004 05:27:01 -0400 Received: from eins.siemens.at ([193.81.246.11]) by ietf-mx with esmtp (Exim 4.12) id 1BdmyA-0006kn-00 for megaco@ietf.org; Fri, 25 Jun 2004 05:26:02 -0400 Received: from vies1kbx.sie.siemens.at (forix [10.1.140.2]) by eins.siemens.at (8.12.9/8.12.8) with ESMTP id i5P9PXEP017406 for ; Fri, 25 Jun 2004 11:25:33 +0200 Received: from vies194a.sie.siemens.at (vies1kbx [158.226.135.174]) by vies1kbx.sie.siemens.at (8.12.10/8.12.1) with ESMTP id i5P9PWgP006083 for ; Fri, 25 Jun 2004 11:25:32 +0200 Received: by vies194a.sie.siemens.at with Internet Mail Service (5.5.2653.19) id ; Fri, 25 Jun 2004 11:27:09 +0200 Message-ID: From: Kalleitner Franz To: "'CHATRAS Bruno FTRD/DAC/ISS'" , Christian Groves Subject: AW: RE : AW: [Megaco] telephony event defintion Date: Fri, 25 Jun 2004 11:27:08 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Cc: BELLING THOMAS , megaco@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Of course, its possible to use SDP equivalents and it seems to be the = only way out to solve this problem. Yes, the question is related to 3GPP TS 29.332.=20 So if there is the necessity to use the SDP equivalents, its not = possible to align the BICC procedure with the IMS(SIP) procedures. Franz -----Urspr=FCngliche Nachricht----- Von: CHATRAS Bruno FTRD/DAC/ISS = [mailto:bruno.chatras@francetelecom.com] Gesendet: Freitag, 25. Juni 2004 11:01 An: Kalleitner Franz; Christian Groves=20 Cc: BELLING THOMAS; megaco@ietf.org Betreff: RE : AW: [Megaco] telephony event defintion Why not using the code point for SDP_A defined in Annex C.11 of = H.248.1? Is this question related to 3GPP TS 29.332? Regards, Bruno -----Message d'origine----- De : megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] De la = part de Kalleitner Franz Envoy=E9 : vendredi 25 juin 2004 09:58 =C0 : 'Christian Groves '; Kalleitner Franz Cc : BELLING THOMAS; ''megaco@ietf.org' ' Objet : AW: AW: [Megaco] telephony event defintion Hello Christian, thanks a lot for you answer. You are right, for BICC networks its possible to use the tunneling = solution. However, we need to find a solution to manage the interworking between = SIP and ISUP networks Q.1912.5 or RFC3398 as well the 3GPP 29.163, = specifying a SIP-BICC interworking as well. As you proposed, for the BICC interface = we want to use the methods defined in Q1950 and Q765.5 but its not = possible to use them for the SIP interface. SIP doesn't offer any tunneling in a = similar way. Nevertheless its necessary to configure an IP termination = connected to a SIP network via H248.=20 So that's the background, why I'm asking these questions concerning = DTMF codec and codeclists, because we want to reuse h248 basics as much as possible to implement the interworking between SIP and ISUP/BICC = networks. Do you think there is a chance to solve these two items within H248 standardization? kind regards Franz -----Originalnachricht----- Von: Christian Groves An: Kalleitner Franz Cc: 'megaco@ietf.org'; BELLING THOMAS Gesendet: 25.06.04 04:16 Betreff: Re: AW: [Megaco] telephony event defintion Hello Franz, For BICC networks (where the Acodec is defined in Q.765.5) sending DTMF = as per=20 RFC2833 is not needed across Q.1950(H.248). The actual SDP parameters = used for=20 the connection are transmitted via IPBCP (Q.1970). There is a parameter in H.248.1 annex C 0x100F "Payload Type" that may = be of some use. Regards, Christian Kalleitner Franz wrote: > I wonder if anybody could respond on that threat! > Without a codepoint for DTMF, the functionality of RFC2833 cannot be applied > for > network configuration specifing DTMF as an ACodec i.e for codec negosiation > purposes! > A solution for text encoded H248 is available but not for binary. >=20 > Many thanks in advance > Franz >=20 > -----Urspr=FCngliche Nachricht----- > Von: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org]Im Auftrag > von Kalleitner Franz > Gesendet: Donnerstag, 17. Juni 2004 13:21 > An: 'megaco@ietf.org' > Betreff: [Megaco] telephony event defintion >=20 >=20 > Hello megaco-list members, >=20 > I didn't manage to transfer the media description of the telephone-event > (defined in RFC 2833) as a media attribute into ASN.1 format. In SDP=20 > its easily done via a dynamically payload type definition, plus=20 > fmtp,rtpmap for the codec definition Using ASN.1 encoding the payload = > attribute is defined in H248.1 Annex C. > However, an reference pointing to the codec definition is not available, > therefore I scanned ITU-T and 3GPP references, but I didn't found any = > definition for the telephone-event. >=20 > Probably another had the same problem, with more success than I'm and may > send a reply to this threat. > Many thanks in advance! >=20 > Franz >=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 >=20 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Fri Jun 25 14:19:22 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00027 for ; Fri, 25 Jun 2004 14:19:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdvBW-0003w7-Df; Fri, 25 Jun 2004 14:12:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bduyd-0007Xk-PH for megaco@megatron.ietf.org; Fri, 25 Jun 2004 13:59: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 NAA28488 for ; Fri, 25 Jun 2004 13:59:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bduyc-0006ij-Ha for megaco@ietf.org; Fri, 25 Jun 2004 13:59:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BduxT-0006KD-00 for megaco@ietf.org; Fri, 25 Jun 2004 13:57:51 -0400 Received: from zcars04e.nortelnetworks.com ([47.129.242.56]) by ietf-mx with esmtp (Exim 4.12) id 1Bduvt-0005Xh-00 for megaco@ietf.org; Fri, 25 Jun 2004 13:56:13 -0400 Received: from zcard303.ca.nortel.com (zcard303.ca.nortel.com [47.129.242.59]) by zcars04e.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i5PHtSK04413; Fri, 25 Jun 2004 13:55:28 -0400 (EDT) Received: from [47.130.24.109] (acart14e.ca.nortel.com [47.130.24.109]) by zcard303.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NALS04A9; Fri, 25 Jun 2004 13:55:28 -0400 Message-ID: <40DC670F.6000606@nortelnetworks.com> Date: Fri, 25 Jun 2004 13:55:27 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Groves Subject: Re: [Megaco] MID used to identify sender References: <40DB8EF4.8000104@ericsson.com> In-Reply-To: <40DB8EF4.8000104@ericsson.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cc: megaco@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org Content-Transfer-Encoding: 7bit Let's go one further on this. If you identify errors, please notify the author. It's time we got this document cleaned up and posted as an Informational RFC. Christian Groves wrote: > Hello Inger, > > Where there are differences between the Call Flows and the H.248.1 > recommendation, H.248.1 takes precedence. > > A note for everyone: DO NOT BASE AN IMPLEMENTATION on the > draft. These flows have quite a few > errors > and misassumptions and do not represent a definitive guide to the use of > H.248.1. > > Regards, Christian > > Inger Bohlbro wrote: > > > Hi > > > > I have a question regarding the Message Identifier (MID). > > > > H.248.1 states > > "A H.248.1 entity (MG/MGC) must consistently use the same MID > > in all messages it originates for the duration of control > > association with the peer (MGC/MG)". > > > > Is it allowed for a MG to use the MID to check if the message > > is received from the MGC with which contol association is > > obtained, i.e. compare MID in received messages with the > > MID received in the ServiceChange response ? > > > > This could be especially relevant when running over UDP, in > > order to discard messages received from "old" associations. > > > > It could also be relevant during a failover situation > > to be able to distinguish between messages from an "old" > > MGC and messages from the MGC at which a ServiceChange request > > is outstanding. Requests received from the "new" MGC should > > be answered with error code 505 if received before the > > ServiceChange response. > > > > However, in draft-ietf-megaco-callflows-03.txt there is an > > example in section 3.1.1 where the MID used in ServiceChange > > response is [216.33.33.61]:2944 and in all following messages > > it is [216.33.33.61]:25000. The ServiceChange response contains > > the ServiceChangeAddress = 25000 parameter, but never the less > > the two MID's are not identical. > > > > > > Regards > > Inger Bohlbro > > > > > > _______________________________________________ > 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-bounces@ietf.org Sun Jun 27 20:59:00 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15869 for ; Sun, 27 Jun 2004 20:59:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BekSC-00016b-Up; Sun, 27 Jun 2004 20:57:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BekRt-000104-MK for megaco@megatron.ietf.org; Sun, 27 Jun 2004 20:56: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 UAA15791 for ; Sun, 27 Jun 2004 20:56:39 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BekRs-0002eW-48 for megaco@ietf.org; Sun, 27 Jun 2004 20:56:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BekQy-0002UD-00 for megaco@ietf.org; Sun, 27 Jun 2004 20:55:45 -0400 Received: from [211.160.15.6] (helo=mail.putian.com) by ietf-mx with esmtp (Exim 4.12) id 1BekQK-00028n-00 for megaco@ietf.org; Sun, 27 Jun 2004 20:55:04 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 28 Jun 2004 08:58:02 +0800 Message-ID: <006A9E7E02D21C45AC3CB741AEBF844E015D67EE@mail.putian.com> Thread-Topic: Megaco Digest, Vol 2, Issue 19 Thread-Index: AcRbmEKG4KyiFaurQhO5mzXgUx1LQgBESGhA From: =?utf-8?B?5p2o5YWI5rOi?= To: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Megaco] Reply: Megaco Digest, Vol 2, Issue 19 X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0500366914==" Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org --===============0500366914== content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TUdDIHdpbGwgdXNlIHRoZSBvbGQgTUlEIGluIHNlcnZpY2VjaGFuZ2UgcmVzcG9uY2UgY29tbWFu ZCB3aXRoIG5ldyBzZXJ2aWNlY2hhbmdlIGFkZHJlc3MsDQpNRyBzaG91bGQgaWRlbnRpZnkgdGhl IE1HQyB3aXRoIG9sZCBtaWQgd2hpY2ggd2FzIHVzZWQgaW4gc2VydmljZWNoYW5nZSByZXEgY29t bWFuZCAsb3IgaG93IA0KZG9lcyBNRyBrbm93IHRoZSByZXNwb25zaW5nIE1HQyBpcyB0aGUgTUdD IGl0IGp1c3Qgc2VuZCBzZXJ2aWVjaGNoYW5nZSByZXEgdG8gPyBPbmx5IGFmdGVyIHRoaXMNCnBy b2Nlc3MsIHRoZW4gTUcga25vd3MgIE1HQydzIG5ldyBBZGRyZXNzLg0KDQoNCg0K5Y+R5Lu25Lq6 OiBtZWdhY28tYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1lZ2Fjby1ib3VuY2VzQGlldGYub3Jn XeS7o+ihqCBtZWdhY28tcmVxdWVzdEBpZXRmLm9yZw0K5Y+R6YCB5pe26Ze0OiAyMDA05bm0Nuac iDI35pelIDA6MTINCuaUtuS7tuS6ujogbWVnYWNvQGlldGYub3JnDQrkuLvpopg6IE1lZ2FjbyBE aWdlc3QsIFZvbCAyLCBJc3N1ZSAxOQ0KDQoNClNlbmQgTWVnYWNvIG1haWxpbmcgbGlzdCBzdWJt aXNzaW9ucyB0bw0KCW1lZ2Fjb0BpZXRmLm9yZw0KDQpUbyBzdWJzY3JpYmUgb3IgdW5zdWJzY3Jp YmUgdmlhIHRoZSBXb3JsZCBXaWRlIFdlYiwgdmlzaXQNCglodHRwczovL3d3dzEuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9tZWdhY28NCm9yLCB2aWEgZW1haWwsIHNlbmQgYSBtZXNzYWdlIHdp dGggc3ViamVjdCBvciBib2R5ICdoZWxwJyB0bw0KCW1lZ2Fjby1yZXF1ZXN0QGlldGYub3JnDQoN CllvdSBjYW4gcmVhY2ggdGhlIHBlcnNvbiBtYW5hZ2luZyB0aGUgbGlzdCBhdA0KCW1lZ2Fjby1v d25lckBpZXRmLm9yZw0KDQpXaGVuIHJlcGx5aW5nLCBwbGVhc2UgZWRpdCB5b3VyIFN1YmplY3Qg bGluZSBzbyBpdCBpcyBtb3JlIHNwZWNpZmljDQp0aGFuICJSZTogQ29udGVudHMgb2YgTWVnYWNv IGRpZ2VzdC4uLiINCg0KDQpUb2RheSdzIFRvcGljczoNCg0KICAgMS4gUmU6IE1JRCB1c2VkIHRv IGlkZW50aWZ5IHNlbmRlciAoVG9tIFRheWxvcikNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCk1lc3Nh Z2U6IDENCkRhdGU6IEZyaSwgMjUgSnVuIDIwMDQgMTM6NTU6MjcgLTA0MDANCkZyb206IFRvbSBU YXlsb3IgPHRheWxvckBub3J0ZWxuZXR3b3Jrcy5jb20+DQpTdWJqZWN0OiBSZTogW01lZ2Fjb10g TUlEIHVzZWQgdG8gaWRlbnRpZnkgc2VuZGVyDQpUbzogQ2hyaXN0aWFuIEdyb3ZlcyA8Y2hyaXN0 aWFuLmdyb3Zlc0Blcmljc3Nvbi5jb20+DQpDYzogbWVnYWNvQGlldGYub3JnDQpNZXNzYWdlLUlE OiA8NDBEQzY3MEYuNjAwMDYwNkBub3J0ZWxuZXR3b3Jrcy5jb20+DQpDb250ZW50LVR5cGU6IHRl eHQvcGxhaW47IGNoYXJzZXQ9dXMtYXNjaWk7IGZvcm1hdD1mbG93ZWQNCg0KTGV0J3MgZ28gb25l IGZ1cnRoZXIgb24gdGhpcy4gIElmIHlvdSBpZGVudGlmeSBlcnJvcnMsIHBsZWFzZSBub3RpZnkg dGhlIGF1dGhvci4gDQpJdCdzIHRpbWUgd2UgZ290IHRoaXMgZG9jdW1lbnQgY2xlYW5lZCB1cCBh bmQgcG9zdGVkIGFzIGFuIEluZm9ybWF0aW9uYWwgUkZDLg0KDQpDaHJpc3RpYW4gR3JvdmVzIHdy b3RlOg0KPiBIZWxsbyBJbmdlciwNCj4gDQo+IFdoZXJlIHRoZXJlIGFyZSBkaWZmZXJlbmNlcyBi ZXR3ZWVuIHRoZSBDYWxsIEZsb3dzIGFuZCB0aGUgSC4yNDguMQ0KPiByZWNvbW1lbmRhdGlvbiwg SC4yNDguMSB0YWtlcyBwcmVjZWRlbmNlLg0KPiANCj4gQSBub3RlIGZvciBldmVyeW9uZTogRE8g Tk9UIEJBU0UgQU4gSU1QTEVNRU5UQVRJT04gb24gdGhlDQo+IDxkcmFmdC1pZXRmLW1lZ2Fjby1j YWxsZmxvd3MtMDMudHh0PiBkcmFmdC4gVGhlc2UgZmxvd3MgaGF2ZSBxdWl0ZSBhIGZldyANCj4g ZXJyb3JzDQo+IGFuZCBtaXNhc3N1bXB0aW9ucyBhbmQgZG8gbm90IHJlcHJlc2VudCBhIGRlZmlu aXRpdmUgZ3VpZGUgdG8gdGhlIHVzZSBvZiANCj4gSC4yNDguMS4NCj4gDQo+IFJlZ2FyZHMsIENo cmlzdGlhbg0KPiANCj4gSW5nZXIgQm9obGJybyB3cm90ZToNCj4gDQo+ICA+IEhpDQo+ICA+DQo+ ICA+IEkgaGF2ZSBhIHF1ZXN0aW9uIHJlZ2FyZGluZyB0aGUgTWVzc2FnZSBJZGVudGlmaWVyIChN SUQpLg0KPiAgPg0KPiAgPiBILjI0OC4xIHN0YXRlcw0KPiAgPiAiQSBILjI0OC4xIGVudGl0eSAo TUcvTUdDKSBtdXN0IGNvbnNpc3RlbnRseSB1c2UgdGhlIHNhbWUgTUlEDQo+ICA+IGluIGFsbCBt ZXNzYWdlcyBpdCBvcmlnaW5hdGVzIGZvciB0aGUgZHVyYXRpb24gb2YgY29udHJvbA0KPiAgPiBh c3NvY2lhdGlvbiB3aXRoIHRoZSBwZWVyIChNR0MvTUcpIi4NCj4gID4NCj4gID4gSXMgaXQgYWxs b3dlZCBmb3IgYSBNRyB0byB1c2UgdGhlIE1JRCB0byBjaGVjayBpZiB0aGUgbWVzc2FnZQ0KPiAg PiBpcyByZWNlaXZlZCBmcm9tIHRoZSBNR0Mgd2l0aCB3aGljaCBjb250b2wgYXNzb2NpYXRpb24g aXMNCj4gID4gb2J0YWluZWQsIGkuZS4gY29tcGFyZSBNSUQgaW4gcmVjZWl2ZWQgbWVzc2FnZXMg d2l0aCB0aGUNCj4gID4gTUlEIHJlY2VpdmVkIGluIHRoZSBTZXJ2aWNlQ2hhbmdlIHJlc3BvbnNl ID8NCj4gID4NCj4gID4gVGhpcyBjb3VsZCBiZSBlc3BlY2lhbGx5IHJlbGV2YW50IHdoZW4gcnVu bmluZyBvdmVyIFVEUCwgaW4NCj4gID4gb3JkZXIgdG8gZGlzY2FyZCBtZXNzYWdlcyByZWNlaXZl ZCBmcm9tICJvbGQiIGFzc29jaWF0aW9ucy4NCj4gID4NCj4gID4gSXQgY291bGQgYWxzbyBiZSBy ZWxldmFudCBkdXJpbmcgYSBmYWlsb3ZlciBzaXR1YXRpb24NCj4gID4gdG8gYmUgYWJsZSB0byBk aXN0aW5ndWlzaCBiZXR3ZWVuIG1lc3NhZ2VzIGZyb20gYW4gIm9sZCINCj4gID4gTUdDIGFuZCBt ZXNzYWdlcyBmcm9tIHRoZSBNR0MgYXQgd2hpY2ggYSBTZXJ2aWNlQ2hhbmdlIHJlcXVlc3QNCj4g ID4gaXMgb3V0c3RhbmRpbmcuIFJlcXVlc3RzIHJlY2VpdmVkIGZyb20gdGhlICJuZXciIE1HQyBz aG91bGQNCj4gID4gYmUgYW5zd2VyZWQgd2l0aCBlcnJvciBjb2RlIDUwNSBpZiByZWNlaXZlZCBi ZWZvcmUgdGhlDQo+ICA+IFNlcnZpY2VDaGFuZ2UgcmVzcG9uc2UuDQo+ICA+DQo+ICA+IEhvd2V2 ZXIsIGluIGRyYWZ0LWlldGYtbWVnYWNvLWNhbGxmbG93cy0wMy50eHQgdGhlcmUgaXMgYW4NCj4g ID4gZXhhbXBsZSBpbiBzZWN0aW9uIDMuMS4xIHdoZXJlIHRoZSBNSUQgdXNlZCBpbiBTZXJ2aWNl Q2hhbmdlDQo+ICA+IHJlc3BvbnNlIGlzIFsyMTYuMzMuMzMuNjFdOjI5NDQgYW5kIGluIGFsbCBm b2xsb3dpbmcgbWVzc2FnZXMNCj4gID4gaXQgaXMgWzIxNi4zMy4zMy42MV06MjUwMDAuIFRoZSBT ZXJ2aWNlQ2hhbmdlIHJlc3BvbnNlIGNvbnRhaW5zDQo+ICA+IHRoZSBTZXJ2aWNlQ2hhbmdlQWRk cmVzcyA9IDI1MDAwIHBhcmFtZXRlciwgYnV0IG5ldmVyIHRoZSBsZXNzDQo+ICA+IHRoZSB0d28g TUlEJ3MgYXJlIG5vdCBpZGVudGljYWwuDQo+ICA+DQo+ICA+DQo+ICA+IFJlZ2FyZHMNCj4gID4g SW5nZXIgQm9obGJybw0KPiAgPg0KPiANCj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBNZWdhY28gbWFpbGluZyBsaXN0DQo+IE1lZ2Fj b0BpZXRmLm9yZw0KPiBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tZWdh Y28NCj4gDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk1lZ2FjbyBtYWlsaW5nIGxp c3QNCk1lZ2Fjb0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbWVnYWNvDQoNCg0KRW5kIG9mIE1lZ2FjbyBEaWdlc3QsIFZvbCAyLCBJc3N1ZSAxOQ0KKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0K --===============0500366914== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============0500366914==--