From Raphael.Tryster@Teledata-Networks.com Tue Jun 15 00:26:25 2010 Return-Path: X-Original-To: megaco@core3.amsl.com Delivered-To: megaco@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE3FA3A692D for ; Tue, 15 Jun 2010 00:26:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.965 X-Spam-Level: *** X-Spam-Status: No, score=3.965 tagged_above=-999 required=5 tests=[BAYES_80=2, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, J_CHICKENPOX_65=0.6, SARE_RECV_BEZEQINT_B=0.763, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4wfGXWw7yPOB for ; Tue, 15 Jun 2010 00:26:24 -0700 (PDT) Received: from teledata-networks.com (mail.teledata-networks.com [81.218.12.242]) by core3.amsl.com (Postfix) with ESMTP id 2CB7B3A686E for ; Tue, 15 Jun 2010 00:26:23 -0700 (PDT) Received: from Internal Mail-Server by Mail-SeCure (envelope-from Raphael.Tryster@Teledata-Networks.com) with SMTP; 15 Jun 2010 10:13:30 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB0C5C.1B7AA056" Date: Tue, 15 Jun 2010 10:26:44 +0300 Message-ID: In-Reply-To: <4BB2C3BE.2020701@nteczone.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Does an event generated by strict=state stop signals? Thread-Index: AcrQg7fsw39/KugQRvWxdLzk/K/qGw71n9+w From: "Raphael Tryster" To: "megaco ietf" Subject: [Megaco] Does an event generated by strict=state stop signals? X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2010 07:26:25 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB0C5C.1B7AA056 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Megaco stipulates that detection of an event should stop any signal that is playing. Does an existing hook state, reported immediately with init=3Dtrue because the MGC requested strict=3Dstate, count as an event = for the purpose of stopping signals? =20 If the answer is yes, then we could have the following scenario: =20 1. MG sends Notify al/of. 2. MGC sends Modify, requesting signal cg/dt, and events al/of{strict=3Dstate},al/on(strict=3Dstate}. 3. MG immediately sends Notify al/of{init=3Dtrue}, and stops the dial tone! =20 A variation of the above is when the strict parameter is omitted, but the MG decides to assume strict=3Dstate because it is working with = Megaco version 1 or 2, where no default is specified. =20 Possible conclusions: =20 1. This is not a real event and the signal should not be stopped. 2. This is a real event and the MGC is stupid to send such a command. 3. This is a real event, and if strict is not specified, the MG must assume strict=3Dexact. =20 I await the experts' opinion. =20 Raphael Tryster ------_=_NextPart_001_01CB0C5C.1B7AA056 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Megaco stipulates that detection of an event should stop any signal that is = playing.  Does an existing hook state, reported immediately with init=3Dtrue because = the MGC requested strict=3Dstate, count as an event for the purpose of stopping = signals?

 

If the answer is yes, then we could have = the following scenario:

 

1.       = MG sends Notify al/of.

2.       = MGC sends Modify, requesting signal cg/dt, and events al/of{strict=3Dstate},al/on(strict=3Dstate}.

3.       = MG immediately sends Notify al/of{init=3Dtrue}, and stops the dial = tone!

 

A variation of the above is when the = strict parameter is omitted, but the MG decides to assume strict=3Dstate = because it is working with Megaco version 1 or 2, where no default is = specified.

 

Possible = conclusions:

 

1.       = This is not a real event and the signal should not be = stopped.

2.       = This is a real event and the MGC is stupid to send such a = command.

3.       = This is a real event, and if strict is not specified, the MG must assume = strict=3Dexact.

 

I await the experts' = opinion.

 

Raphael = Tryster

------_=_NextPart_001_01CB0C5C.1B7AA056-- From tom111.taylor@bell.net Tue Jun 15 05:24:28 2010 Return-Path: X-Original-To: megaco@core3.amsl.com Delivered-To: megaco@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 883743A6A63 for ; Tue, 15 Jun 2010 05:24:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.004 X-Spam-Level: ** X-Spam-Status: No, score=2.004 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_44=0.6, J_CHICKENPOX_65=0.6, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tZJQ7MKRjJ6f for ; Tue, 15 Jun 2010 05:24:23 -0700 (PDT) Received: from blu0-omc2-s31.blu0.hotmail.com (blu0-omc2-s31.blu0.hotmail.com [65.55.111.106]) by core3.amsl.com (Postfix) with ESMTP id DAAFD3A6A4C for ; Tue, 15 Jun 2010 05:24:22 -0700 (PDT) Received: from BLU0-SMTP33 ([65.55.111.71]) by blu0-omc2-s31.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Jun 2010 05:24:27 -0700 X-Originating-IP: [174.94.9.71] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.11] ([174.94.9.71]) by BLU0-SMTP33.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Jun 2010 05:24:26 -0700 Date: Tue, 15 Jun 2010 08:24:23 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Raphael Tryster References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Jun 2010 12:24:27.0097 (UTC) FILETIME=[B240DC90:01CB0C85] Cc: megaco ietf Subject: Re: [Megaco] Does an event generated by strict=state stop signals? X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2010 12:24:28 -0000 I go for interpretation 2. Raphael Tryster wrote: > Megaco stipulates that detection of an event should stop any signal that > is playing. Does an existing hook state, reported immediately with > init=true because the MGC requested strict=state, count as an event for > the purpose of stopping signals? > > > > If the answer is yes, then we could have the following scenario: > > > > 1. MG sends Notify al/of. > > 2. MGC sends Modify, requesting signal cg/dt, and events > al/of{strict=state},al/on(strict=state}. > > 3. MG immediately sends Notify al/of{init=true}, and stops the > dial tone! > > > > A variation of the above is when the strict parameter is omitted, but > the MG decides to assume strict=state because it is working with Megaco > version 1 or 2, where no default is specified. > > > > Possible conclusions: > > > > 1. This is not a real event and the signal should not be stopped. > > 2. This is a real event and the MGC is stupid to send such a > command. > > 3. This is a real event, and if strict is not specified, the MG > must assume strict=exact. > > > > I await the experts' opinion. > > > > Raphael Tryster > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www.ietf.org/mailman/listinfo/megaco From Christian.Groves@nteczone.com Tue Jun 15 16:55:51 2010 Return-Path: X-Original-To: megaco@core3.amsl.com Delivered-To: megaco@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C4163A69F3 for ; Tue, 15 Jun 2010 16:55:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.201 X-Spam-Level: * X-Spam-Status: No, score=1.201 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_44=0.6, J_CHICKENPOX_65=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OSXPNGsGDaXq for ; Tue, 15 Jun 2010 16:55:50 -0700 (PDT) Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [150.101.137.131]) by core3.amsl.com (Postfix) with ESMTP id 238713A68E3 for ; Tue, 15 Jun 2010 16:55:49 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApEBAHevF0x20V+m/2dsb2JhbAAH4RGFGgQ Received: from ppp118-209-95-166.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.95.166]) by ipmail07.adl2.internode.on.net with ESMTP; 16 Jun 2010 09:25:53 +0930 Message-ID: <4C18132A.3000403@nteczone.com> Date: Wed, 16 Jun 2010 09:56:26 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Raphael Tryster References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: megaco ietf Subject: Re: [Megaco] Does an event generated by strict=state stop signals? X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2010 23:55:51 -0000 Hello Raphael, I think it is a real event so the behaviour would be to send the notify and stop the dial tone. So I think conclusion 2 is the one to take. However I think conclusion 3 is also applicable. Megaco v1, v2, or v3 really is only for the syntax and procedures surrounding that. In the case of the Analog Line Supervision Package (al) the package version has remained at v1 for all Megaco versions. Therefore the inclusion of the default should be seen as correcting an omission. So the MG should assume strict=exact if strict is not specified (unless provisioned otherwise :-) ). Regards, Christian On 15/06/2010 5:26 PM, Raphael Tryster wrote: > > Megaco stipulates that detection of an event should stop any signal > that is playing. Does an existing hook state, reported immediately > with init=true because the MGC requested strict=state, count as an > event for the purpose of stopping signals? > > If the answer is yes, then we could have the following scenario: > > 1. MG sends Notify al/of. > > 2. MGC sends Modify, requesting signal cg/dt, and events > al/of{strict=state},al/on(strict=state}. > > 3. MG immediately sends Notify al/of{init=true}, and stops the dial tone! > > A variation of the above is when the strict parameter is omitted, but > the MG decides to assume strict=state because it is working with > Megaco version 1 or 2, where no default is specified. > > Possible conclusions: > > 1. This is not a real event and the signal should not be stopped. > > 2. This is a real event and the MGC is stupid to send such a command. > > 3. This is a real event, and if strict is not specified, the MG must > assume strict=exact. > > I await the experts' opinion. > > Raphael Tryster > > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www.ietf.org/mailman/listinfo/megaco > From tomas.kukosa@siemens-enterprise.com Thu Jun 17 01:59:22 2010 Return-Path: X-Original-To: megaco@core3.amsl.com Delivered-To: megaco@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B9B33A6A7D for ; Thu, 17 Jun 2010 01:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xG4bz5DvEXQ8 for ; Thu, 17 Jun 2010 01:59:21 -0700 (PDT) Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 764F23A6A2D for ; Thu, 17 Jun 2010 01:59:21 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-539986 for megaco@ietf.org; Thu, 17 Jun 2010 10:59:25 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 87ADE23F028E for ; Thu, 17 Jun 2010 10:59:25 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Thu, 17 Jun 2010 10:59:25 +0200 From: "Kukosa, Tomas" To: "megaco@ietf.org" Date: Thu, 17 Jun 2010 10:59:24 +0200 Thread-Topic: H.248 using RFC2833/RFC2198 and SRTP/MIKEY Thread-Index: AcsN+2ImUyvLT7aRRHSP28mzopKsEQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Megaco] H.248 using RFC2833/RFC2198 and SRTP/MIKEY X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2010 08:59:22 -0000 Hello, I start looking to H.248 protocol and studying what it can do and what can'= t. I am not able to find any documents related to following topics/questions: 1) RFC2833/RFC2198 - how the MGC can get RFC2833/RFC2198 capabilities from the MG? (used pay= load types, list of supported tones, ...) - how the MGC can put peer RFC2833/RFC2198 capabilities to the MG termin= ation? 2) SRTP/MIKEY - is there any document how to use MIKEY within H.248 to negotiate SRTP co= ntexted between the MG and peer media endpoint ?(can be also H.248 MG but a= lso any other kind of SRTP endpoint) BTW I would prefer to use binary encoding of H.248 and if I understand it w= ell it can not use SDP equivalent properties, is it right? Thanks in advance for any hint. Best regards, Tomas= From Raphael.Tryster@Teledata-Networks.com Thu Jun 17 02:17:55 2010 Return-Path: X-Original-To: megaco@core3.amsl.com Delivered-To: megaco@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 378C33A6A99 for ; Thu, 17 Jun 2010 02:17:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.965 X-Spam-Level: ** X-Spam-Status: No, score=2.965 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_50=0.001, J_CHICKENPOX_44=0.6, J_CHICKENPOX_65=0.6, SARE_RECV_BEZEQINT_B=0.763, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t+O3aMY4Xu7Z for ; Thu, 17 Jun 2010 02:17:53 -0700 (PDT) Received: from teledata-networks.com (mail.teledata-networks.com [81.218.12.242]) by core3.amsl.com (Postfix) with ESMTP id 88B313A67B1 for ; Thu, 17 Jun 2010 02:17:51 -0700 (PDT) Received: from Internal Mail-Server by Mail-SeCure (envelope-from Raphael.Tryster@Teledata-Networks.com) with SMTP; 17 Jun 2010 12:04:33 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 17 Jun 2010 12:18:15 +0300 Message-ID: In-Reply-To: <4C18132A.3000403@nteczone.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Megaco] Does an event generated by strict=state stop signals? Thread-Index: AcsM5lzcDqKDz+YyRiOan8vch0il8wBFx2Lg From: "Raphael Tryster" To: "Christian Groves" Cc: megaco ietf Subject: Re: [Megaco] Does an event generated by strict=state stop signals? X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2010 09:17:55 -0000 Thank you, Tom and Christian, for your replies. The actual case that prompted my question was one in which conclusion 3 applies. As you said, "unless provisioned otherwise" is very relevant, as we have had interoperations in which it is necessary to assume a default of strict=3Dstate. Regards, Raphael -----Original Message----- From: Christian Groves [mailto:Christian.Groves@nteczone.com]=20 Sent: Wednesday, 16 June 2010 2:56 AM To: Raphael Tryster Cc: megaco ietf Subject: Re: [Megaco] Does an event generated by strict=3Dstate stop signals? Hello Raphael, I think it is a real event so the behaviour would be to send the notify=20 and stop the dial tone. So I think conclusion 2 is the one to take.=20 However I think conclusion 3 is also applicable. Megaco v1, v2, or v3=20 really is only for the syntax and procedures surrounding that. In the=20 case of the Analog Line Supervision Package (al) the package version has remained at v1 for all Megaco versions. Therefore the inclusion of the=20 default should be seen as correcting an omission. So the MG should=20 assume strict=3Dexact if strict is not specified (unless provisioned=20 otherwise :-) ). Regards, Christian On 15/06/2010 5:26 PM, Raphael Tryster wrote: > > Megaco stipulates that detection of an event should stop any signal=20 > that is playing. Does an existing hook state, reported immediately=20 > with init=3Dtrue because the MGC requested strict=3Dstate, count as an = > event for the purpose of stopping signals? > > If the answer is yes, then we could have the following scenario: > > 1. MG sends Notify al/of. > > 2. MGC sends Modify, requesting signal cg/dt, and events=20 > al/of{strict=3Dstate},al/on(strict=3Dstate}. > > 3. MG immediately sends Notify al/of{init=3Dtrue}, and stops the dial tone! > > A variation of the above is when the strict parameter is omitted, but=20 > the MG decides to assume strict=3Dstate because it is working with=20 > Megaco version 1 or 2, where no default is specified. > > Possible conclusions: > > 1. This is not a real event and the signal should not be stopped. > > 2. This is a real event and the MGC is stupid to send such a command. > > 3. This is a real event, and if strict is not specified, the MG must=20 > assume strict=3Dexact. > > I await the experts' opinion. > > Raphael Tryster > > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www.ietf.org/mailman/listinfo/megaco > =20 From Albrecht.Schwarz@alcatel-lucent.com Thu Jun 17 05:02:07 2010 Return-Path: X-Original-To: megaco@core3.amsl.com Delivered-To: megaco@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 528A73A6857 for ; Thu, 17 Jun 2010 05:02:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.902 X-Spam-Level: X-Spam-Status: No, score=-0.902 tagged_above=-999 required=5 tests=[AWL=3.488, BAYES_20=-0.74, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bNiF4fEpWV3w for ; Thu, 17 Jun 2010 05:02:06 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id 1CF7F3A688B for ; Thu, 17 Jun 2010 05:02:05 -0700 (PDT) Received: from FRVELSBHS02.ad2.ad.alcatel.com (frvelsbhs02.dc-m.alcatel-lucent.com [155.132.6.74]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o5HC216o005527; Thu, 17 Jun 2010 14:02:07 +0200 Received: from FRVELSMBS23.ad2.ad.alcatel.com ([155.132.6.51]) by FRVELSBHS02.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 17 Jun 2010 14:02:03 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 17 Jun 2010 14:02:02 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Megaco] H.248 using RFC2833/RFC2198 and SRTP/MIKEY Thread-Index: AcsN+2ImUyvLT7aRRHSP28mzopKsEQAF0s0g References: From: "Schwarz Albrecht" To: "Kukosa, Tomas" , X-OriginalArrivalTime: 17 Jun 2010 12:02:03.0371 (UTC) FILETIME=[E6280BB0:01CB0E14] X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Subject: Re: [Megaco] H.248 using RFC2833/RFC2198 and SRTP/MIKEY X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2010 12:02:07 -0000 to 1): - RFC2833 is obsoleted by RFC 4733, ...!=20 - just use the SDP elements as defined by the RFCs in the H.248 LD/RD - it looks fairly strange to use H.248 binary encoding when such SDP-controlled RTP capabilities are used in the IP domain; do you really want to translate SDP text encoding at your MGC call control interface in "SDP binary" format at H.248? to 2): - see Draft H.248.77 for H.248-controlled SRTP endpoints - see 3GPP 23.334 and 29.334 as a first H.248 Profile with SRTP support > negotiate SRTP contexted between the MG and peer media=20 > endpoint ?(can be also H.248 MG but also any other kind of=20 You refer to the IP media-path (RFC 5479) related keying methods for SRTP. Any procedures at the H.248 MG "IP media-path" interface are per se out of scope of H.248. If ... then subject of an H.248 profile specification. > -----Original Message----- > From: megaco-bounces@ietf.org=20 > [mailto:megaco-bounces@ietf.org] On Behalf Of Kukosa, Tomas > Sent: Donnerstag, 17. Juni 2010 10:59 > To: megaco@ietf.org > Subject: [Megaco] H.248 using RFC2833/RFC2198 and SRTP/MIKEY >=20 > Hello, >=20 > I start looking to H.248 protocol and studying what it can do=20 > and what can't. >=20 > I am not able to find any documents related to following=20 > topics/questions: >=20 > 1) RFC2833/RFC2198 > - how the MGC can get RFC2833/RFC2198 capabilities from the=20 > MG? (used payload types, list of supported tones, ...) > - how the MGC can put peer RFC2833/RFC2198 capabilities to=20 > the MG termination? >=20 > 2) SRTP/MIKEY > - is there any document how to use MIKEY within H.248 to=20 > negotiate SRTP contexted between the MG and peer media=20 > endpoint ?(can be also H.248 MG but also any other kind of=20 > SRTP endpoint) >=20 > BTW I would prefer to use binary encoding of H.248 and if I=20 > understand it well it can not use SDP equivalent properties,=20 > is it right? >=20 > Thanks in advance for any hint. >=20 > Best regards, > Tomas > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www.ietf.org/mailman/listinfo/megaco >=20 From tomas.kukosa@siemens-enterprise.com Fri Jun 18 00:30:28 2010 Return-Path: X-Original-To: megaco@core3.amsl.com Delivered-To: megaco@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEA9E3A69DC for ; Fri, 18 Jun 2010 00:30:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lz2CAbamoQn8 for ; Fri, 18 Jun 2010 00:30:27 -0700 (PDT) Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id A430728C0CF for ; Fri, 18 Jun 2010 00:30:26 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-552066 for megaco@ietf.org; Fri, 18 Jun 2010 09:30:31 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id F183023F0278 for ; Fri, 18 Jun 2010 09:30:27 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 18 Jun 2010 09:30:28 +0200 From: "Kukosa, Tomas" To: "megaco@ietf.org" Date: Fri, 18 Jun 2010 09:30:27 +0200 Thread-Topic: [Megaco] H.248 using RFC2833/RFC2198 and SRTP/MIKEY Thread-Index: AcsN+2ImUyvLT7aRRHSP28mzopKsEQAF0s0gACjdwhA= Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Megaco] H.248 using RFC2833/RFC2198 and SRTP/MIKEY X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jun 2010 07:30:29 -0000 Hi, thanky you for your response. I would like to avoid SDP as it not my favorit protocol. But I have not find any possibility how to map H.245 TCS to H.248. Especially receiveRTPAudioTelephonyEventCapability and mediaPacketizationCa= pability. I.e. my question does not come from SDP but from H.245 area. Best regards, Tomas -----Original Message----- From: Schwarz Albrecht [mailto:Albrecht.Schwarz@alcatel-lucent.com]=20 Sent: Thursday, June 17, 2010 2:02 PM To: Kukosa, Tomas; megaco@ietf.org Subject: RE: [Megaco] H.248 using RFC2833/RFC2198 and SRTP/MIKEY to 1): - RFC2833 is obsoleted by RFC 4733, ...!=20 - just use the SDP elements as defined by the RFCs in the H.248 LD/RD - it looks fairly strange to use H.248 binary encoding when such SDP-controlled RTP capabilities are used in the IP domain; do you really want to translate SDP text encoding at your MGC call control interface in "SDP binary" format at H.248? to 2): - see Draft H.248.77 for H.248-controlled SRTP endpoints - see 3GPP 23.334 and 29.334 as a first H.248 Profile with SRTP support > negotiate SRTP contexted between the MG and peer media=20 > endpoint ?(can be also H.248 MG but also any other kind of=20 You refer to the IP media-path (RFC 5479) related keying methods for SRTP. Any procedures at the H.248 MG "IP media-path" interface are per se out of scope of H.248. If ... then subject of an H.248 profile specification. > -----Original Message----- > From: megaco-bounces@ietf.org=20 > [mailto:megaco-bounces@ietf.org] On Behalf Of Kukosa, Tomas > Sent: Donnerstag, 17. Juni 2010 10:59 > To: megaco@ietf.org > Subject: [Megaco] H.248 using RFC2833/RFC2198 and SRTP/MIKEY >=20 > Hello, >=20 > I start looking to H.248 protocol and studying what it can do=20 > and what can't. >=20 > I am not able to find any documents related to following=20 > topics/questions: >=20 > 1) RFC2833/RFC2198 > - how the MGC can get RFC2833/RFC2198 capabilities from the=20 > MG? (used payload types, list of supported tones, ...) > - how the MGC can put peer RFC2833/RFC2198 capabilities to=20 > the MG termination? >=20 > 2) SRTP/MIKEY > - is there any document how to use MIKEY within H.248 to=20 > negotiate SRTP contexted between the MG and peer media=20 > endpoint ?(can be also H.248 MG but also any other kind of=20 > SRTP endpoint) >=20 > BTW I would prefer to use binary encoding of H.248 and if I=20 > understand it well it can not use SDP equivalent properties,=20 > is it right? >=20 > Thanks in advance for any hint. >=20 > Best regards, > Tomas > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www.ietf.org/mailman/listinfo/megaco >=20 From Albrecht.Schwarz@alcatel-lucent.com Sat Jun 19 03:11:30 2010 Return-Path: X-Original-To: megaco@core3.amsl.com Delivered-To: megaco@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FE033A67B1 for ; Sat, 19 Jun 2010 03:11:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.329 X-Spam-Level: X-Spam-Status: No, score=-0.329 tagged_above=-999 required=5 tests=[AWL=1.920, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eFpYqEF3bK3Y for ; Sat, 19 Jun 2010 03:11:28 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by core3.amsl.com (Postfix) with ESMTP id 782BB3A694A for ; Sat, 19 Jun 2010 03:11:27 -0700 (PDT) Received: from FRVELSBHS05.ad2.ad.alcatel.com (frvelsbhs05.dc-m.alcatel-lucent.com [155.132.6.77]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o5JABVeo017812; Sat, 19 Jun 2010 12:11:31 +0200 Received: from FRVELSMBS23.ad2.ad.alcatel.com ([155.132.6.51]) by FRVELSBHS05.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 19 Jun 2010 12:11:22 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 19 Jun 2010 12:11:23 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: H.323/H.245 interworking (H.248.12); RE: [Megaco] H.248 using RFC2833/RFC2198 and SRTP/MIKEY Thread-Index: AcsN+2ImUyvLT7aRRHSP28mzopKsEQAF0s0gACjdwhAAOE4I0A== References: From: "Schwarz Albrecht" To: "Kukosa, Tomas" , X-OriginalArrivalTime: 19 Jun 2010 10:11:22.0873 (UTC) FILETIME=[C4EFF690:01CB0F97] X-Scanned-By: MIMEDefang 2.64 on 155.132.188.84 Subject: [Megaco] H.323/H.245 interworking (H.248.12); RE: H.248 using RFC2833/RFC2198 and SRTP/MIKEY X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jun 2010 10:11:30 -0000 =20 Sounds like a topic for H.248.12, if H.245-to-H.248 interworking aspects, right? Perhaps you need an extension/upversion of the H.248.12 H245 Package. Do you terminate H.245 at MG or MGC level? Did you already consider H.248.12? > -----Original Message----- > From: megaco-bounces@ietf.org=20 > [mailto:megaco-bounces@ietf.org] On Behalf Of Kukosa, Tomas > Sent: Freitag, 18. Juni 2010 09:30 > To: megaco@ietf.org > Subject: Re: [Megaco] H.248 using RFC2833/RFC2198 and SRTP/MIKEY >=20 > Hi, >=20 > thanky you for your response. >=20 > I would like to avoid SDP as it not my favorit protocol. >=20 > But I have not find any possibility how to map H.245 TCS to H.248. > Especially receiveRTPAudioTelephonyEventCapability and=20 > mediaPacketizationCapability. >=20 > I.e. my question does not come from SDP but from H.245 area. >=20 > Best regards, > Tomas >=20 >=20 > -----Original Message----- > From: Schwarz Albrecht [mailto:Albrecht.Schwarz@alcatel-lucent.com] > Sent: Thursday, June 17, 2010 2:02 PM > To: Kukosa, Tomas; megaco@ietf.org > Subject: RE: [Megaco] H.248 using RFC2833/RFC2198 and SRTP/MIKEY >=20 > to 1): > - RFC2833 is obsoleted by RFC 4733, ...!=20 > - just use the SDP elements as defined by the RFCs in the H.248 LD/RD > - it looks fairly strange to use H.248 binary encoding when=20 > such SDP-controlled RTP capabilities are used in the IP=20 > domain; do you really want to translate SDP text encoding at=20 > your MGC call control interface in "SDP binary" format at H.248? >=20 > to 2): > - see Draft H.248.77 for H.248-controlled SRTP endpoints > - see 3GPP 23.334 and 29.334 as a first H.248 Profile with=20 > SRTP support >=20 > > negotiate SRTP contexted between the MG and peer media=20 > endpoint ?(can=20 > > be also H.248 MG but also any other kind of >=20 > You refer to the IP media-path (RFC 5479) related keying=20 > methods for SRTP. > Any procedures at the H.248 MG "IP media-path" interface are=20 > per se out of scope of H.248. > If ... then subject of an H.248 profile specification. >=20 >=20 > > -----Original Message----- > > From: megaco-bounces@ietf.org > > [mailto:megaco-bounces@ietf.org] On Behalf Of Kukosa, Tomas > > Sent: Donnerstag, 17. Juni 2010 10:59 > > To: megaco@ietf.org > > Subject: [Megaco] H.248 using RFC2833/RFC2198 and SRTP/MIKEY > >=20 > > Hello, > >=20 > > I start looking to H.248 protocol and studying what it can=20 > do and what=20 > > can't. > >=20 > > I am not able to find any documents related to following > > topics/questions: > >=20 > > 1) RFC2833/RFC2198 > > - how the MGC can get RFC2833/RFC2198 capabilities from the MG?=20 > > (used payload types, list of supported tones, ...) > > - how the MGC can put peer RFC2833/RFC2198 capabilities=20 > to the MG=20 > > termination? > >=20 > > 2) SRTP/MIKEY > > - is there any document how to use MIKEY within H.248 to negotiate=20 > > SRTP contexted between the MG and peer media endpoint ?(can be also=20 > > H.248 MG but also any other kind of SRTP endpoint) > >=20 > > BTW I would prefer to use binary encoding of H.248 and if I=20 > understand=20 > > it well it can not use SDP equivalent properties, is it right? > >=20 > > Thanks in advance for any hint. > >=20 > > Best regards, > > Tomas > > _______________________________________________ > > Megaco mailing list > > Megaco@ietf.org > > https://www.ietf.org/mailman/listinfo/megaco > >=20 > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www.ietf.org/mailman/listinfo/megaco >=20 From Christian.Groves@nteczone.com Sun Jun 20 20:52:50 2010 Return-Path: X-Original-To: megaco@core3.amsl.com Delivered-To: megaco@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04CC73A6A0B for ; Sun, 20 Jun 2010 20:52:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.699 X-Spam-Level: X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5 tests=[AWL=1.900, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EYnAe8sdptAk for ; Sun, 20 Jun 2010 20:52:49 -0700 (PDT) Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [150.101.137.143]) by core3.amsl.com (Postfix) with ESMTP id 630EF3A635F for ; Sun, 20 Jun 2010 20:52:47 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApEBAGZ8Hkx20eZI/2dsb2JhbAAH4AiFGwQ Received: from ppp118-209-230-72.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.230.72]) by ipmail05.adl6.internode.on.net with ESMTP; 21 Jun 2010 13:22:50 +0930 Message-ID: <4C1EE234.5020106@nteczone.com> Date: Mon, 21 Jun 2010 13:53:24 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: megaco@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Megaco] H.323/H.245 interworking (H.248.12); RE: H.248 using RFC2833/RFC2198 and SRTP/MIKEY X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2010 03:52:50 -0000 Hello Tomas, There's no description on how to map H.245 TCS to H.248 as I think that it is commonly assumed that the MGC will receive the H.245 TCS directly or tunnelled through the MG (as provided by by H.248.12). The MGC will apply what ever logic is required and then issue the appropriate H.248 commands. There is not necessary a 1:1 mapping of the information. For example "receiveRTPAudioTelephonyEventCapability" broadly maps into H.248 ability to set events to detect tones (e.g. H.248.1 annex E.6) and to send signals to initiate tones (e.g. H.248.1 annex E.7). The method to indicate these is the same whether text or binary is used. The payload type can be specified by H.248.1 annex C.1 "rtppayload". I do note that there have been a number of additions to H.245 in recent years to address additions to SDP. Neither H.248.1 Annex C nor H.248.12 has been updated specifically for these. So any proposals for enhancements are welcome. Regards, Christian On 19/06/2010 8:11 PM, Schwarz Albrecht wrote: > > Sounds like a topic for H.248.12, if H.245-to-H.248 interworking > aspects, right? > Perhaps you need an extension/upversion of the H.248.12 H245 Package. > Do you terminate H.245 at MG or MGC level? > Did you already consider H.248.12? > > >> -----Original Message----- >> From: megaco-bounces@ietf.org >> [mailto:megaco-bounces@ietf.org] On Behalf Of Kukosa, Tomas >> Sent: Freitag, 18. Juni 2010 09:30 >> To: megaco@ietf.org >> Subject: Re: [Megaco] H.248 using RFC2833/RFC2198 and SRTP/MIKEY >> >> Hi, >> >> thanky you for your response. >> >> I would like to avoid SDP as it not my favorit protocol. >> >> But I have not find any possibility how to map H.245 TCS to H.248. >> Especially receiveRTPAudioTelephonyEventCapability and >> mediaPacketizationCapability. >> >> I.e. my question does not come from SDP but from H.245 area. >> >> Best regards, >> Tomas >> >> >> -----Original Message----- >> From: Schwarz Albrecht [mailto:Albrecht.Schwarz@alcatel-lucent.com] >> Sent: Thursday, June 17, 2010 2:02 PM >> To: Kukosa, Tomas; megaco@ietf.org >> Subject: RE: [Megaco] H.248 using RFC2833/RFC2198 and SRTP/MIKEY >> >> to 1): >> - RFC2833 is obsoleted by RFC 4733, ...! >> - just use the SDP elements as defined by the RFCs in the H.248 LD/RD >> - it looks fairly strange to use H.248 binary encoding when >> such SDP-controlled RTP capabilities are used in the IP >> domain; do you really want to translate SDP text encoding at >> your MGC call control interface in "SDP binary" format at H.248? >> >> to 2): >> - see Draft H.248.77 for H.248-controlled SRTP endpoints >> - see 3GPP 23.334 and 29.334 as a first H.248 Profile with >> SRTP support >> >> >>> negotiate SRTP contexted between the MG and peer media >>> >> endpoint ?(can >> >>> be also H.248 MG but also any other kind of >>> >> You refer to the IP media-path (RFC 5479) related keying >> methods for SRTP. >> Any procedures at the H.248 MG "IP media-path" interface are >> per se out of scope of H.248. >> If ... then subject of an H.248 profile specification. >> >> >> >>> -----Original Message----- >>> From: megaco-bounces@ietf.org >>> [mailto:megaco-bounces@ietf.org] On Behalf Of Kukosa, Tomas >>> Sent: Donnerstag, 17. Juni 2010 10:59 >>> To: megaco@ietf.org >>> Subject: [Megaco] H.248 using RFC2833/RFC2198 and SRTP/MIKEY >>> >>> Hello, >>> >>> I start looking to H.248 protocol and studying what it can >>> >> do and what >> >>> can't. >>> >>> I am not able to find any documents related to following >>> topics/questions: >>> >>> 1) RFC2833/RFC2198 >>> - how the MGC can get RFC2833/RFC2198 capabilities from the MG? >>> (used payload types, list of supported tones, ...) >>> - how the MGC can put peer RFC2833/RFC2198 capabilities >>> >> to the MG >> >>> termination? >>> >>> 2) SRTP/MIKEY >>> - is there any document how to use MIKEY within H.248 to negotiate >>> SRTP contexted between the MG and peer media endpoint ?(can be also >>> H.248 MG but also any other kind of SRTP endpoint) >>> >>> BTW I would prefer to use binary encoding of H.248 and if I >>> >> understand >> >>> it well it can not use SDP equivalent properties, is it right? >>> >>> Thanks in advance for any hint. >>> >>> Best regards, >>> Tomas >>> _______________________________________________ >>> Megaco mailing list >>> Megaco@ietf.org >>> https://www.ietf.org/mailman/listinfo/megaco >>> >>> >> _______________________________________________ >> Megaco mailing list >> Megaco@ietf.org >> https://www.ietf.org/mailman/listinfo/megaco >> >> > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www.ietf.org/mailman/listinfo/megaco > . > > From tomas.kukosa@siemens-enterprise.com Sun Jun 20 23:15:50 2010 Return-Path: X-Original-To: megaco@core3.amsl.com Delivered-To: megaco@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8C923A6A24 for ; Sun, 20 Jun 2010 23:15:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lq3o46zwC+pK for ; Sun, 20 Jun 2010 23:15:48 -0700 (PDT) Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 8DC8C3A6824 for ; Sun, 20 Jun 2010 23:15:47 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-568623; Mon, 21 Jun 2010 08:15:52 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 407B623F0278; Mon, 21 Jun 2010 08:15:52 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 21 Jun 2010 08:15:52 +0200 From: "Kukosa, Tomas" To: Christian Groves , "megaco@ietf.org" Date: Mon, 21 Jun 2010 08:15:51 +0200 Thread-Topic: [Megaco] H.323/H.245 interworking (H.248.12); RE: H.248 using RFC2833/RFC2198 and SRTP/MIKEY Thread-Index: AcsQ9T9VMvXI44S0QRyhK2MjnjhXSQAE8Liw Message-ID: References: <4C1EE234.5020106@nteczone.com> In-Reply-To: <4C1EE234.5020106@nteczone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Megaco] H.323/H.245 interworking (H.248.12); RE: H.248 using RFC2833/RFC2198 and SRTP/MIKEY X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2010 06:15:51 -0000 Hello Christian, thank you very much for all your hints! I will look at all mentioned documents and chapters. Best regards, Tomas=20 -----Original Message----- From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf Of= Christian Groves Sent: Monday, June 21, 2010 5:53 AM To: megaco@ietf.org Subject: Re: [Megaco] H.323/H.245 interworking (H.248.12); RE: H.248 using = RFC2833/RFC2198 and SRTP/MIKEY Hello Tomas, There's no description on how to map H.245 TCS to H.248 as I think that=20 it is commonly assumed that the MGC will receive the H.245 TCS directly=20 or tunnelled through the MG (as provided by by H.248.12). The MGC will=20 apply what ever logic is required and then issue the appropriate H.248=20 commands. There is not necessary a 1:1 mapping of the information. For example "receiveRTPAudioTelephonyEventCapability" broadly maps into=20 H.248 ability to set events to detect tones (e.g. H.248.1 annex E.6)=20 and to send signals to initiate tones (e.g. H.248.1 annex E.7). The=20 method to indicate these is the same whether text or binary is used. The=20 payload type can be specified by H.248.1 annex C.1 "rtppayload". I do note that there have been a number of additions to H.245 in recent=20 years to address additions to SDP. Neither H.248.1 Annex C nor H.248.12=20 has been updated specifically for these. So any proposals for=20 enhancements are welcome. Regards, Christian On 19/06/2010 8:11 PM, Schwarz Albrecht wrote: > > Sounds like a topic for H.248.12, if H.245-to-H.248 interworking > aspects, right? > Perhaps you need an extension/upversion of the H.248.12 H245 Package. > Do you terminate H.245 at MG or MGC level? > Did you already consider H.248.12? > > =20 >> -----Original Message----- >> From: megaco-bounces@ietf.org >> [mailto:megaco-bounces@ietf.org] On Behalf Of Kukosa, Tomas >> Sent: Freitag, 18. Juni 2010 09:30 >> To: megaco@ietf.org >> Subject: Re: [Megaco] H.248 using RFC2833/RFC2198 and SRTP/MIKEY >> >> Hi, >> >> thanky you for your response. >> >> I would like to avoid SDP as it not my favorit protocol. >> >> But I have not find any possibility how to map H.245 TCS to H.248. >> Especially receiveRTPAudioTelephonyEventCapability and >> mediaPacketizationCapability. >> >> I.e. my question does not come from SDP but from H.245 area. >> >> Best regards, >> Tomas >> >> >> -----Original Message----- >> From: Schwarz Albrecht [mailto:Albrecht.Schwarz@alcatel-lucent.com] >> Sent: Thursday, June 17, 2010 2:02 PM >> To: Kukosa, Tomas; megaco@ietf.org >> Subject: RE: [Megaco] H.248 using RFC2833/RFC2198 and SRTP/MIKEY >> >> to 1): >> - RFC2833 is obsoleted by RFC 4733, ...! >> - just use the SDP elements as defined by the RFCs in the H.248 LD/RD >> - it looks fairly strange to use H.248 binary encoding when >> such SDP-controlled RTP capabilities are used in the IP >> domain; do you really want to translate SDP text encoding at >> your MGC call control interface in "SDP binary" format at H.248? >> >> to 2): >> - see Draft H.248.77 for H.248-controlled SRTP endpoints >> - see 3GPP 23.334 and 29.334 as a first H.248 Profile with >> SRTP support >> >> =20 >>> negotiate SRTP contexted between the MG and peer media >>> =20 >> endpoint ?(can >> =20 >>> be also H.248 MG but also any other kind of >>> =20 >> You refer to the IP media-path (RFC 5479) related keying >> methods for SRTP. >> Any procedures at the H.248 MG "IP media-path" interface are >> per se out of scope of H.248. >> If ... then subject of an H.248 profile specification. >> >> >> =20 >>> -----Original Message----- >>> From: megaco-bounces@ietf.org >>> [mailto:megaco-bounces@ietf.org] On Behalf Of Kukosa, Tomas >>> Sent: Donnerstag, 17. Juni 2010 10:59 >>> To: megaco@ietf.org >>> Subject: [Megaco] H.248 using RFC2833/RFC2198 and SRTP/MIKEY >>> >>> Hello, >>> >>> I start looking to H.248 protocol and studying what it can >>> =20 >> do and what >> =20 >>> can't. >>> >>> I am not able to find any documents related to following >>> topics/questions: >>> >>> 1) RFC2833/RFC2198 >>> - how the MGC can get RFC2833/RFC2198 capabilities from the MG? >>> (used payload types, list of supported tones, ...) >>> - how the MGC can put peer RFC2833/RFC2198 capabilities >>> =20 >> to the MG >> =20 >>> termination? >>> >>> 2) SRTP/MIKEY >>> - is there any document how to use MIKEY within H.248 to negotiate >>> SRTP contexted between the MG and peer media endpoint ?(can be also >>> H.248 MG but also any other kind of SRTP endpoint) >>> >>> BTW I would prefer to use binary encoding of H.248 and if I >>> =20 >> understand >> =20 >>> it well it can not use SDP equivalent properties, is it right? >>> >>> Thanks in advance for any hint. >>> >>> Best regards, >>> Tomas >>> _______________________________________________ >>> Megaco mailing list >>> Megaco@ietf.org >>> https://www.ietf.org/mailman/listinfo/megaco >>> >>> =20 >> _______________________________________________ >> Megaco mailing list >> Megaco@ietf.org >> https://www.ietf.org/mailman/listinfo/megaco >> >> =20 > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www.ietf.org/mailman/listinfo/megaco > . > > =20 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www.ietf.org/mailman/listinfo/megaco From sharu.allimatti@gmail.com Wed Jun 23 06:46:25 2010 Return-Path: X-Original-To: megaco@core3.amsl.com Delivered-To: megaco@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1BE63A6A92 for ; Wed, 23 Jun 2010 06:46:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.09 X-Spam-Level: X-Spam-Status: No, score=0.09 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oPsA2Ey6PG75 for ; Wed, 23 Jun 2010 06:46:22 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id B824B3A6A8A for ; Wed, 23 Jun 2010 06:46:21 -0700 (PDT) Received: by wye20 with SMTP id 20so566762wye.31 for ; Wed, 23 Jun 2010 06:46:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=SShhGQyh85IxHAcxl8cCmPQYO0xsJGb0iGWcQU+HpuA=; b=jonnJfFZ3wfxUzWnzGRt6Edb4MGcTKYIjvAdno88HMkdsmrWHO5jaLy3URGSg3O7ja WNFiJ0imI6MEBP1PSGbHoCDiHHXbV5EBTGcv0eiq23GRwcwEMd2dZRF+WX/qLpJZ9i9n qR3/bckWeVZ7Su+OH1GTaEW1K+n4JlhCGVFoI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=hGbiDhJuORgPODBAMBYQFHQ2X/jVRJ2qWE80YVQovfTADAysEKUIdRP1Ijoc8NRhkD DvDV/fJo1GSgERiqD6a1nNm25fKfWJfaAZvvzXsv+zCw5Q5lnscM4Gx4JaLZELAyxGba ykrVAvtjmhvzo2syOzTbmHhUfXrQ6etinCO0k= MIME-Version: 1.0 Received: by 10.216.171.147 with SMTP id r19mr5960260wel.70.1277300785416; Wed, 23 Jun 2010 06:46:25 -0700 (PDT) Received: by 10.216.20.131 with HTTP; Wed, 23 Jun 2010 06:46:25 -0700 (PDT) Date: Wed, 23 Jun 2010 19:16:25 +0530 Message-ID: From: sharada rayar To: megaco@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [Megaco] ReserveGroup Reservevalue X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 13:46:25 -0000 Hi, Would like to know if the below message flow is valid scenarios for IPV6 and IPV4 connection with ReserveGroup= true. MGC-->MG " Add = DS0/1/1; Add = $ { Media { LocalControl { Mode = ReceiveOnly, ReserveGroup = true, ReserveValue = true} Local { v=0 c=IN IP4 $ m=audio $ RTP/AVP 4 m=audio $ RTP/AVP 0 ; IP termination for audio m=image $ udptl t38 ;IP termination for fax v=0 c=IN IP6 $ m=image $ udptl t38 ;IP termination for fax " MG--->MGC: " Context = 2000 { Add = DS0/1/1; Add = RTP/1 { Media { Local { v=0 c=IN IP4 124.124.124.222 m=audio 2222 RTP/AVP 4 m=audio 2222 RTP/AVP 0 ; m=image $ udptl t38 ;IP termination for fax All values are possible v=0 c=IN IP6 0.0.0.0 ; not active m=image 1111 udptl t38 ;other udp port for fax a=... ; }" Thanks, Sharada From Christian.Groves@nteczone.com Wed Jun 23 16:31:42 2010 Return-Path: X-Original-To: megaco@core3.amsl.com Delivered-To: megaco@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1EEF3A68BC for ; Wed, 23 Jun 2010 16:31:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.749 X-Spam-Level: X-Spam-Status: No, score=-0.749 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P4AB3FCNqYsl for ; Wed, 23 Jun 2010 16:31:41 -0700 (PDT) Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [150.101.137.131]) by core3.amsl.com (Postfix) with ESMTP id 7433B3A6814 for ; Wed, 23 Jun 2010 16:31:40 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuIBAG80Ikx20eZI/2dsb2JhbAAHkn/QMoUbBA Received: from ppp118-209-230-72.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.230.72]) by ipmail07.adl2.internode.on.net with ESMTP; 24 Jun 2010 09:01:47 +0930 Message-ID: <4C229985.70607@nteczone.com> Date: Thu, 24 Jun 2010 09:32:21 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: megaco@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Megaco] ReserveGroup Reservevalue X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 23:31:43 -0000 Hello Sharada, No, you can only have one m= per group. Thus the "ReserveGroup=true" has the effect of reserving one m=line per group. "ReserveValue=true" has the effect of reserving the contents of that m=line. See H.248.1v3 Amd.2 section 7.1.7.1.3. Regards, Christian On 23/06/2010 11:46 PM, sharada rayar wrote: > Hi, > Would like to know if the below message flow is valid scenarios for > IPV6 and IPV4 connection with ReserveGroup= true. > > > MGC-->MG > " Add = DS0/1/1; > Add = $ { > Media { > LocalControl { > Mode = ReceiveOnly, > ReserveGroup = true, > ReserveValue = true} > Local { > v=0 > c=IN IP4 $ > m=audio $ RTP/AVP 4 > m=audio $ RTP/AVP 0 ; IP termination for audio > m=image $ udptl t38 > ;IP termination for fax > v=0 > c=IN IP6 $ > m=image $ udptl t38 > ;IP termination for fax > " > > > MG--->MGC: > " > Context = 2000 { > Add = DS0/1/1; > Add = RTP/1 { > Media { > Local { > v=0 > c=IN IP4 124.124.124.222 > m=audio 2222 RTP/AVP 4 > m=audio 2222 RTP/AVP 0 ; > m=image $ udptl t38 > ;IP termination for fax All values are possible > v=0 > c=IN IP6 0.0.0.0 ; not active > m=image 1111 udptl t38 ;other udp port for fax > a=... ; > }" > > > Thanks, > Sharada > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www.ietf.org/mailman/listinfo/megaco > > From jwright@azteknetworks.net Thu Jun 24 15:07:42 2010 Return-Path: X-Original-To: megaco@core3.amsl.com Delivered-To: megaco@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D853E3A69CD for ; Thu, 24 Jun 2010 15:07:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.376 X-Spam-Level: X-Spam-Status: No, score=-3.376 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NJUCW7kN5M3l for ; Thu, 24 Jun 2010 15:07:42 -0700 (PDT) Received: from p01c12o149.mxlogic.net (p01c12o149.mxlogic.net [208.65.145.72]) by core3.amsl.com (Postfix) with ESMTP id B558C3A68C3 for ; Thu, 24 Jun 2010 15:07:41 -0700 (PDT) Received: from unknown [216.166.12.31] by p01c12o149.mxlogic.net(mxl_mta-6.7.0-0) with SMTP id 537d32c4.0.8123.00-399.19187.p01c12o149.mxlogic.net (envelope-from ); Thu, 24 Jun 2010 16:07:50 -0600 (MDT) X-MXL-Hash: 4c23d7361b75bee9-3864584845b18673f506105e3bb0a815dfc948a8 Received: from mail-gx0-f172.google.com (10.2.3.210) by smtp.collaborationhost.net (10.2.0.46) with Microsoft SMTP Server (TLS) id 8.1.375.2; Thu, 24 Jun 2010 17:07:24 -0500 Received: by gxk8 with SMTP id 8so1812055gxk.31 for ; Thu, 24 Jun 2010 15:07:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.190.80 with SMTP id dh16mr5776574qcb.29.1277417243718; Thu, 24 Jun 2010 15:07:23 -0700 (PDT) Received: by 10.229.235.193 with HTTP; Thu, 24 Jun 2010 15:07:23 -0700 (PDT) Date: Thu, 24 Jun 2010 16:07:23 -0600 Message-ID: From: Jeffrey Wright To: Content-Type: multipart/alternative; boundary="00163631035b0ab5300489cde1d8" X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010062201)] X-MAIL-FROM: X-SOURCE-IP: [(unknown)] X-AnalysisOut: [v=1.0 c=1 a=SY4N7blsve0A:10 a=q8OS1GolVHwA:10 a=VphdPIyG4k] X-AnalysisOut: [EA:10 a=qS3xps/WtSuafY8lc/WARg==:17 a=Wt2RA5aJZWyWHyPA21YA] X-AnalysisOut: [:9 a=oC6fAXSW0QsepQl2xSZOyN5xQVEA:4 a=wPNLvfGTeEIA:10 a=Oa] X-AnalysisOut: [715I9j90fKqZ0n:21 a=95T7zgA6qQjjHZ1k:21 a=vu7YqqywVF0JNVE8] X-AnalysisOut: [28IA:9 a=Fo9WHxS4glXdk-L3yuTrwh-e7cQA:4] Subject: [Megaco] Recommendations for small/cheap MGs X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2010 22:07:43 -0000 --00163631035b0ab5300489cde1d8 Content-Type: text/plain; charset="ISO-8859-1" Hi all, I hope this is an appropriate question to ask on this list. I am looking for a few cheap/small H.248-compliant gateways that would allow me to connect a couple of analog phones to them and make calls. I have a test network at work with a Metaswitch 2510 that I was hoping to use as a MGC; I'd like to connect some MGs to that, and do a little sniffing on the network to further my understanding of H.248 callflows. I've done similar things in the past with SIP devices, and was able to find several vendors of cheap little SIP-enabled gateways. But I'm having a harder time finding something similar (if it exists) for H.248. Can anyone recommend to me something that might suit my purpose? BTW I would prefer to have devices that implement H.248 v3, but at this point I'd take anything that (a) lets me make a call, and (b) doesn't break the bank. Thanks in advance, Jeffrey D. Wright --00163631035b0ab5300489cde1d8 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Hi all,

I hope this is an appropriate question to ask on this list.= =A0 I am looking for a few cheap/small H.248-compliant gateways that would = allow me to connect a couple of analog phones to them and make calls.=A0 I = have a test network at work with a Metaswitch 2510 that I was hoping to use= as a MGC; I'd like to connect some MGs to that, and do a little sniffi= ng on the network to further my understanding of H.248 callflows.

I've done similar things in the past with SIP devices, and was able= to find several vendors of cheap little SIP-enabled gateways.=A0 But I'= ;m having a harder time finding something similar (if it exists) for H.248.=

Can anyone recommend to me something that might suit my purpose?=A0 BTW= I would prefer to have devices that implement H.248 v3, but at this point = I'd take anything that (a) lets me make a call, and (b) doesn't bre= ak the bank.

Thanks in advance,

Jef= frey D. Wright

--00163631035b0ab5300489cde1d8-- From Albrecht.Schwarz@alcatel-lucent.com Fri Jun 25 04:18:08 2010 Return-Path: X-Original-To: megaco@core3.amsl.com Delivered-To: megaco@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2CDD3A67C0 for ; Fri, 25 Jun 2010 04:18:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.269 X-Spam-Level: X-Spam-Status: No, score=-1.269 tagged_above=-999 required=5 tests=[AWL=2.379, BAYES_50=0.001, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MlCFFGxo2-Xd for ; Fri, 25 Jun 2010 04:18:07 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id B6C5B3A697D for ; Fri, 25 Jun 2010 04:18:05 -0700 (PDT) Received: from FRVELSBHS06.ad2.ad.alcatel.com (frvelsbhs06.dc-m.alcatel-lucent.com [155.132.6.78]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o5PBI8kD024917; Fri, 25 Jun 2010 13:18:10 +0200 Received: from FRVELSMBS23.ad2.ad.alcatel.com ([155.132.6.55]) by FRVELSBHS06.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 25 Jun 2010 13:18:08 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB1458.167129D6" Date: Fri, 25 Jun 2010 13:18:07 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: StreamMode & Statistics Thread-Index: AcsUWBYiGA9u79/iTMSreIN7Qh+nHQ== From: "Schwarz Albrecht" To: "Christian Groves" , X-OriginalArrivalTime: 25 Jun 2010 11:18:08.0409 (UTC) FILETIME=[16E6C090:01CB1458] X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Subject: [Megaco] StreamMode & Statistics X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2010 11:18:09 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB1458.167129D6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Christian, et al., =20 we were looking again at some info how a specific StreamMode setting is related to the local generation of Statistics. =20 E.g.=20 StreamMode =3D Inactive Statistic =3D "... octets/packets received" =20 I'm fairly sure that this item was already raised and discussed in the past. Do you know? =20 E.g., the Inactive semantic ("=20 Inactive: The termination does not pass any media for the stream. ") is not explicit on the 'receive' part, just on the forwarding part. =20 Thanks, Albrecht ------_=_NextPart_001_01CB1458.167129D6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Christian,=20 et al.,
 
we were=20 looking again at some info how a specific StreamMode setting is related = to the=20 local generation of Statistics.
 
E.g.=20
StreamMode =3D=20 Inactive
Statistic =3D=20 "... octets/packets received"
 
I'm fairly=20 sure that this item was already raised and discussed in the=20 past.
Do you=20 know?
 
E.g., the=20 Inactive semantic ("

Inactive:       The = termination=20 does not pass any media for the = stream.

")
is not=20 explicit on the 'receive' part, just on the forwarding = part.
 
Thanks,
Albrecht
------_=_NextPart_001_01CB1458.167129D6--