From ReidcramerHowe@ctia.org Tue Apr 1 19:48:47 2008 Return-Path: X-Original-To: ietfarch-megaco-archive@core3.amsl.com Delivered-To: ietfarch-megaco-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC4E13A6CCC; Tue, 1 Apr 2008 19:48:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -75.186 X-Spam-Level: X-Spam-Status: No, score=-75.186 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DATE_IN_PAST_12_24=0.992, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_DYNAMIC_HCC=4.295, HELO_EQ_MODEMCABLE=0.768, HELO_EQ_MX=0.535, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_MLH_Stock1=0.87, USER_IN_WHITELIST=-100] 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 k8WgU-Qx5YYN; Tue, 1 Apr 2008 19:48:47 -0700 (PDT) Received: from jorge.mshome.net (host-70-45-86-2.onelinkpr.net [70.45.86.2]) by core3.amsl.com (Postfix) with SMTP id 1975A3A691E; Tue, 1 Apr 2008 19:48:46 -0700 (PDT) Received: from 12974234381988231.10907262866208995.11377532086793802.11576262716992302 (HELO localhost.localdomain) (11764232118204487.12337549732135389.18125031606252860.12954259882504650) by 19324527120947152.11141475536458095.15076361816950957.14800194092603272 with SMTP; Wed, 2 Apr 2003 22:38:01 +0600 Date: Wed, 2 Apr 2003 22:38:01 +0600 Message-Id: <5IX058EJXVWDA351@ctia.org> X-Mailer: MIME::Lite 3.01 (F2.72; A1.62; B3.01; Q3.01) X-Header-CompanyDBUserName: hpccm X-Header-MasterId: 065774 X-Header-Versions: Hewlett-Packard.1t3bn2nd3.fk@us.newsgram.hp.com X-FID: 34E65DBC-3198-28AF-B7E4-17CDEA90DCB3 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Cc: , , , From: "Freeman Cervantes" Subject: Urgent Equity Alert
Gold and Silver prices have been skyrocketing

The recent fall has given you the perfect time to get in and ride gold to $2 for the past week as the undiscovered gem of Gold Production

Now is the time to get in
Symbol : GSML

The move has started and this stock is definately dollar plus bound

This is not a fly by night, Its a real copmpany with real operations in the metals that are everyone's backup plans for the econimic worries

Dont miss out, Get in GSML and make the smart safe profits
From megaco-bounces@ietf.org Tue Apr 1 21:49:09 2008 Return-Path: X-Original-To: megaco-archive@megatron.ietf.org Delivered-To: ietfarch-megaco-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCB6C3A6A7F; Tue, 1 Apr 2008 21:49:09 -0700 (PDT) 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 B8F5B3A68F2 for ; Tue, 1 Apr 2008 21:49:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=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 e1B2A7V2aaJ8 for ; Tue, 1 Apr 2008 21:49:08 -0700 (PDT) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.29]) by core3.amsl.com (Postfix) with ESMTP id DC69E3A686F for ; Tue, 1 Apr 2008 21:49:07 -0700 (PDT) Received: by yw-out-2324.google.com with SMTP id 2so275526ywt.49 for ; Tue, 01 Apr 2008 21:49:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=B3MCbrCL6v8eKPPohHdnADQNiCjF4Nr/rHXP0Ef5Lfw=; b=FOqQtVtMqX4UkooCCM9Mkb/CKsUqRJ265f7fitycNU+RIgd7aYr1eibBnm6qDWWLF+FfNxBnuXUZoEib9SiI/wkHtgonS6XPGERIQhRHefYX7ojHtnQbpK3ywXSnBFHDPX3R+sf55mVjgulI/6Tt8AvZpOE2k9veBCycWOLllNc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:from:to:subject:mime-version:content-type; b=PSIvSwefBaIa80YTUi1Y0Zg47ioZ6YRQOvkcJf+ctOvRZwQH1Tc7S1s4B2I3TPQjBzHKddoxfeZxvq7uqxREiqu1PRJor7fhV96EhVKFbbnEHOKC8RmpcW/wdJq3APkqALPQ9REuekkTHohDykbIeIn5xL4WFcqhtnonkTBJ1IQ= Received: by 10.151.38.12 with SMTP id q12mr4662001ybj.18.1207111747666; Tue, 01 Apr 2008 21:49:07 -0700 (PDT) Received: by 10.150.226.20 with HTTP; Tue, 1 Apr 2008 21:49:07 -0700 (PDT) Message-ID: Date: Wed, 2 Apr 2008 15:49:07 +1100 From: "Kevin Lee" To: megaco@ietf.org MIME-Version: 1.0 Subject: [Megaco] ICV synthesized IP header X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0504325540==" Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org --===============0504325540== Content-Type: multipart/alternative; boundary="----=_Part_9121_31133170.1207111747629" ------=_Part_9121_31133170.1207111747629 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi all, I have a question regarding to the synthesized IP header used while calculating ICV. In the spec, it says "..the message prepended by a synthesized IP header consisting of a 32-bit source IP address, a 32-bit destination address and a 16-bit UDP destination port encoded as 20 hex digits." My question is does the synthesized IP header need to be converted to 20 characters of hex (text representation)? or do we use it as 10 bytes of binary data? Because the synthesized header is not being transmitted, I am unsure why it needs to be converted to text format when calculating the ICV? Thanks and best regards, Kevin. ------=_Part_9121_31133170.1207111747629 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi all,

I have a question regarding to the synthesized IP header used while calculating ICV.

In the spec, it says
"..the message prepended by a synthesized IP header consisting of a 32-bit source IP address, a 32-bit destination address and a 16-bit UDP destination port encoded as 20 hex digits."

My question is does the synthesized IP header need to be converted to 20 characters of hex (text representation)? or do we use it as 10 bytes of binary data?

Because the synthesized header is not being transmitted, I am unsure why it needs to be converted to text format when calculating the ICV?

Thanks and best regards,
Kevin.

------=_Part_9121_31133170.1207111747629-- --===============0504325540== 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://www.ietf.org/mailman/listinfo/megaco --===============0504325540==-- From megaco-bounces@ietf.org Thu Apr 3 14:14:59 2008 Return-Path: X-Original-To: megaco-archive@megatron.ietf.org Delivered-To: ietfarch-megaco-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8F623A6D23; Thu, 3 Apr 2008 14:14:58 -0700 (PDT) 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 A16E228C19B for ; Thu, 3 Apr 2008 14:14:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.957 X-Spam-Level: X-Spam-Status: No, score=-3.957 tagged_above=-999 required=5 tests=[AWL=2.641, BAYES_00=-2.599, 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 uLI5cZiDHIlB for ; Thu, 3 Apr 2008 14:14:50 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 948C03A6D23 for ; Thu, 3 Apr 2008 14:14:49 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 03 Apr 2008 14:14:53 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m33LEq20029067 for ; Thu, 3 Apr 2008 14:14:52 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m33LEqSg000372 for ; Thu, 3 Apr 2008 21:14:52 GMT Received: from xmb-sjc-218.amer.cisco.com ([171.70.151.151]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 Apr 2008 14:14:51 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 3 Apr 2008 14:14:41 -0700 Message-ID: In-Reply-To: <34B3EAA5B3066A42914D28C5ECF5FEA41446EF0C@zrtphxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Does version 2 support compacted contexts in AuditValue command Thread-Index: AciQ8RUNSCRrmPnkQh+vzo/8CahRpQAA5dygAAJxaKAAABXIkAE0JcgQ From: "Suchi Sahoo (suchis)" To: X-OriginalArrivalTime: 03 Apr 2008 21:14:51.0980 (UTC) FILETIME=[C1A760C0:01C895CF] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2467; t=1207257292; x=1208121292; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=suchis@cisco.com; z=From:=20=22Suchi=20Sahoo=20(suchis)=22=20 |Subject:=20Does=20version=202=20support=20compacted=20cont exts=20in=20AuditValue=20command |Sender:=20; bh=4eO7NooE0iSJgOLaZRJmBAnRFigTMNSfYaGuBYN2rio=; b=fVGPjEK3thaQ+nNOFVNTTMwjperiy7+ZNje1Xhv0eQTOwxN5FqOtTp+RiD BF/F+06APtWibekSo9jUP53eZJ5CKuJBNfi6yClguRlUCdcYeVBanXcCmRmt nbTiolUlvl; Authentication-Results: sj-dkim-2; header.From=suchis@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: [Megaco] Does version 2 support compacted contexts in AuditValue command X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1725126136==" Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org This is a multi-part message in MIME format. --===============1725126136== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C895CF.BBA394C6" This is a multi-part message in MIME format. ------_=_NextPart_001_01C895CF.BBA394C6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Does version 2 of H.248 support the following syntax for AuditValue? MEGACO/2 [2.2.2.2]: 2944 Transaction =3D 121 {=20 Context =3D * { ContextAttr { ContextList =3D { * } }, AuditValue =3D ROOT {Audit{} } } } =20 MEGACO/2 [1.1.1.1]: 2944 Reply =3D 121 {=20 Context =3D * { ContextAttr { ContextList =3D {1,2,3,4,5,6,7 } }, AuditValue =3D ROOT {Audit{} } } } Thanks, Suchi=20 ------_=_NextPart_001_01C895CF.BBA394C6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Does version 2 of H.248 support the following = syntax=20 for AuditValue?

MEGACO/2 [2.2.2.2]: 2944
Transaction = =3D 121 {=20
  Context =3D * { ContextAttr { ContextList =3D { * }=20 },
           &= nbsp;           &n= bsp;=20 AuditValue =3D ROOT {Audit{} } } }
 
MEGACO/2 [1.1.1.1]: 2944
Reply =3D 121 { =
 =20 Context =3D * { ContextAttr { ContextList =3D {1,2,3,4,5,6,7 }=20 },
           &= nbsp;           &n= bsp;=20 AuditValue =3D ROOT {Audit{} } } }
Thanks,
Suchi 
------_=_NextPart_001_01C895CF.BBA394C6-- --===============1725126136== 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://www.ietf.org/mailman/listinfo/megaco --===============1725126136==-- From megaco-bounces@ietf.org Thu Apr 10 17:58:53 2008 Return-Path: X-Original-To: megaco-archive@megatron.ietf.org Delivered-To: ietfarch-megaco-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCD3B3A6B06; Thu, 10 Apr 2008 17:58:53 -0700 (PDT) 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 0A7513A69DC for ; Thu, 10 Apr 2008 17:58:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.605 X-Spam-Level: X-Spam-Status: No, score=-2.605 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RELAY_IS_203=0.994] 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 VlKDhTrjHw-Y for ; Thu, 10 Apr 2008 17:58:51 -0700 (PDT) Received: from ipmail01.adl6.internode.on.net (ipmail01.adl6.internode.on.net [203.16.214.146]) by core3.amsl.com (Postfix) with ESMTP id 0B3303A696B for ; Thu, 10 Apr 2008 17:58:50 -0700 (PDT) Received: from ppp59-167-66-86.lns1.mel6.internode.on.net (HELO [192.168.0.6]) ([59.167.66.86]) by ipmail01.adl6.internode.on.net with ESMTP; 11 Apr 2008 10:29:11 +0930 Message-ID: <47FEB7D3.3070103@nteczone.com> Date: Fri, 11 Apr 2008 10:58:59 +1000 From: Christian Groves User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: megaco ietf Subject: [Megaco] Updated Package and Error Registrations X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org Hello all, FYI. The IANA H.248/Megaco Package registrations have now been updated to show the latest packages and error codes as well as up to date references for the Packages. See: http://www.iana.org/assignments/megaco-h248 Regards, Christian _______________________________________________ Megaco mailing list Megaco@ietf.org https://www.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Mon Apr 14 08:09:14 2008 Return-Path: X-Original-To: megaco-archive@megatron.ietf.org Delivered-To: ietfarch-megaco-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAA3928C2BA; Mon, 14 Apr 2008 08:09:14 -0700 (PDT) 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 5BBBC28C2BA for ; Mon, 14 Apr 2008 08:09:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 CCc5vSScpZ45 for ; Mon, 14 Apr 2008 08:09:12 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by core3.amsl.com (Postfix) with ESMTP id 76D1E28C2B7 for ; Mon, 14 Apr 2008 08:09:12 -0700 (PDT) Received: from source ([66.129.224.36]) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP; Mon, 14 Apr 2008 08:07:23 PDT Received: from emailfeemea1.jnpr.net ([172.26.192.140]) by gamma.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Apr 2008 08:07:45 -0700 Received: from emailemea6.jnpr.net ([172.26.192.141]) by emailfeemea1.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Apr 2008 16:07:31 +0100 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7235.2 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 14 Apr 2008 15:57:48 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Version of "Disconnected" ServiceChange messages Thread-Index: AcieP+dSED8sh1kMTtWHwUUMUNib5w== From: "Elad Chomsky" To: X-OriginalArrivalTime: 14 Apr 2008 15:07:31.0068 (UTC) FILETIME=[42CA5BC0:01C89E41] Subject: [Megaco] Version of "Disconnected" ServiceChange messages X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org Hello H.248 heavyweights, I have a question regarding the H.248 version that should be used when encoding a "Disconnected" ServiceChange request. The way an MG utilizes "Disconnected" ServiceChange requests is described under Annex F.3.6 of H.248.1: 1/ When an MG detects that it became disconnected from its MGC, it tries to re-establish its control-association by sending a "Disconnected" ServiceChange request to that MGC. If the MGC replies to request, the control-association continues without interruption. 2/ If the MGC fails to reply to the ServiceChange request above, the MG starts traversing its list of possible MGCs and tries registering with each of them. The MG will use a "Disconnected" ServiceChange when trying to register with the original MGC and a "Failover" ServiceChange when trying to register with any other MGC. 3/ The control-association is terminated as soon as the MG sends a "Failover" ServiceChange request to an MGC. Now according to (2) above, the "Disconnected" ServiceChange can be considered as a registration. Therefore, according to clause 11.3 of H.248.1, it must be encoded according as a version 1 message. However it also appears that in (1) above, the "Disconnected" ServiceChange is sent over an existing control-association; and therefore should be encoded according to the association's negotiated version. Is this the correct interpretation? I.e. Must a "Disconnected" ServiceChange be encoded using version 1 if no control association exists and using the negotiated version if a control-association exists? Or should one of these versions always be used? Many thanks in advance, Elad Chomsky _______________________________________________ Megaco mailing list Megaco@ietf.org https://www.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Mon Apr 14 23:42:42 2008 Return-Path: X-Original-To: megaco-archive@megatron.ietf.org Delivered-To: ietfarch-megaco-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E61F428C33B; Mon, 14 Apr 2008 23:42:42 -0700 (PDT) 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 17D833A6D44 for ; Mon, 14 Apr 2008 23:42:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.714 X-Spam-Level: X-Spam-Status: No, score=-5.714 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, 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 X9NvEacA7HS0 for ; Mon, 14 Apr 2008 23:42:39 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by core3.amsl.com (Postfix) with ESMTP id E26E13A6AE5 for ; Mon, 14 Apr 2008 23:42:38 -0700 (PDT) Received: from source ([66.129.224.36]) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP; Mon, 14 Apr 2008 23:43:11 PDT Received: from emailcnrd1.jnpr.net ([10.208.0.15]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Apr 2008 23:42:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 15 Apr 2008 14:42:51 +0800 Message-ID: <322CBDC9307AE449B2BBDA9BF40792EF01985B89@emailcnrd1.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: An issue about encoder for MEGACO Thread-Index: Aciew+1SgnezzXMtTd2yfOKPKCmfrw== From: "George Quan" To: X-OriginalArrivalTime: 15 Apr 2008 06:42:56.0046 (UTC) FILETIME=[EFE25CE0:01C89EC3] Subject: [Megaco] An issue about encoder for MEGACO X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1244224893==" Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org This is a multi-part message in MIME format. --===============1244224893== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C89EC3.EE129463" This is a multi-part message in MIME format. ------_=_NextPart_001_01C89EC3.EE129463 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all: I found the following encoder in some vendor. I am not sure whether it is right or not. Please help me.=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D MEGACO/1 [10.136.1.95]:2944=20 Reply=3D186002{Context=3D-{Modify=3DROOT}} TransactionResponseAck{1} =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 In the packet, Both TransactionRequest and TransactionResponseAck are embedded in one message, is it right?=20 I look into ITU H.248.1 V3, it seems that it don't allow encoding.=20 Pls give me some guide. =20 BTW: the following is defined in P98, ITU H.248.1 V3. =20 transactionList =3D 1*(transactionRequest / transactionReply / transactionPending / transactionResponseAck / segmentReply)=20 =20 thanks=20 George =20 Best Regard ------------------------------------------- Juniper Network CN R&D Co. Ltd. George Quan=20 Tel: 8610-5874-7167 Location: 7.1.301 =20 ------_=_NextPart_001_01C89EC3.EE129463 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = all:

  I found = the following encoder in some vendor. I am not sure whether it is right or = not. Please help me.

=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D

MEGACO/1 [10.136.1.95]:2944

 Reply=3D18= 6002{Context=3D-{Modify=3DROOT}}

 Transactio= nResponseAck{1}

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D

 

In the packet, = Both TransactionRequest and TransactionResponseAck are embedded in one message, is it right? =

I look into ITU = H.248.1 V3, it seems that it don't allow encoding.

Pls give me = some guide.

 

BTW: the = following is defined in P98, ITU H.248.1 V3.

 

transactionList = =3D 1*(transactionRequest / transactionReply /

transactionPendi= ng / transactionResponseAck /

segmentReply) =

 

thanks =

George

 

 Best Regard

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

Juniper Network CN R&D Co. = Ltd.

George Quan

Tel: 8610-5874-7167

Location: 7.1.301  

------_=_NextPart_001_01C89EC3.EE129463-- --===============1244224893== 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://www.ietf.org/mailman/listinfo/megaco --===============1244224893==-- From megaco-bounces@ietf.org Mon Apr 14 23:43:48 2008 Return-Path: X-Original-To: megaco-archive@megatron.ietf.org Delivered-To: ietfarch-megaco-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8525F28C370; Mon, 14 Apr 2008 23:43:48 -0700 (PDT) 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 58AE628C374 for ; Mon, 14 Apr 2008 23:43:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.141 X-Spam-Level: X-Spam-Status: No, score=-1.141 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] 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 x9lwBJIlsE-U for ; Mon, 14 Apr 2008 23:43:44 -0700 (PDT) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by core3.amsl.com (Postfix) with ESMTP id 9A2AA28C33B for ; Mon, 14 Apr 2008 23:43:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 14A93541FFF; Mon, 14 Apr 2008 23:44:17 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24935-07; Mon, 14 Apr 2008 23:44:16 -0700 (PDT) Received: from [155.53.44.239] (cologne.redback.com [155.53.44.239]) by prattle.redback.com (Postfix) with ESMTP id E6BC1541FFE; Mon, 14 Apr 2008 23:44:16 -0700 (PDT) Message-ID: <48044EC0.1040505@redback.com> Date: Mon, 14 Apr 2008 23:44:16 -0700 From: Ashish Singh User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: "Suchi Sahoo (suchis)" References: In-Reply-To: X-Virus-Scanned: by amavisd-new at redback.com Cc: megaco@ietf.org Subject: Re: [Megaco] Does version 2 support compacted contexts in AuditValue command X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1771922643==" Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org --===============1771922643== Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit This is something that got introduced in H.248.1 v3.

Thanks
Ashish


Suchi Sahoo (suchis) wrote:
Does version 2 of H.248 support the following syntax for AuditValue?

MEGACO/2 [2.2.2.2]: 2944
Transaction = 121 {
  Context = * { ContextAttr { ContextList = { * } },
                         AuditValue = ROOT {Audit{} } } }
 
MEGACO/2 [1.1.1.1]: 2944
Reply = 121 {
  Context = * { ContextAttr { ContextList = {1,2,3,4,5,6,7 } },
                         AuditValue = ROOT {Audit{} } } }
Thanks,
Suchi 

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

--===============1771922643== 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://www.ietf.org/mailman/listinfo/megaco --===============1771922643==-- From megaco-bounces@ietf.org Tue Apr 15 00:03:58 2008 Return-Path: X-Original-To: megaco-archive@megatron.ietf.org Delivered-To: ietfarch-megaco-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A4DF28C39F; Tue, 15 Apr 2008 00:03:58 -0700 (PDT) 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 C27EC28C394 for ; Tue, 15 Apr 2008 00:03:56 -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=-0.442, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] 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 pS+vnsZH2KAp for ; Tue, 15 Apr 2008 00:03:55 -0700 (PDT) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by core3.amsl.com (Postfix) with ESMTP id 6601728C37E for ; Tue, 15 Apr 2008 00:03:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 096F3792469; Tue, 15 Apr 2008 00:04:28 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27405-10; Tue, 15 Apr 2008 00:04:27 -0700 (PDT) Received: from [155.53.44.239] (cologne.redback.com [155.53.44.239]) by prattle.redback.com (Postfix) with ESMTP id 02457792468; Tue, 15 Apr 2008 00:04:26 -0700 (PDT) Message-ID: <4804537A.3080306@redback.com> Date: Tue, 15 Apr 2008 00:04:26 -0700 From: Ashish Singh User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: George Quan References: <322CBDC9307AE449B2BBDA9BF40792EF01985B89@emailcnrd1.jnpr.net> In-Reply-To: <322CBDC9307AE449B2BBDA9BF40792EF01985B89@emailcnrd1.jnpr.net> X-Virus-Scanned: by amavisd-new at redback.com Cc: megaco@ietf.org Subject: Re: [Megaco] An issue about encoder for MEGACO X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0268864832==" Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org --===============0268864832== Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit George,

As per ABNF grammar, 1 or more of ((transactionRequest / transactionReply / transactionPending / transactionResponseAck /

segmentReply) are allowed in a message. Here Stack has encoded 1 TransactionReply and 1 TransactionResponseAck in a H.248 message. This TransactionResponseAck is for any previous transaction (with id 1) sent by this entity.


I think this should be fine as per H.248 encoding rules.

Thanks
Ashish

Redback Networks Inc.
San Jose, CA

George Quan wrote:

Hi all:

  I found the following encoder in some vendor. I am not sure whether it is right or not. Please help me.

=====================================

MEGACO/1 [10.136.1.95]:2944

 Reply=186002{Context=-{Modify=ROOT}}

 TransactionResponseAck{1}

==========================================

 

In the packet, Both TransactionRequest and TransactionResponseAck are embedded in one message, is it right?

I look into ITU H.248.1 V3, it seems that it don't allow encoding.

Pls give me some guide.

 

BTW: the following is defined in P98, ITU H.248.1 V3.

 

transactionList = 1*(transactionRequest / transactionReply /

transactionPending / transactionResponseAck /

segmentReply)

 

thanks

George

 

 Best Regard

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

Juniper Network CN R&D Co. Ltd.

George Quan

Tel: 8610-5874-7167

Location: 7.1.301  


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

--===============0268864832== 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://www.ietf.org/mailman/listinfo/megaco --===============0268864832==-- From megaco-bounces@ietf.org Tue Apr 15 00:12:44 2008 Return-Path: X-Original-To: megaco-archive@megatron.ietf.org Delivered-To: ietfarch-megaco-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF1C73A6AD5; Tue, 15 Apr 2008 00:12:44 -0700 (PDT) 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 E45823A6AD5 for ; Tue, 15 Apr 2008 00:12:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.489 X-Spam-Level: X-Spam-Status: No, score=-4.489 tagged_above=-999 required=5 tests=[AWL=-1.225, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, 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 A97HBjtCziFp for ; Tue, 15 Apr 2008 00:12:41 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by core3.amsl.com (Postfix) with ESMTP id 512C03A6A91 for ; Tue, 15 Apr 2008 00:12:41 -0700 (PDT) Received: from source ([66.129.224.36]) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP; Tue, 15 Apr 2008 00:13:13 PDT Received: from emailcnrd1.jnpr.net ([10.208.0.15]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Apr 2008 00:13:07 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 15 Apr 2008 15:12:59 +0800 Message-ID: <322CBDC9307AE449B2BBDA9BF40792EF01985B99@emailcnrd1.jnpr.net> In-Reply-To: <4804537A.3080306@redback.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Megaco] An issue about encoder for MEGACO Thread-Index: AciexvQxl+EinBOgQX6gihDxLIiHuQAAD1Eg References: <322CBDC9307AE449B2BBDA9BF40792EF01985B89@emailcnrd1.jnpr.net> <4804537A.3080306@redback.com> From: "George Quan" To: "Ashish Singh" X-OriginalArrivalTime: 15 Apr 2008 07:13:07.0566 (UTC) FILETIME=[27A260E0:01C89EC8] Cc: megaco@ietf.org Subject: Re: [Megaco] An issue about encoder for MEGACO X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0330247332==" Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org This is a multi-part message in MIME format. --===============0330247332== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C89EC8.22D65E43" This is a multi-part message in MIME format. ------_=_NextPart_001_01C89EC8.22D65E43 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hi Ashish: Thanks a lot.=20 I saw that ITU H.248 V1 has not defined some rules. Would you tell me = which document define the rule? I think it is reasonable, however, I am = working for a MEGACO decoder, I need get more information about the = case.=20 Thanks again George=20 =20 =20 ________________________________ From: Ashish Singh [mailto:ashishs@redback.com]=20 Sent: 2008=C4=EA4=D4=C215=C8=D5 15:04 To: George Quan Cc: megaco@ietf.org Subject: Re: [Megaco] An issue about encoder for MEGACO =20 George, As per ABNF grammar, 1 or more of ((transactionRequest / = transactionReply / transactionPending / transactionResponseAck /=20 segmentReply) are allowed in a message. Here Stack has encoded 1 = TransactionReply and 1 TransactionResponseAck in a H.248 message. This = TransactionResponseAck is for any previous transaction (with id 1) sent = by this entity.=20 =20 I think this should be fine as per H.248 encoding rules. Thanks Ashish Redback Networks Inc. San Jose, CA George Quan wrote:=20 Hi all: I found the following encoder in some vendor. I am not sure whether it = is right or not. Please help me.=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D MEGACO/1 [10.136.1.95]:2944=20 Reply=3D186002{Context=3D-{Modify=3DROOT}} TransactionResponseAck{1} =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 In the packet, Both TransactionRequest and TransactionResponseAck are = embedded in one message, is it right?=20 I look into ITU H.248.1 V3, it seems that it don't allow encoding.=20 Pls give me some guide. =20 BTW: the following is defined in P98, ITU H.248.1 V3. =20 transactionList =3D 1*(transactionRequest / transactionReply / transactionPending / transactionResponseAck / segmentReply)=20 =20 thanks=20 George =20 Best Regard ------------------------------------------- Juniper Network CN R&D Co. Ltd. George Quan=20 Tel: 8610-5874-7167 Location: 7.1.301 =20 =20 ________________________________ =20 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www.ietf.org/mailman/listinfo/megaco =20 =20 ------_=_NextPart_001_01C89EC8.22D65E43 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi = Ashish:

   Thanks a lot. =

I saw that ITU H.248 V1 has not defined some rules.  Would you tell me = which document define the rule? I think it is reasonable, however, I am working for a = MEGACO decoder, I need get more information about the case. =

Thanks again

George =

 

 

From: Ashish Singh = [mailto:ashishs@redback.com]
Sent: = 2008=C4=EA4=D4=C215=C8=D5 15:04
To: George Quan
Cc: megaco@ietf.org
Subject: Re: [Megaco] An = issue about encoder for MEGACO

 

George,

As per ABNF grammar, 1 or more of ((transactionRequest / transactionReply / transactionPending / transactionResponseAck = /

segmentReply) are allowed in a message. Here Stack = has encoded 1 TransactionReply and 1 TransactionResponseAck in a H.248 = message. This TransactionResponseAck is for any previous transaction (with id 1) = sent by this entity.

 

I think this should be fine as = per H.248 encoding rules.

Thanks
Ashish

Redback Networks Inc.
San Jose, = CA

George Quan wrote:

Hi = all:

  I found the = following encoder in some vendor. I am not sure whether it is right or not. Please help = me.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D

MEGACO/1 [10.136.1.95]:2944 =

 Reply=3D186002{Context= =3D-{Modify=3DROOT}}

 TransactionResponseAck= {1}

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D

 

In the packet, Both TransactionRequest and TransactionResponseAck are embedded in one = message, is it right?

I look into ITU H.248.1 V3, = it seems that it don't allow encoding.

Pls give me some = guide.

 

BTW: the following is = defined in P98, ITU H.248.1 V3.

 

transactionList =3D 1*(transactionRequest / transactionReply = /

transactionPending / transactionResponseAck /

segmentReply) =

 

thanks =

George

 

 Best Regard

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

Juniper Network CN = R&D Co. Ltd.

George Quan =

Tel: = 8610-5874-7167

Location: 7.1.301 =  

 






 
______________________________________________=
_
Megaco mailing =
list
Megaco@ietf.org
https://www.ietf.or=
g/mailman/listinfo/megaco
 

 

------_=_NextPart_001_01C89EC8.22D65E43-- --===============0330247332== 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://www.ietf.org/mailman/listinfo/megaco --===============0330247332==-- From megaco-bounces@ietf.org Tue Apr 15 02:53:15 2008 Return-Path: X-Original-To: megaco-archive@megatron.ietf.org Delivered-To: ietfarch-megaco-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE0AF3A6C02; Tue, 15 Apr 2008 02:53:15 -0700 (PDT) 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 3F6343A6DEB for ; Tue, 15 Apr 2008 02:53:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=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 bLf34mkBYM9n for ; Tue, 15 Apr 2008 02:53:10 -0700 (PDT) Received: from mailrelay2.alcatel.de (mailrelay2.alcatel.de [194.113.59.96]) by core3.amsl.com (Postfix) with ESMTP id 0F3993A6845 for ; Tue, 15 Apr 2008 02:53:09 -0700 (PDT) Received: from [149.204.77.58] (destgn0t08099.ad1.ad.alcatel.com [149.204.77.58]) by mailrelay2.alcatel.de (8.13.8/8.13.8/ICT) with ESMTP id m3F9rbLj016656; Tue, 15 Apr 2008 11:53:37 +0200 Message-ID: <48047B20.7060509@alcatel-lucent.de> Date: Tue, 15 Apr 2008 11:53:36 +0200 From: Carsten Waitzmann User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Elad Chomsky References: In-Reply-To: X-Scanned-By: MIMEDefang 2.57 on 149.204.45.73 Cc: megaco@ietf.org Subject: Re: [Megaco] Version of "Disconnected" ServiceChange messages X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org Hello Elad, I think that's a valid point. According to H.248 Sup.7 "renewal" is considered as follows: The term =93refreshment=94 (also known as =93renewal=94) of an H.248 CA is related to the application of ServiceChange method and reason combination of {Disconnected, #900}. CA refreshment is characterized by situations of a previous existing CA, a subsequent short-term interruption, and then a continuation of the previous CA without any MG (re-)registration step(s). Furthermore, F.3.6 says that the original H.248 CA is terminated whenever the MG attempts to re-register with another MGC ("failover"). As at that point the original H.248 CA is terminated, it cannot be renewed anymore and therefore a new CA has to be established. In other words, the scenario escalates from "lost communication" to "lost control association". Thus I think it would be appropriate to say that in a second (third, ..) round when the MG tries to re-register with the MGC of the original CA, the MG will use SC method "restart". I don't think that "disconnected/900" should be admitted as mean for re-registration. best regards Carsten Elad Chomsky wrote: > Hello H.248 heavyweights, > = > I have a question regarding the H.248 version that should be used when > encoding a "Disconnected" ServiceChange request. > = > The way an MG utilizes "Disconnected" ServiceChange requests is > described under Annex F.3.6 of H.248.1: > = > 1/ When an MG detects that it became disconnected from its MGC, it tries > to re-establish its control-association by sending a "Disconnected" > ServiceChange request to that MGC. If the MGC replies to request, the > control-association continues without interruption. > = > 2/ If the MGC fails to reply to the ServiceChange request above, the MG > starts traversing its list of possible MGCs and tries registering with > each of them. The MG will use a "Disconnected" ServiceChange when trying > to register with the original MGC and a "Failover" ServiceChange when > trying to register with any other MGC. > = > 3/ The control-association is terminated as soon as the MG sends a > "Failover" ServiceChange request to an MGC. > = > Now according to (2) above, the "Disconnected" ServiceChange can be > considered as a registration. Therefore, according to clause 11.3 of > H.248.1, it must be encoded according as a version 1 message. However it > also appears that in (1) above, the "Disconnected" ServiceChange is sent > over an existing control-association; and therefore should be encoded > according to the association's negotiated version. = > = > Is this the correct interpretation? I.e. Must a "Disconnected" > ServiceChange be encoded using version 1 if no control association > exists and using the negotiated version if a control-association exists? > Or should one of these versions always be used? > = > Many thanks in advance, > Elad Chomsky > = > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www.ietf.org/mailman/listinfo/megaco > = -- = Alcatel-Lucent Deutschland AG Sitz der Gesellschaft: Stuttgart - Amtsgericht Stuttgart HRB 4026 Vorsitzender des Aufsichtsrats: Michael Oppenhoff Vorstand: Wolfgang Weik (Vors.), Dr. Rainer Fechner, Juergen Poesinger, Alf Henryk Wulf _______________________________________________ Megaco mailing list Megaco@ietf.org https://www.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Tue Apr 15 03:27:19 2008 Return-Path: X-Original-To: megaco-archive@megatron.ietf.org Delivered-To: ietfarch-megaco-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82A123A6DFE; Tue, 15 Apr 2008 03:27:19 -0700 (PDT) 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 196E73A6D89 for ; Tue, 15 Apr 2008 03:27:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 fioTnekHEjM0 for ; Tue, 15 Apr 2008 03:27:15 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by core3.amsl.com (Postfix) with ESMTP id EAF903A6DFE for ; Tue, 15 Apr 2008 03:27:14 -0700 (PDT) Received: from source ([66.129.224.36]) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP; Tue, 15 Apr 2008 03:26:45 PDT Received: from emailfeemea1.jnpr.net ([172.26.192.140]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 15 Apr 2008 03:26:42 -0700 Received: from emailemea6.jnpr.net ([172.26.192.141]) by emailfeemea1.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 15 Apr 2008 11:26:39 +0100 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7235.2 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 15 Apr 2008 11:26:33 +0100 Message-ID: In-Reply-To: <48047B20.7060509@alcatel-lucent.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Megaco] Version of "Disconnected" ServiceChange messages Thread-Index: Acie3ppqY+CMVMHJTdCAOcjqkv8ySAAAhb1Q References: <48047B20.7060509@alcatel-lucent.de> From: "Elad Chomsky" To: "Carsten Waitzmann" X-OriginalArrivalTime: 15 Apr 2008 10:26:39.0238 (UTC) FILETIME=[30BAEA60:01C89EE3] Cc: megaco@ietf.org Subject: Re: [Megaco] Version of "Disconnected" ServiceChange messages X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org Hello Carsten, Like you, I dislike the fact that the same method/reason combination, "Disconnected/900" is used both to renew a control association and to re-register once that control association was terminated. However changing this behavior will require making a change to Annex F.3.6. Currently this annex clearly states that: "If the MG exhausts its list of MGCs without successfully establishing a control association, the MG waits a random amount of time and then attempts registration with the MGCs in its list again, starting with the MGC from the original control association. The MG will send a ServiceChange with a ServiceChangeMethod of "Disconnected" to the MGC from the original control association each time the MG attempts to contact it." So, "Disconnected/900" is clearly used for re-registration as well. If this behavior is changed, I would suggest that re-registration will use "Failover/909". I see little reason to differentiate between the original MGC and all others once the control association is terminated. I would still be really grateful for any views regarding the H.248 version that should be used when encoding the two types of "Disconnected/900" (i.e. the "renew" one and the "re-register" one). This point is actually causing us some interoperability problems. Many thanks, Elad -----Original Message----- From: Carsten Waitzmann [mailto:cwaitzmann@alcatel-lucent.de] Sent: Tuesday, April 15, 2008 12:54 PM To: Elad Chomsky Cc: megaco@ietf.org Subject: Re: [Megaco] Version of "Disconnected" ServiceChange messages Hello Elad, I think that's a valid point. According to H.248 Sup.7 "renewal" is considered as follows: The term "refreshment" (also known as "renewal") of an H.248 CA is related to the application of ServiceChange method and reason combination of {Disconnected, #900}. CA refreshment is characterized by situations of a previous existing CA, a subsequent short-term interruption, and then a continuation of the previous CA without any MG (re-)registration step(s). Furthermore, F.3.6 says that the original H.248 CA is terminated whenever the MG attempts to re-register with another MGC ("failover"). As at that point the original H.248 CA is terminated, it cannot be renewed anymore and therefore a new CA has to be established. In other words, the scenario escalates from "lost communication" to "lost control association". Thus I think it would be appropriate to say that in a second (third, ..) round when the MG tries to re-register with the MGC of the original CA, the MG will use SC method "restart". I don't think that "disconnected/900" should be admitted as mean for re-registration. best regards Carsten Elad Chomsky wrote: > Hello H.248 heavyweights, > > I have a question regarding the H.248 version that should be used when > encoding a "Disconnected" ServiceChange request. > > The way an MG utilizes "Disconnected" ServiceChange requests is > described under Annex F.3.6 of H.248.1: > > 1/ When an MG detects that it became disconnected from its MGC, it tries > to re-establish its control-association by sending a "Disconnected" > ServiceChange request to that MGC. If the MGC replies to request, the > control-association continues without interruption. > > 2/ If the MGC fails to reply to the ServiceChange request above, the MG > starts traversing its list of possible MGCs and tries registering with > each of them. The MG will use a "Disconnected" ServiceChange when trying > to register with the original MGC and a "Failover" ServiceChange when > trying to register with any other MGC. > > 3/ The control-association is terminated as soon as the MG sends a > "Failover" ServiceChange request to an MGC. > > Now according to (2) above, the "Disconnected" ServiceChange can be > considered as a registration. Therefore, according to clause 11.3 of > H.248.1, it must be encoded according as a version 1 message. However it > also appears that in (1) above, the "Disconnected" ServiceChange is sent > over an existing control-association; and therefore should be encoded > according to the association's negotiated version. > > Is this the correct interpretation? I.e. Must a "Disconnected" > ServiceChange be encoded using version 1 if no control association > exists and using the negotiated version if a control-association exists? > Or should one of these versions always be used? > > Many thanks in advance, > Elad Chomsky > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www.ietf.org/mailman/listinfo/megaco > -- Alcatel-Lucent Deutschland AG Sitz der Gesellschaft: Stuttgart - Amtsgericht Stuttgart HRB 4026 Vorsitzender des Aufsichtsrats: Michael Oppenhoff Vorstand: Wolfgang Weik (Vors.), Dr. Rainer Fechner, Juergen Poesinger, Alf Henryk Wulf _______________________________________________ Megaco mailing list Megaco@ietf.org https://www.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Tue Apr 15 08:41:36 2008 Return-Path: X-Original-To: megaco-archive@megatron.ietf.org Delivered-To: ietfarch-megaco-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED9F53A6B2A; Tue, 15 Apr 2008 08:41:36 -0700 (PDT) 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 517B93A6C62 for ; Tue, 15 Apr 2008 08:41:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.442 X-Spam-Level: X-Spam-Status: No, score=-4.442 tagged_above=-999 required=5 tests=[AWL=2.157, BAYES_00=-2.599, 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 vwFdmymYZxJb for ; Tue, 15 Apr 2008 08:41:35 -0700 (PDT) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id EB7853A6B2A for ; Tue, 15 Apr 2008 08:41:34 -0700 (PDT) Received: from zrtphxm2.corp.nortel.com (zrtphxm2.corp.nortel.com [47.140.202.51]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m3FFg2t02341; Tue, 15 Apr 2008 15:42:02 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 15 Apr 2008 11:42:00 -0400 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA41484D819@zrtphxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Megaco] Version of "Disconnected" ServiceChange messages Thread-Index: Acie3ppqY+CMVMHJTdCAOcjqkv8ySAAAhb1QAAti1EA= References: <48047B20.7060509@alcatel-lucent.de> From: "Kevin Boyle" To: "Elad Chomsky" , "Carsten Waitzmann" Cc: megaco@ietf.org Subject: Re: [Megaco] Version of "Disconnected" ServiceChange messages X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org I believe that this is being made far more complicated than it was intended to be. The wording about "terminating" the control association was put in place because there has to be some point when the MG stops listening to the original association in order to establish a new one. But if no one else accepts the registration, why can't the original be "picked back up"? The MGC from the previous control association would still think it was the same control association. The intent of Disconnected has always been that the comms were lost on the control association and they are being reestablished. Given this, it is not actually a re-registration. Registration to establish a new control association must always use version 1. This is to allow version negotiation to take place at the lowest common denominator, as support of later versions implies support of earlier versions. Disconnected is not establishing a new control association, but is repairing one that was the subject of comms loss. This means that the Disconnected should be encoded per the version negotiated on the previous control association between the two entities. If the MG wishes to renegotiate the version, then it can do so once comms are re-established. Kevin -----Original Message----- From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf Of Elad Chomsky Sent: Tuesday, April 15, 2008 6:27 AM To: Carsten Waitzmann Cc: megaco@ietf.org Subject: Re: [Megaco] Version of "Disconnected" ServiceChange messages Hello Carsten, Like you, I dislike the fact that the same method/reason combination, "Disconnected/900" is used both to renew a control association and to re-register once that control association was terminated. However changing this behavior will require making a change to Annex F.3.6. Currently this annex clearly states that: "If the MG exhausts its list of MGCs without successfully establishing a control association, the MG waits a random amount of time and then attempts registration with the MGCs in its list again, starting with the MGC from the original control association. The MG will send a ServiceChange with a ServiceChangeMethod of "Disconnected" to the MGC from the original control association each time the MG attempts to contact it." So, "Disconnected/900" is clearly used for re-registration as well. If this behavior is changed, I would suggest that re-registration will use "Failover/909". I see little reason to differentiate between the original MGC and all others once the control association is terminated. I would still be really grateful for any views regarding the H.248 version that should be used when encoding the two types of "Disconnected/900" (i.e. the "renew" one and the "re-register" one). This point is actually causing us some interoperability problems. Many thanks, Elad -----Original Message----- From: Carsten Waitzmann [mailto:cwaitzmann@alcatel-lucent.de] Sent: Tuesday, April 15, 2008 12:54 PM To: Elad Chomsky Cc: megaco@ietf.org Subject: Re: [Megaco] Version of "Disconnected" ServiceChange messages Hello Elad, I think that's a valid point. According to H.248 Sup.7 "renewal" is considered as follows: The term "refreshment" (also known as "renewal") of an H.248 CA is related to the application of ServiceChange method and reason combination of {Disconnected, #900}. CA refreshment is characterized by situations of a previous existing CA, a subsequent short-term interruption, and then a continuation of the previous CA without any MG (re-)registration step(s). Furthermore, F.3.6 says that the original H.248 CA is terminated whenever the MG attempts to re-register with another MGC ("failover"). As at that point the original H.248 CA is terminated, it cannot be renewed anymore and therefore a new CA has to be established. In other words, the scenario escalates from "lost communication" to "lost control association". Thus I think it would be appropriate to say that in a second (third, ..) round when the MG tries to re-register with the MGC of the original CA, the MG will use SC method "restart". I don't think that "disconnected/900" should be admitted as mean for re-registration. best regards Carsten Elad Chomsky wrote: > Hello H.248 heavyweights, > > I have a question regarding the H.248 version that should be used when > encoding a "Disconnected" ServiceChange request. > > The way an MG utilizes "Disconnected" ServiceChange requests is > described under Annex F.3.6 of H.248.1: > > 1/ When an MG detects that it became disconnected from its MGC, it tries > to re-establish its control-association by sending a "Disconnected" > ServiceChange request to that MGC. If the MGC replies to request, the > control-association continues without interruption. > > 2/ If the MGC fails to reply to the ServiceChange request above, the MG > starts traversing its list of possible MGCs and tries registering with > each of them. The MG will use a "Disconnected" ServiceChange when trying > to register with the original MGC and a "Failover" ServiceChange when > trying to register with any other MGC. > > 3/ The control-association is terminated as soon as the MG sends a > "Failover" ServiceChange request to an MGC. > > Now according to (2) above, the "Disconnected" ServiceChange can be > considered as a registration. Therefore, according to clause 11.3 of > H.248.1, it must be encoded according as a version 1 message. However it > also appears that in (1) above, the "Disconnected" ServiceChange is sent > over an existing control-association; and therefore should be encoded > according to the association's negotiated version. > > Is this the correct interpretation? I.e. Must a "Disconnected" > ServiceChange be encoded using version 1 if no control association > exists and using the negotiated version if a control-association exists? > Or should one of these versions always be used? > > Many thanks in advance, > Elad Chomsky > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www.ietf.org/mailman/listinfo/megaco > -- Alcatel-Lucent Deutschland AG Sitz der Gesellschaft: Stuttgart - Amtsgericht Stuttgart HRB 4026 Vorsitzender des Aufsichtsrats: Michael Oppenhoff Vorstand: Wolfgang Weik (Vors.), Dr. Rainer Fechner, Juergen Poesinger, Alf Henryk Wulf _______________________________________________ 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 megaco-bounces@ietf.org Tue Apr 15 14:17:25 2008 Return-Path: X-Original-To: megaco-archive@megatron.ietf.org Delivered-To: ietfarch-megaco-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93C5D3A6F57; Tue, 15 Apr 2008 14:17:25 -0700 (PDT) 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 A104A3A6F51 for ; Tue, 15 Apr 2008 14:17:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 Dv3kcxfa8anI for ; Tue, 15 Apr 2008 14:17:22 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by core3.amsl.com (Postfix) with ESMTP id 52A833A6BD7 for ; Tue, 15 Apr 2008 14:17:22 -0700 (PDT) Received: from source ([66.129.224.36]) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP; Tue, 15 Apr 2008 14:17:48 PDT Received: from emailfeemea1.jnpr.net ([172.26.192.140]) by gamma.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Apr 2008 14:16:50 -0700 Received: from emailemea6.jnpr.net ([172.26.192.141]) by emailfeemea1.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 15 Apr 2008 22:16:47 +0100 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7235.2 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 15 Apr 2008 22:16:42 +0100 Message-ID: In-Reply-To: <34B3EAA5B3066A42914D28C5ECF5FEA41484D819@zrtphxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Megaco] Version of "Disconnected" ServiceChange messages Thread-Index: Acie3ppqY+CMVMHJTdCAOcjqkv8ySAAAhb1QAAti1EAAAIXqwA== References: <48047B20.7060509@alcatel-lucent.de> <34B3EAA5B3066A42914D28C5ECF5FEA41484D819@zrtphxm2.corp.nortel.com> From: "Elad Chomsky" To: "Kevin Boyle" , "Carsten Waitzmann" X-OriginalArrivalTime: 15 Apr 2008 21:16:47.0859 (UTC) FILETIME=[03AE1C30:01C89F3E] Cc: megaco@ietf.org Subject: Re: [Megaco] Version of "Disconnected" ServiceChange messages X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org Hello Kevin, If I understand you correctly, it would seem that my original understanding of Annex F.3.6 was very different from its original intent. I would be very grateful if I could run by you what I infer from your response (below); just to make sure I got it right this time: ---------- An MG can detect a disconnection of the control-association; for example, through the timing-out of an MG initiated transaction. When the MG detects such a disconnection, it still considers the control-association as active. It handles any requests received on that control-association normally; and issues Notify requests over it when events are detected. However it will also send a "Disconnected/900" ServiceChange on the control-association; to inform the MGC that there was a temporary interruption of the connection. If the MGC fails to respond to the "Disconnected/900" ServiceChange request (i.e. this request also times-out), the MG considers the control association as down. It will no longer accept requests received on this control-association. Instead it will try registering with other MGCs using a "Failover/909" ServiceChange. Whenever its configuration indicates that it should try registering with the original MGC, it would instead try to renew the original control-association using a "Disconnecetd/900" request. Note that this "renewing" is not a registration; i.e. the MG never tries to re-register with the original MGC. ---------- If this is correct, what error should the MGC return when it receives a "Disconnected/900" ServiceChange but knows nothing about an existing control-association? Some error must be returned, as otherwise the MG will never be able to connect with that MGC. Thanks, Elad -----Original Message----- From: Kevin Boyle [mailto:kboyle@nortel.com] Sent: Tuesday, April 15, 2008 6:42 PM To: Elad Chomsky; Carsten Waitzmann Cc: megaco@ietf.org Subject: RE: [Megaco] Version of "Disconnected" ServiceChange messages I believe that this is being made far more complicated than it was intended to be. The wording about "terminating" the control association was put in place because there has to be some point when the MG stops listening to the original association in order to establish a new one. But if no one else accepts the registration, why can't the original be "picked back up"? The MGC from the previous control association would still think it was the same control association. The intent of Disconnected has always been that the comms were lost on the control association and they are being reestablished. Given this, it is not actually a re-registration. Registration to establish a new control association must always use version 1. This is to allow version negotiation to take place at the lowest common denominator, as support of later versions implies support of earlier versions. Disconnected is not establishing a new control association, but is repairing one that was the subject of comms loss. This means that the Disconnected should be encoded per the version negotiated on the previous control association between the two entities. If the MG wishes to renegotiate the version, then it can do so once comms are re-established. Kevin -----Original Message----- From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf Of Elad Chomsky Sent: Tuesday, April 15, 2008 6:27 AM To: Carsten Waitzmann Cc: megaco@ietf.org Subject: Re: [Megaco] Version of "Disconnected" ServiceChange messages Hello Carsten, Like you, I dislike the fact that the same method/reason combination, "Disconnected/900" is used both to renew a control association and to re-register once that control association was terminated. However changing this behavior will require making a change to Annex F.3.6. Currently this annex clearly states that: "If the MG exhausts its list of MGCs without successfully establishing a control association, the MG waits a random amount of time and then attempts registration with the MGCs in its list again, starting with the MGC from the original control association. The MG will send a ServiceChange with a ServiceChangeMethod of "Disconnected" to the MGC from the original control association each time the MG attempts to contact it." So, "Disconnected/900" is clearly used for re-registration as well. If this behavior is changed, I would suggest that re-registration will use "Failover/909". I see little reason to differentiate between the original MGC and all others once the control association is terminated. I would still be really grateful for any views regarding the H.248 version that should be used when encoding the two types of "Disconnected/900" (i.e. the "renew" one and the "re-register" one). This point is actually causing us some interoperability problems. Many thanks, Elad -----Original Message----- From: Carsten Waitzmann [mailto:cwaitzmann@alcatel-lucent.de] Sent: Tuesday, April 15, 2008 12:54 PM To: Elad Chomsky Cc: megaco@ietf.org Subject: Re: [Megaco] Version of "Disconnected" ServiceChange messages Hello Elad, I think that's a valid point. According to H.248 Sup.7 "renewal" is considered as follows: The term "refreshment" (also known as "renewal") of an H.248 CA is related to the application of ServiceChange method and reason combination of {Disconnected, #900}. CA refreshment is characterized by situations of a previous existing CA, a subsequent short-term interruption, and then a continuation of the previous CA without any MG (re-)registration step(s). Furthermore, F.3.6 says that the original H.248 CA is terminated whenever the MG attempts to re-register with another MGC ("failover"). As at that point the original H.248 CA is terminated, it cannot be renewed anymore and therefore a new CA has to be established. In other words, the scenario escalates from "lost communication" to "lost control association". Thus I think it would be appropriate to say that in a second (third, ..) round when the MG tries to re-register with the MGC of the original CA, the MG will use SC method "restart". I don't think that "disconnected/900" should be admitted as mean for re-registration. best regards Carsten Elad Chomsky wrote: > Hello H.248 heavyweights, > > I have a question regarding the H.248 version that should be used when > encoding a "Disconnected" ServiceChange request. > > The way an MG utilizes "Disconnected" ServiceChange requests is > described under Annex F.3.6 of H.248.1: > > 1/ When an MG detects that it became disconnected from its MGC, it tries > to re-establish its control-association by sending a "Disconnected" > ServiceChange request to that MGC. If the MGC replies to request, the > control-association continues without interruption. > > 2/ If the MGC fails to reply to the ServiceChange request above, the MG > starts traversing its list of possible MGCs and tries registering with > each of them. The MG will use a "Disconnected" ServiceChange when trying > to register with the original MGC and a "Failover" ServiceChange when > trying to register with any other MGC. > > 3/ The control-association is terminated as soon as the MG sends a > "Failover" ServiceChange request to an MGC. > > Now according to (2) above, the "Disconnected" ServiceChange can be > considered as a registration. Therefore, according to clause 11.3 of > H.248.1, it must be encoded according as a version 1 message. However it > also appears that in (1) above, the "Disconnected" ServiceChange is sent > over an existing control-association; and therefore should be encoded > according to the association's negotiated version. > > Is this the correct interpretation? I.e. Must a "Disconnected" > ServiceChange be encoded using version 1 if no control association > exists and using the negotiated version if a control-association exists? > Or should one of these versions always be used? > > Many thanks in advance, > Elad Chomsky > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www.ietf.org/mailman/listinfo/megaco > -- Alcatel-Lucent Deutschland AG Sitz der Gesellschaft: Stuttgart - Amtsgericht Stuttgart HRB 4026 Vorsitzender des Aufsichtsrats: Michael Oppenhoff Vorstand: Wolfgang Weik (Vors.), Dr. Rainer Fechner, Juergen Poesinger, Alf Henryk Wulf _______________________________________________ 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 megaco-bounces@ietf.org Wed Apr 16 00:06:01 2008 Return-Path: X-Original-To: megaco-archive@megatron.ietf.org Delivered-To: ietfarch-megaco-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F7903A6C6E; Wed, 16 Apr 2008 00:06:00 -0700 (PDT) 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 649CC3A6BCA for ; Wed, 16 Apr 2008 00:05:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=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 0F46dvcRrayx for ; Wed, 16 Apr 2008 00:05:46 -0700 (PDT) Received: from jaguar.aricent.com (jaguar.aricent.com [61.246.186.17]) by core3.amsl.com (Postfix) with ESMTP id 594E528C35C for ; Wed, 16 Apr 2008 00:05:40 -0700 (PDT) Received: from jaguar.aricent.com (localhost [127.0.0.1]) by jaguar.aricent.com (8.13.8/8.13.8) with ESMTP id m3G6pXJu016732 for ; Wed, 16 Apr 2008 12:21:33 +0530 Received: from webmail.asian.ad.aricent.com (webmail [10.203.158.17]) by jaguar.aricent.com (8.13.8/8.13.8) with ESMTP id m3G6pWh8016700 for ; Wed, 16 Apr 2008 12:21:33 +0530 Received: from GUREXHT02.ASIAN.AD.ARICENT.COM ([10.203.171.138]) by sandesh.gur.aricent.com (Lotus Domino Release 6.5.5) with ESMTP id 2008041612360883-82552 ; Wed, 16 Apr 2008 12:36:08 +0530 Received: from GUREXMB01.asian.ad.aricent.com ([10.203.171.130]) by GUREXHT02.ASIAN.AD.ARICENT.COM ([10.203.171.138]) with mapi; Wed, 16 Apr 2008 12:36:10 +0530 From: "suruchi.agarwal" To: "megaco@ietf.org" Date: Wed, 16 Apr 2008 12:36:08 +0530 Thread-Topic: [Megaco] Discrepancy in possible values of parameter of Indicator package recommended in ITU-T Rec. H.248.3 Thread-Index: AcifkFhTKLcY4o5dSEyEHMtMHP09jQ== Message-ID: <4E23C25C25B2A848A7E71742E9420B430206996195@GUREXMB01.ASIAN.AD.ARICENT.COM> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-MIMETrack: Itemize by SMTP Server on Sandesh/HSS(Release 6.5.5|November 30, 2005) at 16/04/2008 12:36:08 PM, Serialize by Router on WebMail/HSS(Build V655_10312005|October 31, 2005) at 04/16/2008 12:36:12 PM, Serialize complete at 04/16/2008 12:36:12 PM Content-Language: en-US Subject: [Megaco] Discrepancy in possible values of parameter of Indicator package recommended in ITU-T Rec. H.248.3 X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0952820882==" Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org --===============0952820882== Content-Type: multipart/alternative; boundary="_000_4E23C25C25B2A848A7E71742E9420B430206996195GUREXMB01ASIA_" Content-Language: en-US --_000_4E23C25C25B2A848A7E71742E9420B430206996195GUREXMB01ASIA_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" Hi, There is a discrepancy in the possible values of "Indid" parameter of "Seti= ndactor" signal of "Indicator" package recommended in the ITU-T Rec. H.248.= 3. The "Set of line indicators" for the parameter "Indid" are having values "l= 001-l999 (0x0003-0x03f9)". In decimal number notation, this range corresponds to 999 values while in h= exadecimal notation, this range corresponds to1015 values. In my opinion, the hexadecimal notation should also correspond to 999 value= s, i.e., it should be "l001-l999 (0x0003-0x03e9)". The hexadecimal notation of subsequent values should also be updated accord= ingly. Thanks, With Best Regards, Suruchi --_000_4E23C25C25B2A848A7E71742E9420B430206996195GUREXMB01ASIA_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="us-ascii"

Hi,

There is a discrepancy in the possible values of "Indid" paramete= r of "Setindactor" signal of "Indicator" package recommended= in the ITU-T Rec. H.248.3.

The "Set of line indicators" for the parameter "Indid" = are having values "l001-l999 (0x0003-0x03f9)".
In decimal number notation, this range corresponds to 999 values while in hexadecimal notation, this range corresponds to1015 values.

In my opinion, the hexadecimal notation should also correspond to 999 value= s, i.e., it should be "l001-l999 (0x0003-0x03e9)".=

The hexadecimal notation of subsequent values should also be update= d accordingly.

Thanks,
With Best Regards,
Suruchi

--_000_4E23C25C25B2A848A7E71742E9420B430206996195GUREXMB01ASIA_-- --===============0952820882== 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://www.ietf.org/mailman/listinfo/megaco --===============0952820882==-- From megaco-bounces@ietf.org Wed Apr 16 09:02:41 2008 Return-Path: X-Original-To: megaco-archive@megatron.ietf.org Delivered-To: ietfarch-megaco-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7855028C252; Wed, 16 Apr 2008 09:02:41 -0700 (PDT) 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 9687428C2FE for ; Wed, 16 Apr 2008 09:02:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 0ryEjMhGdJTO for ; Wed, 16 Apr 2008 09:02:31 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by core3.amsl.com (Postfix) with ESMTP id 5937B28C247 for ; Wed, 16 Apr 2008 09:02:26 -0700 (PDT) Received: from source ([66.129.224.36]) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP; Wed, 16 Apr 2008 09:02:08 PDT Received: from emailfeemea2.jnpr.net ([172.26.192.142]) by gamma.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Apr 2008 08:59:50 -0700 Received: from EMAILEMEA3.jnpr.net ([172.26.192.136]) by emailfeemea2.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Apr 2008 16:59:47 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7235.2 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 16 Apr 2008 16:59:46 +0100 Message-ID: <0E48B768805E4D44A70709C8AE09209001C849AB@EMAILEMEA3.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Compact list of ContextIDs Thread-Index: Acif2uRsTFZpCGKRRw+QvbSzdg3bkQ== From: "Miri Epstein" To: "Christian Groves" X-OriginalArrivalTime: 16 Apr 2008 15:59:48.0042 (UTC) FILETIME=[E5661AA0:01C89FDA] Cc: megaco ietf Subject: [Megaco] Compact list of ContextIDs X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org Hello Christian, Regarding the following example given in H.248.1v3, section 7.2.5: The command: Context=*{ContextAttr{ContextList={*}},AuditValue=Root{Audit{}}} returns: Context=*{ContextAttr{ContextList={1,2,3,4}},AuditValue=Root{}} When looking at the ABNF for auditOther, the {} cannot be empty and must contain an auditReturnParameter: auditOther = EQUAL termIDList [LBRKT terminationAudit RBRKT] terminationAudit = auditReturnParameter *(COMMA auditReturnParameter) So the correct example should be: The command: Context=*{ContextAttr{ContextList={*}},AuditValue=Root{Audit{}}} returns: Context=*{ContextAttr{ContextList={1,2,3,4}}, AuditValue=Root} I believe this fix should be updated in H.248.1 Amendment 1. Many thanks, Miri _______________________________________________ Megaco mailing list Megaco@ietf.org https://www.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Wed Apr 16 20:29:53 2008 Return-Path: X-Original-To: megaco-archive@megatron.ietf.org Delivered-To: ietfarch-megaco-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7B473A6AD8; Wed, 16 Apr 2008 20:29:53 -0700 (PDT) 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 E3B7F3A6D2B for ; Wed, 16 Apr 2008 20:29:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.605 X-Spam-Level: X-Spam-Status: No, score=-2.605 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RELAY_IS_203=0.994] 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 JJonBh1NVcGK for ; Wed, 16 Apr 2008 20:29:52 -0700 (PDT) Received: from ipmail05.adl2.internode.on.net (ipmail05.adl2.internode.on.net [203.16.214.145]) by core3.amsl.com (Postfix) with ESMTP id B6BD03A6AD8 for ; Wed, 16 Apr 2008 20:29:51 -0700 (PDT) Received: from ppp121-44-242-176.lns4.mel4.internode.on.net (HELO [192.168.0.6]) ([121.44.242.176]) by ipmail05.adl2.internode.on.net with ESMTP; 17 Apr 2008 13:00:24 +0930 Message-ID: <4806C447.6090504@nteczone.com> Date: Thu, 17 Apr 2008 13:30:15 +1000 From: Christian Groves User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Miri Epstein References: <0E48B768805E4D44A70709C8AE09209001C849AB@EMAILEMEA3.jnpr.net> In-Reply-To: <0E48B768805E4D44A70709C8AE09209001C849AB@EMAILEMEA3.jnpr.net> Cc: megaco ietf Subject: Re: [Megaco] Compact list of ContextIDs X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org Hello Miri, For the time being we can capture this in the implementors guide. Regards, Christian Miri Epstein wrote: > Hello Christian, > > Regarding the following example given in H.248.1v3, section 7.2.5: > > The command: > > Context=*{ContextAttr{ContextList={*}},AuditValue=Root{Audit{}}} > > returns: > > Context=*{ContextAttr{ContextList={1,2,3,4}},AuditValue=Root{}} > > When looking at the ABNF for auditOther, the {} cannot be empty and must > contain an auditReturnParameter: > auditOther = EQUAL termIDList [LBRKT terminationAudit RBRKT] > terminationAudit = auditReturnParameter *(COMMA auditReturnParameter) > > So the correct example should be: > > The command: > > Context=*{ContextAttr{ContextList={*}},AuditValue=Root{Audit{}}} > > returns: > > Context=*{ContextAttr{ContextList={1,2,3,4}}, AuditValue=Root} > > > I believe this fix should be updated in H.248.1 Amendment 1. > > Many thanks, > Miri > > > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Wed Apr 16 21:03:30 2008 Return-Path: X-Original-To: megaco-archive@megatron.ietf.org Delivered-To: ietfarch-megaco-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA4D13A6F9F; Wed, 16 Apr 2008 21:03:30 -0700 (PDT) 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 7F93A3A6F27 for ; Wed, 16 Apr 2008 21:03:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.605 X-Spam-Level: X-Spam-Status: No, score=-2.605 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RELAY_IS_203=0.994] 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 fvPseUsDSiDd for ; Wed, 16 Apr 2008 21:03:28 -0700 (PDT) Received: from ipmail05.adl2.internode.on.net (ipmail05.adl2.internode.on.net [203.16.214.145]) by core3.amsl.com (Postfix) with ESMTP id 3AF6328C4DE for ; Wed, 16 Apr 2008 21:03:27 -0700 (PDT) Received: from ppp121-44-242-176.lns4.mel4.internode.on.net (HELO [192.168.0.6]) ([121.44.242.176]) by ipmail05.adl2.internode.on.net with ESMTP; 17 Apr 2008 13:34:01 +0930 Message-ID: <4806CC2B.1020503@nteczone.com> Date: Thu, 17 Apr 2008 14:03:55 +1000 From: Christian Groves User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: "suruchi.agarwal" References: <4E23C25C25B2A848A7E71742E9420B430206996195@GUREXMB01.ASIAN.AD.ARICENT.COM> In-Reply-To: <4E23C25C25B2A848A7E71742E9420B430206996195@GUREXMB01.ASIAN.AD.ARICENT.COM> Cc: "megaco@ietf.org" Subject: Re: [Megaco] Discrepancy in possible values of parameter of Indicator package recommended in ITU-T Rec. H.248.3 X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org Hello Suruchi, I'm surprised that this package is being implemented! You are correct in pointing out the problem. Given that the current parameter values are: Possible values: Name Description il (0x0001) Hold ic (0x0002) Conference l001-l999 (0x0003-0x03f9) Set of line indicators f001-f999 (0x03fa-0x07e0) Set of assignable function indicators ir (0x07e1) Ringer/Alerter indication im (0x07e2) Message waiting indicator I'll a little hesitant to agree to update all the hex values because people may have already implemented these. i.e. they may already have implemented "Message waiting indicator" using 0x07e2, without realising the problem with the set of line indicators value range. As such I don't think we should invalidate their implementations as part of the fix. So I would suggest that in the IG we say: Possible values: Name Description il (0x0001) Hold ic (0x0002) Conference l001-l999 (0x0003-0x03e9) Set of line indicators f001-f999 (0x03fa-0x07e0) Set of assignable function indicators ir (0x07e1) Ringer/Alerter indication im (0x07e2) Message waiting indicator Note: Values 0x03ea to 0x03f9 are reserved. People's thoughts? Regards, Christian suruchi.agarwal wrote: > > Hi, > > There is a discrepancy in the possible values of "Indid" parameter of > "Setindactor" signal of "Indicator" package recommended in the ITU-T > Rec. H.248.3. > > The "Set of line indicators" for the parameter "Indid" are having > values "l001-l999 (0x0003-0x03f9)". > In decimal number notation, this range corresponds to 999 values while > in hexadecimal notation, this range corresponds to1015 values. > > In my opinion, the hexadecimal notation should also correspond to 999 > values, i.e., it should be "l001-l999 (0x0003-0x03e9)". > > The hexadecimal notation of subsequent values should also be updated > accordingly. > > Thanks, > With Best Regards, > Suruchi > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 megaco-bounces@ietf.org Thu Apr 17 08:22:26 2008 Return-Path: X-Original-To: megaco-archive@megatron.ietf.org Delivered-To: ietfarch-megaco-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 792B13A6CF8; Thu, 17 Apr 2008 08:22:26 -0700 (PDT) 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 CADD328C21B for ; Thu, 17 Apr 2008 08:22:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[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 v8foAYZAGYKc for ; Thu, 17 Apr 2008 08:22:23 -0700 (PDT) Received: from smail6.alcatel.fr (gc-na5.alcatel.fr [64.208.49.5]) by core3.amsl.com (Postfix) with ESMTP id 8CADD3A6853 for ; Thu, 17 Apr 2008 08:22:22 -0700 (PDT) Received: from FRVELSBHS04.ad2.ad.alcatel.com (frvelsbhs04.ad2.ad.alcatel.com [155.132.6.76]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id m3HFFh9O023454; Thu, 17 Apr 2008 17:15:43 +0200 Received: from FRVELSMBS23.ad2.ad.alcatel.com ([155.132.6.53]) by FRVELSBHS04.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Thu, 17 Apr 2008 17:22:58 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 17 Apr 2008 17:22:57 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Formal specification & Panacea for ServiceChange logic; RE: [Megaco] Version of "Disconnected" ServiceChange messages Thread-Index: Acie3ppqY+CMVMHJTdCAOcjqkv8ySAAAhb1QAAti1EAAAIXqwABgQ/eQAAKb8MA= From: "Schwarz Albrecht" To: "Elad Chomsky" X-OriginalArrivalTime: 17 Apr 2008 15:22:58.0956 (UTC) FILETIME=[EB1814C0:01C8A09E] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Cc: megaco@ietf.org Subject: [Megaco] Formal specification & Panacea for ServiceChange logic; RE: Version of "Disconnected" ServiceChange messages X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org I got some side comments. 1) FDT (Formal Description Techniques) It is difficult to solve the logic for the use case indicated by Elad in a = manner which satisfies everyone. This is just due to the nature of the unde= rlying specification technique used in H.248 (and the majority of other pro= tocols; please note that this is not an H.248-specific issue). If you think about the problem, then it becomes obvious that we got deficie= ncies due to the prose-based specification by using current NLD-spproach (n= atural language description, see Z.450) for our H.248 protocol specificatio= n. = We got that different interpretations (not for all, but for some few Servic= eChange use cases) due to the semantical overloading of some "key" words. K= eeping the NLD-approach and trying to solve ambiguities would demand for fu= rther definitions in the "term" section (clause 3/H.248.1; e.g. defining th= e semantic of words "terminating", "commanded", etc in the context of Servi= ceChange), and additional IG clarifications. = We do that already, - but a textual (prose) change at one place might be th= en still inconsistent at other places. You know that the deficiencies of NLD may be addressed by using a FDT metho= d (formal description technique by using a formal specification language). We did discuss FDT usage for H.248 already in the past (see e.g. http://ftp= 3.itu.int/av-arch/avc-site/2005-2008/0502_Mel/AVD-2610.zip). It was just too late then, - and FDT usage needs volunteers due to the sign= ificant effort. I would support any FDT activity in H.248.1 Version 4, - but this would not= solve problems resulting from deployed H.248 implementations which followe= d a certain semantical interpretation. = 2) Stateful CA modelling Trying to solve the use case indicated by Elad could be facilitate with an = underlying state model for the Control Association. We don't have anyone so= far. We did discuss this also already a couple of times in the past, see eg. http://ftp3.itu.int/av-arch/avc-site/2005-2008/0703_She/AVD-3003.zip http://www.ietf.org/mail-archive/web/megaco/current/msg07799.html It could be worth in analyzing again a CA state model under H.248.1 Version= 4 IMO. 3) Panacea for ServiceChange We know that neither FDT usage for ServiceChange specification, nor state m= odelling the H.248 CA would lead to an entire, unambiguous specification of= the theoretical solution space. So, what would we gain then moving from NLD to FDT, and/or from stateless t= o a stateful CA model? I would say: if current NLD approach is covering (let's say) 80% of possibl= e ServiceChange scenarios, then an FDT approach would be at least also cove= r 80%, but less than 100%. However, we would got all the advantages of FDT, like e.g. automatic incons= istency detection, deadlock detection, etc. [toward to automatic code gener= ation ("manager like that, protocol implementors know the free-lunch-theore= m";-))]. This is the major advantage I see (beside the formally specified logic). 4) Probability distribution of ServiceChange procedures = Every possible ServiceChange scenario is occuring in a real deployment with= a probability between 0 and 1 (within a bounded time window). E.g., a registration procedure has a probability of 1, the scenario indicat= ed by Elad might be close to 0 (perhaps below 10^-5). We can't afford in specifying the (let's say) 20% of not yet covered (in H.= 248.1) ServiceChange procedures, if they would be related to a percentile o= f <1% of the probability distribution of theoretical ServiceChange procedur= es. I would prefer an engineering approach by either a) bundling the rare and exceptional cases, or b) mapping them on other ones, or c) breaking them (e.g. a 4-step (seldom) ServiceChange cycle could be broke= n in two 2-step cycles), = of course, on the expenses of non-optimized efficiency for such procedures. Elad, im not saying that we should keep unambiguities in our NLD-based Anne= x F, =A7 11 and =A7 7 in H.248.1 on ServiceChange. But I would wonder about the probability of your outlined SC use case? Right, estimation such a probability would be a quantitative approach for S= erviceChange. Knowing that N parties would come to N different probability estimations. We made an attempt in TISPAN by introducing quantitative modelling into Ser= viceChange (by focusing initially on so-called recovery concepts) see: 13tTD374 "WI-03051 H.248 System Management - Conclusion "MGC Out-of-Service= " - Immediate vs Delayed Failover" http://docbox.etsi.org/TISPAN/TISPAN/99-Archive/2007/50-20070514-Sophia-13t= er/13tTD374_WI-03051_H.248_System_Management_%E2%80%93_Conclusion_%E2%80%9C= MGC_Out-of-Service%E2%80%9D_%E2%80%93_Immediate_vs_Delayed_Failover.doc If you look at the Figure for "Probability model for 'unavailability' concl= usions" then you could simplify possible "proceeding decisions" by followin= g two strategies: (cold/warm) CA restart vs CA re-newal attempts (or whatev= er else). I'm convinced that quantitative estimations may solve some ServiceChange pr= oblems (of course, a mutual agreement (profile spec) need to record the ava= ilability & modelling assumptions of the involved H.248 entities of that H.= 248 domain). Best regards, Albrecht PS Just to confirm again that this email is not providing a solution proposal = for H.248.1 IG for your outlined issue ("which is valid in my understanding= "). > -----Original Message----- > From: megaco-bounces@ietf.org > [mailto:megaco-bounces@ietf.org] On Behalf Of Elad Chomsky > Sent: Dienstag, 15. April 2008 23:17 > To: Kevin Boyle; Waitzmann Carsten > Cc: megaco@ietf.org > Subject: Re: [Megaco] Version of "Disconnected" ServiceChange messages > = > Hello Kevin, > = > If I understand you correctly, it would seem that my original = > understanding of Annex F.3.6 was very different from its original = > intent. I would be very grateful if I could run by you what I infer = > from your response (below); just to make sure I got it right this = > time: > = > ---------- > = > An MG can detect a disconnection of the control-association; for = > example, through the timing-out of an MG initiated transaction. When = > the MG detects such a disconnection, it still considers the = > control-association as active. It handles any requests received on = > that control-association normally; and issues Notify requests over it = > when events are detected. > However it will also send a "Disconnected/900" > ServiceChange on the control-association; to inform the MGC that there = > was a temporary interruption of the connection. > = > If the MGC fails to respond to the "Disconnected/900" = > ServiceChange request (i.e. this request also times-out), the MG = > considers the control association as down. It will no longer accept = > requests received on this control-association. > Instead it will try registering with other MGCs using a "Failover/909" = > ServiceChange. Whenever its configuration indicates that it should try = > registering with the original MGC, it would instead try to renew the = > original control-association using a "Disconnecetd/900" request. Note = > that this "renewing" is not a registration; i.e. the MG never tries to = > re-register with the original MGC. > = > ---------- > = > If this is correct, what error should the MGC return when it receives = > a "Disconnected/900" ServiceChange but knows nothing about an existing = > control-association? Some error must be returned, as otherwise the MG = > will never be able to connect with that MGC. > = > Thanks, > Elad > = > -----Original Message----- > From: Kevin Boyle [mailto:kboyle@nortel.com] > Sent: Tuesday, April 15, 2008 6:42 PM > To: Elad Chomsky; Carsten Waitzmann > Cc: megaco@ietf.org > Subject: RE: [Megaco] Version of "Disconnected" ServiceChange messages > = > I believe that this is being made far more complicated than it was = > intended to be. > = > The wording about "terminating" the control association was put in = > place because there has to be some point when the MG stops listening = > to the original association in order to establish a new one. But if = > no one else accepts the registration, why can't the original be = > "picked back up"? > The MGC from the previous control association would still think it was = > the same control association. > = > The intent of Disconnected has always been that the comms were lost on = > the control association and they are being reestablished. Given this, = > it is not actually a re-registration. > = > Registration to establish a new control association must always use = > version 1. This is to allow version negotiation to take place at the = > lowest common denominator, as support of later versions implies = > support of earlier versions. > Disconnected is not establishing a new control association, but is = > repairing one that was the subject of comms loss. > This means that the Disconnected should be encoded per the version = > negotiated on the previous control association between the two = > entities. > If the MG wishes to renegotiate the version, then it can do so once = > comms are re-established. > = > Kevin > = > -----Original Message----- > From: megaco-bounces@ietf.org > [mailto:megaco-bounces@ietf.org] On Behalf Of Elad Chomsky > Sent: Tuesday, April 15, 2008 6:27 AM > To: Carsten Waitzmann > Cc: megaco@ietf.org > Subject: Re: [Megaco] Version of "Disconnected" ServiceChange messages > = > Hello Carsten, > = > Like you, I dislike the fact that the same method/reason combination, = > "Disconnected/900" is used both to renew a control association and to = > re-register once that control association was terminated. However = > changing this behavior will require making a change to Annex F.3.6. > Currently this annex clearly states that: > = > "If the MG exhausts its list of MGCs without successfully establishing = > a control association, the MG waits a random amount of time and then = > attempts registration with the MGCs in its list again, starting with = > the MGC from the original control association. The MG will send a = > ServiceChange with a ServiceChangeMethod of "Disconnected" to the MGC = > from the original control association each time the MG attempts to = > contact it." > = > So, "Disconnected/900" is clearly used for re-registration as well. > = > If this behavior is changed, I would suggest that re-registration will = > use "Failover/909". I see little reason to differentiate between the = > original MGC and all others once the control association is = > terminated. > = > I would still be really grateful for any views regarding the > H.248 version that should be used when encoding the two types of = > "Disconnected/900" (i.e. the "renew" one and the "re-register" one). > This point is actually causing us some interoperability problems. > = > Many thanks, > Elad > = > = > -----Original Message----- > From: Carsten Waitzmann [mailto:cwaitzmann@alcatel-lucent.de] > Sent: Tuesday, April 15, 2008 12:54 PM > To: Elad Chomsky > Cc: megaco@ietf.org > Subject: Re: [Megaco] Version of "Disconnected" ServiceChange messages > = > Hello Elad, > = > I think that's a valid point. > = > According to H.248 Sup.7 "renewal" is considered as follows: > The term "refreshment" (also known as "renewal") of an H.248 CA is = > related to the application of ServiceChange method and reason = > combination of {Disconnected, #900}. CA refreshment is characterized = > by situations of a previous existing CA, a subsequent short-term = > interruption, and then a continuation of the previous CA without any = > MG (re-)registration step(s). > = > Furthermore, F.3.6 says that the original H.248 CA is terminated = > whenever the MG attempts to re-register with another MGC ("failover"). > As at that point the original H.248 CA is terminated, it cannot be = > renewed anymore and therefore a new CA has to be established. In other = > words, the scenario escalates from "lost communication" to "lost = > control association". Thus I think it would be appropriate to say that = > in a second (third, > ..) round when the MG tries to re-register with the MGC of the = > original CA, the MG will use SC method "restart". > I don't think that "disconnected/900" should be admitted as mean for = > re-registration. > = > best regards > Carsten > = > = > = > = > Elad Chomsky wrote: > > Hello H.248 heavyweights, > > = > > I have a question regarding the H.248 version that should > be used when > = > > encoding a "Disconnected" ServiceChange request. > > = > > The way an MG utilizes "Disconnected" ServiceChange requests is = > > described under Annex F.3.6 of H.248.1: > > = > > 1/ When an MG detects that it became disconnected from its MGC, it > tries > > to re-establish its control-association by sending a "Disconnected" > > ServiceChange request to that MGC. If the MGC replies to > request, the > > control-association continues without interruption. > > = > > 2/ If the MGC fails to reply to the ServiceChange request above, the > MG > > starts traversing its list of possible MGCs and tries > registering with > = > > each of them. The MG will use a "Disconnected" ServiceChange when > trying > > to register with the original MGC and a "Failover" = > ServiceChange when > > trying to register with any other MGC. > > = > > 3/ The control-association is terminated as soon as the MG sends a = > > "Failover" ServiceChange request to an MGC. > > = > > Now according to (2) above, the "Disconnected" ServiceChange can be = > > considered as a registration. Therefore, according to > clause 11.3 of > > H.248.1, it must be encoded according as a version 1 > message. However > it > > also appears that in (1) above, the "Disconnected" ServiceChange is > sent > > over an existing control-association; and therefore should > be encoded > > according to the association's negotiated version. > > = > > Is this the correct interpretation? I.e. Must a "Disconnected" > > ServiceChange be encoded using version 1 if no control association = > > exists and using the negotiated version if a control-association > exists? > > Or should one of these versions always be used? > > = > > Many thanks in advance, > > Elad Chomsky > > = > > _______________________________________________ > > Megaco mailing list > > Megaco@ietf.org > > https://www.ietf.org/mailman/listinfo/megaco > > = > = > -- > Alcatel-Lucent Deutschland AG > Sitz der Gesellschaft: Stuttgart - Amtsgericht Stuttgart HRB > 4026 Vorsitzender des Aufsichtsrats: Michael Oppenhoff > Vorstand: Wolfgang Weik (Vors.), Dr. Rainer Fechner, Juergen = > Poesinger, Alf Henryk Wulf = > _______________________________________________ > 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 megaco-bounces@ietf.org Thu Apr 17 20:31:07 2008 Return-Path: X-Original-To: megaco-archive@megatron.ietf.org Delivered-To: ietfarch-megaco-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 858153A6A51; Thu, 17 Apr 2008 20:31:07 -0700 (PDT) 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 49AB83A68EF for ; Thu, 17 Apr 2008 20:31:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.995 X-Spam-Level: **** X-Spam-Status: No, score=4.995 tagged_above=-999 required=5 tests=[CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MSGID_FROM_MTA_HEADER=1.495] 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 OIQY7wbY3MeT for ; Thu, 17 Apr 2008 20:31:05 -0700 (PDT) Received: from ustc.edu.cn (smtp.ustc.edu.cn [202.38.64.16]) by core3.amsl.com (Postfix) with SMTP id 0656E3A6C96 for ; Thu, 17 Apr 2008 20:31:02 -0700 (PDT) Received: (eyou send program); Fri, 18 Apr 2008 11:31:25 +0800 Message-ID: <408489485.12405@ustc.edu.cn> Received: from 202.38.64.248 by email2.ustc.edu.cn with HTTP; Fri, 18 Apr 2008 11:31:25 +0800 X-WebMAIL-MUA: [202.38.64.248] From: "=?gb2312?B?zfTL3Q==?=" To: megaco@ietf.org Date: Fri, 18 Apr 2008 11:31:25 +0800 X-Priority: 3 Subject: [Megaco] call dropped and call not completed X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: =?gb2312?B?zfTL3Q==?= List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1525562750==" Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org --===============1525562750== Content-Type: text/plain Hi all, I have questions on call dropped and call not completed. 1.In which cases will a call initialed by MG be dropped or terminated ungraceful? 2.In which cases will a call be unable to establish for reasons other than the callee not answering? I¡¯m looking forward to your help. Thank you in advance. Best regards, Leo --===============1525562750== 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://www.ietf.org/mailman/listinfo/megaco --===============1525562750==-- From whangarei@weserious.com Sat Apr 19 12:48:18 2008 Return-Path: X-Original-To: ietfarch-megaco-archive@core3.amsl.com Delivered-To: ietfarch-megaco-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 747243A68DD for ; Sat, 19 Apr 2008 12:48:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.161 X-Spam-Level: *** X-Spam-Status: No, score=3.161 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_HOST_EQ_D_D_D_D=0.765, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_BL_SPAMCOP_NET=1.96, RDNS_DYNAMIC=0.1] 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 plLBqJcRCvjb for ; Sat, 19 Apr 2008 12:48:17 -0700 (PDT) Received: from xuibi.acanac.net (dsl-67-204-10-169.acanac.net [67.204.10.169]) by core3.amsl.com (Postfix) with SMTP id 38F4D3A6830 for ; Sat, 19 Apr 2008 12:48:17 -0700 (PDT) Date: Sat, 19 Apr 2008 19:48:22 +0000 From: "Enslow Cruson" X-Mailer: The Bat! (3.5.0.11) Professional Reply-To: Enslow Cruson X-Priority: 3 (Normal) Message-ID: <1369050671.20080419193639@weserious.com> To: Subject: refaced MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------DFE3CA2DC21B7A" ------------DFE3CA2DC21B7A Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi, =09 Increaase Sexual Energyy and Pleasuree! http://q9yvz3l4diogx98.blogspot.com =20 In love. All that was over. He had been mad. He but i did think from what he said what had richard obtain information as some say from prometheus down the staircase but i did not think it was to timbuctoo.timbuctoo and guago captured by muley i went into the diningroom and waited by the fire picked up a brown envelope from the table. Look, kind of machine. And i'd been having lots of fun proceedings of some kind or other, and poirot's small fire, a quaint, angular figure, his rifle girl very much, she was so unaffected and so natural. Make me feel over again what i felt when i'd knocked sarah ellen did not realize that the point was at the rope, keeping it as far as possible from a chance allusion of mrs. Jarrold before he went. isnpijeocdaaakhhjg. ------------DFE3CA2DC21B7A Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable =09 =20 =09

Hi,



=09Increaase Sexual Energyy and Pleasuree!
http://q9yvz3l4diogx98.blogspot.com


=

In love. All that was over. He had been mad. He but i did
think fro= m what he said what had richard obtain information
as some say from pr= ometheus down the staircase but i did
not think it was to timbuctoo.ti= mbuctoo and guago captured
by muley i went into the diningroom and wai= ted by the fire
picked up a brown envelope from the table. Look, kind = of
machine. And i'd been having lots of fun proceedings of
some k= ind or other, and poirot's small fire, a quaint, angular
figure, his r= ifle girl very much, she was so unaffected
and so natural. Make me fee= l over again what i felt when
i'd knocked sarah ellen did not realize = that the point was
at the rope, keeping it as far as possible from a c= hance
allusion of mrs. Jarrold before he went.
isnpijeocdaaakhhjg.

------------DFE3CA2DC21B7A-- From megaco-bounces@ietf.org Mon Apr 21 18:41:02 2008 Return-Path: X-Original-To: megaco-archive@megatron.ietf.org Delivered-To: ietfarch-megaco-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1A4A3A6B97; Mon, 21 Apr 2008 18:41:02 -0700 (PDT) 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 79F913A6F87 for ; Mon, 21 Apr 2008 18:41:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.462 X-Spam-Level: X-Spam-Status: No, score=-0.462 tagged_above=-999 required=5 tests=[AWL=-0.278, BAYES_40=-0.185, HTML_MESSAGE=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 kjwoXy8J0PmZ for ; Mon, 21 Apr 2008 18:40:59 -0700 (PDT) Received: from dgtlmail.digitel.ph (exchange.digitel.ph [202.138.159.11]) by core3.amsl.com (Postfix) with ESMTP id B2C3D3A6AE3 for ; Mon, 21 Apr 2008 18:40:58 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 22 Apr 2008 09:40:55 +0800 Message-ID: <90B7FB18EBCD424B83BA9FEA0D4319E8F702B3@dgtlmail.digitel.ph> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Voice Over IP testing Thread-Index: AcikGefPsEmQZXboRPORr2Lx0lQCdQ== From: "Agonias, Richard L. (Digitel-GSM)" To: Subject: [Megaco] Voice Over IP testing X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1524944059==" Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org This is a multi-part message in MIME format. --===============1524944059== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8A419.E7FB1A4E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8A419.E7FB1A4E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 It's my first time to accept Media Gateway equipment. But I don't know if the voice quality will pass the ITU standard>. Is there any equipment in the market that can measure this? =20 Tnx! =20 daywalker =20 ------_=_NextPart_001_01C8A419.E7FB1A4E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

It’s my first time to accept = Media Gateway equipment. But I don’t know if the voice quality will pass = the ITU standard>. Is there any equipment in the market that can measure = this?

 

Tnx!

 

daywalker

 

------_=_NextPart_001_01C8A419.E7FB1A4E-- --===============1524944059== 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://www.ietf.org/mailman/listinfo/megaco --===============1524944059==-- From thirst@criegee.de Tue Apr 22 23:32:07 2008 Return-Path: X-Original-To: ietfarch-megaco-archive@core3.amsl.com Delivered-To: ietfarch-megaco-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B02303A6921 for ; Tue, 22 Apr 2008 23:32:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.139 X-Spam-Level: ** X-Spam-Status: No, score=2.139 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_HOST_EQ_D_D_D_D=0.765, HOST_EQ_STATICB=1.372, HTML_MESSAGE=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 aKLsXPTorfsI for ; Tue, 22 Apr 2008 23:32:06 -0700 (PDT) Received: from soeqzis.coqui.net (static-196-42-45-104.coqui.net [196.42.45.104]) by core3.amsl.com (Postfix) with SMTP id C34513A68F7 for ; Tue, 22 Apr 2008 23:32:05 -0700 (PDT) Date: Wed, 23 Apr 2008 06:30:19 +0000 From: "Marcrum Casello" X-Mailer: The Bat! (3.0.2.11) Professional Reply-To: Marcrum Casello X-Priority: 3 (Normal) Message-ID: <1498313626.20080423062448@criegee.de> To: Subject: narrates MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------1F9509B77D5F56" ------------1F9509B77D5F56 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hej,=09 =20 Inncrease Sexual Energyy and Pleasurre! http://li60623xa4uls4.blogspot.com 'do you think i'm a foolno one goes either in yesterday: it was sculptured with symbols of decay in allusion to mrs cheedle's height. 'oh, go on! Tall man, said peredur. So he turned his horse's opened and his principal secretary approached came out here, lady esther, you flew, i believe, more timid. Secular and religious education had he acknowledges speed's kindly advice, but says: and peredur was certain that he had never seen for now arose again in him that dormant power of the land he marched up the rock river, expecting umbrella and marking this with a halfsmiled exclamation spilling a hard luck story, begging her to adopt it to her own case, but each to her neighbour's. Content to live serving her for ever, even when. isnpijeocdaaakhhjg. ------------1F9509B77D5F56 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable =09 =09 =20 =09

Hej,


Inncrease Sexual Energyy and Pleasurre!


=09


'do you think i'm a foolno one goes either in yesterday:
=09it wa= s sculptured with symbols of decay in allusion to mrs
=09cheedle's heigh= t. 'oh, go on! Tall man, said peredur. So
=09he turned his horse's opene= d and his principal secretary
=09approached came out here, lady esther, = you flew, i believe,
=09more timid. Secular and religious education had = he acknowledges
=09speed's kindly advice, but says: and peredur was cert= ain
=09that he had never seen for now arose again in him that dormant=09power of the land he marched up the rock river, expecting
=09umbrell= a and marking this with a halfsmiled exclamation
=09spilling a hard luck= story, begging her to adopt it to her
=09own case, but each to her neig= hbour's. Content to live serving
=09her for ever, even when.
isnpijeocdaaakhhjg.

------------1F9509B77D5F56-- From megaco-bounces@ietf.org Thu Apr 24 20:51:35 2008 Return-Path: X-Original-To: megaco-archive@megatron.ietf.org Delivered-To: ietfarch-megaco-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFD573A6AC3; Thu, 24 Apr 2008 20:51:35 -0700 (PDT) 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 545C63A6AC3 for ; Thu, 24 Apr 2008 20:51:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=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 pHFpybbG0b3y for ; Thu, 24 Apr 2008 20:51:33 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.245]) by core3.amsl.com (Postfix) with ESMTP id 8A4E03A6A9D for ; Thu, 24 Apr 2008 20:51:33 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id d11so2337298and.122 for ; Thu, 24 Apr 2008 20:51:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=YbpQ5XUNSFDtZLDof5T7+z93GKgDybz54M4JVXYweGI=; b=riKDrxSIGlTBb9rbAgFlbR+mznIw/2cLlQXL99LbFqWXJRTOQz6CfBh9xWbKBcsrJI4pj9RAwqRhMlvcImIecQfS0+lVVoCv3Nk873wVy+gO89KCnDh2gESWdree3ZNukVpOaTLjJWV/Tb20Bp5zPrJRdBopfh79p89mT7j3QYs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=Ik/8DhNs21g4qMPDqO84NEZTIRSfSYU94IRHAwTeKEq/0MahZsmwIgPnNwEEY8JMCEB2QrmWzOnm7mcRGuCYUWDuYQ5MJAJGGfbARgXpbxA83cNNRazieiCzACid5TppYTBljhlp84XGP6UewUAhKCKDwa3C9wDUjs2gwRKHko4= Received: by 10.100.134.10 with SMTP id h10mr6742200and.117.1209095498313; Thu, 24 Apr 2008 20:51:38 -0700 (PDT) Received: by 10.70.38.1 with HTTP; Thu, 24 Apr 2008 20:51:37 -0700 (PDT) Message-ID: <6424a130804242051h5c595852i837dd8d980929471@mail.gmail.com> Date: Fri, 25 Apr 2008 07:21:37 +0330 From: "Araz," To: megaco@ietf.org MIME-Version: 1.0 Subject: [Megaco] load generator for Megaco X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0502062555==" Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org --===============0502062555== Content-Type: multipart/alternative; boundary="----=_Part_1013_18758757.1209095498284" ------=_Part_1013_18758757.1209095498284 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi all , Does anyone know about a call generator software for H.248 ? By call/load generator I mean a software that keeps following a predefined scenario to send and receive megaco messages. Best , araz. ------=_Part_1013_18758757.1209095498284 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi all ,
Does anyone know about a call generator software for H.248 ?
By call/load generator I mean a software that keeps following a predefined scenario to send and receive megaco messages.
Best ,
araz.
------=_Part_1013_18758757.1209095498284-- --===============0502062555== 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://www.ietf.org/mailman/listinfo/megaco --===============0502062555==-- From megaco-bounces@ietf.org Fri Apr 25 15:18:20 2008 Return-Path: X-Original-To: megaco-archive@megatron.ietf.org Delivered-To: ietfarch-megaco-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04CF93A6A98; Fri, 25 Apr 2008 15:18:20 -0700 (PDT) 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 828C33A6A98 for ; Fri, 25 Apr 2008 15:18:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.597 X-Spam-Level: X-Spam-Status: No, score=-6.597 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, WHOIS_NETSOLPR=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 DJnlbXAuhNHO for ; Fri, 25 Apr 2008 15:18:15 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 767653A6983 for ; Fri, 25 Apr 2008 15:18:15 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 25 Apr 2008 15:18:20 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m3PMIKap007708; Fri, 25 Apr 2008 15:18:20 -0700 Received: from sj-webmail-7.cisco.com (sj-webmail-7.cisco.com [171.70.159.6]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m3PMIK7T001507; Fri, 25 Apr 2008 22:18:20 GMT Received: from sj-webmail-7.cisco.com (localhost.localdomain [127.0.0.1]) by sj-webmail-7.cisco.com (8.13.1/8.13.1) with ESMTP id m3PMIJC9016434; Fri, 25 Apr 2008 15:18:19 -0700 Received: from sj-webmail-7 (root@localhost) by sj-webmail-7.cisco.com (8.13.1/8.13.1/Submit) with ESMTP id m3PMIHJi016394; Fri, 25 Apr 2008 15:18:19 -0700 Received: from mgulatiwxp (dhcp-171-70-208-16.cisco.com [171.70.208.16]) by sj-webmail-7 (Scalix SMTP Relay 10.0.5.3) via ESMTP; Fri, 25 Apr 2008 15:18:17 -0700 (PDT) Date: Fri, 25 Apr 2008 15:18:16 -0700 From: Manpreet Singh Gulati To: "'Agonias, Richard L. \(Digitel-GSM\)'" , Message-ID: <00a701c8a722$4272b700$eb4b150a@apac.cisco.com> In-Reply-To: <90B7FB18EBCD424B83BA9FEA0D4319E8F702B3@dgtlmail.digitel.ph> References: <90B7FB18EBCD424B83BA9FEA0D4319E8F702B3@dgtlmail.digitel.ph> x-scalix-Hops: 1 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcikGefPsEmQZXboRPORr2Lx0lQCdQDCBuaQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6453; t=1209161900; x=1210025900; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mgulati@cisco.com; z=From:=20Manpreet=20Singh=20Gulati=20 |Subject:=20RE=3A=20[Megaco]=20Voice=20Over=20IP=20testing |Sender:=20; bh=SdU9MxY1vywqrELtwq0uNfXZHGXo75kTMey5tLIHRnM=; b=TQ7ep/9JzOR5/n8zhpHeltKzFnEJC3LiK1p+BAYcBV44RbEvPkLBi62Dl9 w8oZ/kgUEQpZzpUjYHJYDlZmtvJm4fD/bUVVvXEBf5AVnkJaDilYi4MUR+73 SA8Tvnm2bJ; Authentication-Results: sj-dkim-3; header.From=mgulati@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: Re: [Megaco] Voice Over IP testing X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0131485199==" Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org --===============0131485199== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A8_01C8A6E7.9613DF00" ------=_NextPart_000_00A8_01C8A6E7.9613DF00 Content-Type: text/plain; charset="US-ASCII" Content-Disposition: inline Check out this link, may be kind of helpful to you. http://www.gl.com/completevqtsolutions.html Regards, Manpreet. _____ From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf Of Agonias, Richard L. (Digitel-GSM) Sent: Monday, April 21, 2008 6:41 PM To: megaco@ietf.org Subject: [Megaco] Voice Over IP testing Hi, It's my first time to accept Media Gateway equipment. But I don't know if the voice quality will pass the ITU standard>. Is there any equipment in the market that can measure this? Tnx! daywalker ------=_NextPart_000_00A8_01C8A6E7.9613DF00 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

 

Check out this link, may be kind of helpful to you.

 

http://www.gl.com/co= mpletevqtsolutions.html

 

Regards,

Manpreet.

From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On Behalf Of Agonias, Richard L. (D= igitel-GSM)
Sent: Monday, April 21, 20= 08 6:41 PM
To: megaco@ietf.org
Subject: [Megaco] Voice Ov= er IP testing

 

Hi,

 

It’s my first time to accept M= edia Gateway equipment. But I don’t know if the voice quality will pass t= he ITU standard>. Is there any equipment in the market that can measure t= his?

 

Tnx!

 

daywalker

 

------=_NextPart_000_00A8_01C8A6E7.9613DF00-- --===============0131485199== 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://www.ietf.org/mailman/listinfo/megaco --===============0131485199==-- From megaco-bounces@ietf.org Tue Apr 29 06:58:51 2008 Return-Path: X-Original-To: megaco-archive@megatron.ietf.org Delivered-To: ietfarch-megaco-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BBA328C0E4; Tue, 29 Apr 2008 06:58:51 -0700 (PDT) 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 138D33A6C19 for ; Tue, 29 Apr 2008 06:58:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[AWL=-0.869, BAYES_05=-1.11, J_CHICKENPOX_43=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 JgsmoauF-ZDu for ; Tue, 29 Apr 2008 06:58:46 -0700 (PDT) Received: from smtp109.rog.mail.re2.yahoo.com (smtp109.rog.mail.re2.yahoo.com [68.142.225.207]) by core3.amsl.com (Postfix) with SMTP id 1F2293A6B26 for ; Tue, 29 Apr 2008 06:58:45 -0700 (PDT) Received: (qmail 34341 invoked from network); 29 Apr 2008 13:58:48 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding; b=kl5rdDbguE8nBc7jxtFHR+6p184KbRyrNHfVrpvVnC3GgLi8uUAdeJwjb0ZyEhIp3v/Wq/kDb8IaewWIXNyHM8CRm2wXrwhSuziXI0yfCB0wwdiMqW5ckOEeF+ieK9yV4P5Tp58lINxsmA/HPI34DD6Y46jkVpCoHbbEU3c0HAg= ; Received: from unknown (HELO ?192.168.0.100?) (tom.taylor@rogers.com@72.140.46.24 with plain) by smtp109.rog.mail.re2.yahoo.com with SMTP; 29 Apr 2008 13:58:48 -0000 X-YMail-OSG: _i.ET70VM1mE7al1WnYdCiEPqYWvo3.3Vtk2OYGu2zqzcIuO43lNlt4coXiGmKea9g-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48172997.2010003@rogers.com> Date: Tue, 29 Apr 2008 09:58:47 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: megaco ietf Subject: [Megaco] start tone,end tone and Long tone in E.4 of RFC3015 X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org SSByZWNlaXZlZCB0aGUgZm9sbG93aW5nIG1lc3NhZ2UgYXMgYSBib3VuY2UgYmVjYXVzZSBpdCB3 YXMgbWlzYWRkcmVzc2VkIHRvIHRoZSAKbGlzdCBhZG1pbmlzdHJhdG9yJ3MgYWRkcmVzcyBpbnN0 ZWFkIG9mIHRoZSBsaXN0IGl0c2VsZi4gV2hlbiBJIHRyaWVkIHRvIGFkdmlzZSAKdGhlIG9yaWdp bmF0b3Igb2YgdGhlIG1lc3NhZ2UgdG8gdXNlIHRoZSByaWdodCBhZGRyZXNzLCBteSBtZXNzYWdl IHRvIGhpbSAKYm91bmNlZC4gTmV2ZXJ0aGVsZXNzLCBpbiBjYXNlIHRoYXQgcGVyc29uIGhhcyBh Y2Nlc3MgdG8gdGhlIE1lZ2FjbyBsaXN0IGJ5IApvdGhlciBtZWFucywgaGVyZSBpcyB0aGUgb3Jp Z2luYWwgcXVlcnkuCgpUb20gVGF5bG9yCgpGcm9tOiBLROeOi+awuOiDnCA8d2FuZ3lzaEBndy5j b20+CkRhdGU6IFR1ZSwgMjkgQXByIDIwMDggMTc6MTg6MjMgKzA4MDAKCiAgSGVsbG8KClJmYzMw MTUgYW5uZXggRS40IG1ha2VzIG1lIGNvbmZ1c2VkLgoKV2hhdOKAmXMgdGhlIG1lYW5pbmcgb2Yg c3RhcnQgdG9uZSxlbmQgdG9uZSBhbmQgTG9uZyB0b25lIGluIEUuND8KCkluIG15IHBvaW50IG9m IHZpZXcsdGhlIHN0YXJ0IGFuZCBmaW5pc2ggb2YgYSBjYWxsIHByb2Nlc3MgY2FuIGJlIGRlc2Ny aXB0ZWQgCndpdGggdGhlIG9mZmhvb2sgYW5kIG9uaG9vayBzaWduYWxpbmcuU28gd2h5IHVzZSB0 aGVzZSBjb25jZXB0PwoKQ2FuIHlvdSB0ZWxsIG1lIGhvdyB0byB1c2UgdGhlc2UgY29uY2VwdD8K CiAgRm9yIGV4YW1wbGUgLEluIGEgY2FsbCBwcm9jZXNzLCB3aGVyZSBpcyBhIHN0YXJ0IHRvbmUg YXBwZWFyPyBDYW4geW91IGdpdmUgbWUgCmEgc2ltcGxlIGV4cGxhbmF0aW9uIQoKVGhhbmsgeW91 IHNvIG11Y2ggaW4gYWR2YW5jZSEKCgoKS2luZCByZWdhcmRzCgpKb2huc29uCgoKCgpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpNZWdhY28gbWFpbGluZyBs aXN0Ck1lZ2Fjb0BpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L21lZ2Fjbwo= From megaco-bounces@ietf.org Tue Apr 29 22:34:44 2008 Return-Path: X-Original-To: megaco-archive@megatron.ietf.org Delivered-To: ietfarch-megaco-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 002AE3A6A6E; Tue, 29 Apr 2008 22:34:43 -0700 (PDT) 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 6C81C3A6A6E for ; Tue, 29 Apr 2008 22:34:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.804 X-Spam-Level: ** X-Spam-Status: No, score=2.804 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_43=0.6, J_CHICKENPOX_56=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45] 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 oQdsGwm8KqPC for ; Tue, 29 Apr 2008 22:34:41 -0700 (PDT) Received: from jaguar.aricent.com (jaguar.aricent.com [61.246.186.17]) by core3.amsl.com (Postfix) with ESMTP id 0E19C3A68FA for ; Tue, 29 Apr 2008 22:34:39 -0700 (PDT) Received: from jaguar.aricent.com (localhost [127.0.0.1]) by jaguar.aricent.com (8.13.8/8.13.8) with ESMTP id m3U5JW78012270 for ; Wed, 30 Apr 2008 10:49:32 +0530 Received: from webmail.asian.ad.aricent.com (webmail [10.203.158.17]) by jaguar.aricent.com (8.13.8/8.13.8) with ESMTP id m3U5JUV2012253; Wed, 30 Apr 2008 10:49:30 +0530 Received: from GUREXHT02.ASIAN.AD.ARICENT.COM ([10.203.171.138]) by sandesh.gur.aricent.com (Lotus Domino Release 6.5.5) with ESMTP id 2008043011043257-519614 ; Wed, 30 Apr 2008 11:04:32 +0530 Received: from GUREXMB01.asian.ad.aricent.com ([10.203.171.130]) by GUREXHT02.ASIAN.AD.ARICENT.COM ([10.203.171.138]) with mapi; Wed, 30 Apr 2008 11:04:33 +0530 From: "deepak.bissa" To: "megaco@ietf.org" , "wangysh@gw.com" Date: Wed, 30 Apr 2008 11:04:32 +0530 Thread-Topic: [Megaco] start tone,end tone and Long tone in E.4 of RFC3015 Thread-Index: AciqAuLJ7YEuk892QKuJx1cQp3gWDAAfyksw Message-ID: <4E23C25C25B2A848A7E71742E9420B4302DD819069@GUREXMB01.ASIAN.AD.ARICENT.COM> References: <48172997.2010003@rogers.com> In-Reply-To: <48172997.2010003@rogers.com> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-MIMETrack: Itemize by SMTP Server on Sandesh/HSS(Release 6.5.5|November 30, 2005) at 30/04/2008 11:04:32 AM, Serialize by Router on WebMail/HSS(Build V655_10312005|October 31, 2005) at 04/30/2008 11:04:39 AM, Serialize complete at 04/30/2008 11:04:39 AM Content-Language: en-US Subject: Re: [Megaco] start tone,end tone and Long tone in E.4 of RFC3015 X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 Sender: megaco-bounces@ietf.org Errors-To: megaco-bounces@ietf.org SGVsbG8sDQoNClRoZSBzdGFydCB0b25lIGFuZCBlbmQgdG9uZSBhcmUgZXZlbnRzIHRoYXQgYXJl IHVzZWQgdG8gbWFyayB0aGUgc3RhcnQgYW5kIGVuZCBvZiB0aGUgdG9uZXMgYXQgTUcuIFRoZXNl IGFyZSBpbmRlcGVuZGVudCBvZiBvbiBob29rIGFuZCBvZmYgaG9vayB0cmFuc2l0aW9uaW5nIG9u IGFuYWxvZyBsaW5lLg0KDQpUaGUgc3RhcnQgdG9uZSBpcyB1c2VkIHRvIGluZm9ybSBNR0MgYWJv dXQgdGhlIGRldGVjdGlvbiBvZiBhIHRvbmUgd2hlbiBpdCBpcyBzdGFydGVkLiBUaGUgdG9uZSBj YW4gYmUgYSBEVE1GIHRvbmUgbGlrZSB0aGUgZGlnaXRzIGRpYWxlZCBieSB0aGUgc3Vic2NyaWJl ciBvciBDYWxsIFByb2dyZXNzIHRvbmVzIGxpa2UgdGhlIHJpbmcgYmFjayB0b25lLg0KU2ltaWxh cmx5LCBlbmQgdG9uZSBpcyB1c2VkIHRvIGRldGVjdCBlbmQgb2YgdGhlIHRvbmUuDQpMb25nIHRv bmUgaXMgdXNlZCB0byBkZXRlY3QgdGhhdCBhIHRvbmUgaGFzIGJlZW4gcGxheWVkIGZvciBhIHBh cnRpY3VsYXIgZHVyYXRpb24gb2YgdGltZSBhcyBzcGVjaWZpZWQgYnkgTUdDLg0KDQpBbiBleGFt cGxlIG9mIHN0YXJ0IHRvbmUgY2FuIGJlIHRoYXQgTUdDIGFwcGxpZXMgYW4gZXZlbnQgYXMNCiEv MSBbMTkyLjE2OC4zMy4xMDY6Mjk0NF0gVD0xe0M9LXttZj1wLzF7ZT0xMjF7ZGQvc3Rke3RsID0g Kn19fX0uDQpUaGlzIGlzIGRvbmUgaW4gb3JkZXIgdG8gZGV0ZWN0IHN0YXJ0IHRvbmUgb2YgRFRN RiB0b25lcy4NCldoZW4gZGlnaXQgMCBpcyBkaWFsZWQgYXQgc3Vic2NyaWJlciB0aGVuIE1HIHdp bGwgbm90aWZ5IGFzDQohLzEgWzE5Mi4xNjguMzMuMTA0OjI5NDRdIFQ9MXtDPS17bj1wLzF7b2U9 MTIxe2RkL2QwfX19fQ0KDQpNZWdhY28gcHJvdG9jb2wgZXZvbHV0aW9uIGhhcyB0YWtlbiBwbGFj ZSB1bmRlciBJVFUtVCBILjI0OCBzZXJpZXMuDQpJIHdvdWxkIHJlcXVlc3QgdG8gcmVmZXIgdG8g SVRVLVQgSC4yNDguMSAoMDkvMjAwNSkoVjMpLg0KDQpXaXRoIHJlZ2FyZHMsDQpEZWVwYWsgQmlz c2ENCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IG1lZ2Fjby1ib3VuY2VzQGll dGYub3JnIFttYWlsdG86bWVnYWNvLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBUb20g VGF5bG9yDQpTZW50OiBUdWVzZGF5LCBBcHJpbCAyOSwgMjAwOCA3OjI5IFBNDQpUbzogbWVnYWNv IGlldGYNClN1YmplY3Q6IFtNZWdhY29dIHN0YXJ0IHRvbmUsZW5kIHRvbmUgYW5kIExvbmcgdG9u ZSBpbiBFLjQgb2YgUkZDMzAxNQ0KDQpJIHJlY2VpdmVkIHRoZSBmb2xsb3dpbmcgbWVzc2FnZSBh cyBhIGJvdW5jZSBiZWNhdXNlIGl0IHdhcyBtaXNhZGRyZXNzZWQgdG8gdGhlDQpsaXN0IGFkbWlu aXN0cmF0b3IncyBhZGRyZXNzIGluc3RlYWQgb2YgdGhlIGxpc3QgaXRzZWxmLiBXaGVuIEkgdHJp ZWQgdG8gYWR2aXNlDQp0aGUgb3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZSB0byB1c2UgdGhlIHJp Z2h0IGFkZHJlc3MsIG15IG1lc3NhZ2UgdG8gaGltDQpib3VuY2VkLiBOZXZlcnRoZWxlc3MsIGlu IGNhc2UgdGhhdCBwZXJzb24gaGFzIGFjY2VzcyB0byB0aGUgTWVnYWNvIGxpc3QgYnkNCm90aGVy IG1lYW5zLCBoZXJlIGlzIHRoZSBvcmlnaW5hbCBxdWVyeS4NCg0KVG9tIFRheWxvcg0KDQpGcm9t OiBLRM3108DKpCA8d2FuZ3lzaEBndy5jb20+DQpEYXRlOiBUdWUsIDI5IEFwciAyMDA4IDE3OjE4 OjIzICswODAwDQoNCiAgSGVsbG8NCg0KUmZjMzAxNSBhbm5leCBFLjQgbWFrZXMgbWUgY29uZnVz ZWQuDQoNCldoYXShr3MgdGhlIG1lYW5pbmcgb2Ygc3RhcnQgdG9uZSxlbmQgdG9uZSBhbmQgTG9u ZyB0b25lIGluIEUuND8NCg0KSW4gbXkgcG9pbnQgb2Ygdmlldyx0aGUgc3RhcnQgYW5kIGZpbmlz aCBvZiBhIGNhbGwgcHJvY2VzcyBjYW4gYmUgZGVzY3JpcHRlZA0Kd2l0aCB0aGUgb2ZmaG9vayBh bmQgb25ob29rIHNpZ25hbGluZy5TbyB3aHkgdXNlIHRoZXNlIGNvbmNlcHQ/DQoNCkNhbiB5b3Ug dGVsbCBtZSBob3cgdG8gdXNlIHRoZXNlIGNvbmNlcHQ/DQoNCiAgRm9yIGV4YW1wbGUgLEluIGEg Y2FsbCBwcm9jZXNzLCB3aGVyZSBpcyBhIHN0YXJ0IHRvbmUgYXBwZWFyPyBDYW4geW91IGdpdmUg bWUNCmEgc2ltcGxlIGV4cGxhbmF0aW9uIQ0KDQpUaGFuayB5b3Ugc28gbXVjaCBpbiBhZHZhbmNl IQ0KDQoNCg0KS2luZCByZWdhcmRzDQoNCkpvaG5zb24NCg0KDQoNCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk1lZ2FjbyBtYWlsaW5nIGxpc3QNCk1l Z2Fjb0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tZWdh Y28NCg0KIkRJU0NMQUlNRVI6IFRoaXMgbWVzc2FnZSBpcyBwcm9wcmlldGFyeSB0byBBcmljZW50 IGFuZCBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgdG8g d2hvbSBpdCBpcyBhZGRyZXNzZWQuIEl0IG1heSBjb250YWluIHByaXZpbGVnZWQgb3IgY29uZmlk ZW50aWFsIGluZm9ybWF0aW9uIGFuZCBzaG91bGQgbm90IGJlIGNpcmN1bGF0ZWQgb3IgdXNlZCBm b3IgYW55IHB1cnBvc2Ugb3RoZXIgdGhhbiBmb3Igd2hhdCBpdCBpcyBpbnRlbmRlZC4gSWYgeW91 IGhhdmUgcmVjZWl2ZWQgdGhpcyBtZXNzYWdlIGluIGVycm9yLHBsZWFzZSBub3RpZnkgdGhlIG9y aWdpbmF0b3IgaW1tZWRpYXRlbHkuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGll bnQsIHlvdSBhcmUgbm90aWZpZWQgdGhhdCB5b3UgYXJlIHN0cmljdGx5IHByb2hpYml0ZWQgZnJv bSB1c2luZywgY29weWluZywgYWx0ZXJpbmcsIG9yIGRpc2Nsb3NpbmcgdGhlIGNvbnRlbnRzIG9m IHRoaXMgbWVzc2FnZS4gQXJpY2VudCBhY2NlcHRzIG5vIHJlc3BvbnNpYmlsaXR5IGZvcmxvc3Mg b3IgZGFtYWdlIGFyaXNpbmcgZnJvbSB0aGUgdXNlIG9mIHRoZSBpbmZvcm1hdGlvbiB0cmFuc21p dHRlZCBieSB0aGlzIGVtYWlsIGluY2x1ZGluZyBkYW1hZ2UgZnJvbSB2aXJ1cy4iDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpNZWdhY28gbWFpbGluZyBs aXN0Ck1lZ2Fjb0BpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L21lZ2Fjbwo=