From megaco-bounces@ietf.org Sun Oct 02 11:39:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EM5vo-0008Hl-Iq; Sun, 02 Oct 2005 11:39:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EM5vn-0008Hg-HY for megaco@megatron.ietf.org; Sun, 02 Oct 2005 11:39:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20908 for ; Sun, 2 Oct 2005 11:39:13 -0400 (EDT) Received: from mail.tdsoft.com ([212.143.64.34] helo=TdSoftesaferelay) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EM644-0003ma-RR for megaco@ietf.org; Sun, 02 Oct 2005 11:47:50 -0400 Received: from mailserver.td-soft.co.il ([172.16.1.203]) by eSafe SMTP Relay 1127368311; Sun Oct 2 17:37:13 Received: by MAILSERVER with Internet Mail Service (5.5.2657.72) id ; Sun, 2 Oct 2005 18:40:09 +0200 Message-ID: <9A64A99CD3F2BD4582BE4FB63FC1F381010D33BD@MAILSERVER> From: Raphael Tryster To: megaco@ietf.org Date: Sun, 2 Oct 2005 18:40:06 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-ESAFE-STATUS: Mail clean X-ESAFE-DETAILS: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Subject: [Megaco] When is automatic switching between codecs useful? 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="===============1934094308==" 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. --===============1934094308== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5C76F.F20BE410" 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_01C5C76F.F20BE410 Content-Type: text/plain; charset="WINDOWS-1255" ReserveValue=TRUE may be used to reserve resources for multiple codecs in a call. In this case, the local descriptor will list multiple codecs. Common examples of where this might be done are where a low bit rate codec should be switched to G.711 on detecting a DTMF digit or fax or modem. My question is whether there are other scenarios when this is useful, and what would typically be the trigger? Would it be automatically switching the transmit codec when the received codec changes? In that case, what might have triggered the remote sender to switch to a different codec? Are there any scenarios where automatic switching between different low bit rate codecs is useful? Raphael Tryster ------_=_NextPart_001_01C5C76F.F20BE410 Content-Type: text/html; charset="WINDOWS-1255" Content-Transfer-Encoding: quoted-printable When is automatic switching between codecs useful?

ReserveValue=3DTRUE may be used to reserve resources fo= r multiple codecs in a call.  In this case, the local descriptor wil= l list multiple codecs.  Common examples of where this might be done= are where a low bit rate codec should be switched to G.711 on detecting = a DTMF digit or fax or modem.  My question is whether there are othe= r scenarios when this is useful, and what would typically be the trigger?=   Would it be automatically switching the transmit codec when the re= ceived codec changes?  In that case, what might have triggered the r= emote sender to switch to a different codec?  Are there any scenario= s where automatic switching between different low bit rate codecs is usef= ul?

Raphael Tryster

------_=_NextPart_001_01C5C76F.F20BE410-- --===============1934094308== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============1934094308==-- From megaco-bounces@ietf.org Mon Oct 03 11:00:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMRnt-0008Rf-4u; Mon, 03 Oct 2005 11:00:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMRns-0008RT-5T for megaco@megatron.ietf.org; Mon, 03 Oct 2005 11:00:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09938 for ; Mon, 3 Oct 2005 11:00:30 -0400 (EDT) Received: from zctfs063.nortelnetworks.com ([47.164.128.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMRwL-0001rJ-RV for megaco@ietf.org; Mon, 03 Oct 2005 11:09:19 -0400 Received: from zctfhxm1.corp.nortel.com (zctfhxm1.corp.nortel.com [47.164.129.157]) by zctfs063.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j93ELZE00901; Mon, 3 Oct 2005 16:21:35 +0200 (MEST) Received: from zcarhxp0.corp.nortel.com ([47.129.230.91]) by zctfhxm1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 3 Oct 2005 16:21:34 +0200 Received: from [127.0.0.1] ([47.130.18.245] RDNS failed) by zcarhxp0.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 3 Oct 2005 10:21:32 -0400 Message-ID: <43413E6A.30104@nortel.com> Date: Mon, 03 Oct 2005 10:21:30 -0400 From: "Tom-PT Taylor" User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Raphael Tryster Subject: Re: [Megaco] When is automatic switching between codecs useful? References: <9A64A99CD3F2BD4582BE4FB63FC1F381010D33BD@MAILSERVER> In-Reply-To: <9A64A99CD3F2BD4582BE4FB63FC1F381010D33BD@MAILSERVER> Content-Type: text/plain; charset=windows-1255; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Oct 2005 14:21:33.0071 (UTC) FILETIME=[C13469F0:01C5C825] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 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 Something on the top of my mind: RFC 2833! Raphael Tryster wrote: > ReserveValue=TRUE may be used to reserve resources for multiple codecs in a > call. In this case, the local descriptor will list multiple codecs. Common > examples of where this might be done are where a low bit rate codec should > be switched to G.711 on detecting a DTMF digit or fax or modem. My question > is whether there are other scenarios when this is useful, and what would > typically be the trigger? Would it be automatically switching the transmit > codec when the received codec changes? In that case, what might have > triggered the remote sender to switch to a different codec? Are there any > scenarios where automatic switching between different low bit rate codecs is > useful? > > Raphael Tryster > > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Oct 03 16:24:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMWri-0001JG-Qi; Mon, 03 Oct 2005 16:24:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMWrg-0001Hi-Qr for megaco@megatron.ietf.org; Mon, 03 Oct 2005 16:24:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08592 for ; Mon, 3 Oct 2005 16:24:46 -0400 (EDT) Received: from chekov.siemens.com.br ([200.186.153.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMX09-00068D-FK for megaco@ietf.org; Mon, 03 Oct 2005 16:33:38 -0400 Received: from sao0021x.siemens.com.br ([200.186.153.35]) by chekov.siemens.com.br (8.13.4/8.13.4) with ESMTP id j93KQZ2l082813 for ; Mon, 3 Oct 2005 17:26:35 -0300 (BRT) Received: from sao1100a.ww101.siemens.net ([129.214.31.218]) by sao0021x.siemens.com.br (8.12.10/8.9.3) with ESMTP id j93KIige067451 for ; Mon, 3 Oct 2005 17:18:45 -0300 (BRT) Received: from SAO1016V.ww101.siemens.net ([129.214.31.16]) by sao1100a.ww101.siemens.net with InterScan Messaging Security Suite; Mon, 03 Oct 2005 17:24:20 -0300 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Mon, 3 Oct 2005 17:24:20 -0300 Message-ID: <954E619901355547BE6436CF230843C9BFD936@SAO1016V.ww101.siemens.net> Thread-Topic: Service Change Reason - ASN.1 binary encoding Thread-Index: AcXIWG9IWFu9LNipR9S5C2HvI+n3YA== From: "Maruo, Luciano Mikio" To: X-Spam-Score: 3.0 (+++) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: quoted-printable Subject: [Megaco] Service Change Reason - ASN.1 binary encoding 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 For the service change reason parameter it is stated in the Annex A.2 of H.248.1 that=20 =20 "This string is first BER-encoded as an IA5String. The result of this BER-encoding is then encoded as an ASN.1 OCTET STRING type, "double wrapping" the value as was done for package elements." =20 For the service change reason "901 Cold Boot" which of the following encoding is correct? 1) with IA5 String tag from X.690 A4 11 04 0F 16 0D 39 30 31 20 43 6F 6C 64 20 42 6F 6F 74 | | | | | | |--> 901 Cold Boot | | | | | |-----> length | | | | |--------> tag for IA5 String (BER) | | | |-----------> length | | |--------------> tag for octet string (ASN.1) | |-----------------> length |--------------------> automatic tag for Service Change Reason =20 2) without IA5 String tag from X.690 A4 0F 04 0D 39 30 31 20 43 6F 6C 64 20 42 6F 6F 74 | | | | |--> 901 Cold Boot | | | |-----> length | | |--------> tag for octet string=20 | |-----------> length |--------------> automatic tag for Service Change Reason=20 Thank you very much, Luciano Mikio Maruo _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Mon Oct 03 16:42:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMX8s-0006RP-48; Mon, 03 Oct 2005 16:42:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMX8r-0006RA-Ci for megaco@megatron.ietf.org; Mon, 03 Oct 2005 16:42:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13508 for ; Mon, 3 Oct 2005 16:42:31 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMXHO-00086j-3A for megaco@ietf.org; Mon, 03 Oct 2005 16:51:23 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 03 Oct 2005 13:42:23 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j93Kfu4r017176 for ; Mon, 3 Oct 2005 13:42:21 -0700 (PDT) Received: from xmb-sjc-233.amer.cisco.com ([128.107.191.88]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 3 Oct 2005 13:42:15 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 3 Oct 2005 13:42:14 -0700 Message-ID: Thread-Topic: When is automatic switching between codecs useful? Thread-Index: AcXINJF15CKELZTVRVelIoEnfyvtLQAH6Jwg From: "Joe Stone \(joestone\)" To: X-OriginalArrivalTime: 03 Oct 2005 20:42:15.0371 (UTC) FILETIME=[F046C9B0:01C5C85A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: quoted-printable Subject: [Megaco] Re: When is automatic switching between codecs useful? 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 > Raphael Tryster wrote: > > ReserveValue=3DTRUE may be used to reserve resources for multiple codecs=20 > > in a call. In this case, the local descriptor will list multiple=20 > > codecs. Common examples of where this might be done are where a low > > bit rate codec should be switched to G.711 on detecting a DTMF digit > > or fax or modem. My question is whether there are other scenarios=20 > > when this is useful, and what would typically be the trigger? Would > > it be automatically switching the transmit codec when the received=20 > > codec changes? In that case, what might have triggered the remote=20 > > sender to switch to a different codec? Are there any scenarios where=20 > > automatic switching between different low bit rate codecs is useful? This is an excellent question. One example is V.152. With V.152, specific payload types are identified as voiceband data (VBD) payload types, a=3Drtpmap:98 PCMU/8000 a=3Dgpmd:98 vbd=3Dyes V.152 defines the semantics by which the transition to and from VBD codecs is coordinated. Are there other "standards" which define similar semantics in applications other than VBD (fax, modem, text, ...)? Tom mentioned RFC 2833. I'm not sure if he's alluding to DTMF (0 - 15), fax/modem (32 - 36), ... all of the above. Is there a standard that defines the sematics involved in coordinating the switch between transmit/receive codecs with any telephone-event? On a related topic... Is ReserveValue intended to apply to all payload types? In other words, must ReserveValue=3DTRUE in order for a Media Gateway to return more = than one payload type (regardless of what the payload types represent)? For example, must ReserveValue=3DTRUE in order for a Media Gateway to return G.729 and telephone-event, m=3Daudio 12345 RTP/AVP 18 96 a=3Drtpmap:101 telephone-event/8000 Or is the scope of ReserveValue limited to audio payload types (which would allow a Media Gateway to return payload types corresponding to G.729 and telephone-event with ReserveValue=3DFALSE)? If ReserveValue is intended to apply to all payload types, it becomes rather meaningless. A media description will commonly involve non-audio payload types (mandating ReserveValue=3DTRUE). We are left with no = syntax by which a Call Agent can request a Media Gateway to negotiate one and only one audio codec (short of explicitly specifying the one and only one code which would defeat the purpose of "negotiation"). Joe Stone _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Mon Oct 03 17:17:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMXgK-0006hU-EP; Mon, 03 Oct 2005 17:17:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMXgI-0006hP-JT for megaco@megatron.ietf.org; Mon, 03 Oct 2005 17:17:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15468 for ; Mon, 3 Oct 2005 17:17:04 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMXop-0000cR-QA for megaco@ietf.org; Mon, 03 Oct 2005 17:25:57 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 03 Oct 2005 14:16:52 -0700 X-IronPort-AV: i="3.97,169,1125903600"; d="scan'208"; a="216702779:sNHT22761214" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j93LGA5W009927 for ; Mon, 3 Oct 2005 14:16:48 -0700 (PDT) Received: from xmb-sjc-233.amer.cisco.com ([128.107.191.88]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 3 Oct 2005 14:10:08 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 3 Oct 2005 14:10:07 -0700 Message-ID: Thread-Topic: When is automatic switching between codecs useful? Thread-Index: AcXINJF15CKELZTVRVelIoEnfyvtLQAH6JwgAAKg5SA= From: "Joe Stone \(joestone\)" To: X-OriginalArrivalTime: 03 Oct 2005 21:10:08.0495 (UTC) FILETIME=[D5893FF0:01C5C85E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Content-Transfer-Encoding: quoted-printable Subject: [Megaco] RE: When is automatic switching between codecs useful? 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 =20 (typo corrected) m=3Daudio 12345 RTP/AVP 18 96 a=3Drtpmap:96 telephone-event/8000 Joe Stone _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Tue Oct 04 00:38:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMeZa-0007fD-JI; Tue, 04 Oct 2005 00:38:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMeZY-0007ds-Fk for megaco@megatron.ietf.org; Tue, 04 Oct 2005 00:38:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12077 for ; Tue, 4 Oct 2005 00:38:33 -0400 (EDT) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMeiA-0004lz-Cb for megaco@ietf.org; Tue, 04 Oct 2005 00:47:30 -0400 Received: from zrtphxm2.corp.nortel.com (zrtphxm2.corp.nortel.com [47.140.202.51]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j944ad208134; Tue, 4 Oct 2005 00:36:39 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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] Re: When is automatic switching between codecs useful? Date: Tue, 4 Oct 2005 00:36:38 -0400 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA404748DAC@zrtphxm2> Thread-Topic: [Megaco] Re: When is automatic switching between codecs useful? Thread-Index: AcXINJF15CKELZTVRVelIoEnfyvtLQAH6JwgABIdhhA= From: "Kevin Boyle" To: "Joe Stone \(joestone\)" , X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: quoted-printable Cc: 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 For alternative streams such as audio versus video, the use of ReserveGroup comes into play. This will allow the specification of multiple property groups within the SDP. Each of those can be forced to a single codec alternative through the use of ReserveValue. See clauses 7.1.7 and 7.1.8. Kevin=20 -----Original Message----- From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf Of Joe Stone (joestone) Sent: Monday, October 03, 2005 4:42 PM To: megaco@ietf.org Subject: [Megaco] Re: When is automatic switching between codecs useful? > Raphael Tryster wrote: > > ReserveValue=3DTRUE may be used to reserve resources for multiple codecs=20 > > in a call. In this case, the local descriptor will list multiple=20 > > codecs. Common examples of where this might be done are where a low > > bit rate codec should be switched to G.711 on detecting a DTMF digit > > or fax or modem. My question is whether there are other scenarios=20 > > when this is useful, and what would typically be the trigger? Would > > it be automatically switching the transmit codec when the received=20 > > codec changes? In that case, what might have triggered the remote=20 > > sender to switch to a different codec? Are there any scenarios where=20 > > automatic switching between different low bit rate codecs is useful? This is an excellent question. One example is V.152. With V.152, specific payload types are identified as voiceband data (VBD) payload types, a=3Drtpmap:98 PCMU/8000 a=3Dgpmd:98 vbd=3Dyes V.152 defines the semantics by which the transition to and from VBD codecs is coordinated. Are there other "standards" which define similar semantics in applications other than VBD (fax, modem, text, ...)? Tom mentioned RFC 2833. I'm not sure if he's alluding to DTMF (0 - 15), fax/modem (32 - 36), ... all of the above. Is there a standard that defines the sematics involved in coordinating the switch between transmit/receive codecs with any telephone-event? On a related topic... Is ReserveValue intended to apply to all payload types? In other words, must ReserveValue=3DTRUE in order for a Media Gateway to return more = than one payload type (regardless of what the payload types represent)? For example, must ReserveValue=3DTRUE in order for a Media Gateway to return G.729 and telephone-event, m=3Daudio 12345 RTP/AVP 18 96 a=3Drtpmap:101 telephone-event/8000 Or is the scope of ReserveValue limited to audio payload types (which would allow a Media Gateway to return payload types corresponding to G.729 and telephone-event with ReserveValue=3DFALSE)? If ReserveValue is intended to apply to all payload types, it becomes rather meaningless. A media description will commonly involve non-audio payload types (mandating ReserveValue=3DTRUE). We are left with no = syntax by which a Call Agent can request a Media Gateway to negotiate one and only one audio codec (short of explicitly specifying the one and only one code which would defeat the purpose of "negotiation"). Joe Stone _______________________________________________ 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 Oct 04 00:41:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMecG-0007zT-5e; Tue, 04 Oct 2005 00:41:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMecD-0007z9-BY for megaco@megatron.ietf.org; Tue, 04 Oct 2005 00:41:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12171 for ; Tue, 4 Oct 2005 00:41:18 -0400 (EDT) Received: from zcars04e.nortelnetworks.com ([47.129.242.56] helo=zcars04e.ca.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMeko-0004q8-Db for megaco@ietf.org; Tue, 04 Oct 2005 00:50:15 -0400 Received: from zrtphxm2.corp.nortel.com (zrtphxm2.corp.nortel.com [47.140.202.51]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id j944cjn28078 for ; Tue, 4 Oct 2005 00:38:45 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message Subject: RE: [Megaco] T.38 MGC Transitioning Method Date: Tue, 4 Oct 2005 00:41:10 -0400 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA404748DAD@zrtphxm2> Thread-Topic: [Megaco] T.38 MGC Transitioning Method Thread-Index: AcW+xyj8+sixiHerRv2pQLaDxSAk9gAAtw4wAnTS6dA= From: "Kevin Boyle" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: 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 One would build alternative session descriptions and utilize the ReserveGroup property to have the MG prepare for the use of either stream. Each m= line would have to appear in its own v= section, per H.248.1 clause 7.1.8. Note that setting the port to 0 is a common way of indicating a LACK of support. That doesn't seem constructive here. If there is an SDP interworking problem between SIP and H.248, then an intermediary would have to step in to perform the translation between SIP SDP and H.248 SDP. Generally, this would fall upon the MGC. Kevin -----Original Message----- From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf Of joestone@cisco.com Sent: Wednesday, September 21, 2005 12:41 PM To: megaco@ietf.org Subject: [Megaco] T.38 MGC Transitioning Method How are people using SDP to advertise support for T.38oUDPTL as a latent capability (the UDPTL port is not active) in conjunction with the MGC Transitioning Method of T.38 (04/2004)? With the example call flow in Appendix III.2.1, the Media Gateway does not advertise support for T.38 at the time the call is established. Step 4 hints that a second session description with the T.38 port set to zero COULD be used, m=image 0 udptl t38 However, this is not required and wouldn't seem to play well in terms of H.248-SIP interworking. Has anyone leveraged RFC 3407 syntax in conjunction with H.248, m=audio 3456 RTP/AVP 0 a=sqn: 0 a=cdsc: 1 audio RTP/AVP 0 a=cdsc: 2 image udptl t38 Joe Stone _______________________________________________ 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 Oct 04 02:50:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMgdI-0000U8-09; Tue, 04 Oct 2005 02:50:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMgdE-0000Re-DG for megaco@megatron.ietf.org; Tue, 04 Oct 2005 02:50:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00775 for ; Tue, 4 Oct 2005 02:50:30 -0400 (EDT) From: Albrecht.Schwarz@alcatel.de Received: from mailrelay2.alcatel.de ([194.113.59.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMglr-0007Zj-0z for megaco@ietf.org; Tue, 04 Oct 2005 02:59:27 -0400 Received: from demail05.netfr.alcatel.fr (demail05.netfr.alcatel.fr [155.132.182.205]) by mailrelay2.alcatel.de (8.12.10/8.12.10/ICT TSC MAIL 2005) with ESMTP id j946oJDO004388; Tue, 4 Oct 2005 08:50:19 +0200 In-Reply-To: <34B3EAA5B3066A42914D28C5ECF5FEA404748DAC@zrtphxm2> Subject: RE: [Megaco] Re: When is automatic switching between codecs useful? To: "Joe Stone \(joestone\)" , "Kevin Boyle" X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: Date: Tue, 4 Oct 2005 08:50:18 +0200 X-MIMETrack: Serialize by Router on DEMAIL05/DE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 10/04/2005 08:50:19 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable X-Scanned-By: MIMEDefang 2.49 on 149.204.45.73 X-Spam-Score: 0.3 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Content-Transfer-Encoding: quoted-printable 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 Joe, Raphael: >... >Are there other "standards" which define similar >semantics in applications other than VBD (fax, modem, text, ...)? Tom >mentioned RFC 2833. I'm not sure if he's alluding to DTMF (0 - 15), >fax/modem (32 - 36), ... all of the above. Your examples are all related to H.248-controlled VoRTP endpoints. You may also have a look on H.248-controlled VoAAL2 with ITU-T I.366.2 = as SSCS. Annex P is defining some codec profiles, concept is explained in =A7 13= .1 ("there might be a codec change on packet basis, receiver knows from codepoint (UUI&LI) in header how to interprete ..."). Main purpose of (VoAAL2) codec profiles are: support of "correct" bearer service (-> VBD; VBDoAAL2), bandwidth related changes (e.g., used in loop emulation service), or= codec mode changes of multirate codecs (-> e.g., AMR, see Profile 11= ) on packet individual basis (within an active bearer connection). The same framework is relevant for VoRTP, but there isn't yet such an explicit profile concept as I.366.2 for VoAAL2. What you also may see from I.366.2: there are NO profiles considered wi= th TWO compression codec types (like G.729 & G.723.1) for voice. Noone couldn't identify a use case for that. Regards Albrecht = =20 "Kevin Boyle" = =20 , =20 om> cc: = =20 Sent by: Subject: RE: [Megaco] Re= : When is automatic switching between codecs useful? =20 megaco-bounces@i = =20 etf.org = =20 = =20 = =20 04.10.2005 06:36 = =20 = =20 For alternative streams such as audio versus video, the use of ReserveGroup comes into play. This will allow the specification of multiple property groups within the SDP. Each of those can be forced t= o a single codec alternative through the use of ReserveValue. See clauses 7.1.7 and 7.1.8. Kevin -----Original Message----- From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behal= f Of Joe Stone (joestone) Sent: Monday, October 03, 2005 4:42 PM To: megaco@ietf.org Subject: [Megaco] Re: When is automatic switching between codecs useful= ? > Raphael Tryster wrote: > > ReserveValue=3DTRUE may be used to reserve resources for multiple codecs > > in a call. In this case, the local descriptor will list multiple > > codecs. Common examples of where this might be done are where a lo= w > > bit rate codec should be switched to G.711 on detecting a DTMF digi= t > > or fax or modem. My question is whether there are other scenarios > > when this is useful, and what would typically be the trigger? Woul= d > > it be automatically switching the transmit codec when the received > > codec changes? In that case, what might have triggered the remote > > sender to switch to a different codec? Are there any scenarios where > > automatic switching between different low bit rate codecs is useful= ? This is an excellent question. One example is V.152. With V.152, specific payload types are identified as voiceband data (VBD) payload types, a=3Drtpmap:98 PCMU/8000 a=3Dgpmd:98 vbd=3Dyes V.152 defines the semantics by which the transition to and from VBD codecs is coordinated. Are there other "standards" which define similar= semantics in applications other than VBD (fax, modem, text, ...)? Tom mentioned RFC 2833. I'm not sure if he's alluding to DTMF (0 - 15), fax/modem (32 - 36), ... all of the above. Is there a standard that defines the sematics involved in coordinating the switch between transmit/receive codecs with any telephone-event? On a related topic... Is ReserveValue intended to apply to all payload types? In other words,= must ReserveValue=3DTRUE in order for a Media Gateway to return more th= an one payload type (regardless of what the payload types represent)? For example, must ReserveValue=3DTRUE in order for a Media Gateway to retur= n G.729 and telephone-event, m=3Daudio 12345 RTP/AVP 18 96 a=3Drtpmap:101 telephone-event/8000 Or is the scope of ReserveValue limited to audio payload types (which would allow a Media Gateway to return payload types corresponding to G.729 and telephone-event with ReserveValue=3DFALSE)? If ReserveValue is intended to apply to all payload types, it becomes rather meaningless. A media description will commonly involve non-audio= payload types (mandating ReserveValue=3DTRUE). We are left with no synt= ax by which a Call Agent can request a Media Gateway to negotiate one and only one audio codec (short of explicitly specifying the one and only one code which would defeat the purpose of "negotiation"). Joe Stone _______________________________________________ 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 Tue Oct 04 04:50:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMiVj-0008Dx-5w; Tue, 04 Oct 2005 04:50:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMiVi-0008Dp-0f for megaco@megatron.ietf.org; Tue, 04 Oct 2005 04:50:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05287 for ; Tue, 4 Oct 2005 04:50:51 -0400 (EDT) Received: from defender.ccpu.com ([216.54.134.34] helo=smtp.ccpu.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMieL-00024m-O0 for megaco@ietf.org; Tue, 04 Oct 2005 04:59:50 -0400 Received: from sd-exchange.ccsd.ccpu.com (sd-exchange.ccpu.com [172.16.0.203]) by smtp.ccpu.com (Postfix) with ESMTP id 0E90D346950 for ; Tue, 4 Oct 2005 01:50:44 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 4 Oct 2005 01:42:16 -0700 Message-ID: Thread-Topic: Query on ASN grammer Thread-Index: AcXIv4ZCDK/olGHST5OdLbmh9hetCw== From: "Deepak Pokharna" To: X-Spam-Score: 0.2 (/) X-Scan-Signature: af2aae76ea468dc53420d9ba52ca6045 Subject: [Megaco] Query on ASN grammer 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="===============0512737980==" Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org This is a multi-part message in MIME format. --===============0512737980== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5C8BF.87294F32" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5C8BF.87294F32 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi=20 According to V2 Draft (ASN Grammar) it says at most one descriptor is required in list of descriptor in AmmRequest..But it has not made the descriptors as optional too so it means one Descriptor should be there in Add, Move and Mod Request. Here it has difference from ABNF grammar which have made the list of descriptor as optional. Can some one clarify this. =20 Command ::=3D CHOICE=20 {=20 addReq AmmRequest,=20 moveReq AmmRequest,=20 modReq AmmRequest,=20 -- Add, Move, Modify requests have the same parameters=20 subtractReq SubtractRequest,=20 auditCapRequest AuditRequest,=20 auditValueRequest AuditRequest,=20 notifyReq NotifyRequest,=20 serviceChangeReq ServiceChangeRequest,=20 ...=20 }=20 =20 =20 AmmRequest ::=3D SEQUENCE=20 {=20 terminationID TerminationIDList,=20 descriptors SEQUENCE OF AmmDescriptor,=20 -- At most one descriptor of each type (see AmmDescriptor)=20 -- allowed in the sequence.=20 ...=20 =20 =20 Groves et al Expires - October 2003 [Page 103]=20 Megaco Protocol version 2 April 2003 =20 =20 }=20 =20 AmmDescriptor ::=3D CHOICE=20 {=20 mediaDescriptor MediaDescriptor,=20 modemDescriptor ModemDescriptor,=20 muxDescriptor MuxDescriptor,=20 eventsDescriptor EventsDescriptor,=20 eventBufferDescriptor EventBufferDescriptor,=20 signalsDescriptor SignalsDescriptor,=20 digitMapDescriptor DigitMapDescriptor,=20 auditDescriptor AuditDescriptor,=20 ...=20 } =20 Regards Deepak =20 ------_=_NextPart_001_01C5C8BF.87294F32 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi

     According = to V2 Draft (ASN Grammar) it says at most one descriptor is required in list = of descriptor in AmmRequest..But it has not made the descriptors as = optional too so it means one Descriptor should be there in Add, Move and Mod Request. = Here it has difference from ABNF grammar which have made the list of = descriptor as optional. Can some one clarify this.

 

      = Command ::=3D CHOICE

      { =

      =    addReq           &= nbsp;   AmmRequest,

      =    moveReq           =    AmmRequest,

      =    modReq           &= nbsp;   AmmRequest,

      =    -- Add, Move, Modify requests have the same parameters =

      =    subtractReq          SubtractRequest,

      =    auditCapRequest      AuditRequest, =

      =    auditValueRequest    AuditRequest, =

      =    notifyReq          &nbs= p; NotifyRequest,

      =    serviceChangeReq     ServiceChangeRequest, =

      =    ...

      } =

      =

      =

      = AmmRequest ::=3D SEQUENCE

      { =

      =    terminationID        = TerminationIDList,

      =    descriptors   = ;       SEQUENCE OF AmmDescriptor,

=          -- At most one descriptor of each type (see AmmDescriptor) =

=          -- allowed in the sequence.

=          ...

    =

    =

   Groves et al            = Expires - October 2003           &nb= sp;  [Page 103]


      =             &= nbsp;      Megaco Protocol version = 2            April 2003

    =

    =

      } =

      =

      AmmDescriptor ::=3D CHOICE

      { =

      =    mediaDescriptor         MediaDescriptor,

      =    modemDescriptor         ModemDescriptor,

      =    muxDescriptor          = MuxDescriptor,

      =    eventsDescriptor        = EventsDescriptor,

      =    eventBufferDescriptor   EventBufferDescriptor, =

      =    signalsDescriptor       SignalsDescriptor, =

      =    digitMapDescriptor      DigitMapDescriptor, =

      =    auditDescriptor         AuditDescriptor,

      =    ...

      = }

 

Regards

=

Deepak

 

------_=_NextPart_001_01C5C8BF.87294F32-- --===============0512737980== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============0512737980==-- From megaco-bounces@ietf.org Tue Oct 04 12:06:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMpJi-00064K-3Q; Tue, 04 Oct 2005 12:06:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMpJg-000642-I6 for megaco@megatron.ietf.org; Tue, 04 Oct 2005 12:06:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06099 for ; Tue, 4 Oct 2005 12:06:53 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMpSN-0007pI-Cu for megaco@ietf.org; Tue, 04 Oct 2005 12:15:56 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 04 Oct 2005 09:06:42 -0700 X-IronPort-AV: i="3.97,173,1125903600"; d="scan'208"; a="348101558:sNHT1336968076" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j94G6R58023125 for ; Tue, 4 Oct 2005 09:06:40 -0700 (PDT) Received: from xmb-sjc-233.amer.cisco.com ([128.107.191.88]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 4 Oct 2005 09:06:39 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 4 Oct 2005 09:06:39 -0700 Message-ID: Thread-Topic: T.38 MGC Transitioning Method Thread-Index: AcXIwU7OBZjhW8NATRSvhQoc8cxxEwAN2OVQ From: "Joe Stone \(joestone\)" To: X-OriginalArrivalTime: 04 Oct 2005 16:06:39.0829 (UTC) FILETIME=[9ABD1050:01C5C8FD] X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: quoted-printable Subject: [Megaco] Re: T.38 MGC Transitioning Method 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 Kevin Boyle wrote: > One would build alternative session descriptions and utilize the > ReserveGroup property to have the MG prepare for the use of either > stream. Each m=3D line would have to appear in its own v=3D section, = per > H.248.1 clause 7.1.8. This does not involve having the MG prepare to use either stream. That would be analogous to the T.38 Autonomous Transitioning Method. In the case of the T.38 Autonomous Transitioning Method, the MG would return two session descriptions each with a non-zero port (i.e., both the RTP and UDPTL ports are active). I had posed the question regarding how support for T.38 as a latent capability (i.e., the UDPTL port is not active) is advertised with the T.38 MGC Transitioning Method. With the T.38 MGC Transitioning Method, the MGC must explicitly instruct the MG to switch from one transport to the other. There's no need for the MG to prepare to use the UDPTL stream.=20 > Note that setting the port to 0 is a common way of indicating a LACK of > support. That doesn't seem constructive here. I agree, however, this is allowed by the T.38 standard and groups within the industry have latched onto this "loophole" and made it an integral part of their solution.=20 > If there is an SDP interworking problem between SIP and H.248, then an > intermediary would have to step in to perform the translation between > SIP SDP and H.248 SDP. Generally, this would fall upon the MGC. I don't disagree, but if we can agree on common strategies across multiple SDP-based control protocols (Megaco/H.248, MGCP, SIP, ...) we can minimize the interworking requirements on the MGC. At the least, we can avoid strategies with known conflicts (such as the use of port zero to advertise a latent capability). This brings me back to the use of RFC 3407 syntax and T.38. I take it that no one is currently leveraging RFC 3407 syntax to advertise T.38 as a latent capability in conjunction with Megaco/H.248. Does anyone see this as a good idea? A really bad idea? In case you're not familiar with RFC 3407 syntax, it's of the form (refer to the last three lines), v=3D0 =20 o=3D- 25678 753849 IN IP4 128.96.41.2=20 s=3D- =20 c=3DIN IP4 128.96.41.2=20 t=3D0 0 =20 m=3Daudio 1296 RTP/AVP 18 96 97 a=3Drtpmap:96 RED/8000 a=3Dfmtp:96 97/97 a=3Drtpmap:97 PCMU/8000 a=3Dgpmd:97 vbd=3Dyes > a=3Dsqn: 0 =20 > a=3Dcdsc: 1 audio RTP/AVP 18 96 97 > a=3Dcdsc: 4 image udptl t38 This is an example with G.729 as the audio codec and G.711u as the VBD codec with a single level of redundancy per RFC 2198. If both MGs were to advertise support for T.38 as a latent capability at the time the call was established, the MGC would instruct the MGs to switch to T.38 upon being notified of the fax stimulus. If one MG or the other failed to advertise T.38 as a latent capability, the MGs would autonomously switch to VBD mode upon detecting the fax stimulus (assuming that V.152 was successfully negotiated). Joe Stone _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Tue Oct 04 12:23:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMpZH-00078V-Eq; Tue, 04 Oct 2005 12:23:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMpZF-00074O-AS for megaco@megatron.ietf.org; Tue, 04 Oct 2005 12:23:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07410 for ; Tue, 4 Oct 2005 12:22:58 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMphw-0008RW-Eg for megaco@ietf.org; Tue, 04 Oct 2005 12:32:01 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 04 Oct 2005 09:22:50 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j94GMVKK004721 for ; Tue, 4 Oct 2005 09:22:48 -0700 (PDT) Received: from xmb-sjc-233.amer.cisco.com ([128.107.191.88]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 4 Oct 2005 09:22:47 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 4 Oct 2005 09:22:46 -0700 Message-ID: Thread-Topic: When is automatic switching between codecs useful? Thread-Index: AcXIwU7OBZjhW8NATRSvhQoc8cxxEwAMfurg From: "Joe Stone \(joestone\)" To: X-OriginalArrivalTime: 04 Oct 2005 16:22:47.0126 (UTC) FILETIME=[DB4ADF60:01C5C8FF] X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: quoted-printable Subject: [Megaco] Re: When is automatic switching between codecs useful? 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 Kevin Boyle wrote: > For alternative streams such as audio versus video, the use of > ReserveGroup comes into play. This will allow the specification of > multiple property groups within the SDP. Each of those can be forced to > a single codec alternative through the use of ReserveValue. > > See clauses 7.1.7 and 7.1.8. I don't think that we're talking about alternate streams. We're talking about alternate encodings for the same stream. How does the MGC authorize the use of DTMF relay in conjunction with one and only one audio codec without explicity specifying the audio codec? Albrecht Schwarz wrote: > Your examples are all related to H.248-controlled VoRTP endpoints. > You may also have a look on H.248-controlled VoAAL2 with ITU-T I.366.2 > as SSCS. Excellent point! I inferred VoIP from Raphael's post. Raphael was referring to lists of multiple codecs. With VoAAL2, you'd be negotiating lists of AAL2 profiles, m=3Daudio $ AAL2/ITU 1 2 7 Joe Stone _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Thu Oct 06 20:08:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENfmV-0007ea-59; Thu, 06 Oct 2005 20:08:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENdYZ-00089M-Om for megaco@megatron.ietf.org; Thu, 06 Oct 2005 17:45:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19715 for ; Thu, 6 Oct 2005 17:45:36 -0400 (EDT) Received: from auds953.usa.alcatel.com ([143.209.238.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENdhi-00022A-Sm for megaco@ietf.org; Thu, 06 Oct 2005 17:55:08 -0400 Received: from usa.alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id j96LjSqK019796 for ; Thu, 6 Oct 2005 16:45:28 -0500 (CDT) Received: from [143.209.175.110] by auds930.usa.alcatel.com (mshttpd); Thu, 06 Oct 2005 16:45:28 -0500 From: Chandrakan Kamath To: megaco@ietf.org Message-ID: <1f41181f50c1.1f50c11f4118@usa.alcatel.com> Date: Thu, 06 Oct 2005 16:45:28 -0500 X-Mailer: iPlanet Messenger Express 5.2 Patch 2 (built Jul 14 2004) MIME-Version: 1.0 Content-Language: en X-Accept-Language: en Priority: normal Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 06 Oct 2005 20:08:09 -0400 Subject: [Megaco] digitmap syntax in event without digitmap name 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 , my registered email id with megaco group is ckamath@axes- mach01.usa.alcatel.com but as currently as i am unable to access it i am sending mail from my this email id. i would like to know if the below syntax for digitmap is correct. Basicaly i want to know if after Digitmap, whether "=" token is reqd or not ? awaiting reply. The message received is MEGACO/1 [172.16.1.71] Transaction = 390 { Context=20{ Modify = TAURUS/GATEWAY1/408 { Events = 408 { bcas/cf, mfd/ce{ DigitMap { T:10, S:15, L:10, A.X.F|A.X.G|A.X.H|A.10XE|A.95XXXXXE|A.X.EA.X.E|A.1[2-9]X.E } } }, Signals { rbs/psoff } } } } TransactionResponseAck{ 389 } rgds kamath _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Fri Oct 07 10:54:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENtc1-0002m8-Js; Fri, 07 Oct 2005 10:54:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENtc0-0002m3-PO for megaco@megatron.ietf.org; Fri, 07 Oct 2005 10:54:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23439 for ; Fri, 7 Oct 2005 10:54:14 -0400 (EDT) Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENtlJ-00023v-9p for megaco@ietf.org; Fri, 07 Oct 2005 11:03:54 -0400 Received: from ma8117exch002u.wins.lucent.com (h152-148-89-177.lucent.com [152.148.89.177]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j97EsDcT025549 for ; Fri, 7 Oct 2005 09:54:13 -0500 (CDT) Received: by ma8117exch002u.inse.lucent.com with Internet Mail Service (5.5.2657.72) id ; Fri, 7 Oct 2005 10:54:13 -0400 Message-ID: <4F9DBE266768DC46A1F17E875D37164114300905@ma8117exch002u.inse.lucent.com> From: "Lu, Kang-Sen (Kang-Sen)" To: "'megaco@ietf.org'" Date: Fri, 7 Oct 2005 10:54:10 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Subject: [Megaco] question about digitMapDescriptor 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 The ABNF of meagco defines the digitMapDescriptor as "DigitMapToken EQUAL (( LBRKT digitMapValue RBRKT ) / (digitMapName [ LBRKT digitMapValue RBRKT] ))". So it is acceptable to have digitmap descriptor contains only digitmap value but no digitmap name. What is the semantic meaning of that case? Thanks. Kang-sen _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Sun Oct 09 04:41:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOWjs-0005Fy-1n; Sun, 09 Oct 2005 04:41:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOWjq-0005Eg-At for megaco@megatron.ietf.org; Sun, 09 Oct 2005 04:40:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03217 for ; Sun, 9 Oct 2005 04:40:56 -0400 (EDT) Received: from nat1.alcatel-sbell.com.cn ([202.96.203.177] helo=mail.alcatel-sbell.com.cn) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EOWtV-0004ng-51 for megaco@ietf.org; Sun, 09 Oct 2005 04:50:58 -0400 Received: from asbmail4.sbell.com.cn (localhost [127.0.0.1]) by mail.alcatel-sbell.com.cn (8.12.11/8.12.11/Alcanet1.0) with ESMTP id j998brqg020475 for ; Sun, 9 Oct 2005 16:38:06 +0800 Received: from asbmail1.sbell.com.cn ([172.24.208.61]) by asbmail4.sbell.com.cn with Microsoft SMTPSVC(5.0.2195.6713); Sun, 9 Oct 2005 16:39:38 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: [Megaco] a mistake in H.248.30 Date: Sun, 9 Oct 2005 16:37:06 +0800 Message-ID: Thread-Topic: [Megaco] a doubt about audit context of H248 V3 Thread-Index: AcW5pWxaga5XT3ZeTJS/5MYLZaNWYQACsdQgBL7QfIA= From: "FCG SHI Hao" To: X-OriginalArrivalTime: 09 Oct 2005 08:39:38.0922 (UTC) FILETIME=[FC4C30A0:01C5CCAC] X-imss-version: 2.032 X-imss-result: Passed X-imss-approveListMatch: *@alcatel-sbell.com.cn X-Spam-Score: 0.2 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 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="===============0753918863==" Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org This is a multi-part message in MIME format. --===============0753918863== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5CCAC.A1AAFF3B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5CCAC.A1AAFF3B Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hello, In ITU-T H.248.30, there are two packages "rtcpxr" and "xrbm" defined.=20 But two statistics of package "rtcpxr" have the same ID as below: R Factor---StatisticID: ns (0x0008) External R Factor---StatisticID: ns (0x0009) I think it must be a editorial mistake. Can you tell me what are their = correct names? Thanks, Shi Hao ------_=_NextPart_001_01C5CCAC.A1AAFF3B Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable [Megaco] a mistake in H.248.30

Hello,

In ITU-T = H.248.30, there are two packages "rtcpxr" and "xrbm" = defined.
But two = statistics of package "rtcpxr" have the same ID as = below:
R Factor---StatisticID: ns = (0x0008)
External R = Factor---StatisticID: ns = (0x0009)
I think it must be a = editorial mistake. Can you tell me what are their correct = names?

Thanks,
Shi Hao





------_=_NextPart_001_01C5CCAC.A1AAFF3B-- --===============0753918863== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============0753918863==-- From megaco-bounces@ietf.org Mon Oct 10 05:07:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOtcm-0001mU-J2; Mon, 10 Oct 2005 05:07:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOtck-0001mB-6w for megaco@megatron.ietf.org; Mon, 10 Oct 2005 05:07:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26362 for ; Mon, 10 Oct 2005 05:07:06 -0400 (EDT) Received: from ns.telrad.co.il ([62.90.58.229] helo=tparelay.telradnetworks.co.il) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EOtmS-0006aR-RP for Megaco@ietf.org; Mon, 10 Oct 2005 05:17:21 -0400 Received: from tparelay.telradnetworks.co.il (localhost [127.0.0.1]) by tparelay.telradnetworks.co.il (8.12.11/8.12.5) with ESMTP id j9A90gNb001889 for ; Mon, 10 Oct 2005 11:00:42 +0200 (IST) Received: from tpa-mail1.Telrad.co.il ([141.226.76.57]) by tparelay.telradnetworks.co.il (8.12.11/8.12.5) with ESMTP id j9A90fRi001875 for ; Mon, 10 Oct 2005 11:00:41 +0200 (IST) Received: by tpa-mail1.telrad.co.il with Internet Mail Service (5.5.2657.72) id <4DZZV7CW>; Mon, 10 Oct 2005 11:07:05 +0200 Message-ID: From: Tamar Nemet To: Megaco@ietf.org Date: Mon, 10 Oct 2005 11:06:57 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.1 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: Victoria Mendelevich , Michal Yachimovitz , Rima Mazorov Subject: [Megaco] Silence Suppression 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="===============1711249777==" 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. --===============1711249777== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5CD79.A7D0EE60" 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_01C5CD79.A7D0EE60 Content-Type: text/plain; charset="windows-1255" Hello, I am looking for the package which include silence suppression (ON/OFF ?). I looked at the tdmc package and I found there echo cancellation and gain control, but no silence suppression. Does anybody know where is it ? Thanks, Tamar ------_=_NextPart_001_01C5CD79.A7D0EE60 Content-Type: text/html; charset="windows-1255"
Hello,
 
I am looking for the package which include silence suppression (ON/OFF ?).
 
I looked at the tdmc package and I found there echo cancellation and gain control, but no silence suppression.
 
Does anybody know where is it ?
 
Thanks,
Tamar
------_=_NextPart_001_01C5CD79.A7D0EE60-- --===============1711249777== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============1711249777==-- From megaco-bounces@ietf.org Mon Oct 10 07:04:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOvSN-0001xn-Aw; Mon, 10 Oct 2005 07:04:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOvSL-0001xi-Sl for megaco@megatron.ietf.org; Mon, 10 Oct 2005 07:04:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01340 for ; Mon, 10 Oct 2005 07:04:30 -0400 (EDT) From: Albrecht.Schwarz@alcatel.de Received: from mailrelay2.alcatel.de ([194.113.59.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EOvcD-0000zE-Vs for Megaco@ietf.org; Mon, 10 Oct 2005 07:14:47 -0400 Received: from demail05.netfr.alcatel.fr (demail05.netfr.alcatel.fr [155.132.182.205]) by mailrelay2.alcatel.de (8.12.10/8.12.10/ICT TSC MAIL 2005) with ESMTP id j9AB46DO019626; Mon, 10 Oct 2005 13:04:06 +0200 In-Reply-To: Subject: Re: [Megaco] Silence Suppression To: Tamar Nemet X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: Date: Mon, 10 Oct 2005 13:04:04 +0200 X-MIMETrack: Serialize by Router on DEMAIL05/DE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 10/10/2005 13:04:06 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.49 on 149.204.45.73 X-Spam-Score: 0.3 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: Michal Yachimovitz , Victoria Mendelevich , Megaco@ietf.org, Rima Mazorov 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 There isn't any explicit Package so far. One solution is to use the SDP attribute according RFC 3108: 5.6.3.2 The 'silenceSupp' attribute. This is defined for ATM-based ephemeral Terminations, but some of the RFC 3108 SDP structures are used for non-ATM Terminations, too. But I'm not aware of explicit documentation. - Albrecht Tamar Nemet cc: Victoria Mendelevich , Michal Sent by: Yachimovitz , Rima Mazorov megaco-bounces@i etf.org Subject: [Megaco] Silence Suppression 10.10.2005 11:06 Hello, I am looking for the package which include silence suppression (ON/OFF ?). I looked at the tdmc package and I found there echo cancellation and gain control, but no silence suppression. Does anybody know where is it ? Thanks, Tamar_______________________________________________ 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 Oct 10 07:54:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOwEO-000108-Gq; Mon, 10 Oct 2005 07:54:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOwEN-000103-UA for megaco@megatron.ietf.org; Mon, 10 Oct 2005 07:54:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03630 for ; Mon, 10 Oct 2005 07:54:10 -0400 (EDT) Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EOwOF-0002Pe-Lq for megaco@ietf.org; Mon, 10 Oct 2005 08:04:26 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 0EE6AE40 for ; Mon, 10 Oct 2005 13:52:50 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Mon, 10 Oct 2005 13:51:07 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Mon, 10 Oct 2005 13:51:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 10 Oct 2005 13:51:05 +0200 Message-ID: Thread-Topic: [Megaco] ContextID All with terminationID All Thread-Index: AcWmzUBRJiYdlqgmRJ2Y6vJ3mdq5hQSXisLQAB5OHwAAO5R9wAS/Z37w From: "Christer Holmberg (JO/LMF)" To: X-OriginalArrivalTime: 10 Oct 2005 11:51:07.0047 (UTC) FILETIME=[E62AB370:01C5CD90] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: quoted-printable Subject: [Megaco] ABNF issue: sigIntsigDelay missing from sigParameter 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, I applogize if the following has already been discussed. In the ABNF rule for sigParameter, the sigIntsigDelay parameter is = missing. The ABNF says: sigParameter =3D sigStream / sigSignalType / sigDuration / sigOther / notifyCompletion / KeepActiveToken / sigDirection / sigRequestID ...but I guess it should say: sigParameter =3D sigStream / sigSignalType / sigDuration / sigOther / notifyCompletion / KeepActiveToken / sigDirection / sigRequestID / sigIntsigDelay Right? Regards, Christer Ericsson _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Mon Oct 10 08:17:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOwZD-0005HM-6N; Mon, 10 Oct 2005 08:15:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOwZB-0005HA-Uz for megaco@megatron.ietf.org; Mon, 10 Oct 2005 08:15:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05109 for ; Mon, 10 Oct 2005 08:15:40 -0400 (EDT) Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EOwj3-00034z-QP for Megaco@ietf.org; Mon, 10 Oct 2005 08:25:56 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id j9ACFKkT011422; Mon, 10 Oct 2005 07:15:21 -0500 (CDT) Received: from milu ([192.11.174.133]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id j9ACFK502892; Mon, 10 Oct 2005 07:15:20 -0500 (CDT) From: "Maridi R. Makaraju \(Raju\)" To: "Tamar Nemet" , Subject: RE: [Megaco] Silence Suppression Date: Mon, 10 Oct 2005 07:15:15 -0500 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal In-Reply-To: X-Spam-Score: 0.3 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: Victoria Mendelevich , Rima Mazorov , Michal Yachimovitz 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="===============1518802802==" Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org This is a multi-part message in MIME format. --===============1518802802== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0168_01C5CD6A.5CC2E0B0" This is a multi-part message in MIME format. ------=_NextPart_000_0168_01C5CD6A.5CC2E0B0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: 7bit Tamar, RFC 3108 defines 'silenceSupp' SDP parameter. You can take a look at it. (The RFC is meant for ATM bearers but the silenceSupp can be used for all bearer types). For binary encoding you can use Annex C. I don't think there is any package which attempts to defined them as they are available in AnnexC(for binary) and in RFC 3108 for text. -Raju -----Original Message----- From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org]On Behalf Of Tamar Nemet Sent: Monday, October 10, 2005 4:07 AM To: Megaco@ietf.org Cc: Victoria Mendelevich; Michal Yachimovitz; Rima Mazorov Subject: [Megaco] Silence Suppression Hello, I am looking for the package which include silence suppression (ON/OFF ?). I looked at the tdmc package and I found there echo cancellation and gain control, but no silence suppression. Does anybody know where is it ? Thanks, Tamar ------=_NextPart_000_0168_01C5CD6A.5CC2E0B0 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable
Tamar,
 
RFC = 3108 defines=20 'silenceSupp' SDP parameter. You can take a = look at=20 it.
(The RFC is meant=20 for ATM bearers but the silenceSupp can be used for
all = bearer=20 types).
For = binary=20 encoding you can use Annex C.
 
I = don't think=20 there is any package which attempts to defined them as = they
are = available in=20 AnnexC(for binary) and in RFC 3108 for text.
 
-Raju
-----Original Message-----
From: = megaco-bounces@ietf.org=20 [mailto:megaco-bounces@ietf.org]On Behalf Of Tamar=20 Nemet
Sent: Monday, October 10, 2005 4:07 AM
To:=20 Megaco@ietf.org
Cc: Victoria Mendelevich; Michal = Yachimovitz; Rima=20 Mazorov
Subject: [Megaco] Silence=20 Suppression

Hello,
 
I am looking for = the package=20 which include silence suppression (ON/OFF ?).
 
I looked at the = tdmc package=20 and I found there echo cancellation and gain control, but no silence=20 suppression.
 
Does anybody know = where is it=20 ?
 
Thanks,
Tamar
------=_NextPart_000_0168_01C5CD6A.5CC2E0B0-- --===============1518802802== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============1518802802==-- From megaco-bounces@ietf.org Tue Oct 11 01:03:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPCIZ-0001Cz-Dt; Tue, 11 Oct 2005 01:03:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPCIX-0001Cu-Hs for megaco@megatron.ietf.org; Tue, 11 Oct 2005 01:03:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15324 for ; Tue, 11 Oct 2005 01:03:31 -0400 (EDT) From: shicao@harbournetworks.com Received: from [219.235.233.45] (helo=harbournetworks.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPCSU-00046k-Ki for megaco@ietf.org; Tue, 11 Oct 2005 01:13:55 -0400 Received: (qmail 29460 invoked by uid 510); 11 Oct 2005 13:02:50 +0800 Received: from shicao@harbournetworks.com by mx1.harbournetworks.com by uid 508 with qmail-scanner-1.22-st-qms (spamassassin: 2.63. Clear:RC:1(10.1.0.48):. Processed in 0.015498 secs); 11 Oct 2005 05:02:50 -0000 ClamAV-Antivirus-Mail-From: shicao@harbournetworks.com via mx1.harbournetworks.com ClamAV-Antivirus: 1.22-st-qms (Clear:RC:1(10.1.0.48):. Processed in 0.015498 secs Process 29456) Received: from unknown (HELO ns8.harbournetworks.com) (10.1.0.48) by mx1.harbournetworks.com with SMTP; 11 Oct 2005 13:02:49 +0800 To: megaco@ietf.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Tue, 11 Oct 2005 13:01:10 +0800 X-MIMETrack: Serialize by Router on ns8/harbournetworks(Release 6.5|September 18, 2003) at 10/11/2005 13:02:49 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.3 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: [Megaco] Re: Silence Suppression (Tamar Nemet) 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 As far as I know there is no package defining "Silence suppression " in H.248 But There are some SDP option that can enable "Silence suppression ": for G729, you can send G729 paytype 18 with an attribute line "a=fmtp:18 annexb=yes(no)" to enable/diable silence suppression Silence compression is defined in G729B example: m=audio xxxx RTP/AVP 18 a=fmtp:18 annexb=yes /* enable silence suppression "a=fmtp:18 annexb=no" diable silence suppression */ For G711,there are some way to diable silence compression,such as enable VBD mode. //Hello, //I am looking for the package which include silence suppression (ON/OFF ?). //I looked at the tdmc package and I found there echo cancellation and gain //control, but no silence suppression. //Does anybody know where is it ? /*--------------------------------------------------- Scientists try to learn the world better; Engineers try to make the world better ---------------------------------------------------*/ _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Tue Oct 11 11:52:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPMQt-0003HI-8O; Tue, 11 Oct 2005 11:52:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPMQs-0003Gj-5t for megaco@megatron.ietf.org; Tue, 11 Oct 2005 11:52:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10799 for ; Tue, 11 Oct 2005 11:52:47 -0400 (EDT) Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPMaw-0007e0-Gp for megaco@ietf.org; Tue, 11 Oct 2005 12:03:18 -0400 Received: from homail.ho.lucent.com (h135-17-192-10.lucent.com [135.17.192.10]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j9BFqdtW022716 for ; Tue, 11 Oct 2005 10:52:39 -0500 (CDT) Received: from [135.112.125.111] ([135.112.125.111]) by homail.ho.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id j9BFqdI28693; Tue, 11 Oct 2005 11:52:39 -0400 (EDT) Message-ID: <434BE29E.6070302@lucent.com> Date: Tue, 11 Oct 2005 12:04:46 -0400 From: Richard Sun User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: megaco@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Subject: [Megaco] ON-OFF signals in signal 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 Does anyone know if there any reason to disallow on/off signal in the middle of the signal list? Is it because that it needs to define "The duration of a sequential signal list"? From implementation point of view, I do not see any case that the concept of "The duration of a sequential signal list" can be used, but it is usefull if on/off signal can be allowed in the middle of signal list. Thanks for any insight. -Richard QUOTE from H248.1: A sequential signal list consists of a signal list identifier and a sequence of signals to be played sequentially. Only the trailing element of the sequence of signals in a sequential signal list may be an on/off signal. The duration of a sequential signal list is the sum of the durations of the signals it contains. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Tue Oct 11 20:27:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPUST-0003KW-FF; Tue, 11 Oct 2005 20:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPUSR-0003KM-3Y for megaco@megatron.ietf.org; Tue, 11 Oct 2005 20:26:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12702 for ; Tue, 11 Oct 2005 20:26:56 -0400 (EDT) Received: from zctfs063.nortelnetworks.com ([47.164.128.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPUcc-0006cj-C4 for megaco@ietf.org; Tue, 11 Oct 2005 20:37:31 -0400 Received: from zctfhxm0.corp.nortel.com (zctfhxm0.corp.nortel.com [47.164.129.155]) by zctfs063.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j9C0Qaw26033 for ; Wed, 12 Oct 2005 02:26:37 +0200 (MEST) Received: from zcarhxp0.corp.nortel.com ([47.129.230.91]) by zctfhxm0.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 12 Oct 2005 02:26:36 +0200 Received: from [127.0.0.1] ([47.130.17.107] RDNS failed) by zcarhxp0.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 11 Oct 2005 20:26:34 -0400 Message-ID: <434C5835.30706@nortel.com> Date: Tue, 11 Oct 2005 20:26:29 -0400 From: "Tom-PT Taylor" User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Richard Sun Subject: Re: [Megaco] ON-OFF signals in signal list References: <434BE29E.6070302@lucent.com> In-Reply-To: <434BE29E.6070302@lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Oct 2005 00:26:35.0106 (UTC) FILETIME=[9A355C20:01C5CEC3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 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 It wasn't a question of duration. We figured you could get into some strange situations if you had on/off signals in the middle of the list. It would be hard to specify consistent behaviour. Richard Sun wrote: > Does anyone know if there any reason to disallow > on/off signal in the middle of the signal list? > Is it because that it needs to define > "The duration of a sequential signal list"? > > From implementation point of view, I do not see > any case that the concept of "The duration of a sequential > signal list" can be used, but it is usefull if > on/off signal can be allowed in the middle of > signal list. > > Thanks for any insight. > -Richard > > QUOTE from H248.1: > A sequential signal list consists of a signal list identifier and a > sequence of signals to be played sequentially. Only the trailing element > of the sequence of signals in a sequential signal list may be an on/off > signal. The duration of a sequential signal list is the sum of the > durations of the signals it contains. > > > _______________________________________________ > 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 Oct 13 17:50:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQAyW-00051S-Gm; Thu, 13 Oct 2005 17:50:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQAyV-00051K-Hw for megaco@megatron.ietf.org; Thu, 13 Oct 2005 17:50:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19864 for ; Thu, 13 Oct 2005 17:50:51 -0400 (EDT) Received: from sonussf1.sonusnet.com ([208.45.178.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQB93-0002Fk-Ia for megaco@ietf.org; Thu, 13 Oct 2005 18:01:52 -0400 Received: from sonusmail03.sonusnet.com (sonusmail03.sonusnet.com [10.128.32.97]) by sonussf1.sonusnet.com (8.13.3/8.13.3) with ESMTP id j9DLod4Y005726 for ; Thu, 13 Oct 2005 17:50:39 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 13 Oct 2005 17:50:37 -0400 Message-ID: Thread-Topic: Move Command Question Thread-Index: AcXQQCUOgB6uopRASeWkweHN1xq0pw== From: "Leonelli, Greg" To: X-Spam-Score: 0.2 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Subject: [Megaco] Move Command 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: , Content-Type: multipart/mixed; boundary="===============1950649072==" Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org This is a multi-part message in MIME format. --===============1950649072== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5D040.253B30D8" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5D040.253B30D8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Does the spec allow a termination to move to the CHOOSE context ? I = know the spec disallows a move to the NULL context. ------_=_NextPart_001_01C5D040.253B30D8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Does = the=20 spec allow a termination to move to the CHOOSE = context=20 ?  I know the spec disallows a move to
the = NULL=20 context.
------_=_NextPart_001_01C5D040.253B30D8-- --===============1950649072== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============1950649072==-- From megaco-bounces@ietf.org Thu Oct 13 20:59:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQDv2-0001FA-D2; Thu, 13 Oct 2005 20:59:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQDv0-0001F5-MS for megaco@megatron.ietf.org; Thu, 13 Oct 2005 20:59:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07591 for ; Thu, 13 Oct 2005 20:59:25 -0400 (EDT) Received: from nat1.alcatel-sbell.com.cn ([202.96.203.177] helo=mail.alcatel-sbell.com.cn) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQE5b-0001Xh-Qq for megaco@ietf.org; Thu, 13 Oct 2005 21:10:29 -0400 Received: from asbmail4.sbell.com.cn (localhost [127.0.0.1]) by mail.alcatel-sbell.com.cn (8.12.11/8.12.11/Alcanet1.0) with ESMTP id j9E0uVMU027574 for ; Fri, 14 Oct 2005 08:56:32 +0800 Received: from asbmail1.sbell.com.cn ([172.24.208.61]) by asbmail4.sbell.com.cn with Microsoft SMTPSVC(5.0.2195.6713); Fri, 14 Oct 2005 08:59:12 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: re: [Megaco] Move Command Question Date: Fri, 14 Oct 2005 08:59:11 +0800 Message-ID: Thread-Topic: Move Command Question Thread-Index: AcXQQCUOgB6uopRASeWkweHN1xq0pwAGX5gA From: "FCG SHI Hao" To: X-OriginalArrivalTime: 14 Oct 2005 00:59:12.0239 (UTC) FILETIME=[7D93A7F0:01C5D05A] X-imss-version: 2.032 X-imss-result: Passed X-imss-approveListMatch: *@alcatel-sbell.com.cn X-Spam-Score: 1.1 (+) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 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="===============1460683642==" Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org This is a multi-part message in MIME format. --===============1460683642== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5D05A.7D59578B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5D05A.7D59578B Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable It doesn't allow a termination to move to the CHOOSE context. "The = Context to which the Termination is moved is indicated by the target ContextId in the Action." So it should be a = specific context with contextID. =20 -----????----- ???: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org]?? = Leonelli, Greg ????: 2005?10?14? 5:51 ???: megaco@ietf.org ??: [Megaco] Move Command Question Does the spec allow a termination to move to the CHOOSE context ? I = know the spec disallows a move to the NULL context. ------_=_NextPart_001_01C5D05A.7D59578B Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
It=20 doesn't allow a termination to move to the CHOOSE context. "The Context = to which=20 the Termination is moved is
indicated by the target ContextId in the = Action."=20 So it should be a specific context with contextID.
 
-----原始邮件-----
发件= ;人: megaco-bounces@ietf.org=20 [mailto:megaco-bounces@ietf.org]代表 Leonelli, = Greg
发送时间:=20 2005年10月14日 = 5:51
收件人: = megaco@ietf.org
主题: [Megaco] Move=20 Command Question

Does = the=20 spec allow a termination to move to the CHOOSE = context=20 ?  I know the spec disallows a move to
the = NULL=20 context.
------_=_NextPart_001_01C5D05A.7D59578B-- --===============1460683642== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============1460683642==-- From megaco-bounces@ietf.org Fri Oct 14 00:01:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQGki-0006uY-5r; Fri, 14 Oct 2005 00:01:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQGkg-0006pX-4t for megaco@megatron.ietf.org; Fri, 14 Oct 2005 00:01:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14380 for ; Fri, 14 Oct 2005 00:00:57 -0400 (EDT) Received: from omta03sl.mx.bigpond.com ([144.140.92.155]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQGvJ-0005kQ-AE for megaco@ietf.org; Fri, 14 Oct 2005 00:12:01 -0400 Received: from [127.0.0.1] (really [139.168.45.176]) by omta03sl.mx.bigpond.com with ESMTP id <20051014040044.AVX15527.omta03sl.mx.bigpond.com@[127.0.0.1]>; Fri, 14 Oct 2005 04:00:44 +0000 Message-ID: <434F1E11.7010300@bigpond.net.au> Date: Fri, 14 Oct 2005 12:55:13 +1000 From: Christian Groves User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom-PT Taylor Subject: Re: =?GB2312?B?u9i4tDpSZTogW01lZ2Fjb10gYSBkb3VidCBhYm91dCBhdWRpdA==?= =?GB2312?B?IGNvbnRleHQgb2YgSDI0OCBWMw==?= References: <57b6d157c53a.57c53a57b6d1@huawei.com> <433D398A.1070903@nortel.com> In-Reply-To: <433D398A.1070903@nortel.com> Content-Type: text/plain; charset=GB2312 X-Authentication-Info: Submitted using SMTP AUTH PLAIN at omta03sl.mx.bigpond.com from [139.168.45.176] using ID cngroves@bigpond.net.au at Fri, 14 Oct 2005 04:00:42 +0000 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id AAA14380 Cc: zhuning 17035 , "Megaco IETF - Mail List \(E-mail\)" 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 all, Yes I tend to agree with Tom. Kevin you submitted this text with D410 in 01/04 any idea if you had something in particular to distinguish the cases in mind? Regards, Christian Tom-PT Taylor wrote: >Not that you were unclear, I just didn't think about it. There does >seem to be something missing. > >zhuning 17035 wrote: > =20 > >>i think my expression was not clear . >> >>in H248 V3, cotext audit is supported. there are context auditvalue and= context auditcapbility. >>command is another level structure.and maybe there is no command in a a= ction .in struct=20 >>ContextAttrAuditRequest there is no flag for audit type(value or capbil= ity). >> >> >>ContextAttrAuditRequest ::=3D SEQUENCE >>{ >> topology NULL OPTIONAL, >> emergency NULL OPTIONAL, >> priority NULL OPTIONAL, >> =A1=AD, >> iepscallind NULL OPTIONAL, >> contextPropAud SEQUENCE OF IndAudPropertyParm OPTIONAL, >> selectpriority INTEGER(0..15) OPTIONAL, >> -- to select given priority >> selectemergency BOOLEAN OPTIONAL, >> -- to select if emergency set/not set (T/F)=20 >> selectiepscallind BOOLEAN OPTIONAL, >> -- to select if IEPS set/not set (T/F) >> selectLogic SelectLogic OPTIONAL -- default is AND >>} >> >> >> >>***********************************************************************= ******************* >> This email and its attachments contain confidential information from H= UAWEI, which is intended only for the person or entity whose address is l= isted above. Any use of the information contained herein in any way (incl= uding, but not limited to, total or partial disclosure, reproduction, or = dissemination) by persons other than the intended recipient(s) is prohibi= ted. If you receive this e-mail in error, please notify the sender by pho= ne or em >>ail immediately and delete it! >> **********************************************************************= ******************* >> >>----- =D4=AD=D3=CA=BC=FE ----- >>=B4=D3: Tom-PT Taylor >>=C8=D5=C6=DA: =D0=C7=C6=DA=CE=E5, =BE=C5=D4=C2 30=C8=D5, 2005 =C9=CF=CE= =E70:23 >>=D6=F7=CC=E2: Re: [Megaco] a doubt about audit context of H248 V3 >> >> >> =20 >> >>>AuditValue and AuditCapability are two separate protocol commands.=20 >>>They >>>have been there from the beginning. It isn't necessary to make the >>>distinction within the descriptors when it is already made at=20 >>>command level. >>> >>>zhuning 17035 wrote: >>> >>> =20 >>> >>>... >>> >>> =20 >>> >>>>It is a context level audit ,not a termination level audit.So=20 >>>> =20 >>>> >>>what is >>> >>> =20 >>> >>>>the flag of audit type in it? i mean that how to indicate that=20 >>>> =20 >>>> >>>it is >>> >>> =20 >>> >>>>a value audit or capbility audit in of context audit ? >>>> >>>> =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 Fri Oct 14 00:01:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQGkj-0006vF-AY; Fri, 14 Oct 2005 00:01:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQGkg-0006pa-5Y for megaco@megatron.ietf.org; Fri, 14 Oct 2005 00:01:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14381 for ; Fri, 14 Oct 2005 00:00:57 -0400 (EDT) Received: from omta04sl.mx.bigpond.com ([144.140.93.156]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQGvJ-0005kP-AN for megaco@ietf.org; Fri, 14 Oct 2005 00:12:01 -0400 Received: from [127.0.0.1] (really [139.168.45.176]) by omta04sl.mx.bigpond.com with ESMTP id <20051014040043.CTHU23411.omta04sl.mx.bigpond.com@[127.0.0.1]>; Fri, 14 Oct 2005 04:00:43 +0000 Message-ID: <434F0341.8040305@bigpond.net.au> Date: Fri, 14 Oct 2005 11:00:49 +1000 From: Christian Groves User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kamitses, Jerry" Subject: Re: [Megaco] Generic announcement package Rules (h.248.7) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH PLAIN at omta04sl.mx.bigpond.com from [139.168.45.176] using ID cngroves@bigpond.net.au at Fri, 14 Oct 2005 04:00:42 +0000 X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 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 Hello Jerry, Please see below. Regards, Christian Kamitses, Jerry wrote: >During interop testing some confusion has arisen regarding how "flexible" >the an/apf is intended to be. > >As defined this signal supports the parameter "an" to specify the desired >announcement. Is only one instance of this parameter allowed per apf signal? > > > [CHG] You can only have one instance of a parameter eg. "an" if it occurs twice you will get error code 456. >If the MGC wants to string together a sequence of announcements to play >in succession is it valid to use a comma separated list of "an" parameters, >using a signal descriptor such as ... > signals {an/apf{an=600,an=911}} > > [CHG] See above comment. >Does h.248.7 somehow preclude multiple instances of the "an" parameter >(and if so shouldn't a specification actually make this point clearly?) > > > [CHG] Yes H.248.7 is sketchy on this as it states "enumeration of announcements". It the "of announcements" which leads to the confusion. Enumeration is a single value unless parameter type "sub-list of Enumeration" is used. I believe the original intention was a single value (you can check pl-35 from Feb 2000). >The syntax > signals {an/apf{an=600},an/apf{an=911}} >would not have this effect since in this case the two signals should play >concurrently. > >Must the sequence of an/apf signals be encapsulated in a signal list signal? > > > [CHG] Using a signal list would be the best way to play a list of announcements. >_______________________________________________ >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 Oct 14 00:01:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQGkk-0006wI-2X; Fri, 14 Oct 2005 00:01:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQGkg-0006rP-CD for megaco@megatron.ietf.org; Fri, 14 Oct 2005 00:01:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14385 for ; Fri, 14 Oct 2005 00:00:58 -0400 (EDT) Received: from omta02sl.mx.bigpond.com ([144.140.93.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQGvJ-0005kS-AJ for megaco@ietf.org; Fri, 14 Oct 2005 00:12:02 -0400 Received: from [127.0.0.1] (really [139.168.45.176]) by omta02sl.mx.bigpond.com with ESMTP id <20051014040046.ZVYS21196.omta02sl.mx.bigpond.com@[127.0.0.1]>; Fri, 14 Oct 2005 04:00:46 +0000 Message-ID: <434F209D.6000107@bigpond.net.au> Date: Fri, 14 Oct 2005 13:06:05 +1000 From: Christian Groves User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Deepak Pokharna Subject: Re: [Megaco] Query on ASN grammer References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH PLAIN at omta02sl.mx.bigpond.com from [139.168.45.176] using ID cngroves@bigpond.net.au at Fri, 14 Oct 2005 04:00:44 +0000 X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 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 Hello Depak, I'm not sure what the problem is. AmmRequest contains a "SEQUENCE OF" descriptors. The note simply says that you shouldn't have 2 or more of the same descriptors per command. My understanding is that a sequence of could be a null sequence. Christian Deepak Pokharna wrote: > Hi > > According to V2 Draft (ASN Grammar) it says at most one > descriptor is required in list of descriptor in AmmRequest..But it has > not made the descriptors as optional too so it means one Descriptor > should be there in Add, Move and Mod Request. Here it has difference > from ABNF grammar which have made the list of descriptor as optional. > Can some one clarify this. > > > > Command ::= CHOICE > > { > > addReq AmmRequest, > > moveReq AmmRequest, > > modReq AmmRequest, > > -- Add, Move, Modify requests have the same parameters > > subtractReq SubtractRequest, > > auditCapRequest AuditRequest, > > auditValueRequest AuditRequest, > > notifyReq NotifyRequest, > > serviceChangeReq ServiceChangeRequest, > > ... > > } > > > > > > AmmRequest ::= SEQUENCE > > { > > terminationID TerminationIDList, > > */descriptors SEQUENCE OF AmmDescriptor/*, > > * -- At most one descriptor of each type (see AmmDescriptor) * > > * -- allowed in the sequence. * > > * ... * > > > > > > Groves et al Expires - October 2003 [Page 103] > > > Megaco Protocol version 2 April 2003 > > > > > > } > > > > AmmDescriptor ::= CHOICE > > { > > mediaDescriptor MediaDescriptor, > > modemDescriptor ModemDescriptor, > > muxDescriptor MuxDescriptor, > > eventsDescriptor EventsDescriptor, > > eventBufferDescriptor EventBufferDescriptor, > > signalsDescriptor SignalsDescriptor, > > digitMapDescriptor DigitMapDescriptor, > > auditDescriptor AuditDescriptor, > > ... > > } > > > > Regards > > Deepak > > > >------------------------------------------------------------------------ > >_______________________________________________ >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 Oct 14 00:01:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQGkp-0006ye-Sd; Fri, 14 Oct 2005 00:01:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQGko-0006wx-Lj for megaco@megatron.ietf.org; Fri, 14 Oct 2005 00:01:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14393 for ; Fri, 14 Oct 2005 00:01:06 -0400 (EDT) Received: from omta01sl.mx.bigpond.com ([144.140.92.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQGvR-0005ke-OY for megaco@ietf.org; Fri, 14 Oct 2005 00:12:11 -0400 Received: from [127.0.0.1] (really [139.168.45.176]) by omta01sl.mx.bigpond.com with ESMTP id <20051014040057.VKXC5164.omta01sl.mx.bigpond.com@[127.0.0.1]>; Fri, 14 Oct 2005 04:00:57 +0000 Message-ID: <434F27FB.1090802@bigpond.net.au> Date: Fri, 14 Oct 2005 13:37:31 +1000 From: Christian Groves User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: FCG SHI Hao Subject: Re: [Megaco] a mistake in H.248.30 References: In-Reply-To: Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH PLAIN at omta01sl.mx.bigpond.com from [139.168.45.176] using ID cngroves@bigpond.net.au at Fri, 14 Oct 2005 04:00:56 +0000 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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 Hello Shi Hao, Seems like a cut and paste error on both the statistics. I would say the correct names should be: R Factor --> rf (0x0008) External R Factor --> efr (0x0009) These should be picked up by the editors guide and a corigenda. Christian FCG SHI Hao wrote: > Hello, > > In ITU-T H.248.30, there are two packages "rtcpxr" and "xrbm" defined. > But two statistics of package "rtcpxr" have the same ID as below: > *R Factor---*StatisticID: ns (0x0008) > *External R Factor---*StatisticID: ns (0x0009) > I think it must be a editorial mistake. Can you tell me what are their > correct names? > > Thanks, > Shi Hao > > > > > >------------------------------------------------------------------------ > >_______________________________________________ >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 Oct 14 00:01:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQGkr-0006zB-Lm; Fri, 14 Oct 2005 00:01:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQGkq-0006z1-2r for megaco@megatron.ietf.org; Fri, 14 Oct 2005 00:01:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14398 for ; Fri, 14 Oct 2005 00:01:07 -0400 (EDT) Received: from omta05sl.mx.bigpond.com ([144.140.93.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQGvT-0005kf-56 for Megaco@ietf.org; Fri, 14 Oct 2005 00:12:12 -0400 Received: from [127.0.0.1] (really [139.168.45.176]) by omta05sl.mx.bigpond.com with ESMTP id <20051014040058.BPSI15509.omta05sl.mx.bigpond.com@[127.0.0.1]>; Fri, 14 Oct 2005 04:00:58 +0000 Message-ID: <434F290C.20607@bigpond.net.au> Date: Fri, 14 Oct 2005 13:42:04 +1000 From: Christian Groves User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Maridi R. Makaraju (Raju)" Subject: Re: [Megaco] Silence Suppression References: In-Reply-To: Content-Type: text/plain; charset=windows-1255; format=flowed Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH PLAIN at omta05sl.mx.bigpond.com from [139.168.45.176] using ID cngroves@bigpond.net.au at Fri, 14 Oct 2005 04:00:56 +0000 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit Cc: Michal Yachimovitz , Victoria Mendelevich , Megaco@ietf.org, Rima Mazorov 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 all, The value of Acodec (Annex C and used by Q.1950/3GPP Ts29.232) may also specify silence suppression for a given codec type. See the codec type subfield in Q.765.5 Christian Maridi R. Makaraju (Raju) wrote: > Tamar, > > RFC 3108 defines 'silenceSupp' > SDP parameter. You can take a look at it. > (The RFC is meant for ATM bearers but the silenceSupp can be used for > all bearer types). > For binary encoding you can use Annex C. > > I don't think there is any package which attempts to defined them as they > are available in AnnexC(for binary) and in RFC 3108 for text. > > -Raju > > -----Original Message----- > *From:* megaco-bounces@ietf.org > [mailto:megaco-bounces@ietf.org]*On Behalf Of *Tamar Nemet > *Sent:* Monday, October 10, 2005 4:07 AM > *To:* Megaco@ietf.org > *Cc:* Victoria Mendelevich; Michal Yachimovitz; Rima Mazorov > *Subject:* [Megaco] Silence Suppression > > Hello, > > I am looking for the package which include silence suppression > (ON/OFF ?). > > I looked at the tdmc package and I found there echo cancellation > and gain control, but no silence suppression. > > Does anybody know where is it ? > > Thanks, > Tamar > >------------------------------------------------------------------------ > >_______________________________________________ >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 Oct 14 01:04:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQHjq-0002WI-PA; Fri, 14 Oct 2005 01:04:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQHjm-0002Qq-Ir for megaco@megatron.ietf.org; Fri, 14 Oct 2005 01:04:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17528 for ; Fri, 14 Oct 2005 01:04:05 -0400 (EDT) Received: from defender.ccpu.com ([216.54.134.34] helo=smtp.ccpu.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQHuQ-0007Lw-1j for megaco@ietf.org; Fri, 14 Oct 2005 01:15:11 -0400 Received: from sd-exchange.ccsd.ccpu.com (sd-exchange.ccpu.com [172.16.0.203]) by smtp.ccpu.com (Postfix) with ESMTP id 119B034695C; Thu, 13 Oct 2005 22:04:00 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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] Query on ASN grammer Date: Thu, 13 Oct 2005 22:03:59 -0700 Message-ID: Thread-Topic: [Megaco] Query on ASN grammer Thread-Index: AcXQdHAGNjiQ1ggUSOCxvQsaPtcxBAAB1EhQ From: "Rashim Anand" To: "Christian Groves" , "Deepak Pokharna" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Content-Transfer-Encoding: quoted-printable 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 Hi Christian, I think that for consistency and clarity purposes "OPTIONAL" should be specified. There are other examples of using "OPTIONAL" in SEQUENCE OF s which are optional in the spec. One such example is - ContextRequest ::=3D=3D SEQUENCE { priority INTEGER(0..15) OPTIONAL, emergency BOOLEAN OPTIONAL, topologyReq SEQUENCE OF TopologyRequest OPTIONAL, ... } This will prevent some confusion. -Rashim Anand -----Original Message----- From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf Of Christian Groves Sent: Thursday, October 13, 2005 8:06 PM To: Deepak Pokharna Cc: megaco@ietf.org Subject: Re: [Megaco] Query on ASN grammer Hello Depak, I'm not sure what the problem is. AmmRequest contains a "SEQUENCE OF"=20 descriptors. The note simply says that you shouldn't have 2 or more of=20 the same descriptors per command. My understanding is that a sequence of could be a null sequence. Christian Deepak Pokharna wrote: > Hi > > According to V2 Draft (ASN Grammar) it says at most one > descriptor is required in list of descriptor in AmmRequest..But it has > not made the descriptors as optional too so it means one Descriptor=20 > should be there in Add, Move and Mod Request. Here it has difference=20 > from ABNF grammar which have made the list of descriptor as optional.=20 > Can some one clarify this. > > =20 > > Command ::=3D CHOICE > > { > > addReq AmmRequest, > > moveReq AmmRequest, > > modReq AmmRequest, > > -- Add, Move, Modify requests have the same parameters > > subtractReq SubtractRequest, > > auditCapRequest AuditRequest, > > auditValueRequest AuditRequest, > > notifyReq NotifyRequest, > > serviceChangeReq ServiceChangeRequest, > > ... > > } > > =20 > > =20 > > AmmRequest ::=3D SEQUENCE > > { > > terminationID TerminationIDList, > > */descriptors SEQUENCE OF AmmDescriptor/*, > > * -- At most one descriptor of each type (see AmmDescriptor) * > > * -- allowed in the sequence. * > > * ... * > > =20 > > =20 > > Groves et al Expires - October 2003 [Page 103] > > > Megaco Protocol version 2 April 2003 > > =20 > > =20 > > } > > =20 > > AmmDescriptor ::=3D CHOICE > > { > > mediaDescriptor MediaDescriptor, > > modemDescriptor ModemDescriptor, > > muxDescriptor MuxDescriptor, > > eventsDescriptor EventsDescriptor, > > eventBufferDescriptor EventBufferDescriptor, > > signalsDescriptor SignalsDescriptor, > > digitMapDescriptor DigitMapDescriptor, > > auditDescriptor AuditDescriptor, > > ... > > } > > =20 > > Regards > > Deepak > > =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 Oct 14 03:12:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQJjp-0000Ap-TI; Fri, 14 Oct 2005 03:12:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQJjo-0000Ac-68 for megaco@megatron.ietf.org; Fri, 14 Oct 2005 03:12:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22143 for ; Fri, 14 Oct 2005 03:12:14 -0400 (EDT) Received: from omta01sl.mx.bigpond.com ([144.140.92.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQJuS-0001xM-8K for megaco@ietf.org; Fri, 14 Oct 2005 03:23:21 -0400 Received: from [127.0.0.1] (really [139.168.45.176]) by omta01sl.mx.bigpond.com with ESMTP id <20051014071157.DLMK5164.omta01sl.mx.bigpond.com@[127.0.0.1]>; Fri, 14 Oct 2005 07:11:57 +0000 Message-ID: <434F5A3C.9060507@bigpond.net.au> Date: Fri, 14 Oct 2005 17:11:56 +1000 From: Christian Groves User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rashim Anand Subject: Re: [Megaco] Query on ASN grammer References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH PLAIN at omta01sl.mx.bigpond.com from [139.168.45.176] using ID cngroves@bigpond.net.au at Fri, 14 Oct 2005 07:11:55 +0000 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93df555cbdbcdae9621e5b95d44b301e 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 Hello Rashim, I not sure that we can just retrospectively had optionals to the ASN.1. My understanding is that this would not be backwards compatible. Christian Rashim Anand wrote: >Hi Christian, > >I think that for consistency and clarity purposes "OPTIONAL" should be >specified. There are other examples of using "OPTIONAL" in SEQUENCE OF s >which are optional in the spec. One such example is - > >ContextRequest ::== SEQUENCE >{ > priority INTEGER(0..15) OPTIONAL, > emergency BOOLEAN OPTIONAL, > topologyReq SEQUENCE OF TopologyRequest OPTIONAL, > ... >} > >This will prevent some confusion. >-Rashim Anand > > > > >-----Original Message----- >From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf >Of Christian Groves >Sent: Thursday, October 13, 2005 8:06 PM >To: Deepak Pokharna >Cc: megaco@ietf.org >Subject: Re: [Megaco] Query on ASN grammer > > >Hello Depak, > >I'm not sure what the problem is. AmmRequest contains a "SEQUENCE OF" >descriptors. The note simply says that you shouldn't have 2 or more of >the same descriptors per command. My understanding is that a sequence of > >could be a null sequence. > >Christian > >Deepak Pokharna wrote: > > > >>Hi >> >> According to V2 Draft (ASN Grammar) it says at most one >>descriptor is required in list of descriptor in AmmRequest..But it has >> >> > > > >>not made the descriptors as optional too so it means one Descriptor >>should be there in Add, Move and Mod Request. Here it has difference >>from ABNF grammar which have made the list of descriptor as optional. >>Can some one clarify this. >> >> >> >> Command ::= CHOICE >> >> { >> >> addReq AmmRequest, >> >> moveReq AmmRequest, >> >> modReq AmmRequest, >> >> -- Add, Move, Modify requests have the same parameters >> >> subtractReq SubtractRequest, >> >> auditCapRequest AuditRequest, >> >> auditValueRequest AuditRequest, >> >> notifyReq NotifyRequest, >> >> serviceChangeReq ServiceChangeRequest, >> >> ... >> >> } >> >> >> >> >> >> AmmRequest ::= SEQUENCE >> >> { >> >> terminationID TerminationIDList, >> >> */descriptors SEQUENCE OF AmmDescriptor/*, >> >>* -- At most one descriptor of each type (see AmmDescriptor) * >> >>* -- allowed in the sequence. * >> >>* ... * >> >> >> >> >> >> Groves et al Expires - October 2003 [Page >> >> >103] > > >> Megaco Protocol version 2 April >> >> >2003 > > >> >> >> >> >> } >> >> >> >> AmmDescriptor ::= CHOICE >> >> { >> >> mediaDescriptor MediaDescriptor, >> >> modemDescriptor ModemDescriptor, >> >> muxDescriptor MuxDescriptor, >> >> eventsDescriptor EventsDescriptor, >> >> eventBufferDescriptor EventBufferDescriptor, >> >> signalsDescriptor SignalsDescriptor, >> >> digitMapDescriptor DigitMapDescriptor, >> >> auditDescriptor AuditDescriptor, >> >> ... >> >> } >> >> >> >>Regards >> >>Deepak >> >> >> >>----------------------------------------------------------------------- >>- >> >>_______________________________________________ >>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 Fri Oct 14 06:02:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQMO7-0002VW-8Y; Fri, 14 Oct 2005 06:02:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQMO5-0002V2-Rx for megaco@megatron.ietf.org; Fri, 14 Oct 2005 06:02:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29525 for ; Fri, 14 Oct 2005 06:02:01 -0400 (EDT) Received: from smtp.dataconnection.com ([192.91.191.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQMYl-0006V3-10 for megaco@ietf.org; Fri, 14 Oct 2005 06:13:09 -0400 Received: from enfimail1.datcon.co.uk ([172.19.14.253]) by smtp.dataconnection.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Oct 2005 11:01:46 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Megaco] Move Command Question Date: Fri, 14 Oct 2005 11:01:45 +0100 Message-ID: <8E4A9A66F7AED54C89F478AF4477C7D81EAAC7@enfimail1.datcon.co.uk> Thread-Topic: [Megaco] Move Command Question Thread-Index: AcXQQCUOgB6uopRASeWkweHN1xq0pwAGX5gAABKj3GA= From: "Jon Rowland" To: "FCG SHI Hao" , X-OriginalArrivalTime: 14 Oct 2005 10:01:46.0252 (UTC) FILETIME=[4947D4C0:01C5D0A6] X-Spam-Score: 1.1 (+) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Cc: 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="===============0056671146==" Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org This is a multi-part message in MIME format. --===============0056671146== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5D0A6.493A7138" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5D0A6.493A7138 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: quoted-printable Sorry, but I don't agree. Nothing about the below text specifically = prohibits using CHOOSE (which is effectively a context ID), although I = can see that it could be worded more clearly. CHOOSE just asks the MG to = create a new context which is a perfectly valid thing to ask it to do on = a MOVE request. =20 Moving to CHOOSE is the only way to move a termination into a new = context by itself in an atomic fashion. This would be a good way, for = example, to implement 'call waiting' function in telephony applications. = Using SUBTRACT/ADD doesn't really do the trick as well, because there = are various side effects of a subtract, such as resetting of signals and = events descriptors. =20 Regards, Jon. =20 ________________________________ From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On = Behalf Of FCG SHI Hao Sent: 14 October 2005 01:59 To: megaco@ietf.org Subject: re: [Megaco] Move Command Question =09 =09 It doesn't allow a termination to move to the CHOOSE context. "The = Context to which the Termination is moved is indicated by the target ContextId in the Action." So it should be a = specific context with contextID. =20 -----=D4=AD=CA=BC=D3=CA=BC=FE----- =B7=A2=BC=FE=C8=CB: megaco-bounces@ietf.org = [mailto:megaco-bounces@ietf.org]=B4=FA=B1=ED Leonelli, Greg =B7=A2=CB=CD=CA=B1=BC=E4: 2005=C4=EA10=D4=C214=C8=D5 5:51 =CA=D5=BC=FE=C8=CB: megaco@ietf.org =D6=F7=CC=E2: [Megaco] Move Command Question =09 =09 Does the spec allow a termination to move to the CHOOSE context ? I = know the spec disallows a move to the NULL context. ------_=_NextPart_001_01C5D0A6.493A7138 Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: quoted-printable
Sorry, but I don't agree. Nothing about the = below text=20 specifically prohibits using CHOOSE (which is effectively a context ID), = although I can see that it could be worded more clearly. CHOOSE just = asks the MG=20 to create a new context which is a perfectly valid thing to ask it to do = on a=20 MOVE request.
 
Moving to CHOOSE is the only way to move a = termination into=20 a new context by itself in an atomic fashion. This would be a good way, = for=20 example, to implement 'call waiting' function in telephony applications. = Using=20 SUBTRACT/ADD doesn't really do the trick as well, because there are = various side=20 effects of a subtract, such as resetting of signals and events=20 descriptors.
 
Regards,
Jon.
 

From: megaco-bounces@ietf.org=20 [mailto:megaco-bounces@ietf.org] On Behalf Of FCG SHI=20 Hao
Sent: 14 October 2005 01:59
To:=20 megaco@ietf.org
Subject: re: [Megaco] Move Command=20 Question

It=20 doesn't allow a termination to move to the CHOOSE context. "The = Context to=20 which the Termination is moved is
indicated by the target ContextId = in the=20 Action." So it should be a specific context with=20 contextID.
 
-----=D4=AD=CA=BC=D3=CA=BC=FE-----
=B7=A2=BC=FE=C8=CB:= megaco-bounces@ietf.org=20 [mailto:megaco-bounces@ietf.org]=B4=FA=B1=ED Leonelli, = Greg
=B7=A2=CB=CD=CA=B1=BC=E4:=20 2005=C4=EA10=D4=C214=C8=D5 5:51
=CA=D5=BC=FE=C8=CB: = megaco@ietf.org
=D6=F7=CC=E2: [Megaco] Move=20 Command Question

Does the=20 spec allow a termination to move to the CHOOSE = context=20 ?  I know the spec disallows a move to
the NULL=20 context.
------_=_NextPart_001_01C5D0A6.493A7138-- --===============0056671146== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============0056671146==-- From megaco-bounces@ietf.org Fri Oct 14 08:32:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQOk7-0007Lo-Ij; Fri, 14 Oct 2005 08:32:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQLhQ-0005Is-AC for megaco@megatron.ietf.org; Fri, 14 Oct 2005 05:18:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27532 for ; Fri, 14 Oct 2005 05:17:53 -0400 (EDT) Received: from bay9-f19.bay9.hotmail.com ([64.4.46.123] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQLs1-0005M1-4g for megaco@ietf.org; Fri, 14 Oct 2005 05:29:00 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 14 Oct 2005 02:17:41 -0700 Message-ID: Received: from 63.236.40.150 by by9fd.bay9.hotmail.msn.com with HTTP; Fri, 14 Oct 2005 09:17:41 GMT X-Originating-IP: [194.237.142.21] X-Originating-Email: [jminguito75@hotmail.com] X-Sender: jminguito75@hotmail.com From: "Julio Martinez Minguito" To: megaco@ietf.org Subject: re: [Megaco] Move Command Question Date: Fri, 14 Oct 2005 09:17:41 +0000 Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed X-OriginalArrivalTime: 14 Oct 2005 09:17:41.0632 (UTC) FILETIME=[20F6D800:01C5D0A0] X-Spam-Score: 1.6 (+) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 X-Mailman-Approved-At: Fri, 14 Oct 2005 08:32:57 -0400 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: We have the opinion that it's valid to move a termination to a choose context. The GW shall create a new context for that moved termination, and indicate the new context id in the command reply. /Julio Date: Fri, 14 Oct 2005 08:59:11 +0800 From: "FCG SHI Hao" Subject: re: [Megaco] Move Command Question To: Message-ID: Content-Type: text/plain; charset="iso-8859-1" It doesn't allow a termination to move to the CHOOSE context. "The Context to which the Termination is moved is indicated by the target ContextId in the Action." So it should be a specific context with contextID. -----原始邮件----- 发件人: megaco-bounces at ietf.org [mailto:megaco-bounces at ietf.org]代表 Leonelli, Greg 发送时间: 2005年10月14日 5:51 收件人: megaco at ietf.org 主题: [Megaco] Move Command Question Does the spec allow a termination to move to the CHOOSE context ? I know the spec disallows a move to the NULL context. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Fri Oct 14 10:47:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQQpw-0000qd-OS; Fri, 14 Oct 2005 10:47:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQQpu-0000qV-T5 for megaco@megatron.ietf.org; Fri, 14 Oct 2005 10:47:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14763 for ; Fri, 14 Oct 2005 10:47:02 -0400 (EDT) Received: from sonussf1.sonusnet.com ([208.45.178.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQR0e-0005ez-Gg for megaco@ietf.org; Fri, 14 Oct 2005 10:58:13 -0400 Received: from sonusmail03.sonusnet.com (sonusmail03.sonusnet.com [10.128.32.97]) by sonussf1.sonusnet.com (8.13.3/8.13.3) with ESMTP id j9EEkoxb030041; Fri, 14 Oct 2005 10:46:50 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Megaco] Move Command Question Date: Fri, 14 Oct 2005 10:46:47 -0400 Message-ID: Thread-Topic: [Megaco] Move Command Question Thread-Index: AcXQQCUOgB6uopRASeWkweHN1xq0pwAGX5gAABKj3GAACgMfAA== From: "Kamitses, Jerry" To: "Jon Rowland" , "FCG SHI Hao" , X-Spam-Score: 0.8 (/) X-Scan-Signature: f0b5a4216bfa030ed8a6f68d1833f8ae Cc: 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="===============1483973269==" Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org This is a multi-part message in MIME format. --===============1483973269== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5D0CE.1A3D5018" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5D0CE.1A3D5018 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable The consensus seems to have come down on the side of allowing CHOOSE for = the context=20 ID in a move command. In particular, this allows sending an action with = context ID CHOOSE=20 containing a combination of ADD commands (to terminations in the NULL = context) and MOVE=20 commands (to terminations in a non-NULL context). I only mention this = point since, from=20 this perspective, it becomes a little more apparent that this is both a = reasonable and useful=20 capability. =20 =20 As for the SUBTRACT/ADD alternative, another item for the list of = missing tricks here is that=20 this option is a non-starter for an ephemeral termination, since = SUBTRACT instantly kills them. So now this becomes a reasonable, useful, and essential capability. =20 =20 -----Original Message----- From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org]On Behalf = Of Jon Rowland Sent: Friday, October 14, 2005 6:02 AM To: FCG SHI Hao; megaco@ietf.org Subject: RE: [Megaco] Move Command Question Sorry, but I don't agree. Nothing about the below text specifically = prohibits using CHOOSE (which is effectively a context ID), although I = can see that it could be worded more clearly. CHOOSE just asks the MG to = create a new context which is a perfectly valid thing to ask it to do on = a MOVE request. =20 Moving to CHOOSE is the only way to move a termination into a new = context by itself in an atomic fashion. This would be a good way, for = example, to implement 'call waiting' function in telephony applications. = Using SUBTRACT/ADD doesn't really do the trick as well, because there = are various side effects of a subtract, such as resetting of signals and = events descriptors. =20 Regards, Jon. =20 _____ =20 From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf = Of FCG SHI Hao Sent: 14 October 2005 01:59 To: megaco@ietf.org Subject: re: [Megaco] Move Command Question It doesn't allow a termination to move to the CHOOSE context. "The = Context to which the Termination is moved is indicated by the target ContextId in the Action." So it should be a = specific context with contextID. =20 -----=D4=AD=CA=BC=D3=CA=BC=FE----- =B7=A2=BC=FE=C8=CB: megaco-bounces@ietf.org = [mailto:megaco-bounces@ietf.org]=B4=FA=B1=ED Leonelli, Greg =B7=A2=CB=CD=CA=B1=BC=E4: 2005=C4=EA10=D4=C214=C8=D5 5:51 =CA=D5=BC=FE=C8=CB: megaco@ietf.org =D6=F7=CC=E2: [Megaco] Move Command Question Does the spec allow a termination to move to the CHOOSE context ? I = know the spec disallows a move to the NULL context. ------_=_NextPart_001_01C5D0CE.1A3D5018 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
The=20 consensus seems to have come down on the side of allowing CHOOSE=20 for the context
ID=20 in a move command.  In particular, this allows=20 sending an action with context ID=20 CHOOSE
containing a combination of ADD commands=20 (to terminations in the NULL context) and MOVE
commands (to terminations in a non-NULL context). I only = mention=20 this point since, from
this=20 perspective, it becomes a little more apparent that this is both a = reasonable=20 and useful
capability. 
 
As=20 for the SUBTRACT/ADD alternative, another item for the list of = missing=20 tricks here is that
this=20 option is a non-starter for an ephemeral termination, since = SUBTRACT=20 instantly kills them.
So=20 now this becomes a reasonable, useful, and essential capability. 
 
-----Original Message-----
From: = megaco-bounces@ietf.org=20 [mailto:megaco-bounces@ietf.org]On Behalf Of Jon=20 Rowland
Sent: Friday, October 14, 2005 6:02 AM
To: = FCG SHI=20 Hao; megaco@ietf.org
Subject: RE: [Megaco] Move Command=20 Question

Sorry, but I don't agree. Nothing about the = below text=20 specifically prohibits using CHOOSE (which is effectively a context = ID),=20 although I can see that it could be worded more clearly. CHOOSE just = asks the=20 MG to create a new context which is a perfectly valid thing to ask it = to do on=20 a MOVE request.
 
Moving to CHOOSE is the only way to move a = termination=20 into a new context by itself in an atomic fashion. This would be a = good way,=20 for example, to implement 'call waiting' function in telephony = applications.=20 Using SUBTRACT/ADD doesn't really do the trick as well, because there = are=20 various side effects of a subtract, such as resetting of signals and = events=20 descriptors.
 
Regards,
Jon.
 

From: megaco-bounces@ietf.org=20 [mailto:megaco-bounces@ietf.org] On Behalf Of FCG SHI=20 Hao
Sent: 14 October 2005 01:59
To:=20 megaco@ietf.org
Subject: re: [Megaco] Move Command=20 Question

It=20 doesn't allow a termination to move to the CHOOSE context. "The = Context to=20 which the Termination is moved is
indicated by the target = ContextId in=20 the Action." So it should be a specific context with=20 contextID.
 
-----=D4=AD=CA=BC=D3=CA=BC=FE-----
=B7=A2=BC=FE=C8=CB:= megaco-bounces@ietf.org=20 [mailto:megaco-bounces@ietf.org]=B4=FA=B1=ED Leonelli, = Greg
=B7=A2=CB=CD=CA=B1=BC=E4:=20 2005=C4=EA10=D4=C214=C8=D5 5:51
=CA=D5=BC=FE=C8=CB: = megaco@ietf.org
=D6=F7=CC=E2: [Megaco]=20 Move Command Question

Does the=20 spec allow a termination to move to the CHOOSE = context=20 ?  I know the spec disallows a move to
the NULL=20 = context.
------_=_NextPart_001_01C5D0CE.1A3D5018-- --===============1483973269== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============1483973269==-- From megaco-bounces@ietf.org Fri Oct 14 10:55:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQQxd-0004ZW-21; Fri, 14 Oct 2005 10:55:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQQxb-0004Yp-QL for megaco@megatron.ietf.org; Fri, 14 Oct 2005 10:55:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16395 for ; Fri, 14 Oct 2005 10:54:59 -0400 (EDT) Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQR8K-0006IE-CQ for megaco@ietf.org; Fri, 14 Oct 2005 11:06:10 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j9EEsfs12144; Fri, 14 Oct 2005 10:54:41 -0400 (EDT) Received: from zcarhxp0.corp.nortel.com ([47.129.230.91]) by zrc2hxm2.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 14 Oct 2005 09:54:40 -0500 Received: from [127.0.0.1] ([47.130.24.67] RDNS failed) by zcarhxp0.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 14 Oct 2005 10:54:39 -0400 Message-ID: <434FC6A9.2040309@nortel.com> Date: Fri, 14 Oct 2005 10:54:33 -0400 From: "Tom-PT Taylor" User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jon Rowland Subject: Re: [Megaco] Move Command Question References: <8E4A9A66F7AED54C89F478AF4477C7D81EAAC7@enfimail1.datcon.co.uk> In-Reply-To: <8E4A9A66F7AED54C89F478AF4477C7D81EAAC7@enfimail1.datcon.co.uk> Content-Type: text/plain; charset=GB2312 X-OriginalArrivalTime: 14 Oct 2005 14:54:39.0263 (UTC) FILETIME=[339C82F0:01C5D0CF] Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by zrtps0kn.nortelnetworks.com id j9EEsfs12144 X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: quoted-printable Cc: FCG SHI Hao , 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 I agree. Look at Figure 2 in section 6 of H.248.1/RFC 3015. That was achieved using a MOVE to CHOOSE. Jon Rowland wrote: > Sorry, but I don't agree. Nothing about the below text specifically pro= hibits using CHOOSE (which is effectively a context ID), although I can s= ee that it could be worded more clearly. CHOOSE just asks the MG to creat= e a new context which is a perfectly valid thing to ask it to do on a MOV= E request. > =20 > Moving to CHOOSE is the only way to move a termination into a new conte= xt by itself in an atomic fashion. This would be a good way, for example,= to implement 'call waiting' function in telephony applications. Using SU= BTRACT/ADD doesn't really do the trick as well, because there are various= side effects of a subtract, such as resetting of signals and events desc= riptors. > =20 > Regards, > Jon. > =20 >=20 >=20 > ________________________________ >=20 > From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Beha= lf Of FCG SHI Hao > Sent: 14 October 2005 01:59 > To: megaco@ietf.org > Subject: re: [Megaco] Move Command Question > =09 > =09 > It doesn't allow a termination to move to the CHOOSE context. "The Con= text to which the Termination is moved is > indicated by the target ContextId in the Action." So it should be a sp= ecific context with contextID. > =20 >=20 > -----=D4=AD=CA=BC=D3=CA=BC=FE----- > =B7=A2=BC=FE=C8=CB: megaco-bounces@ietf.org [mailto:megaco-bounces@ie= tf.org]=B4=FA=B1=ED Leonelli, Greg > =B7=A2=CB=CD=CA=B1=BC=E4: 2005=C4=EA10=D4=C214=C8=D5 5:51 > =CA=D5=BC=FE=C8=CB: megaco@ietf.org > =D6=F7=CC=E2: [Megaco] Move Command Question > =09 > =09 > Does the spec allow a termination to move to the CHOOSE context ? I = know the spec disallows a move to > the NULL context. >=20 >=20 >=20 >=20 > -----------------------------------------------------------------------= - >=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 Oct 14 10:56:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQQzG-0005SI-Uj; Fri, 14 Oct 2005 10:56:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQQzF-0005RX-36 for megaco@megatron.ietf.org; Fri, 14 Oct 2005 10:56:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16842 for ; Fri, 14 Oct 2005 10:56:40 -0400 (EDT) Received: from zrtps0kp.nortelnetworks.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQR9w-0006Si-0d for megaco@ietf.org; Fri, 14 Oct 2005 11:07:50 -0400 Received: from zrtphxm0.corp.nortel.com (zrtphxm0.corp.nortel.com [47.140.202.49]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j9EEuT729328; Fri, 14 Oct 2005 10:56:30 -0400 (EDT) Received: from zcarhxp0.corp.nortel.com ([47.129.230.91]) by zrtphxm0.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 14 Oct 2005 10:56:27 -0400 Received: from [127.0.0.1] ([47.130.24.67] RDNS failed) by zcarhxp0.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 14 Oct 2005 10:56:26 -0400 Message-ID: <434FC715.3000604@nortel.com> Date: Fri, 14 Oct 2005 10:56:21 -0400 From: "Tom-PT Taylor" User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 Subject: Re: [Megaco] Move Command Question References: <8E4A9A66F7AED54C89F478AF4477C7D81EAAC7@enfimail1.datcon.co.uk> <434FC6A9.2040309@nortel.com> In-Reply-To: <434FC6A9.2040309@nortel.com> Content-Type: text/plain; charset=GB2312 X-OriginalArrivalTime: 14 Oct 2005 14:56:26.0372 (UTC) FILETIME=[73740C40:01C5D0CF] Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by zrtps0kp.nortelnetworks.com id j9EEuT729328 X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: quoted-printable Cc: FCG SHI Hao , megaco@ietf.org, Jon Rowland 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 Sorry, should have looked more closely. I still agree that you can MOVE to CHOOSE, but the section 6 sequence has nothing to do with it. Tom Taylor wrote: > I agree. Look at Figure 2 in section 6 of H.248.1/RFC 3015. That was > achieved using a MOVE to CHOOSE. >=20 > Jon Rowland wrote: >=20 >>Sorry, but I don't agree. Nothing about the below text specifically pro= hibits using CHOOSE (which is effectively a context ID), although I can s= ee that it could be worded more clearly. CHOOSE just asks the MG to creat= e a new context which is a perfectly valid thing to ask it to do on a MOV= E request. >>=20 >>Moving to CHOOSE is the only way to move a termination into a new conte= xt by itself in an atomic fashion. This would be a good way, for example,= to implement 'call waiting' function in telephony applications. Using SU= BTRACT/ADD doesn't really do the trick as well, because there are various= side effects of a subtract, such as resetting of signals and events desc= riptors. >>=20 >>Regards, >>Jon. >>=20 >> >> >>________________________________ >> >> From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Beha= lf Of FCG SHI Hao >> Sent: 14 October 2005 01:59 >> To: megaco@ietf.org >> Subject: re: [Megaco] Move Command Question >>=09 >>=09 >> It doesn't allow a termination to move to the CHOOSE context. "The Con= text to which the Termination is moved is >> indicated by the target ContextId in the Action." So it should be a sp= ecific context with contextID. >> =20 >> >> -----=D4=AD=CA=BC=D3=CA=BC=FE----- >> =B7=A2=BC=FE=C8=CB: megaco-bounces@ietf.org [mailto:megaco-bounces@ie= tf.org]=B4=FA=B1=ED Leonelli, Greg >> =B7=A2=CB=CD=CA=B1=BC=E4: 2005=C4=EA10=D4=C214=C8=D5 5:51 >> =CA=D5=BC=FE=C8=CB: megaco@ietf.org >> =D6=F7=CC=E2: [Megaco] Move Command Question >> =09 >> =09 >> Does the spec allow a termination to move to the CHOOSE context ? I = know the spec disallows a move to >> the NULL context. >> >> >> >> >>-----------------------------------------------------------------------= - >> >>_______________________________________________ >>Megaco mailing list >>Megaco@ietf.org >>https://www1.ietf.org/mailman/listinfo/megaco >=20 >=20 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Fri Oct 14 15:37:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQVN9-0001nU-IY; Fri, 14 Oct 2005 15:37:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQVN7-0001l7-JP for megaco@megatron.ietf.org; Fri, 14 Oct 2005 15:37:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06752 for ; Fri, 14 Oct 2005 15:37:35 -0400 (EDT) Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQVXs-0007RE-Ut for megaco@ietf.org; Fri, 14 Oct 2005 15:48:50 -0400 Received: from homail.ho.lucent.com (h135-17-192-10.lucent.com [135.17.192.10]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id j9EJbaNQ025188; Fri, 14 Oct 2005 14:37:37 -0500 (CDT) Received: from [135.112.125.111] ([135.112.125.111]) by homail.ho.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id j9EJba313016; Fri, 14 Oct 2005 15:37:36 -0400 (EDT) Message-ID: <43500BDB.7080706@lucent.com> Date: Fri, 14 Oct 2005 15:49:47 -0400 From: Richard Sun User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom-PT Taylor Subject: Re: [Megaco] ON-OFF signals in signal list References: <434BE29E.6070302@lucent.com> <434C5835.30706@nortel.com> In-Reply-To: <434C5835.30706@nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 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 Tom, Thanks for your reply. What would you suggest to accomplish the following sequential actions: 1) sig1, which is an on/off signal (e.g., xal/las) 2) within 50ms after sig1, play sig2, (e.g. altert/ri). Signal list can not be used since sig1 is on/off. Multiple signals can not be used since multiple signals shall be played simultaneously. Multiple messages can not be used since there is a 50ms timing restriction. H248.1 says: "Production of a signal on a termination is stopped by application of a new SignalsDescriptor": After Signals{xal/las}, what should MG do when it receives a new SignalDescriptor, say Signals{}, or Signals{altert/ri}? Should MG perform normal polarity? My requirement is that reverse polarity should be maintained untill MGC explicity asks MG to go back to normal polarity. So I'll use H248.34. Just need to find out the standard to perform a sequential reversePolarity,then ringing. -Richard _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Sat Oct 15 16:12:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQsOP-0007na-2K; Sat, 15 Oct 2005 16:12:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQsOM-0007nQ-PJ for megaco@megatron.ietf.org; Sat, 15 Oct 2005 16:12:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25161 for ; Sat, 15 Oct 2005 16:12:24 -0400 (EDT) Received: from zrtps0kp.nortelnetworks.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQsZL-0003lj-0n for megaco@ietf.org; Sat, 15 Oct 2005 16:23:52 -0400 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j9FKCDh22675 for ; Sat, 15 Oct 2005 16:12:13 -0400 (EDT) Received: from zcarhxp0.corp.nortel.com ([47.129.230.91]) by zcarhxm0.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 15 Oct 2005 16:12:13 -0400 Received: from [127.0.0.1] ([47.9.16.149] RDNS failed) by zcarhxp0.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 15 Oct 2005 16:12:12 -0400 Message-ID: <43516299.5010602@nortel.com> Date: Sat, 15 Oct 2005 16:12:09 -0400 From: "Tom-PT Taylor" User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Richard Sun Subject: Re: [Megaco] ON-OFF signals in signal list References: <434BE29E.6070302@lucent.com> <434C5835.30706@nortel.com> <43500BDB.7080706@lucent.com> In-Reply-To: <43500BDB.7080706@lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Oct 2005 20:12:12.0934 (UTC) FILETIME=[BAE5BA60:01C5D1C4] X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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 How about two Modify commands in the same transaction, one restoring normal polarity, the other applying the ringing? Richard Sun wrote: > Tom, Thanks for your reply. > > What would you suggest to accomplish the following > sequential actions: > 1) sig1, which is an on/off signal (e.g., xal/las) > 2) within 50ms after sig1, play sig2, (e.g. altert/ri). > > Signal list can not be used since sig1 is on/off. > > Multiple signals can not be used since multiple signals > shall be played simultaneously. > > Multiple messages can not be used since there is > a 50ms timing restriction. > H248.1 says: "Production of a signal on a termination > is stopped by application of a new SignalsDescriptor": > After Signals{xal/las}, what should MG do when > it receives a new SignalDescriptor, say Signals{}, > or Signals{altert/ri}? > Should MG perform normal polarity? > > My requirement is that reverse polarity should be > maintained untill MGC explicity asks MG to go back to > normal polarity. So I'll use H248.34. Just need to find > out the standard to perform a sequential > reversePolarity,then ringing. > > -Richard > > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Sun Oct 16 22:01:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERKJE-00031H-1q; Sun, 16 Oct 2005 22:01:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERKJC-00031C-RY for megaco@megatron.ietf.org; Sun, 16 Oct 2005 22:01:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07820 for ; Sun, 16 Oct 2005 22:00:56 -0400 (EDT) Received: from nat1.alcatel-sbell.com.cn ([202.96.203.177] helo=mail.alcatel-sbell.com.cn) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERKUQ-0004Jg-Bc for megaco@ietf.org; Sun, 16 Oct 2005 22:12:40 -0400 Received: from asbmail4.sbell.com.cn (localhost [127.0.0.1]) by mail.alcatel-sbell.com.cn (8.12.11/8.12.11/Alcanet1.0) with ESMTP id j9H1vrhI025624 for ; Mon, 17 Oct 2005 09:57:54 +0800 Received: from asbmail1.sbell.com.cn ([172.24.208.61]) by asbmail4.sbell.com.cn with Microsoft SMTPSVC(5.0.2195.6713); Mon, 17 Oct 2005 10:00:38 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: quoted-printable Subject: RE: [Megaco] Move Command Question Date: Mon, 17 Oct 2005 10:00:38 +0800 Message-ID: Thread-Topic: [Megaco] Move Command Question Thread-Index: AcXQ0jZ6CIx2ofs7Q4ecfHKWi4jungB6jAiQ From: "FCG SHI Hao" To: X-OriginalArrivalTime: 17 Oct 2005 02:00:38.0582 (UTC) FILETIME=[920C3560:01C5D2BE] X-imss-version: 2.032 X-imss-result: Passed X-imss-approveListMatch: *@alcatel-sbell.com.cn X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 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 I don't know the application case which needs to move the termination to = a CHOOSE context. As I know, the "call waiting" service doesn't need the = MOVE command, it only uses the "Modify" command to modify the waiting = user's SDP to point to the Media Server's music resource, let it listen = to the music. But I believe it should be my misunderstanding on the protocol text. I = agree the "Move" and "Subtract" have different effects on the = terminations. Sorry for my previous answer. I suggest to add the CHOOSE allowance of Move command in the protocol = directly for the possible application cases. -----=D4=AD=CA=BC=D3=CA=BC=FE----- =B7=A2=BC=FE=C8=CB: Tom-PT Taylor [mailto:taylor@nortel.com] =B7=A2=CB=CD=CA=B1=BC=E4: 2005=C4=EA10=D4=C214=C8=D5 22:56 =B3=AD=CB=CD: Jon Rowland; FCG SHI Hao; megaco@ietf.org =D6=F7=CC=E2: Re: [Megaco] Move Command Question Sorry, should have looked more closely. I still agree that you can MOVE to CHOOSE, but the section 6 sequence has nothing to do with it. Tom Taylor wrote: > I agree. Look at Figure 2 in section 6 of H.248.1/RFC 3015. That was > achieved using a MOVE to CHOOSE. >=20 > Jon Rowland wrote: >=20 >>Sorry, but I don't agree. Nothing about the below text specifically = prohibits using CHOOSE (which is effectively a context ID), although I = can see that it could be worded more clearly. CHOOSE just asks the MG to = create a new context which is a perfectly valid thing to ask it to do on = a MOVE request. >>=20 >>Moving to CHOOSE is the only way to move a termination into a new = context by itself in an atomic fashion. This would be a good way, for = example, to implement 'call waiting' function in telephony applications. = Using SUBTRACT/ADD doesn't really do the trick as well, because there = are various side effects of a subtract, such as resetting of signals and = events descriptors. >>=20 >>Regards, >>Jon. >>=20 >> >> >>________________________________ >> >> From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On = Behalf Of FCG SHI Hao >> Sent: 14 October 2005 01:59 >> To: megaco@ietf.org >> Subject: re: [Megaco] Move Command Question >>=09 >>=09 >> It doesn't allow a termination to move to the CHOOSE context. "The = Context to which the Termination is moved is >> indicated by the target ContextId in the Action." So it should be a = specific context with contextID. >> =20 >> >> -----=D4=AD=CA=BC=D3=CA=BC=FE----- >> =B7=A2=BC=FE=C8=CB: megaco-bounces@ietf.org = [mailto:megaco-bounces@ietf.org]=B4=FA=B1=ED Leonelli, Greg >> =B7=A2=CB=CD=CA=B1=BC=E4: 2005=C4=EA10=D4=C214=C8=D5 5:51 >> =CA=D5=BC=FE=C8=CB: megaco@ietf.org >> =D6=F7=CC=E2: [Megaco] Move Command Question >> =09 >> =09 >> Does the spec allow a termination to move to the CHOOSE context ? I = know the spec disallows a move to >> the NULL context. >> >> >> >> >>-----------------------------------------------------------------------= - >> >>_______________________________________________ >>Megaco mailing list >>Megaco@ietf.org >>https://www1.ietf.org/mailman/listinfo/megaco >=20 >=20 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Mon Oct 17 00:01:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERMBi-00005y-T5; Mon, 17 Oct 2005 00:01:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERMBg-00005p-4X for megaco@megatron.ietf.org; Mon, 17 Oct 2005 00:01:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12951 for ; Mon, 17 Oct 2005 00:01:16 -0400 (EDT) Received: from omta03ps.mx.bigpond.com ([144.140.82.155]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERMMt-00074Z-9L for megaco@ietf.org; Mon, 17 Oct 2005 00:13:02 -0400 Received: from [127.0.0.1] (really [203.51.150.12]) by omta03ps.mx.bigpond.com with ESMTP id <20051017040013.WWVS12238.omta03ps.mx.bigpond.com@[127.0.0.1]> for ; Mon, 17 Oct 2005 04:00:13 +0000 Message-ID: <435321CC.6080603@bigpond.net.au> Date: Mon, 17 Oct 2005 14:00:12 +1000 From: Christian Groves User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'megaco@ietf.org'" Subject: Re: [Megaco] Move Command Question References: In-Reply-To: Content-Type: text/plain; charset=GB2312 X-Authentication-Info: Submitted using SMTP AUTH PLAIN at omta03ps.mx.bigpond.com from [203.51.150.12] using ID cngroves@bigpond.net.au at Mon, 17 Oct 2005 04:00:11 +0000 X-Spam-Score: 0.1 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id AAA12951 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, We don't have to add anything to the protocol. From day 1, H.248.1 already allowed ContextID=3DCHOOSE in a Move command. Actually if Move didn't support ContextID=3Dchoose it would be a big limitation as you would always have to have another termination in the target context before you could move the required termination to that context. Regards, Christian FCG SHI Hao wrote: >I don't know the application case which needs to move the termination to= a CHOOSE context. As I know, the "call waiting" service doesn't need the= MOVE command, it only uses the "Modify" command to modify the waiting us= er's SDP to point to the Media Server's music resource, let it listen to = the music. > >But I believe it should be my misunderstanding on the protocol text. I a= gree the "Move" and "Subtract" have different effects on the terminations= . Sorry for my previous answer. > > I suggest to add the CHOOSE allowance of Move command in the protocol d= irectly for the possible application cases. > >-----=D4=AD=CA=BC=D3=CA=BC=FE----- >=B7=A2=BC=FE=C8=CB: Tom-PT Taylor [mailto:taylor@nortel.com] >=B7=A2=CB=CD=CA=B1=BC=E4: 2005=C4=EA10=D4=C214=C8=D5 22:56 >=B3=AD=CB=CD: Jon Rowland; FCG SHI Hao; megaco@ietf.org >=D6=F7=CC=E2: Re: [Megaco] Move Command Question > > >Sorry, should have looked more closely. I still agree that you can MOVE >to CHOOSE, but the section 6 sequence has nothing to do with it. > >Tom Taylor wrote: > =20 > >>I agree. Look at Figure 2 in section 6 of H.248.1/RFC 3015. That was >>achieved using a MOVE to CHOOSE. >> >>Jon Rowland wrote: >> >> =20 >> >>>Sorry, but I don't agree. Nothing about the below text specifically pr= ohibits using CHOOSE (which is effectively a context ID), although I can = see that it could be worded more clearly. CHOOSE just asks the MG to crea= te a new context which is a perfectly valid thing to ask it to do on a MO= VE request. >>> >>>Moving to CHOOSE is the only way to move a termination into a new cont= ext by itself in an atomic fashion. This would be a good way, for example= , to implement 'call waiting' function in telephony applications. Using S= UBTRACT/ADD doesn't really do the trick as well, because there are variou= s side effects of a subtract, such as resetting of signals and events des= criptors. >>> >>>Regards, >>>Jon. >>> >>> >>> >>>________________________________ >>> >>> From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Beh= alf Of FCG SHI Hao >>> Sent: 14 October 2005 01:59 >>> To: megaco@ietf.org >>> Subject: re: [Megaco] Move Command Question >>>=09 >>>=09 >>> It doesn't allow a termination to move to the CHOOSE context. "The Co= ntext to which the Termination is moved is >>> indicated by the target ContextId in the Action." So it should be a s= pecific context with contextID. >>> =20 >>> >>> -----=D4=AD=CA=BC=D3=CA=BC=FE----- >>> =B7=A2=BC=FE=C8=CB: megaco-bounces@ietf.org [mailto:megaco-bounces@i= etf.org]=B4=FA=B1=ED Leonelli, Greg >>> =B7=A2=CB=CD=CA=B1=BC=E4: 2005=C4=EA10=D4=C214=C8=D5 5:51 >>> =CA=D5=BC=FE=C8=CB: megaco@ietf.org >>> =D6=F7=CC=E2: [Megaco] Move Command Question >>> =09 >>> =09 >>> Does the spec allow a termination to move to the CHOOSE context ? I= know the spec disallows a move to >>> the NULL context. >>> >>> >>> >>> >>>----------------------------------------------------------------------= -- >>> >>>_______________________________________________ >>>Megaco mailing list >>>Megaco@ietf.org >>>https://www1.ietf.org/mailman/listinfo/megaco >>> =20 >>> >> =20 >> > > >_______________________________________________ >Megaco mailing list >Megaco@ietf.org >https://www1.ietf.org/mailman/listinfo/megaco > > > =20 > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Mon Oct 17 06:11:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERRy7-0007mN-Hy; Mon, 17 Oct 2005 06:11:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERRy5-0007mD-RP for megaco@megatron.ietf.org; Mon, 17 Oct 2005 06:11:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01357 for ; Mon, 17 Oct 2005 06:11:38 -0400 (EDT) Received: from smtp.dataconnection.com ([192.91.191.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERS9L-0000DI-Tx for megaco@ietf.org; Mon, 17 Oct 2005 06:23:27 -0400 Received: from enfimail1.datcon.co.uk ([172.19.14.253]) by smtp.dataconnection.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Oct 2005 11:11:25 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: quoted-printable Subject: RE: [Megaco] Move Command Question Date: Mon, 17 Oct 2005 11:11:22 +0100 Message-ID: <8E4A9A66F7AED54C89F478AF4477C7D81EAC83@enfimail1.datcon.co.uk> Thread-Topic: [Megaco] Move Command Question Thread-Index: AcXQ0jZ6CIx2ofs7Q4ecfHKWi4jungB6jAiQABGQ8wA= From: "Jon Rowland" To: "FCG SHI Hao" , X-OriginalArrivalTime: 17 Oct 2005 10:11:25.0470 (UTC) FILETIME=[21C2BBE0:01C5D303] X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Content-Transfer-Encoding: quoted-printable Cc: 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 You're making a lot of assumptions about the call waiting scenario = there. - What if the call doesn't involve any RTP stream - there'd be no SDP to = change - could just be three physical terminations on the same MG. - What if you aren't using a media server to play music, or indeed, = aren't playing music at all, but silence, or an announcement, and the MG = has the capabilities to play it directly on the endpoint. Remember that just because you can see one way to implement some = function doesn't mean the protocol doesn=A1=AFt need to more flexible - = it's trying to cover all eventualities. Glad we've resolved the confusion over the support for MOVE-CHOOSE = anyway! Cheers, Jon. -----Original Message----- From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf = Of FCG SHI Hao Sent: 17 October 2005 03:01 To: megaco@ietf.org Subject: RE: [Megaco] Move Command Question I don't know the application case which needs to move the termination to = a CHOOSE context. As I know, the "call waiting" service doesn't need the = MOVE command, it only uses the "Modify" command to modify the waiting = user's SDP to point to the Media Server's music resource, let it listen = to the music. But I believe it should be my misunderstanding on the protocol text. I = agree the "Move" and "Subtract" have different effects on the = terminations. Sorry for my previous answer. I suggest to add the CHOOSE allowance of Move command in the protocol = directly for the possible application cases. -----=D4=AD=CA=BC=D3=CA=BC=FE----- =B7=A2=BC=FE=C8=CB: Tom-PT Taylor [mailto:taylor@nortel.com] =B7=A2=CB=CD=CA=B1=BC=E4: 2005=C4=EA10=D4=C214=C8=D5 22:56 =B3=AD=CB=CD: Jon Rowland; FCG SHI Hao; megaco@ietf.org =D6=F7=CC=E2: Re: [Megaco] Move Command Question Sorry, should have looked more closely. I still agree that you can MOVE to CHOOSE, but the section 6 sequence has nothing to do with it. Tom Taylor wrote: > I agree. Look at Figure 2 in section 6 of H.248.1/RFC 3015. That was > achieved using a MOVE to CHOOSE. >=20 > Jon Rowland wrote: >=20 >>Sorry, but I don't agree. Nothing about the below text specifically = prohibits using CHOOSE (which is effectively a context ID), although I = can see that it could be worded more clearly. CHOOSE just asks the MG to = create a new context which is a perfectly valid thing to ask it to do on = a MOVE request. >>=20 >>Moving to CHOOSE is the only way to move a termination into a new = context by itself in an atomic fashion. This would be a good way, for = example, to implement 'call waiting' function in telephony applications. = Using SUBTRACT/ADD doesn't really do the trick as well, because there = are various side effects of a subtract, such as resetting of signals and = events descriptors. >>=20 >>Regards, >>Jon. >>=20 >> >> >>________________________________ >> >> From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On = Behalf Of FCG SHI Hao >> Sent: 14 October 2005 01:59 >> To: megaco@ietf.org >> Subject: re: [Megaco] Move Command Question >>=09 >>=09 >> It doesn't allow a termination to move to the CHOOSE context. "The = Context to which the Termination is moved is >> indicated by the target ContextId in the Action." So it should be a = specific context with contextID. >> =20 >> >> -----=D4=AD=CA=BC=D3=CA=BC=FE----- >> =B7=A2=BC=FE=C8=CB: megaco-bounces@ietf.org = [mailto:megaco-bounces@ietf.org]=B4=FA=B1=ED Leonelli, Greg >> =B7=A2=CB=CD=CA=B1=BC=E4: 2005=C4=EA10=D4=C214=C8=D5 5:51 >> =CA=D5=BC=FE=C8=CB: megaco@ietf.org >> =D6=F7=CC=E2: [Megaco] Move Command Question >> =09 >> =09 >> Does the spec allow a termination to move to the CHOOSE context ? I = know the spec disallows a move to >> the NULL context. >> >> >> >> >>-----------------------------------------------------------------------= - >> >>_______________________________________________ >>Megaco mailing list >>Megaco@ietf.org >>https://www1.ietf.org/mailman/listinfo/megaco >=20 >=20 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Mon Oct 17 11:37:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERX3E-0005bw-EL; Mon, 17 Oct 2005 11:37:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERX3D-0005bX-69 for megaco@megatron.ietf.org; Mon, 17 Oct 2005 11:37:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19730 for ; Mon, 17 Oct 2005 11:37:15 -0400 (EDT) Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERXEX-0001Xt-8g for megaco@ietf.org; Mon, 17 Oct 2005 11:49:07 -0400 Received: from homail.ho.lucent.com (h135-17-192-10.lucent.com [135.17.192.10]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id j9HFbH4T025878; Mon, 17 Oct 2005 10:37:17 -0500 (CDT) Received: from [135.112.125.111] ([135.112.125.111]) by homail.ho.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id j9HFbGC25104; Mon, 17 Oct 2005 11:37:16 -0400 (EDT) Message-ID: <4353C80B.6030905@lucent.com> Date: Mon, 17 Oct 2005 11:49:31 -0400 From: Richard Sun User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom-PT Taylor Subject: Re: [Megaco] ON-OFF signals in signal list References: <434BE29E.6070302@lucent.com> <434C5835.30706@nortel.com> <43500BDB.7080706@lucent.com> <43516299.5010602@nortel.com> In-Reply-To: <43516299.5010602@nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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 > How about two Modify commands in the same transaction, one restoring > normal polarity, the other applying the ringing? Tom, There are two issues here: 1. My polarity must be kept reversed while ringing. With two Modify commands, the 1st one contains Signals{xal/las}, the 2nd one contains Signals{altert/ri}, how to interpret this requirement from H248.1: "Production of a signal on a termination is stopped by application of a new SignalsDescriptor". What does "is stopped" mean here for on-off signals such as xal/las? 2. A general need is a standard to accomplish the following two actions sequentially: 1) apply an on/off signal sig1 (e.g., xal/las) 2) delay X millisec 3) apply sig2, (e.g. ringing) H248v3 defines an inter signal delay, which is great. So if SignalList{sig1,sig2} had been allowed for on-off sig1, then it would have been perfect. But H248v3 still restrict "Only the trailing element of the sequence of signals in a sequential signal list may be an on/off signal." It would be great to hear any comments of the standard for above two issues. Thanks a lot for your helpfull discussions. -Richard _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Mon Oct 17 12:01:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERXQS-0001vg-1v; Mon, 17 Oct 2005 12:01:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERXQP-0001vV-Rx for megaco@megatron.ietf.org; Mon, 17 Oct 2005 12:01:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20846 for ; Mon, 17 Oct 2005 12:01:11 -0400 (EDT) Received: from smtp.dataconnection.com ([192.91.191.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERXbh-0002BP-2z for megaco@ietf.org; Mon, 17 Oct 2005 12:13:04 -0400 Received: from enfimail1.datcon.co.uk ([172.19.14.253]) by smtp.dataconnection.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Oct 2005 17:01:01 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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] ON-OFF signals in signal list Date: Mon, 17 Oct 2005 17:01:00 +0100 Message-ID: <8E4A9A66F7AED54C89F478AF4477C7D82C214C@enfimail1.datcon.co.uk> Thread-Topic: [Megaco] ON-OFF signals in signal list Thread-Index: AcXTMTX/yEivnLaiRMOBHOQ3O7nkQgAAk8wA From: "Jon Rowland" To: "Richard Sun" , "Tom-PT Taylor" X-OriginalArrivalTime: 17 Oct 2005 16:01:01.0304 (UTC) FILETIME=[F854FF80:01C5D333] X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: quoted-printable 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 How sensitive is the value of X in your delay between the signals? Could the MGC run the timer and specify two subsequent Modifies in two Transactions: First transaction: Modify: Signals {xal/las} Second transaction: Modify: Signals {xal/las{KA}, alert/ri} (using the keep-active flag so you don't restart the las signal). Then later when you want to turn off ringing and/or switch polarity, you can do something similar. Slightly hokey, and depends on the intersignal delay not being a very sensitive value, but could do the trick. Regards, Jon. =20 -----Original Message----- From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf Of Richard Sun Sent: 17 October 2005 16:50 To: Tom-PT Taylor Cc: megaco@ietf.org Subject: Re: [Megaco] ON-OFF signals in signal list > How about two Modify commands in the same transaction, one restoring=20 > normal polarity, the other applying the ringing? Tom, There are two issues here: 1. My polarity must be kept reversed while ringing. With two Modify commands, the 1st one contains Signals{xal/las}, the 2nd one contains Signals{altert/ri}, how to interpret this requirement from H248.1: "Production of a signal on a termination is stopped by application of a new SignalsDescriptor". What does "is stopped" mean here for on-off signals such as xal/las? 2. A general need is a standard to accomplish the following two actions sequentially: 1) apply an on/off signal sig1 (e.g., xal/las) 2) delay X millisec 3) apply sig2, (e.g. ringing) H248v3 defines an inter signal delay, which is great. So if SignalList{sig1,sig2} had been allowed for on-off sig1, then it would have been perfect. But H248v3 still restrict "Only the trailing element of the sequence of signals in a sequential signal list may be an on/off signal." It would be great to hear any comments of the standard for above two issues. Thanks a lot for your helpfull discussions. -Richard _______________________________________________ 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 Oct 17 12:20:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERXgg-0007Xm-11; Mon, 17 Oct 2005 12:18:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERXgc-0007XN-FV for megaco@megatron.ietf.org; Mon, 17 Oct 2005 12:18:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22247 for ; Mon, 17 Oct 2005 12:17:58 -0400 (EDT) Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERXrw-0002pa-PN for megaco@ietf.org; Mon, 17 Oct 2005 12:29:51 -0400 Received: from homail.ho.lucent.com (h135-17-192-10.lucent.com [135.17.192.10]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id j9HGHwEL017530; Mon, 17 Oct 2005 11:17:59 -0500 (CDT) Received: from [135.112.125.111] ([135.112.125.111]) by homail.ho.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id j9HGHvC11966; Mon, 17 Oct 2005 12:17:57 -0400 (EDT) Message-ID: <4353D194.9000902@lucent.com> Date: Mon, 17 Oct 2005 12:30:12 -0400 From: Richard Sun User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jon Rowland Subject: Re: [Megaco] ON-OFF signals in signal list References: <8E4A9A66F7AED54C89F478AF4477C7D82C214C@enfimail1.datcon.co.uk> In-Reply-To: <8E4A9A66F7AED54C89F478AF4477C7D82C214C@enfimail1.datcon.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 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 Jon, Thanks for the trick. Signals {xal/las{KA}, alert/ri} is good enough for my case without CallerID. About the sensitivity of X, short answer is very sensitive: it is really about caller ID application. I've read the andisp/dwa thread, and agree that andisp/dwa is a good signal to leave many details to implementor. But now I need to combine {xal/las{KA}, andisp/dwa} with a very sensitive inter signal delay. I'd like to avoid to implement andisp/dwa in such way that reverse polarity is implicit (because in most regions reverse polarity is not needed). Any more suggestions? Thanks, -Richard Jon Rowland wrote: > How sensitive is the value of X in your delay between the signals? Could > the MGC run the timer and specify two subsequent Modifies in two > Transactions: > > First transaction: > Modify: Signals {xal/las} > > Second transaction: > Modify: Signals {xal/las{KA}, alert/ri} (using the keep-active flag > so you don't restart the las signal). > > Then later when you want to turn off ringing and/or switch polarity, you > can do something similar. > > Slightly hokey, and depends on the intersignal delay not being a very > sensitive value, but could do the trick. > > Regards, > Jon. > > > -----Original Message----- > From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf > Of Richard Sun > Sent: 17 October 2005 16:50 > To: Tom-PT Taylor > Cc: megaco@ietf.org > Subject: Re: [Megaco] ON-OFF signals in signal list > > >>How about two Modify commands in the same transaction, one restoring >>normal polarity, the other applying the ringing? > > > Tom, > There are two issues here: > > 1. My polarity must be kept reversed while ringing. > With two Modify commands, the 1st one contains > Signals{xal/las}, the 2nd one contains Signals{altert/ri}, > how to interpret this requirement from H248.1: > "Production of a signal on a termination > is stopped by application of a new SignalsDescriptor". > What does "is stopped" mean here for on-off signals > such as xal/las? > > 2. A general need is a standard to > accomplish the following two actions sequentially: > 1) apply an on/off signal sig1 (e.g., xal/las) > 2) delay X millisec > 3) apply sig2, (e.g. ringing) > > H248v3 defines an inter signal delay, which is great. > So if SignalList{sig1,sig2} had been allowed for on-off sig1, > then it would have been perfect. But H248v3 still restrict > "Only the trailing element of the sequence of signals in a > sequential signal list may be an on/off signal." > > It would be great to hear any comments of the standard > for above two issues. > Thanks a lot for your helpfull discussions. > > -Richard > > _______________________________________________ > 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 Oct 17 13:03:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERYOh-0001kA-48; Mon, 17 Oct 2005 13:03:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERYOg-0001jf-03 for megaco@megatron.ietf.org; Mon, 17 Oct 2005 13:03:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24521 for ; Mon, 17 Oct 2005 13:03:29 -0400 (EDT) Received: from smtp.dataconnection.com ([192.91.191.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERYa2-00046p-M1 for megaco@ietf.org; Mon, 17 Oct 2005 13:15:23 -0400 Received: from enfimail1.datcon.co.uk ([172.19.14.253]) by smtp.dataconnection.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Oct 2005 18:03:27 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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] ON-OFF signals in signal list Date: Mon, 17 Oct 2005 18:03:26 +0100 Message-ID: <8E4A9A66F7AED54C89F478AF4477C7D82C21A2@enfimail1.datcon.co.uk> Thread-Topic: [Megaco] ON-OFF signals in signal list Thread-Index: AcXTNlj9uJb/HADqSz68XhdzcncnsAAA3yYQ From: "Jon Rowland" To: "Richard Sun" X-OriginalArrivalTime: 17 Oct 2005 17:03:27.0115 (UTC) FILETIME=[B10265B0:01C5D33C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Content-Transfer-Encoding: quoted-printable 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 Richard, If this is a regional requirement whereby ringing and callerID require the line to be set to reverse polarity, then I'd say the best solution is for the MG to be aware of its local requirements and implement alert/ri and andisp/dwa in such a way that it reverses the polarity with the right timings as part of playing the base signal. You could even get rid of specifying xal/las entirely (as it's intended for Line-side Answer Supervision, as the name suggests). MGs already need to know how to implement andisp/dwa differently as the caller ID format, and timings are different in different regions, this just feels like another variant, if I'm understanding it correctly. That said, as a pure thought exercise, how about the following nasty solution? :-) You need to be able to play a 'do nothing' signal on the termination. Something like qtlt/quietterm would be the right sort of idea, although it's obviously a nasty hack. Then override the signal type to timeout and give it the duration of your intersignal delay (X), and use an embedded signals descriptor to play the caller ID at the right point based on the completion of the QT signal. You get something like this: Modify: Signals{xal/las, qtlt/quietterm{NC=3D{TO}, DR=3DX}} Events=3D1{g/sc, EM{Signals{xal/las{KA}, andisp/dwa{ddb=3Detc...}}} I think this does the trick logically, although MGs may not support it, and I certainly don't recommend it as a real-world solution - just something to entertain me on a Monday afternoon! :-). Cheers, Jon. -----Original Message----- From: Richard Sun [mailto:xsun@lucent.com]=20 Sent: 17 October 2005 17:30 To: Jon Rowland Cc: Tom-PT Taylor; megaco@ietf.org Subject: Re: [Megaco] ON-OFF signals in signal list Jon, Thanks for the trick. Signals {xal/las{KA}, alert/ri} is good enough for my case without CallerID. About the sensitivity of X, short answer is very sensitive: it is really about caller ID application. I've read the andisp/dwa thread, and agree that andisp/dwa is a good signal to leave many details to implementor. But now I need to combine {xal/las{KA}, andisp/dwa} with a very sensitive inter signal delay. I'd like to avoid to implement andisp/dwa in such way that reverse polarity is implicit (because in most regions reverse polarity is not needed). Any more suggestions? Thanks, -Richard Jon Rowland wrote: > How sensitive is the value of X in your delay between the signals? Could > the MGC run the timer and specify two subsequent Modifies in two > Transactions: >=20 > First transaction: > Modify: Signals {xal/las} >=20 > Second transaction: > Modify: Signals {xal/las{KA}, alert/ri} (using the keep-active flag > so you don't restart the las signal). >=20 > Then later when you want to turn off ringing and/or switch polarity, you > can do something similar. >=20 > Slightly hokey, and depends on the intersignal delay not being a very > sensitive value, but could do the trick. >=20 > Regards, > Jon. > =20 >=20 > -----Original Message----- > From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf > Of Richard Sun > Sent: 17 October 2005 16:50 > To: Tom-PT Taylor > Cc: megaco@ietf.org > Subject: Re: [Megaco] ON-OFF signals in signal list >=20 >=20 >>How about two Modify commands in the same transaction, one restoring=20 >>normal polarity, the other applying the ringing? >=20 >=20 > Tom, > There are two issues here: >=20 > 1. My polarity must be kept reversed while ringing. > With two Modify commands, the 1st one contains > Signals{xal/las}, the 2nd one contains Signals{altert/ri}, > how to interpret this requirement from H248.1: > "Production of a signal on a termination > is stopped by application of a new SignalsDescriptor". > What does "is stopped" mean here for on-off signals > such as xal/las? >=20 > 2. A general need is a standard to > accomplish the following two actions sequentially: > 1) apply an on/off signal sig1 (e.g., xal/las) > 2) delay X millisec > 3) apply sig2, (e.g. ringing) >=20 > H248v3 defines an inter signal delay, which is great. > So if SignalList{sig1,sig2} had been allowed for on-off sig1, > then it would have been perfect. But H248v3 still restrict > "Only the trailing element of the sequence of signals in a > sequential signal list may be an on/off signal." >=20 > It would be great to hear any comments of the standard > for above two issues. > Thanks a lot for your helpfull discussions. >=20 > -Richard >=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 Mon Oct 17 14:11:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERZSJ-0002U3-7y; Mon, 17 Oct 2005 14:11:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERZSH-0002Ty-CZ for megaco@megatron.ietf.org; Mon, 17 Oct 2005 14:11:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28629 for ; Mon, 17 Oct 2005 14:11:18 -0400 (EDT) Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERZdc-00067N-S2 for megaco@ietf.org; Mon, 17 Oct 2005 14:23:11 -0400 Received: from homail.ho.lucent.com (h135-17-192-10.lucent.com [135.17.192.10]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id j9HIBJM6022102; Mon, 17 Oct 2005 13:11:19 -0500 (CDT) Received: from [135.112.125.111] ([135.112.125.111]) by homail.ho.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id j9HIBJC27939; Mon, 17 Oct 2005 14:11:19 -0400 (EDT) Message-ID: <4353EC26.9060407@lucent.com> Date: Mon, 17 Oct 2005 14:23:34 -0400 From: Richard Sun User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jon Rowland Subject: Re: [Megaco] ON-OFF signals in signal list References: <8E4A9A66F7AED54C89F478AF4477C7D82C21A2@enfimail1.datcon.co.uk> In-Reply-To: <8E4A9A66F7AED54C89F478AF4477C7D82C21A2@enfimail1.datcon.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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 Jon, Your example is great to understand how the protocol works. Thanks a lot. -Richard Jon Rowland wrote: > Richard, > > If this is a regional requirement whereby ringing and callerID require > the line to be set to reverse polarity, then I'd say the best solution > is for the MG to be aware of its local requirements and implement > alert/ri and andisp/dwa in such a way that it reverses the polarity with > the right timings as part of playing the base signal. You could even get > rid of specifying xal/las entirely (as it's intended for Line-side > Answer Supervision, as the name suggests). MGs already need to know how > to implement andisp/dwa differently as the caller ID format, and timings > are different in different regions, this just feels like another > variant, if I'm understanding it correctly. > > That said, as a pure thought exercise, how about the following nasty > solution? :-) > > You need to be able to play a 'do nothing' signal on the termination. > Something like qtlt/quietterm would be the right sort of idea, although > it's obviously a nasty hack. Then override the signal type to timeout > and give it the duration of your intersignal delay (X), and use an > embedded signals descriptor to play the caller ID at the right point > based on the completion of the QT signal. You get something like this: > > Modify: > Signals{xal/las, qtlt/quietterm{NC={TO}, DR=X}} > Events=1{g/sc, EM{Signals{xal/las{KA}, andisp/dwa{ddb=etc...}}} > > I think this does the trick logically, although MGs may not support it, > and I certainly don't recommend it as a real-world solution - just > something to entertain me on a Monday afternoon! :-). > > Cheers, > Jon. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Tue Oct 18 01:44:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERkHQ-0000MB-Fq; Tue, 18 Oct 2005 01:44:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERkHN-0000M5-OG for megaco@megatron.ietf.org; Tue, 18 Oct 2005 01:44:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05202 for ; Tue, 18 Oct 2005 01:44:45 -0400 (EDT) Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERkSr-0001Cr-Ah for megaco@ietf.org; Tue, 18 Oct 2005 01:56:45 -0400 Received: from horh1.emsr.lucent.com (h135-112-138-211.lucent.com [135.112.138.211]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id j9I5io48016777 for ; Tue, 18 Oct 2005 00:44:51 -0500 (CDT) Received: from new-wopr.eng.ascend.com (new-wopr.eng.ascend.com [135.140.53.19]) by horh1.emsr.lucent.com (8.12.11/8.12.11) with ESMTP id j9I5imvZ021391; Tue, 18 Oct 2005 00:44:48 -0500 (CDT) Received: from india.ascend.com (indiamail.india.ascend.com [135.254.196.198]) by new-wopr.eng.ascend.com (8.11.6+Sun/8.10.2) with ESMTP id j9I5ik806462; Mon, 17 Oct 2005 22:44:46 -0700 (PDT) Received: from lucent.com (spokane.india.ascend.com [135.254.196.68]) by india.ascend.com (8.8.8+Sun/8.8.8) with ESMTP id LAA15126; Tue, 18 Oct 2005 11:14:45 +0530 (IST) Message-ID: <43548BCD.1B765765@lucent.com> Date: Tue, 18 Oct 2005 11:14:45 +0530 From: Naveen Sujit Kumar X-Mailer: Mozilla 4.79 [en] (X11; U; SunOS 5.6 i86pc) X-Accept-Language: en MIME-Version: 1.0 To: "megaco@ietf.org" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit Cc: Subject: [Megaco] Query on H.248 ReserveValue Implementation 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, I had few queries regarding MG's behaviour when ReserveValue was 'On'. 1. The Add message contains both local and remote descriptors with a list of codecs. There might be common codecs between the two descriptors. The message might be like this: Add = R$ {Media { LocalControl {Mode = ReceiveOnly,ReservedValue=ON}, Local { v=0 c=IN IP4 7.7.7.160 m=audio 20000 RTP/AVP 0 18 4 <<<<< a=ptime:20 }, Remote { v=0 c=IN IP4 7.7.7.123 m=audio 20000 RTP/AVP 0 18 <<<<< a=ptime:20 } } } } } What exactly should we do when we have both local and remote descriptors..?? * Should only one descriptor be considered..?? Or * Should MG go thro' both the lists and take only the common codecs ( 0 18 ) for consideration..?? Or * Should both the lists be treated seperately and resources reserved for the same..?? * Also, what should be the behaviour if there are no common codecs between local and remote descriptors..?? Is there any such real world application for any of the above conditions..?? 2. How does Ignore go with ReserveValue..?? The message might be like this: Add = R$ {Media { LocalControl {Mode = ReceiveOnly,ReservedValue=ON}, Local { v=0 c=IN IP4 7.7.7.160 m=audio 20000 RTP/AVP - <<<<< a=ptime:20 } } } } } What needs to be done here..?? Should we return an empty descriptor as RFC says, since we cannot reserve any resources..?? Or should we return an error and what needs to be the error value..?? TIA for any suggestions, -Naveen _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Tue Oct 18 03:05:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERlWy-0000VJ-D5; Tue, 18 Oct 2005 03:05:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERlWw-0000SF-9r for megaco@megatron.ietf.org; Tue, 18 Oct 2005 03:05:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08806 for ; Tue, 18 Oct 2005 03:04:54 -0400 (EDT) From: Albrecht.Schwarz@alcatel.de Received: from mailrelay2.alcatel.de ([194.113.59.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERliO-00033b-M2 for Megaco@ietf.org; Tue, 18 Oct 2005 03:16:54 -0400 Received: from demail05.netfr.alcatel.fr (demail05.netfr.alcatel.fr [155.132.182.205]) by mailrelay2.alcatel.de (8.12.10/8.12.10/ICT TSC MAIL 2005) with ESMTP id j9I74jDO016694; Tue, 18 Oct 2005 09:04:45 +0200 In-Reply-To: <434F290C.20607@bigpond.net.au> Subject: Re: [Megaco] Silence Suppression To: Christian Groves X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: Date: Tue, 18 Oct 2005 09:04:44 +0200 X-MIMETrack: Serialize by Router on DEMAIL05/DE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 10/18/2005 09:04:44 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable X-Scanned-By: MIMEDefang 2.49 on 149.204.45.73 X-Spam-Score: 0.3 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Content-Transfer-Encoding: quoted-printable 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 Hi Christian, "Q.765.5, =A7 11.1.7.2.1.1 Codec Type subfield" provides codepoints for silence suppression modes of G.723.1 and G.729 codecs. How would you enable/disable silence suppression mode for G.711 in case= of H.248 binary encoding mode? Couldn't find any code in Q.765.5. Thanks, Albrecht = =20 Christian Groves = =20 =20 d.net.au> cc: Michal Yachimov= itz , Victoria Mendelevich =20 Sent by: , Megaco@ietf.org, Rima Mazorov =20 megaco-bounces@i =20 etf.org Subject: Re: [Megaco] Si= lence Suppression =20 = =20 = =20 14.10.2005 05:42 = =20 = =20 Hello all, The value of Acodec (Annex C and used by Q.1950/3GPP Ts29.232) may also= specify silence suppression for a given codec type. See the codec type subfield in Q.765.5 Christian Maridi R. Makaraju (Raju) wrote: > Tamar, > > RFC 3108 defines 'silenceSupp' > SDP parameter. You can take a look at it. > (The RFC is meant for ATM bearers but the silenceSupp can be used for= > all bearer types). > For binary encoding you can use Annex C. > > I don't think there is any package which attempts to defined them as = they > are available in AnnexC(for binary) and in RFC 3108 for text. > > -Raju > > -----Original Message----- > *From:* megaco-bounces@ietf.org > [mailto:megaco-bounces@ietf.org]*On Behalf Of *Tamar Nemet > *Sent:* Monday, October 10, 2005 4:07 AM > *To:* Megaco@ietf.org > *Cc:* Victoria Mendelevich; Michal Yachimovitz; Rima Mazorov > *Subject:* [Megaco] Silence Suppression > > Hello, > > I am looking for the package which include silence suppression > (ON/OFF ?). > > I looked at the tdmc package and I found there echo cancellation > and gain control, but no silence suppression. > > Does anybody know where is it ? > > Thanks, > Tamar > >----------------------------------------------------------------------= -- > >_______________________________________________ >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 Tue Oct 18 03:50:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERmEl-0004lM-AQ; Tue, 18 Oct 2005 03:50:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERmEi-0004lD-Pq for megaco@megatron.ietf.org; Tue, 18 Oct 2005 03:50:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10874 for ; Tue, 18 Oct 2005 03:50:08 -0400 (EDT) Received: from omta05ps.mx.bigpond.com ([144.140.83.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERmQA-00047g-Nu for Megaco@ietf.org; Tue, 18 Oct 2005 04:02:09 -0400 Received: from [127.0.0.1] (really [138.217.150.87]) by omta05ps.mx.bigpond.com with ESMTP id <20051018074953.GDER7407.omta05ps.mx.bigpond.com@[127.0.0.1]>; Tue, 18 Oct 2005 07:49:53 +0000 Message-ID: <4354A91C.2050102@bigpond.net.au> Date: Tue, 18 Oct 2005 17:49:48 +1000 From: Christian Groves User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Albrecht.Schwarz@alcatel.de Subject: Re: [Megaco] Silence Suppression References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Authentication-Info: Submitted using SMTP AUTH PLAIN at omta05ps.mx.bigpond.com from [138.217.150.87] using ID cngroves@bigpond.net.au at Tue, 18 Oct 2005 07:49:51 +0000 X-Spam-Score: 0.1 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id DAA10874 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 Hello Albrecht, Are you refering to G.711 Appendix II? "Single Codec" was added to=20 Q.765.5 before Appendix II came into being. Therefore a codec point for=20 G.711 with Silence suppression was not added. If someone requires a=20 codepoint for this in Q.765.5 then a submission should be made to ITU=20 SG11 for an amendment. regards, Christian Albrecht.Schwarz@alcatel.de wrote: >Hi Christian, > >"Q.765.5, =A7 11.1.7.2.1.1 Codec Type subfield" >provides codepoints for silence suppression modes of G.723.1 and G.729 >codecs. > >How would you enable/disable silence suppression mode for G.711 in case = of >H.248 binary encoding mode? >Couldn't find any code in Q.765.5. > >Thanks, >Albrecht > > > > = =20 > Christian Groves = =20 > =20 > d.net.au> cc: Michal Yachimovi= tz , Victoria Mendelevich =20 > Sent by: , Megaco@ietf.org, Rima Mazorov =20 > megaco-bounces@i =20 > etf.org Subject: Re: [Megaco] Sil= ence Suppression =20 > = =20 > = =20 > 14.10.2005 05:42 = =20 > = =20 > > > > >Hello all, > >The value of Acodec (Annex C and used by Q.1950/3GPP Ts29.232) may also >specify silence suppression for a given codec type. See the codec type >subfield in Q.765.5 > >Christian > >Maridi R. Makaraju (Raju) wrote: > > =20 > >>Tamar, >> >>RFC 3108 defines 'silenceSupp' >>SDP parameter. You can take a look at it. >>(The RFC is meant for ATM bearers but the silenceSupp can be used for >>all bearer types). >>For binary encoding you can use Annex C. >> >>I don't think there is any package which attempts to defined them as th= ey >>are available in AnnexC(for binary) and in RFC 3108 for text. >> >>-Raju >> >> -----Original Message----- >> *From:* megaco-bounces@ietf.org >> [mailto:megaco-bounces@ietf.org]*On Behalf Of *Tamar Nemet >> *Sent:* Monday, October 10, 2005 4:07 AM >> *To:* Megaco@ietf.org >> *Cc:* Victoria Mendelevich; Michal Yachimovitz; Rima Mazorov >> *Subject:* [Megaco] Silence Suppression >> >> Hello, >> >> I am looking for the package which include silence suppression >> (ON/OFF ?). >> >> I looked at the tdmc package and I found there echo cancellation >> and gain control, but no silence suppression. >> >> Does anybody know where is it ? >> >> Thanks, >> Tamar >> >>-----------------------------------------------------------------------= - >> >>_______________________________________________ >>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 Tue Oct 18 05:21:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERnez-0002ZB-KW; Tue, 18 Oct 2005 05:21:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERney-0002Z0-FN for megaco@megatron.ietf.org; Tue, 18 Oct 2005 05:21:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16007 for ; Tue, 18 Oct 2005 05:21:20 -0400 (EDT) Received: from smtpoutuk02.marconi.com ([128.87.251.113]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERnqT-0006sQ-2P for megaco@ietf.org; Tue, 18 Oct 2005 05:33:21 -0400 Received: from cvdgwy02.uk.marconicomms.com (cvis27.uk.marconicomms.com [128.87.251.110]) by smtpoutuk02.marconi.com (8.12.11/8.12.11) with ESMTP id j9I9LDlk022771 for ; Tue, 18 Oct 2005 10:21:13 +0100 (envelope-from Stephen.Mell@marconi.com) To: "xsun" Subject: Re: [Megaco] ON-OFF signals in signal list MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: "Stephen Mell" Date: Tue, 18 Oct 2005 10:21:11 +0100 X-MIMETrack: Serialize by Router on CVDGWY02/S/EXT/MC1(5012HF354 | August 26, 2003) at 18/10/2005 10:21:16, Serialize complete at 18/10/2005 10:21:16 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac 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: , Content-Type: multipart/mixed; boundary="===============0216987393==" Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org This is a multipart message in MIME format. --===============0216987393== Content-Type: multipart/alternative; boundary="=_alternative 003362088025709E_=" This is a multipart message in MIME format. --=_alternative 003362088025709E_= Content-Type: text/plain; charset="us-ascii" > > How about two Modify commands in the same transaction, one restoring > > normal polarity, the other applying the ringing? > Tom, > There are two issues here: > 1. My polarity must be kept reversed while ringing. > With two Modify commands, the 1st one contains > Signals{xal/las}, the 2nd one contains Signals{altert/ri}, > how to interpret this requirement from H248.1: > "Production of a signal on a termination > is stopped by application of a new SignalsDescriptor". > What does "is stopped" mean here for on-off signals > such as xal/las? > 2. A general need is a standard to > accomplish the following two actions sequentially: > 1) apply an on/off signal sig1 (e.g., xal/las) > 2) delay X millisec > 3) apply sig2, (e.g. ringing) > H248v3 defines an inter signal delay, which is great. > So if SignalList{sig1,sig2} had been allowed for on-off sig1, > then it would have been perfect. But H248v3 still restrict > "Only the trailing element of the sequence of signals in a > sequential signal list may be an on/off signal." > It would be great to hear any comments of the standard > for above two issues. > Thanks a lot for your helpfull discussions. > -Richard There are drawbacks with the On/Off disposition of some of these steady state DC signals; it would seem to imply that the line condition returns to "idle" when that signal is stopped (or completes if it is changed to a timeout disposition). In your case that is not what you require, as the reversal condition should persist throughout the next signal. Really you need a signal that is defined (or can meaningfully have its disposition changed to) brief, such that its duration as a brief signal is merely the time it takes to switch to the new line condition. In this case the line condition would actually persist until it is explicitly removed. So a package which explicitly describes all possible line conditions would be required, so that you can remove the reversal at the end of ringing, if you need to. H.248.34 goes some way to doing this by describing all the line conditions, but this only really defines behaviour as OnOff, and would again imply that a "default/idle" DC line condition is applied when the signal is replaced. In practice MGs may very well let the existing DC "stedsig" line condition remain during the period that subsequent signals like ringing are made, until a specific change is made to the line condition, but it is far from clear that that is the correct way to behave. I see that you are not trying to indicate called party answer by sending "xal/las", but are instead simply trying to effect a line reversal (to wake up a ringer amp?), and then start other signals in parallel. This seems to be partly the reason why the signal is causing you problems. I'd be tempted to use a signal that is less purpose-specific, I wouldn't be surprised to find that some MGs failed to apply "xal/las" in the face of an on-hook line condition. Steve --=_alternative 003362088025709E_= Content-Type: text/html; charset="us-ascii"
> > How about two Modify commands in the same transaction, one restoring
> > normal polarity, the other applying the ringing?

> Tom,
> There are two issues here:

> 1. My polarity must be kept reversed while ringing.
>     With two Modify commands, the 1st one contains
>     Signals{xal/las}, the 2nd one contains Signals{altert/ri},
>     how to interpret this requirement from H248.1:
>     "Production of a signal on a termination
>     is stopped by application of a new SignalsDescriptor".
>     What does "is stopped" mean here for on-off signals
>     such as xal/las?

> 2. A general need is a standard to
>     accomplish the following two actions sequentially:
>     1) apply an on/off signal sig1 (e.g., xal/las)
>    2) delay X millisec
>    3) apply sig2, (e.g. ringing)

>    H248v3 defines an inter signal delay, which is great.
>     So if SignalList{sig1,sig2} had been allowed for on-off sig1,
>     then it would have been perfect. But H248v3 still restrict
>     "Only the trailing element of the sequence of signals in a
>     sequential signal list may be an on/off signal."

> It would be great to hear any comments of the standard
> for above two issues.
> Thanks a lot for your helpfull discussions.

> -Richard


There are drawbacks with the On/Off disposition of some of these steady state DC signals; it would seem
to imply that the line condition returns to "idle" when that signal is stopped (or completes if it is
changed to a timeout disposition). In your case that is not what you require, as the reversal condition
should persist throughout the next signal.

Really you need a signal that is defined (or can meaningfully have its disposition changed to) brief, such
that its duration as a brief signal is merely the time it takes to switch to the new line condition.
In this case the line condition would actually persist until it is explicitly removed. So a package which
explicitly describes all possible line conditions would be required, so that you can remove the reversal
at the end of ringing, if you need to.

H.248.34 goes some way to doing this by describing all the line conditions, but this only really defines
behaviour as OnOff, and would again imply that a "default/idle" DC line condition is applied when the signal
is replaced. In practice MGs may very well let the existing DC "stedsig" line condition remain during
the period that subsequent signals like ringing are made, until a specific change is made to the line
condition, but it is far from clear that that is the correct way to behave.

I see that you are not trying to indicate called party answer by sending "xal/las", but are instead simply
trying to effect a line reversal (to wake up a ringer amp?), and then start other signals in parallel. This seems
to be partly the reason why the signal is causing you problems.

I'd be tempted to use a signal that is less purpose-specific, I wouldn't be surprised to find that some MGs
failed to apply "xal/las" in the face of an on-hook line condition.



Steve --=_alternative 003362088025709E_=-- --===============0216987393== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============0216987393==-- From megaco-bounces@ietf.org Tue Oct 18 06:14:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERoU7-00045s-Pm; Tue, 18 Oct 2005 06:14:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERoU6-00043q-1R for megaco@megatron.ietf.org; Tue, 18 Oct 2005 06:14:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19073 for ; Tue, 18 Oct 2005 06:14:09 -0400 (EDT) Received: from smtp.dataconnection.com ([192.91.191.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERofa-0008Nn-SZ for megaco@ietf.org; Tue, 18 Oct 2005 06:26:12 -0400 Received: from enfimail1.datcon.co.uk ([172.19.14.253]) by smtp.dataconnection.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Oct 2005 11:14:00 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 18 Oct 2005 11:08:50 +0100 Message-ID: <8E4A9A66F7AED54C89F478AF4477C7D819D0AC@enfimail1.datcon.co.uk> Thread-Topic: Question on H.248.9, 2005 draft. Thread-Index: AcXTy++fyeHSr/a2SsKGC54laWVV8w== From: "Nick Cawdery" To: X-OriginalArrivalTime: 18 Oct 2005 10:14:00.0911 (UTC) FILETIME=[A8D2E5F0:01C5D3CC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: quoted-printable Subject: [Megaco] Question on H.248.9, 2005 draft. 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 I have a question about following section (9.3.1.1.19) in the latest = draft version of H.248.9 (dated "??/2005"). ------------------------------------------------------ This parameter indicates the digit used to signal the end of input. When the Maximum Number of Digits equals the Minimum Number of Digits, = the End Input Key (could be present but) has no meaning. This parameter = can be one or two digits. When the Maximum Number of Digits is greater = than the Minimum Number of Digits the following applies: If the End Input Key is not present, the end of input is indicated: - when the inter-digit timer expires; or - when the number of valid digits received equals the Maximum Number of = Digits. If the End Input Key is present, the end of input is indicated: - when the inter-digit timer expires; or - when the end input digit is received; or - when the number of valid digits received equals the Maximum Number of = Digits. If the inter digit timer expires or the End Input Key is received and = the number of valid digits received is less than the Minimum Number of = Digits, the input is specified as being erroneous. This parameter corresponds to the INAP parameter 'endOfReplyDigit'. --------------------------------------------------------- This section refers to a "Minimum Number of Digits" and "Maximum Number = of Digits". These are not mentioned anywhere else in the document, so = we assume that the inclusion of this entire section is an editorial = error. Is this the case? =20 [These fields are referenced in texts describing the INAP parameter = 'endOfReplyDigit' (which EndInputKey "corresponds to") - = http://www.itu.int/ITU-T/asn1/database/itu-t/q/q1248.3/2001/IN-SCF-SRF-da= tatypes.html.] Thanks in advance for your help.=20 Nick _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Tue Oct 18 07:05:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERpHb-0003gf-7v; Tue, 18 Oct 2005 07:05:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERkgX-0000A2-9D for megaco@megatron.ietf.org; Tue, 18 Oct 2005 02:10:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06219 for ; Tue, 18 Oct 2005 02:10:44 -0400 (EDT) Received: from zproxy.gmail.com ([64.233.162.206]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERks0-0001lF-6y for megaco@ietf.org; Tue, 18 Oct 2005 02:22:45 -0400 Received: by zproxy.gmail.com with SMTP id 12so1081872nzp for ; Mon, 17 Oct 2005 23:10:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=M7fApC29TPvKpcVxAeC5DOsiFXrjrcS7hs1J347vhoU7u3vAnibw+9Y31bi89lLJw+47f9bxOXJPSEqM08YNYr7szjneWp4DEESDXdS9kAwdAY2YWPqHZEgcIILN3afMlxANYMWqvIgRlGTt+voMNd0d2gAdq6AE9YAxURgLqi8= Received: by 10.37.2.16 with SMTP id e16mr3468163nzi; Mon, 17 Oct 2005 23:10:51 -0700 (PDT) Received: by 10.36.19.15 with HTTP; Mon, 17 Oct 2005 23:10:51 -0700 (PDT) Message-ID: <7985f0f50510172310o386bcc0ek@mail.gmail.com> Date: Tue, 18 Oct 2005 14:10:51 +0800 From: suker davor To: xsun@lucent.com Subject: Re: [Megaco] ON-OFF signals in signal list MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 18 Oct 2005 07:05:25 -0400 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 HI, Could the 'keepactive flag' can be used for issue 1? _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Tue Oct 18 10:36:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERsaH-0001qe-7i; Tue, 18 Oct 2005 10:36:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERsaF-0001qG-Cg for megaco@megatron.ietf.org; Tue, 18 Oct 2005 10:36:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04400 for ; Tue, 18 Oct 2005 10:36:47 -0400 (EDT) Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERslm-0007OU-Iv for megaco@ietf.org; Tue, 18 Oct 2005 10:48:51 -0400 Received: from homail.ho.lucent.com (h135-17-192-10.lucent.com [135.17.192.10]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id j9IEapp2009301 for ; Tue, 18 Oct 2005 09:36:51 -0500 (CDT) Received: from [135.112.125.111] ([135.112.125.111]) by homail.ho.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id j9IEapt16695; Tue, 18 Oct 2005 10:36:51 -0400 (EDT) Message-ID: <43550B63.5090301@lucent.com> Date: Tue, 18 Oct 2005 10:49:07 -0400 From: Richard Sun User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: megaco@ietf.org Subject: Re: [Megaco] ON-OFF signals in signal list References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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 One more question on H248.34 and the following text in H248.1: "Production of a signal on a termination is stopped by application of a new SignalsDescriptor". Consider the following 2 scenarios, where the SignalDescriptors are received in the sequential order. Scenario1: Signals{stimal/stedsig{sig=reversePolarity}} Signals{stimal/stedsig{sig=normalPolarity}}} Signals{} Scenario2: Signals{stimal/stedsig{sig=reversePolarity}} Signals{} The end result of the line for Scenario2 should be normal polarity, right? What should be the end result of the line for Scenario1? I noticed some discussions regarding returning provisioned default value for Subtract. One may also argue that Signal{} should return to default for all signals. But even so, what about the end result of the polarity in the following: Scenario3: Signals{stimal/stedsig{sig=reversePolarity}} Signals{stimal/stedsig{sig=normalPolarity}}} Signals{alert/ri} -Richard _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Wed Oct 19 08:51:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESDPp-0003Om-S8; Wed, 19 Oct 2005 08:51:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESDPo-0003Ms-4o for megaco@megatron.ietf.org; Wed, 19 Oct 2005 08:51:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13833 for ; Wed, 19 Oct 2005 08:51:22 -0400 (EDT) Received: from smtpoutuk02.marconi.com ([128.87.251.113]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESDbU-0002Ms-S5 for megaco@ietf.org; Wed, 19 Oct 2005 09:03:40 -0400 Received: from cvdgwy02.uk.marconicomms.com (cvis27.uk.marconicomms.com [128.87.251.110]) by smtpoutuk02.marconi.com (8.12.11/8.12.11) with ESMTP id j9JCp9ve006114; Wed, 19 Oct 2005 13:51:11 +0100 (envelope-from Stephen.Mell@marconi.com) To: Subject: Re: [Megaco] ON-OFF signals in signal list MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: "Stephen Mell" Date: Wed, 19 Oct 2005 13:51:06 +0100 X-MIMETrack: Serialize by Router on CVDGWY02/S/EXT/MC1(5012HF354 | August 26, 2003) at 19/10/2005 13:51:14, Serialize complete at 19/10/2005 13:51:14 X-Spam-Score: 0.5 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db 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: , Content-Type: multipart/mixed; boundary="===============2046491402==" Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org This is a multipart message in MIME format. --===============2046491402== Content-Type: multipart/alternative; boundary="=_alternative 004699C98025709F_=" This is a multipart message in MIME format. --=_alternative 004699C98025709F_= Content-Type: text/plain; charset="us-ascii" Hi richard, We are making an assumption here that there is a default line state that will be applied when all signals are removed. Now that default could be "idle" (normal polarity) or perhaps "parked" (reduced battery). With signals like "ringing" it is more obvious what the default line state is ( "not ringing!!!!" ). But with the DC line conditions it is not. I don't think that stimal package provides much guidance. I think a lot of Analogue Gateways will allow the DC line condition (wherever possible) to persist during the application of further signals, but that is down to implementation. Thats why it should really be possible to modify the signal type to brief, and the package should allow this and describe its behaviour: { stimal/stedsig{sig=reversePolarity, SY=BR}, alert/ri } so that you can put this anywhere in a signal list. Then the polarity is reversed during alert/ri and remains reversed until something explicitly change it back, or a signal is played which implicitly requires a change in line state. Steve --=_alternative 004699C98025709F_= Content-Type: text/html; charset="us-ascii"
Hi richard,

We are making an assumption here that there is a default line state that will be applied when all signals are removed.

Now that default could be "idle" (normal polarity) or perhaps "parked" (reduced battery).

With signals like "ringing" it is more obvious what the default line state is ( "not ringing!!!!" ). But with the DC line conditions it is not.

I don't think that stimal package provides much guidance.

I think a lot of Analogue Gateways will allow the DC line condition (wherever possible) to persist during the application of further signals, but that is down to implementation.



Thats why it should really be possible to modify the signal type to brief, and the package should allow this and describe its behaviour:

{
  stimal/stedsig{sig=reversePolarity, SY=BR},
  alert/ri
}

so that you can put this anywhere in a signal list. Then the polarity is reversed during alert/ri and remains reversed until something explicitly change it back, or a signal is played

which implicitly requires a change in line state.




Steve










--=_alternative 004699C98025709F_=-- --===============2046491402== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============2046491402==-- From megaco-bounces@ietf.org Thu Oct 20 01:50:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESTKC-0000qd-MC; Thu, 20 Oct 2005 01:50:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESTKA-0000q2-Ft for megaco@megatron.ietf.org; Thu, 20 Oct 2005 01:50:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13032 for ; Thu, 20 Oct 2005 01:50:36 -0400 (EDT) Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESTW1-0001JK-Bc for megaco@ietf.org; Thu, 20 Oct 2005 02:03:03 -0400 Received: from horh1.emsr.lucent.com (h135-112-138-211.lucent.com [135.112.138.211]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id j9K5ofJP014337 for ; Thu, 20 Oct 2005 00:50:41 -0500 (CDT) Received: from new-wopr.eng.ascend.com (new-wopr.eng.ascend.com [135.140.53.19]) by horh1.emsr.lucent.com (8.12.11/8.12.11) with ESMTP id j9K5ocp5025906; Thu, 20 Oct 2005 00:50:39 -0500 (CDT) Received: from india.ascend.com (indiamail.india.ascend.com [135.254.196.198]) by new-wopr.eng.ascend.com (8.11.6+Sun/8.10.2) with ESMTP id j9K5ob815093; Wed, 19 Oct 2005 22:50:37 -0700 (PDT) Received: from lucent.com (spokane.india.ascend.com [135.254.196.68]) by india.ascend.com (8.8.8+Sun/8.8.8) with ESMTP id LAA24880; Thu, 20 Oct 2005 11:20:35 +0530 (IST) Message-ID: <4357302B.70C9A4A7@lucent.com> Date: Thu, 20 Oct 2005 11:20:35 +0530 From: Naveen Sujit Kumar X-Mailer: Mozilla 4.79 [en] (X11; U; SunOS 5.6 i86pc) X-Accept-Language: en MIME-Version: 1.0 To: "megaco@ietf.org" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: 7bit Cc: Subject: [Megaco] Query on H.248 ReserveValue Implementation 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, Resending the mail as I did not get any responses for the first mail. I had few queries regarding MG's behaviour when ReserveValue was 'On'. 1. The Add message contains both local and remote descriptors with a list of codecs. There might be common codecs between the two descriptors. The message might be like this: Add = R$ {Media { LocalControl {Mode = ReceiveOnly,ReservedValue=ON}, Local { v=0 c=IN IP4 7.7.7.160 m=audio 20000 RTP/AVP 0 18 4 <<<<< a=ptime:20 }, Remote { v=0 c=IN IP4 7.7.7.123 m=audio 20000 RTP/AVP 0 18 <<<<< a=ptime:20 } } } } } What exactly should we do when we have both local and remote descriptors..?? * Should only one descriptor be considered..?? Or * Should MG go thro' both the lists and take only the common codecs ( 0 18 ) for consideration..?? Or * Should both the lists be treated seperately and resources reserved for the same..?? * Also, what should be the behaviour if there are no common codecs between local and remote descriptors..?? Is there any such real world application for any of the above conditions..?? 2. How does Ignore go with ReserveValue..?? The message might be like this: Add = R$ {Media { LocalControl {Mode = ReceiveOnly,ReservedValue=ON}, Local { v=0 c=IN IP4 7.7.7.160 m=audio 20000 RTP/AVP - <<<<< a=ptime:20 } } } } } What needs to be done here..?? Should we return an empty descriptor as RFC says, since we cannot reserve any resources..?? Or should we return an error and what needs to be the error value..?? TIA for any suggestions, -Naveen _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Fri Oct 21 06:51:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESuVC-0004Fg-KF; Fri, 21 Oct 2005 06:51:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESuVA-00048k-KU for megaco@megatron.ietf.org; Fri, 21 Oct 2005 06:51:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13355 for ; Fri, 21 Oct 2005 06:51:46 -0400 (EDT) Received: from web54211.mail.yahoo.com ([206.190.39.44]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ESuhF-0003rs-N1 for megaco@ietf.org; Fri, 21 Oct 2005 07:04:29 -0400 Received: (qmail 78886 invoked by uid 60001); 21 Oct 2005 10:51:44 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.hk; h=Message-ID:Received:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Ff0vR+Nv9l8DYqL+mGQPab5Ta3OM3nSR3qO86lp00ejNm++vVl23/S21R46t4CzfIjIntcw8oVU5a5DivTHP5DGDwjs9NjY3Tf/QujlrnJEYGS2ZRXNpdt9x1mfn49Od3hWolObVGkw7uX7JBc/kTWR+UEqxwgGEdJlboAs6U5I= ; Message-ID: <20051021105144.78884.qmail@web54211.mail.yahoo.com> Received: from [194.237.142.10] by web54211.mail.yahoo.com via HTTP; Fri, 21 Oct 2005 18:51:44 CST Date: Fri, 21 Oct 2005 18:51:44 +0800 (CST) From: Tonny Kung To: megaco@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Subject: [Megaco] RequestID in EventsDescriptor X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mail2tonny-megaco@yahoo.com.hk List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0700034379==" Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org --===============0700034379== Content-Type: multipart/alternative; boundary="0-1841612893-1129891904=:78800" --0-1841612893-1129891904=:78800 Content-Type: text/plain; charset=big5 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id GAA13355 Hi All, =20 I have some doubts regarding the use of RequestID =3D 0. =20 1) Is it allowed for the MGC to arm an event in the MG with RequestID set= to 0? =20 2) When an event is not armed by the MGC, but provisioned in the MG, what= RequestID should the MG use in the Notify message?=20 >From reading H.248.1 section 7.2.7 Notify, I'm assuming it should be 0. B= ut then it stated the use of RequestID =3D 0 is for further study.=20 =20 I would appreciate if someone can clarify that. =20 Thanks, Tonny _______________________________________ =B7Q=A7Y=AE=C9=A6=AC=A8=EC=B7s email =B3q=AA=BE=A1H =A4U=B8=FC Yahoo! Messenger http://messenger.yahoo.com.hk=20 --0-1841612893-1129891904=:78800 Content-Type: text/html; charset=big5 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id GAA13355
Hi All,
 
I have some doubts regarding the use of RequestID =3D 0.
 
1) Is it allowed for the MGC to arm an event in the MG with RequestI= D set to 0?
 
2) When an event is not armed by the MGC, but provisioned in the MG,= what RequestID should the MG use in the Notify message?
From reading H.248.1 section 7.2.7 Notify, I'm assuming it should be= 0. But then it stated the use of RequestID =3D 0 is for further study. <= /DIV>
 
I would appreciate if someone can clarify that.
 
Thanks,
Tonny

_______________________________________
=B7Q=A7Y=AE= =C9=A6=AC=A8=EC=B7s email =B3q=AA=BE=A1H
=A4U=B8=FC Yahoo! Messenger = http://messenger.yahoo.com.hk=20 --0-1841612893-1129891904=:78800-- --===============0700034379== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============0700034379==-- From megaco-bounces@ietf.org Fri Oct 21 10:52:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESyFt-000348-LZ; Fri, 21 Oct 2005 10:52:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESyFs-00033t-Dv for megaco@megatron.ietf.org; Fri, 21 Oct 2005 10:52:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26145 for ; Fri, 21 Oct 2005 10:52:13 -0400 (EDT) From: peter.tury@nokia.com Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESyS1-00041H-8W for megaco@ietf.org; Fri, 21 Oct 2005 11:04:58 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j9LEoAVg029134 for ; Fri, 21 Oct 2005 17:50:12 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Oct 2005 17:52:18 +0300 Received: from buebe101.NOE.Nokia.com ([10.211.0.53]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Oct 2005 17:52:18 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 21 Oct 2005 16:52:16 +0200 Message-ID: <4B5BDDC9AE76CA47AF37CE848F0DE46CDE46A4@buebe101.NOE.Nokia.com> Thread-Topic: serviceChangeReason code's length Thread-Index: AcXWTEhEifqsWY0xRtyWf6aZYJSCwwAAiS0A To: X-OriginalArrivalTime: 21 Oct 2005 14:52:18.0079 (UTC) FILETIME=[0859CAF0:01C5D64F] X-Spam-Score: 0.3 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable Subject: [Megaco] serviceChangeReason code's length 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, "A serviceChangeReason consists of a numeric reason code and an optional text description." These codes now are 3 digit long (between 900 and 920). Is it garanteed anywhere that these codes are always exactly 3 digit long? (E.g. in H.248.1 one can read: "14.3 ServiceChange reasons The following considerations SHALL be met to register service change reason with IANA: 1) A one-phrase, 80-character maximum, unique reason code is registered for each reason." Is this a bug in the standard's text? Or this refers only to IANA's needs, while the standard can be more strict? I haven't found any other restrictions on the length of this code... Do they exist anywhere?) Thanks, Peter Tury _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Mon Oct 24 01:36:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETv0v-0002kg-4g; Mon, 24 Oct 2005 01:36:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETv0t-0002kY-Cn for megaco@megatron.ietf.org; Mon, 24 Oct 2005 01:36:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16312 for ; Mon, 24 Oct 2005 01:36:37 -0400 (EDT) Received: from ns2.nec.com.au ([147.76.180.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ETvDY-0004ks-MA for megaco@ietf.org; Mon, 24 Oct 2005 01:49:58 -0400 Received: from tns.neca.nec.com.au (localhost.localdomain [127.0.0.1]) by smtp2.nec.com.au (8.12.8/8.12.8) with ESMTP id j9O5aWTf014685 for ; Mon, 24 Oct 2005 15:36:32 +1000 Received: from JFISHERXPP ([147.76.208.107]) by tns.neca.nec.com.au (8.12.8/8.12.8) with SMTP id j9O5aTiE017087 for ; Mon, 24 Oct 2005 15:36:30 +1000 From: "John Fisher" To: Date: Mon, 24 Oct 2005 15:34:05 +1000 Message-ID: <000401c5d85c$8d78eb30$6bd04c93@JFISHERXPP> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: 7bit Subject: [Megaco] Wikipedia article X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: john.fisher@nec.com.au List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org Dear Megaco members, I would like to draw your attention to the fact that the Wikipedia article on Megaco, http:\\en.wikipedia.org\wiki\Megaco is still a stub. Introductory material on Megaco is scarce, and writing a Wikipedia article would be a good way to improve that situation. Perhaps some of the readers of this mailing list would like to contribute to such an article. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Mon Oct 24 11:34:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU4LG-0006KW-3g; Mon, 24 Oct 2005 11:34:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU4LD-0006K2-Mj for megaco@megatron.ietf.org; Mon, 24 Oct 2005 11:34:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15790 for ; Mon, 24 Oct 2005 11:34:14 -0400 (EDT) From: Albrecht.Schwarz@alcatel.de Received: from mailrelay2.alcatel.de ([194.113.59.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EU4Xy-0007ey-EN for megaco@ietf.org; Mon, 24 Oct 2005 11:47:39 -0400 Received: from demail05.netfr.alcatel.fr (demail05.netfr.alcatel.fr [155.132.182.205]) by mailrelay2.alcatel.de (8.12.10/8.12.10/ICT TSC MAIL 2005) with ESMTP id j9OFY9DO032660; Mon, 24 Oct 2005 17:34:09 +0200 In-Reply-To: <4357302B.70C9A4A7@lucent.com> Subject: Re: [Megaco] Query on H.248 ReserveValue Implementation To: Naveen Sujit Kumar X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: Date: Mon, 24 Oct 2005 17:34:08 +0200 X-MIMETrack: Serialize by Router on DEMAIL05/DE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 10/24/2005 17:34:09 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.49 on 149.204.45.73 X-Spam-Score: 0.3 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 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 Naveen, just a comment to your first block of questions: There is NO correlation between LD & RD data (like codec types, packetization times, etc) from H.248 perspective. There might be (in theory) an asymmetrical application using different media coding/encapsulation in both direction (in case of bidirection communication). Guess this topic was already mentioned on the list in the past ("search in the archive"). ... perhaps your questions will change then ... - Albrecht Naveen Sujit Kumar To: "megaco@ietf.org" Subject: [Megaco] Query on H.248 ReserveValue Implementation Sent by: megaco-bounces@i etf.org 20.10.2005 07:50 Hi All, Resending the mail as I did not get any responses for the first mail. I had few queries regarding MG's behaviour when ReserveValue was 'On'. 1. The Add message contains both local and remote descriptors with a list of codecs. There might be common codecs between the two descriptors. The message might be like this: Add = R$ {Media { LocalControl {Mode = ReceiveOnly,ReservedValue=ON}, Local { v=0 c=IN IP4 7.7.7.160 m=audio 20000 RTP/AVP 0 18 4 <<<<< a=ptime:20 }, Remote { v=0 c=IN IP4 7.7.7.123 m=audio 20000 RTP/AVP 0 18 <<<<< a=ptime:20 } } } } } What exactly should we do when we have both local and remote descriptors..?? * Should only one descriptor be considered..?? Or * Should MG go thro' both the lists and take only the common codecs ( 0 18 ) for consideration..?? Or * Should both the lists be treated seperately and resources reserved for the same..?? * Also, what should be the behaviour if there are no common codecs between local and remote descriptors..?? Is there any such real world application for any of the above conditions..?? 2. How does Ignore go with ReserveValue..?? The message might be like this: Add = R$ {Media { LocalControl {Mode = ReceiveOnly,ReservedValue=ON}, Local { v=0 c=IN IP4 7.7.7.160 m=audio 20000 RTP/AVP - <<<<< a=ptime:20 } } } } } What needs to be done here..?? Should we return an empty descriptor as RFC says, since we cannot reserve any resources..?? Or should we return an error and what needs to be the error value..?? TIA for any suggestions, -Naveen _______________________________________________ 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 Oct 25 10:15:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUPa0-0000rh-Kh; Tue, 25 Oct 2005 10:15:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUPa0-0000rc-1V for megaco@megatron.ietf.org; Tue, 25 Oct 2005 10:15:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19638 for ; Tue, 25 Oct 2005 10:14:53 -0400 (EDT) Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUPmx-0003xg-MS for megaco@ietf.org; Tue, 25 Oct 2005 10:28:32 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id A71434F0006 for ; Tue, 25 Oct 2005 16:14:40 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Oct 2005 16:13:26 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Oct 2005 16:13:16 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 25 Oct 2005 16:13:14 +0200 Message-ID: Thread-Topic: [Megaco] Descriptor order Thread-Index: AcWQuUniXcOqgt7bSGmTNY/jCTvoNwAHrbygAAFWAUAAL/FzwADfH6TwCF/LWHAARwWUEAhuH5jw From: "Christer Holmberg (JO/LMF)" To: X-OriginalArrivalTime: 25 Oct 2005 14:13:16.0979 (UTC) FILETIME=[3E994830:01C5D96E] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: quoted-printable Subject: [Megaco] Empty 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, The ABNF currenty says: localDescriptor =3D LocalToken LBRKT octetString RBRKT remoteDescriptor =3D RemoteToken LBRKT octetString RBRKT signalsDescriptor =3D SignalsToken [LBRKT signalParm *(COMMA = signalParm) RBRKT] ISSUE: To me this means that an empty local (or remote) descriptor looks like: Local {} ...while an empty signals descriptor looks like: Signal QUESTION:=20 Why are curly brackets requried for an empty local/remote descriptor, = but not for an empty signals descriptor? Regards, Christer LM Ericsson _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Tue Oct 25 12:30:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EURhA-00013l-Qb; Tue, 25 Oct 2005 12:30:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EURh8-000135-Am for megaco@megatron.ietf.org; Tue, 25 Oct 2005 12:30:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03327 for ; Tue, 25 Oct 2005 12:30:22 -0400 (EDT) Received: from smtpoutuk02.marconi.com ([128.87.251.113]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EURu7-0001UW-Fi for megaco@ietf.org; Tue, 25 Oct 2005 12:44:04 -0400 Received: from cvdgwy02.uk.marconicomms.com (cvis27.uk.marconicomms.com [128.87.251.110]) by smtpoutuk02.marconi.com (8.12.11/8.12.11) with ESMTP id j9PGUJxK025160; Tue, 25 Oct 2005 17:30:19 +0100 (envelope-from Stephen.Mell@marconi.com) To: christer.holmberg@ericsson.com Subject: Re: [MEGACO] Empty descriptor (Christer Holmberg (JO/LMF)) MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: "Stephen Mell" Date: Tue, 25 Oct 2005 17:30:21 +0100 X-MIMETrack: Serialize by Router on CVDGWY02/S/EXT/MC1(5012HF354 | August 26, 2003) at 25/10/2005 17:30:24, Serialize complete at 25/10/2005 17:30:24 X-Spam-Score: 0.5 (/) X-Scan-Signature: 76c7db407a166e4c39f35d8215d8dd32 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: , Content-Type: multipart/mixed; boundary="===============1106225560==" Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org This is a multipart message in MIME format. --===============1106225560== Content-Type: multipart/alternative; boundary="=_alternative 005AACE0802570A5_=" This is a multipart message in MIME format. --=_alternative 005AACE0802570A5_= Content-Type: text/plain; charset="us-ascii" The v2. ABNF for signalsDescriptor is: signalsDescriptor = SignalsToken LBRKT [signalParm *(COMMA signalParm)] RBRKT Where you thinking of Events? Steve megaco-request@ietf.org Sent by: megaco-bounces@ietf.org 25/10/2005 17:12 Please respond to megaco To: megaco@ietf.org cc: Subject: Megaco Digest, Vol 18, Issue 22 Send Megaco mailing list submissions to megaco@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www1.ietf.org/mailman/listinfo/megaco or, via email, send a message with subject or body 'help' to megaco-request@ietf.org You can reach the person managing the list at megaco-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Megaco digest..." Today's Topics: 1. Empty descriptor (Christer Holmberg (JO/LMF)) ---------------------------------------------------------------------- Message: 1 Date: Tue, 25 Oct 2005 16:13:14 +0200 From: "Christer Holmberg (JO/LMF)" Subject: [Megaco] Empty descriptor To: Message-ID: Content-Type: text/plain; charset="iso-8859-1" Hi, The ABNF currenty says: localDescriptor = LocalToken LBRKT octetString RBRKT remoteDescriptor = RemoteToken LBRKT octetString RBRKT signalsDescriptor = SignalsToken [LBRKT signalParm *(COMMA signalParm) RBRKT] ISSUE: To me this means that an empty local (or remote) descriptor looks like: Local {} ...while an empty signals descriptor looks like: Signal QUESTION: Why are curly brackets requried for an empty local/remote descriptor, but not for an empty signals descriptor? Regards, Christer LM Ericsson ------------------------------ _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco End of Megaco Digest, Vol 18, Issue 22 ************************************** --=_alternative 005AACE0802570A5_= Content-Type: text/html; charset="us-ascii"
The v2. ABNF for signalsDescriptor is:

signalsDescriptor                                  = SignalsToken LBRKT [signalParm *(COMMA signalParm)] RBRKT


Where you thinking of Events?


Steve



megaco-request@ietf.org
Sent by: megaco-bounces@ietf.org

25/10/2005 17:12
Please respond to megaco

       
        To:        megaco@ietf.org
        cc:        
        Subject:        Megaco Digest, Vol 18, Issue 22



Send Megaco mailing list submissions to
                megaco@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
                https://www1.ietf.org/mailman/listinfo/megaco
or, via email, send a message with subject or body 'help' to
                megaco-request@ietf.org

You can reach the person managing the list at
                megaco-owner@ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Megaco digest..."


Today's Topics:

  1. Empty descriptor (Christer Holmberg (JO/LMF))


----------------------------------------------------------------------

Message: 1
Date: Tue, 25 Oct 2005 16:13:14 +0200
From: "Christer Holmberg (JO/LMF)" <christer.holmberg@ericsson.com>
Subject: [Megaco] Empty descriptor
To: <megaco@ietf.org>
Message-ID:
                <D60C37C9EF5C39459E0F4EF508E560A2CDCB42@esealmw113.eemea.ericsson.se>
Content-Type: text/plain;                 charset="iso-8859-1"


Hi,

The ABNF currenty says:

localDescriptor                                  = LocalToken LBRKT octetString RBRKT

remoteDescriptor                                  = RemoteToken LBRKT octetString RBRKT

signalsDescriptor                                  = SignalsToken [LBRKT signalParm *(COMMA signalParm)
                                                                                    RBRKT]

ISSUE:

To me this means that an empty local (or remote) descriptor looks like:

Local {}

...while an empty signals descriptor looks like:

Signal


QUESTION:

Why are curly brackets requried for an empty local/remote descriptor, but not for an empty signals descriptor?


Regards,

Christer
LM Ericsson



------------------------------

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


End of Megaco Digest, Vol 18, Issue 22
**************************************

--=_alternative 005AACE0802570A5_=-- --===============1106225560== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============1106225560==-- From megaco-bounces@ietf.org Tue Oct 25 12:54:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUS4H-0002tk-69; Tue, 25 Oct 2005 12:54:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUS4F-0002sI-L5 for megaco@megatron.ietf.org; Tue, 25 Oct 2005 12:54:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04795 for ; Tue, 25 Oct 2005 12:54:17 -0400 (EDT) Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUSHA-0002Gv-Kn for megaco@ietf.org; Tue, 25 Oct 2005 13:07:57 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id C2451A33; Tue, 25 Oct 2005 18:53:24 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 25 Oct 2005 18:52:59 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 25 Oct 2005 18:52:58 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [MEGACO] Empty descriptor (Christer Holmberg (JO/LMF)) Date: Tue, 25 Oct 2005 18:52:57 +0200 Message-ID: Thread-Topic: [MEGACO] Empty descriptor (Christer Holmberg (JO/LMF)) Thread-Index: AcXZgW3xnETZ0r/ETZKbKciZUf5EmAAAv7fQ From: "Christer Holmberg (JO/LMF)" To: "Stephen Mell" X-OriginalArrivalTime: 25 Oct 2005 16:52:58.0775 (UTC) FILETIME=[8DCB5270:01C5D984] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 1.0 (+) X-Scan-Signature: 4515df9441674711565101d9d5c4f63f 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: , Content-Type: multipart/mixed; boundary="===============2082256588==" Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org This is a multi-part message in MIME format. --===============2082256588== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5D984.8D514336" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5D984.8D514336 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 In v3 the ABNF has been changed. I appologize for not mentioning that. =20 Regards, =20 Christer -----Original Message----- From: Stephen Mell [mailto:Stephen.Mell@marconi.com] Sent: 25. lokakuuta 2005 19:30 To: Christer Holmberg (JO/LMF) Cc: megaco@ietf.org Subject: Re: [MEGACO] Empty descriptor (Christer Holmberg (JO/LMF)) The v2. ABNF for signalsDescriptor is:=20 signalsDescriptor =3D SignalsToken = LBRKT [signalParm *(COMMA signalParm)] RBRKT=20 Where you thinking of Events?=20 Steve=20 megaco-request@ietf.org=20 Sent by: megaco-bounces@ietf.org=20 25/10/2005 17:12=20 Please respond to megaco=20 =20 To: megaco@ietf.org=20 cc: =20 Subject: Megaco Digest, Vol 18, Issue 22 Send Megaco mailing list submissions to megaco@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www1.ietf.org/mailman/listinfo/megaco or, via email, send a message with subject or body 'help' to megaco-request@ietf.org You can reach the person managing the list at megaco-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Megaco digest..." Today's Topics: 1. Empty descriptor (Christer Holmberg (JO/LMF)) ---------------------------------------------------------------------- Message: 1 Date: Tue, 25 Oct 2005 16:13:14 +0200 From: "Christer Holmberg (JO/LMF)" Subject: [Megaco] Empty descriptor To: Message-ID: = Content-Type: text/plain; charset=3D"iso-8859-1" Hi, The ABNF currenty says: localDescriptor =3D LocalToken LBRKT = octetString RBRKT remoteDescriptor =3D RemoteToken LBRKT = octetString RBRKT signalsDescriptor =3D SignalsToken = [LBRKT signalParm *(COMMA signalParm) = RBRKT] ISSUE: To me this means that an empty local (or remote) descriptor looks like: Local {} ...while an empty signals descriptor looks like: Signal QUESTION:=20 Why are curly brackets requried for an empty local/remote descriptor, = but not for an empty signals descriptor? Regards, Christer LM Ericsson ------------------------------ _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco End of Megaco Digest, Vol 18, Issue 22 ************************************** ------_=_NextPart_001_01C5D984.8D514336 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,
 
In v3=20 the ABNF has been changed. I appologize for not mentioning=20 that.
 
Regards,
 
Christer
-----Original Message-----
From: Stephen Mell=20 [mailto:Stephen.Mell@marconi.com]
Sent: 25. lokakuuta 2005=20 19:30
To: Christer Holmberg (JO/LMF)
Cc:=20 megaco@ietf.org
Subject: Re: [MEGACO] Empty descriptor = (Christer=20 Holmberg (JO/LMF))


The=20 v2. ABNF for signalsDescriptor is:

signalsDescriptor             =  =20                   =  =3D=20 SignalsToken LBRKT [signalParm *(COMMA signalParm)] RBRKT=20


Where you thinking of=20 Events?


Steve=20



megaco-request@ietf.org=20
Sent by: = megaco-bounces@ietf.org=20

25/10/2005 17:12 =
Please respond to megaco =

        =
        To: =    =20    megaco@ietf.org
        cc:      =20  
    =  =20   Subject:        Megaco Digest, Vol = 18, Issue=20 22



Send=20 Megaco mailing list submissions to
        =  =20       megaco@ietf.org

To subscribe or = unsubscribe via=20 the World Wide Web, visit
            =  =20   https://www1.ietf.org/mailman/listinfo/megaco
or, via email, = send a=20 message with subject or body 'help' to
        =  =20       megaco-request@ietf.org

You can reach the = person=20 managing the list at
            =  =20   megaco-owner@ietf.org

When replying, please edit your = Subject=20 line so it is more specific
than "Re: Contents of Megaco=20 digest..."


Today's Topics:

  1. Empty = descriptor=20 (Christer Holmberg=20 = (JO/LMF))


----------------------------------------------------= ------------------

Message:=20 1
Date: Tue, 25 Oct 2005 16:13:14 +0200
From: "Christer Holmberg = (JO/LMF)" <christer.holmberg@ericsson.com>
Subject: [Megaco] = Empty=20 descriptor
To: <megaco@ietf.org>
Message-ID:
  =  =20            =20 = <D60C37C9EF5C39459E0F4EF508E560A2CDCB42@esealmw113.eemea.ericsson.se&g= t;
Content-Type:=20 text/plain;                =20 charset=3D"iso-8859-1"


Hi,

The ABNF currenty=20 says:

localDescriptor             =  =20                   =  =3D=20 LocalToken LBRKT octetString RBRKT

remoteDescriptor   =  =20                     =  =20        =3D RemoteToken LBRKT octetString=20 RBRKT

signalsDescriptor           =  =20                     =  =3D=20 SignalsToken [LBRKT signalParm *(COMMA signalParm)
    =  =20                     =  =20                     =  =20                     =  =20             = RBRKT]

ISSUE:

To me=20 this means that an empty local (or remote) descriptor looks = like:

Local=20 {}

...while an empty signals descriptor looks=20 like:

Signal


QUESTION:

Why are curly = brackets=20 requried for an empty local/remote descriptor, but not for an empty = signals=20 descriptor?


Regards,

Christer
LM=20 = Ericsson



------------------------------

___________= ____________________________________
Megaco=20 mailing=20 = list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco<= BR>

End=20 of Megaco Digest, Vol 18, Issue=20 = 22
**************************************


------_=_NextPart_001_01C5D984.8D514336-- --===============2082256588== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============2082256588==-- From megaco-bounces@ietf.org Tue Oct 25 13:07:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUSGy-0006IA-MA; Tue, 25 Oct 2005 13: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 1EUSGw-0006Dq-3G for megaco@megatron.ietf.org; Tue, 25 Oct 2005 13:07:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05965 for ; Tue, 25 Oct 2005 13:07:24 -0400 (EDT) Received: from sonussf1.sonusnet.com ([208.45.178.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUSTr-0002nQ-M0 for megaco@ietf.org; Tue, 25 Oct 2005 13:21:01 -0400 Received: from sonusmail03.sonusnet.com (sonusmail03.sonusnet.com [10.128.32.97]) by sonussf1.sonusnet.com (8.13.3/8.13.3) with ESMTP id j9PH7KRl019054 for ; Tue, 25 Oct 2005 13:07:20 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 25 Oct 2005 13:07:19 -0400 Message-ID: Thread-Topic: Question about Descriptors in an Add Command Thread-Index: AcXZho7C9Q/n58G5R+KciDgb2E/73Q== From: "Leonelli, Greg" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: d008c19e97860b8641c1851f84665a75 Subject: [Megaco] Question about Descriptors in an Add Command 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="===============2005275555==" Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org This is a multi-part message in MIME format. --===============2005275555== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5D986.8EC64C63" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5D986.8EC64C63 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 =20 Section 7.2.1 Add contains the text: =20 " All descriptors that can be modified could be returned by MG if a parameter was underspecified or overspecified. ObservedEvents, Statistics, and Packages, and the EventBuffer descriptors are returned only if requested in the AuditDescriptor. " =20 The last sentence implies that the following list of descriptors could=20 be included in the response if that same descriptor was included=20 in the request with a parameter that was underspecified or = overspecified: EventsDescriptor SignalsDescriptor DigitMapDescriptor =20 For the EventsDescriptor I believe "underspecified" would imply the=20 "all events" wildcard. What is less clear are instances of = underspecified=20 or overspecified in the following cases: =20 Descriptor underspecified overspecified Events all wildcard ? Signals all wildcard(??) ? DigitMap ? ? =20 We would appreciate some specific examples of the entries with "?". =20 In particular, are there any instances where the DigitMapDescriptor is = required=20 in the response without it having been requested in an audit descriptor? =20 Greg ------_=_NextPart_001_01C5D986.8EC64C63 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
 
  Section 7.2.1 Add contains the=20 text:
 
" All descriptors that can be modified = could be=20 returned by MG if a
   parameter was underspecified or=20 overspecified.  ObservedEvents,
   Statistics, and = Packages,=20 and the EventBuffer descriptors are
   returned only if = requested=20 in the AuditDescriptor.=20 "
 
The last sentence implies that the following = list of=20 descriptors could
be included in the response if that same = descriptor was=20 included
in the = request with=20 a parameter that was = underspecified=20 or overspecified:
    =20 EventsDescriptor
    =20 SignalsDescriptor
    =20 DigitMapDescriptor
 
For the=20 EventsDescriptor I believe "underspecified" would imply the
"all events"=20 wildcard.   What is=20 less clear are = instances of=20 underspecified
or overspecified in the following=20 cases:
 
Descriptor      =  =20 underspecified          = ;=20 overspecified
Events      &nbs= p;        =20 all=20 wildcard           = ;    =20 ?
Signals         = ;     =20 all=20 wildcard(??)          &= nbsp;?
DigitMap      &n= bsp;   =20      =20 ?            =              = ?
 
We would appreciate some specific = examples of the=20 entries with "?".
 
In particular, are there any instances where = the=20 DigitMapDescriptor is required
in the response without it = having been=20 requested in an audit=20 descriptor?
 
Greg
------_=_NextPart_001_01C5D986.8EC64C63-- --===============2005275555== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============2005275555==-- From megaco-bounces@ietf.org Wed Oct 26 02:37:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUeuk-0000Vy-NS; Wed, 26 Oct 2005 02:37:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUeuh-0000OS-MQ for megaco@megatron.ietf.org; Wed, 26 Oct 2005 02:37:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26775 for ; Wed, 26 Oct 2005 02:37:16 -0400 (EDT) From: Albrecht.Schwarz@alcatel.de Received: from mailrelay2.alcatel.de ([194.113.59.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUf7n-0005UL-9W for megaco@ietf.org; Wed, 26 Oct 2005 02:51:04 -0400 Received: from demail05.netfr.alcatel.fr (demail05.netfr.alcatel.fr [155.132.182.205]) by mailrelay2.alcatel.de (8.12.10/8.12.10/ICT TSC MAIL 2005) with ESMTP id j9Q6bBDO024562; Wed, 26 Oct 2005 08:37:11 +0200 In-Reply-To: To: "Christer Holmberg (JO/LMF)" X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: Date: Wed, 26 Oct 2005 08:37:10 +0200 X-MIMETrack: Serialize by Router on DEMAIL05/DE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 10/26/2005 08:37:10 MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.49 on 149.204.45.73 X-Spam-Score: 1.4 (+) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: TISPAN_WG3@LIST.ETSI.ORG, megaco@ietf.org Subject: [Megaco] Re: updated - H.248 Termination ID Structure Enhancement 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="===============1741861490==" Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org --===============1741861490== Content-type: text/plain; charset=big5 Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 DQpJIHRoaW5rIHRoYXQgdGhlcmUgbWlnaHQgYmUgZ3VpZGFuY2UgKG9yIGV2ZW4gaGlnaC1sZXZl bCBhbGlnbm1lbnQpIHdpdGgNCnRoZSAiSVAgUmVhbG0gSWRlbnRpZmllciIgcHJvcGVydHkgb2Yg ZHJhZnQgSC4yNDguSVBEQyBQYWNrYWdlLCBiZWNhdXNlDQpib3RoIGhhdmUgYWN0dWFsbHkgdGhl IHNhbWUgcHVycG9zZS4NCg0KUHJvcGVydHkgaXBkYy9yZWFsbSBpcyBvZiB0eXBlIFNUUklORywg c28gZmFyIG5vdCBsaW1pdGVkICgiYWxzbyBiZWNhdXNlDQpub3QgcmVhbGx5IGRpc2N1c3NlZCB5 ZXQiKS4NCg0KVGhlcmVmb3JlIEknbSB0ZW5kaW5nIHRvIHRoZSAibWF4IDUxIiBvcHRpb24uDQoN CkFsYnJlY2h0DQoNCg0KDQoNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAg ICAgICAgICAgICAgICJDaHJpc3RlciBIb2xtYmVyZyAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAgIChKTy9MTUYpIiAgICAgICAg ICAgICAgICAgICAgIFRvOiAgICAgIFRJU1BBTl9XRzNATElTVC5FVFNJLk9SRyAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAg ICAgICAgICAgIDxjaHJpc3Rlci5ob2xtYmVyZ0BFUiAgICAgICAgIGNjOiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAgIElDU1NPTi5DT00+ICAgICAgICAg ICAgICAgICAgIFN1YmplY3Q6IFJlOiB1cGRhdGVkIC0gSC4yNDggIFRlcm1pbmF0aW9uIElEIFN0 cnVjdHVyZSBFbmhhbmNlbWVudCAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAgIDI1LjEwLjIwMDUgMTg6NDkgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAg ICAgIFBsZWFzZSByZXNwb25kIHRvICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAgICJDaHJpc3RlciBIb2xtYmVyZyAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAg IChKTy9MTUYpIiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNCg0KDQpDYW4gSSBoZWFyIHNvbWUg dm90ZXMgZm9yIHdoaWNoIG9wdGlvbiB0byBjaG9vc2U/IDopDQoNClJlZ2FyZHMsDQoNCkNocmlz dGVyDQogLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCiBGcm9tOiBBbm5pZSBCZW5pdGV6IFBl bGFleiBbbWFpbHRvOkFCZW5pdGV6QGFjbWVwYWNrZXQuY29tXQ0KIFNlbnQ6IDI0LiBsb2tha3V1 dGEgMjAwNSAxNTowNg0KIFRvOiBUSVNQQU5fV0czQExJU1QuRVRTSS5PUkc7IENocmlzdGVyIEhv bG1iZXJnIChKTy9MTUYpDQogU3ViamVjdDogdXBkYXRlZCAtIEguMjQ4IFRlcm1pbmF0aW9uIElE IFN0cnVjdHVyZSBFbmhhbmNlbWVudA0KDQogSGVsbG8hIEF0dGFjaGVkIGlzIGFuIHVwZGF0ZSBv ZiBwcm9wb3NhbDogoacwOGJURDEyNXIxOiBILjI0OCAgVGVybWluYXRpb24NCiBJRCBTdHJ1Y3R1 cmUgRW5oYW5jZW1lbnShqCBiYXNlZCBvbiB0aGlzIG1vcm5pbmdzICCDe0lhIFByb2ZpbGUgIGRp c2N1c3Npb24uDQogVGhlcmUgYXJlIDMgbGVuZ3RoIHByb3Bvc2FscyBwcmVzZW50ZWQsIHBsZWFz ZSBwcm92aWRlIGZlZWRiYWNrIG9uIHRoZQ0KIHByZWZlcnJlZCBhcHByb2FjaC4NCg0KIEJlc3Qg UmVnYXJkcywNCiBBbm5pZQ0KDQogQW5uaWUgQmVuaXRleiBQZWxhZXoNCiBQcm9kdWN0IE1hbmFn ZW1lbnQgLSBBY21lIFBhY2tldA0KIFQ6ICsxICg3ODEpIDMyOCA0MzkyDQogTTogKzEgKDg1Nykg MjIyIDM3MzgNCiBhYmVuaXRlekBhY21lcGFja2V0LmNvbQ0KDQoNCg== --===============1741861490== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============1741861490==-- From megaco-bounces@ietf.org Mon Oct 31 10:59:17 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWc45-0005PX-08; Mon, 31 Oct 2005 10:59:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWc42-0005Ok-W5 for megaco@megatron.ietf.org; Mon, 31 Oct 2005 10:59:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15774 for ; Mon, 31 Oct 2005 10:58:54 -0500 (EST) Received: from mail.siemenscom.com ([12.146.131.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWcIE-0001jB-ES for megaco@ietf.org; Mon, 31 Oct 2005 11:13:56 -0500 Received: from fdns2.rolm.com (imail2.icn.siemens.com [165.218.1.59]) by mail.siemenscom.com (8.13.4/8.13.4) with ESMTP id j9VFxeLa017099 for ; Mon, 31 Oct 2005 07:59:40 -0800 (PST) Received: from stca200a.bus.sc.rolm.com (stca200a.bus.sc.rolm.com [165.218.68.180]) by fdns2.rolm.com (8.12.10/8.12.10) with ESMTP id j9VFx4Q4016205 for ; Mon, 31 Oct 2005 07:59:04 -0800 (PST) Received: by stca200a.bus.sc.rolm.com with Internet Mail Service (5.5.2657.72) id ; Mon, 31 Oct 2005 07:59:04 -0800 Message-ID: From: "Wainwright, John" To: megaco@ietf.org Date: Mon, 31 Oct 2005 07:58:58 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [Megaco] Socket set-up. 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 Does anyone have any suggestions / recommendations on the setting up of sockets as related to a typical call flow ? What I mean is at what point in the NOTIFY/ ADD/ MODIFY sequence etc should the sockets on the origination & destination side be created. E.g. should an originating side create a socket as soon as the initial ADD message is being processed for a new call set up or should it wait until it receives SDP details from the terminating end ? Thanks John _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Mon Oct 31 14:07:08 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWezr-0004Ix-VW; Mon, 31 Oct 2005 14:07:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWezp-0004IK-M5 for megaco@megatron.ietf.org; Mon, 31 Oct 2005 14:07:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29992 for ; Mon, 31 Oct 2005 14:06:46 -0500 (EST) Received: from defender.ccpu.com ([216.54.134.34] helo=smtp.ccpu.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWfE1-000896-Dc for megaco@ietf.org; Mon, 31 Oct 2005 14:21:48 -0500 Received: from sd-exchange.ccsd.ccpu.com (sd-exchange.ccpu.com [172.16.0.203]) by smtp.ccpu.com (Postfix) with ESMTP id D7FA43469CB; Mon, 31 Oct 2005 11:06:50 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Megaco] Query on ASN grammer Date: Mon, 31 Oct 2005 11:06:49 -0800 Message-ID: Thread-Topic: [Megaco] Query on ASN grammer Thread-Index: AcXQjpRSgGjwmHUtQ0+M/hf5tWhmBwNvroEg From: "Rashim Anand" To: "Christian Groves" X-Spam-Score: 0.2 (/) X-Scan-Signature: ae94eee30e48a465014d0c9cbb0ac2ba 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: , Content-Type: multipart/mixed; boundary="===============1997657179==" Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org This is a multi-part message in MIME format. --===============1997657179== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5DE4E.3EC94C84" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5DE4E.3EC94C84 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I have a doubt wrt encoding of descriptors in AmmRequest. If the descriptors in AmmRequest are absent, then how would the message be binary encoded - * Would the tag for AmmRequest be present along with length =3D 0 to indicate the absence of the descriptors. * OR would the tag for AmmRequest be absent altogether to indicate the absence of the descriptors? What exactly is meant by a NULL sequence? Does this mean a "sequence of" tag along with length =3D 0? Regards, -Rashim Anand -----Original Message----- From: Christian Groves [mailto:cngroves@bigpond.net.au]=20 Sent: Friday, October 14, 2005 12:12 AM To: Rashim Anand Cc: Deepak Pokharna; megaco@ietf.org Subject: Re: [Megaco] Query on ASN grammer Hello Rashim, I not sure that we can just retrospectively had optionals to the ASN.1.=20 My understanding is that this would not be backwards compatible. Christian Rashim Anand wrote: >Hi Christian, > >I think that for consistency and clarity purposes "OPTIONAL" should be=20 >specified. There are other examples of using "OPTIONAL" in SEQUENCE OF=20 >s which are optional in the spec. One such example is - > >ContextRequest ::=3D=3D SEQUENCE >{ > priority INTEGER(0..15) OPTIONAL, > emergency BOOLEAN OPTIONAL, > topologyReq SEQUENCE OF TopologyRequest OPTIONAL, > ... >} > >This will prevent some confusion. >-Rashim Anand > > > > >-----Original Message----- >From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On=20 >Behalf Of Christian Groves >Sent: Thursday, October 13, 2005 8:06 PM >To: Deepak Pokharna >Cc: megaco@ietf.org >Subject: Re: [Megaco] Query on ASN grammer > > >Hello Depak, > >I'm not sure what the problem is. AmmRequest contains a "SEQUENCE OF" >descriptors. The note simply says that you shouldn't have 2 or more of=20 >the same descriptors per command. My understanding is that a sequence of > >could be a null sequence. > >Christian > >Deepak Pokharna wrote: > > =20 > >>Hi >> >> According to V2 Draft (ASN Grammar) it says at most one=20 >>descriptor is required in list of descriptor in AmmRequest..But it has >> =20 >> > > =20 > >>not made the descriptors as optional too so it means one Descriptor >>should be there in Add, Move and Mod Request. Here it has difference=20 >>from ABNF grammar which have made the list of descriptor as optional.=20 >>Can some one clarify this. >> >>=20 >> >> Command ::=3D CHOICE >> >> { >> >> addReq AmmRequest, >> >> moveReq AmmRequest, >> >> modReq AmmRequest, >> >> -- Add, Move, Modify requests have the same parameters >> >> subtractReq SubtractRequest, >> >> auditCapRequest AuditRequest, >> >> auditValueRequest AuditRequest, >> >> notifyReq NotifyRequest, >> >> serviceChangeReq ServiceChangeRequest, >> >> ... >> >> } >> >> =20 >> >> =20 >> >> AmmRequest ::=3D SEQUENCE >> >> { >> >> terminationID TerminationIDList, >> >> */descriptors SEQUENCE OF AmmDescriptor/*, >> >>* -- At most one descriptor of each type (see AmmDescriptor) * >> >>* -- allowed in the sequence. * >> >>* ... * >> >> =20 >> >> =20 >> >> Groves et al Expires - October 2003 [Page >> =20 >> >103] > =20 > >> Megaco Protocol version 2 April >> =20 >> >2003 > =20 > >> =20 >> >> =20 >> >> } >> >> =20 >> >> AmmDescriptor ::=3D CHOICE >> >> { >> >> mediaDescriptor MediaDescriptor, >> >> modemDescriptor ModemDescriptor, >> >> muxDescriptor MuxDescriptor, >> >> eventsDescriptor EventsDescriptor, >> >> eventBufferDescriptor EventBufferDescriptor, >> >> signalsDescriptor SignalsDescriptor, >> >> digitMapDescriptor DigitMapDescriptor, >> >> auditDescriptor AuditDescriptor, >> >> ... >> >> } >> >>=20 >> >>Regards >> >>Deepak >> >>=20 >> >>---------------------------------------------------------------------- >>- >>- >> >>_______________________________________________ >>Megaco mailing list >>Megaco@ietf.org >>https://www1.ietf.org/mailman/listinfo/megaco >>=20 >> >> =20 >> > > > >_______________________________________________ >Megaco mailing list >Megaco@ietf.org >https://www1.ietf.org/mailman/listinfo/megaco > > > =20 > ------_=_NextPart_001_01C5DE4E.3EC94C84 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [Megaco] Query on ASN grammer

Hi,

I have a doubt wrt = encoding of descriptors in AmmRequest. If the descriptors in AmmRequest are absent, then how = would the message be binary encoded -

  • Would the tag for = AmmRequest be present along with length =3D 0 to indicate the absence of = the descriptors.
  • OR would the tag = for AmmRequest be absent altogether to indicate the absence of the = descriptors?

What exactly is = meant by a NULL sequence? Does this mean a "sequence of" tag = along with length =3D 0?

Regards,
-Rashim = Anand



-----Original = Message-----
From: Christian = Groves [mailto:cngroves@bigpond.net.au]
Sent: Friday, = October 14, 2005 12:12 AM
To: Rashim = Anand
Cc: Deepak = Pokharna; megaco@ietf.org
Subject: Re: = [Megaco] Query on ASN grammer


Hello = Rashim,

I not sure that we = can just retrospectively had optionals to the ASN.1.
My understanding = is that this would not be backwards compatible.

Christian

Rashim Anand = wrote:

>Hi = Christian,
>
>I think that = for consistency and clarity purposes "OPTIONAL" should be =
>specified. = There are other examples of using "OPTIONAL" in SEQUENCE OF =
>s which are = optional in the spec. One such example is -
>
>ContextRequest ::=3D=3D SEQUENCE
>{
>   = priority       INTEGER(0..15) = OPTIONAL,
>   = emergency      BOOLEAN OPTIONAL,
>   = topologyReq    SEQUENCE OF TopologyRequest = OPTIONAL,
>   = ...
>}
>
>This will = prevent some confusion.
>-Rashim = Anand
>
>
>
>
>-----Original = Message-----
>From: = megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On
>Behalf Of = Christian Groves
>Sent: = Thursday, October 13, 2005 8:06 PM
>To: Deepak = Pokharna
>Cc: = megaco@ietf.org
>Subject: Re: = [Megaco] Query on ASN grammer
>
>
>Hello = Depak,
>
>I'm not sure = what the problem is. AmmRequest contains a "SEQUENCE = OF"
>descriptors. = The note simply says that you shouldn't have 2 or more of
>the same = descriptors per command. My understanding is that a sequence = of
>
>could be a = null sequence.
>
>Christian
>
>Deepak = Pokharna wrote:
>
>  =
>
>>Hi
>>
>>     According to V2 Draft = (ASN Grammar) it says at most one
>>descriptor is required in list of descriptor in = AmmRequest..But it has
>>   
>>
>
>  =
>
>>not made = the descriptors as optional too so it means one Descriptor
>>should be = there in Add, Move and Mod Request. Here it has difference =
>>from ABNF = grammar which have made the list of descriptor as optional. =
>>Can some = one clarify this.
>>
>> =
>>
>>      Command ::=3D = CHOICE
>>
>>      {
>>
>>         = addReq           &= nbsp;   AmmRequest,
>>
>>         = moveReq           =    AmmRequest,
>>
>>         = modReq           &= nbsp;   AmmRequest,
>>
>>         = -- Add, Move, Modify requests have the same parameters
>>
>>         = subtractReq          = SubtractRequest,
>>
>>         = auditCapRequest      = AuditRequest,
>>
>>         = auditValueRequest    AuditRequest,
>>
>>         = notifyReq          &nbs= p; NotifyRequest,
>>
>>         = serviceChangeReq     = ServiceChangeRequest,
>>
>>         = ...
>>
>>      }
>>
>>     
>>
>>     
>>
>>      AmmRequest ::=3D = SEQUENCE
>>
>>      {
>>
>>         = terminationID        = TerminationIDList,
>>
>>         = */descriptors          = SEQUENCE OF AmmDescriptor/*,
>>
>>*         = -- At most one descriptor of each type (see AmmDescriptor) = *
>>
>>*         = -- allowed in the sequence. *
>>
>>*         = ... *
>>
>>  
>>
>>  
>>
>>   Groves et = al            = Expires - October = 2003           &nb= sp;  [Page
>>   
>>
>103]
>  =
>
>>        &n= bsp;           &nb= sp;    Megaco Protocol version = 2            = April
>>   
>>
>2003
>  =
>
>>  
>>
>>  
>>
>>      }
>>
>>     
>>
>>      AmmDescriptor = ::=3D CHOICE
>>
>>      {
>>
>>         = mediaDescriptor         = MediaDescriptor,
>>
>>         = modemDescriptor         = ModemDescriptor,
>>
>>         = muxDescriptor          = MuxDescriptor,
>>
>>         = eventsDescriptor        = EventsDescriptor,
>>
>>         = eventBufferDescriptor   EventBufferDescriptor,
>>
>>         = signalsDescriptor       = SignalsDescriptor,
>>
>>         = digitMapDescriptor      = DigitMapDescriptor,
>>
>>         = auditDescriptor         = AuditDescriptor,
>>
>>         = ...
>>
>>      }
>>
>> =
>>
>>Regards
>>
>>Deepak
>>
>> =
>>
>>--------------------------------------------------= --------------------
>>-
>>-
>>
>>_______________________________________________
>>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_01C5DE4E.3EC94C84-- --===============1997657179== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============1997657179==--