From Ren_weiz@kubo-clinic.com Sat Sep 01 03:33:02 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRNTa-0000ZT-7L for megaco-archive@lists.ietf.org; Sat, 01 Sep 2007 03:33:02 -0400 Received: from [85.110.48.208] (helo=[85.110.48.208]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IRNTZ-0007a3-6E for megaco-archive@lists.ietf.org; Sat, 01 Sep 2007 03:33:01 -0400 Received: by 10.229.90.17 with SMTP id YuDsEpeyrXYQz; Sat, 1 Sep 2007 10:32:51 +0300 (GMT) Received: by 192.168.17.115 with SMTP id AlyqKWQDulthab.9722479532901; Sat, 1 Sep 2007 10:32:49 +0300 (GMT) Message-ID: <000301c7ec6a$4aacde00$d0306e55@ekamu> From: "Ren weiz" To: Subject: cuttlebo Date: Sat, 1 Sep 2007 10:32:46 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C7EC83.6FFA1600" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 2.8 (++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0004_01C7EC83.6FFA1600 Content-Type: text/plain; charset="iso-8859-9" Content-Transfer-Encoding: quoted-printable http://www.adfrc.com/ Hello megaco-archive Many men want to improve their schlong size Gargyan Olschewski ------=_NextPart_000_0004_01C7EC83.6FFA1600 Content-Type: text/html; charset="iso-8859-9" Content-Transfer-Encoding: quoted-printable
http://www.adfrc.com/
Hello megaco-archive
Many men want to improve their schlong = size
Gargyan Olschewski
------=_NextPart_000_0004_01C7EC83.6FFA1600-- From megaco-bounces@ietf.org Sat Sep 01 08:36:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRSBT-0002Hy-Gk; Sat, 01 Sep 2007 08:34:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRSBR-0002BP-JQ for megaco@ietf.org; Sat, 01 Sep 2007 08:34:37 -0400 Received: from wa-out-1112.google.com ([209.85.146.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IRSBQ-0005xB-Bw for megaco@ietf.org; Sat, 01 Sep 2007 08:34:37 -0400 Received: by wa-out-1112.google.com with SMTP id k40so1649853wah for ; Sat, 01 Sep 2007 05:34:35 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=dUG5MrSsjlsPflWmUor5oTfiJ8I5o/jbf0QkcHg6VkDr0QXjoVkOQeEOjbhjr0ICiY7zU9qGqGoEOa1Imz8VPkMwYgHk+as56o2hs+zBrerncFG4BzO2MEAYyJFt8DYKTOw50MBRe2cChNn0DNeh2W0FjGqmTXHYc24fobyxHAo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=a+fR/UbzidwdHjrH+xiVrkPx9F0xx8ywXUTF+2guTNNvAVG5o74AxsFpfyyP3yDWYcmO4ji9L/sVt0nea6A6xB9tpsVS7Xkxc2mTRD/RrZAEfOrKbudMhR2JoE6RekrALUGfPUEy2qfCTxkbL/bipQ1SKbfg+vC510C1MN4w8ZQ= Received: by 10.142.78.10 with SMTP id a10mr128415wfb.1188650075652; Sat, 01 Sep 2007 05:34:35 -0700 (PDT) Received: by 10.143.12.8 with HTTP; Sat, 1 Sep 2007 05:34:30 -0700 (PDT) Message-ID: Date: Sat, 1 Sep 2007 18:04:30 +0530 From: "Gopalarathnam Sambasivan" To: megaco@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Subject: [Megaco] A Addreply error scenario doubt. X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1318447978==" Errors-To: megaco-bounces@ietf.org --===============1318447978== Content-Type: multipart/alternative; boundary="----=_Part_2873_23284883.1188650070541" ------=_Part_2873_23284883.1188650070541 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello All, rfc3525 states, If the receiver encounters an error in processing a ContextID, the requested Action response will consist of the Context ID and a single error descriptor, 422 - Syntax Error in Action. A ADD has resulted in a error.(originating call attempt - context being created by gateway) P=8597{C=60{A=GW30901/1{ER=422{"Syntax Error in Action"}},A=rtp/24}} Is this response correct - even when termination GW30901/1 has not been added to context 60? Because a modify congestion tone sent to this termination in response to the above response, responds with P=8598{C=60{MF=GW30901/1{ER=435{"Termination ID is not in specified Context : ContextId = NULL"}}}} Thanks and Best Regards, Gopalarathnam. ------=_Part_2873_23284883.1188650070541 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hello All,
rfc3525 states,
  If the receiver encounters an error in processing a ContextID, the
   requested Action response will consist of the Context ID and a single
   error descriptor, 422 - Syntax Error in Action.
 
A ADD has resulted in a error.(originating call attempt - context being created by gateway)
 
P=8597{C=60{A=GW30901/1{ER=422{"Syntax Error in Action"}},A=rtp/24}}
Is this response correct - even when termination GW30901/1 has not been added to context 60?
 
Because a modify congestion tone sent to this termination in response to the above response,
responds with

P=8598{C=60{MF=GW30901/1{ER=435{"Termination ID is not in specified Context : ContextId = NULL"}}}}
 
Thanks and Best Regards,
Gopalarathnam.
------=_Part_2873_23284883.1188650070541-- --===============1318447978== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============1318447978==-- From keaten.Rosendahl@joviel.com Sun Sep 02 00:40:55 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRhGZ-0001xh-H5 for megaco-archive@lists.ietf.org; Sun, 02 Sep 2007 00:40:55 -0400 Received: from host239.200-82-79.telecom.net.ar ([200.82.79.239] helo=host195.190-136-249.telecom.net.ar) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IRhGX-0001Hj-49 for megaco-archive@lists.ietf.org; Sun, 02 Sep 2007 00:40:55 -0400 Received: from yessica ([173.175.9.161]:5667 "EHLO yessica" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by host195.190-136-249.telecom.net.ar with ESMTP id S22LLWJIWTLPYIUA (ORCPT ); Sun, 2 Sep 2007 01:41:32 -0300 Message-ID: <000401c7ed1b$765d14a0$c3f988be@yessica> From: "keaten Rosendahl" To: Subject: estvrije Date: Sun, 2 Sep 2007 01:41:00 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C7ED02.510FDCA0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 3.0 (+++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0007_01C7ED02.510FDCA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://atasru.com/ News to Rosendahl Say hello to my little friend, well big friend now Latoshia kurji ------=_NextPart_000_0007_01C7ED02.510FDCA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://atasru.com/
News to Rosendahl
Say hello to my little friend, well big friend = now
Latoshia kurji
------=_NextPart_000_0007_01C7ED02.510FDCA0-- From megaco-bounces@ietf.org Sun Sep 02 08:31:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRoaL-0000jh-Of; Sun, 02 Sep 2007 08:29:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRoaK-0000Z5-0M for megaco@ietf.org; Sun, 02 Sep 2007 08:29:48 -0400 Received: from owa.vocaltec.com ([212.143.64.50] helo=mailserver.vocaltec.co.il) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IRoaJ-00024X-Bp for megaco@ietf.org; Sun, 02 Sep 2007 08:29:47 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Megaco] Reporting actual codec used in a call Date: Sun, 2 Sep 2007 15:31:42 +0300 Message-ID: <431F3BDE11BF2F42A22CBEFA36BD88A4F606D5@mailserver.vocaltec.local> In-Reply-To: <46D367AD.10408@internode.on.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Megaco] Reporting actual codec used in a call Thread-Index: AcfpCC7N2peFp1LhTv6Rgajam0ePDQEU31ig References: <431F3BDE11BF2F42A22CBEFA36BD88A4F606C1@mailserver.vocaltec.local> <46D367AD.10408@internode.on.net> From: "Raphael Tryster" To: "Christian Groves" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: megaco ietf X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: megaco-bounces@ietf.org Thank you, Christian. rtp/pltrans looks like a good way to report a change in codec, but what about the initial value? Is there an assumption here that the initial codec is the first one listed in the SDP, and therefore an MG receiving rtp/pltrans in Events that chooses another codec to start with should immediately notify rtp/pltrans? =20 Raphael Tryster -----Original Message----- From: Christian Groves [mailto:cngroves@internode.on.net]=20 Sent: Tuesday, August 28, 2007 3:09 AM To: Raphael Tryster Cc: megaco ietf Subject: Re: [Megaco] Reporting actual codec used in a call Hello Raphael, There's to payload transition event in the RTP package that can be used, however its not linked to a subtract (end of call). Regards, Christian Raphael Tryster wrote: > > Is there any package that allows the MG to report to the MGC at the=20 > end of a call, which codec was actually used for the call? (As=20 > opposed to codec negotiation at the start of a call, which may produce > a list of codecs, not all of which are actually used in the call). > > =20 > > Raphael Tryster > > ------------------------------------------------------------------------ > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > =20 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From Gaddiscgcik@adves.net Sun Sep 02 19:29:47 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRyt1-0004aS-H9 for megaco-archive@lists.ietf.org; Sun, 02 Sep 2007 19:29:47 -0400 Received: from host142-246-static.23-80-b.business.telecomitalia.it ([80.23.246.142]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IRyt0-0007Cz-O7 for megaco-archive@lists.ietf.org; Sun, 02 Sep 2007 19:29:47 -0400 Received: by 10.117.23.147 with SMTP id pxoSgqThGGRMV; Mon, 3 Sep 2007 01:31:49 +0200 (GMT) Received: by 192.168.227.221 with SMTP id BhuEWrhYhEEIrv.3726362640854; Mon, 3 Sep 2007 01:31:47 +0200 (GMT) Message-ID: <000401c7edb9$6c0de0d0$8ef61750@PCPIERINI> From: "kerrie Gaddis" To: Subject: ptstelle Date: Mon, 3 Sep 2007 01:31:44 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C7EDCA.2F96B0D0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 2.0 (++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0006_01C7EDCA.2F96B0D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://www.eqiqbbs.com/ Wazzup Gaddis bigger than average, thats what i am now Hyung Gotsch ------=_NextPart_000_0006_01C7EDCA.2F96B0D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://www.eqiqbbs.com/
Wazzup Gaddis
bigger than average, thats what i am = now
Hyung Gotsch
------=_NextPart_000_0006_01C7EDCA.2F96B0D0-- From Jeramie@allegiance.com.sg Mon Sep 03 01:23:24 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IS4PE-0002xx-CB for megaco-archive@lists.ietf.org; Mon, 03 Sep 2007 01:23:24 -0400 Received: from host173-200-dynamic.59-82-r.retail.telecomitalia.it ([82.59.200.173]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IS4PD-0005ZY-7Q for megaco-archive@lists.ietf.org; Mon, 03 Sep 2007 01:23:23 -0400 Received: from end-z9bs2ai7w2e ([131.126.189.153] helo=end-z9bs2ai7w2e) by host173-200-dynamic.59-82-r.retail.telecomitalia.it ( sendmail 8.13.3/8.13.1) with esmtpa id 1IkIhF-000HPE-hK for megaco-archive@lists.ietf.org; Mon, 3 Sep 2007 07:23:58 +0200 Message-ID: <000701c7edea$8f4d3380$adc83b52@endz9bs2ai7w2e> From: "Jeramie timmons" To: Subject: skrownat Date: Mon, 3 Sep 2007 07:23:28 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C7EDFB.52D60380" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 2.1 (++) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 ------=_NextPart_000_0004_01C7EDFB.52D60380 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://elegeek.com/ How it is going megaco-archive No girls laugh at me now Joachim okabe ------=_NextPart_000_0004_01C7EDFB.52D60380 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://elegeek.com/
How it is going megaco-archive
No girls laugh at me now
Joachim okabe
------=_NextPart_000_0004_01C7EDFB.52D60380-- From joaniecaprara@DIGITALMALL.COM Mon Sep 03 16:38:25 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISIgj-0000LH-Il for megaco-archive@lists.ietf.org; Mon, 03 Sep 2007 16:38:25 -0400 Received: from host76-50-dynamic.50-82-r.retail.telecomitalia.it ([82.50.50.76]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ISIgi-0005fL-8E for megaco-archive@lists.ietf.org; Mon, 03 Sep 2007 16:38:24 -0400 Received: from abbate ([164.186.111.24] helo=abbate) by host76-50-dynamic.50-82-r.retail.telecomitalia.it ( sendmail 8.13.3/8.13.1) with esmtpa id 1XyqwH-000CVP-XG for megaco-archive@lists.ietf.org; Mon, 3 Sep 2007 22:32:50 +0200 Message-ID: <000301c7ee69$8df997b0$4c323252@abbate> From: "joanie caprara" To: Subject: ag-check Date: Mon, 3 Sep 2007 22:32:32 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C7EE7A.518267B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 2.1 (++) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 ------=_NextPart_000_0007_01C7EE7A.518267B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://mhtlhelp.com/ Good day joanie You should see me now, i am so much more confident with the women. Artid akdamet ------=_NextPart_000_0007_01C7EE7A.518267B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://mhtlhelp.com/
Good day joanie
You should see me now, i am so much more = confident with=20 the women.
Artid akdamet
------=_NextPart_000_0007_01C7EE7A.518267B0-- From megaco-bounces@ietf.org Mon Sep 03 21:04:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISMoS-0004xg-BU; Mon, 03 Sep 2007 21:02:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISMoQ-0004xa-E5 for megaco@ietf.org; Mon, 03 Sep 2007 21:02:38 -0400 Received: from ipmail01.adl2.internode.on.net ([203.16.214.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ISMoO-0006Fl-Lo for megaco@ietf.org; Mon, 03 Sep 2007 21:02:38 -0400 X-IronPort-AV: E=Sophos;i="4.20,203,1186324200"; d="scan'208";a="184985037" Received: from ppp59-167-144-196.lns4.mel6.internode.on.net (HELO [127.0.0.1]) ([59.167.144.196]) by ipmail01.adl2.internode.on.net with ESMTP; 04 Sep 2007 10:31:23 +0930 Message-ID: <46DCAE61.60800@nteczone.com> Date: Tue, 04 Sep 2007 11:01:21 +1000 From: Christian Groves User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Raphael Tryster Subject: Re: [Megaco] Reporting actual codec used in a call References: <431F3BDE11BF2F42A22CBEFA36BD88A4F606C1@mailserver.vocaltec.local> <46D367AD.10408@internode.on.net> <431F3BDE11BF2F42A22CBEFA36BD88A4F606D5@mailserver.vocaltec.local> In-Reply-To: <431F3BDE11BF2F42A22CBEFA36BD88A4F606D5@mailserver.vocaltec.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.0 (-) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: megaco ietf X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: megaco-bounces@ietf.org Hello Raphael, I agree that it is not really specified what the initial value would be. I think your suggestion is a pragmatic one to define the behaviour when a codec has not been already selected. An alternative is to say that the MGC should not set the rtp/pltrans event until an initial codec is used but the MGC wouldn't know when this was. This might be a candidate for an IG item. Regards, Christian Raphael Tryster wrote: > Thank you, Christian. rtp/pltrans looks like a good way to report a > change in codec, but what about the initial value? Is there an > assumption here that the initial codec is the first one listed in the > SDP, and therefore an MG receiving rtp/pltrans in Events that chooses > another codec to start with should immediately notify rtp/pltrans? > > Raphael Tryster > > -----Original Message----- > From: Christian Groves [mailto:cngroves@internode.on.net] > Sent: Tuesday, August 28, 2007 3:09 AM > To: Raphael Tryster > Cc: megaco ietf > Subject: Re: [Megaco] Reporting actual codec used in a call > > Hello Raphael, > > There's to payload transition event in the RTP package that can be used, > > however its not linked to a subtract (end of call). > > Regards, Christian > > Raphael Tryster wrote: > >> Is there any package that allows the MG to report to the MGC at the >> end of a call, which codec was actually used for the call? (As >> opposed to codec negotiation at the start of a call, which may produce >> > > >> a list of codecs, not all of which are actually used in the call). >> >> >> >> Raphael Tryster >> >> >> > ------------------------------------------------------------------------ > >> _______________________________________________ >> Megaco mailing list >> Megaco@ietf.org >> https://www1.ietf.org/mailman/listinfo/megaco >> >> > > > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Tue Sep 04 01:41:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISR8K-0001Ve-Qu; Tue, 04 Sep 2007 01:39:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISR8F-0001VL-QP for megaco@ietf.org; Tue, 04 Sep 2007 01:39:23 -0400 Received: from smail5.alcatel.fr ([62.23.212.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ISR8E-00052m-BQ for megaco@ietf.org; Tue, 04 Sep 2007 01:39:23 -0400 Received: from FRVELSBHS05.ad2.ad.alcatel.com (frvelsbhs05.ad2.ad.alcatel.com [155.132.6.77]) by smail5.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l845cirn015452; Tue, 4 Sep 2007 07:38:44 +0200 Received: from FRVELSMBS15.ad2.ad.alcatel.com ([155.132.6.31]) by FRVELSBHS05.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Tue, 4 Sep 2007 07:39:15 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Megaco] Reporting actual codec used in a call Date: Tue, 4 Sep 2007 07:39:13 +0200 Message-ID: <8BB8AD9870081C42B2B309E00352E4EAA4FC33@FRVELSMBS15.ad2.ad.alcatel.com> In-Reply-To: <46DCAE61.60800@nteczone.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Megaco] Reporting actual codec used in a call Thread-Index: AcfukAimccK204n2TfK1ad88BukXLwAI/MiA References: <431F3BDE11BF2F42A22CBEFA36BD88A4F606C1@mailserver.vocaltec.local><46D367AD.10408@internode.on.net><431F3BDE11BF2F42A22CBEFA36BD88A4F606D5@mailserver.vocaltec.local> <46DCAE61.60800@nteczone.com> From: "Schwarz Albrecht" To: "Christian Groves" , "Raphael Tryster" X-OriginalArrivalTime: 04 Sep 2007 05:39:15.0923 (UTC) FILETIME=[EE61DA30:01C7EEB5] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.13 X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: megaco ietf X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: megaco-bounces@ietf.org Like to note that there are further aspects when using RTP = payload/packet type codepoint (PT) as information for used codec in a = call: 1) codec changes 2) multiple PTs in use e.g. due to telephone events for RFC 4733 packets 3) multiple PTs in use e.g. due to voiceband data services (V.152, T.38, = V.150.1, V.151) > > Raphael Tryster wrote: > > =20 > >> Is there any package that allows the MG to report to the=20 > MGC at the=20 > >> end of a call, which codec was actually used for the call? (As=20 > >> opposed to codec negotiation at the start of a call, which may=20 > >> produce I could see two ways: A) H.248.1 V3 & H.248.39 (see e.g. =A7 8.1 "Individual auditing of Local = and Remote SDP was introduced in H.248.1 Version 3") =3D> auditing of SDP "m=3D" and/or "a=3D" lines B) New H.248 Statistic "Used codec(s) in a IP call/RTP session" =3D> ordered list of media formats used (the first list item indicates = the last codec used)=20 -Albrecht > -----Original Message----- > From: Christian Groves [mailto:Christian.Groves@nteczone.com]=20 > Sent: Dienstag, 4. September 2007 03:01 > To: Raphael Tryster > Cc: megaco ietf > Subject: Re: [Megaco] Reporting actual codec used in a call >=20 > Hello Raphael, >=20 > I agree that it is not really specified what the initial=20 > value would be.=20 > I think your suggestion is a pragmatic one to define the=20 > behaviour when a codec has not been already selected. An=20 > alternative is to say that the MGC should not set the=20 > rtp/pltrans event until an initial codec is used but the MGC=20 > wouldn't know when this was. >=20 > This might be a candidate for an IG item. >=20 > Regards, Christian >=20 > Raphael Tryster wrote: > > Thank you, Christian. rtp/pltrans looks like a good way to=20 > report a=20 > > change in codec, but what about the initial value? Is there an=20 > > assumption here that the initial codec is the first one=20 > listed in the=20 > > SDP, and therefore an MG receiving rtp/pltrans in Events=20 > that chooses=20 > > another codec to start with should immediately notify rtp/pltrans? > > =20 > > Raphael Tryster > > > > -----Original Message----- > > From: Christian Groves [mailto:cngroves@internode.on.net] > > Sent: Tuesday, August 28, 2007 3:09 AM > > To: Raphael Tryster > > Cc: megaco ietf > > Subject: Re: [Megaco] Reporting actual codec used in a call > > > > Hello Raphael, > > > > There's to payload transition event in the RTP package that can be=20 > > used, > > > > however its not linked to a subtract (end of call). > > > > Regards, Christian > > > > Raphael Tryster wrote: > > =20 > >> Is there any package that allows the MG to report to the=20 > MGC at the=20 > >> end of a call, which codec was actually used for the call? (As=20 > >> opposed to codec negotiation at the start of a call, which may=20 > >> produce > >> =20 > > > > =20 > >> a list of codecs, not all of which are actually used in the call). > >> > >> =20 > >> > >> Raphael Tryster > >> > >> > >> =20 > >=20 > ---------------------------------------------------------------------- > > -- > > =20 > >> _______________________________________________ > >> Megaco mailing list > >> Megaco@ietf.org > >> https://www1.ietf.org/mailman/listinfo/megaco > >> =20 > >> =20 > > > > > > =20 >=20 > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco >=20 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Tue Sep 04 01:55:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISRM8-0004fA-La; Tue, 04 Sep 2007 01:53:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISRM7-0004U5-D0 for megaco@ietf.org; Tue, 04 Sep 2007 01:53:43 -0400 Received: from smail5.alcatel.fr ([64.208.49.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ISRM5-0005Il-RU for megaco@ietf.org; Tue, 04 Sep 2007 01:53:43 -0400 Received: from FRVELSBHS02.ad2.ad.alcatel.com (frvelsbhs02.ad2.ad.alcatel.com [155.132.6.74]) by smail5.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l845r9bF017572; Tue, 4 Sep 2007 07:53:09 +0200 Received: from FRVELSMBS15.ad2.ad.alcatel.com ([155.132.6.31]) by FRVELSBHS02.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Tue, 4 Sep 2007 07:53:39 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Megaco] Regarding virtual MGs Date: Tue, 4 Sep 2007 07:53:36 +0200 Message-ID: <8BB8AD9870081C42B2B309E00352E4EAA4FC3A@FRVELSMBS15.ad2.ad.alcatel.com> In-Reply-To: <46CBB96D.1080303@internode.on.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Megaco] Regarding virtual MGs Thread-Index: Acfkc+2lLQyg3xjRSaCT2NkHXs4neAKQuo8w References: <52a9bccc0708170442k7565f233sdd5e85b21abd953f@mail.gmail.com> <46C76C25.8060607@redback.com> <46CBB96D.1080303@internode.on.net> From: "Schwarz Albrecht" To: "Gopalarathnam Sambasivan" X-OriginalArrivalTime: 04 Sep 2007 05:53:39.0854 (UTC) FILETIME=[F15342E0:01C7EEB7] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.13 X-Spam-Score: 0.0 (/) X-Scan-Signature: cd000eda3d43531d5b01b5d305410e3c Cc: megaco@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: megaco-bounces@ietf.org Do agree to Christian. Looking at the email discussions, the key point is the "H.248 Control = Association" (CA) concept. A single CA binds a MG to an MGC, independent of a PMG or VMG. Now, what constitutes a CA? Is the transport endpoint address part of = the CA or not? H.Sup7, =A7 5.2 provides a clarification, see: http://ftp3.itu.int/av-arch/avc-site/2005-2008/0706_Gen/H_Supp_7_output.z= ip=20 =3D> the understanding is that a CA is constitute just by the MID pair, = independent of transport endpoint information or any address tuples in = general! This is an important aspect, also concerning some ServiceChange = procedures (e.g. handoff), where transport address information may = change, but not the MID value. -Albrecht > -----Original Message----- > From: Christian Groves [mailto:cngroves@internode.on.net]=20 > Sent: Mittwoch, 22. August 2007 06:20 > To: Gopalarathnam Sambasivan > Cc: megaco@ietf.org > Subject: Re: [Megaco] Regarding virtual MGs >=20 > Hello, >=20 > From a MGC perspective it should not be aware of the=20 > difference between a control association with a physical MG=20 > or with a VMG. >=20 > Regards, Christian >=20 > Gopalarathnam Sambasivan wrote: > > Hello All, > > Iam still not convinced by the concept of each VMG in a physical MG=20 > > needs to have a unique IP+port. > > Please read the following theoritical description of a MG=20 > and let me=20 > > know if it is in any contradiction with any of the RFCs=20 > including RFC3525. > >=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=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=3D=3D A physical gateway has a physical = interface card for IP=20 > > and various other cards for connecting telephone lines,.... > > This physical interface is configured having only 1 IP and=20 > 1 port used=20 > > for communication with the MGCs. > > Say totally 4K subscrs are managed by this card. > > This is split across 4 MGCs with each 1K subscrs. > > Each Termination is configured with its own primary and=20 > secondary MGCs=20 > > and say 4 max failing MGC contacts. > > VGW1/1 to 1000 - MGC1, MGC1B (if MGC1 doesnt respond),MGC1C, MGC1D > > VGW2/1 to 1000 -MGC2..... and so on. > > Also, the RTP ports can be similarly allocated per MGC....... > > =20 > > Communications from MGC: > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > MG checks whether the MGC is the one controlling those terminations. > > Per termination - If there is modify/add/subtract from a MGC1 to > > VGW1/1 to 1000 it is done..... otherwise error reply. > > =20 > > Root or wildcard - If a MGC sends a modify for ROOT, MGC1 then all=20 > > terminations controlled by that MGC - > > VGW1/1 to 1000 are alone affected. > > =20 > > Communications from MG: > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > A notify VGW1/50 going offhook and dialling digits - needs=20 > to be sent=20 > > only to MGC1 which controls it. > > =20 > > Service change: > > ----------------------- > > When coming online, this MG does not send service change=20 > restart for=20 > > root termination, it sends service change restart for terminations=20 > > VGW1/1 to 1000 - > > VGW1/* to MGC1, VGW2/* to MGC2,.... > > =20 > > There is no need of seperate IP+port per VGW, as this I see the=20 > > handling is just internal logic of MG and its configuration=20 > > association with a MGC per termination.The termination-MGC=20 > association=20 > > needs to be checked for both communication from and to a MG, by the=20 > > MG. > > =20 > > Since Iam a more a tester basically, I do not know much about the=20 > > internal designs.... > > still, Handling of each requests is going to be processed=20 > via seperate=20 > > threads, internal temp memory needed,..... > > are all independent of the IP+port from which the message=20 > arrives....=20 > > also the actual processing itself need not be in the same=20 > card having=20 > > the interface - it depends on the realisation of MG.......... > >=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=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=3D > > =20 > > Please let me know if this theoritical description valid=20 > according to RFC. > > =20 > > Isn't there any GW which works like this ?? - a real GW=20 > supporting VGW > > - "The model does not > > require that other resources be statically allocated, just > > Terminations." > > =20 > > Please also let me know what are the practical difficulties in not=20 > > following same IP+port for all VGWs, if any. > > =20 > > Thanks in Advance. > > =20 > > Best Regards, > > Gopalarathnam. > > > > =20 > > On 8/19/07, *Ashish Singh* > > wrote: > > > > Hi Gopal, > > > > MGC should be able to handle Virtual MG or physical MG=20 > in the same > > way. > > MGC only requires some way to identify the VMG.=20 > Normally each VMG > > on the > > same physical MG uses the unique (IP + port), so MGC=20 > can identify the > > VMG on receiving any message. > > > > One more thing, VMG can change its (IP + port) through=20 > configuration > > interface while the H248 association is active. In this=20 > case, VMG > > indicate this to MGC by sending a Servicechange with=20 > new [ip adrr]: > > port. After this, MGC should expect to receive VMG=20 > messages from new > > address. > > > > The only thing VMG doesn't change during the tenure of H248 > > association > > is MID (Message Identifier). So MGC can use this field also to > > identify > > VMGs. > > > > My 2 cents :-) > > Ashish > > > > > > > > Gopalarathnam Sambasivan wrote: > > > Hello Jagan, All, > > > Thanks for your answer. But it still doesn't=20 > completely solve my > > query. > > > Iam working on a MGC and not on a MG. > > > The physical real MG that Iam using is a small=20 > audiocode gateway > > which > > > is not capable of handling multiple MGCs. > > > > > > I had the following configuration in my MGC. MG is done using > > simulator. > > > MGC had 2 Gateways (VGW) - 2 different logical names=20 > in MGC With the > > > same ip@. > > > I had all other configurations - DNs and other things=20 > needed for > > > making the call. > > > When I sent a restart service change for root=20 > termination from this > > > ip@ only one of the 2 VGW endpoints is made to=20 > in-service in the > > MGC. > > > If restart service change (1 terminations in 2 VGWs)=20 > seperately, > > same > > > configuration, > > > those terminations are in service in MGC and call is possible. > > > > > > A bug raised for the same has been rejected as configuration > > problem - > > > saying VGWs need to have its own IP@ (floating IP@)=20 > on the same > > > physical interface. > > > But Iam not fully convinced with this reply. 1=20 > physical gateway > > with x > > > VGW mapped to x IP@. > > > why should a service provider have x IP@ for 1 device??? > > > > > > Iam not able to find much info from the web for a GW product > > > supporting VGW with configuration details. > > > I saw a cisco product document - VXSM card for VoIP - > > > > > =20 > http://www.cisco.com/en/US/products/hw/gatecont/ps3869/product > s_configuration_guide_chapter09186a0080751588.html#wp1089696 > > =20 > ts_configuration_guide_chapter09186a0080751588.html#wp1089696> > > > > > =20 > ts_configuration_guide_chapter09186a0080751588.html#wp1089696 > > =20 > ts_configuration_guide_chapter09186a0080751588.html#wp1089696>> > > > but it is not clear whether it *can/must* have different IP@. > > > > > > Please let me know about some gateway which supports=20 > VGWs and its > > > configuration needs different ip@ or same ip@ can=20 > also be used. But > > > from rest of the configuration details it seems to be=20 > it should work > > > with same ip@ > > > > > > > > > If it must be different IP@, then why is there a RFC statement > > > > > > "ServiceChange may only be applied to a Termination or set of > > > Terminations partitioned to the Virtual MG or=20 > created (in the > > case of > > > ephemeral Terminations) by that Virtual MG." > > > > > > - only if ip@ and port be the same is there a need=20 > not to send root > > > and use Termination or set of termination alone. > > > Otherwise with ip@ and/or port a distinction - root=20 > handling can be > > > done by MG for its various VirtualMG. > > > > > > So, should MGC make a mark for virtual gateway, to know its > > virtual? > > > What MGC needs to do if service change restart root=20 > comes from a > > > Virtual MG by mistake and if it controls both the Virtual GWs? > > > > > > Thanks in advance. > > > > > > Best Regards, > > > Gopalarathnam. > > > > > > On 8/17/07, *Jagan Mohan* > > > > >> wrote: > > > > > > Before I answer to your queries, here is basic=20 > concept of how > > > virutal MGs would be implemented. > > > > > > There would be a profile on a MG, which has the=20 > info. about the > > > MGC to which it needs to register. You can have multiple > > profiles > > > and hence the MG can register to multiple MGCs. Any > > > physical/ephemeral termination on the MG would be=20 > associated > > with > > > only profile and hence associated with only one MGC. > > > > > > Please see my answers inline. > > > > > > Does MGC need to specifically remember it is a virtual GW? > > > >>> MGC is not aware that there are virtual GWs=20 > on a single > > > physical MG. It's the MG which needs to be aware of the > > > terminations associated with the particular MGC. > > > > > > How is the property of root termination per MGC?? Is there > > no need > > > for MGC to make any difference between MG and a Virtual MG > > and it is > > > complete responsibility or MG?? > > > >> Yes, it's the responsibility of the MG. > > > > > > What MGC needs to do if service change restart=20 > root comes from a > > > Virtual MG by mistake and if it controls both the=20 > Virtual GWs? > > > >> MGC treats virtual GWs as two separate MGs. > > > > > > Cheers, > > > Jagan > > > > > > > > > On 8/16/07, *Gopalarathnam Sambasivan* < > > s.gopalarathnam@gmail.com > > > > >> wrote: > > > > > > Hello All, > > > Can someone Please enlighten me with the concept of > > virtual MG > > > from MG point of view and more so from MGC=20 > point of view. > > > RFC3525, Sec 11.1 states > > > "Each virtual MG has its own Root=20 > Termination. In most > > > cases the > > > values for the properties of the Root=20 > Termination are > > > independently > > > settable by each MGC. Where there can only be one > > value, the > > > parameter is read-only to all but the Master MGC. > > > > > > ServiceChange may only be applied to a=20 > Termination or > > set of > > > Terminations partitioned to the Virtual MG=20 > or created (in > > > the case of > > > ephemeral Terminations) by that Virtual MG." > > > > > > Question: > > > =3D=3D=3D=3D=3D=3D=3D > > > Does MGC need to specifically remember it is=20 > a virtual GW? > > > How is the property of root termination per MGC?? Is > > there no > > > need for MGC to make any difference between MG and a > > Virtual > > > MG and it is > > > complete responsibility or MG?? > > > What MGC needs to do if service change restart root > > comes from > > > a Virtual MG by mistake and if it controls both the > > Virtual GWs? > > > > > > Please also let me know which commercially=20 > available GWs > > > support virtual MG. > > > > > > Thanks and Best Regards, > > > Gopalarathnam. > > > > > > > > > _______________________________________________ > > > Megaco mailing list > > > Megaco@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/megaco > > > > > > > > > > > > > > =20 > -------------------------------------------------------------- > ---------- > > > > > > _______________________________________________ > > > Megaco mailing list > > > Megaco@ietf.org > > > https://www1.ietf.org/mailman/listinfo/megaco > > > > > > > > >=20 > ---------------------------------------------------------------------- > > -- > > > > _______________________________________________ > > Megaco mailing list > > Megaco@ietf.org > > https://www1.ietf.org/mailman/listinfo/megaco > > =20 >=20 > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco >=20 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Tue Sep 04 02:13:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISRdy-0003By-Pu; Tue, 04 Sep 2007 02:12:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISRdx-0003Bn-Hz for megaco@ietf.org; Tue, 04 Sep 2007 02:12:09 -0400 Received: from owa.vocaltec.com ([212.143.64.50] helo=mailserver.vocaltec.co.il) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ISRdv-0005hd-RO for megaco@ietf.org; Tue, 04 Sep 2007 02:12:09 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Megaco] Reporting actual codec used in a call Date: Tue, 4 Sep 2007 09:14:06 +0300 Message-ID: <431F3BDE11BF2F42A22CBEFA36BD88A4F606D7@mailserver.vocaltec.local> In-Reply-To: <8BB8AD9870081C42B2B309E00352E4EAA4FC33@FRVELSMBS15.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Megaco] Reporting actual codec used in a call Thread-Index: AcfukAimccK204n2TfK1ad88BukXLwAI/MiAAAGoCCA= References: <431F3BDE11BF2F42A22CBEFA36BD88A4F606C1@mailserver.vocaltec.local><46D367AD.10408@internode.on.net><431F3BDE11BF2F42A22CBEFA36BD88A4F606D5@mailserver.vocaltec.local> <46DCAE61.60800@nteczone.com> <8BB8AD9870081C42B2B309E00352E4EAA4FC33@FRVELSMBS15.ad2.ad.alcatel.com> From: "Raphael Tryster" To: "Schwarz Albrecht" , "Christian Groves" X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Cc: megaco ietf X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: megaco-bounces@ietf.org Is B) something that doesn't exist yet and you are proposing it for = Megaco version 4? Raphael Tryster -----Original Message----- From: Schwarz Albrecht [mailto:Albrecht.Schwarz@alcatel-lucent.de]=20 Sent: Tuesday, September 04, 2007 8:39 AM To: Christian Groves; Raphael Tryster Cc: megaco ietf Subject: RE: [Megaco] Reporting actual codec used in a call Like to note that there are further aspects when using RTP = payload/packet type codepoint (PT) as information for used codec in a = call: 1) codec changes 2) multiple PTs in use e.g. due to telephone events for RFC 4733 packets 3) multiple PTs in use e.g. due to voiceband data services (V.152, T.38, = V.150.1, V.151) > > Raphael Tryster wrote: > > =20 > >> Is there any package that allows the MG to report to the=20 > MGC at the=20 > >> end of a call, which codec was actually used for the call? (As=20 > >> opposed to codec negotiation at the start of a call, which may=20 > >> produce I could see two ways: A) H.248.1 V3 & H.248.39 (see e.g. =A7 8.1 "Individual auditing of Local = and Remote SDP was introduced in H.248.1 Version 3") =3D> auditing of SDP "m=3D" and/or "a=3D" lines B) New H.248 Statistic "Used codec(s) in a IP call/RTP session" =3D> ordered list of media formats used (the first list item indicates = the last codec used)=20 -Albrecht > -----Original Message----- > From: Christian Groves [mailto:Christian.Groves@nteczone.com]=20 > Sent: Dienstag, 4. September 2007 03:01 > To: Raphael Tryster > Cc: megaco ietf > Subject: Re: [Megaco] Reporting actual codec used in a call >=20 > Hello Raphael, >=20 > I agree that it is not really specified what the initial=20 > value would be.=20 > I think your suggestion is a pragmatic one to define the=20 > behaviour when a codec has not been already selected. An=20 > alternative is to say that the MGC should not set the=20 > rtp/pltrans event until an initial codec is used but the MGC=20 > wouldn't know when this was. >=20 > This might be a candidate for an IG item. >=20 > Regards, Christian >=20 > Raphael Tryster wrote: > > Thank you, Christian. rtp/pltrans looks like a good way to=20 > report a=20 > > change in codec, but what about the initial value? Is there an=20 > > assumption here that the initial codec is the first one=20 > listed in the=20 > > SDP, and therefore an MG receiving rtp/pltrans in Events=20 > that chooses=20 > > another codec to start with should immediately notify rtp/pltrans? > > =20 > > Raphael Tryster > > > > -----Original Message----- > > From: Christian Groves [mailto:cngroves@internode.on.net] > > Sent: Tuesday, August 28, 2007 3:09 AM > > To: Raphael Tryster > > Cc: megaco ietf > > Subject: Re: [Megaco] Reporting actual codec used in a call > > > > Hello Raphael, > > > > There's to payload transition event in the RTP package that can be=20 > > used, > > > > however its not linked to a subtract (end of call). > > > > Regards, Christian > > > > Raphael Tryster wrote: > > =20 > >> Is there any package that allows the MG to report to the=20 > MGC at the=20 > >> end of a call, which codec was actually used for the call? (As=20 > >> opposed to codec negotiation at the start of a call, which may=20 > >> produce > >> =20 > > > > =20 > >> a list of codecs, not all of which are actually used in the call). > >> > >> =20 > >> > >> Raphael Tryster > >> > >> > >> =20 > >=20 > ---------------------------------------------------------------------- > > -- > > =20 > >> _______________________________________________ > >> Megaco mailing list > >> Megaco@ietf.org > >> https://www1.ietf.org/mailman/listinfo/megaco > >> =20 > >> =20 > > > > > > =20 >=20 > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco >=20 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Tue Sep 04 05:53:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISV43-0001M0-K3; Tue, 04 Sep 2007 05:51:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISV41-0001Lt-NH for megaco@ietf.org; Tue, 04 Sep 2007 05:51:17 -0400 Received: from eci-iron.ecitele.com ([147.234.242.112] helo=iron.ecitele.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ISV40-0003YH-AE for megaco@ietf.org; Tue, 04 Sep 2007 05:51:17 -0400 Received: from ilptexfe.ecitele.com (HELO ILPTEXFE02.ecitele.com) ([147.234.245.181]) by eci-iron-out.ecitele.com with ESMTP; 04 Sep 2007 13:10:09 +0300 Received: from ILPTMAIL01.ecitele.com ([147.234.245.211]) by ILPTEXFE02.ecitele.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 4 Sep 2007 12:51:14 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 4 Sep 2007 12:51:14 +0300 Message-ID: In-Reply-To: <8BB8AD9870081C42B2B309E00352E4EA3C3A43@FRVELSMBS15.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Base root package properties Thread-Index: Ace+VLZRbDh1/5uqRcaqOz1XGZz5jwAANtdwAACFjVAAHKcAMAwDiADg References: <8BB8AD9870081C42B2B309E00352E4EA3C3A43@FRVELSMBS15.ad2.ad.alcatel.com> From: "Seraya Miletzki" To: X-OriginalArrivalTime: 04 Sep 2007 09:51:14.0765 (UTC) FILETIME=[21EA0FD0:01C7EED9] X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Subject: [Megaco] Base root package properties X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1241625944==" Errors-To: megaco-bounces@ietf.org This is a multi-part message in MIME format. --===============1241625944== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7EED9.21B10133" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7EED9.21B10133 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all =20 The values defined at the base root package properties are : any positive integer. According to this 0 is also a valid value. But, there is no meaning to 0 at this properties. The only property that has different values is : MaxNrOfContexts. Its default value is: 1 and up. =20 I think that the other properties should have similar definition to its value, For example : MaxTerminationsPerContext should be 2 and up and not just any positive integer=20 Please help me clarify this issue. Thanks =20 Seraya ------_=_NextPart_001_01C7EED9.21B10133 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 all
 
The=20 values defined at the base root package properties are : any positive integer. = According to=20 this 0 is also a valid=20 value.
But, = there is no=20 meaning to 0 at this properties.
The only = property=20 that has different values is : MaxNrOfContexts.=20 Its default value is: 1 and up.
 
I=20 think that the other properties should have similar definition to its = value, For=20 example : MaxTerminationsPerContext should be 2 and up and not just any positive = integer

Please help me clarify = this=20 issue.

Thanks

 

Seraya

<= /SPAN>
------_=_NextPart_001_01C7EED9.21B10133-- --===============1241625944== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============1241625944==-- From megaco-bounces@ietf.org Tue Sep 04 11:13:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISa4W-0000KT-MS; Tue, 04 Sep 2007 11:12:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISa4V-0000KN-GK for megaco@ietf.org; Tue, 04 Sep 2007 11:12:07 -0400 Received: from gc-na5.alcatel.fr ([64.208.49.5] helo=smail6.alcatel.fr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ISa4T-00046E-It for megaco@ietf.org; Tue, 04 Sep 2007 11:12:07 -0400 Received: from FRVELSBHS07.ad2.ad.alcatel.com (frvelsbhs07.ad2.ad.alcatel.com [155.132.6.79]) by smail6.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l84FBOQZ015889; Tue, 4 Sep 2007 17:11:32 +0200 Received: from FRVELSMBS15.ad2.ad.alcatel.com ([155.132.6.31]) by FRVELSBHS07.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Tue, 4 Sep 2007 17:11:58 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Megaco] Base root package properties Date: Tue, 4 Sep 2007 17:11:57 +0200 Message-ID: <8BB8AD9870081C42B2B309E00352E4EAA50114@FRVELSMBS15.ad2.ad.alcatel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Megaco] Base root package properties Thread-Index: Ace+VLZRbDh1/5uqRcaqOz1XGZz5jwAANtdwAACFjVAAHKcAMAwDiADgAAsFBkA= References: <8BB8AD9870081C42B2B309E00352E4EA3C3A43@FRVELSMBS15.ad2.ad.alcatel.com> From: "Schwarz Albrecht" To: "Seraya Miletzki" , X-OriginalArrivalTime: 04 Sep 2007 15:11:58.0089 (UTC) FILETIME=[EFD44790:01C7EF05] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.84 X-Spam-Score: 0.0 (/) X-Scan-Signature: dfc64cf6e4c6efdbf6b8f4c995df04df Cc: X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0189922168==" Errors-To: megaco-bounces@ietf.org This is a multi-part message in MIME format. --===============0189922168== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7EF05.EF963821" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7EF05.EF963821 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Seraya, =20 I'm tending to disagree. =20 root package properties: =20 maxNumberOfContexts =3D> no issue, 0 excluded maxTerminationsPerContext=20 =3D> right value range could be limited, but no issue [Note: there are valid services with one Termination per Context, = e.g. a standalone test scenario] normalMGExecutionTime=20 =3D> no issue, this is implementation specific, unit is ms!=20 [Note: just think about an implementation with a normal execution = time of 450 =B5s, which has to be rounded to 0 ms!] normalMGCExecutionTime=20 =3D> no issue, see above MGProvisionalResponseTimerValue=20 =3D> no issue, again related to a particular implementation of a = network .. MGCProvisionalResponseTimerValue=20 =3D> no issue, see above MGCOriginatedPendingLimit=20 =3D> no issue, this is implicit ("sth like a flow control mechanism = with a 'window size'") MGOriginatedPendingLimit=20 =3D> no issue, this is implicit ("sth like a flow control mechanism = with a 'window size'") =20 =20 Conclusion: there is a possible semantic for all seven root properties = with zero as possible value. -Albrecht ________________________________ From: Seraya Miletzki [mailto:Seraya.Miletzki@ecitele.com]=20 Sent: Dienstag, 4. September 2007 11:51 To: megaco@ietf.org Subject: [Megaco] Base root package properties =09 =09 Hi all =20 The values defined at the base root package properties are : any = positive integer. According to this 0 is also a valid value. But, there is no meaning to 0 at this properties. The only property that has different values is : MaxNrOfContexts. Its = default value is: 1 and up. =20 I think that the other properties should have similar definition to its = value, For example : MaxTerminationsPerContext should be 2 and up and = not just any positive integer=20 Please help me clarify this issue. Thanks =20 Seraya ------_=_NextPart_001_01C7EF05.EF963821 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Seraya,
 
I'm tending to disagree.
 
root package properties:
 
maxNumberOfContexts
    =3D> no issue, 0=20 excluded
maxTerminationsPerContext=20
    =3D> right value range = could be=20 limited, but no issue
    [Note: there are valid = services with=20 one Termination per Context, e.g. a standalone test=20 scenario]
normalMGExecutionTime =
    =3D> no issue, this is=20 implementation specific, unit is ms!
    [Note: just think about an = implementation with a normal execution time of 450 =B5s, which has to be = rounded=20 to 0 ms!]
normalMGCExecutionTime=20
    =3D> no issue, see=20 above
MGProvisionalResponseTimerValue=20
    =3D> no issue, again = related to a=20 particular implementation of a network=20 ..
MGCProvisionalResponseTimerValue=20
    =3D> no issue, see=20 above
MGCOriginatedPendingLimit=20
    =3D> no issue, this is = implicit=20 ("sth like a flow control mechanism with a 'window=20 size'")
MGOriginatedPendingLimit=20
    =3D> no issue, this is = implicit=20 ("sth like a flow control mechanism with a 'window=20 size'")
 
 
Conclusion: there is a possible semantic for all seven root = properties=20 with zero as possible value.
-Albrecht


From: Seraya Miletzki=20 [mailto:Seraya.Miletzki@ecitele.com]
Sent: Dienstag, 4. = September=20 2007 11:51
To: megaco@ietf.org
Subject: [Megaco] = Base root=20 package properties

Hi=20 all
 
The=20 values defined at the base root package properties are : any positive=20 integer. According to this 0 is = also a=20 valid value.
But, there=20 is no meaning to 0 at this properties.
The only=20 property that has different values is : MaxNrOfContexts.=20 Its default value is: 1 and up.
 
I=20 think that the other properties should have similar definition to its = value,=20 For example : MaxTerminationsPerContext should=20 be 2 and up and not just any positive integer=20

Please help me = clarify this=20 issue.

Thanks

 

Seraya

<= /SPAN>
------_=_NextPart_001_01C7EF05.EF963821-- --===============0189922168== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============0189922168==-- From megaco-bounces@ietf.org Tue Sep 04 14:03:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISciU-0000S2-Km; Tue, 04 Sep 2007 14:01:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISciT-0000Oq-MS for megaco@ietf.org; Tue, 04 Sep 2007 14:01:33 -0400 Received: from smail5.alcatel.fr ([62.23.212.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ISciS-0007uO-61 for megaco@ietf.org; Tue, 04 Sep 2007 14:01:33 -0400 Received: from FRVELSBHS05.ad2.ad.alcatel.com (frvelsbhs05.ad2.ad.alcatel.com [155.132.6.77]) by smail5.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l84I0tXd002310; Tue, 4 Sep 2007 20:00:55 +0200 Received: from FRVELSMBS15.ad2.ad.alcatel.com ([155.132.6.31]) by FRVELSBHS05.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Tue, 4 Sep 2007 20:01:26 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Megaco] Reporting actual codec used in a call Date: Tue, 4 Sep 2007 20:01:26 +0200 Message-ID: <8BB8AD9870081C42B2B309E00352E4EAA501BB@FRVELSMBS15.ad2.ad.alcatel.com> In-Reply-To: <431F3BDE11BF2F42A22CBEFA36BD88A4F606D7@mailserver.vocaltec.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Megaco] Reporting actual codec used in a call Thread-Index: AcfukAimccK204n2TfK1ad88BukXLwAI/MiAAAGoCCAAGHv+IA== References: <431F3BDE11BF2F42A22CBEFA36BD88A4F606C1@mailserver.vocaltec.local><46D367AD.10408@internode.on.net><431F3BDE11BF2F42A22CBEFA36BD88A4F606D5@mailserver.vocaltec.local> <46DCAE61.60800@nteczone.com> <8BB8AD9870081C42B2B309E00352E4EAA4FC33@FRVELSMBS15.ad2.ad.alcatel.com> <431F3BDE11BF2F42A22CBEFA36BD88A4F606D7@mailserver.vocaltec.local> From: "Schwarz Albrecht" To: "Raphael Tryster" , "Christian Groves" X-OriginalArrivalTime: 04 Sep 2007 18:01:26.0932 (UTC) FILETIME=[9CEE9540:01C7EF1D] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.13 X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Cc: megaco ietf X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: megaco-bounces@ietf.org 'B' does not yet exist. Such a statistic should be a package issue, i.e. not related to a = specific H.248.1 protocol version. [Please note that I wouldn't see here a Context-level statistic (which = could mean V4), it should be on H.248 Termination- and/or Stream-level = (due to possible media conversion between Stream-/Terminations, e.g. = voice transcoding). As ususual for existing H.248 statistics.]=20 -Albrecht > -----Original Message----- > From: Raphael Tryster [mailto:raphael.tryster@vocaltec.com]=20 > Sent: Dienstag, 4. September 2007 08:14 > To: Schwarz Albrecht; Christian Groves > Cc: megaco ietf > Subject: RE: [Megaco] Reporting actual codec used in a call >=20 > Is B) something that doesn't exist yet and you are proposing=20 > it for Megaco version 4? >=20 > Raphael Tryster >=20 > -----Original Message----- > From: Schwarz Albrecht [mailto:Albrecht.Schwarz@alcatel-lucent.de] > Sent: Tuesday, September 04, 2007 8:39 AM > To: Christian Groves; Raphael Tryster > Cc: megaco ietf > Subject: RE: [Megaco] Reporting actual codec used in a call >=20 > Like to note that there are further aspects when using RTP=20 > payload/packet type codepoint (PT) as information for used=20 > codec in a call: > 1) codec changes > 2) multiple PTs in use e.g. due to telephone events for RFC=20 > 4733 packets > 3) multiple PTs in use e.g. due to voiceband data services=20 > (V.152, T.38, V.150.1, V.151) >=20 > > > Raphael Tryster wrote: > > > =20 > > >> Is there any package that allows the MG to report to the > > MGC at the > > >> end of a call, which codec was actually used for the call? (As=20 > > >> opposed to codec negotiation at the start of a call, which may=20 > > >> produce >=20 > I could see two ways: >=20 > A) H.248.1 V3 & H.248.39 (see e.g. =A7 8.1 "Individual auditing=20 > of Local and Remote SDP was introduced in H.248.1 Version 3") > =3D> auditing of SDP "m=3D" and/or "a=3D" lines >=20 > B) New H.248 Statistic "Used codec(s) in a IP call/RTP session" > =3D> ordered list of media formats used (the first list=20 > item indicates the last codec used)=20 >=20 > -Albrecht >=20 >=20 > > -----Original Message----- > > From: Christian Groves [mailto:Christian.Groves@nteczone.com] > > Sent: Dienstag, 4. September 2007 03:01 > > To: Raphael Tryster > > Cc: megaco ietf > > Subject: Re: [Megaco] Reporting actual codec used in a call > >=20 > > Hello Raphael, > >=20 > > I agree that it is not really specified what the initial=20 > value would=20 > > be. > > I think your suggestion is a pragmatic one to define the behaviour=20 > > when a codec has not been already selected. An alternative=20 > is to say=20 > > that the MGC should not set the rtp/pltrans event until an initial=20 > > codec is used but the MGC wouldn't know when this was. > >=20 > > This might be a candidate for an IG item. > >=20 > > Regards, Christian > >=20 > > Raphael Tryster wrote: > > > Thank you, Christian. rtp/pltrans looks like a good way to > > report a > > > change in codec, but what about the initial value? Is there an=20 > > > assumption here that the initial codec is the first one > > listed in the > > > SDP, and therefore an MG receiving rtp/pltrans in Events > > that chooses > > > another codec to start with should immediately notify rtp/pltrans? > > > =20 > > > Raphael Tryster > > > > > > -----Original Message----- > > > From: Christian Groves [mailto:cngroves@internode.on.net] > > > Sent: Tuesday, August 28, 2007 3:09 AM > > > To: Raphael Tryster > > > Cc: megaco ietf > > > Subject: Re: [Megaco] Reporting actual codec used in a call > > > > > > Hello Raphael, > > > > > > There's to payload transition event in the RTP package=20 > that can be=20 > > > used, > > > > > > however its not linked to a subtract (end of call). > > > > > > Regards, Christian > > > > > > Raphael Tryster wrote: > > > =20 > > >> Is there any package that allows the MG to report to the > > MGC at the > > >> end of a call, which codec was actually used for the call? (As=20 > > >> opposed to codec negotiation at the start of a call, which may=20 > > >> produce > > >> =20 > > > > > > =20 > > >> a list of codecs, not all of which are actually used in=20 > the call). > > >> > > >> =20 > > >> > > >> Raphael Tryster > > >> > > >> > > >> =20 > > >=20 > >=20 > ---------------------------------------------------------------------- > > > -- > > > =20 > > >> _______________________________________________ > > >> Megaco mailing list > > >> Megaco@ietf.org > > >> https://www1.ietf.org/mailman/listinfo/megaco > > >> =20 > > >> =20 > > > > > > > > > =20 > >=20 > > _______________________________________________ > > Megaco mailing list > > Megaco@ietf.org > > https://www1.ietf.org/mailman/listinfo/megaco > >=20 >=20 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Tue Sep 04 19:29:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISho7-0004aU-Ce; Tue, 04 Sep 2007 19:27:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISho6-0004aO-4g for megaco@ietf.org; Tue, 04 Sep 2007 19:27:42 -0400 Received: from ipmail02.adl2.internode.on.net ([203.16.214.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ISho3-0008Dq-Rp for megaco@ietf.org; Tue, 04 Sep 2007 19:27:42 -0400 X-IronPort-AV: E=Sophos;i="4.20,208,1186324200"; d="scan'208";a="181757143" Received: from ppp59-167-133-157.lns3.mel6.internode.on.net (HELO [127.0.0.1]) ([59.167.133.157]) by ipmail02.adl2.internode.on.net with ESMTP; 05 Sep 2007 08:56:36 +0930 Message-ID: <46DDE9AA.1070409@nteczone.com> Date: Wed, 05 Sep 2007 09:26:34 +1000 From: Christian Groves User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Schwarz Albrecht Subject: Re: [Megaco] Reporting actual codec used in a call References: <431F3BDE11BF2F42A22CBEFA36BD88A4F606C1@mailserver.vocaltec.local><46D367AD.10408@internode.on.net><431F3BDE11BF2F42A22CBEFA36BD88A4F606D5@mailserver.vocaltec.local> <46DCAE61.60800@nteczone.com> <8BB8AD9870081C42B2B309E00352E4EAA4FC33@FRVELSMBS15.ad2.ad.alcatel.com> <431F3BDE11BF2F42A22CBEFA36BD88A4F606D7@mailserver.vocaltec.local> <8BB8AD9870081C42B2B309E00352E4EAA501BB@FRVELSMBS15.ad2.ad.alcatel.com> In-Reply-To: <8BB8AD9870081C42B2B309E00352E4EAA501BB@FRVELSMBS15.ad2.ad.alcatel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -1.0 (-) X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c Cc: megaco ietf , Raphael Tryster X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: megaco-bounces@ietf.org Hello Raphael, I tend to agree with Albrecht. H.248.1v4 wouldn't be needed for this. However the statistic would probably be closely related to H.248.1v3 which allows statistics at a stream level. Regards, Christian Schwarz Albrecht wrote: > 'B' does not yet exist. > Such a statistic should be a package issue, i.e. not related to a specific H.248.1 protocol version. > > [Please note that I wouldn't see here a Context-level statistic (which could mean V4), it should be on H.248 Termination- and/or Stream-level (due to possible media conversion between Stream-/Terminations, e.g. voice transcoding). As ususual for existing H.248 statistics.] > > -Albrecht > > >> -----Original Message----- >> From: Raphael Tryster [mailto:raphael.tryster@vocaltec.com] >> Sent: Dienstag, 4. September 2007 08:14 >> To: Schwarz Albrecht; Christian Groves >> Cc: megaco ietf >> Subject: RE: [Megaco] Reporting actual codec used in a call >> >> Is B) something that doesn't exist yet and you are proposing >> it for Megaco version 4? >> >> Raphael Tryster >> >> -----Original Message----- >> From: Schwarz Albrecht [mailto:Albrecht.Schwarz@alcatel-lucent.de] >> Sent: Tuesday, September 04, 2007 8:39 AM >> To: Christian Groves; Raphael Tryster >> Cc: megaco ietf >> Subject: RE: [Megaco] Reporting actual codec used in a call >> >> Like to note that there are further aspects when using RTP >> payload/packet type codepoint (PT) as information for used >> codec in a call: >> 1) codec changes >> 2) multiple PTs in use e.g. due to telephone events for RFC >> 4733 packets >> 3) multiple PTs in use e.g. due to voiceband data services >> (V.152, T.38, V.150.1, V.151) >> >> >>>> Raphael Tryster wrote: >>>> >>>> >>>>> Is there any package that allows the MG to report to the >>>>> >>> MGC at the >>> >>>>> end of a call, which codec was actually used for the call? (As >>>>> opposed to codec negotiation at the start of a call, which may >>>>> produce >>>>> >> I could see two ways: >> >> A) H.248.1 V3 & H.248.39 (see e.g. § 8.1 "Individual auditing >> of Local and Remote SDP was introduced in H.248.1 Version 3") >> => auditing of SDP "m=" and/or "a=" lines >> >> B) New H.248 Statistic "Used codec(s) in a IP call/RTP session" >> => ordered list of media formats used (the first list >> item indicates the last codec used) >> >> -Albrecht >> >> >> >>> -----Original Message----- >>> From: Christian Groves [mailto:Christian.Groves@nteczone.com] >>> Sent: Dienstag, 4. September 2007 03:01 >>> To: Raphael Tryster >>> Cc: megaco ietf >>> Subject: Re: [Megaco] Reporting actual codec used in a call >>> >>> Hello Raphael, >>> >>> I agree that it is not really specified what the initial >>> >> value would >> >>> be. >>> I think your suggestion is a pragmatic one to define the behaviour >>> when a codec has not been already selected. An alternative >>> >> is to say >> >>> that the MGC should not set the rtp/pltrans event until an initial >>> codec is used but the MGC wouldn't know when this was. >>> >>> This might be a candidate for an IG item. >>> >>> Regards, Christian >>> >>> Raphael Tryster wrote: >>> >>>> Thank you, Christian. rtp/pltrans looks like a good way to >>>> >>> report a >>> >>>> change in codec, but what about the initial value? Is there an >>>> assumption here that the initial codec is the first one >>>> >>> listed in the >>> >>>> SDP, and therefore an MG receiving rtp/pltrans in Events >>>> >>> that chooses >>> >>>> another codec to start with should immediately notify rtp/pltrans? >>>> >>>> Raphael Tryster >>>> >>>> -----Original Message----- >>>> From: Christian Groves [mailto:cngroves@internode.on.net] >>>> Sent: Tuesday, August 28, 2007 3:09 AM >>>> To: Raphael Tryster >>>> Cc: megaco ietf >>>> Subject: Re: [Megaco] Reporting actual codec used in a call >>>> >>>> Hello Raphael, >>>> >>>> There's to payload transition event in the RTP package >>>> >> that can be >> >>>> used, >>>> >>>> however its not linked to a subtract (end of call). >>>> >>>> Regards, Christian >>>> >>>> Raphael Tryster wrote: >>>> >>>> >>>>> Is there any package that allows the MG to report to the >>>>> >>> MGC at the >>> >>>>> end of a call, which codec was actually used for the call? (As >>>>> opposed to codec negotiation at the start of a call, which may >>>>> produce >>>>> >>>>> >>>> >>>> >>>>> a list of codecs, not all of which are actually used in >>>>> >> the call). >> >>>>> >>>>> >>>>> Raphael Tryster >>>>> >>>>> >>>>> >>>>> >> ---------------------------------------------------------------------- >> >>>> -- >>>> >>>> >>>>> _______________________________________________ >>>>> Megaco mailing list >>>>> Megaco@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/megaco >>>>> >>>>> >>>>> >>>> >>>> >>> _______________________________________________ >>> Megaco mailing list >>> Megaco@ietf.org >>> https://www1.ietf.org/mailman/listinfo/megaco >>> >>> > > > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From kreem@ProtechATV.com Tue Sep 04 21:39:38 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISjrm-0000mQ-Ej for megaco-archive@lists.ietf.org; Tue, 04 Sep 2007 21:39:38 -0400 Received: from [125.191.95.46] (helo=[125.191.95.46]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ISjrl-0003CC-PF for megaco-archive@lists.ietf.org; Tue, 04 Sep 2007 21:39:38 -0400 Received: from hxgsfyl2d81aap9 ([104.101.2.101] helo=hxgsfyl2d81aap9) by [125.191.95.46] ( sendmail 8.13.3/8.13.1) with esmtpa id 1yehPN-000TQD-Os for megaco-archive@lists.ietf.org; Wed, 5 Sep 2007 10:39:51 +0900 Message-ID: <000701c7ef5d$9c8c35e0$2e5fbf7d@hxgsfyl2d81aap9> From: "kreem Sellar" To: Subject: stupite Date: Wed, 5 Sep 2007 10:39:34 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C7EFA9.0C73DDE0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 3.9 (+++) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 ------=_NextPart_000_0008_01C7EFA9.0C73DDE0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable http://www.diasoul.com/ Good day megaco-archive With the advance in science.... cock enlargement is now possible without = expensive surgery Julia Sylvester ------=_NextPart_000_0008_01C7EFA9.0C73DDE0 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable
http://www.diasoul.com/
Good day megaco-archive
With the advance in science.... cock = enlargement is now=20 possible without expensive surgery
Julia Sylvester
------=_NextPart_000_0008_01C7EFA9.0C73DDE0-- From baxterOliphant@acmecolorink.com Wed Sep 05 02:37:20 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISoVr-0006xT-Uh for megaco-archive@lists.ietf.org; Wed, 05 Sep 2007 02:37:19 -0400 Received: from host86-12-static.14-79-b.business.telecomitalia.it ([79.14.12.86]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ISoVq-0001qQ-Ul for megaco-archive@lists.ietf.org; Wed, 05 Sep 2007 02:37:19 -0400 Received: by 10.176.56.174 with SMTP id tyxFypjFjyEiu; Wed, 5 Sep 2007 08:37:24 +0200 (GMT) Received: by 192.168.193.37 with SMTP id XrogxSgDIlJzeW.1113383436395; Wed, 5 Sep 2007 08:37:22 +0200 (GMT) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 5 Sep 2007 08:37:19 +0200 To: megaco-archive@lists.ietf.org From: "baxter Oliphant" Subject: tiloz Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 3.0 (+++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Hi bro baxter why not stand out from the crowd and enlarge your manhood Leains Pehlke http://www.disnniy.com/ From nary_Fayyaz@anwaltskanzlei-rohwedder.de Wed Sep 05 06:41:04 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISsJk-0004Rl-7q for megaco-archive@lists.ietf.org; Wed, 05 Sep 2007 06:41:04 -0400 Received: from host243-116-dynamic.56-82-r.retail.telecomitalia.it ([82.56.116.243]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ISsJj-0000hI-JM for megaco-archive@lists.ietf.org; Wed, 05 Sep 2007 06:41:04 -0400 Received: from ACER ([148.188.196.100]:16160 "EHLO ACER" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by host243-116-dynamic.56-82-r.retail.telecomitalia.it with ESMTP id S22LHCROBNPNGRXD (ORCPT ); Wed, 5 Sep 2007 12:41:29 +0200 Date: Wed, 5 Sep 2007 12:41:01 +0200 From: "nary Fayyaz" Reply-To: "nary Fayyaz" Message-ID: <803985897016.765933238219@anwaltskanzlei-rohwedder.de> To: Subject: 1954 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original X-Spam-Score: 4.0 (++++) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Yo Fayyaz life is short, dont have a small cock all your life mingfeng Kelliher http://www.divcerse.com/ From megaco-bounces@ietf.org Thu Sep 06 07:24:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITFRr-0000xD-OC; Thu, 06 Sep 2007 07:22:59 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITFRn-0000ws-F2 for megaco@ietf.org; Thu, 06 Sep 2007 07:22:56 -0400 Received: from owa.vocaltec.com ([212.143.64.50] helo=mailserver.vocaltec.co.il) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ITFRm-0006dL-4W for megaco@ietf.org; Thu, 06 Sep 2007 07:22:55 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Megaco] Question about RTP payloadtype Date: Thu, 6 Sep 2007 14:24:55 +0300 Message-ID: <431F3BDE11BF2F42A22CBEFA36BD88A4F606DD@mailserver.vocaltec.local> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Megaco] Question about RTP payloadtype Thread-Index: AcJ/fzbNPp4kkggRSfmaSYfkPIGmo4rh7fyA References: From: "Raphael Tryster" To: "Christian Groves" X-Spam-Score: 0.0 (/) X-Scan-Signature: 919b3965bd46f7460d234f848680b238 Cc: megaco@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2122090756==" Errors-To: megaco-bounces@ietf.org This is a multi-part message in MIME format. --===============2122090756== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7F078.8CE07F52" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7F078.8CE07F52 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This is a continuation of a thread that I started a few days ago, but the exchange below from 5 years ago is somewhat relevant, as it establishes that the rtppltype parameter of rtp/pltrans does not refer to Rx/Tx. My question is then, what is the meaning of rtppltype being of type sublist of enumeration? Syntactically, I assume this means something like =20 ObservedEvents =3D 1111 { 20070906T141539 : rtp/pltrans { rtppltype =3D [g723, g729] } } =20 But what does it mean semantically? How could it happen that two payload type transitions are reported in the same notification? =20 If all but the last payload type in the list is being reported with a delay, what is the mechanism by which this delayed reporting is engineered? Is there a way that the MGC could request buffering of such events, and then have them all reported at once by requesting that ObservedEvents be included in the reply to Subtract? =20 Raphael Tryster =20 ________________________________ From: Terry L Anderson [mailto:tlatla@verizon.net]=20 Sent: Tuesday, October 29, 2002 8:55 PM To: Christian Groves Cc: Seunghan Choi; megaco@ietf.org Subject: Re: [Megaco] Question about RTP payloadtype =20 Agreed. We would need to bump the version of the package. Perhaps we should add a note to rtp v1 and add a parameter to rtp v2 Christian Groves wrote: G'Day, =20 The assumption behind E.12 was that the payload was symmetrical. We could add a note stating this but I believe the additional of an extra parameter is beyond an IG item. There no way to add an extra parameter to an event and maintain backward compatibility, it would have to be a new event. =20 Regards, Christian =20 That is a very good issue. There is no parameter in the current event notice to indicate which of the two payloads changed. While many use symmetric payload types this is certainly not a requirement. I suppose we should consider adding a parameter of enumeration type with values of send, recv, sendRecv to include with the notice. =20 Kevin Boyle is our new Implementors Guide editor (as of the end of the SG16 meeting today, I am handing over the editorship rather than do that as well as rapporteur). Kevin can propose a fix for discussion on the list. =20 Seunghan Choi wrote: =20 =20 Hi, All. =20 Is there the case that RTPpayload type(Rx CodecType) in localDescriptor and RTPpayload type(Tx CodecType) in remoteDescriptor is different? If there is that case, Which does the rtppltype mean, Rx CodecType or Tx CodecType, in E.12 Payload Transition? =20 Thanks. =20 =20 =20 =20 =20 =20 =20 ------_=_NextPart_001_01C7F078.8CE07F52 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This is a continuation of a thread = that I started a few days ago, but the exchange below from 5 years ago is = somewhat relevant, as it establishes that the rtppltype parameter of rtp/pltrans does not = refer to Rx/Tx.  My question is then, what is the meaning of rtppltype being = of type sublist of enumeration?  Syntactically, I assume this means = something like

 

ObservedEvents =3D 1111 { = 20070906T141539 : rtp/pltrans { rtppltype =3D [g723, g729] } }

 

But what does it mean semantically? =  How could it happen that two payload type transitions are reported in the = same notification?

 

If all but the last payload type in = the list is being reported with a delay, what is the mechanism by which this = delayed reporting is engineered?  Is there a way that the MGC could request buffering of such events, and then have them all reported at once by = requesting that ObservedEvents be included in the reply to = Subtract?

 

Raphael Tryster

 


From: Terry = L Anderson [mailto:tlatla@verizon.net]
Sent: Tuesday, October = 29, 2002 8:55 PM
To: Christian Groves
Cc: Seunghan Choi; = megaco@ietf.org
Subject: Re: [Megaco] = Question about RTP payloadtype

 

Agreed.  We would need to bump the version of the package.  Perhaps we should add a note to rtp v1 and add a parameter to rtp = v2

Christian Groves wrote:

G'Day,
 
The =
assumption behind E.12 was that the payload was symmetrical. We could =
add a
note =
stating this but I believe the additional of an extra parameter is =
beyond
an IG =
item. There no way to add an extra parameter to an event and =
maintain
backward =
compatibility, it would have to be a new =
event.
 
Regards,  =
Christian
 
That is a =
very good issue. There is no parameter in the current =
event
notice to =
indicate which of the two payloads changed. While many =
use
symmetric =
payload types this is certainly not a requirement. I =
suppose
we should =
consider adding a parameter of enumeration type with values =
of
send, =
recv, sendRecv to include with the =
notice.
 
Kevin =
Boyle is our new Implementors Guide editor (as of the end of =
the
SG16 =
meeting today, I am handing over the editorship rather than do =
that
as well =
as rapporteur). Kevin can propose a fix for discussion on the =
list.
 
Seunghan =
Choi wrote:
 
  =
Hi, =
All.
 
Is there =
the case that RTPpayload type(Rx CodecType) in localDescriptor and =
RTPpayload type(Tx CodecType) in remoteDescriptor is =
different?
If there =
is that case, Which does the rtppltype mean, Rx CodecType or Tx =
CodecType, in E.12 Payload =
Transition?
 
Thanks.
 
    =
 
 
 
  =

 

------_=_NextPart_001_01C7F078.8CE07F52-- --===============2122090756== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============2122090756==-- From megaco-bounces@ietf.org Thu Sep 06 09:27:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITHMu-00058P-UV; Thu, 06 Sep 2007 09:26:00 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITHMt-00057n-TU for megaco@ietf.org; Thu, 06 Sep 2007 09:26:00 -0400 Received: from colt-na7.alcatel.fr ([62.23.212.7] helo=smail6.alcatel.fr) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ITHMs-0001lz-CR for megaco@ietf.org; Thu, 06 Sep 2007 09:25:59 -0400 Received: from FRVELSBHS06.ad2.ad.alcatel.com (frvelsbhs06.ad2.ad.alcatel.com [155.132.6.78]) by smail6.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l86DPE0d015831; Thu, 6 Sep 2007 15:25:18 +0200 Received: from FRVELSMBS15.ad2.ad.alcatel.com ([155.132.6.31]) by FRVELSBHS06.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Thu, 6 Sep 2007 15:25:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Megaco] Question about RTP payloadtype Date: Thu, 6 Sep 2007 15:25:44 +0200 Message-ID: <8BB8AD9870081C42B2B309E00352E4EAAC0EAA@FRVELSMBS15.ad2.ad.alcatel.com> In-Reply-To: <431F3BDE11BF2F42A22CBEFA36BD88A4F606DD@mailserver.vocaltec.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Megaco] Question about RTP payloadtype Thread-Index: AcJ/fzbNPp4kkggRSfmaSYfkPIGmo4rh7fyAAARoGBA= References: <431F3BDE11BF2F42A22CBEFA36BD88A4F606DD@mailserver.vocaltec.local> From: "Schwarz Albrecht" To: "Raphael Tryster" , "Christian Groves" X-OriginalArrivalTime: 06 Sep 2007 13:25:44.0407 (UTC) FILETIME=[6DA51670:01C7F089] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.84 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2f46977da373544777a750d5247d6ccc Cc: megaco@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0245176503==" Errors-To: megaco-bounces@ietf.org This is a multi-part message in MIME format. --===============0245176503== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7F089.6D88972E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7F089.6D88972E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable rtp/pltrans is an event, thus for the Rx flow only ("the semantic is not explicitly extended on the Tx flow as well, as e.g. done in H.248.40"). Right? =20 If my understanding is correct, the the semantic means RTP payload type changes just of the remote RTP endpoint. =20 Guess your rtppltype list is correct. =20 -Albrecht =20 ________________________________ From: Raphael Tryster [mailto:raphael.tryster@vocaltec.com]=20 Sent: Donnerstag, 6. September 2007 13:25 To: Christian Groves Cc: megaco@ietf.org Subject: RE: [Megaco] Question about RTP payloadtype =09 =09 This is a continuation of a thread that I started a few days ago, but the exchange below from 5 years ago is somewhat relevant, as it establishes that the rtppltype parameter of rtp/pltrans does not refer to Rx/Tx. My question is then, what is the meaning of rtppltype being of type sublist of enumeration? Syntactically, I assume this means something like =20 ObservedEvents =3D 1111 { 20070906T141539 : rtp/pltrans { rtppltype =3D [g723, g729] } } =20 But what does it mean semantically? How could it happen that two payload type transitions are reported in the same notification? =20 If all but the last payload type in the list is being reported with a delay, what is the mechanism by which this delayed reporting is engineered? Is there a way that the MGC could request buffering of such events, and then have them all reported at once by requesting that ObservedEvents be included in the reply to Subtract? =20 Raphael Tryster =20 =09 ________________________________ From: Terry L Anderson [mailto:tlatla@verizon.net]=20 Sent: Tuesday, October 29, 2002 8:55 PM To: Christian Groves Cc: Seunghan Choi; megaco@ietf.org Subject: Re: [Megaco] Question about RTP payloadtype =20 Agreed. We would need to bump the version of the package. Perhaps we should add a note to rtp v1 and add a parameter to rtp v2 =09 Christian Groves wrote: =09 =09 G'Day, =20 The assumption behind E.12 was that the payload was symmetrical. We could add a note stating this but I believe the additional of an extra parameter is beyond an IG item. There no way to add an extra parameter to an event and maintain backward compatibility, it would have to be a new event. =20 Regards, Christian =20 That is a very good issue. There is no parameter in the current event notice to indicate which of the two payloads changed. While many use symmetric payload types this is certainly not a requirement. I suppose we should consider adding a parameter of enumeration type with values of send, recv, sendRecv to include with the notice. =20 Kevin Boyle is our new Implementors Guide editor (as of the end of the SG16 meeting today, I am handing over the editorship rather than do that as well as rapporteur). Kevin can propose a fix for discussion on the list. =20 Seunghan Choi wrote: =20 =20 Hi, All. =20 Is there the case that RTPpayload type(Rx CodecType) in localDescriptor and RTPpayload type(Tx CodecType) in remoteDescriptor is different? If there is that case, Which does the rtppltype mean, Rx CodecType or Tx CodecType, in E.12 Payload Transition? =20 Thanks. =20 =20 =20 =20 =20 =20 =20 ------_=_NextPart_001_01C7F089.6D88972E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
rtp/pltrans is an event, thus for the Rx flow = only=20 ("the semantic is not explicitly extended on the Tx flow as well, as = e.g. done=20 in H.248.40"). Right?
 
If my understanding is correct, the the = semantic means=20 RTP payload type changes just of the remote RTP = endpoint.
 
Guess your rtppltype list is=20 correct.
 
-Albrecht
 


From: Raphael Tryster=20 [mailto:raphael.tryster@vocaltec.com]
Sent: Donnerstag, 6.=20 September 2007 13:25
To: Christian Groves
Cc:=20 megaco@ietf.org
Subject: RE: [Megaco] Question about RTP=20 payloadtype

This is a=20 continuation of a thread that I started a few days ago, but the = exchange below=20 from 5 years ago is somewhat relevant, as it establishes that the = rtppltype=20 parameter of rtp/pltrans does not refer to Rx/Tx.  My question is = then,=20 what is the meaning of rtppltype being of type sublist of enumeration? =  Syntactically, I assume this means something=20 like

 

ObservedEvents =3D 1111=20 { 20070906T141539 : rtp/pltrans { rtppltype =3D [g723, g729] }=20 }

 

But what = does it mean=20 semantically?  How could it happen that two payload type = transitions are=20 reported in the same notification?

 

If all but = the last=20 payload type in the list is being reported with a delay, what is the = mechanism=20 by which this delayed reporting is engineered?  Is there a way = that the=20 MGC could request buffering of such events, and then have them all = reported at=20 once by requesting that ObservedEvents be included in the reply to=20 Subtract?

 

Raphael=20 Tryster

 


From: Terry L=20 Anderson [mailto:tlatla@verizon.net]
Sent:
Tuesday, October 29, 2002 = 8:55=20 PM
To: Christian=20 Groves
Cc: Seunghan = Choi;=20 megaco@ietf.org
Subject: Re:=20 [Megaco] Question about RTP = payloadtype

 

Agreed.  We would need to bump the = version of the=20 package.  Perhaps we should add a note to rtp v1 and add a = parameter to=20 rtp v2

Christian Groves = wrote:

G'Day,
 
The assumption behind E.12 =
was that the payload was symmetrical. We could add =
a
note stating this but I believe =
the additional of an extra parameter is =
beyond
an IG item. There no way to add =
an extra parameter to an event and =
maintain
backward compatibility, it =
would have to be a new event.
 
Regards,  =
Christian
 
That is a very good issue. =
There is no parameter in the current =
event
notice to indicate which of the =
two payloads changed. While many =
use
symmetric payload types this is =
certainly not a requirement. I =
suppose
we should consider adding a =
parameter of enumeration type with values =
of
send, recv, sendRecv to include =
with the notice.
 
Kevin Boyle is our new =
Implementors Guide editor (as of the end of =
the
SG16 meeting today, I am =
handing over the editorship rather than do =
that
as well as rapporteur). Kevin =
can propose a fix for discussion on the =
list.
 
Seunghan Choi =
wrote:
 
  =
Hi, =
All.
 
Is there the case that =
RTPpayload type(Rx CodecType) in localDescriptor and RTPpayload type(Tx =
CodecType) in remoteDescriptor is =
different?
If there is that case, Which =
does the rtppltype mean, Rx CodecType or Tx CodecType, in E.12 Payload =
Transition?
 
Thanks.
 
    =
 
 
 
  =

 

------_=_NextPart_001_01C7F089.6D88972E-- --===============0245176503== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============0245176503==-- From megaco-bounces@ietf.org Thu Sep 06 09:39:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITHY6-0000FT-7W; Thu, 06 Sep 2007 09:37:34 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITHY4-0000FC-B4 for megaco@ietf.org; Thu, 06 Sep 2007 09:37:32 -0400 Received: from owa.vocaltec.com ([212.143.64.50] helo=mailserver.vocaltec.co.il) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ITHY2-0002BI-C1 for megaco@ietf.org; Thu, 06 Sep 2007 09:37:31 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Megaco] Question about RTP payloadtype Date: Thu, 6 Sep 2007 16:39:31 +0300 Message-ID: <431F3BDE11BF2F42A22CBEFA36BD88A4F606E0@mailserver.vocaltec.local> In-Reply-To: <8BB8AD9870081C42B2B309E00352E4EAAC0EAA@FRVELSMBS15.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Megaco] Question about RTP payloadtype Thread-Index: AcJ/fzbNPp4kkggRSfmaSYfkPIGmo4rh7fyAAARoGBAAALvt0A== References: <431F3BDE11BF2F42A22CBEFA36BD88A4F606DD@mailserver.vocaltec.local> <8BB8AD9870081C42B2B309E00352E4EAAC0EAA@FRVELSMBS15.ad2.ad.alcatel.com> From: "Raphael Tryster" To: "Schwarz Albrecht" , "Christian Groves" X-Spam-Score: 0.0 (/) X-Scan-Signature: 778b456acd32f555185589e04d062871 Cc: megaco@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1830040635==" Errors-To: megaco-bounces@ietf.org This is a multi-part message in MIME format. --===============1830040635== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7F08B.5A87889E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7F08B.5A87889E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Albrecht, =20 What you wrote clarifies the discussion of 5 years ago, but I am still puzzled why a list and not a single value. Clearly, the RTP payload cannot change to multiple different values at the same time. That suggests that changes that occurred at different times are being reported together, and I am wondering how this would be done. =20 Raphael Tryster=20 =20 ________________________________ From: Schwarz Albrecht [mailto:Albrecht.Schwarz@alcatel-lucent.de]=20 Sent: Thursday, September 06, 2007 4:26 PM To: Raphael Tryster; Christian Groves Cc: megaco@ietf.org Subject: RE: [Megaco] Question about RTP payloadtype =20 rtp/pltrans is an event, thus for the Rx flow only ("the semantic is not explicitly extended on the Tx flow as well, as e.g. done in H.248.40"). Right? =20 If my understanding is correct, the the semantic means RTP payload type changes just of the remote RTP endpoint. =20 Guess your rtppltype list is correct. =20 -Albrecht =20 =20 =09 ________________________________ From: Raphael Tryster [mailto:raphael.tryster@vocaltec.com]=20 Sent: Donnerstag, 6. September 2007 13:25 To: Christian Groves Cc: megaco@ietf.org Subject: RE: [Megaco] Question about RTP payloadtype This is a continuation of a thread that I started a few days ago, but the exchange below from 5 years ago is somewhat relevant, as it establishes that the rtppltype parameter of rtp/pltrans does not refer to Rx/Tx. My question is then, what is the meaning of rtppltype being of type sublist of enumeration? Syntactically, I assume this means something like =20 ObservedEvents =3D 1111 { 20070906T141539 : rtp/pltrans { rtppltype =3D [g723, g729] } } =20 But what does it mean semantically? How could it happen that two payload type transitions are reported in the same notification? =20 If all but the last payload type in the list is being reported with a delay, what is the mechanism by which this delayed reporting is engineered? Is there a way that the MGC could request buffering of such events, and then have them all reported at once by requesting that ObservedEvents be included in the reply to Subtract? =20 Raphael Tryster =20 =09 ________________________________ From: Terry L Anderson [mailto:tlatla@verizon.net]=20 Sent: Tuesday, October 29, 2002 8:55 PM To: Christian Groves Cc: Seunghan Choi; megaco@ietf.org Subject: Re: [Megaco] Question about RTP payloadtype =20 Agreed. We would need to bump the version of the package. Perhaps we should add a note to rtp v1 and add a parameter to rtp v2 =09 Christian Groves wrote: G'Day, =20 The assumption behind E.12 was that the payload was symmetrical. We could add a note stating this but I believe the additional of an extra parameter is beyond an IG item. There no way to add an extra parameter to an event and maintain backward compatibility, it would have to be a new event. =20 Regards, Christian =20 That is a very good issue. There is no parameter in the current event notice to indicate which of the two payloads changed. While many use symmetric payload types this is certainly not a requirement. I suppose we should consider adding a parameter of enumeration type with values of send, recv, sendRecv to include with the notice. =20 Kevin Boyle is our new Implementors Guide editor (as of the end of the SG16 meeting today, I am handing over the editorship rather than do that as well as rapporteur). Kevin can propose a fix for discussion on the list. =20 Seunghan Choi wrote: =20 =20 Hi, All. =20 Is there the case that RTPpayload type(Rx CodecType) in localDescriptor and RTPpayload type(Tx CodecType) in remoteDescriptor is different? If there is that case, Which does the rtppltype mean, Rx CodecType or Tx CodecType, in E.12 Payload Transition? =20 Thanks. =20 =20 =20 =20 =20 =20 =20 ------_=_NextPart_001_01C7F08B.5A87889E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Albrecht,

 

What you wrote clarifies the = discussion of 5 years ago, but I am still puzzled why a list and not a single value. =  Clearly, the RTP payload cannot change to multiple different values at the same = time.  That suggests that changes that occurred at different times are being = reported together, and I am wondering how this would be = done.

 

Raphael Tryster

 


From: = Schwarz Albrecht [mailto:Albrecht.Schwarz@alcatel-lucent.de]
Sent: Thursday, September = 06, 2007 4:26 PM
To: Raphael = Tryster; Christian Groves
Cc: megaco@ietf.org
Subject: RE: [Megaco] = Question about RTP payloadtype

 

rtp/pltrans is an event, thus for the Rx flow only ("the semantic is not explicitly = extended on the Tx flow as well, as e.g. done in H.248.40"). = Right?

 

If my understanding is correct, the the semantic means RTP payload type = changes just of the remote RTP endpoint.

 

Guess = your rtppltype list is correct.

 

-Albrecht

 

 


From: Raphael = Tryster [mailto:raphael.tryster@vocaltec.com]
Sent: Donnerstag, 6. = September 2007 13:25
To: Christian Groves
Cc: megaco@ietf.org
Subject: RE: [Megaco] = Question about RTP payloadtype

This is a continuation of a thread = that I started a few days ago, but the exchange below from 5 years ago is = somewhat relevant, as it establishes that the rtppltype parameter of rtp/pltrans = does not refer to Rx/Tx.  My question is then, what is the meaning of = rtppltype being of type sublist of enumeration?  Syntactically, I assume this = means something like

 

ObservedEvents =3D 1111 { = 20070906T141539 : rtp/pltrans { rtppltype =3D [g723, g729] } = }

 

But what does it mean semantically?  How could it happen that two payload type transitions are reported = in the same notification?

 

If all but the last payload type in = the list is being reported with a delay, what is the mechanism by which this delayed reporting is engineered?  Is there a way that the MGC could request buffering of such events, and then have them all reported at = once by requesting that ObservedEvents be included in the reply to = Subtract?

 

Raphael Tryster

 


From: Terry = L Anderson [mailto:tlatla@verizon.net]
Sent: Tuesday, October = 29, 2002 8:55 PM
To: Christian Groves
Cc: Seunghan Choi; = megaco@ietf.org
Subject: Re: [Megaco] = Question about RTP payloadtype

 

Agreed. =  We would need to bump the version of the package.  Perhaps we should add a = note to rtp v1 and add a parameter to rtp v2

Christian Groves wrote:

G'Day,
 
The =
assumption behind E.12 was that the payload was symmetrical. We could =
add a
note =
stating this but I believe the additional of an extra parameter is =
beyond
an IG =
item. There no way to add an extra parameter to an event and =
maintain
backward =
compatibility, it would have to be a new =
event.
 
Regards,  =
Christian
 
That is a =
very good issue. There is no parameter in the current =
event
notice to =
indicate which of the two payloads changed. While many =
use
symmetric =
payload types this is certainly not a requirement. I =
suppose
we should =
consider adding a parameter of enumeration type with values =
of
send, =
recv, sendRecv to include with the =
notice.
 
Kevin =
Boyle is our new Implementors Guide editor (as of the end of =
the
SG16 =
meeting today, I am handing over the editorship rather than do =
that
as well =
as rapporteur). Kevin can propose a fix for discussion on the =
list.
 
Seunghan =
Choi wrote:
 
  =
Hi, =
All.
 
Is there =
the case that RTPpayload type(Rx CodecType) in localDescriptor and =
RTPpayload type(Tx CodecType) in remoteDescriptor is =
different?
If there =
is that case, Which does the rtppltype mean, Rx CodecType or Tx =
CodecType, in E.12 Payload =
Transition?
 
Thanks.
 
    =
 
 
 
  =

 

------_=_NextPart_001_01C7F08B.5A87889E-- --===============1830040635== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============1830040635==-- From megaco-bounces@ietf.org Thu Sep 06 11:44:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITJV2-00046G-SC; Thu, 06 Sep 2007 11:42:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITJV1-00046B-Rf for megaco@ietf.org; Thu, 06 Sep 2007 11:42:31 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ITJUz-0002jz-TT for megaco@ietf.org; Thu, 06 Sep 2007 11:42:31 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id B3CD3203E9; Thu, 6 Sep 2007 17:42:28 +0200 (CEST) X-AuditID: c1b4fb3c-aee7cbb0000007e1-f7-46e01fe4c57b Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 8C9702004E; Thu, 6 Sep 2007 17:42:28 +0200 (CEST) Received: from esealmw118.eemea.ericsson.se ([153.88.200.77]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Sep 2007 17:42:28 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Megaco] Question about RTP payloadtype Date: Thu, 6 Sep 2007 17:38:28 +0200 Message-ID: In-Reply-To: <431F3BDE11BF2F42A22CBEFA36BD88A4F606E0@mailserver.vocaltec.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Megaco] Question about RTP payloadtype Thread-Index: AcJ/fzbNPp4kkggRSfmaSYfkPIGmo4rh7fyAAARoGBAAALvt0AAD24vA From: "Stephen Mell (CV/ETL)" To: "Raphael Tryster" X-OriginalArrivalTime: 06 Sep 2007 15:42:28.0074 (UTC) FILETIME=[876954A0:01C7F09C] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 3d2cbbe10c97d56c753ea98882cec394 Cc: Christian Groves , megaco@ietf.org, Schwarz Albrecht X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1533895619==" Errors-To: megaco-bounces@ietf.org This is a multi-part message in MIME format. --===============1533895619== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7F09C.8765FF14" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7F09C.8765FF14 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Raphael, =20 Perhaps this multiple payload type would be used when transiting to a compression codec which supplemeted by non-periodic packets with a different payload type - for example RFC2833 Out-Of-Band RTP events or VAD packets for the purposes of comfort noise generation, these will always use a different payload type to the periodic compression codec. =20 By the time that the Rx media handling engine has detected the change in codec (received at least N periodic packets of the new compressed codec) and wishes to report it, there is a slim chance that some of the non-periodic (supplementary) packets have also been received as well, so the MG may report Received periodic and non-periodic codec types in the pltrans event =20 Does that sound feasible? =20 Steve=20 =20 ________________________________ From: Raphael Tryster [mailto:raphael.tryster@vocaltec.com]=20 Sent: 06 September 2007 14:40 To: Schwarz Albrecht; Christian Groves Cc: megaco@ietf.org Subject: RE: [Megaco] Question about RTP payloadtype Albrecht, =20 What you wrote clarifies the discussion of 5 years ago, but I am still puzzled why a list and not a single value. Clearly, the RTP payload cannot change to multiple different values at the same time. That suggests that changes that occurred at different times are being reported together, and I am wondering how this would be done. =20 Raphael Tryster=20 =20 ________________________________ From: Schwarz Albrecht [mailto:Albrecht.Schwarz@alcatel-lucent.de]=20 Sent: Thursday, September 06, 2007 4:26 PM To: Raphael Tryster; Christian Groves Cc: megaco@ietf.org Subject: RE: [Megaco] Question about RTP payloadtype =20 rtp/pltrans is an event, thus for the Rx flow only ("the semantic is not explicitly extended on the Tx flow as well, as e.g. done in H.248.40"). Right? =20 If my understanding is correct, the the semantic means RTP payload type changes just of the remote RTP endpoint. =20 Guess your rtppltype list is correct. =20 -Albrecht =20 =20 =09 ________________________________ From: Raphael Tryster [mailto:raphael.tryster@vocaltec.com]=20 Sent: Donnerstag, 6. September 2007 13:25 To: Christian Groves Cc: megaco@ietf.org Subject: RE: [Megaco] Question about RTP payloadtype This is a continuation of a thread that I started a few days ago, but the exchange below from 5 years ago is somewhat relevant, as it establishes that the rtppltype parameter of rtp/pltrans does not refer to Rx/Tx. My question is then, what is the meaning of rtppltype being of type sublist of enumeration? Syntactically, I assume this means something like =20 ObservedEvents =3D 1111 { 20070906T141539 : rtp/pltrans { rtppltype =3D [g723, g729] } } =20 But what does it mean semantically? How could it happen that two payload type transitions are reported in the same notification? =20 If all but the last payload type in the list is being reported with a delay, what is the mechanism by which this delayed reporting is engineered? Is there a way that the MGC could request buffering of such events, and then have them all reported at once by requesting that ObservedEvents be included in the reply to Subtract? =20 Raphael Tryster =20 =09 ________________________________ From: Terry L Anderson [mailto:tlatla@verizon.net]=20 Sent: Tuesday, October 29, 2002 8:55 PM To: Christian Groves Cc: Seunghan Choi; megaco@ietf.org Subject: Re: [Megaco] Question about RTP payloadtype =20 Agreed. We would need to bump the version of the package. Perhaps we should add a note to rtp v1 and add a parameter to rtp v2 =09 Christian Groves wrote: G'Day, =20 The assumption behind E.12 was that the payload was symmetrical. We could add a note stating this but I believe the additional of an extra parameter is beyond an IG item. There no way to add an extra parameter to an event and maintain backward compatibility, it would have to be a new event. =20 Regards, Christian =20 That is a very good issue. There is no parameter in the current event notice to indicate which of the two payloads changed. While many use symmetric payload types this is certainly not a requirement. I suppose we should consider adding a parameter of enumeration type with values of send, recv, sendRecv to include with the notice. =20 Kevin Boyle is our new Implementors Guide editor (as of the end of the SG16 meeting today, I am handing over the editorship rather than do that as well as rapporteur). Kevin can propose a fix for discussion on the list. =20 Seunghan Choi wrote: =20 =20 Hi, All. =20 Is there the case that RTPpayload type(Rx CodecType) in localDescriptor and RTPpayload type(Tx CodecType) in remoteDescriptor is different? If there is that case, Which does the rtppltype mean, Rx CodecType or Tx CodecType, in E.12 Payload Transition? =20 Thanks. =20 =20 =20 =20 =20 =20 =20 ------_=_NextPart_001_01C7F09C.8765FF14 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Raphael,
 
Perhaps this multiple payload type would be = used when=20 transiting to a compression codec which supplemeted by non-periodic = packets=20 with a different payload type - for example RFC2833 Out-Of-Band RTP = events or=20 VAD packets for the purposes of comfort noise generation, = these will always=20 use a different payload type to the periodic compression=20 codec.
 
By the time that the Rx media handling engine = has detected=20 the change in codec (received at least N periodic packets of the new = compressed=20 codec) and wishes to report it, there is a slim chance that some of the=20 non-periodic (supplementary) packets have also been received as well, so = the MG=20 may report Received periodic and non-periodic codec types in the pltrans = event
 
Does that sound feasible?
 
Steve
 

From: = Raphael Tryster=20 [mailto:raphael.tryster@vocaltec.com]
Sent: 06 September 2007 = 14:40
To: Schwarz Albrecht; Christian Groves
Cc:=20 megaco@ietf.org
Subject: RE: [Megaco] Question about RTP=20 payloadtype

Albrecht,

 

What you = wrote=20 clarifies the discussion of 5 years ago, but I am still puzzled why a = list and=20 not a single value.  Clearly, the RTP payload cannot change to = multiple=20 different values at the same time.  That suggests that changes that = occurred at different times are being reported together, and I am = wondering how=20 this would be done.

 

Raphael=20 Tryster=20

 


From: Schwarz=20 Albrecht [mailto:Albrecht.Schwarz@alcatel-lucent.de]
Sent:
Thursday, September 06, = 2007 4:26=20 PM
To: = Raphael = Tryster;=20 Christian Groves
Cc:=20 megaco@ietf.org
Subject: RE:=20 [Megaco] Question about RTP = payloadtype

 

rtp/pltrans is=20 an event, thus for the Rx flow only ("the semantic is not explicitly = extended on=20 the Tx flow as well, as e.g. done in H.248.40").=20 Right?

 

If my = understanding is correct, the the semantic means RTP payload type = changes just=20 of the remote RTP endpoint.

 

Guess = your=20 rtppltype list is correct.

 

-Albrecht

 

 


From:=20 Raphael=20 Tryster [mailto:raphael.tryster@vocaltec.com] =
Sent:
Donnerstag, 6. September = 2007=20 13:25
To: Christian = Groves
Cc:=20 megaco@ietf.org
Subject: RE:=20 [Megaco] Question about RTP payloadtype

This is a=20 continuation of a thread that I started a few days ago, but the = exchange below=20 from 5 years ago is somewhat relevant, as it establishes that the = rtppltype=20 parameter of rtp/pltrans does not refer to Rx/Tx.  My question is = then,=20 what is the meaning of rtppltype being of type sublist of enumeration? =  Syntactically, I assume this means something=20 like

 

ObservedEvents =3D 1111=20 { 20070906T141539 : rtp/pltrans { rtppltype =3D [g723, g729] }=20 }

 

But what = does it mean=20 semantically?  How could it happen that two payload type = transitions are=20 reported in the same notification?

 

If all but = the last=20 payload type in the list is being reported with a delay, what is the = mechanism=20 by which this delayed reporting is engineered?  Is there a way = that the=20 MGC could request buffering of such events, and then have them all = reported at=20 once by requesting that ObservedEvents be included in the reply to=20 Subtract?

 

Raphael=20 Tryster

 


From: Terry L=20 Anderson [mailto:tlatla@verizon.net]
Sent:
Tuesday, October 29, 2002 = 8:55=20 PM
To: Christian=20 Groves
Cc: Seunghan = Choi;=20 megaco@ietf.org
Subject: Re:=20 [Megaco] Question about RTP = payloadtype

 

Agreed.  We would need = to bump the=20 version of the package.  Perhaps we should add a note to rtp v1 = and add a=20 parameter to rtp v2

Christian Groves=20 wrote:

G'Day,
 
The assumption behind E.12 =
was that the payload was symmetrical. We could add =
a
note stating this but I believe =
the additional of an extra parameter is =
beyond
an IG item. There no way to add =
an extra parameter to an event and =
maintain
backward compatibility, it =
would have to be a new event.
 
Regards,  =
Christian
 
That is a very good issue. =
There is no parameter in the current =
event
notice to indicate which of the =
two payloads changed. While many =
use
symmetric payload types this is =
certainly not a requirement. I =
suppose
we should consider adding a =
parameter of enumeration type with values =
of
send, recv, sendRecv to include =
with the notice.
 
Kevin Boyle is our new =
Implementors Guide editor (as of the end of =
the
SG16 meeting today, I am =
handing over the editorship rather than do =
that
as well as rapporteur). Kevin =
can propose a fix for discussion on the =
list.
 
Seunghan Choi =
wrote:
 
  =
Hi, =
All.
 
Is there the case that =
RTPpayload type(Rx CodecType) in localDescriptor and RTPpayload type(Tx =
CodecType) in remoteDescriptor is =
different?
If there is that case, Which =
does the rtppltype mean, Rx CodecType or Tx CodecType, in E.12 Payload =
Transition?
 
Thanks.
 
    =
 
 
 
  =

 

------_=_NextPart_001_01C7F09C.8765FF14-- --===============1533895619== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============1533895619==-- From megaco-bounces@ietf.org Thu Sep 06 12:18:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITK2I-0002P3-GR; Thu, 06 Sep 2007 12:16:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITK2G-0002KB-PW for megaco@ietf.org; Thu, 06 Sep 2007 12:16:52 -0400 Received: from owa.tdsoft.com ([212.143.64.50] helo=mailserver.vocaltec.co.il) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ITK2E-000421-2i for megaco@ietf.org; Thu, 06 Sep 2007 12:16:52 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Megaco] Question about RTP payloadtype Date: Thu, 6 Sep 2007 19:18:50 +0300 Message-ID: <431F3BDE11BF2F42A22CBEFA36BD88A4F606E1@mailserver.vocaltec.local> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Megaco] Question about RTP payloadtype Thread-Index: AcJ/fzbNPp4kkggRSfmaSYfkPIGmo4rh7fyAAARoGBAAALvt0AAD24vAAADE2KA= References: <431F3BDE11BF2F42A22CBEFA36BD88A4F606E0@mailserver.vocaltec.local> From: "Raphael Tryster" To: "Stephen Mell (CV/ETL)" X-Spam-Score: 0.0 (/) X-Scan-Signature: d2ef8a017d8070cfdc3108436d3b9538 Cc: Christian Groves , megaco@ietf.org, Schwarz Albrecht X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0184943337==" Errors-To: megaco-bounces@ietf.org This is a multi-part message in MIME format. --===============0184943337== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7F0A1.9C5A044E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7F0A1.9C5A044E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Steve, =20 It doesn't sound plausible to me, because: =20 1. If things like VAD or RFC2833 were intended to be included in reports of a periodic payload transition, then it stands to reason that they should also be reported when there is no periodic payload transition. That could produce a barrage of notifications, and I doubt that is what the designers of rtp/pltrans had in mind. =20 2. If you ask me to deliver an envelope to someone outside the office, then while I am getting ready to leave the office you can add things that you remember at the last minute. That's because I am human and not a computer (some people dispute that). Computer programs generally have "left the office" as soon as they get a job to do, and would have to be complicated considerably to provide the kind of functionality you suggest. =20 So, unless one of the authors informs us otherwise, I'm betting they had something else in mind. =20 Raphael Tryster ________________________________ From: Stephen Mell (CV/ETL) [mailto:stephen.mell@ericsson.com]=20 Sent: Thursday, September 06, 2007 6:38 PM To: Raphael Tryster Cc: Schwarz Albrecht; Christian Groves; megaco@ietf.org Subject: RE: [Megaco] Question about RTP payloadtype =20 Raphael, =20 Perhaps this multiple payload type would be used when transiting to a compression codec which supplemeted by non-periodic packets with a different payload type - for example RFC2833 Out-Of-Band RTP events or VAD packets for the purposes of comfort noise generation, these will always use a different payload type to the periodic compression codec. =20 By the time that the Rx media handling engine has detected the change in codec (received at least N periodic packets of the new compressed codec) and wishes to report it, there is a slim chance that some of the non-periodic (supplementary) packets have also been received as well, so the MG may report Received periodic and non-periodic codec types in the pltrans event =20 Does that sound feasible? =20 Steve=20 =20 ________________________________ From: Raphael Tryster [mailto:raphael.tryster@vocaltec.com]=20 Sent: 06 September 2007 14:40 To: Schwarz Albrecht; Christian Groves Cc: megaco@ietf.org Subject: RE: [Megaco] Question about RTP payloadtype Albrecht, =20 What you wrote clarifies the discussion of 5 years ago, but I am still puzzled why a list and not a single value. Clearly, the RTP payload cannot change to multiple different values at the same time. That suggests that changes that occurred at different times are being reported together, and I am wondering how this would be done. =20 Raphael Tryster=20 =20 ________________________________ From: Schwarz Albrecht [mailto:Albrecht.Schwarz@alcatel-lucent.de]=20 Sent: Thursday, September 06, 2007 4:26 PM To: Raphael Tryster; Christian Groves Cc: megaco@ietf.org Subject: RE: [Megaco] Question about RTP payloadtype =20 rtp/pltrans is an event, thus for the Rx flow only ("the semantic is not explicitly extended on the Tx flow as well, as e.g. done in H.248.40"). Right? =20 If my understanding is correct, the the semantic means RTP payload type changes just of the remote RTP endpoint. =20 Guess your rtppltype list is correct. =20 -Albrecht =20 =20 =09 ________________________________ From: Raphael Tryster [mailto:raphael.tryster@vocaltec.com]=20 Sent: Donnerstag, 6. September 2007 13:25 To: Christian Groves Cc: megaco@ietf.org Subject: RE: [Megaco] Question about RTP payloadtype This is a continuation of a thread that I started a few days ago, but the exchange below from 5 years ago is somewhat relevant, as it establishes that the rtppltype parameter of rtp/pltrans does not refer to Rx/Tx. My question is then, what is the meaning of rtppltype being of type sublist of enumeration? Syntactically, I assume this means something like =20 ObservedEvents =3D 1111 { 20070906T141539 : rtp/pltrans { rtppltype =3D [g723, g729] } } =20 But what does it mean semantically? How could it happen that two payload type transitions are reported in the same notification? =20 If all but the last payload type in the list is being reported with a delay, what is the mechanism by which this delayed reporting is engineered? Is there a way that the MGC could request buffering of such events, and then have them all reported at once by requesting that ObservedEvents be included in the reply to Subtract? =20 Raphael Tryster =20 =09 ________________________________ From: Terry L Anderson [mailto:tlatla@verizon.net]=20 Sent: Tuesday, October 29, 2002 8:55 PM To: Christian Groves Cc: Seunghan Choi; megaco@ietf.org Subject: Re: [Megaco] Question about RTP payloadtype =20 Agreed. We would need to bump the version of the package. Perhaps we should add a note to rtp v1 and add a parameter to rtp v2 =09 Christian Groves wrote: G'Day, =20 The assumption behind E.12 was that the payload was symmetrical. We could add a note stating this but I believe the additional of an extra parameter is beyond an IG item. There no way to add an extra parameter to an event and maintain backward compatibility, it would have to be a new event. =20 Regards, Christian =20 That is a very good issue. There is no parameter in the current event notice to indicate which of the two payloads changed. While many use symmetric payload types this is certainly not a requirement. I suppose we should consider adding a parameter of enumeration type with values of send, recv, sendRecv to include with the notice. =20 Kevin Boyle is our new Implementors Guide editor (as of the end of the SG16 meeting today, I am handing over the editorship rather than do that as well as rapporteur). Kevin can propose a fix for discussion on the list. =20 Seunghan Choi wrote: =20 =20 Hi, All. =20 Is there the case that RTPpayload type(Rx CodecType) in localDescriptor and RTPpayload type(Tx CodecType) in remoteDescriptor is different? If there is that case, Which does the rtppltype mean, Rx CodecType or Tx CodecType, in E.12 Payload Transition? =20 Thanks. =20 =20 =20 =20 =20 =20 =20 ------_=_NextPart_001_01C7F0A1.9C5A044E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Steve,

 

It doesn’t sound plausible to = me, because:

 

1.       = If things like VAD or RFC2833 were = intended to be included in reports of a periodic payload transition, then it stands to = reason that they should also be reported when there is no periodic payload = transition.  That could produce a barrage of notifications, and I doubt that is = what the designers of rtp/pltrans had in = mind.

 

2.       = If you ask me to deliver an envelope to = someone outside the office, then while I am getting ready to leave the office you can = add things that you remember at the last minute.  That’s because = I am human and not a computer (some people dispute that).  Computer programs generally have “left the office” as soon as they get a job = to do, and would have to be complicated considerably to provide the kind of functionality you suggest.

 

So, unless one of the authors = informs us otherwise, I’m betting they had something else in = mind.

 

Raphael Tryster


From: = Stephen Mell (CV/ETL) [mailto:stephen.mell@ericsson.com]
Sent: Thursday, September = 06, 2007 6:38 PM
To: Raphael = Tryster
Cc: Schwarz Albrecht; = Christian Groves; megaco@ietf.org
Subject: RE: [Megaco] = Question about RTP payloadtype

 

Raphael,

 

Perhaps this multiple payload type = would be used when transiting to a compression codec which supplemeted by non-periodic packets with a different payload type - for example RFC2833 Out-Of-Band RTP events or VAD packets for the purposes of comfort noise generation, these will always use a different payload type to = the periodic compression codec.

 

By the time that the Rx media = handling engine has detected the change in codec (received at least N periodic = packets of the new compressed codec) and wishes to report it, there is a slim = chance that some of the non-periodic (supplementary) packets have also been = received as well, so the MG may report Received periodic and non-periodic codec = types in the pltrans event

 

Does that sound = feasible?

 

Steve

 


From: Raphael = Tryster [mailto:raphael.tryster@vocaltec.com]
Sent: 06 September 2007 = 14:40
To: Schwarz Albrecht; = Christian Groves
Cc: megaco@ietf.org
Subject: RE: [Megaco] = Question about RTP payloadtype

Albrecht,

 

What you wrote clarifies the = discussion of 5 years ago, but I am still puzzled why a list and not a single value.  Clearly, the RTP payload cannot change to multiple different = values at the same time.  That suggests that changes that occurred at = different times are being reported together, and I am wondering how this would be = done.

 

Raphael Tryster

 


From: = Schwarz Albrecht [mailto:Albrecht.Schwarz@alcatel-lucent.de]
Sent: Thursday, September = 06, 2007 4:26 PM
To: Raphael = Tryster; Christian Groves
Cc: megaco@ietf.org
Subject: RE: [Megaco] = Question about RTP payloadtype

 

rtp/pltrans is an event, thus for the Rx flow only ("the semantic is not explicitly = extended on the Tx flow as well, as e.g. done in H.248.40"). = Right?

 

If my understanding is correct, the the semantic means RTP payload type = changes just of the remote RTP endpoint.

 

Guess = your rtppltype list is correct.

 

-Albrecht

 

 


From: Raphael = Tryster [mailto:raphael.tryster@vocaltec.com]
Sent: Donnerstag, 6. = September 2007 13:25
To: Christian Groves
Cc: megaco@ietf.org
Subject: RE: [Megaco] = Question about RTP payloadtype

This is a continuation of a thread = that I started a few days ago, but the exchange below from 5 years ago is = somewhat relevant, as it establishes that the rtppltype parameter of rtp/pltrans = does not refer to Rx/Tx.  My question is then, what is the meaning of = rtppltype being of type sublist of enumeration?  Syntactically, I assume this = means something like

 

ObservedEvents =3D 1111 { = 20070906T141539 : rtp/pltrans { rtppltype =3D [g723, g729] } = }

 

But what does it mean semantically?  How could it happen that two payload type transitions are reported = in the same notification?

 

If all but the last payload type in = the list is being reported with a delay, what is the mechanism by which this delayed reporting is engineered?  Is there a way that the MGC could request buffering of such events, and then have them all reported at = once by requesting that ObservedEvents be included in the reply to = Subtract?

 

Raphael Tryster

 


From: Terry = L Anderson [mailto:tlatla@verizon.net]
Sent: Tuesday, October = 29, 2002 8:55 PM
To: Christian Groves
Cc: Seunghan Choi; = megaco@ietf.org
Subject: Re: [Megaco] = Question about RTP payloadtype

 

Agreed. =  We would need to bump the version of the package.  Perhaps we should add a = note to rtp v1 and add a parameter to rtp v2

Christian Groves wrote:

G'Day,
 
The =
assumption behind E.12 was that the payload was symmetrical. We could =
add a
note =
stating this but I believe the additional of an extra parameter is =
beyond
an IG =
item. There no way to add an extra parameter to an event and =
maintain
backward =
compatibility, it would have to be a new =
event.
 
Regards,  =
Christian
 
That is a =
very good issue. There is no parameter in the current =
event
notice to =
indicate which of the two payloads changed. While many =
use
symmetric =
payload types this is certainly not a requirement. I =
suppose
we should =
consider adding a parameter of enumeration type with values =
of
send, =
recv, sendRecv to include with the =
notice.
 
Kevin =
Boyle is our new Implementors Guide editor (as of the end of =
the
SG16 =
meeting today, I am handing over the editorship rather than do =
that
as well =
as rapporteur). Kevin can propose a fix for discussion on the =
list.
 
Seunghan =
Choi wrote:
 
  =
Hi, =
All.
 
Is there =
the case that RTPpayload type(Rx CodecType) in localDescriptor and =
RTPpayload type(Tx CodecType) in remoteDescriptor is =
different?
If there =
is that case, Which does the rtppltype mean, Rx CodecType or Tx =
CodecType, in E.12 Payload =
Transition?
 
Thanks.
 
    =
 
 
 
  =

 

------_=_NextPart_001_01C7F0A1.9C5A044E-- --===============0184943337== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============0184943337==-- From Sammonshycjv@gmsnet.com Thu Sep 06 12:38:44 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITKNQ-0001GR-Jc for megaco-archive@lists.ietf.org; Thu, 06 Sep 2007 12:38:44 -0400 Received: from [85.101.93.172] (helo=[85.101.93.172]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ITKNP-0008E8-Ni for megaco-archive@lists.ietf.org; Thu, 06 Sep 2007 12:38:44 -0400 Received: from [85.101.93.172] by ; Thu, 6 Sep 2007 18:30:49 +0200 From: Benton To: Subject: Re: Date: Thu, 6 Sep 2007 18:30:49 +0200 Message-ID: <01c7f0a4$5fae26e0$ac5d6555@Sammonshycjv> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal X-Spam-Score: 4.3 (++++) X-Scan-Signature: bb8eae9af85e4fcfe76f325e38493bf4 New pharmacy shop http://throwman.com From megaco-bounces@ietf.org Thu Sep 06 22:40:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITTjl-0002oc-Ja; Thu, 06 Sep 2007 22:38:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITTjk-0002oX-AZ for megaco@ietf.org; Thu, 06 Sep 2007 22:38:24 -0400 Received: from ipmail01.adl2.internode.on.net ([203.16.214.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ITTjh-0003y6-IW for megaco@ietf.org; Thu, 06 Sep 2007 22:38:24 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAPtV4EZ5LOmu/2dsb2JhbAAM X-IronPort-AV: E=Sophos;i="4.20,219,1186324200"; d="scan'208";a="187051039" Received: from ppp121-44-233-174.lns2.mel4.internode.on.net (HELO [127.0.0.1]) ([121.44.233.174]) by ipmail01.adl2.internode.on.net with ESMTP; 07 Sep 2007 12:08:06 +0930 Message-ID: <46E0B98B.1030002@nteczone.com> Date: Fri, 07 Sep 2007 12:38:03 +1000 From: Christian Groves User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Raphael Tryster Subject: Re: [Megaco] Question about RTP payloadtype References: <431F3BDE11BF2F42A22CBEFA36BD88A4F606E0@mailserver.vocaltec.local> <431F3BDE11BF2F42A22CBEFA36BD88A4F606E1@mailserver.vocaltec.local> In-Reply-To: <431F3BDE11BF2F42A22CBEFA36BD88A4F606E1@mailserver.vocaltec.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -1.0 (-) X-Scan-Signature: 72dbfff5c6b8ad2b1b727c13be042129 Cc: megaco@ietf.org, Schwarz Albrecht X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: megaco-bounces@ietf.org Hello Raphael, I believe that having the rtp/pltrans as a list of was to account for the case where an event was set and the MG detected a change in codec in both the send and receive directions. Events sit at a level higher than the local/remote descriptors so in theory it covers both. The list of allowed the notification of both directions to be signalled, e.g. able to notify when a change in codec on the received stream, able to notify when a MG autonomously decides to change the codec sent. I suspect that there wasn't more thought on specific use cases when it was added. The thread you pointed to highlights the issue but it seems that the note proposed back then didn't make it into an implementor's guide proposal. If we now add something to the IG then we need to agree on: a) what a single value in the list means b) what 2 values in the list means c) can there be more than 2? Some initial thoughts: On a) Does a single value mean a codec change in both the send/receive direction (symmetrical change) or only the receive direction? On b) I think we could easily say that the first value is the local value, the second is the remote On c) I can't see a case for three so we may be able to limit the list size to 2. I tried to find where the text originated to see if this could provide some more information. It seems it came from the period between the November 1999 Washington IETF meeting and the Feb 2000 ITU. However I can't find any email/contribution actually proposing it. Regards, Christian PS: Raphael, you need to update your address book I haven't worked Ericsson for some time now :-). Raphael Tryster wrote: > > Steve, > > It doesn’t sound plausible to me, because: > > 1. If things like VAD or RFC2833 were intended to be included in > reports of a periodic payload transition, then it stands to reason > that they should also be reported when there is no periodic payload > transition. That could produce a barrage of notifications, and I doubt > that is what the designers of rtp/pltrans had in mind. > > 2. If you ask me to deliver an envelope to someone outside the office, > then while I am getting ready to leave the office you can add things > that you remember at the last minute. That’s because I am human and > not a computer (some people dispute that). Computer programs generally > have “left the office” as soon as they get a job to do, and would have > to be complicated considerably to provide the kind of functionality > you suggest. > > So, unless one of the authors informs us otherwise, I’m betting they > had something else in mind. > > Raphael Tryster > > ------------------------------------------------------------------------ > > *From:* Stephen Mell (CV/ETL) [mailto:stephen.mell@ericsson.com] > *Sent:* Thursday, September 06, 2007 6:38 PM > *To:* Raphael Tryster > *Cc:* Schwarz Albrecht; Christian Groves; megaco@ietf.org > *Subject:* RE: [Megaco] Question about RTP payloadtype > > Raphael, > > Perhaps this multiple payload type would be used when transiting to a > compression codec which supplemeted by non-periodic packets with a > different payload type - for example RFC2833 Out-Of-Band RTP events or > VAD packets for the purposes of comfort noise generation, these will > always use a different payload type to the periodic compression codec. > > By the time that the Rx media handling engine has detected the change > in codec (received at least N periodic packets of the new compressed > codec) and wishes to report it, there is a slim chance that some of > the non-periodic (supplementary) packets have also been received as > well, so the MG may report Received periodic and non-periodic codec > types in the pltrans event > > Does that sound feasible? > > Steve > > ------------------------------------------------------------------------ > > *From:* Raphael Tryster [mailto:raphael.tryster@vocaltec.com] > *Sent:* 06 September 2007 14:40 > *To:* Schwarz Albrecht; Christian Groves > *Cc:* megaco@ietf.org > *Subject:* RE: [Megaco] Question about RTP payloadtype > > Albrecht, > > What you wrote clarifies the discussion of 5 years ago, but I am still > puzzled why a list and not a single value. Clearly, the RTP payload > cannot change to multiple different values at the same time. That > suggests that changes that occurred at different times are being > reported together, and I am wondering how this would be done. > > Raphael Tryster > > ------------------------------------------------------------------------ > > *From:* Schwarz Albrecht [mailto:Albrecht.Schwarz@alcatel-lucent.de] > *Sent:* Thursday, September 06, 2007 4:26 PM > *To:* Raphael Tryster; Christian Groves > *Cc:* megaco@ietf.org > *Subject:* RE: [Megaco] Question about RTP payloadtype > > rtp/pltrans is an event, thus for the Rx flow only ("the semantic is > not explicitly extended on the Tx flow as well, as e.g. done in > H.248.40"). Right? > > If my understanding is correct, the the semantic means RTP payload > type changes just of the remote RTP endpoint. > > Guess your rtppltype list is correct. > > -Albrecht > > ------------------------------------------------------------------------ > > *From:* Raphael Tryster [mailto:raphael.tryster@vocaltec.com] > *Sent:* Donnerstag, 6. September 2007 13:25 > *To:* Christian Groves > *Cc:* megaco@ietf.org > *Subject:* RE: [Megaco] Question about RTP payloadtype > > This is a continuation of a thread that I started a few days ago, > but the exchange below from 5 years ago is somewhat relevant, as > it establishes that the rtppltype parameter of rtp/pltrans does > not refer to Rx/Tx. My question is then, what is the meaning of > rtppltype being of type sublist of enumeration? Syntactically, I > assume this means something like > > ObservedEvents = 1111 { 20070906T141539 : rtp/pltrans { rtppltype > = [g723, g729] } } > > But what does it mean semantically? How could it happen that two > payload type transitions are reported in the same notification? > > If all but the last payload type in the list is being reported > with a delay, what is the mechanism by which this delayed > reporting is engineered? Is there a way that the MGC could request > buffering of such events, and then have them all reported at once > by requesting that ObservedEvents be included in the reply to > Subtract? > > Raphael Tryster > > ------------------------------------------------------------------------ > > *From:* Terry L Anderson [mailto:tlatla@verizon.net] > *Sent:* Tuesday, October 29, 2002 8:55 PM > *To:* Christian Groves > *Cc:* Seunghan Choi; megaco@ietf.org > *Subject:* Re: [Megaco] Question about RTP payloadtype > > Agreed. We would need to bump the version of the package. Perhaps > we should add a note to rtp v1 and add a parameter to rtp v2 > > Christian Groves wrote: > > G'Day, > > > > The assumption behind E.12 was that the payload was symmetrical. We could add a > > note stating this but I believe the additional of an extra parameter is beyond > > an IG item. There no way to add an extra parameter to an event and maintain > > backward compatibility, it would have to be a new event. > > > > Regards, Christian > > > > That is a very good issue. There is no parameter in the current event > > notice to indicate which of the two payloads changed. While many use > > symmetric payload types this is certainly not a requirement. I suppose > > we should consider adding a parameter of enumeration type with values of > > send, recv, sendRecv to include with the notice. > > > > Kevin Boyle is our new Implementors Guide editor (as of the end of the > > SG16 meeting today, I am handing over the editorship rather than do that > > as well as rapporteur). Kevin can propose a fix for discussion on the list. > > > > Seunghan Choi wrote: > > > > > >> Hi, All. >> >> Is there the case that RTPpayload type(Rx CodecType) in localDescriptor and RTPpayload type(Tx CodecType) in remoteDescriptor is different? >> If there is that case, Which does the rtppltype mean, Rx CodecType or Tx CodecType, in E.12 Payload Transition? >> >> Thanks. >> >> > > > > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From Tien250@oohla.net Fri Sep 07 07:31:06 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITc3G-0007DQ-Uw for megaco-archive@lists.ietf.org; Fri, 07 Sep 2007 07:31:06 -0400 Received: from host7-64-dynamic.53-82-r.retail.telecomitalia.it ([82.53.64.7] helo=host55-132-dynamic.18-79-r.retail.telecomitalia.it) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ITc3C-0005zV-8L for megaco-archive@lists.ietf.org; Fri, 07 Sep 2007 07:31:06 -0400 Received: from user-llxxlfizmu ([169.118.12.190]:29838 "EHLO user-llxxlfizmu" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by host55-132-dynamic.18-79-r.retail.telecomitalia.it with ESMTP id S22FWSLOXXLAPCQD (ORCPT ); Fri, 7 Sep 2007 13:31:20 +0200 Message-ID: <000901c7f142$91726f80$3784124f@userllxxlfizmu> From: "Tien Lanteigne" To: Subject: ;elgulb Date: Fri, 7 Sep 2007 13:31:01 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C7F153.54FB3F80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 4.7 (++++) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 ------=_NextPart_000_0005_01C7F153.54FB3F80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://gygge.com/ Wassup Tien Like millions of other males, I was not too happy with my penis size. so = i dont something about it Hetal Ferrari ------=_NextPart_000_0005_01C7F153.54FB3F80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://gygge.com/
Wassup Tien
Like millions of other males, I was not too = happy with=20 my penis size. so i dont something about it
Hetal Ferrari
------=_NextPart_000_0005_01C7F153.54FB3F80-- From Danyll_Larson@d576c0ec.kabel.telenet.be Fri Sep 07 10:20:53 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITehZ-0006To-12 for megaco-archive@lists.ietf.org; Fri, 07 Sep 2007 10:20:53 -0400 Received: from [219.251.162.232] (helo=[219.251.162.232]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ITehY-0006Hz-19 for megaco-archive@lists.ietf.org; Fri, 07 Sep 2007 10:20:52 -0400 Received: from samsung-b9266ad ([131.192.17.27] helo=samsung-b9266ad) by [219.251.162.232] ( sendmail 8.13.3/8.13.1) with esmtpa id 1LPggg-000QQM-gB for megaco-archive@lists.ietf.org; Fri, 7 Sep 2007 23:21:32 +0900 Message-ID: <42C7CEDB.96F808ED@d576c0ec.kabel.telenet.be> Date: Fri, 7 Sep 2007 23:20:57 +0900 From: "Danyll Larson" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: megaco-archive@lists.ietf.org Subject: ty|uskon Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 4.7 (++++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Yo Larson voted no.1 male enhancement product 2005 - 2007 Mens Health Inc Marissa Gerrop http://www.herritge.com/ From megaco-bounces@ietf.org Fri Sep 07 16:28:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITkPR-0006tK-60; Fri, 07 Sep 2007 16:26:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITkPQ-0006sU-67 for megaco@ietf.org; Fri, 07 Sep 2007 16:26:32 -0400 Received: from smtp105.rog.mail.re2.yahoo.com ([206.190.36.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ITkPP-000317-0m for megaco@ietf.org; Fri, 07 Sep 2007 16:26:32 -0400 Received: (qmail 72680 invoked from network); 7 Sep 2007 20:26:30 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:X-YMail-OSG:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding; b=iz4QUKgmgyi9WZqm9Ru9d0NZSDA03zA4lO0OuqTGmG5tqWSPMhODhDmeicIvjIHyd3V0PDyv+TMIg6h/UwU5FgYKReTjDWH/4yOakQjkclKpVBiornY1ip1fa6z29Zw2oEUYZmjq8Gkw/jtk8LDMtoD1Dsx+UPU4vMF52JXix+k= ; Received: from unknown (HELO ?192.168.0.100?) (tom.taylor@rogers.com@74.105.35.229 with plain) by smtp105.rog.mail.re2.yahoo.com with SMTP; 7 Sep 2007 20:26:30 -0000 X-YMail-OSG: xK5qtlgVM1mF70BBHy3WnuEdTDP0eW2vE1c2nQEJ34GJ0KUhrB_21emnAa.CuU7Bpg-- Message-ID: <46E1B3F9.6070107@rogers.com> Date: Fri, 07 Sep 2007 16:26:33 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: megaco@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Subject: [Megaco] [Fwd: Nomcom 2007-8: Nominations Close on Sep 10, 2007] X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: megaco-bounces@ietf.org -------- Original Message -------- Subject: Nomcom 2007-8: Nominations Close on Sep 10, 2007 Date: Fri, 07 Sep 2007 12:52:33 -0700 From: Lakshminath Dondeti To: ietf-announce@ietf.org, wgchairs@ietf.org, IESG IESG , IAB IAB WGchairs, IESG and IAB members Please forward this request to the lists you manage and request feedback and nominations. All, Here is the link to nominate: https://tools.ietf.org/group/nomcom/07/nominate You may also send nominations or comments via email to nomcom07@ietf.org or ldondeti@qualcomm.com. We have received very few nominations (1, 2, 2, 2, 3, 4, 8, 8, 19) and even fewer accepted (1-2 people in each area, IAB acceptances is 4 at last count). I request the community to provide feedback on the incumbents (send email or send notes via the web page). 1) If you think that the incumbent is doing a good job a) provide feedback AND b) nominate similar people just in case there is strong negative feedback on the incumbent 2) If you think the incumbent can do somethings better a) provide feedback AND b) nominate someone who you think might do better Candidates, if time commitment is the only issue, please indicate that to the nomcom and accept the nominations. thanks, Lakshminath _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From Moeiz-Ohta@abileneaccenthomes.com Sat Sep 08 04:39:45 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITvqz-0004e5-FJ for megaco-archive@lists.ietf.org; Sat, 08 Sep 2007 04:39:45 -0400 Received: from host153-33-static.45-85-b.business.telecomitalia.it ([85.45.33.153]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ITvqy-0000EF-Ub for megaco-archive@lists.ietf.org; Sat, 08 Sep 2007 04:39:45 -0400 Received: from OFFICINA ([165.162.101.135]:27994 "EHLO OFFICINA" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by host153-33-static.45-85-b.business.telecomitalia.it with ESMTP id S22AUHMCRTZYGSDH (ORCPT ); Sat, 8 Sep 2007 10:48:26 +0200 Message-ID: <000701c7f1f4$f1687ee0$99212d55@OFFICINA> From: "Moeiz Ohta" To: Subject: ostinsky Date: Sat, 8 Sep 2007 10:47:52 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C7F205.B4F14EE0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 4.1 (++++) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 ------=_NextPart_000_0009_01C7F205.B4F14EE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://www.halosout.com/ Hi bro megaco-archive are you one of many men unsatisfied with your penis size? Harijot Piercy ------=_NextPart_000_0009_01C7F205.B4F14EE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://www.halosout.com/
Hi bro megaco-archive
are you one of many men unsatisfied with your = penis size?
Harijot Piercy
------=_NextPart_000_0009_01C7F205.B4F14EE0-- From farlynmpz@convivia.co.uk Sat Sep 08 07:41:38 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITyh0-0007eO-9c for megaco-archive@lists.ietf.org; Sat, 08 Sep 2007 07:41:38 -0400 Received: from abpf224.neoplus.adsl.tpnet.pl ([83.8.47.224] helo=aboh91.neoplus.adsl.tpnet.pl) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ITygz-0004zp-Gt for megaco-archive@lists.ietf.org; Sat, 08 Sep 2007 07:41:38 -0400 Received: from klient-x077dk5i by convivia.co.uk with ASMTP id 27AB6840 for ; Sat, 8 Sep 2007 13:42:07 +0200 Received: from klient-x077dk5i ([128.179.167.179]) by convivia.co.uk with ESMTP id 883F78621A11 for ; Sat, 8 Sep 2007 13:42:07 +0200 Message-ID: <000d01c7f20d$3aa46f20$5b170853@klientx077dk5i> From: "Vladislav farly" To: Subject: me'gapho Date: Sat, 8 Sep 2007 13:41:43 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C7F21D.FE2D3F20" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 1.8 (+) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 ------=_NextPart_000_0004_01C7F21D.FE2D3F20 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable http://www.hljsoft.com/ Wassup farly With the advance in science.... cock enlargement is now possible without = expensive surgery afdasf Hosier ------=_NextPart_000_0004_01C7F21D.FE2D3F20 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
http://www.hljsoft.com/
Wassup farly
With the advance in science.... cock = enlargement is now=20 possible without expensive surgery
afdasf Hosier
------=_NextPart_000_0004_01C7F21D.FE2D3F20-- From Miele@blmss.com Sat Sep 08 07:44:05 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITyjN-0002Rf-Ne for megaco-archive@lists.ietf.org; Sat, 08 Sep 2007 07:44:05 -0400 Received: from 122-192-237-24.gci.net ([24.237.192.122] helo=84-18-178-69.gci.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ITyjN-000556-71 for megaco-archive@lists.ietf.org; Sat, 08 Sep 2007 07:44:05 -0400 Received: from amd3400 ([153.182.172.4] helo=amd3400) by 122-192-237-24.gci.net ( sendmail 8.13.3/8.13.1) with esmtpa id 1rMsHY-000IMB-hM for megaco-archive@lists.ietf.org; Sat, 8 Sep 2007 03:49:46 -0800 Message-ID: <000601c7f20e$4449ce20$7ac0ed18@amd3400> From: "Taneli Miele" To: Subject: tariokym Date: Sat, 8 Sep 2007 03:49:09 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C7F1CB.36268E20" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 4.1 (++++) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 ------=_NextPart_000_0008_01C7F1CB.36268E20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://www.hokecomm.com/ Wazzup megaco-archive ladies like em big, so i enlarged mine.. Miah McKeehen ------=_NextPart_000_0008_01C7F1CB.36268E20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://www.hokecomm.com/
Wazzup megaco-archive
ladies like em big, so i enlarged = mine..
Miah McKeehen
------=_NextPart_000_0008_01C7F1CB.36268E20-- From Baoquoc@orielhousing.org.uk Sat Sep 08 18:56:36 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IU9EC-00082G-2S for megaco-archive@lists.ietf.org; Sat, 08 Sep 2007 18:56:36 -0400 Received: from [89.106.113.223] (helo=vidin-119-54.vidaoptics.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IU9EA-0005hr-Gu for megaco-archive@lists.ietf.org; Sat, 08 Sep 2007 18:56:36 -0400 Received: from home-rganv6qyvj ([108.101.116.150]:12966 "EHLO home-rganv6qyvj" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by vidin-119-54.vidaoptics.com with ESMTP id S22IDZPUOJSTIMDR (ORCPT ); Sun, 9 Sep 2007 01:56:56 +0300 Message-ID: <000601c7f26b$7f758860$36776a59@homerganv6qyvj> From: "Baoquoc Hatlesatd" To: Subject: odraccil Date: Sun, 9 Sep 2007 01:56:31 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C7F284.A4C2C060" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 2.8 (++) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 ------=_NextPart_000_0003_01C7F284.A4C2C060 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable http://horsem.com/ How it is going megaco-archive wishing you had a bigger one-eyed wonder? and do something about it camila Grecynski ------=_NextPart_000_0003_01C7F284.A4C2C060 Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable
http://horsem.com/
How it is going megaco-archive
wishing you had a bigger one-eyed wonder? and = do=20 something about it
camila Grecynski
------=_NextPart_000_0003_01C7F284.A4C2C060-- From Laqui@BIONICK.RU Sun Sep 09 10:53:10 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUO9u-0004F0-Q1 for megaco-archive@lists.ietf.org; Sun, 09 Sep 2007 10:53:10 -0400 Received: from host237-90-dynamic.12-79-r.retail.telecomitalia.it ([79.12.90.237]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IUO9t-0006MZ-6T for megaco-archive@lists.ietf.org; Sun, 09 Sep 2007 10:53:10 -0400 Received: from computer1 ([103.180.16.60] helo=computer1) by host237-90-dynamic.12-79-r.retail.telecomitalia.it ( sendmail 8.13.3/8.13.1) with esmtpa id 1fuodb-000XLC-RK for megaco-archive@lists.ietf.org; Sun, 9 Sep 2007 16:48:09 +0200 Message-ID: <000c01c7f2f0$63187ad0$ed5a0c4f@computer1> From: "annie Laqui" To: Subject: renoorc Date: Sun, 9 Sep 2007 16:47:47 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C7F301.26A14AD0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 4.8 (++++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0007_01C7F301.26A14AD0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://www.sloebers.com/ Wassup Laqui How To Safely Grow Your Penis Radek Middleton ------=_NextPart_000_0007_01C7F301.26A14AD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://www.sloebers.com/
Wassup Laqui
How To Safely Grow Your Penis
Radek Middleton
------=_NextPart_000_0007_01C7F301.26A14AD0-- From Kanjihtksy@termpapersway.com Sun Sep 09 11:29:26 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUOj0-0006b0-3a for megaco-archive@lists.ietf.org; Sun, 09 Sep 2007 11:29:26 -0400 Received: from p57a8b05d.dip0.t-ipconnect.de ([87.168.176.93]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IUOiz-0005UE-Bh for megaco-archive@lists.ietf.org; Sun, 09 Sep 2007 11:29:26 -0400 Received: from pc-aeee26c02d39 ([143.190.98.185] helo=pc-aeee26c02d39) by p57A8B05D.dip0.t-ipconnect.de ( sendmail 8.13.3/8.13.1) with esmtpa id 1IiKBo-000TQE-UN for megaco-archive@lists.ietf.org; Sun, 9 Sep 2007 17:35:00 +0200 Message-ID: <000c01c7f2f6$e47507a0$5db0a857@pcaeee26c02d39> From: "Jaspreet Kanji" To: Subject: roon Date: Sun, 9 Sep 2007 17:34:21 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C7F307.A7FDD7A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 3.0 (+++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0006_01C7F307.A7FDD7A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://smitana.com/ How it is going Kanji I love him to death but our sex life sucked Glyndwr crabtree ------=_NextPart_000_0006_01C7F307.A7FDD7A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://smitana.com/
How it is going Kanji
I love him to death but our sex life = sucked
Glyndwr crabtree
------=_NextPart_000_0006_01C7F307.A7FDD7A0-- From micahmanahil72@chello.no Sun Sep 09 12:58:21 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUQ73-0004G4-In for megaco-archive@lists.ietf.org; Sun, 09 Sep 2007 12:58:21 -0400 Received: from [88.222.50.130] (helo=88.222.50.130) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IUQ72-0007nk-Kg for megaco-archive@lists.ietf.org; Sun, 09 Sep 2007 12:58:21 -0400 Received: from [88.222.50.130] by pgaan.chello.no; Sun, 09 Sep 2007 16:58:24 +0000 Message-ID: <000601c7f302$072aa1f4$a4a40699@nomyy> From: "Rickie Mcrae" To: "Tara Koehler" Subject: Thanks for your recent loan request, we are ready to lend you money Date: Sun, 09 Sep 2007 15:11:02 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C7F302.072A86D8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.2663 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757 X-Spam-Score: 4.7 (++++) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 This is a multi-part message in MIME format. ------=_NextPart_000_0003_01C7F302.072A86D8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Credit score does not matter to us! If your family OWN property and want IMMEDIATE pocket money to spend ANY = way you like, or simply wish to LOWER your payments by a third or more, = here is best deal we can offer you NOW (hurry, this tender will expire = TONIGHT: $400,000+ debt AND EVEN MORE: After further review, our lenders have established the = lowest monthly payments! Hurry, when the deal is gone, it is gone. Simply fill out this short = form...=20 Do not worry about approval, your Credit history will not disqualify = you! http://okoknedmoreok.com/ ------=_NextPart_000_0003_01C7F302.072A86D8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Credit score does not = matter to us!

If your family OWN = property and want IMMEDIATE pocket money to spend ANY way you like, or = simply wish to LOWER your payments by a third or more, here is best deal = we can offer you NOW (hurry, this tender will expire = TONIGHT:

$400,000+ = debt

AND EVEN MORE: After = further review, our lenders have established the lowest monthly = payments!

Hurry, when the deal is = gone, it is gone. Simply fill out this short form... =

Do not worry about = approval, your Credit history will not disqualify you!

http://okoknedmoreok.com/
------=_NextPart_000_0003_01C7F302.072A86D8-- From Hearnwxms@practicalpages.com Sun Sep 09 16:47:25 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUTgj-000730-So for megaco-archive@lists.ietf.org; Sun, 09 Sep 2007 16:47:25 -0400 Received: from 20151002157.user.veloxzone.com.br ([201.51.2.157]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IUTgj-0005E0-9b for megaco-archive@lists.ietf.org; Sun, 09 Sep 2007 16:47:25 -0400 Received: from Fabio ([176.196.128.9] helo=Fabio) by 20151062116.user.veloxzone.com.br ( sendmail 8.13.3/8.13.1) with esmtpa id 1xefvu-000WLI-Te for megaco-archive@lists.ietf.org; Sun, 9 Sep 2007 17:47:49 -0300 Message-ID: <1D030821.804E7542@practicalpages.com> Date: Sun, 9 Sep 2007 17:47:14 -0300 From: "Azghoud Hearn" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: megaco-archive@lists.ietf.org Subject: valvonta Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 4.1 (++++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Good day Hearn I started to notice that my penis had grown at least an inch Sheri Kroger http://www.sloebers.com/ From matsumotozlmw@sunlive.com.tw Mon Sep 10 01:09:14 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUbWM-0001w1-Kb for megaco-archive@lists.ietf.org; Mon, 10 Sep 2007 01:09:14 -0400 Received: from [89.222.180.131] (helo=131.nortelcom.ru) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IUbWM-0000Fo-19 for megaco-archive@lists.ietf.org; Mon, 10 Sep 2007 01:09:14 -0400 Received: from zhiltsov ([144.172.160.19] helo=zhiltsov) by 131.nortelcom.ru ( sendmail 8.13.3/8.13.1) with esmtpa id 1qqtHg-000ADU-Dn for megaco-archive@lists.ietf.org; Mon, 10 Sep 2007 09:09:35 +0400 Message-ID: <000b01c7f368$bcd2d2f0$83b4de59@zhiltsov> From: "DUCHEL matsumoto" To: Subject: ittsamer Date: Mon, 10 Sep 2007 09:09:17 +0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C7F38A.43E472F0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 3.9 (+++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0008_01C7F38A.43E472F0 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: quoted-printable http://skybleog.com/ Yo matsumoto Ever felt like you don't measure up? moose sarabia ------=_NextPart_000_0008_01C7F38A.43E472F0 Content-Type: text/html; charset="windows-1251" Content-Transfer-Encoding: quoted-printable
http://skybleog.com/
Yo matsumoto
Ever felt like you don't measure = up?
moose sarabia
------=_NextPart_000_0008_01C7F38A.43E472F0-- From Heering@akademigrup.com.tr Mon Sep 10 05:18:50 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUfPu-000090-IA for megaco-archive@lists.ietf.org; Mon, 10 Sep 2007 05:18:50 -0400 Received: from p508f4d79.dip.t-dialin.net ([80.143.77.121]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IUfPr-0007Rf-Ns for megaco-archive@lists.ietf.org; Mon, 10 Sep 2007 05:18:49 -0400 Received: by 10.56.105.51 with SMTP id eWfamaAiHlUJR; Mon, 10 Sep 2007 11:18:35 -0700 (GMT) Received: by 192.168.63.5 with SMTP id gOpQyVoALsfLyY.8416644547458; Mon, 10 Sep 2007 11:18:33 -0700 (GMT) Message-ID: <000401c7f3d6$fd93eef0$794d8f50@yourcfl70f8ckn> From: "Liubie Heering" To: Subject: atnatto Date: Mon, 10 Sep 2007 11:18:30 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C7F39C.513516F0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 3.4 (+++) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 ------=_NextPart_000_0006_01C7F39C.513516F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://skitkit.com/ Hi bro Heering His penis wasn=92t big enough to reach the most sensitive parts of my = vagina ghj pods ------=_NextPart_000_0006_01C7F39C.513516F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://skitkit.com/
Hi bro Heering
His penis wasn=92t big enough to reach the = most sensitive=20 parts of my vagina
ghj pods
------=_NextPart_000_0006_01C7F39C.513516F0-- From megaco-bounces@ietf.org Mon Sep 10 10:52:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUkbK-0001EL-Tb; Mon, 10 Sep 2007 10:50:58 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUkbJ-0001B9-2y for megaco@ietf.org; Mon, 10 Sep 2007 10:50:57 -0400 Received: from owa.vocaltec.com ([212.143.64.50] helo=mailserver.vocaltec.co.il) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IUkbH-0000gD-Kz for megaco@ietf.org; Mon, 10 Sep 2007 10:50:57 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Megaco] rtp/pl *syntax broken* in the V2 IG Date: Mon, 10 Sep 2007 17:52:58 +0300 Message-ID: <431F3BDE11BF2F42A22CBEFA36BD88A4F606E6@mailserver.vocaltec.local> In-Reply-To: <456C65E1.9050007@bell-labs.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Megaco] rtp/pl *syntax broken* in the V2 IG Thread-Index: AccTDGk9JBWNuubCQiGk4+Hx5p8M+jgqi4Mg References: <34B3EAA5B3066A42914D28C5ECF5FEA40BF4C534@zrtphxm2.corp.nortel.com> <456C65E1.9050007@bell-labs.com> From: "Raphael Tryster" To: "Troy Cauble" , "Kevin Boyle" X-Spam-Score: 0.0 (/) X-Scan-Signature: 142a000676f5977e1797396caab8b611 Cc: Albrecht.Schwarz@alcatel.de, megaco@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: megaco-bounces@ietf.org To take it a step further, the percentage we are talking about comes = from an 8-bit field in the RTCP record, where 00000001 =3D 0.390625%, = 10000000 =3D 50%, 11111111 =3D 99.609375%, and so on. So to convert = this number to rtp/pl, multiply by 100/256, and then by 2^32, or more = simply, multiply by 100 x 2^24. Is that correct? If the 8-bit fraction lost field in RTCP is the only source for this = statistic, then the exact numbers Kevin used below would not occur, = since 60/256 =3D 23.4375% and 61/256 =3D 23.828125%. Or are you saying, = Kevin, that an application may choose different sources for this data, = such as dividing the 24-bit cumulative count of packets lost by the = number of packets received? If so, under what circumstances would one = data source be preferred over another? I assume that all this only applies to implementations claiming = compliance from a certain version of H.248 or of the rtp package, = otherwise supporting the broken syntax using a dot, e.g rtp/pl=3D23.4375 = or rtp/pl=3D"23.4375" has better chances for interoperability. This is = of course a guess, as nobody in the list, myself included, took up = Christian's invitation to say how they represented rtp/pl until now. =20 Raphael Tryster -----Original Message----- From: Troy Cauble [mailto:troy@bell-labs.com]=20 Sent: Tuesday, November 28, 2006 6:38 PM To: Kevin Boyle Cc: Albrecht.Schwarz@alcatel.de; megaco@ietf.org; Christian Groves Subject: Re: [Megaco] rtp/pl *syntax broken* in the V2 IG Kevin, Sorry for the late response, I was on vacation last week. The example seems unnecessarily complex. Aren't your 5 steps equivalent to "multiply the percentage by 2^32"? (Not multiply the fractional part and combine with the integer part.) -troy Kevin Boyle wrote: > All, >=20 > The IG item in question was modified at the Ottawa Rapporteur's = Meeting in August to read like this: >=20 > "Possible values: a 32-bit whole number and a 32-bit fraction. The = value shall be encoded in ABNF as a string "x.y" where x is the whole = part and y the fractional part of the percentage. >=20 > The actual data type is a fixed point number, which is mapped on the = H.248 type "double". The whole number and the fractional part shall be = interpreted as 32-bit integer each, thus the "double" type for rtp/pl = shall be encoded as the concatenation of two integers. The fractional = part must be therefore first converted into an integer, i.e. multiplied = by 2^32.=20 >=20 > Binary encoding shall be as described in clause A.2 for type = "integer"." >=20 > It was recognized at the meeting here in Geneva that this text still = does not resolve the issue brought up by Troy: that the use of a string = breaks the syntax. >=20 > Therefore, I have produced text at the direction of the meeting to = address this issue. I propose the following text: >=20 > "Possible values: a 32-bit whole number and a 32-bit fraction. >=20 > The actual data type is a fixed point number, which is mapped on the = H.248 type "double". The whole number and the fractional part shall be = interpreted as 32-bit integer each, thus the "double" type for rtp/pl = shall be encoded as the concatenation of two integers. The fractional = part must be therefore first converted into an integer, i.e. multiplied = by 2^32.=20 >=20 > For example, given the percentage 23.625, to express this in the = Packet Loss Statistic we perform the following steps: >=20 > 1. Convert the number to binary: 23.625 base 10 equals 10111.101 base = 2. > 2. Break the binary representation into the whole number and the = fraction: Whole =3D 10111; fraction =3D .101 > 3. Convert the fraction into a whole number. Because half of a double = is 32 bits wide, multiple the fraction by 232. The fractional part in = our example now becomes 10100000000000000000000000000000. Note that = multiplying a binary number by a power of two is the same as shifting it = to the left the same number of places as the power of two by which it is = being multiplied. > 4. Concatenate the whole portion and the converted fraction together: = 1011110100000000000000000000000000000 is the binary value of our = statistic. > 5. Convert the binary value to integer: the statistic is reported as = having value 101468602368. >=20 > To return the statistic back to its fractional representation, the = steps are reversed. Once the integer is converted back to its binary = form, the lower 32 bits represent the fraction and the rest are the = whole number. From there, conversion back to a floating point integer = is fairly straightforward. >=20 > Binary encoding shall be as described in clause A.2 for type = "integer"." >=20 > Comments? Note that this text will be put forward for approval at the = end of the week, therefore any concerns need to be voiced by Thursday. >=20 > Kevin > (H.248 IG Editor) >=20 > -----Original Message----- > From: Christian Groves [mailto:Christian.Groves@nteczone.com]=20 > Sent: Wednesday, November 01, 2006 6:27 PM > To: Troy Cauble > Cc: Albrecht.Schwarz@alcatel.de; megaco@ietf.org > Subject: Re: [Megaco] rtp/pl *syntax broken* in the V2 IG >=20 > Hello Troy, >=20 > I'll put this on the agenda of the upcoming q.3/16 meeting. > I do understand your concerns about redefinition of type. So we can = revisit this IG item. Unfortunately it seems given the original = definition somebodies implementation is going to be broken no matter = what we do. It would be interesting to hear from other on the list as to = how they have represented rtp/pl since version one. >=20 > In terms of FLOAT discussion of this has been added to the "H.248.1v4 = living list" as it was recognised that any changes for this would result = in syntax change. >=20 > Regards, Christian >=20 > Troy Cauble wrote: >=20 >> Thanks Albrecht, >> >> You concern is more general than mine. >> >> I don't find the arguments for adding FLOATs in V4 compelling. >> But if they are to be added, you need to give them real ASN.1 data=20 >> types. All of the current parameters have embedded type information=20 >> in the ASN.1. Why should these then be lumped into OCTET STRING? >> >> >> But back to my current V1/V2 issue. >> >> What are V1 and V2 compliant systems to do with rtp/pl? >> The V2 IG fixed a confusing spec by specifying a *broken syntax*. >> >> If I understand the decision (a) below correctly, it sidesteps the=20 >> whole question and doesn't solve anything. >> There is no "undefined" parameter type in the protocol. >> The way to specify the legal text and ASN.1 encodings is by picking a = >> type from 12.2. >> >> The only parameter type that can be text encoded "x.y" >> is a STRING. (And it must have the double quotes, btw.) If we want=20 >> "x.y", we need to change the type to STRING. >> >> Or we can keep/change/clarify the scaling and either leave the type = as=20 >> DOUBLE or change it to INTEGER. (Scaling by >> 2^8 would fit in an INTEGER and satisfy the precision specified in=20 >> RFC3550.) >> >> -troy >> >> >> Albrecht.Schwarz@alcatel.de wrote: >> >>> Troy, >>> do agree to your analysis, made also a proposal based on "scaling"=20 >>> (see AVD-2916). >>> We did discuss this subject already in a couple of meetings (see = list >>> below) this year and finally agreed: >>> >>> a) to fix the interpretation of rtp/pl in the IMG (i.e., the H.248=20 >>> served user instance may only interpret rtp/pl, the H.248 message=20 >>> decoder may not itself convert it in the final data structure), and >>> b) extend the set of H.248 data types in H.248.1 Version 4 (i.e. = data=20 >>> types are a V4 living list item). >>> >>> I would then for H.248.1 V4 propose to use "FLOAT32" (a 4-byte=20 >>> floating point number according the single-precision 32-bit IEEE 754 = >>> format) for rtp/pl, which would provide the advantages of a native=20 >>> data type, simple handling of fractional part, and avoidance of=20 >>> "complex data type conversions". >>> >>> Regards, Albrecht >>> >>> 1) = http://ftp3.itu.int/av-arch/avc-site/2005-2008/0608_Ott/AVD-2916.zip >>> Implementers' Guides for H.248.1 Version 2 & 3 ? ABNF Grammar = >>> for =A7 >>> E.12.4.3 Packet Loss rtp/pl >>> >>> 2) >>> = http://www.itu.int/md/meetingdoc.asp?lang=3Den&parent=3DT05-SG16-060403-D= >>> -0303 >>> >>> =3D> =A7 2.6 H.248.1 v1, 2, 3 Clarification on rtp/pl coding >>> >>> 3) >>> = http://www.itu.int/md/meetingdoc.asp?lang=3Den&parent=3DT05-SG16-060403-D= >>> -0228 >>> >>> H.248.1 - Discussion on floating numbers data types and = example=20 >>> scenarios for type conversions >>> >>> 4) >>> = http://www.itu.int/md/meetingdoc.asp?lang=3Den&parent=3DT05-SG16-060403-D= >>> -0227 >>> >>> H.248.1 - Missing Data Type(s) for Floating Numbers (IEEE 754) >>> >>> >>> >>> = =20 >>> Troy=20 >>> Cauble = =20 >>> >> megaco@ietf.org = =20 >>> com> =20 >>> cc: = =20 >>> Subject: [Megaco]=20 >>> rtp/pl non-double breakage in the V2 >>> IG 30.10.2006=20 >>> 18:15 = =20 >>> = =20 >>> >>> >>> >>> >>> >>> I just noticed the following clarification in the >>> H.248.1 V2 IG involving the rtp/pl value. >>> >>> It says that rtp/pl is a double that be encoded "x.y" >>> >>> But if it can be encoded "x.y" it is not a double. >>> A double is defined in the document as a 64 bit integer. >>> A double's text encoding is defined as follows. >>> >>> ; Integer, Double, and Unsigned Integer: Decimal values can be=20 >>> encoded ; using characters 0-9. Hexadecimal values must be prefixed = with '0x' >>> ; and can use characters 0-9,a-f,A-F. An octal format is not = supported. >>> ; Negative integers start with '-' and MUST be Decimal. The SafeChar = >>> ; form of VALUE MUST be used. >>> >>> Saying it can be encoded "x.y" is inventing a new type that needs to = >>> be defined in the main document, with support for text and ASN.1=20 >>> encodings. >>> >>> Casual re-definitions or type inventions within package definitions=20 >>> should not be allowed. >>> >>> The problem being solved, a vague original definition, should be=20 >>> fixed by saying the integer representation is achieved by = multiplying=20 >>> the percentage by 1000. >>> (Or some other number.) It could easily be changed from double to=20 >>> integer as well. >>> >>> -troy >>> >>> >>> >>> _______________________________________________ >>> Megaco mailing list >>> Megaco@ietf.org >>> https://www1.ietf.org/mailman/listinfo/megaco >>> >>> >>> >> >> >> _______________________________________________ >> Megaco mailing list >> Megaco@ietf.org >> https://www1.ietf.org/mailman/listinfo/megaco >> >> >> >> >=20 >=20 > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From Mayugapface@liquidquiet.com Mon Sep 10 17:51:43 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUrAV-0005rv-7Q for megaco-archive@lists.ietf.org; Mon, 10 Sep 2007 17:51:43 -0400 Received: from adsl-64-237-152-197.prtc.net ([64.237.152.197]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IUrAT-00063v-Lg for megaco-archive@lists.ietf.org; Mon, 10 Sep 2007 17:51:43 -0400 Received: from home-3990d1fa92 ([188.196.134.143]:15592 "EHLO home-3990d1fa92" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by adsl-64-237-152-197.prtc.net with ESMTP id S22PAFKAIUKBNCNP (ORCPT ); Mon, 10 Sep 2007 17:51:29 -0700 Message-ID: <000901c7f40d$db270c30$c598ed40@home3990d1fa92> From: "Cory Mayuga" To: Subject: uwoug Date: Mon, 10 Sep 2007 17:51:15 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C7F3D3.2EC83430" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 4.0 (++++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0009_01C7F3D3.2EC83430 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://mehrizat.net/ Wassup megaco-archive its the size of ones penis that determines success Ezana Luoti ------=_NextPart_000_0009_01C7F3D3.2EC83430 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://mehrizat.net/
Wassup megaco-archive
its the size of ones penis that determines = success
Ezana Luoti
------=_NextPart_000_0009_01C7F3D3.2EC83430-- From codey-sorrell@alentus.com Tue Sep 11 00:52:48 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUxk0-0006jU-MZ for megaco-archive@lists.ietf.org; Tue, 11 Sep 2007 00:52:48 -0400 Received: from [189.25.246.161] (helo=18925245075.user.veloxzone.com.br) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IUxjz-0007sp-R8 for megaco-archive@lists.ietf.org; Tue, 11 Sep 2007 00:52:48 -0400 Received: from omar-b52cbe1656 by alentus.com with ASMTP id A4485F57 for ; Tue, 11 Sep 2007 01:53:10 -0300 Received: from omar-b52cbe1656 ([103.151.183.184]) by alentus.com with ESMTP id 3D862DFA04F8 for ; Tue, 11 Sep 2007 01:53:10 -0300 Message-ID: <000501c7f42f$99cb0d50$4bf519bd@omarb52cbe1656> From: "codey sorrell" To: Subject: rhabener Date: Tue, 11 Sep 2007 01:52:48 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C7F416.747DD550" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 2.1 (++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0009_01C7F416.747DD550 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://lueair.com/ Hi bro megaco-archive A girl once told me i was too small.. ke donovan ------=_NextPart_000_0009_01C7F416.747DD550 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://lueair.com/
Hi bro megaco-archive
A girl once told me i was too = small..
ke donovan
------=_NextPart_000_0009_01C7F416.747DD550-- From Chenier@STANTON-GROUP.COM Tue Sep 11 03:53:49 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV0ZB-0006FX-Tb for megaco-archive@lists.ietf.org; Tue, 11 Sep 2007 03:53:49 -0400 Received: from [58.174.164.178] (helo=[58.174.164.178]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IV0ZA-0003sj-W7 for megaco-archive@lists.ietf.org; Tue, 11 Sep 2007 03:53:49 -0400 Received: from Acclimatize ([119.101.123.106]:15409 "EHLO Acclimatize" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by [58.174.164.178] with ESMTP id S22XNAXONNLKPXBJ (ORCPT ); Tue, 11 Sep 2007 17:54:02 +1000 Message-ID: Date: Tue, 11 Sep 2007 17:53:25 +1000 From: "Vartkes Chenier" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: megaco-archive@lists.ietf.org Subject: pil-lluf Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.8 (++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea How it is going Vartkes Many men want to improve their schlong size gintu Kodede http://mensange.com/ From megaco-bounces@ietf.org Tue Sep 11 09:33:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV5qZ-0003tw-S3; Tue, 11 Sep 2007 09:32:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV5qY-0003tr-Og for megaco@ietf.org; Tue, 11 Sep 2007 09:32:06 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IV5qX-0002li-28 for megaco@ietf.org; Tue, 11 Sep 2007 09:32:06 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 333E8211F0; Tue, 11 Sep 2007 15:32:04 +0200 (CEST) X-AuditID: c1b4fb3e-b0034bb0000007e1-be-46e698d3fddd Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id D4D162056E; Tue, 11 Sep 2007 15:32:03 +0200 (CEST) Received: from esealmw118.eemea.ericsson.se ([153.88.200.77]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Sep 2007 15:32:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Megaco] Question about RTP payloadtype Date: Tue, 11 Sep 2007 15:27:53 +0200 Message-ID: In-Reply-To: <46E0B98B.1030002@nteczone.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Megaco] Question about RTP payloadtype Thread-Index: Acfw+Dag5aFYap4bRa+GX09FslcomwAaCZeA From: "Stephen Mell (CV/ETL)" To: "Christian Groves" X-OriginalArrivalTime: 11 Sep 2007 13:32:02.0911 (UTC) FILETIME=[2350F6F0:01C7F478] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: bc102ac530ba955ef81f1f75b8bebe44 Cc: megaco@ietf.org, Albrecht.Schwarz@alcatel-lucent.de, raphael.tryster@vocaltec.com X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: megaco-bounces@ietf.org Hi Christian, Exploring your initial ideas a bit further: If mode is sendonly or recvonly then a single value might be interpreted with respect to the media mode that is currently in force, as tx pltrans and rx pltrans respectively. This could be difficult to interpret if the event is generated during a mode change, so Im not sure that idea is too great. If mode is sendrecv and only the transmit codec changes (perhaps the original bidirectional connection was asymmetrical and the Rx codec was already uncompressed in a VoiceBandData switch scenario), then the list semantics are problematic, as it is not possible to represent a change in Tx only in this way (as it is the second element in the list). Maybe for these purposes a sentinel value can be employed to explicilty signify that no RX codec change has taken place: E.g. rtp/pltrans =3D [ None, G711 ] - Rx no change, Tx changed to 8 I also think it would there are advantages if an MGC were able to unambiguously report a change in Rx codec, without an implied change in Tx codec in that Observed Event, as this could serve as an indication for situations where automated VBD switches between gateways have failed to work properly.=20 Having said that its probably more important to maintain backward compatibility with existing implementations. I would guess that many implementations only ever report one value for rtp/pltrans and that value is the New Rx CODEC, and this would be true regardless of whether the Tx codec has changed or not. Given the existing vagueness of the published package, these implementations seem reasonable to me. For backward compatibility reasons, it might be wise to state that reporting of a change in Tx Codec is optional. In the case where the Tx codec at the end of the list is not present than it would not be possible to tell if the Tx codec had changed or not. If the MG puts the sentinel value as the second value in the codec list, then it would be possible to infer that the Tx codec has not changed. In summary, a suggested scheme using sentinel values to explicility signify NoChange and at the same time (hopefully) achieving backward compatibility:- rtp/pltrans =3D G711 - Rx changed to G711, no information about Tx = change can=20 be inferred by the MGC (for backward compatibility) rtp/pltrans =3D [ None, G711 ] - Rx No change, Tx changed to g711 rtp/pltrans =3D [ G711, None ] - Rx changed to g711, Tx No Change rtp/pltrans =3D [ G711, G711 ] - Rx changed to g711, Tx changed to g711 rtp/pltrans =3D [ None, None ] - TxRx no change - MG should not report this! Interpretation of above is always independent of the media mode. Steve=20 -----Original Message----- From: Christian Groves [mailto:Christian.Groves@nteczone.com]=20 Sent: 07 September 2007 03:38 To: Raphael Tryster Cc: megaco@ietf.org; Schwarz Albrecht Subject: Re: [Megaco] Question about RTP payloadtype Hello Raphael, I believe that having the rtp/pltrans as a list of was to account for the case where an event was set and the MG detected a change in codec in both the send and receive directions. Events sit at a level higher than the local/remote descriptors so in theory it covers both. The list of allowed the notification of both directions to be signalled, e.g. able to notify when a change in codec on the received stream, able to notify when a MG autonomously decides to change the codec sent. I suspect that there wasn't more thought on specific use cases when it was added. The thread you pointed to highlights the issue but it seems that the note proposed back then didn't make it into an implementor's guide proposal. If we now add something to the IG then we need to agree on: a) what a single value in the list means b) what 2 values in the list means c) can there be more than 2? Some initial thoughts: On a) Does a single value mean a codec change in both the send/receive direction (symmetrical change) or only the receive direction? On b) I think we could easily say that the first value is the local value, the second is the remote On c) I can't see a case for three so we may be able to limit the list size to 2. I tried to find where the text originated to see if this could provide some more information. It seems it came from the period between the November 1999 Washington IETF meeting and the Feb 2000 ITU. However I can't find any email/contribution actually proposing it. Regards, Christian PS: Raphael, you need to update your address book I haven't worked Ericsson for some time now :-). Raphael Tryster wrote: > > Steve, > > It doesn't sound plausible to me, because: > > 1. If things like VAD or RFC2833 were intended to be included in=20 > reports of a periodic payload transition, then it stands to reason=20 > that they should also be reported when there is no periodic payload=20 > transition. That could produce a barrage of notifications, and I doubt > that is what the designers of rtp/pltrans had in mind. > > 2. If you ask me to deliver an envelope to someone outside the office, > then while I am getting ready to leave the office you can add things=20 > that you remember at the last minute. That's because I am human and=20 > not a computer (some people dispute that). Computer programs generally > have "left the office" as soon as they get a job to do, and would have > to be complicated considerably to provide the kind of functionality=20 > you suggest. > > So, unless one of the authors informs us otherwise, I'm betting they=20 > had something else in mind. > > Raphael Tryster > > ---------------------------------------------------------------------- > -- > > *From:* Stephen Mell (CV/ETL) [mailto:stephen.mell@ericsson.com] > *Sent:* Thursday, September 06, 2007 6:38 PM > *To:* Raphael Tryster > *Cc:* Schwarz Albrecht; Christian Groves; megaco@ietf.org > *Subject:* RE: [Megaco] Question about RTP payloadtype > > Raphael, > > Perhaps this multiple payload type would be used when transiting to a=20 > compression codec which supplemeted by non-periodic packets with a=20 > different payload type - for example RFC2833 Out-Of-Band RTP events or > VAD packets for the purposes of comfort noise generation, these will=20 > always use a different payload type to the periodic compression codec. > > By the time that the Rx media handling engine has detected the change=20 > in codec (received at least N periodic packets of the new compressed > codec) and wishes to report it, there is a slim chance that some of=20 > the non-periodic (supplementary) packets have also been received as=20 > well, so the MG may report Received periodic and non-periodic codec=20 > types in the pltrans event > > Does that sound feasible? > > Steve > > ---------------------------------------------------------------------- > -- > > *From:* Raphael Tryster [mailto:raphael.tryster@vocaltec.com] > *Sent:* 06 September 2007 14:40 > *To:* Schwarz Albrecht; Christian Groves > *Cc:* megaco@ietf.org > *Subject:* RE: [Megaco] Question about RTP payloadtype > > Albrecht, > > What you wrote clarifies the discussion of 5 years ago, but I am still > puzzled why a list and not a single value. Clearly, the RTP payload=20 > cannot change to multiple different values at the same time. That=20 > suggests that changes that occurred at different times are being=20 > reported together, and I am wondering how this would be done. > > Raphael Tryster > > ---------------------------------------------------------------------- > -- > > *From:* Schwarz Albrecht [mailto:Albrecht.Schwarz@alcatel-lucent.de] > *Sent:* Thursday, September 06, 2007 4:26 PM > *To:* Raphael Tryster; Christian Groves > *Cc:* megaco@ietf.org > *Subject:* RE: [Megaco] Question about RTP payloadtype > > rtp/pltrans is an event, thus for the Rx flow only ("the semantic is=20 > not explicitly extended on the Tx flow as well, as e.g. done in=20 > H.248.40"). Right? > > If my understanding is correct, the the semantic means RTP payload=20 > type changes just of the remote RTP endpoint. > > Guess your rtppltype list is correct. > > -Albrecht > > =20 > ---------------------------------------------------------------------- > -- > > *From:* Raphael Tryster [mailto:raphael.tryster@vocaltec.com] > *Sent:* Donnerstag, 6. September 2007 13:25 > *To:* Christian Groves > *Cc:* megaco@ietf.org > *Subject:* RE: [Megaco] Question about RTP payloadtype > > This is a continuation of a thread that I started a few days ago, > but the exchange below from 5 years ago is somewhat relevant, as > it establishes that the rtppltype parameter of rtp/pltrans does > not refer to Rx/Tx. My question is then, what is the meaning of > rtppltype being of type sublist of enumeration? Syntactically, I > assume this means something like > > ObservedEvents =3D 1111 { 20070906T141539 : rtp/pltrans { = rtppltype > =3D [g723, g729] } } > > But what does it mean semantically? How could it happen that two > payload type transitions are reported in the same notification? > > If all but the last payload type in the list is being reported > with a delay, what is the mechanism by which this delayed > reporting is engineered? Is there a way that the MGC could request > buffering of such events, and then have them all reported at once > by requesting that ObservedEvents be included in the reply to > Subtract? > > Raphael Tryster > > =20 > ---------------------------------------------------------------------- > -- > > *From:* Terry L Anderson [mailto:tlatla@verizon.net] > *Sent:* Tuesday, October 29, 2002 8:55 PM > *To:* Christian Groves > *Cc:* Seunghan Choi; megaco@ietf.org > *Subject:* Re: [Megaco] Question about RTP payloadtype > > Agreed. We would need to bump the version of the package. Perhaps > we should add a note to rtp v1 and add a parameter to rtp v2 > > Christian Groves wrote: > > G'Day, > > =20 > > The assumption behind E.12 was that the payload was symmetrical.=20 > We could add a > > note stating this but I believe the additional of an extra=20 > parameter is beyond > > an IG item. There no way to add an extra parameter to an event and > maintain > > backward compatibility, it would have to be a new event. > > =20 > > Regards, Christian > > =20 > > That is a very good issue. There is no parameter in the current=20 > event > > notice to indicate which of the two payloads changed. While many=20 > use > > symmetric payload types this is certainly not a requirement. I=20 > suppose > > we should consider adding a parameter of enumeration type with=20 > values of > > send, recv, sendRecv to include with the notice. > > =20 > > Kevin Boyle is our new Implementors Guide editor (as of the end of > the > > SG16 meeting today, I am handing over the editorship rather than=20 > do that > > as well as rapporteur). Kevin can propose a fix for discussion on the list. > > =20 > > Seunghan Choi wrote: > > =20 > > =20 > >> Hi, All. >> =20 >> Is there the case that RTPpayload type(Rx CodecType) in localDescriptor and RTPpayload type(Tx CodecType) in remoteDescriptor is different? >> If there is that case, Which does the rtppltype mean, Rx CodecType or Tx CodecType, in E.12 Payload Transition? >> =20 >> Thanks. >> =20 >> =20 > =20 > > =20 > > =20 > > =20 > > ---------------------------------------------------------------------- > -- > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > =20 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Tue Sep 11 11:14:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV7QI-0007A4-NR; Tue, 11 Sep 2007 11:13:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV7QI-00079o-4j for megaco@ietf.org; Tue, 11 Sep 2007 11:13:06 -0400 Received: from owa.vocaltec.com ([212.143.64.50] helo=mailserver.vocaltec.co.il) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IV7QF-0005Ru-F8 for megaco@ietf.org; Tue, 11 Sep 2007 11:13:06 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Megaco] Question about RTP payloadtype Date: Tue, 11 Sep 2007 18:15:09 +0300 Message-ID: <431F3BDE11BF2F42A22CBEFA36BD88A4F606E9@mailserver.vocaltec.local> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Megaco] Question about RTP payloadtype Thread-Index: Acfw+Dag5aFYap4bRa+GX09FslcomwAaCZeAAMkmY7A= References: <46E0B98B.1030002@nteczone.com> From: "Raphael Tryster" To: "Stephen Mell (CV/ETL)" , "Christian Groves" X-Spam-Score: 0.0 (/) X-Scan-Signature: db284e046c8702920c1c6125bc4d0b7a Cc: megaco@ietf.org, Albrecht.Schwarz@alcatel-lucent.de X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: megaco-bounces@ietf.org I am wondering if this goes against the spirit of what a list is. If you can say that the first element in the list means this and the second element means that and you can't have more than two, then the appropriate representation of this functionality is two parameters and not a list. Are there any other cases in Megaco where a list is used in this way? I understand there is a backward compatibility issue, but it appears the only thing we need to be backward compatible with is a single value meaning Rx change. If, instead of a list, we add a second parameter meaning Tx change, would this break more implementations than keeping the list with the semantics now being suggested? Raphael Tryster -----Original Message----- From: Stephen Mell (CV/ETL) [mailto:stephen.mell@ericsson.com]=20 Sent: Tuesday, September 11, 2007 4:28 PM To: Christian Groves Cc: Raphael Tryster; Albrecht.Schwarz@alcatel-lucent.de; megaco@ietf.org Subject: RE: [Megaco] Question about RTP payloadtype Hi Christian, Exploring your initial ideas a bit further: If mode is sendonly or recvonly then a single value might be interpreted with respect to the media mode that is currently in force, as tx pltrans and rx pltrans respectively. This could be difficult to interpret if the event is generated during a mode change, so Im not sure that idea is too great. If mode is sendrecv and only the transmit codec changes (perhaps the original bidirectional connection was asymmetrical and the Rx codec was already uncompressed in a VoiceBandData switch scenario), then the list semantics are problematic, as it is not possible to represent a change in Tx only in this way (as it is the second element in the list). Maybe for these purposes a sentinel value can be employed to explicilty signify that no RX codec change has taken place: E.g. rtp/pltrans =3D [ None, G711 ] - Rx no change, Tx changed to 8 I also think it would there are advantages if an MGC were able to unambiguously report a change in Rx codec, without an implied change in Tx codec in that Observed Event, as this could serve as an indication for situations where automated VBD switches between gateways have failed to work properly.=20 Having said that its probably more important to maintain backward compatibility with existing implementations. I would guess that many implementations only ever report one value for rtp/pltrans and that value is the New Rx CODEC, and this would be true regardless of whether the Tx codec has changed or not. Given the existing vagueness of the published package, these implementations seem reasonable to me. For backward compatibility reasons, it might be wise to state that reporting of a change in Tx Codec is optional. In the case where the Tx codec at the end of the list is not present than it would not be possible to tell if the Tx codec had changed or not. If the MG puts the sentinel value as the second value in the codec list, then it would be possible to infer that the Tx codec has not changed. In summary, a suggested scheme using sentinel values to explicility signify NoChange and at the same time (hopefully) achieving backward compatibility:- rtp/pltrans =3D G711 - Rx changed to G711, no information about Tx = change can=20 be inferred by the MGC (for backward compatibility) rtp/pltrans =3D [ None, G711 ] - Rx No change, Tx changed to g711 rtp/pltrans =3D [ G711, None ] - Rx changed to g711, Tx No Change rtp/pltrans =3D [ G711, G711 ] - Rx changed to g711, Tx changed to g711 rtp/pltrans =3D [ None, None ] - TxRx no change - MG should not report this! Interpretation of above is always independent of the media mode. Steve=20 -----Original Message----- From: Christian Groves [mailto:Christian.Groves@nteczone.com]=20 Sent: 07 September 2007 03:38 To: Raphael Tryster Cc: megaco@ietf.org; Schwarz Albrecht Subject: Re: [Megaco] Question about RTP payloadtype Hello Raphael, I believe that having the rtp/pltrans as a list of was to account for the case where an event was set and the MG detected a change in codec in both the send and receive directions. Events sit at a level higher than the local/remote descriptors so in theory it covers both. The list of allowed the notification of both directions to be signalled, e.g. able to notify when a change in codec on the received stream, able to notify when a MG autonomously decides to change the codec sent. I suspect that there wasn't more thought on specific use cases when it was added. The thread you pointed to highlights the issue but it seems that the note proposed back then didn't make it into an implementor's guide proposal. If we now add something to the IG then we need to agree on: a) what a single value in the list means b) what 2 values in the list means c) can there be more than 2? Some initial thoughts: On a) Does a single value mean a codec change in both the send/receive direction (symmetrical change) or only the receive direction? On b) I think we could easily say that the first value is the local value, the second is the remote On c) I can't see a case for three so we may be able to limit the list size to 2. I tried to find where the text originated to see if this could provide some more information. It seems it came from the period between the November 1999 Washington IETF meeting and the Feb 2000 ITU. However I can't find any email/contribution actually proposing it. Regards, Christian PS: Raphael, you need to update your address book I haven't worked Ericsson for some time now :-). Raphael Tryster wrote: > > Steve, > > It doesn't sound plausible to me, because: > > 1. If things like VAD or RFC2833 were intended to be included in=20 > reports of a periodic payload transition, then it stands to reason=20 > that they should also be reported when there is no periodic payload=20 > transition. That could produce a barrage of notifications, and I doubt > that is what the designers of rtp/pltrans had in mind. > > 2. If you ask me to deliver an envelope to someone outside the office, > then while I am getting ready to leave the office you can add things=20 > that you remember at the last minute. That's because I am human and=20 > not a computer (some people dispute that). Computer programs generally > have "left the office" as soon as they get a job to do, and would have > to be complicated considerably to provide the kind of functionality=20 > you suggest. > > So, unless one of the authors informs us otherwise, I'm betting they=20 > had something else in mind. > > Raphael Tryster > > ---------------------------------------------------------------------- > -- > > *From:* Stephen Mell (CV/ETL) [mailto:stephen.mell@ericsson.com] > *Sent:* Thursday, September 06, 2007 6:38 PM > *To:* Raphael Tryster > *Cc:* Schwarz Albrecht; Christian Groves; megaco@ietf.org > *Subject:* RE: [Megaco] Question about RTP payloadtype > > Raphael, > > Perhaps this multiple payload type would be used when transiting to a=20 > compression codec which supplemeted by non-periodic packets with a=20 > different payload type - for example RFC2833 Out-Of-Band RTP events or > VAD packets for the purposes of comfort noise generation, these will=20 > always use a different payload type to the periodic compression codec. > > By the time that the Rx media handling engine has detected the change=20 > in codec (received at least N periodic packets of the new compressed > codec) and wishes to report it, there is a slim chance that some of=20 > the non-periodic (supplementary) packets have also been received as=20 > well, so the MG may report Received periodic and non-periodic codec=20 > types in the pltrans event > > Does that sound feasible? > > Steve > > ---------------------------------------------------------------------- > -- > > *From:* Raphael Tryster [mailto:raphael.tryster@vocaltec.com] > *Sent:* 06 September 2007 14:40 > *To:* Schwarz Albrecht; Christian Groves > *Cc:* megaco@ietf.org > *Subject:* RE: [Megaco] Question about RTP payloadtype > > Albrecht, > > What you wrote clarifies the discussion of 5 years ago, but I am still > puzzled why a list and not a single value. Clearly, the RTP payload=20 > cannot change to multiple different values at the same time. That=20 > suggests that changes that occurred at different times are being=20 > reported together, and I am wondering how this would be done. > > Raphael Tryster > > ---------------------------------------------------------------------- > -- > > *From:* Schwarz Albrecht [mailto:Albrecht.Schwarz@alcatel-lucent.de] > *Sent:* Thursday, September 06, 2007 4:26 PM > *To:* Raphael Tryster; Christian Groves > *Cc:* megaco@ietf.org > *Subject:* RE: [Megaco] Question about RTP payloadtype > > rtp/pltrans is an event, thus for the Rx flow only ("the semantic is=20 > not explicitly extended on the Tx flow as well, as e.g. done in=20 > H.248.40"). Right? > > If my understanding is correct, the the semantic means RTP payload=20 > type changes just of the remote RTP endpoint. > > Guess your rtppltype list is correct. > > -Albrecht > > =20 > ---------------------------------------------------------------------- > -- > > *From:* Raphael Tryster [mailto:raphael.tryster@vocaltec.com] > *Sent:* Donnerstag, 6. September 2007 13:25 > *To:* Christian Groves > *Cc:* megaco@ietf.org > *Subject:* RE: [Megaco] Question about RTP payloadtype > > This is a continuation of a thread that I started a few days ago, > but the exchange below from 5 years ago is somewhat relevant, as > it establishes that the rtppltype parameter of rtp/pltrans does > not refer to Rx/Tx. My question is then, what is the meaning of > rtppltype being of type sublist of enumeration? Syntactically, I > assume this means something like > > ObservedEvents =3D 1111 { 20070906T141539 : rtp/pltrans { = rtppltype > =3D [g723, g729] } } > > But what does it mean semantically? How could it happen that two > payload type transitions are reported in the same notification? > > If all but the last payload type in the list is being reported > with a delay, what is the mechanism by which this delayed > reporting is engineered? Is there a way that the MGC could request > buffering of such events, and then have them all reported at once > by requesting that ObservedEvents be included in the reply to > Subtract? > > Raphael Tryster > > =20 > ---------------------------------------------------------------------- > -- > > *From:* Terry L Anderson [mailto:tlatla@verizon.net] > *Sent:* Tuesday, October 29, 2002 8:55 PM > *To:* Christian Groves > *Cc:* Seunghan Choi; megaco@ietf.org > *Subject:* Re: [Megaco] Question about RTP payloadtype > > Agreed. We would need to bump the version of the package. Perhaps > we should add a note to rtp v1 and add a parameter to rtp v2 > > Christian Groves wrote: > > G'Day, > > =20 > > The assumption behind E.12 was that the payload was symmetrical.=20 > We could add a > > note stating this but I believe the additional of an extra=20 > parameter is beyond > > an IG item. There no way to add an extra parameter to an event and > maintain > > backward compatibility, it would have to be a new event. > > =20 > > Regards, Christian > > =20 > > That is a very good issue. There is no parameter in the current=20 > event > > notice to indicate which of the two payloads changed. While many=20 > use > > symmetric payload types this is certainly not a requirement. I=20 > suppose > > we should consider adding a parameter of enumeration type with=20 > values of > > send, recv, sendRecv to include with the notice. > > =20 > > Kevin Boyle is our new Implementors Guide editor (as of the end of > the > > SG16 meeting today, I am handing over the editorship rather than=20 > do that > > as well as rapporteur). Kevin can propose a fix for discussion on the list. > > =20 > > Seunghan Choi wrote: > > =20 > > =20 > >> Hi, All. >> =20 >> Is there the case that RTPpayload type(Rx CodecType) in localDescriptor and RTPpayload type(Tx CodecType) in remoteDescriptor is different? >> If there is that case, Which does the rtppltype mean, Rx CodecType or Tx CodecType, in E.12 Payload Transition? >> =20 >> Thanks. >> =20 >> =20 > =20 > > =20 > > =20 > > =20 > > ---------------------------------------------------------------------- > -- > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > =20 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Tue Sep 11 22:04:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVHZC-0000BG-6O; Tue, 11 Sep 2007 22:02:58 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVHZA-0000B6-Dm for megaco@ietf.org; Tue, 11 Sep 2007 22:02:56 -0400 Received: from ipmail03.adl2.internode.on.net ([203.16.214.135]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVHZ8-0007Dz-2E for megaco@ietf.org; Tue, 11 Sep 2007 22:02:56 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAOLi5kY7p0LC/2dsb2JhbAAM X-IronPort-AV: E=Sophos;i="4.20,241,1186324200"; d="scan'208";a="147416581" Received: from ppp59-167-66-194.lns1.mel4.internode.on.net (HELO [127.0.0.1]) ([59.167.66.194]) by ipmail03.adl2.internode.on.net with ESMTP; 12 Sep 2007 11:32:48 +0930 Message-ID: <46E748C6.3080307@nteczone.com> Date: Wed, 12 Sep 2007 12:02:46 +1000 From: Christian Groves User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Raphael Tryster Subject: Re: [Megaco] rtp/pl *syntax broken* in the V2 IG References: <34B3EAA5B3066A42914D28C5ECF5FEA40BF4C534@zrtphxm2.corp.nortel.com> <456C65E1.9050007@bell-labs.com> <431F3BDE11BF2F42A22CBEFA36BD88A4F606E6@mailserver.vocaltec.local> In-Reply-To: <431F3BDE11BF2F42A22CBEFA36BD88A4F606E6@mailserver.vocaltec.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a0ecb232550b38fd41a3cf6a312fbabc Cc: Albrecht.Schwarz@alcatel.de, Troy Cauble , megaco@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: megaco-bounces@ietf.org Hello Raphael, We ended up including an item in the IG and then later in the amendment to H.248.1v3. ie. E.12.4.3 Packet Loss *Statistic Name*: Packet Loss *StatisticID*: pl (0x0006) *Description*: Describes the current rate of packet loss on an RTP stream, as defined in RFC 3550. Packet loss is expressed as percentage value: number of packets lost in the interval between two reception reports, divided by the number of packets expected during that interval. *Type*: Double *Possible values*: a 32-bit whole number and a 32-bit fraction. The actual data type is a fixed point number, which is mapped on the H.248 type “double”. The whole number and the fractional part shall be interpreted as 32-bit integer each, thus the “double” type for rtp/pl shall be encoded as the concatenation of two integers. The fractional part must be therefore first converted into an integer, i.e. multiplied by 2^32 . For example, given the percentage 23.625, to express this in the Packet Loss Statistic we perform the following steps: 1. Convert the number to binary: 23.625_10 equals 10111.101_2 . 2. Multiply the binary number by 2^32 . Note that multiplying a binary number by a power of two is the same as shifting it to the left the same number of places as the power of two by which it is being multiplied. 1011110100000000000000000000000000000 is the binary value of our statistic. 3. Convert the binary value to a decimal double: the statistic is reported as having value 101468602368. To return the statistic back to its fractional representation, the steps are reversed. Once the double is converted back to its binary form, the lower 32 bits represent the fraction and the rest are the whole number. From there, conversion back to a floating point number is fairly straightforward. Binary encoding shall be as described in clause A.2 for type “integer”. *Level*: Either Regards, Christian Raphael Tryster wrote: > To take it a step further, the percentage we are talking about comes from an 8-bit field in the RTCP record, where 00000001 = 0.390625%, 10000000 = 50%, 11111111 = 99.609375%, and so on. So to convert this number to rtp/pl, multiply by 100/256, and then by 2^32, or more simply, multiply by 100 x 2^24. Is that correct? > > If the 8-bit fraction lost field in RTCP is the only source for this statistic, then the exact numbers Kevin used below would not occur, since 60/256 = 23.4375% and 61/256 = 23.828125%. Or are you saying, Kevin, that an application may choose different sources for this data, such as dividing the 24-bit cumulative count of packets lost by the number of packets received? If so, under what circumstances would one data source be preferred over another? > > I assume that all this only applies to implementations claiming compliance from a certain version of H.248 or of the rtp package, otherwise supporting the broken syntax using a dot, e.g rtp/pl=23.4375 or rtp/pl="23.4375" has better chances for interoperability. This is of course a guess, as nobody in the list, myself included, took up Christian's invitation to say how they represented rtp/pl until now. > > Raphael Tryster > > -----Original Message----- > From: Troy Cauble [mailto:troy@bell-labs.com] > Sent: Tuesday, November 28, 2006 6:38 PM > To: Kevin Boyle > Cc: Albrecht.Schwarz@alcatel.de; megaco@ietf.org; Christian Groves > Subject: Re: [Megaco] rtp/pl *syntax broken* in the V2 IG > > > Kevin, > > Sorry for the late response, I was on vacation last week. > > The example seems unnecessarily complex. > Aren't your 5 steps equivalent to "multiply the percentage by 2^32"? > > (Not multiply the fractional part and combine with the integer part.) > > -troy > > > Kevin Boyle wrote: > >> All, >> >> The IG item in question was modified at the Ottawa Rapporteur's Meeting in August to read like this: >> >> "Possible values: a 32-bit whole number and a 32-bit fraction. The value shall be encoded in ABNF as a string "x.y" where x is the whole part and y the fractional part of the percentage. >> >> The actual data type is a fixed point number, which is mapped on the H.248 type "double". The whole number and the fractional part shall be interpreted as 32-bit integer each, thus the "double" type for rtp/pl shall be encoded as the concatenation of two integers. The fractional part must be therefore first converted into an integer, i.e. multiplied by 2^32. >> >> Binary encoding shall be as described in clause A.2 for type "integer"." >> >> It was recognized at the meeting here in Geneva that this text still does not resolve the issue brought up by Troy: that the use of a string breaks the syntax. >> >> Therefore, I have produced text at the direction of the meeting to address this issue. I propose the following text: >> >> "Possible values: a 32-bit whole number and a 32-bit fraction. >> >> The actual data type is a fixed point number, which is mapped on the H.248 type "double". The whole number and the fractional part shall be interpreted as 32-bit integer each, thus the "double" type for rtp/pl shall be encoded as the concatenation of two integers. The fractional part must be therefore first converted into an integer, i.e. multiplied by 2^32. >> >> For example, given the percentage 23.625, to express this in the Packet Loss Statistic we perform the following steps: >> >> 1. Convert the number to binary: 23.625 base 10 equals 10111.101 base 2. >> 2. Break the binary representation into the whole number and the fraction: Whole = 10111; fraction = .101 >> 3. Convert the fraction into a whole number. Because half of a double is 32 bits wide, multiple the fraction by 232. The fractional part in our example now becomes 10100000000000000000000000000000. Note that multiplying a binary number by a power of two is the same as shifting it to the left the same number of places as the power of two by which it is being multiplied. >> 4. Concatenate the whole portion and the converted fraction together: 1011110100000000000000000000000000000 is the binary value of our statistic. >> 5. Convert the binary value to integer: the statistic is reported as having value 101468602368. >> >> To return the statistic back to its fractional representation, the steps are reversed. Once the integer is converted back to its binary form, the lower 32 bits represent the fraction and the rest are the whole number. From there, conversion back to a floating point integer is fairly straightforward. >> >> Binary encoding shall be as described in clause A.2 for type "integer"." >> >> Comments? Note that this text will be put forward for approval at the end of the week, therefore any concerns need to be voiced by Thursday. >> >> Kevin >> (H.248 IG Editor) >> >> -----Original Message----- >> From: Christian Groves [mailto:Christian.Groves@nteczone.com] >> Sent: Wednesday, November 01, 2006 6:27 PM >> To: Troy Cauble >> Cc: Albrecht.Schwarz@alcatel.de; megaco@ietf.org >> Subject: Re: [Megaco] rtp/pl *syntax broken* in the V2 IG >> >> Hello Troy, >> >> I'll put this on the agenda of the upcoming q.3/16 meeting. >> I do understand your concerns about redefinition of type. So we can revisit this IG item. Unfortunately it seems given the original definition somebodies implementation is going to be broken no matter what we do. It would be interesting to hear from other on the list as to how they have represented rtp/pl since version one. >> >> In terms of FLOAT discussion of this has been added to the "H.248.1v4 living list" as it was recognised that any changes for this would result in syntax change. >> >> Regards, Christian >> >> Troy Cauble wrote: >> >> >>> Thanks Albrecht, >>> >>> You concern is more general than mine. >>> >>> I don't find the arguments for adding FLOATs in V4 compelling. >>> But if they are to be added, you need to give them real ASN.1 data >>> types. All of the current parameters have embedded type information >>> in the ASN.1. Why should these then be lumped into OCTET STRING? >>> >>> >>> But back to my current V1/V2 issue. >>> >>> What are V1 and V2 compliant systems to do with rtp/pl? >>> The V2 IG fixed a confusing spec by specifying a *broken syntax*. >>> >>> If I understand the decision (a) below correctly, it sidesteps the >>> whole question and doesn't solve anything. >>> There is no "undefined" parameter type in the protocol. >>> The way to specify the legal text and ASN.1 encodings is by picking a >>> type from 12.2. >>> >>> The only parameter type that can be text encoded "x.y" >>> is a STRING. (And it must have the double quotes, btw.) If we want >>> "x.y", we need to change the type to STRING. >>> >>> Or we can keep/change/clarify the scaling and either leave the type as >>> DOUBLE or change it to INTEGER. (Scaling by >>> 2^8 would fit in an INTEGER and satisfy the precision specified in >>> RFC3550.) >>> >>> -troy >>> >>> >>> Albrecht.Schwarz@alcatel.de wrote: >>> >>> >>>> Troy, >>>> do agree to your analysis, made also a proposal based on "scaling" >>>> (see AVD-2916). >>>> We did discuss this subject already in a couple of meetings (see list >>>> below) this year and finally agreed: >>>> >>>> a) to fix the interpretation of rtp/pl in the IMG (i.e., the H.248 >>>> served user instance may only interpret rtp/pl, the H.248 message >>>> decoder may not itself convert it in the final data structure), and >>>> b) extend the set of H.248 data types in H.248.1 Version 4 (i.e. data >>>> types are a V4 living list item). >>>> >>>> I would then for H.248.1 V4 propose to use "FLOAT32" (a 4-byte >>>> floating point number according the single-precision 32-bit IEEE 754 >>>> format) for rtp/pl, which would provide the advantages of a native >>>> data type, simple handling of fractional part, and avoidance of >>>> "complex data type conversions". >>>> >>>> Regards, Albrecht >>>> >>>> 1) http://ftp3.itu.int/av-arch/avc-site/2005-2008/0608_Ott/AVD-2916.zip >>>> Implementers' Guides for H.248.1 Version 2 & 3 ? ABNF Grammar >>>> for § >>>> E.12.4.3 Packet Loss rtp/pl >>>> >>>> 2) >>>> http://www.itu.int/md/meetingdoc.asp?lang=en&parent=T05-SG16-060403-D >>>> -0303 >>>> >>>> => § 2.6 H.248.1 v1, 2, 3 Clarification on rtp/pl coding >>>> >>>> 3) >>>> http://www.itu.int/md/meetingdoc.asp?lang=en&parent=T05-SG16-060403-D >>>> -0228 >>>> >>>> H.248.1 - Discussion on floating numbers data types and example >>>> scenarios for type conversions >>>> >>>> 4) >>>> http://www.itu.int/md/meetingdoc.asp?lang=en&parent=T05-SG16-060403-D >>>> -0227 >>>> >>>> H.248.1 - Missing Data Type(s) for Floating Numbers (IEEE 754) >>>> >>>> >>>> >>>> >>>> Troy >>>> Cauble >>>> >>> megaco@ietf.org >>>> com> >>>> cc: >>>> Subject: [Megaco] >>>> rtp/pl non-double breakage in the V2 >>>> IG 30.10.2006 >>>> 18:15 >>>> >>>> >>>> >>>> >>>> >>>> >>>> I just noticed the following clarification in the >>>> H.248.1 V2 IG involving the rtp/pl value. >>>> >>>> It says that rtp/pl is a double that be encoded "x.y" >>>> >>>> But if it can be encoded "x.y" it is not a double. >>>> A double is defined in the document as a 64 bit integer. >>>> A double's text encoding is defined as follows. >>>> >>>> ; Integer, Double, and Unsigned Integer: Decimal values can be >>>> encoded ; using characters 0-9. Hexadecimal values must be prefixed with '0x' >>>> ; and can use characters 0-9,a-f,A-F. An octal format is not supported. >>>> ; Negative integers start with '-' and MUST be Decimal. The SafeChar >>>> ; form of VALUE MUST be used. >>>> >>>> Saying it can be encoded "x.y" is inventing a new type that needs to >>>> be defined in the main document, with support for text and ASN.1 >>>> encodings. >>>> >>>> Casual re-definitions or type inventions within package definitions >>>> should not be allowed. >>>> >>>> The problem being solved, a vague original definition, should be >>>> fixed by saying the integer representation is achieved by multiplying >>>> the percentage by 1000. >>>> (Or some other number.) It could easily be changed from double to >>>> integer as well. >>>> >>>> -troy >>>> >>>> >>>> >>>> _______________________________________________ >>>> Megaco mailing list >>>> Megaco@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/megaco >>>> >>>> >>>> >>>> >>> _______________________________________________ >>> Megaco mailing list >>> Megaco@ietf.org >>> https://www1.ietf.org/mailman/listinfo/megaco >>> >>> >>> >>> >>> >> _______________________________________________ >> Megaco mailing list >> Megaco@ietf.org >> https://www1.ietf.org/mailman/listinfo/megaco >> > > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > > > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Tue Sep 11 22:59:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVIPr-0007nC-5U; Tue, 11 Sep 2007 22:57:23 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVIPp-0007n4-He for megaco@ietf.org; Tue, 11 Sep 2007 22:57:21 -0400 Received: from ipmail03.adl2.internode.on.net ([203.16.214.135]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVIPn-0007x8-3O for megaco@ietf.org; Tue, 11 Sep 2007 22:57:21 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAPLw5kY7p0LC/2dsb2JhbAAM X-IronPort-AV: E=Sophos;i="4.20,241,1186324200"; d="scan'208";a="147444081" Received: from ppp59-167-66-194.lns1.mel4.internode.on.net (HELO [127.0.0.1]) ([59.167.66.194]) by ipmail03.adl2.internode.on.net with ESMTP; 12 Sep 2007 12:27:10 +0930 Message-ID: <46E75578.9050407@nteczone.com> Date: Wed, 12 Sep 2007 12:56:56 +1000 From: Christian Groves User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Raphael Tryster Subject: Re: [Megaco] Question about RTP payloadtype References: <46E0B98B.1030002@nteczone.com> <431F3BDE11BF2F42A22CBEFA36BD88A4F606E9@mailserver.vocaltec.local> In-Reply-To: <431F3BDE11BF2F42A22CBEFA36BD88A4F606E9@mailserver.vocaltec.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bfef20db74c24e87b6dbcd42ea7ba67c Cc: megaco@ietf.org, Albrecht.Schwarz@alcatel-lucent.de X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: megaco-bounces@ietf.org Hello Raphael, In itself I don't think specifying what a position means in a list is goes against the spirit of a list. There are other examples where list positions relate etc. However I would agree that a separate parameter would typically be a better way on achieving this for this 2 list position case. I think Steve's proposal has some merit with regards to the logic on how to indicate rx and tx codec payload change though this proposal assumes that tx payload change was covered. However I did some more digging through and found that I was to culprit behind the original text. The text that I proposed in 1999 hasn't changed. I can't remember why a list was chosen other than it was added after a discussion on codec negotiation which made use of codec lists. Given that there hasn't been many questions on this event and people seem to agree that a single codec means a received payload change I'd be quite happy to aaply to KISS principle and simply add a note to the effect: "A single value represents a received payload change. Typically multiple payload changes would be notified separately. Where multiple values are returned they also represent received payload changes. The use cases for multiple values is FFS." If someone wants a separate event for tx payload change then they can bring a contribution/ propose to the this to add it. It seems that we've come full circle back to your first question Raphael. Regards, Christian Raphael Tryster wrote: > I am wondering if this goes against the spirit of what a list is. If > you can say that the first element in the list means this and the second > element means that and you can't have more than two, then the > appropriate representation of this functionality is two parameters and > not a list. Are there any other cases in Megaco where a list is used in > this way? > > I understand there is a backward compatibility issue, but it appears the > only thing we need to be backward compatible with is a single value > meaning Rx change. If, instead of a list, we add a second parameter > meaning Tx change, would this break more implementations than keeping > the list with the semantics now being suggested? > > Raphael Tryster > > -----Original Message----- > From: Stephen Mell (CV/ETL) [mailto:stephen.mell@ericsson.com] > Sent: Tuesday, September 11, 2007 4:28 PM > To: Christian Groves > Cc: Raphael Tryster; Albrecht.Schwarz@alcatel-lucent.de; megaco@ietf.org > Subject: RE: [Megaco] Question about RTP payloadtype > > Hi Christian, > > Exploring your initial ideas a bit further: > > If mode is sendonly or recvonly then a single value might be interpreted > with respect to the media mode that is currently in force, as tx pltrans > and rx pltrans respectively. This could be difficult to interpret if the > event is generated during a mode change, so Im not sure that idea is too > great. > > If mode is sendrecv and only the transmit codec changes (perhaps the > original bidirectional connection was asymmetrical and the Rx codec was > already uncompressed in a VoiceBandData switch scenario), then the list > semantics are problematic, as it is not possible to represent a change > in Tx only in this way (as it is the second element in the list). Maybe > for these purposes a sentinel value can be employed to explicilty > signify that no RX codec change has taken place: > > E.g. rtp/pltrans = [ None, G711 ] - Rx no change, Tx changed to 8 > > I also think it would there are advantages if an MGC were able to > unambiguously report a change in Rx codec, without an implied change in > Tx codec in that Observed Event, as this could serve as an indication > for situations where automated VBD switches between gateways have failed > to work properly. > > Having said that its probably more important to maintain backward > compatibility with existing implementations. I would guess that many > implementations only ever report one value for rtp/pltrans and that > value is the New Rx CODEC, and this would be true regardless of whether > the Tx codec has changed or not. Given the existing vagueness of the > published package, these implementations seem reasonable to me. For > backward compatibility reasons, it might be wise to state that reporting > of a change in Tx Codec is optional. In the case where the Tx codec at > the end of the list is not present than it would not be possible to tell > if the Tx codec had changed or not. If the MG puts the sentinel value as > the second value in the codec list, then it would be possible to infer > that the Tx codec has not changed. > > > In summary, a suggested scheme using sentinel values to explicility > signify NoChange and at the same time (hopefully) achieving backward > compatibility:- > > > rtp/pltrans = G711 - Rx changed to G711, no information about Tx change > can > be inferred by the MGC (for backward > compatibility) > rtp/pltrans = [ None, G711 ] - Rx No change, Tx changed to g711 > rtp/pltrans = [ G711, None ] - Rx changed to g711, Tx No Change > rtp/pltrans = [ G711, G711 ] - Rx changed to g711, Tx changed to g711 > rtp/pltrans = [ None, None ] - TxRx no change - MG should not report > this! > > Interpretation of above is always independent of the media mode. > > > Steve > > -----Original Message----- > From: Christian Groves [mailto:Christian.Groves@nteczone.com] > Sent: 07 September 2007 03:38 > To: Raphael Tryster > Cc: megaco@ietf.org; Schwarz Albrecht > Subject: Re: [Megaco] Question about RTP payloadtype > > Hello Raphael, > > I believe that having the rtp/pltrans as a list of was to account for > the case where an event was set and the MG detected a change in codec in > both the send and receive directions. Events sit at a level higher than > the local/remote descriptors so in theory it covers both. The list of > allowed the notification of both directions to be signalled, e.g. able > to notify when a change in codec on the received stream, able to notify > when a MG autonomously decides to change the codec sent. I suspect that > there wasn't more thought on specific use cases when it was added. > > The thread you pointed to highlights the issue but it seems that the > note proposed back then didn't make it into an implementor's guide > proposal. If we now add something to the IG then we need to agree on: > a) what a single value in the list means > b) what 2 values in the list means > c) can there be more than 2? > > Some initial thoughts: > On a) Does a single value mean a codec change in both the send/receive > direction (symmetrical change) or only the receive direction? > On b) I think we could easily say that the first value is the local > value, the second is the remote On c) I can't see a case for three so we > may be able to limit the list size to 2. > > I tried to find where the text originated to see if this could provide > some more information. It seems it came from the period between the > November 1999 Washington IETF meeting and the Feb 2000 ITU. However I > can't find any email/contribution actually proposing it. > > Regards, Christian > > PS: Raphael, you need to update your address book I haven't worked > Ericsson for some time now :-). > > Raphael Tryster wrote: > >> Steve, >> >> It doesn't sound plausible to me, because: >> >> 1. If things like VAD or RFC2833 were intended to be included in >> reports of a periodic payload transition, then it stands to reason >> that they should also be reported when there is no periodic payload >> transition. That could produce a barrage of notifications, and I doubt >> > > >> that is what the designers of rtp/pltrans had in mind. >> >> 2. If you ask me to deliver an envelope to someone outside the office, >> > > >> then while I am getting ready to leave the office you can add things >> that you remember at the last minute. That's because I am human and >> not a computer (some people dispute that). Computer programs generally >> > > >> have "left the office" as soon as they get a job to do, and would have >> > > >> to be complicated considerably to provide the kind of functionality >> you suggest. >> >> So, unless one of the authors informs us otherwise, I'm betting they >> had something else in mind. >> >> Raphael Tryster >> >> ---------------------------------------------------------------------- >> -- >> >> *From:* Stephen Mell (CV/ETL) [mailto:stephen.mell@ericsson.com] >> *Sent:* Thursday, September 06, 2007 6:38 PM >> *To:* Raphael Tryster >> *Cc:* Schwarz Albrecht; Christian Groves; megaco@ietf.org >> *Subject:* RE: [Megaco] Question about RTP payloadtype >> >> Raphael, >> >> Perhaps this multiple payload type would be used when transiting to a >> compression codec which supplemeted by non-periodic packets with a >> different payload type - for example RFC2833 Out-Of-Band RTP events or >> > > >> VAD packets for the purposes of comfort noise generation, these will >> always use a different payload type to the periodic compression codec. >> >> By the time that the Rx media handling engine has detected the change >> in codec (received at least N periodic packets of the new compressed >> codec) and wishes to report it, there is a slim chance that some of >> the non-periodic (supplementary) packets have also been received as >> well, so the MG may report Received periodic and non-periodic codec >> types in the pltrans event >> >> Does that sound feasible? >> >> Steve >> >> ---------------------------------------------------------------------- >> -- >> >> *From:* Raphael Tryster [mailto:raphael.tryster@vocaltec.com] >> *Sent:* 06 September 2007 14:40 >> *To:* Schwarz Albrecht; Christian Groves >> *Cc:* megaco@ietf.org >> *Subject:* RE: [Megaco] Question about RTP payloadtype >> >> Albrecht, >> >> What you wrote clarifies the discussion of 5 years ago, but I am still >> > > >> puzzled why a list and not a single value. Clearly, the RTP payload >> cannot change to multiple different values at the same time. That >> suggests that changes that occurred at different times are being >> reported together, and I am wondering how this would be done. >> >> Raphael Tryster >> >> ---------------------------------------------------------------------- >> -- >> >> *From:* Schwarz Albrecht [mailto:Albrecht.Schwarz@alcatel-lucent.de] >> *Sent:* Thursday, September 06, 2007 4:26 PM >> *To:* Raphael Tryster; Christian Groves >> *Cc:* megaco@ietf.org >> *Subject:* RE: [Megaco] Question about RTP payloadtype >> >> rtp/pltrans is an event, thus for the Rx flow only ("the semantic is >> not explicitly extended on the Tx flow as well, as e.g. done in >> H.248.40"). Right? >> >> If my understanding is correct, the the semantic means RTP payload >> type changes just of the remote RTP endpoint. >> >> Guess your rtppltype list is correct. >> >> -Albrecht >> >> >> ---------------------------------------------------------------------- >> -- >> >> *From:* Raphael Tryster [mailto:raphael.tryster@vocaltec.com] >> *Sent:* Donnerstag, 6. September 2007 13:25 >> *To:* Christian Groves >> *Cc:* megaco@ietf.org >> *Subject:* RE: [Megaco] Question about RTP payloadtype >> >> This is a continuation of a thread that I started a few days ago, >> but the exchange below from 5 years ago is somewhat relevant, as >> it establishes that the rtppltype parameter of rtp/pltrans does >> not refer to Rx/Tx. My question is then, what is the meaning of >> rtppltype being of type sublist of enumeration? Syntactically, I >> assume this means something like >> >> ObservedEvents = 1111 { 20070906T141539 : rtp/pltrans { rtppltype >> = [g723, g729] } } >> >> But what does it mean semantically? How could it happen that two >> payload type transitions are reported in the same notification? >> >> If all but the last payload type in the list is being reported >> with a delay, what is the mechanism by which this delayed >> reporting is engineered? Is there a way that the MGC could request >> buffering of such events, and then have them all reported at once >> by requesting that ObservedEvents be included in the reply to >> Subtract? >> >> Raphael Tryster >> >> >> ---------------------------------------------------------------------- >> -- >> >> *From:* Terry L Anderson [mailto:tlatla@verizon.net] >> *Sent:* Tuesday, October 29, 2002 8:55 PM >> *To:* Christian Groves >> *Cc:* Seunghan Choi; megaco@ietf.org >> *Subject:* Re: [Megaco] Question about RTP payloadtype >> >> Agreed. We would need to bump the version of the package. Perhaps >> we should add a note to rtp v1 and add a parameter to rtp v2 >> >> Christian Groves wrote: >> >> G'Day, >> >> >> >> The assumption behind E.12 was that the payload was symmetrical. >> We could add a >> >> note stating this but I believe the additional of an extra >> parameter is beyond >> >> an IG item. There no way to add an extra parameter to an event and >> > > >> maintain >> >> backward compatibility, it would have to be a new event. >> >> >> >> Regards, Christian >> >> >> >> That is a very good issue. There is no parameter in the current >> event >> >> notice to indicate which of the two payloads changed. While many >> use >> >> symmetric payload types this is certainly not a requirement. I >> suppose >> >> we should consider adding a parameter of enumeration type with >> values of >> >> send, recv, sendRecv to include with the notice. >> >> >> >> Kevin Boyle is our new Implementors Guide editor (as of the end of >> > > >> the >> >> SG16 meeting today, I am handing over the editorship rather than >> do that >> >> as well as rapporteur). Kevin can propose a fix for discussion on >> > the list. > >> >> >> Seunghan Choi wrote: >> >> >> >> >> >> >>> Hi, All. >>> >>> Is there the case that RTPpayload type(Rx CodecType) in >>> > localDescriptor and RTPpayload type(Tx CodecType) in remoteDescriptor is > different? > >>> If there is that case, Which does the rtppltype mean, Rx >>> > CodecType or Tx CodecType, in E.12 Payload Transition? > >>> >>> Thanks. >>> >>> >>> >> >> >> >> >> >> >> >> >> ---------------------------------------------------------------------- >> -- >> >> _______________________________________________ >> Megaco mailing list >> Megaco@ietf.org >> https://www1.ietf.org/mailman/listinfo/megaco >> >> > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > > > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Wed Sep 12 14:53:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVXJr-0004lm-3l; Wed, 12 Sep 2007 14:52:11 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVXJp-0004lg-Tp for megaco@ietf.org; Wed, 12 Sep 2007 14:52:09 -0400 Received: from prattle.redback.com ([155.53.12.9]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVXJp-0004TK-JH for megaco@ietf.org; Wed, 12 Sep 2007 14:52:09 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id DC3CB3ABC83; Wed, 12 Sep 2007 11:52:08 -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 32224-05; Wed, 12 Sep 2007 11:52:08 -0700 (PDT) Received: from [155.53.44.239] (cologne.redback.com [155.53.44.239]) by prattle.redback.com (Postfix) with ESMTP id C2E453ABC82; Wed, 12 Sep 2007 11:52:08 -0700 (PDT) Message-ID: <46E83558.6000909@redback.com> Date: Wed, 12 Sep 2007 11:52:08 -0700 From: Ashish Singh User-Agent: Thunderbird 1.5.0.9 (X11/20061206) MIME-Version: 1.0 To: Megaco List , "se-voip@redback.com" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Subject: [Megaco] Active MGC is deleted X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: megaco-bounces@ietf.org Hi List, Just wanted to take your opinion on how should MG behave when configuration entity deletes the MGC that is currently active. MG will delete the association the with current active MGC and try to re-establish the association with remaining MGCs in the list. One thing I am not sure is whether MG should send any service change to the MGC that got deleted before tearing down the association with it. If yes, what service change method and reason should be used. Thanks Ashish _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From Rainerwor@TRICONEX.COM Sat Sep 15 05:01:25 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWTWn-0002gK-H2 for megaco-archive@lists.ietf.org; Sat, 15 Sep 2007 05:01:25 -0400 Received: from host199-223-static.73-81-b.business.telecomitalia.it ([81.73.223.199]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IWTWm-0004n3-Je for megaco-archive@lists.ietf.org; Sat, 15 Sep 2007 05:01:25 -0400 Received: from MASSIMO ([144.175.10.80]:9272 "EHLO MASSIMO" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by [81.73.223.199] with ESMTP id S22IBPYPUEAYRMKW (ORCPT ); Sat, 15 Sep 2007 11:01:35 +0200 Message-ID: <000401c7f776$f20f7790$c7df4951@MASSIMO> From: "dheeraj Rainer" To: Subject: makuksat Date: Sat, 15 Sep 2007 11:01:04 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C7F787.B5984790" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 4.9 (++++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0008_01C7F787.B5984790 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://ktscert.com/ Greeting megaco-archive You will truly be amazed at the results. dheeraj Rainer ------=_NextPart_000_0008_01C7F787.B5984790 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://ktscert.com/
Greeting megaco-archive
You will truly be amazed at the = results.
dheeraj Rainer
------=_NextPart_000_0008_01C7F787.B5984790-- From Greky_Jagtiani@cc-dimensions.com Sat Sep 15 13:22:24 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWbLc-0008Ti-RX for megaco-archive@lists.ietf.org; Sat, 15 Sep 2007 13:22:24 -0400 Received: from adsl-dyn207.78-98-110.t-com.sk ([78.98.110.207]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IWbLb-0006vb-3p for megaco-archive@lists.ietf.org; Sat, 15 Sep 2007 13:22:24 -0400 Received: from infernoPC ([173.110.111.124] helo=infernoPC) by adsl-dyn207.78-98-110.t-com.sk ( sendmail 8.13.3/8.13.1) with esmtpa id 1qPQKQ-000WFF-be for megaco-archive@lists.ietf.org; Sat, 15 Sep 2007 19:23:21 +0200 Message-ID: <000a01c7f7bd$0ab3e5b0$cf6e624e@infernoPC> From: "Greky Jagtiani" To: Subject: 1pygmy Date: Sat, 15 Sep 2007 19:22:50 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C7F7CD.CE3E3C50" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 3.4 (+++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0005_01C7F7CD.CE3E3C50 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable http://goslx.com/ Good evening megaco-archive i am the most confident person in the world now.. Greky Jagtiani ------=_NextPart_000_0005_01C7F7CD.CE3E3C50 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
http://goslx.com/
Good evening megaco-archive
i am the most confident person in the world = now..
Greky Jagtiani
------=_NextPart_000_0005_01C7F7CD.CE3E3C50-- From gauna@athv.de Sat Sep 15 14:08:27 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWc4B-000142-TD for megaco-archive@lists.ietf.org; Sat, 15 Sep 2007 14:08:27 -0400 Received: from host171-135-dynamic.3-79-r.retail.telecomitalia.it ([79.3.135.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IWc49-0008Dy-Us for megaco-archive@lists.ietf.org; Sat, 15 Sep 2007 14:08:27 -0400 Received: from vetrano-mhk2fi0 ([182.100.118.186]:26431 "EHLO vetrano-mhk2fi0" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by host171-135-dynamic.3-79-r.retail.telecomitalia.it with ESMTP id S22GZWTTTADOKPOE (ORCPT ); Sat, 15 Sep 2007 20:09:28 +0200 Message-ID: <000a01c7f7c3$7b1f7110$ab87034f@vetranomhk2fi0> From: "fvgfxcg gauna" To: Subject: olihpnon Date: Sat, 15 Sep 2007 20:08:55 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C7F7D4.3EA84110" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 3.2 (+++) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 ------=_NextPart_000_0005_01C7F7D4.3EA84110 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://www.granneis.com/ compliments megaco-archive voted no.1 male enhancement product 2005 - 2007 Mens Health Inc fvgfxcg gauna ------=_NextPart_000_0005_01C7F7D4.3EA84110 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://www.granneis.com/
compliments megaco-archive
voted no.1 male enhancement product 2005 - = 2007 Mens=20 Health Inc
fvgfxcg gauna
------=_NextPart_000_0005_01C7F7D4.3EA84110-- From Winnie@persson.vg Sat Sep 15 20:39:39 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWiAl-00034h-2l for megaco-archive@lists.ietf.org; Sat, 15 Sep 2007 20:39:39 -0400 Received: from [61.87.240.45] (helo=[61.87.240.45]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IWiAk-0004vO-9U for megaco-archive@lists.ietf.org; Sat, 15 Sep 2007 20:39:39 -0400 Received: from FANLIANHUA ([157.160.25.132] helo=FANLIANHUA) by [61.87.240.45] ( sendmail 8.13.3/8.13.1) with esmtpa id 1Nbfwr-000JCY-zs for megaco-archive@lists.ietf.org; Sun, 16 Sep 2007 08:39:34 +0800 Message-ID: <000601c7f7fa$02e4c420$2df0573d@FANLIANHUA> From: "Winnie feuerstein" To: Subject: edcars-w Date: Sun, 16 Sep 2007 08:39:16 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C7F83D.11080420" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 3.9 (+++) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 ------=_NextPart_000_0006_01C7F83D.11080420 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable http://www.boucenbobs.com/ Hi megaco-archive My cock is soooo big now, thanks to these doctors Winnie feuerstein ------=_NextPart_000_0006_01C7F83D.11080420 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
http://www.boucenbobs.com/=
Hi megaco-archive
My cock is soooo big now, thanks to these = doctors
Winnie feuerstein
------=_NextPart_000_0006_01C7F83D.11080420-- From lindefurxks@jusoo.ch Sun Sep 16 08:19:30 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWt62-0002bg-NT for megaco-archive@lists.ietf.org; Sun, 16 Sep 2007 08:19:30 -0400 Received: from host62-119-dynamic.48-82-r.retail.telecomitalia.it ([82.48.119.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IWt61-0007Vg-SE for megaco-archive@lists.ietf.org; Sun, 16 Sep 2007 08:19:30 -0400 Received: from mp11 ([101.132.76.71]:30918 "EHLO mp11" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by host62-119-dynamic.48-82-r.retail.telecomitalia.it with ESMTP id S22VVEMEQWOOTOGY (ORCPT ); Sun, 16 Sep 2007 14:20:37 +0200 Message-ID: <000801c7f85b$f119c9e0$3e773052@mp11> From: "NIKOS lindefur" To: Subject: sisatsog Date: Sun, 16 Sep 2007 14:20:17 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C7F86C.B4A299E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 3.5 (+++) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 ------=_NextPart_000_0007_01C7F86C.B4A299E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://cybertwn.com/ Good night megaco-archive Do you want to have an average to small penis all of your life? No, you = don't NIKOS lindefur ------=_NextPart_000_0007_01C7F86C.B4A299E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://cybertwn.com/
Good night megaco-archive
Do you want to have an average to small penis = all of=20 your life? No, you don't
NIKOS lindefur
------=_NextPart_000_0007_01C7F86C.B4A299E0-- From MenechiaPilsner@arcobem.com Sun Sep 16 13:46:23 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWyCN-0004He-Jo for megaco-archive@lists.ietf.org; Sun, 16 Sep 2007 13:46:23 -0400 Received: from host52-54-dynamic.11-87-r.retail.telecomitalia.it ([87.11.54.52] helo=host213-164-dynamic.7-87-r.retail.telecomitalia.it) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IWyCM-0008WV-UK for megaco-archive@lists.ietf.org; Sun, 16 Sep 2007 13:46:23 -0400 Received: from computer by arcobem.com with ASMTP id C66AAADE for ; Sun, 16 Sep 2007 19:47:09 +0200 Received: from computer ([144.170.122.161]) by arcobem.com with ESMTP id CB944BF4D142 for ; Sun, 16 Sep 2007 19:47:09 +0200 Message-ID: <000801c7f889$8aa47470$d5a40757@computer> From: "Menechia Pilsner" To: Subject: relpek Date: Sun, 16 Sep 2007 19:46:42 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C7F89A.4E2D4470" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 2.1 (++) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 ------=_NextPart_000_0006_01C7F89A.4E2D4470 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://www.cwjos.com/ regards megaco-archive Before Manster i had no women, now i have 3 going at once =3D ) Menechia Pilsner ------=_NextPart_000_0006_01C7F89A.4E2D4470 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://www.cwjos.com/
regards megaco-archive
Before Manster i had no women, now i have 3 = going at=20 once =3D )
Menechia Pilsner
------=_NextPart_000_0006_01C7F89A.4E2D4470-- From phat131@am3d.dk Mon Sep 17 04:52:42 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXCLS-0005DV-KN for megaco-archive@lists.ietf.org; Mon, 17 Sep 2007 04:52:42 -0400 Received: from net84-253-137-234.mclink.it ([84.253.137.234]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXCLQ-0004zb-Vi for megaco-archive@lists.ietf.org; Mon, 17 Sep 2007 04:52:42 -0400 Received: from gareth ([186.135.129.77] helo=gareth) by net84-253-137-234.mclink.it ( sendmail 8.13.3/8.13.1) with esmtpa id 1oijRD-000ZUX-xW for megaco-archive@lists.ietf.org; Mon, 17 Sep 2007 10:54:11 +0200 Message-ID: <000c01c7f908$44ff8700$ea89fd54@gareth> From: "phat Hutchinson" To: Subject: neenioku Date: Mon, 17 Sep 2007 10:53:51 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C7F919.08885700" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 1.9 (+) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 ------=_NextPart_000_0005_01C7F919.08885700 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://crumpe.com/ Regards megaco-archive Get 3 FREE bottles if you order 6 mths supply. Herbal penis pills... get = BIG today.. phat Hutchinson ------=_NextPart_000_0005_01C7F919.08885700 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://crumpe.com/
Regards megaco-archive
Get 3 FREE bottles if you order 6 mths supply. = Herbal=20 penis pills... get BIG today..
phat Hutchinson
------=_NextPart_000_0005_01C7F919.08885700-- From Alok-Jeanclerc@ducharmeconsulting.com Mon Sep 17 09:52:35 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXH1f-0007WH-Ae for megaco-archive@lists.ietf.org; Mon, 17 Sep 2007 09:52:35 -0400 Received: from [201.79.11.47] (helo=20179011047.user.veloxzone.com.br) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IXH1e-0006xP-2j for megaco-archive@lists.ietf.org; Mon, 17 Sep 2007 09:52:35 -0400 Received: from escritorio ([135.194.1.31] helo=escritorio) by 20179011047.user.veloxzone.com.br ( sendmail 8.13.3/8.13.1) with esmtpa id 1PdFQt-000ORN-gS for megaco-archive@lists.ietf.org; Mon, 17 Sep 2007 10:52:44 -0300 Message-ID: <000b01c7f931$f935e100$2f0b4fc9@escritorio> From: "Alok Jeanclerc" To: Subject: moussent Date: Mon, 17 Sep 2007 10:52:23 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C7F918.D3E8A900" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 4.2 (++++) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 ------=_NextPart_000_0009_01C7F918.D3E8A900 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://cwaomaha.com/ Wazzup megaco-archive Our herbal pills is recommended by top European physicians for penis = enlargement Alok Jeanclerc ------=_NextPart_000_0009_01C7F918.D3E8A900 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://cwaomaha.com/
Wazzup megaco-archive
Our herbal pills is recommended by top = European=20 physicians for penis enlargement
Alok Jeanclerc
------=_NextPart_000_0009_01C7F918.D3E8A900-- From Dynasty980@infon70.jet.es Mon Sep 17 12:03:49 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXJ4f-00068n-LP for megaco-archive@lists.ietf.org; Mon, 17 Sep 2007 12:03:49 -0400 Received: from adsll-135.baana.phpoy.fi ([62.241.215.135]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IXJ4e-0001hT-SP for megaco-archive@lists.ietf.org; Mon, 17 Sep 2007 12:03:49 -0400 Received: from PÄÄKONE ([192.159.98.102]:7452 "EHLO PÄÄKONE" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by adslL-135.baana.phpoy.fi with ESMTP id S22LKAMEZWERHYXM (ORCPT ); Mon, 17 Sep 2007 19:04:20 +0300 Message-ID: <000d01c7f944$5a8a64a0$87d7f13e@PKONE> From: "Dynasty PILOTTE" To: Subject: arcistic Date: Mon, 17 Sep 2007 19:03:57 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C7F95D.7FD79CA0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 4.1 (++++) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 ------=_NextPart_000_0005_01C7F95D.7FD79CA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://www.curruy.com/ Hi there megaco-archive Our herbal pills is recommended by top European physicians for penis enl= argement Dynasty PILOTTE ------=_NextPart_000_0005_01C7F95D.7FD79CA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi there megaco-archive
Our herbal pills is recommended by top Europea= n physicians for penis enlargement
Dynasty PILOTTE
------=_NextPart_000_0005_01C7F95D.7FD79CA0-- From megaco-bounces@ietf.org Mon Sep 17 15:34:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXMKq-0003CL-2r; Mon, 17 Sep 2007 15:32:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXMKo-0003CF-Np for megaco@ietf.org; Mon, 17 Sep 2007 15:32:42 -0400 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXMKe-0007CQ-2u for megaco@ietf.org; Mon, 17 Sep 2007 15:32:42 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 78FF270CC7B for ; Mon, 17 Sep 2007 12:32:23 -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 24735-09 for ; Mon, 17 Sep 2007 12:32:23 -0700 (PDT) Received: from [155.53.44.239] (cologne.redback.com [155.53.44.239]) by prattle.redback.com (Postfix) with ESMTP id 4AB3170CC7A for ; Mon, 17 Sep 2007 12:32:23 -0700 (PDT) Message-ID: <46EED647.3070408@redback.com> Date: Mon, 17 Sep 2007 12:32:23 -0700 From: Ashish Singh User-Agent: Thunderbird 1.5.0.9 (X11/20061206) MIME-Version: 1.0 To: Megaco List Content-Type: multipart/mixed; boundary="------------000402080006050309080605" X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Subject: [Megaco] Fwd: Active MGC is deleted X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: megaco-bounces@ietf.org This is a multi-part message in MIME format. --------------000402080006050309080605 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi List, I was expecting some discussion over my previous mail on this topic, but I didn't get any response from List, so rephrasing the question. When configuration entity deletes the MGC that is currently active, should MG send FORCED service change to the MGC that got deleted before tearing down the association with it and then contact remaining MGCs in the list. IMO, MG should NOT be sending any service change to the MGC that got deleted and directly contact remaining MGCs in the list. Any response will be highly appreciated. Thanks Ashish --------------000402080006050309080605 Content-Type: message/rfc822; name="[Megaco] Active MGC is deleted" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="[Megaco] Active MGC is deleted" X-Account-Key: account2 Return-Path: X-Original-To: ashishs@redback.com Delivered-To: ashishs@redback.com Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 6840CDC91E7; Wed, 12 Sep 2007 11:53:25 -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 32286-10; Wed, 12 Sep 2007 11:53:17 -0700 (PDT) Received: from megatron.ietf.org (stiedprmman1.ietf.ORG [156.154.16.145]) by prattle.redback.com (Postfix) with ESMTP id D5ECBDC91E4; Wed, 12 Sep 2007 11:53:17 -0700 (PDT) Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVXJr-0004lm-8q; Wed, 12 Sep 2007 14:52:11 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVXJp-0004lg-Tp for megaco@ietf.org; Wed, 12 Sep 2007 14:52:09 -0400 Received: from prattle.redback.com ([155.53.12.9]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVXJp-0004TK-JH for megaco@ietf.org; Wed, 12 Sep 2007 14:52:09 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id DC3CB3ABC83; Wed, 12 Sep 2007 11:52:08 -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 32224-05; Wed, 12 Sep 2007 11:52:08 -0700 (PDT) Received: from [155.53.44.239] (cologne.redback.com [155.53.44.239]) by prattle.redback.com (Postfix) with ESMTP id C2E453ABC82; Wed, 12 Sep 2007 11:52:08 -0700 (PDT) Message-ID: <46E83558.6000909@redback.com> Date: Wed, 12 Sep 2007 11:52:08 -0700 From: Ashish Singh User-Agent: Thunderbird 1.5.0.9 (X11/20061206) MIME-Version: 1.0 To: Megaco List , "se-voip@redback.com" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at redback.com X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Subject: [Megaco] Active MGC is deleted X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: megaco-bounces@ietf.org X-Virus-Scanned: by amavisd-new at redback.com Hi List, Just wanted to take your opinion on how should MG behave when configuration entity deletes the MGC that is currently active. MG will delete the association the with current active MGC and try to re-establish the association with remaining MGCs in the list. One thing I am not sure is whether MG should send any service change to the MGC that got deleted before tearing down the association with it. If yes, what service change method and reason should be used. Thanks Ashish _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --------------000402080006050309080605 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --------------000402080006050309080605-- From megaco-bounces@ietf.org Mon Sep 17 16:25:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXN8f-0008Di-TI; Mon, 17 Sep 2007 16:24:13 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXN8d-0008BB-Vw for megaco@ietf.org; Mon, 17 Sep 2007 16:24:12 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IXN8d-0003FI-M9 for megaco@ietf.org; Mon, 17 Sep 2007 16:24:11 -0400 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 l8HKO9D26327; Mon, 17 Sep 2007 20:24:09 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Megaco] Fwd: Active MGC is deleted Date: Mon, 17 Sep 2007 16:22:17 -0400 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA41165F6B5@zrtphxm2.corp.nortel.com> In-Reply-To: <46EED647.3070408@redback.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Megaco] Fwd: Active MGC is deleted thread-index: Acf5YwUBJYppXsQ+ToCbiLxoFhCH4gABCVrg References: <46EED647.3070408@redback.com> From: "Kevin Boyle" To: "Ashish Singh" , "Megaco List" X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: megaco-bounces@ietf.org Honestly, I don't see why deletion of the active MGC would/should be allowed. I think that ought to be restricted in the management software. This will lead to a lot fewer headaches and configuration issues, and will certainly reduce the likelihood of an outage. Kevin=20 -----Original Message----- From: Ashish Singh [mailto:ashishs@redback.com]=20 Sent: Monday, September 17, 2007 3:32 PM To: Megaco List Subject: [Megaco] Fwd: Active MGC is deleted Hi List, I was expecting some discussion over my previous mail on this topic, but I didn't get any response from List, so rephrasing the question. When configuration entity deletes the MGC that is currently active, should MG send FORCED service change to the MGC that got deleted before tearing down the association with it and then contact remaining MGCs in the list. IMO, MG should NOT be sending any service change to the MGC that got deleted and directly contact remaining MGCs in the list. Any response will be highly appreciated. Thanks Ashish _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From gabrhelbcor@finessemfg.com Mon Sep 17 21:25:00 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXRpk-0002W3-OM for megaco-archive@lists.ietf.org; Mon, 17 Sep 2007 21:25:00 -0400 Received: from [69.79.192.151] (helo=Dynamic-IP-cr20011813464.cable.net.co) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IXRpf-00032q-Sp for megaco-archive@lists.ietf.org; Mon, 17 Sep 2007 21:24:56 -0400 Received: from leo ([152.124.171.74] helo=leo) by Dynamic-IP-cr20011813464.cable.net.co ( sendmail 8.13.3/8.13.1) with esmtpa id 1ccqiI-000XSC-sL for megaco-archive@lists.ietf.org; Mon, 17 Sep 2007 20:34:24 -0500 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 17 Sep 2007 20:33:49 -0500 To: megaco-archive@lists.ietf.org From: "Hejssan gabrhel" Subject: dnefeoeg Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 2.1 (++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea greeting megaco-archive With M.anster you can look forward to the good times sexually. Hejssan gabrhel http://www.funsilly.net/ From Lippmannacauz@jgbcap.com Mon Sep 17 23:49:20 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXU5Q-0004rB-4K for megaco-archive@lists.ietf.org; Mon, 17 Sep 2007 23:49:20 -0400 Received: from [189.25.107.176] (helo=18925107176.user.veloxzone.com.br) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXU5F-0002xP-KD for megaco-archive@lists.ietf.org; Mon, 17 Sep 2007 23:49:11 -0400 Received: from minilab_7 ([181.146.162.147]:27871 "EHLO minilab_7" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by 18925107176.user.veloxzone.com.br with ESMTP id S22TZJQZPTNQIKMW (ORCPT ); Tue, 18 Sep 2007 00:50:16 -0300 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 18 Sep 2007 00:49:38 -0300 To: megaco-archive@lists.ietf.org From: "Reagan Lippmann" Subject: detoneri Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Night megaco-archive recommended by pornstars since 1999, this is there advantage Reagan Lippmann http://fzxcdz.com/ From megaco-bounces@ietf.org Tue Sep 18 01:36:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXVkB-0000DR-9u; Tue, 18 Sep 2007 01:35:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXVk9-0000DC-Aq for megaco@ietf.org; Tue, 18 Sep 2007 01:35:29 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXVk3-00057m-41 for megaco@ietf.org; Tue, 18 Sep 2007 01:35:29 -0400 X-IronPort-AV: E=Sophos;i="4.20,266,1186383600"; d="scan'208";a="524967636" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 17 Sep 2007 22:35:08 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l8I5Z7ss019324; Mon, 17 Sep 2007 22:35:07 -0700 Received: from sj-webmail-3.cisco.com (sj-webmail-3.cisco.com [171.70.156.8]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l8I5Z7pT011799; Tue, 18 Sep 2007 05:35:07 GMT Received: from sj-webmail-3.cisco.com (localhost.localdomain [127.0.0.1]) by sj-webmail-3.cisco.com (8.13.1/8.13.1) with ESMTP id l8I5Z7OO005146; Mon, 17 Sep 2007 22:35:07 -0700 Received: from sj-webmail-3 (root@localhost) by sj-webmail-3.cisco.com (8.13.1/8.13.1/Submit) with ESMTP id l8I5Z6c4005144; Mon, 17 Sep 2007 22:35:06 -0700 Received: from dsingh2wxp ( [10.76.212.187]) by sj-webmail-3 (Scalix SMTP Relay 10.0.5.3) via ESMTP; Mon, 17 Sep 2007 22:35:06 -0700 (PDT) Date: Tue, 18 Sep 2007 11:05:06 +0530 From: "Deepti Singh -X \(dsingh2 - Flextronics Software at Cisco\)" To: "'Kevin Boyle'" , "'Ashish Singh'" , "'Megaco List'" Message-ID: <00b701c7f9b5$ad3ad7e0$bbd44c0a@apac.cisco.com> In-Reply-To: <34B3EAA5B3066A42914D28C5ECF5FEA41165F6B5@zrtphxm2.corp.nortel.com> Subject: RE: [Megaco] Fwd: Active MGC is deleted x-scalix-Hops: 1 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: Acf5YwUBJYppXsQ+ToCbiLxoFhCH4gABCVrgABM17QA= MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1812; t=1190093707; x=1190957707; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dsingh2@cisco.com; z=From:=20=22Deepti=20Singh=20-X=20\(dsingh2=20-=20Flextronics=20Software= 20at=20Cisco\)=22=20 |Subject:=20RE=3A=20[Megaco]=20Fwd=3A=20Active=20MGC=20is=20deleted |Sender:=20; bh=ScxxFMsewNLKczXlpmpNEId+wRX+W/M3PHnmYZQoApk=; b=ghVX0aCikqGbcgcxhx+lEYFv8bqtY4bzubCW/iMJxGw8C09+5M0P0xQSC0ijvlltzCBOoK4H 8BhFLooBMk1ibuoUsn9fLBPCTBXOi1waZbCxxT4y3St4Lo6mbk8iXiz4; Authentication-Results: sj-dkim-3; header.From=dsingh2@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dsingh2@cisco.com List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: megaco-bounces@ietf.org I agree. Deletion of an active MGC through configuration should not be allowed. In case it is allowed and the configuration decides to delete an active MGC from its list, it has deliberately taken up a decision not to contact a particular active MGC in the list and proceed to the next ones in the list. In my opinion, no Service Change request would be needed in such a scenario since the gateway state has not change. Deepti -----Original Message----- From: Kevin Boyle [mailto:kboyle@nortel.com] Sent: Tuesday, September 18, 2007 1:52 AM To: Ashish Singh; Megaco List Subject: RE: [Megaco] Fwd: Active MGC is deleted Honestly, I don't see why deletion of the active MGC would/should be allowed. I think that ought to be restricted in the management software. This will lead to a lot fewer headaches and configuration issues, and will certainly reduce the likelihood of an outage. Kevin -----Original Message----- From: Ashish Singh [mailto:ashishs@redback.com] Sent: Monday, September 17, 2007 3:32 PM To: Megaco List Subject: [Megaco] Fwd: Active MGC is deleted Hi List, I was expecting some discussion over my previous mail on this topic, but I didn't get any response from List, so rephrasing the question. When configuration entity deletes the MGC that is currently active, should MG send FORCED service change to the MGC that got deleted before tearing down the association with it and then contact remaining MGCs in the list. IMO, MG should NOT be sending any service change to the MGC that got deleted and directly contact remaining MGCs in the list. Any response will be highly appreciated. Thanks Ashish _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Tue Sep 18 04:36:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXYW6-0000Ta-Rh; Tue, 18 Sep 2007 04:33:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXYW5-0000P7-KN for megaco@ietf.org; Tue, 18 Sep 2007 04:33:09 -0400 Received: from smail5.alcatel.fr ([62.23.212.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXYVt-0000Qt-4r for megaco@ietf.org; Tue, 18 Sep 2007 04:33:03 -0400 Received: from FRVELSBHS03.ad2.ad.alcatel.com (frvelsbhs03.ad2.ad.alcatel.com [155.132.6.75]) by smail5.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l8I8VjLg031179; Tue, 18 Sep 2007 10:31:45 +0200 Received: from FRVELSMBS15.ad2.ad.alcatel.com ([155.132.6.32]) by FRVELSBHS03.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Tue, 18 Sep 2007 10:32:25 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Megaco] Fwd: Active MGC is deleted X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 18 Sep 2007 10:32:24 +0200 Message-ID: <8BB8AD9870081C42B2B309E00352E4EAC03AA3@FRVELSMBS15.ad2.ad.alcatel.com> In-Reply-To: <00b701c7f9b5$ad3ad7e0$bbd44c0a@apac.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Megaco] Fwd: Active MGC is deleted Thread-Index: Acf5YwUBJYppXsQ+ToCbiLxoFhCH4gABCVrgABM17QAABgQH0A== References: <34B3EAA5B3066A42914D28C5ECF5FEA41165F6B5@zrtphxm2.corp.nortel.com> <00b701c7f9b5$ad3ad7e0$bbd44c0a@apac.cisco.com> From: "Schwarz Albrecht" To: , "Kevin Boyle" , "Ashish Singh" , "Megaco List" X-OriginalArrivalTime: 18 Sep 2007 08:32:25.0736 (UTC) FILETIME=[70FA0080:01C7F9CE] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.13 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: megaco-bounces@ietf.org Some comments: The element management systems (EMS) for the primary MGC, secondary MGCs and associated MGs must be coordinated. This implies activities in the management plane.=20 There are further interactions between an EMS and H.248 call-independent procedures. E.g., the ETSI TR 183 025 V2.0.0 2007-07 has such interactions in scope. Ashish, "deletion of an active MGC" could mean a couple of things ("when having also the m-plane in mind"). I would assume here that the current primary MGC, which is in in-service state, is put into out-of-service state (via configuration mgmt). Such an OAM activity should be accompained by other management activities in order to achieve an efficient network operation. E.g., your question may relate the "Disable MGC" action in clause 10.5/TR 183 025. This TR is also recommending additional management activities: 10.5 Disable MGC This primitive is sent to a MGC and results in a MGC being taken out of service.=20 Prior to the MGC being disabled, it is recommended that the MGC inform its dependent MGs to move their control associations to an alternative MGC via the MGC HANDOFF procedure (section 10.18) or that all dependent MGs are disabled prior to diabling the MGC (section 10.4). =20 -Albrecht > -----Original Message----- > From: Deepti Singh -X (dsingh2 - Flextronics Software at=20 > Cisco) [mailto:dsingh2@cisco.com]=20 > Sent: Dienstag, 18. September 2007 07:35 > To: 'Kevin Boyle'; 'Ashish Singh'; 'Megaco List' > Subject: RE: [Megaco] Fwd: Active MGC is deleted >=20 > I agree. Deletion of an active MGC through configuration=20 > should not be allowed. In case it is allowed and the=20 > configuration decides to delete an active MGC from its list,=20 > it has deliberately taken up a decision not to contact a=20 > particular active MGC in the list and proceed to the next=20 > ones in the list. In my opinion, no Service Change request=20 > would be needed in such a scenario since the gateway state=20 > has not change. >=20 > Deepti >=20 > -----Original Message----- > From: Kevin Boyle [mailto:kboyle@nortel.com] > Sent: Tuesday, September 18, 2007 1:52 AM > To: Ashish Singh; Megaco List > Subject: RE: [Megaco] Fwd: Active MGC is deleted >=20 > Honestly, I don't see why deletion of the active MGC=20 > would/should be allowed. I think that ought to be restricted=20 > in the management software. > This will lead to a lot fewer headaches and configuration=20 > issues, and will certainly reduce the likelihood of an outage. >=20 > Kevin=20 >=20 > -----Original Message----- > From: Ashish Singh [mailto:ashishs@redback.com] > Sent: Monday, September 17, 2007 3:32 PM > To: Megaco List > Subject: [Megaco] Fwd: Active MGC is deleted >=20 > Hi List, >=20 > I was expecting some discussion over my previous mail on this=20 > topic, but I didn't get any response from List, so rephrasing=20 > the question. >=20 > When configuration entity deletes the MGC that is currently=20 > active, should MG send FORCED service change to the MGC that=20 > got deleted before tearing down the association with it and=20 > then contact remaining MGCs in the list. >=20 > IMO, MG should NOT be sending any service change to the MGC=20 > that got deleted and directly contact remaining MGCs in the list. >=20 > Any response will be highly appreciated. >=20 > Thanks > Ashish >=20 >=20 > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco >=20 > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco >=20 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From Kepicmfo@domanicell.com Tue Sep 18 06:12:44 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXa4S-0002B5-OV for megaco-archive@lists.ietf.org; Tue, 18 Sep 2007 06:12:44 -0400 Received: from p4072-ipad36niho.hiroshima.ocn.ne.jp ([60.40.181.72]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IXa4Q-0006hM-EI for megaco-archive@lists.ietf.org; Tue, 18 Sep 2007 06:12:43 -0400 Received: by 10.234.104.59 with SMTP id jCfaubXUDztTZ; Tue, 18 Sep 2007 19:11:45 +0900 (GMT) Received: by 192.168.43.227 with SMTP id hMGeqCARvcIVna.1134700935858; Tue, 18 Sep 2007 19:11:43 +0900 (GMT) Message-ID: <000d01c7f9dc$4e3a1860$6c26203c@your13jxqacx6s> From: "Cathrine Kepic" To: Subject: ellinnou Date: Tue, 18 Sep 2007 19:11:40 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C7FA27.BE21C060" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 2.0 (++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0008_01C7FA27.BE21C060 Content-Type: text/plain; charset="shift_jis" Content-Transfer-Encoding: quoted-printable http://fsrbnk.com/ Wazzup megaco-archive recommended by pornstars since 1999, this is there advantage Cathrine Kepic ------=_NextPart_000_0008_01C7FA27.BE21C060 Content-Type: text/html; charset="shift_jis" Content-Transfer-Encoding: quoted-printable
http://fsrbnk.com/
Wazzup megaco-archive
recommended by pornstars since 1999, this is = there advantage
Cathrine Kepic
------=_NextPart_000_0008_01C7FA27.BE21C060-- From mingfengFrostholm@pggcohen.net Tue Sep 18 09:32:46 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXdC2-0004Kx-8n for megaco-archive@lists.ietf.org; Tue, 18 Sep 2007 09:32:46 -0400 Received: from 139.99.broadband9.iol.cz ([90.176.99.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXdBp-00072d-Qf for megaco-archive@lists.ietf.org; Tue, 18 Sep 2007 09:32:41 -0400 Received: by 10.163.215.156 with SMTP id FwZrqBjpphMMd; Tue, 18 Sep 2007 15:33:58 +0200 (GMT) Received: by 192.168.75.181 with SMTP id LYeaXnzUfaCVfW.2650911670765; Tue, 18 Sep 2007 15:33:56 +0200 (GMT) Message-ID: <000a01c7f9f8$8dfe5710$8b63b05a@zdena> From: "mingfeng Frostholm" To: Subject: atiedoel Date: Tue, 18 Sep 2007 15:33:53 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C7FA09.51872710" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 1.8 (+) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 ------=_NextPart_000_0004_01C7FA09.51872710 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable http://www.croftytv.com/ Wassup megaco-archive life is short, dont have a small cock all your life mingfeng Frostholm ------=_NextPart_000_0004_01C7FA09.51872710 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
http://www.croftytv.com/
Wassup megaco-archive
life is short, dont have a small cock all your = life
mingfeng Frostholm
------=_NextPart_000_0004_01C7FA09.51872710-- From nicole.paraggio@filterinnovations.com Tue Sep 18 11:37:04 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXf8K-0003Rh-Dn for megaco-archive@lists.ietf.org; Tue, 18 Sep 2007 11:37:04 -0400 Received: from [78.101.239.3] (helo=hthosx) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IXf8D-0002CF-BJ for megaco-archive@lists.ietf.org; Tue, 18 Sep 2007 11:36:59 -0400 Received: (qmail 4787 invoked from network); Tue, 18 Sep 2007 19:36:42 +0400 Received: from unknown (HELO ngqw) (223.57.69.180) by hthosx with SMTP; Tue, 18 Sep 2007 19:36:42 +0400 Message-ID: <46EFF08A.8050402@filterinnovations.com> Date: Tue, 18 Sep 2007 19:36:42 +0400 From: User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: megaco-archive@lists.ietf.org Subject: Check this out Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 3.3 (+++) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 Click here to get over 1000 games for free http://85.101.148.25/ From tara-Ryan@lichfieldcathedralschool.com Tue Sep 18 19:29:55 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXmVv-0002rF-U3 for megaco-archive@lists.ietf.org; Tue, 18 Sep 2007 19:29:55 -0400 Received: from [88.229.193.176] (helo=dsl88-229-57646.ttnet.net.tr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXmVl-0007Nj-Ec for megaco-archive@lists.ietf.org; Tue, 18 Sep 2007 19:29:51 -0400 Received: from Yuksel by lichfieldcathedralschool.com with ASMTP id D32C8D3B for ; Wed, 19 Sep 2007 02:30:04 +0300 Received: from Yuksel ([179.181.87.24]) by lichfieldcathedralschool.com with ESMTP id D44D653DEAA3 for ; Wed, 19 Sep 2007 02:30:04 +0300 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 19 Sep 2007 02:29:51 +0300 To: megaco-archive@lists.ietf.org From: "tara Ryan" Subject: livsnnum Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 1.6 (+) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Good day megaco-archive I went from being mr little too mr big boy within 6 months. tara Ryan http://www.cqkewalk.com/ From Monte-Hellmich@aidingroup.com Wed Sep 19 08:23:34 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXyac-0006OP-JF for megaco-archive@lists.ietf.org; Wed, 19 Sep 2007 08:23:34 -0400 Received: from p5b16f553.dip.t-dialin.net ([91.22.245.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXyab-00007O-7U for megaco-archive@lists.ietf.org; Wed, 19 Sep 2007 08:23:34 -0400 Received: from mb-83i9nz7fvxp4 ([170.137.147.79] helo=mb-83i9nz7fvxp4) by p5B16F553.dip.t-dialin.net ( sendmail 8.13.3/8.13.1) with esmtpa id 1LSydM-000IMH-CD for megaco-archive@lists.ietf.org; Wed, 19 Sep 2007 14:24:50 +0200 Message-ID: <87A933F5.2A34BAD7@aidingroup.com> Date: Wed, 19 Sep 2007 14:24:28 +0200 From: "Monte Hellmich" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: megaco-archive@lists.ietf.org Subject: tjidtjag Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.1 (++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea compliments megaco-archive Want a really big cock? Monte Hellmich http://menchts.net/ From KeithmagnanimitySanchez@biologyinmotion.com Wed Sep 19 09:18:49 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXzS5-0003uq-ED for megaco-archive@lists.ietf.org; Wed, 19 Sep 2007 09:18:49 -0400 Received: from [218.190.183.47] (helo=your11yccq18ks.hgcbroadband.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IXzRw-0001QG-W1 for megaco-archive@lists.ietf.org; Wed, 19 Sep 2007 09:18:47 -0400 Message-ID: From: "Harold Bailey" To: Subject: Fwd: Thanks, we are ready to give a business loan Date: Wed, 19 Sep 2007 21:16:48 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_B266_01C7FABF.9B028680" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.2663 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757 X-Spam-Score: 3.4 (+++) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 This is a multi-part message in MIME format. ------=_NextPart_000_B266_01C7FABF.9B028680 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Your credit score does not matter to us! If you have your own business and wish IMMEDIATE cash to spend ANY way = you like or require Extra money to give your company a boost or need A = low interest loan - NO STRINGS ATTACHED, here is best deal we can offer = you NOW (hurry, this tender will expire TONIGHT): $55,000+ loan Hurry, when best deal is gone, it is gone. Simply Call Us... Don't worry about approval, your credit will not disqualify you! Call Us Free on 877-482-4954 ------=_NextPart_000_B266_01C7FABF.9B028680 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20
Your credit score does not matter = to=20 us!
=20
 
If you have your own business and = wish IMMEDIATE=20 cash to spend ANY way you like or require Extra money to give your = company a=20 boost or need A low interest loan - NO STRINGS ATTACHED, here is best = deal we=20 can offer you NOW (hurry, this tender will expire TONIGHT):
= =20
 
$55,000+ loan
 
Hurry, when best deal is gone, it = is gone.=20 Simply Call Us...
=20
 
Don't worry about approval, your = credit will not=20 disqualify you!
=20
 
Call Us Free on = 877-482-4954
------=_NextPart_000_B266_01C7FABF.9B028680-- From w.gootee@summerporridge.com Wed Sep 19 09:20:19 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXzTX-0005fV-Gv for megaco-archive@lists.ietf.org; Wed, 19 Sep 2007 09:20:19 -0400 Received: from dynamic-89-189-151-124.igs.ufanet.ru ([89.189.151.124]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IXzTK-0001SX-Cd for megaco-archive@lists.ietf.org; Wed, 19 Sep 2007 09:20:13 -0400 Received: (qmail 16852 invoked from network); Wed, 19 Sep 2007 19:19:42 +0600 Received: from unknown (HELO icx) (173.105.186.71) by dynamic-89-189-151-124.igs.ufanet.ru with SMTP; Wed, 19 Sep 2007 19:19:42 +0600 Message-ID: <46F121EE.5000500@summerporridge.com> Date: Wed, 19 Sep 2007 19:19:42 +0600 From: User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: megaco-archive@lists.ietf.org Subject: We have what you need Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 3.5 (+++) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 Get all your pharmaceuticals for wholesale prices http://wokfe.meetsmell.cn/?351530961496 From Sylvie363@ucs-egypt.com Wed Sep 19 11:46:08 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY1ke-0002zR-GZ for megaco-archive@lists.ietf.org; Wed, 19 Sep 2007 11:46:08 -0400 Received: from f049140198.adsl.alicedsl.de ([78.49.140.198]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IY1ka-0003x2-NS for megaco-archive@lists.ietf.org; Wed, 19 Sep 2007 11:46:05 -0400 Received: from W2KINST by ucs-egypt.com with ASMTP id 20A1DE37 for ; Wed, 19 Sep 2007 17:46:41 +0200 Received: from W2KINST ([176.104.49.16]) by ucs-egypt.com with ESMTP id 4C8E2E5263E0 for ; Wed, 19 Sep 2007 17:46:41 +0200 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 19 Sep 2007 17:46:29 +0200 To: megaco-archive@lists.ietf.org From: "Sylvie crawford" Subject: rhtneerg Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 2.0 (++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Compliments megaco-archive Girls actually use to laugh at me! Sylvie crawford http://menchts.net/ From megaco-bounces@ietf.org Wed Sep 19 16:17:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY5y7-00024C-2c; Wed, 19 Sep 2007 16:16:19 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY5y5-0001xs-Nx for megaco@ietf.org; Wed, 19 Sep 2007 16:16:17 -0400 Received: from exchange.txpcorporation.com ([207.71.49.220]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IY5y1-0004XS-1h for megaco@ietf.org; Wed, 19 Sep 2007 16:16:13 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 19 Sep 2007 15:16:11 -0500 Message-ID: In-Reply-To: <34B3EAA5B3066A42914D28C5ECF5FEA41165F6B5@zrtphxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Digitmap syntax thread-index: Acf5YwUBJYppXsQ+ToCbiLxoFhCH4gABCVrgAGRvwjA= References: <46EED647.3070408@redback.com> <34B3EAA5B3066A42914D28C5ECF5FEA41165F6B5@zrtphxm2.corp.nortel.com> From: "John Wainwright" To: "Megaco List" X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [Megaco] Digitmap syntax X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: megaco-bounces@ietf.org Can anyone provide an interpretation of the following digitmap setup "9xxx | [0-9].L" If a user dials 9123 is a match reported immediately as per "9xxx" or does the "[0-9].L" part force the long timer to be used before reporting the number? Does the "L" act as a qualifier for all digits that preceded it or is it invalid after the "." =20 If it qualifies all digits then the setup shown above will use the Long timer for all numbers dialed won't it? Thanks John _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From yan63montgomery00@aidco.ir Wed Sep 19 17:33:59 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY7BH-0007Hb-8u for megaco-archive@lists.ietf.org; Wed, 19 Sep 2007 17:33:59 -0400 Received: from c144-42.icpnet.pl ([85.221.144.42]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IY7B7-0007Wq-4t for megaco-archive@lists.ietf.org; Wed, 19 Sep 2007 17:33:56 -0400 Received: from [85.221.144.42] by ppuq.aidco.ir; Wed, 19 Sep 2007 21:33:24 +0000 Message-ID: <000a01c7fb04$04eaca09$e00f2d99@knywv> From: "Leigh Gorman" To: "Emmett Corley" Subject: Re: Thank you for your loan request, we are ready to lend some cash regardless of Credit Date: Wed, 19 Sep 2007 19:46:01 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C7FB04.04E61399" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.2663 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757 X-Spam-Score: 2.2 (++) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C7FB04.04E61399 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Credit score doesn't matter to us! If you OWN property and want IMMEDIATE pin money to spend ANY way you = like, or simply wish to LOWER your current payments by a third or more, = here is best deal we can offer you THIS NIGHT (hurry, this offer will = expire TODAY: $328,000+ loan AND EVEN MORE: After further review, our lenders have established the = lowest payments! Hurry, when our deal is gone, it is gone. Simply fill this simplified = form...=20 Do not worry about approval, your Credit will not disqualify you! http://funhealthok.com/ ------=_NextPart_000_0007_01C7FB04.04E61399 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Credit score doesn't = matter to us!

If you OWN property and = want IMMEDIATE pin money to spend ANY way you like, or simply wish to = LOWER your current payments by a third or more, here is best deal we can = offer you THIS NIGHT (hurry, this offer will expire = TODAY:

$328,000+ = loan

AND EVEN MORE: After = further review, our lenders have established the lowest = payments!

Hurry, when our deal is = gone, it is gone. Simply fill this simplified form... =

Do not worry about = approval, your Credit will not disqualify you!


------=_NextPart_000_0007_01C7FB04.04E61399-- From megaco-bounces@ietf.org Thu Sep 20 01:20:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYER0-00089v-6e; Thu, 20 Sep 2007 01:18:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYEQz-00083E-6u for megaco@ietf.org; Thu, 20 Sep 2007 01:18:41 -0400 Received: from [219.140.167.45] (helo=mail.zgwri.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IYEQo-0001cs-AD for megaco@ietf.org; Thu, 20 Sep 2007 01:18:37 -0400 Content-class: urn:content-classes:message Subject: Re: [Megaco] Digitmap syntax MIME-Version: 1.0 Date: Thu, 20 Sep 2007 13:17:27 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <7F8C277E2EFB93419D38AACD4F77CCDF108E79@mail.zgwri.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Megaco] Digitmap syntax Thread-Index: Acf5YwUBJYppXsQ+ToCbiLxoFhCH4gABCVrgAGRvwjAAEyfghA== References: <46EED647.3070408@redback.com><34B3EAA5B3066A42914D28C5ECF5FEA41165F6B5@zrtphxm2.corp.nortel.com> From: =?gb2312?B?zfXV8dDL?= To: "John Wainwright" , "Megaco List" X-Spam-Score: 2.5 (++) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1217527611==" Errors-To: megaco-bounces@ietf.org This is a multi-part message in MIME format. --===============1217527611== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7FB45.9DCDEFD1" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7FB45.9DCDEFD1 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable I think "9xxx|[0-9].L" means = "9xxx|[0-9]L|[0-9][0-9]L|[0-9][0-9][0-9]L|=A1=AD=A1=AD",so 9123 also can = match "[0-9][0-9][0-9][0-9]L",and still have a chance to match = "[0-9][0-9][0-9][0-9][0-9]L". "9123" is not a UM for this digitmap , MG = must start a long timer(because the "L")for waiting next dail number. ________________________________ From: John Wainwright [mailto:john.wainwright@txpcorporation.com] Sent: 2007-9-20 (=D0=C7=C6=DA=CB=C4) 4:16 To: Megaco List Subject: [Megaco] Digitmap syntax Can anyone provide an interpretation of the following digitmap setup "9xxx | [0-9].L" If a user dials 9123 is a match reported immediately as per "9xxx" or does the "[0-9].L" part force the long timer to be used before reporting the number? Does the "L" act as a qualifier for all digits that preceded it or is it invalid after the "."=20 If it qualifies all digits then the setup shown above will use the Long timer for all numbers dialed won't it? Thanks John _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco ------_=_NextPart_001_01C7FB45.9DCDEFD1 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable [Megaco] Digitmap syntax=0A= =0A= =0A= =0A=
=0A=
    I think "9xxx|[0-9].L" means = "9xxx|[0-9]L|[0-9][0-9]L|[0-9][0-9][0-9]L|=A1=AD=A1=AD",so 9123 also can = match "[0-9][0-9][0-9][0-9]L",and still have a chance to match = "[0-9][0-9][0-9][0-9][0-9]L". "9123" is not a UM for this = digitmap , MG must start a long timer(because the "L")for = waiting next dail number.
=0A=

=0A=
=0A= From: John Wainwright = [mailto:john.wainwright@txpcorporation.com]
Sent: 2007-9-20 = (=D0=C7=C6=DA=CB=C4) 4:16
To: Megaco List
Subject: = [Megaco] Digitmap syntax

=0A=
=0A=

Can anyone provide an interpretation of the following = digitmap setup
        "9xxx | = [0-9].L"

If a user dials 9123 is a match reported immediately as = per "9xxx" or
does the "[0-9].L" part force the long timer to be used = before reporting
the number?

Does the "L" act as a qualifier = for all digits that preceded it or is it
invalid after the = "." 
If it qualifies all digits then the setup shown above will = use the Long
timer for all numbers dialed won't = it?

Thanks
John


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

------_=_NextPart_001_01C7FB45.9DCDEFD1-- --===============1217527611== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============1217527611==-- From ashishkumar.jain@sherisranch.com Thu Sep 20 07:41:54 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYKPq-0006ty-7m for megaco-archive@lists.ietf.org; Thu, 20 Sep 2007 07:41:54 -0400 Received: from [82.201.221.9] (helo=host-82-201-221-9.static.link.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IYKPl-0002Ja-ET for megaco-archive@lists.ietf.org; Thu, 20 Sep 2007 07:41:51 -0400 Received: from atycp ([36.199.198.142]) by host-82-201-221-9.static.link.net (8.13.2/8.13.2) with SMTP id l8KBisCX050872; Thu, 20 Sep 2007 14:44:54 +0300 Message-ID: <000501c7fb7b$2c7039d0$8ec6c724@atycp> From: To: Subject: Finally, something truly free on the net Date: Thu, 20 Sep 2007 14:41:24 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Spam-Score: 3.5 (+++) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 1000 free online games at your fingertips. http://84.226.130.244/ From RobbycepheusOchoa@significant.be Thu Sep 20 08:01:37 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYKiv-00020L-9f for megaco-archive@lists.ietf.org; Thu, 20 Sep 2007 08:01:37 -0400 Received: from catv-5985a172.catv.broadband.hu ([89.133.161.114] helo=n9m3o7.chello.hu) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IYKip-0004MF-F4 for megaco-archive@lists.ietf.org; Thu, 20 Sep 2007 08:01:31 -0400 Message-ID: <102ff01c7fb7d$f9dcf640$72a18559@n9m3o7> From: "Zachery Shepard" To: Subject: Fw: Thanks, we accepted your company business loan request Date: Thu, 20 Sep 2007 13:59:24 -0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_102FB_01C7FB7D.F9DCF640" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 4.8 (++++) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da This is a multi-part message in MIME format. ------=_NextPart_000_102FB_01C7FB7D.F9DCF640 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Your credit score does not matter to us! If you have your own business and need IMMEDIATE ready money to spend = ANY way you like or need Extra money to give the company a boost or need = A low interest loan - NO STRINGS ATTACHED, here is best deal we can = offer you NOW (hurry, this deal will expire THIS EVENING): $39,000+ loan Hurry, when our deal is gone, it is gone. Simply Call Us... Don't worry about approval, your your credit report will not disqualify = you! Call Us Free on 877-292-6891 ------=_NextPart_000_102FB_01C7FB7D.F9DCF640 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20
Your credit score does not matter = to=20 us!
=20
 
If you have your own business and = need IMMEDIATE=20 ready money to spend ANY way you like or need Extra money to give the = company a=20 boost or need A low interest loan - NO STRINGS ATTACHED, here is best = deal we=20 can offer you NOW (hurry, this deal will expire THIS = EVENING):
=20
 
$39,000+ loan
 
Hurry, when our deal is gone, it = is gone.=20 Simply Call Us...
=20
 
Don't worry about approval, your your = credit=20 report will not disqualify you!
=20
 
Call Us Free on = 877-292-6891
------=_NextPart_000_102FB_01C7FB7D.F9DCF640-- From glenn459@steresphd.com Thu Sep 20 14:13:37 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYQWv-00081W-6W for megaco-archive@lists.ietf.org; Thu, 20 Sep 2007 14:13:37 -0400 Received: from 20151210188.user.veloxzone.com.br ([201.51.210.188]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IYQWu-0007br-E2 for megaco-archive@lists.ietf.org; Thu, 20 Sep 2007 14:13:36 -0400 Received: by 10.218.41.225 with SMTP id IfmIFGvUdAXlg; Thu, 20 Sep 2007 15:08:25 -0300 (GMT) Received: by 192.168.137.111 with SMTP id ofiFfnmlaYEoHe.9067855518375; Thu, 20 Sep 2007 15:08:23 -0300 (GMT) Message-ID: <000c01c7fbb1$3a2820c0$bcd233c9@RVG03> From: "glenn hopps" To: Subject: nelakida Date: Thu, 20 Sep 2007 15:08:20 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C7FB98.14DAE8C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 2.0 (++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0009_01C7FB98.14DAE8C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://www.anmanac.com/ Yo yo yo megaco-archive With M.anster you can look forward to the good times sexually. glenn hopps ------=_NextPart_000_0009_01C7FB98.14DAE8C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://www.anmanac.com/
Yo yo yo megaco-archive
With M.anster you can look forward to the good = times sexually.
glenn hopps
------=_NextPart_000_0009_01C7FB98.14DAE8C0-- From TheresefrictionDahl@trimble.com Thu Sep 20 15:45:53 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYRyD-0000HU-Bl for megaco-archive@lists.ietf.org; Thu, 20 Sep 2007 15:45:53 -0400 Received: from [190.40.69.231] (helo=casa1) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IYRy7-0000AB-3o for megaco-archive@lists.ietf.org; Thu, 20 Sep 2007 15:45:48 -0400 Message-ID: <159201c7fbbe$d0a60e10$0a000a0a@Casa1> From: "Goldie Sumner" To: Subject: Re: Thanks, we are accepting your company business loan request Date: Thu, 20 Sep 2007 13:38:58 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_158E_01C7FBBE.D0A60E10" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 4.2 (++++) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 This is a multi-part message in MIME format. ------=_NextPart_000_158E_01C7FBBE.D0A60E10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Your credit score doesn't matter to us! If you have your own business and want IMMEDIATE cash to spend ANY way = you like or need Extra money to give the business a boost or need A low = interest loan - NO STRINGS ATTACHED, here is our deal we can offer you = TONIGHT (hurry, this offer will expire THIS EVENING): $29,000+ loan Hurry, when the deal is gone, it is gone. Simply Call Us... Don't worry about approval, your credit history will not disqualify you! Call Us Free on 877-292-6891 ------=_NextPart_000_158E_01C7FBBE.D0A60E10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20
Your credit score doesn't matter = to=20 us!
=20
 
If you have your own business and want = IMMEDIATE=20 cash to spend ANY way you like or need Extra money to give the business = a boost=20 or need A low interest loan - NO STRINGS ATTACHED, here is our deal we = can=20 offer you TONIGHT (hurry, this offer will expire THIS = EVENING):
=20
 
$29,000+ loan
 
Hurry, when the deal is gone, it is = gone.=20 Simply Call Us...
=20
 
Don't worry about approval, your credit = history=20 will not disqualify you!
=20
 
Call Us Free on = 877-292-6891
------=_NextPart_000_158E_01C7FBBE.D0A60E10-- From Lindsey_ran@julyservices.com Thu Sep 20 16:02:14 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYSE2-0008JU-Jo for megaco-archive@lists.ietf.org; Thu, 20 Sep 2007 16:02:14 -0400 Received: from 186-mi2-4.acn.waw.pl ([82.210.191.186]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IYSDu-0002u5-M4 for megaco-archive@lists.ietf.org; Thu, 20 Sep 2007 16:02:07 -0400 Received: by 10.186.59.115 with SMTP id tjAwgvJzaKkFK; Thu, 20 Sep 2007 22:03:05 +0200 (GMT) Received: by 192.168.4.44 with SMTP id KWnihZOAnycccV.3371912537744; Thu, 20 Sep 2007 22:03:03 +0200 (GMT) Message-ID: <000601c7fbc1$3ecf2050$babfd252@krah> From: "Lindsey ran" To: Subject: setiudne Date: Thu, 20 Sep 2007 22:03:00 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C7FBD2.0257F050" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 2.0 (++) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 ------=_NextPart_000_0008_01C7FBD2.0257F050 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable http://www.anurizum.com/ Regards megaco-archive A MASSIVE schlong, is only a few months away Lindsey ran ------=_NextPart_000_0008_01C7FBD2.0257F050 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable
http://www.anurizum.com/
Regards megaco-archive
A MASSIVE schlong, is only a few months = away
Lindsey ran
------=_NextPart_000_0008_01C7FBD2.0257F050-- From maxim@electronicandapplianceworld.com Thu Sep 20 18:26:05 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYUTF-0003P6-7g for megaco-archive@lists.ietf.org; Thu, 20 Sep 2007 18:26:05 -0400 Received: from 19.pool85-50-150.dynamic.orange.es ([85.50.150.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IYUT6-0003yU-Qd for megaco-archive@lists.ietf.org; Thu, 20 Sep 2007 18:26:03 -0400 Received: from homeland ([165.141.194.126]:21231 "EHLO homeland" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by 79.pool85-50-203.dynamic.orange.es with ESMTP id S22KFZIPZJSNOWUB (ORCPT ); Fri, 21 Sep 2007 00:25:54 +0200 Message-ID: <000b01c7fbd5$204f6b30$4fcb3255@homeland> From: "maxim Caron" To: Subject: namtogni Date: Fri, 21 Sep 2007 00:25:19 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C7FBE5.E3D83B30" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 4.3 (++++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0009_01C7FBE5.E3D83B30 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://maxwaay.com/ hello megaco-archive now im 2 inch bigger in my manhood.. i have all the confidence. maxim Caron ------=_NextPart_000_0009_01C7FBE5.E3D83B30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://maxwaay.com/
hello megaco-archive
now im 2 inch bigger in my manhood.. i have = all the confidence.
maxim Caron
------=_NextPart_000_0009_01C7FBE5.E3D83B30-- From bhertter@trak-1.com Thu Sep 20 22:35:47 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYYMt-0000tE-0d for megaco-archive@lists.ietf.org; Thu, 20 Sep 2007 22:35:47 -0400 Received: from 64-42-23-92.atgi.net ([64.42.23.92]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IYYMi-0000qY-Jv for megaco-archive@lists.ietf.org; Thu, 20 Sep 2007 22:35:42 -0400 Received: from bzk ([143.51.147.188]) by 64-42-23-92.atgi.net with Microsoft SMTPSVC(6.0.3790.0); Thu, 20 Sep 2007 19:35:47 -0700 Message-ID: <46F32E03.1020701@trak-1.com> Date: Thu, 20 Sep 2007 19:35:47 -0700 From: User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: megaco-archive@lists.ietf.org Subject: Backdoor to free game site Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.1 (++) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 We now have over 1000 free games available online. http://74.140.177.241/ From karnuth@alarmfyn.dk Fri Sep 21 06:23:44 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYffk-0005ZO-B3 for megaco-archive@lists.ietf.org; Fri, 21 Sep 2007 06:23:44 -0400 Received: from host44-153-dynamic.9-79-r.retail.telecomitalia.it ([79.9.153.44] helo=host84-130-dynamic.13-79-r.retail.telecomitalia.it) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IYffh-0006Z0-5t for megaco-archive@lists.ietf.org; Fri, 21 Sep 2007 06:23:41 -0400 Received: from user-9a ([193.142.165.66] helo=user-9a) by host84-130-dynamic.13-79-r.retail.telecomitalia.it ( sendmail 8.13.3/8.13.1) with esmtpa id 1dBKDK-000PQB-bA for megaco-archive@lists.ietf.org; Fri, 21 Sep 2007 12:23:48 +0200 Message-ID: <000901c7fc39$749f4980$54820d4f@user9a> From: "Dang karnuth" To: Subject: coorses Date: Fri, 21 Sep 2007 12:23:30 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C7FC4A.38281980" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Antivirus: avast! (VPS 000775-4, 20/09/2007), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 0.1 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da ------=_NextPart_000_0005_01C7FC4A.38281980 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Rumor News: Oncology Med. Inc. (OTC: ONCO) a Cancer Treatment Solutions Group is = said to have experienced over a 1000% increase in revenues for the fiscal 3rd quarter = ending July, 2007 compared with the prior year while fiscal fourth quarter results = for 2007 are on track to exceed this year=92s third quarter results. ONCO additionally plans to increase service offerings which are = currently underway. Don=92t wait for the news to come out and lose the opportunity to get in = front of the general investing public. Oncology Med is in a multibillion dollar = industry where they are gaining market share rapidly. Call your broker now for ONCO. ------=_NextPart_000_0005_01C7FC4A.38281980 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Rumor News:
Oncology Med. Inc. (OTC: ONCO) a Cancer = Treatment=20 Solutions Group is said to have
experienced over a 1000% increase in revenues = for the=20 fiscal 3rd quarter ending July,
2007 compared with the prior year while fiscal = fourth=20 quarter results for 2007 are on
track to exceed this year=92s third quarter = results.
ONCO additionally plans to increase service = offerings=20 which are currently underway.
Don=92t wait for the news to come out and lose = the=20 opportunity to get in front of the
general investing public. Oncology Med is in = a=20 multibillion dollar industry where
they are gaining market share = rapidly.
Call your broker now for = ONCO.
------=_NextPart_000_0005_01C7FC4A.38281980-- From Kirkhamxazvu@santoivo.com.br Fri Sep 21 06:47:50 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYg33-0000IP-TM for megaco-archive@lists.ietf.org; Fri, 21 Sep 2007 06:47:50 -0400 Received: from host144-196-static.104-82-b.business.telecomitalia.it ([82.104.196.144]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IYg2x-0007HE-RE for megaco-archive@lists.ietf.org; Fri, 21 Sep 2007 06:47:44 -0400 Received: from M7X6Y8 ([190.100.154.186] helo=M7X6Y8) by host144-196-static.104-82-b.business.telecomitalia.it ( sendmail 8.13.3/8.13.1) with esmtpa id 1TyykJ-000FPI-Ql for megaco-archive@lists.ietf.org; Fri, 21 Sep 2007 12:48:59 +0200 Message-ID: <000901c7fc3c$ef8b2760$90c46852@M7X6Y8> From: "Elfinn Kirkham" To: Subject: alldatum Date: Fri, 21 Sep 2007 12:48:25 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C7FC4D.B313F760" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 2.9 (++) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da ------=_NextPart_000_0009_01C7FC4D.B313F760 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Rumor News: Oncology Med. Inc. (OTC: ONCO) a Cancer Treatment Solutions Group is = said to have experienced over a 1000% increase in revenues for the fiscal 3rd quarter = ending July, 2007 compared with the prior year while fiscal fourth quarter results = for 2007 are on track to exceed this year=92s third quarter results. ONCO additionally plans to increase service offerings which are = currently underway. Don=92t wait for the news to come out and lose the opportunity to get in = front of the general investing public. Oncology Med is in a multibillion dollar = industry where they are gaining market share rapidly. Call your broker now for ONCO. ------=_NextPart_000_0009_01C7FC4D.B313F760 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Rumor News:
Oncology Med. Inc. (OTC: ONCO) a Cancer = Treatment=20 Solutions Group is said to have
experienced over a 1000% increase in revenues = for the=20 fiscal 3rd quarter ending July,
2007 compared with the prior year while fiscal = fourth=20 quarter results for 2007 are on
track to exceed this year=92s third quarter = results.
ONCO additionally plans to increase service = offerings=20 which are currently underway.
Don=92t wait for the news to come out and lose = the=20 opportunity to get in front of the
general investing public. Oncology Med is in = a=20 multibillion dollar industry where
they are gaining market share = rapidly.
Call your broker now for = ONCO.
------=_NextPart_000_0009_01C7FC4D.B313F760-- From mvelcr@hydro.mb.ca Sat Sep 22 06:51:38 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZ2aI-0005o0-6V for megaco-archive@lists.ietf.org; Sat, 22 Sep 2007 06:51:38 -0400 Received: from [62.64.75.246] (helo=ll-246.132.162.89.kv.sovam.net.ua) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IZ2aB-0002mn-Ni for megaco-archive@lists.ietf.org; Sat, 22 Sep 2007 06:51:33 -0400 Received: (qmail 23903 invoked from network); Sat, 22 Sep 2007 13:51:21 +0300 Received: from unknown (HELO nja) (221.168.65.228) by ll-246.132.162.89.kv.sovam.net.ua with SMTP; Sat, 22 Sep 2007 13:51:21 +0300 Message-ID: <001d01c7fd06$830f7d50$e441a8dd@nja> From: To: Subject: Tons of free games Date: Sat, 22 Sep 2007 13:51:21 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="windows-1250"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 3.0 (+++) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 All the games you could ever want...FREE http://71.207.10.151/ From Nedim558@altheagodfrey.com Sat Sep 22 07:37:38 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZ3Io-0007mD-M9 for megaco-archive@lists.ietf.org; Sat, 22 Sep 2007 07:37:38 -0400 Received: from [151.67.22.125] (helo=[151.67.17.32]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZ3Ii-0000wy-Sj for megaco-archive@lists.ietf.org; Sat, 22 Sep 2007 07:37:33 -0400 Received: from user-l4aal0dhb0 ([175.129.67.3] helo=user-l4aal0dhb0) by [151.67.17.32] ( sendmail 8.13.3/8.13.1) with esmtpa id 1AfWji-000KOU-iX for megaco-archive@lists.ietf.org; Sat, 22 Sep 2007 13:37:56 +0200 Message-ID: <000401c7fd0c$f3e5d870$20114397@userl4aal0dhb0> From: "Nedim Blumenthal" To: Subject: tytetise Date: Sat, 22 Sep 2007 13:37:27 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C7FD1D.B76EA870" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 2.1 (++) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 ------=_NextPart_000_0004_01C7FD1D.B76EA870 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://www.moblione.com/ Good day megaco-archive imagine the look on your wifes face when she sees the new you Nedim Blumenthal ------=_NextPart_000_0004_01C7FD1D.B76EA870 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://www.moblione.com/
Good day megaco-archive
imagine the look on your wifes face when she = sees the=20 new you
Nedim Blumenthal
------=_NextPart_000_0004_01C7FD1D.B76EA870-- From Vishari@specialdoctor.co.kr Sat Sep 22 12:26:58 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZ7oo-0006RK-BN for megaco-archive@lists.ietf.org; Sat, 22 Sep 2007 12:26:58 -0400 Received: from [189.4.197.43] (helo=bd04c52b.virtua.com.br) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZ7oe-0007g2-Nd for megaco-archive@lists.ietf.org; Sat, 22 Sep 2007 12:26:49 -0400 Received: by 10.147.168.217 with SMTP id TaCBJKgLHyaap; Sat, 22 Sep 2007 13:22:26 -0300 (GMT) Received: by 192.168.47.133 with SMTP id rzmrVQNnbqzRQP.1579311312349; Sat, 22 Sep 2007 13:22:24 -0300 (GMT) Message-ID: <000a01c7fd34$c05c9c50$2bc504bd@suporte0036> From: "Vishari Kabell" To: Subject: orchard1 Date: Sat, 22 Sep 2007 13:22:21 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C7FD1B.9B0F6450" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 3.9 (+++) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 ------=_NextPart_000_0008_01C7FD1B.9B0F6450 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://moifone.com/ Greeting megaco-archive Ladies, here is the ultimate gift for your men, used by p0rnstarrs = worldwide Vishari Kabell ------=_NextPart_000_0008_01C7FD1B.9B0F6450 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://moifone.com/
Greeting megaco-archive
Ladies, here is the ultimate gift for your = men, used by=20 p0rnstarrs worldwide
Vishari Kabell
------=_NextPart_000_0008_01C7FD1B.9B0F6450-- From Kalbfleischahryv@energi-teknikk.no Sat Sep 22 13:45:27 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZ92l-0007kq-EF for megaco-archive@lists.ietf.org; Sat, 22 Sep 2007 13:45:27 -0400 Received: from [41.207.16.131] (helo=[213.136.117.169]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZ92k-00018C-DC for megaco-archive@lists.ietf.org; Sat, 22 Sep 2007 13:45:27 -0400 Received: by 10.120.136.105 with SMTP id NvtDbVjEddDAp; Sun, 23 Sep 2007 05:46:22 +0200 (GMT) Received: by 192.168.15.234 with SMTP id VmmXVAHaWqGIww.1444497426532; Sun, 23 Sep 2007 05:46:20 +0200 (GMT) Message-ID: <000501c7fd94$4bbd9010$a97588d5@poste11> From: "lorenzo Kalbfleisch" To: Subject: ggerg Date: Sun, 23 Sep 2007 05:46:17 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C7FDA5.0F466010" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 2.1 (++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0007_01C7FDA5.0F466010 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://www.moifone.com/ hello megaco-archive 1 inch, 2 inch, 3 inch, its upto you how big you want to go lorenzo Kalbfleisch ------=_NextPart_000_0007_01C7FDA5.0F466010 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://www.moifone.com/
hello megaco-archive
1 inch, 2 inch, 3 inch, its upto you how big = you want to go
lorenzo Kalbfleisch
------=_NextPart_000_0007_01C7FDA5.0F466010-- From Pare@torontoleafs.com Sun Sep 23 08:29:17 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZQaL-0004kB-QU for megaco-archive@lists.ietf.org; Sun, 23 Sep 2007 08:29:17 -0400 Received: from e176019055.adsl.alicedsl.de ([85.176.19.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IZQaK-0006FI-Bp for megaco-archive@lists.ietf.org; Sun, 23 Sep 2007 08:29:17 -0400 Received: by 10.29.163.4 with SMTP id pUxpISHXoCKgk; Sun, 23 Sep 2007 14:29:17 +0200 (GMT) Received: by 192.168.70.38 with SMTP id HOfbEKwqxpCbDA.9120338523769; Sun, 23 Sep 2007 14:29:15 +0200 (GMT) Message-ID: <000701c7fddd$58bfc0f0$3713b055@butze> From: "pardeep Pare" To: Subject: sassandr Date: Sun, 23 Sep 2007 14:29:12 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C7FDEE.1C4890F0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 2.1 (++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0003_01C7FDEE.1C4890F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://gtartner.com/ Hi megaco-archive get a BIG schlong, check this website out. pardeep Pare ------=_NextPart_000_0003_01C7FDEE.1C4890F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://gtartner.com/
Hi megaco-archive
get a BIG schlong, check this website = out.
pardeep Pare
------=_NextPart_000_0003_01C7FDEE.1C4890F0-- From Hom.Romppainen@19-c.com Sun Sep 23 13:27:07 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZVEZ-00019n-Qw for megaco-archive@lists.ietf.org; Sun, 23 Sep 2007 13:27:07 -0400 Received: from host236-5-dynamic.14-87-r.retail.telecomitalia.it ([87.14.5.236] helo=host39-91-dynamic.13-87-r.retail.telecomitalia.it) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZVET-0005BJ-0n for megaco-archive@lists.ietf.org; Sun, 23 Sep 2007 13:27:01 -0400 Received: from diego-q0wllp5tk ([102.165.47.137] helo=diego-q0wllp5tk) by host39-91-dynamic.13-87-r.retail.telecomitalia.it ( sendmail 8.13.3/8.13.1) with esmtpa id 1HPnMh-000XCL-UU for megaco-archive@lists.ietf.org; Sun, 23 Sep 2007 19:27:47 +0200 Message-ID: <000901c7fe06$fb7890f0$275b0d57@diegoq0wllp5tk> From: "Hom Romppainen" To: Subject: redremme Date: Sun, 23 Sep 2007 19:27:14 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C7FE17.BF0160F0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 3.7 (+++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0007_01C7FE17.BF0160F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://greycp.com/ regards megaco-archive Bigger schlong =3D more enjoyment for partner! Hom Romppainen ------=_NextPart_000_0007_01C7FE17.BF0160F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://greycp.com/
regards megaco-archive
Bigger schlong =3D more enjoyment for = partner!
Hom Romppainen
------=_NextPart_000_0007_01C7FE17.BF0160F0-- From candini@santarita-esr.com.ar Sun Sep 23 14:38:11 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZWLL-0003ah-3g for megaco-archive@lists.ietf.org; Sun, 23 Sep 2007 14:38:11 -0400 Received: from gom114.internetdsl.tpnet.pl ([83.3.116.114]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IZWL9-0006ui-Ix for megaco-archive@lists.ietf.org; Sun, 23 Sep 2007 14:38:06 -0400 Received: from nigga by santarita-esr.com.ar with ASMTP id 315C9D22 for ; Sun, 23 Sep 2007 20:38:30 +0200 Received: from nigga ([158.195.135.52]) by santarita-esr.com.ar with ESMTP id 2EF136B0B964 for ; Sun, 23 Sep 2007 20:38:30 +0200 Date: Sun, 23 Sep 2007 20:38:12 +0200 From: "candini Egenby" Reply-To: "candini Egenby" Message-ID: <918338558562.391289738344@santarita-esr.com.ar> To: Subject: sorgente MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-2"; reply-type=original X-Spam-Score: 3.9 (+++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Greeting megaco-archive This product is soooooooooo amazing.. get it today candini Egenby http://greyu.com/ From thaothanh82@menge.smith.is-a-geek.com Sun Sep 23 20:09:26 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZbVu-00012V-9Q for megaco-archive@lists.ietf.org; Sun, 23 Sep 2007 20:09:26 -0400 Received: from [69.15.109.97] (helo=qnoisj) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IZbVo-0006HK-5P for megaco-archive@lists.ietf.org; Sun, 23 Sep 2007 20:09:21 -0400 Received: (qmail 23892 invoked from network); Sun, 23 Sep 2007 20:05:55 -0400 Received: from unknown (HELO xoep) (77.89.53.112) by qnoisj with SMTP; Sun, 23 Sep 2007 20:05:55 -0400 Message-ID: <46F6FF63.8080302@menge.smith.is-a-geek.com> Date: Sun, 23 Sep 2007 20:05:55 -0400 From: User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: megaco-archive@lists.ietf.org Subject: News Alert Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Watch Out For Big News Monday SCORE ONE INC (S R E A) Current: $0.10 This one rockets every time it has big news. Get on SREA before news hits the street on Monday. From Liptontqowp@kurtnoble.com Mon Sep 24 01:19:35 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZgM3-0006S8-Bq for megaco-archive@lists.ietf.org; Mon, 24 Sep 2007 01:19:35 -0400 Received: from [24.32.117.4] (helo=doc-24-32-117-4.clksvl.tx.cebridge.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IZgLz-0003sk-OB for megaco-archive@lists.ietf.org; Mon, 24 Sep 2007 01:19:33 -0400 Received: from LR by kurtnoble.com with ASMTP id DC99F57F for ; Sun, 23 Nov 2003 23:21:45 -0600 Received: from LR ([132.182.175.171]) by kurtnoble.com with ESMTP id A318DD04F905 for ; Sun, 23 Nov 2003 23:21:45 -0600 Message-ID: <000e01c3b24a$d0074fd0$04752018@LR> From: "cha Lipton" To: Subject: koed Date: Sun, 23 Nov 2003 23:21:28 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C3B218.856CDFD0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 3.5 (+++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0005_01C3B218.856CDFD0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://www.sdmpo.com/ hello megaco-archive Get your supply today before prices sky rocket cha Lipton ------=_NextPart_000_0005_01C3B218.856CDFD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://www.sdmpo.com/
hello megaco-archive
Get your supply today before prices sky = rocket
cha Lipton
------=_NextPart_000_0005_01C3B218.856CDFD0-- From dcollins@dlh.de Mon Sep 24 05:23:12 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZk9o-0004zJ-R9 for megaco-archive@lists.ietf.org; Mon, 24 Sep 2007 05:23:12 -0400 Received: from aqr93.neoplus.adsl.tpnet.pl ([83.26.177.93]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IZk9d-00013N-DD for megaco-archive@lists.ietf.org; Mon, 24 Sep 2007 05:23:07 -0400 Received: from crd ([189.40.54.224]) by aqr93.neoplus.adsl.tpnet.pl with Microsoft SMTPSVC(5.0.2195.5329); Mon, 24 Sep 2007 11:21:56 +0200 Message-ID: <46F781B4.2010203@dlh.de> Date: Mon, 24 Sep 2007 11:21:56 +0200 From: User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: megaco-archive@lists.ietf.org Subject: Market Close Pick List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.6 (+) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Watch Out For Big News Monday SCORE ONE (SREA . OB) Current: $0.10 Last big release caused a frenzy. Get on SREA before news hits the street on Monday. From deadyjp@serviceparts.nl Mon Sep 24 06:32:06 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZlEU-0002G4-7h for megaco-archive@lists.ietf.org; Mon, 24 Sep 2007 06:32:06 -0400 Received: from [85.223.177.2] (helo=enzim-gw.sovam.net.ua) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IZlES-0002oy-Nu for megaco-archive@lists.ietf.org; Mon, 24 Sep 2007 06:32:06 -0400 Received: by 10.127.144.26 with SMTP id DOmYMSYEpfBvZ; Mon, 24 Sep 2007 13:29:06 +0300 (GMT) Received: by 192.168.23.105 with SMTP id DnRJlQislCiemg.0596992768460; Mon, 24 Sep 2007 13:29:04 +0300 (GMT) Message-ID: Date: Mon, 24 Sep 2007 13:29:01 +0300 From: "Leonardo dead" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: megaco-archive@lists.ietf.org Subject: hellejak Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Hello megaco-archive You know you want a bigger cock, dont waste anymore time Leonardo dead http://www.siojn.com/ From Tarry@amoreliance.be Mon Sep 24 17:01:24 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZv3U-0006Zs-1o for megaco-archive@lists.ietf.org; Mon, 24 Sep 2007 17:01:24 -0400 Received: from bdp55.neoplus.adsl.tpnet.pl ([83.28.1.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZv3G-0007n5-Vr for megaco-archive@lists.ietf.org; Mon, 24 Sep 2007 17:01:11 -0400 Received: by 10.159.113.20 with SMTP id xjKouZUqRvLOE; Mon, 24 Sep 2007 23:01:25 +0200 (GMT) Received: by 192.168.215.117 with SMTP id knrPccuTQcFOpa.4649914923524; Mon, 24 Sep 2007 23:01:23 +0200 (GMT) Message-ID: <812D8793.B647EC00@amoreliance.be> Date: Mon, 24 Sep 2007 23:01:20 +0200 From: "Tarry renteria" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: megaco-archive@lists.ietf.org Subject: natsilop Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000776-0, 2007-09-24), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 3.6 (+++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Wazzup megaco-archive now im 2 inch bigger in my manhood.. i have all the confidence. Tarry renteria http://www.enbgrish.com/ From Alvaro743@amakom-online.de Mon Sep 24 17:26:53 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZvS9-00083e-2l for megaco-archive@lists.ietf.org; Mon, 24 Sep 2007 17:26:53 -0400 Received: from [151.71.201.226] (helo=[151.71.157.63]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZvS6-0008LX-Ix for megaco-archive@lists.ietf.org; Mon, 24 Sep 2007 17:26:52 -0400 Received: from nome-83e7fb8cdb ([175.193.29.69] helo=nome-83e7fb8cdb) by [151.71.157.63] ( sendmail 8.13.3/8.13.1) with esmtpa id 1YScLS-000IXH-CR for megaco-archive@lists.ietf.org; Mon, 24 Sep 2007 23:27:38 +0200 Message-ID: <000601c7fef1$ae448cd0$3f9d4797@nome83e7fb8cdb> From: "Alvaro gadou" To: Subject: iqueness Date: Mon, 24 Sep 2007 23:27:16 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C7FF02.71CD5CD0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 2.1 (++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0008_01C7FF02.71CD5CD0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://www.esbbanl.com/ Wassup megaco-archive Girls actually use to laugh at me! Alvaro gadou ------=_NextPart_000_0008_01C7FF02.71CD5CD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://www.esbbanl.com/
Wassup megaco-archive
Girls actually use to laugh at = me!
Alvaro gadou
------=_NextPart_000_0008_01C7FF02.71CD5CD0-- From CorineRenz@VitaCost.com Mon Sep 24 19:55:26 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZxlu-0001fn-K8 for megaco-archive@lists.ietf.org; Mon, 24 Sep 2007 19:55:26 -0400 Received: from 213-140-19-116.fastres.net ([213.140.19.116]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZxlp-0004Bg-Qs for megaco-archive@lists.ietf.org; Mon, 24 Sep 2007 19:55:22 -0400 Received: from xp-pro-sp1 by VitaCost.com with ASMTP id DF55F2AF for ; Tue, 25 Sep 2007 01:55:56 +0200 Received: from xp-pro-sp1 ([105.155.115.50]) by VitaCost.com with ESMTP id D29F6D0A493A for ; Tue, 25 Sep 2007 01:55:56 +0200 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 25 Sep 2007 01:55:37 +0200 To: megaco-archive@lists.ietf.org From: "Corine Renz" Subject: iuforot Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 4.1 (++++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Compliments megaco-archive You know you want a bigger cock, dont waste anymore time Corine Renz http://www.entradad.com/ From edscrt@pw.utc.com Tue Sep 25 02:29:19 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia3v5-0004Ax-SC for megaco-archive@lists.ietf.org; Tue, 25 Sep 2007 02:29:19 -0400 Received: from h83-174-242-146.dyn.ufamts.ru ([83.174.242.146]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ia3uv-0002Ak-BZ for megaco-archive@lists.ietf.org; Tue, 25 Sep 2007 02:29:15 -0400 X-AntiVirus: Checked by Dr.Web [version: 4.33, engine: 4.33.5.10110, virus records: 200085, updated: 14.05.2007] Received: from [198.195.75.109] (helo=yceal) by h83-174-242-146.dyn.ufamts.ru with smtp (Exim 4.62 (FreeBSD)) id 1Jk40d-0004J9-PO; Tue, 25 Sep 2007 12:28:37 +0600 Message-ID: <46F8AA6D.6050402@pw.utc.com> Date: Tue, 25 Sep 2007 12:27:57 +0600 From: User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: megaco-archive@lists.ietf.org Subject: Why have one, when you can have 1000's Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 3.5 (+++) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 Arcade World, making online gaming free for the world. http://74.140.209.145/ From McCullum@attiliocompagnone.it Tue Sep 25 08:07:03 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia9Bv-0005Ov-MB for megaco-archive@lists.ietf.org; Tue, 25 Sep 2007 08:07:03 -0400 Received: from aafi137.neoplus.adsl.tpnet.pl ([83.4.138.137] helo=dji180.neoplus.adsl.tpnet.pl) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ia9Bq-0003SZ-Ut for megaco-archive@lists.ietf.org; Tue, 25 Sep 2007 08:07:00 -0400 Received: from LENOVO-463DA5BA ([119.154.142.76] helo=LENOVO-463DA5BA) by dgk33.neoplus.adsl.tpnet.pl ( sendmail 8.13.3/8.13.1) with esmtpa id 1ZKGgV-000RRE-iV for megaco-archive@lists.ietf.org; Tue, 25 Sep 2007 14:06:56 +0200 Message-ID: <000601c7ff6c$8b659670$21a61753@LENOVO463DA5BA> From: "Robet McCullum" To: Subject: namkcolb Date: Tue, 25 Sep 2007 14:06:46 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C7FF7D.4EEE6670" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 4.3 (++++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0003_01C7FF7D.4EEE6670 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable http://encanq.com/ Yo yo yo megaco-archive my banger is HUGE now thanks to these guys.. Robet McCullum ------=_NextPart_000_0003_01C7FF7D.4EEE6670 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable
http://encanq.com/
Yo yo yo megaco-archive
my banger is HUGE now thanks to these = guys..
Robet McCullum
------=_NextPart_000_0003_01C7FF7D.4EEE6670-- From Molotsky@schuelerhilfe-badkreuznach.de Tue Sep 25 14:08:11 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaEpP-0005LQ-8G for megaco-archive@lists.ietf.org; Tue, 25 Sep 2007 14:08:11 -0400 Received: from host-84-9-148-16.bulldogdsl.com ([84.9.148.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaEpF-0005BT-U7 for megaco-archive@lists.ietf.org; Tue, 25 Sep 2007 14:08:08 -0400 Received: from winxp by schuelerhilfe-badkreuznach.de with ASMTP id 59DE1D7B for ; Thu, 4 Oct 2007 19:08:08 +0100 Received: from winxp ([195.173.179.63]) by schuelerhilfe-badkreuznach.de with ESMTP id C8B7997C3508 for ; Thu, 4 Oct 2007 19:08:08 +0100 Message-ID: <000301c806b1$6f29fd60$10940954@winxp> From: "Jet Molotsky" To: Subject: caglar Date: Thu, 4 Oct 2007 19:07:32 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C806B9.D0EE6560" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.5 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 ------=_NextPart_000_0008_01C806B9.D0EE6560 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable http://laminaes.com/ Good night megaco-archive owner's manual for your cock. Jet Molotsky ------=_NextPart_000_0008_01C806B9.D0EE6560 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable
http://laminaes.com/
Good night megaco-archive
owner's manual for your cock.
Jet Molotsky
------=_NextPart_000_0008_01C806B9.D0EE6560-- From caswellnax@pamexfood.com Tue Sep 25 22:35:07 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaMjz-00023S-RA for megaco-archive@lists.ietf.org; Tue, 25 Sep 2007 22:35:07 -0400 Received: from acot81.neoplus.adsl.tpnet.pl ([83.10.199.81]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaMjo-0005x6-SV for megaco-archive@lists.ietf.org; Tue, 25 Sep 2007 22:34:57 -0400 Received: from GZEGORZKÊPA ([136.166.129.17] helo=GZEGORZKÊPA) by acot81.neoplus.adsl.tpnet.pl ( sendmail 8.13.3/8.13.1) with esmtpa id 1gGiNT-000RQN-Oy for megaco-archive@lists.ietf.org; Wed, 26 Sep 2007 04:35:37 +0200 Message-ID: <000c01c7ffe5$d5ecad40$51c70a53@GZEGORZKPA> From: "uni caswell" To: Subject: karjol Date: Wed, 26 Sep 2007 04:35:00 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C7FFF6.99757D40" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 1.8 (+) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 ------=_NextPart_000_0005_01C7FFF6.99757D40 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable http://kvhawks.com/ Greeting megaco-archive wow, its so much bigger now uni caswell ------=_NextPart_000_0005_01C7FFF6.99757D40 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
http://kvhawks.com/
Greeting megaco-archive
wow, its so much bigger now
uni caswell
------=_NextPart_000_0005_01C7FFF6.99757D40-- From megaco-bounces@ietf.org Wed Sep 26 00:33:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaOXI-0006Gx-Pl; Wed, 26 Sep 2007 00:30:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaOXG-0006Aj-Ur for megaco@ietf.org; Wed, 26 Sep 2007 00:30:06 -0400 Received: from [220.226.195.213] (helo=rediffmail.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IaOX5-0004n8-I6 for megaco@ietf.org; Wed, 26 Sep 2007 00:30:00 -0400 Received: (qmail 7393 invoked by uid 510); 26 Sep 2007 04:28:11 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=redf; d=rediffmail.com; b=ABSG6RdLHFMPdSYWOy7qX64mJ5IF3pPzs10BW5FjSCYA8HqRHX9Lim3iAgsKr/zYrEheIGyVz9muQ5fwNzUb7E68xaI/kP/pbOl049szQ58kJVHN/ChTKxr5c1ThzMCq44qOVo2Y6hurTwnbR6Q5I7UEWs9nw+ot7mlyf8zTM30= ; Date: 26 Sep 2007 04:28:11 -0000 Message-ID: <20070926042811.7382.qmail@f5mail14.rediffmail.com> Received: from unknown (202.75.197.36) by rediffmail.com via HTTP; 26 sep 2007 04:28:11 -0000 MIME-Version: 1.0 From: "ramesh ramesh" To: megaco@ietf.org X-Spam-Score: 1.6 (+) X-Scan-Signature: bd8a74b81c71f965ca7918b90d1c49c0 Subject: [Megaco] telephone-event in Modify message X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ramesh ramesh List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0863041037==" Errors-To: megaco-bounces@ietf.org This is a multipart mime message --===============0863041037== Content-type: multipart/alternative; boundary="Next_1190780891---0-220.226.195.213-7337" This is a multipart mime message --Next_1190780891---0-220.226.195.213-7337 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi all,=0A=0A I have a doubt. Is it possible for us to send Modify Req= uest to Media Gateway for an ephemeral endpoint with "telephone-event"? I h= ave given the message below.Please let me know the possibility!!=0A=0ATestC= ase:=0A----------=0A=0A@TCID normal_H248-CallFlow-002.tc=0A@TITLE = Test a basic call tx(IP) tx(TDM)=0A@AUTHOR Ernesto Abad=0A@TEST_PH= ASE DESIGN=0A@KEYWORDS H.248=0A@RELEASE PCR5.1=0A@FEATURE_ID CD144= 7 - PVG - H.248 (Megaco)=0A=0A// Objective of test:=0A// Test a basic ca= ll tx(IP) tx(TDM) and check end-of-call stats=0A//=0A=0A#print Start of tes= t : H248-CallFlow-002=0A=0A// Setup the TDM connection of the near side of = the call.=0A//=0A#send MG1=0AMEGACO/1 {var mgcMid =3D getMgcmId}=0ATransact= ion =3D {var transId =3D newtransid} {=0A Context =3D $ {=0A Add =3D STM/3= /0/1/VC4VC12/1/1/1/1/1{=0A Media {LocalControl {Mode =3D SendReceive}=0A}= }}}=0A#;=0A=0A#receive MG1=0AMEGACO/1 {var mgMid =3D getMgmId}=0AReply =3D = {pop transId} {=0A Context =3D {var context} {=0A Add =3D STM/3/0/1/VC4VC1= 2/1/1/1/1/1=0A }=0A}=0A#;=0A=0A#hold added TDM near=0A=0A// Setup the IP co= nnection of the near side of the call.=0A//=0A#send MG1=0AMEGACO/1 {pop mgc= Mid}=0ATransaction =3D {var transId =3D newtransid} {=0A Context =3D {pop c= ontext} {=0A Add =3D $ {=0A Media {=0A O{MO=3DSR,RG=3DON,RV=3DON},=0A= L=0A {=0Av=3D0=0Ac=3DIN IP4 $=0Am=3Daudio $ RTP/AVP $=0Aa=3Dptime:20= =0A }=0A },=0A E=3D102{nt/netfail}=0A }=0A }=0A}=0A#;=0A=0A#receiv= e MG1=0AMEGACO/1 {pop mgMid}=0AReply =3D {pop transId} {=0A Context =3D {po= p context} {=0A Add =3D {var IPtermId} {=0A Media {=0A Local {=0A{var= sdp =3D getSDP}=0A }=0A }=0A }=0A }=0A}=0A#;=0A=0A#hold added IP Nea= r=0A=0A// Making the TDM far end connection.=0A//=0A#send MG1=0AMEGACO/1 {p= op mgcMid}=0ATransaction =3D {var transId =3D newtransid} {=0A Context =3D = $ {=0A Add =3D STM/3/0/1/VC4VC12/1/1/1/1/2 {=0A Media {LocalControl {Mod= e =3D SendReceive}=0A}}}}=0A#;=0A=0A#receive MG1=0AMEGACO/1 {var mgMid2 =3D= getMgmId}=0AReply =3D {pop transId} {=0A Context =3D {var context2} {=0A = Add =3D STM/3/0/1/VC4VC12/1/1/1/1/2=0A }=0A}=0A#;=0A=0A#hold Added TDM Far= =0A=0A// Setup the IP connection of the far side of the call.=0A//=0A#send = MG1=0AMEGACO/1 {pop mgcMid}=0ATransaction =3D {var transId =3D newtransid} = {=0A Context =3D {pop context2} {=0A Add =3D $ {=0A Media {=0A LocalC= ontrol {=0A Mode =3D SendReceive=0A },= =0A Local {=0Av=3D0=0Ac=3DIN IP4 $=0Am=3Daud= io $ RTP/AVP 99 101 100=0Aa=3Drtpmap:101 EVRCB/8000=0Aa=3Dfmtp:99 silencesu= pp=3D0=0Aa=3Drtpmap:101 telephone-event/8000=0Aa=3Drtpmap:100 nortel-contro= l/8000=0Aa=3Dptime:20=0A },=0A Remote {= =0A{pop sdp}=0A }=0A }=0A }=0A = }=0A}=0A#;=0A=0A=0A#receive MG1=0AMEGACO/1 {pop mgMid2}=0AReply =3D {po= p transId} {=0A Context =3D {pop context2} {=0A Add =3D {var IPtermId2} {= =0A Media {=0A Local {=0A{var sdp2 =3D getSDP}=0A }=0A }=0A }=0A= }=0A}=0A#;=0A=0A#hold Add IP Far=0A=0A// Tell the near end the IP address = of the far end.=0A//=0A=0A// Setup the IP connection of the far side of the= call.=0A//=0A#send MG1=0AMEGACO/1 {pop mgcMid}=0ATransaction =3D {var tran= sId =3D newtransid} {=0A Context =3D {pop context} {=0A Modify =3D {pop IP= termId} {=0A Media {=0A Local {=0Av=3D0=0Ac=3DIN IP4 $=0Am=3Daudio $ = RTP/AVP 99 101 100=0Aa=3Drtpmap:99 EVRCB/8000=0Aa=3Dfmtp:99 silencesupp=3D0= =0Aa=3Drtpmap:101 telephone-event/8000=0Aa=3Drtpmap:100 nortel-control/8000= =0Aa=3Dptime:20=0A },=0A=0A Remote {=0A{p= op sdp2}=0A }=0A }=0A }=0A = }=0A}=0A#;=0A=0A=0A#receive MG1=0AMEGACO/1 {pop mgMid}=0AReply =3D {pop tra= nsId} {=0A Context =3D {pop context} {=0A Modify =3D {pop IPtermId} {=0A = Media {=0A Local {=0A{var sdp =3D getSDP}=0A }=0A}}}}=0A#;=0A=0A#hold D= isplay nsta/x vgs and check that a call is active and using p:10=0A=0A//wai= t 2240=0A#hold before subtract ip=0A=0A#send MG1=0AMEGACO/1 {pop mgcMid}=0A= Transaction =3D {var transId =3D newtransid} {=0A Context =3D {pop = context} {=0A Subtract =3D {pop IPtermId}=0A } }=0A= #;=0A=0A#receive MG1=0AMEGACO/1 {pop mgMid}=0AReply =3D {pop transId} {=0A = Context =3D {pop context} {=0A Subtract =3D {pop IPtermId} {=0A Statis= tics {=0A nt/dur =3D {var dur},=0A nt/os =3D {var os},=0A nt/or = =3D {var or},=0A rtp/ps =3D {var ps},=0A rtp/pr =3D {var pr},=0A r= tp/pl =3D {var pl},=0A rtp/jit =3D {var jit},=0A rtp/delay =3D {var d= elay},=0A xrtp/ct =3D {var ct},=0A xrtp/bu =3D {var bu},=0A xrtp/b= o =3D {var bo},=0A xrtp/tpl =3D {var tpl},=0A xrtp/pd =3D {var pd},= =0A xrtp/ir =3D {var ir}=0A }=0A }=0A }=0A}=0A#;=0A=0A#print nt/dur = =3D {pop dur}=0A#hold before subtract tdm=0A=0A#send MG1=0AMEGACO/1 {pop mg= cMid}=0ATransaction =3D {var transId =3D newtransid} {=0A Context =3D {pop= context} {=0A Subtract =3D STM/3/0/1/VC4VC12/1/1/1/1/1=0A } }=0A#;=0A= =0A=0A#receive MG1=0AMEGACO/1 {pop mgMid}=0AReply =3D {pop transId} {=0A C= ontext =3D {pop context} {=0A Subtract =3D STM/3/0/1/VC4VC12/1/1/1/1/1 {= =0A Statistics {=0A nt/dur =3D {var dur},=0A nt/os =3D {var os},=0A= nt/or =3D {var or}=0A }=0A }=0A }=0A}=0A#;=0A#print nt/dur =3D {pop = dur}, nt/os =3D {pop os}, nt/or =3D {pop or}=0A =0A#send MG1=0AMEGACO/1 {po= p mgcMid}=0ATransaction =3D {var transId =3D newtransid} {=0A Conte= xt =3D {pop context2} {=0A Subtract =3D {pop IPtermId2}=0A = } }=0A#; =0A=0A#receive MG1=0AMEGACO/1 {pop mgMid2}=0AReply =3D {= pop transId} {=0A Context =3D {pop context2} {=0A Subtract =3D {pop IPte= rmId2} {=0A Statistics {=0A nt/dur =3D {var dur},=0A nt/os =3D {var= os},=0A nt/or =3D {var or},=0A rtp/ps =3D {var ps},=0A rtp/pr =3D= {var pr},=0A rtp/pl =3D {var pl},=0A rtp/jit =3D {var jit},=0A rt= p/delay =3D {var delay},=0A xrtp/ct =3D {var ct},=0A xrtp/bu =3D {var= bu},=0A xrtp/bo =3D {var bo},=0A xrtp/tpl =3D {var tpl},=0A xrtp/= pd =3D {var pd},=0A xrtp/ir =3D {var ir}=0A }=0A }=0A }=0A}=0A#;=0A= =0A#print nt/dur =3D {pop dur}=0A =0A//#hold Check the deletion of {pop IPt= ermId2} in context {pop context2}=0A#send MG1=0AMEGACO/1 {pop mgcMid} =0ATr= ansaction =3D {var transId =3D newtransid} {=0A Context =3D {pop context2}= {=0A Subtract =3D STM/3/0/1/VC4VC12/1/1/1/1/2=0A } }=0A#;=0A=0A=0A#rece= ive MG1=0AMEGACO/1 {pop mgMid2}=0AReply =3D {pop transId} {=0A Context =3D= {pop context2} {=0A Subtract =3D STM/3/0/1/VC4VC12/1/1/1/1/2 {=0A Stat= istics {=0A nt/dur =3D {var dur},=0A nt/os =3D {var os},=0A nt/or = =3D {var or}=0A }=0A }=0A }=0A}=0A#;=0A=0A#print nt/dur =3D {pop dur}, n= t/os =3D {pop os}, nt/or =3D {pop or}=0A=0A =0A#print End of test : H248-Ca= llFlowWithStats-002 =0A=0A=0A=0ARegards=0ARamesh K=0A=0A --Next_1190780891---0-220.226.195.213-7337 Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

=0AHi all,
=0A
=0A      I have a doubt. Is it possi= ble for us to send Modify Request to Media Gateway for an ephemeral endpoin= t with "telephone-event"? I have given the message below.Please l= et me know the possibility!!
=0A
=0ATestCase:
=0A----------
=0A=
=0A@TCID        normal_H248-CallFlow-002.tc
=0A@= TITLE      Test a basic call tx(IP) tx(TDM)
=0A@AUTHOR&n= bsp;     Ernesto Abad
=0A@TEST_PHASE  DESIGN
=0A@KEYWO= RDS    H.248
=0A@RELEASE    PCR5.1
=0A@FEATURE_I= D  CD1447 - PVG - H.248 (Megaco)
=0A
=0A// Objective of test:=0A//    Test a basic call tx(IP) tx(TDM) and check end-of-call = stats
=0A//
=0A
=0A#print Start of test : H248-CallFlow-002
=0A=
=0A// Setup the TDM connection of the near side of the call.
=0A//=0A#send MG1
=0AMEGACO/1 {var mgcMid =3D getMgcmId}
=0ATransaction = =3D {var transId =3D newtransid} {
=0A     Context =3D $ = {
=0A          Add =3D STM/3/0/1/VC4VC12/1= /1/1/1/1{
=0A               = ;Media {LocalControl {Mode =3D SendReceive}
=0A}}}}
=0A#;
=0A
= =0A#receive MG1
=0AMEGACO/1 {var mgMid =3D getMgmId}
=0AReply =3D {po= p transId} {
=0A     Context =3D {var context} {
=0A&n= bsp;         Add =3D STM/3/0/1/VC4VC12/1/1/1/1/1=0A     }
=0A}
=0A#;
=0A
=0A#hold added TDM ne= ar
=0A
=0A// Setup the IP connection of the near side of the call.=0A//
=0A#send MG1
=0AMEGACO/1 {pop mgcMid}
=0ATransaction =3D {v= ar transId =3D newtransid} {
=0A     Context =3D {pop con= text} {
=0A          Add =3D $ {
=0A&nb= sp;              Media {
=0A&nbs= p;                   = ;O{MO=3DSR,RG=3DON,RV=3DON},
=0A          =           L
=0A       =              {
=0Av=3D0
=0Ac= =3DIN IP4 $
=0Am=3Daudio $ RTP/AVP $
=0Aa=3Dptime:20
=0A  &nb= sp;                  }=0A               },
=0A&n= bsp;              E=3D102{nt/netfai= l}
=0A          }
=0A    &nbs= p;}
=0A}
=0A#;
=0A
=0A#receive MG1
=0AMEGACO/1 {pop mgMid}=0AReply =3D {pop transId} {
=0A     Context =3D {pop c= ontext} {
=0A          Add =3D {var IPterm= Id} {
=0A               Med= ia {
=0A               &nbs= p;    Local {
=0A{var sdp =3D getSDP}
=0A    &nbs= p;               }
=0A = ;              }
=0A   = ;       }
=0A     }
=0A}
=0A#;<= BR>=0A
=0A#hold added IP Near
=0A
=0A// Making the TDM far end con= nection.
=0A//
=0A#send MG1
=0AMEGACO/1 {pop mgcMid}
=0ATransac= tion =3D {var transId =3D newtransid} {
=0A     Context = =3D $ {
=0A          Add =3D STM/3/0/1/VC4= VC12/1/1/1/1/2 {
=0A             = ;  Media {LocalControl {Mode =3D SendReceive}
=0A}}}}
=0A#;
= =0A
=0A#receive MG1
=0AMEGACO/1 {var mgMid2 =3D getMgmId}
=0AReply= =3D {pop transId} {
=0A     Context =3D {var context2} {=
=0A          Add =3D STM/3/0/1/VC4VC12/1/= 1/1/1/2
=0A     }
=0A}
=0A#;
=0A
=0A#hold Add= ed TDM Far
=0A
=0A// Setup the IP connection of the far side of the c= all.
=0A//
=0A#send MG1
=0AMEGACO/1 {pop mgcMid}
=0ATransaction= =3D {var transId =3D newtransid} {
=0A     Context =3D {= pop context2} {
=0A          Add =3D $ {=0A               Media {=0A                 &nbs= p;  LocalControl {
=0A           = ;              Mode =3D SendReceive=
=0A                   = ;             },
=0A      &= nbsp;                    =     Local {
=0Av=3D0
=0Ac=3DIN IP4 $
=0Am=3Daudio $ RTP= /AVP 99 101 100
=0Aa=3Drtpmap:101 EVRCB/8000
=0Aa=3Dfmtp:99 silencesu= pp=3D0
=0Aa=3Drtpmap:101 telephone-event/8000
=0Aa=3Drtpmap:100 norte= l-control/8000
=0Aa=3Dptime:20
=0A          =                      = ; },
=0A               &nbs= p;    Remote {
=0A{pop sdp}
=0A       &= nbsp;            }
=0A    &= nbsp;                   }
= =0A                }
=0A  &= nbsp;     }
=0A}
=0A#;
=0A
=0A
=0A#receive MG1
= =0AMEGACO/1 {pop mgMid2}
=0AReply =3D {pop transId} {
=0A   = ;  Context =3D {pop context2} {
=0A        = ;  Add =3D {var IPtermId2} {
=0A         &= nbsp;     Media {
=0A         &n= bsp;          Local {
=0A{var sdp2 =3D get= SDP}
=0A               &nbs= p;    }
=0A            &nbs= p;  }
=0A          }
=0A  &nb= sp;  }
=0A}
=0A#;
=0A
=0A#hold Add IP Far
=0A
=0A// = Tell the near end the IP address of the far end.
=0A//
=0A
=0A// S= etup the IP connection of the far side of the call.
=0A//
=0A#send MG= 1
=0AMEGACO/1 {pop mgcMid}
=0ATransaction =3D {var transId =3D newtra= nsid} {
=0A     Context =3D {pop context} {
=0A  =         Modify =3D {pop IPtermId} {
=0A  &= nbsp;            Media {
=0A  &n= bsp;                  Loc= al {
=0Av=3D0
=0Ac=3DIN IP4 $
=0Am=3Daudio $ RTP/AVP 99 101 100=0Aa=3Drtpmap:99 EVRCB/8000
=0Aa=3Dfmtp:99 silencesupp=3D0
=0Aa=3Drt= pmap:101 telephone-event/8000
=0Aa=3Drtpmap:100 nortel-control/8000
= =0Aa=3Dptime:20
=0A              &nbs= p;                 },
=0A
=0A=                    &= nbsp;Remote {
=0A{pop sdp2}
=0A         &nbs= p;          }
=0A      &nbs= p;                 }
=0A  &= nbsp;             }
=0A     = ;   }
=0A}
=0A#;
=0A
=0A
=0A#receive MG1
=0AMEGACO/1= {pop mgMid}
=0AReply =3D {pop transId} {
=0A     Cont= ext =3D {pop context} {
=0A          Modif= y =3D {pop IPtermId} {
=0A           =    Media {
=0A            =         Local {
=0A{var sdp =3D getSDP}
=0A&= nbsp;    }
=0A}}}}
=0A#;
=0A
=0A#hold Display nsta/x = vgs and check that a call is active and using p:10
=0A
=0A//wait 2240=
=0A#hold before subtract ip
=0A
=0A#send MG1
=0AMEGACO/1 {pop = mgcMid}
=0ATransaction =3D {var transId =3D newtransid} {
=0A  &= nbsp;     Context =3D {pop context} {
=0A     =           Subtract =3D {pop IPtermId}
=0A&nbs= p;       } }
=0A#;
=0A
=0A#receive MG1
=0AMEGAC= O/1 {pop mgMid}
=0AReply =3D {pop transId} {
=0A      = Context =3D {pop context} {
=0A           = Subtract =3D {pop IPtermId} {
=0A          = ;     Statistics {
=0A         &= nbsp;          nt/dur =3D {var dur},
=0A&n= bsp;                  &nb= sp;nt/os =3D {var os},
=0A           =         nt/or =3D {var or},
=0A    &= nbsp;               rtp/ps =3D= {var ps},
=0A              &nbs= p;     rtp/pr =3D {var pr},
=0A      =              rtp/pl =3D {var pl},<= BR>=0A                 &n= bsp;  rtp/jit =3D {var jit},
=0A         &= nbsp;          rtp/delay =3D {var delay},
= =0A                  = ;  xrtp/ct =3D {var ct},
=0A          = ;          xrtp/bu =3D {var bu},
=0A =                   x= rtp/bo =3D {var bo},
=0A            &= nbsp;       xrtp/tpl =3D {var tpl},
=0A   =                 xrtp/pd = =3D {var pd},
=0A              &= nbsp;     xrtp/ir =3D {var ir}
=0A     &nb= sp;         }
=0A       &nb= sp;  }
=0A     }
=0A}
=0A#;
=0A
=0A#prin= t nt/dur =3D {pop dur}
=0A#hold before subtract tdm
=0A
=0A#send M= G1
=0AMEGACO/1 {pop mgcMid}
=0ATransaction =3D {var transId =3D newtr= ansid} {
=0A      Context =3D {pop context} {
=0A &nbs= p;         Subtract =3D STM/3/0/1/VC4VC12/1/1/1/1/= 1
=0A      } }
=0A#;
=0A
=0A
=0A#receive MG1<= BR>=0AMEGACO/1 {pop mgMid}
=0AReply =3D {pop transId} {
=0A   &n= bsp;  Context =3D {pop context} {
=0A        &n= bsp;  Subtract =3D STM/3/0/1/VC4VC12/1/1/1/1/1 {
=0A    &= nbsp;          Statistics {
=0A  &nbs= p;                 nt/dur= =3D {var dur},
=0A             =       nt/os =3D {var os},
=0A     &n= bsp;              nt/or =3D {var or= }
=0A               }
= =0A          }
=0A     }=0A}
=0A#;
=0A#print nt/dur =3D {pop dur}, nt/os =3D {pop os}, nt/or= =3D {pop or}
=0A
=0A#send MG1
=0AMEGACO/1 {pop mgcMid}
=0ATra= nsaction =3D {var transId =3D newtransid} {
=0A      &nbs= p; Context =3D {pop context2} {
=0A          &= nbsp;     Subtract =3D {pop IPtermId2}
=0A     = ;   } }
=0A#; 
=0A
=0A#receive MG1
=0AMEGACO/1 {po= p mgMid2}
=0AReply =3D {pop transId} {
=0A      Contex= t =3D {pop context2} {
=0A           Subtr= act =3D {pop IPtermId2} {
=0A          &nb= sp;    Statistics {
=0A          = ;          nt/dur =3D {var dur},
=0A =                   n= t/os =3D {var os},
=0A            &nb= sp;       nt/or =3D {var or},
=0A     = ;               rtp/ps =3D {va= r ps},
=0A               &n= bsp;    rtp/pr =3D {var pr},
=0A       &nb= sp;            rtp/pl =3D {var pl},
= =0A                  = ;  rtp/jit =3D {var jit},
=0A         &nbs= p;          rtp/delay =3D {var delay},
=0A=                    &= nbsp;xrtp/ct =3D {var ct},
=0A          &n= bsp;         xrtp/bu =3D {var bu},
=0A  &n= bsp;                 xrtp= /bo =3D {var bo},
=0A            &nbs= p;       xrtp/tpl =3D {var tpl},
=0A    &n= bsp;               xrtp/pd =3D= {var pd},
=0A              &nbs= p;     xrtp/ir =3D {var ir}
=0A      =         }
=0A        =  }
=0A     }
=0A}
=0A#;
=0A
=0A#print n= t/dur =3D {pop dur}
=0A
=0A//#hold Check the deletion of {pop IPterm= Id2} in context {pop context2}
=0A#send MG1
=0AMEGACO/1 {pop mgcMid} =
=0ATransaction =3D {var transId =3D newtransid} {
=0A     =  Context =3D {pop context2} {
=0A         =  Subtract =3D STM/3/0/1/VC4VC12/1/1/1/1/2
=0A      = } }
=0A#;
=0A
=0A
=0A#receive MG1
=0AMEGACO/1 {pop mgMid2}=0AReply =3D {pop transId} {
=0A      Context =3D {pop = context2} {
=0A           Subtract =3D STM= /3/0/1/VC4VC12/1/1/1/1/2 {
=0A          &n= bsp;    Statistics {
=0A         &nbs= p;          nt/dur =3D {var dur},
=0A = ;                   = nt/os =3D {var os},
=0A            &n= bsp;       nt/or =3D {var or}
=0A     = ;          }
=0A      =    }
=0A     }
=0A}
=0A#;
=0A
=0A#= print nt/dur =3D {pop dur}, nt/os =3D {pop os}, nt/or =3D {pop or}
=0A=0A
=0A#print End of test : H248-CallFlowWithStats-002 
=0A<= BR>=0A
=0A
=0ARegards
=0ARamesh K
=0A
=0A=0A

=0A

= =0A --Next_1190780891---0-220.226.195.213-7337-- --===============0863041037== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============0863041037==-- From megaco-bounces@ietf.org Wed Sep 26 02:26:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaQIX-0005nc-9v; Wed, 26 Sep 2007 02:23:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaQIW-0005nV-PH for megaco@ietf.org; Wed, 26 Sep 2007 02:23:00 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaQIU-0008RG-O1 for megaco@ietf.org; Wed, 26 Sep 2007 02:23:00 -0400 X-IronPort-AV: E=Sophos;i="4.20,299,1186383600"; d="scan'208,217";a="225225206" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 25 Sep 2007 23:22:58 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l8Q6Mwsn023633; Tue, 25 Sep 2007 23:22:58 -0700 Received: from sj-webmail-3.cisco.com (sj-webmail-3.cisco.com [171.70.156.8]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l8Q6Mwal014121; Wed, 26 Sep 2007 06:22:58 GMT Received: from sj-webmail-3.cisco.com (localhost.localdomain [127.0.0.1]) by sj-webmail-3.cisco.com (8.13.1/8.13.1) with ESMTP id l8Q6MviI026372; Tue, 25 Sep 2007 23:22:57 -0700 Received: from sj-webmail-3 (root@localhost) by sj-webmail-3.cisco.com (8.13.1/8.13.1/Submit) with ESMTP id l8Q6MtuR026362; Tue, 25 Sep 2007 23:22:56 -0700 Received: from ypatharewxp01 ( [172.30.218.193]) by sj-webmail-3 (Scalix SMTP Relay 10.0.5.3) via ESMTP; Tue, 25 Sep 2007 23:22:49 -0700 (PDT) Date: Wed, 26 Sep 2007 11:57:28 +0530 From: "Yogesh" To: "'ramesh ramesh'" , Message-ID: <"17101.34631190787769.sj-webmail-3*"@MHS> In-Reply-To: <20070926042811.7382.qmail@f5mail14.rediffmail.com> Subject: RE: [Megaco] telephone-event in Modify message x-scalix-Hops: 1 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Acf/+Gqs76SWRindQKqAKrF2QEADNgADAmoQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 MIME-Version: 1.0 DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=32851; t=1190787778; x=1191651778; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ypathare@cisco.com; z=From:=20=22Yogesh=22=20 |Subject:=20RE=3A=20[Megaco]=20telephone-event=20in=20Modify=20message |Sender:=20; bh=Nzg8vjR2WGbFq2ooK2Be3Yb+uINLPpx6LdVBDI0bNx4=; b=yhibL2VVGEtwjQ+dk1udvT+rYKg2OB5xRZpu0YwbIMgvJFHpKH0pi1YJ4d97WwHWMhkKohCD xQhrVJAjcOu3xWnXJ4ONkz7TzRq6xAscwi57o0eOBUUn1Hw4P7wWwGbL; Authentication-Results: sj-dkim-2; header.From=ypathare@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -2.2 (--) X-Scan-Signature: 0dcdaa57c570c86b2e4beb0ed476393e Cc: X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0704565589==" Errors-To: megaco-bounces@ietf.org --===============0704565589== Content-Type: multipart/alternative; boundary="----=_NextPart_000_006D_01C80034.6D388860" ------=_NextPart_000_006D_01C80034.6D388860 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Hi, It is possible to send Modify Request to Media Gateway for an ephemeral endpoint with "telephone-event" Cheers !!! Yogesh Pathare Senior Engineer - Testing A R I C E N T Presidency Tower B Fourth Floor Gurgaon , India 122001 Main +91 1243911200 Ext 5512 _____ From: ramesh ramesh [mailto:ramelcom@rediffmail.com] Sent: Wednesday, September 26, 2007 9:58 AM To: megaco@ietf.org Subject: [Megaco] telephone-event in Modify message Hi all, I have a doubt. Is it possible for us to send Modify Request to Media Gateway for an ephemeral endpoint with "telephone-event"? I have given the message below.Please let me know the possibility!! TestCase: ---------- @TCID normal_H248-CallFlow-002.tc @TITLE Test a basic call tx(IP) tx(TDM) @AUTHOR Ernesto Abad @TEST_PHASE DESIGN @KEYWORDS H.248 @RELEASE PCR5.1 @FEATURE_ID CD1447 - PVG - H.248 (Megaco) // Objective of test: // Test a basic call tx(IP) tx(TDM) and check end-of-call stats // #print Start of test : H248-CallFlow-002 // Setup the TDM connection of the near side of the call. // #send MG1 MEGACO/1 {var mgcMid = getMgcmId} Transaction = {var transId = newtransid} { Context = $ { Add = STM/3/0/1/VC4VC12/1/1/1/1/1{ Media {LocalControl {Mode = SendReceive} }}}} #; #receive MG1 MEGACO/1 {var mgMid = getMgmId} Reply = {pop transId} { Context = {var context} { Add = STM/3/0/1/VC4VC12/1/1/1/1/1 } } #; #hold added TDM near // Setup the IP connection of the near side of the call. // #send MG1 MEGACO/1 {pop mgcMid} Transaction = {var transId = newtransid} { Context = {pop context} { Add = $ { Media { O{MO=SR,RG=ON,RV=ON}, L { v=0 c=IN IP4 $ m=audio $ RTP/AVP $ a=ptime:20 } }, E=102{nt/netfail} } } } #; #receive MG1 MEGACO/1 {pop mgMid} Reply = {pop transId} { Context = {pop context} { Add = {var IPtermId} { Media { Local { {var sdp = getSDP} } } } } } #; #hold added IP Near // Making the TDM far end connection. // #send MG1 MEGACO/1 {pop mgcMid} Transaction = {var transId = newtransid} { Context = $ { Add = STM/3/0/1/VC4VC12/1/1/1/1/2 { Media {LocalControl {Mode = SendReceive} }}}} #; #receive MG1 MEGACO/1 {var mgMid2 = getMgmId} Reply = {pop transId} { Context = {var context2} { Add = STM/3/0/1/VC4VC12/1/1/1/1/2 } } #; #hold Added TDM Far // Setup the IP connection of the far side of the call. // #send MG1 MEGACO/1 {pop mgcMid} Transaction = {var transId = newtransid} { Context = {pop context2} { Add = $ { Media { LocalControl { Mode = SendReceive }, Local { v=0 c=IN IP4 $ m=audio $ RTP/AVP 99 101 100 a=rtpmap:101 EVRCB/8000 a=fmtp:99 silencesupp=0 a=rtpmap:101 telephone-event/8000 a=rtpmap:100 nortel-control/8000 a=ptime:20 }, Remote { {pop sdp} } } } } } #; #receive MG1 MEGACO/1 {pop mgMid2} Reply = {pop transId} { Context = {pop context2} { Add = {var IPtermId2} { Media { Local { {var sdp2 = getSDP} } } } } } #; #hold Add IP Far // Tell the near end the IP address of the far end. // // Setup the IP connection of the far side of the call. // #send MG1 MEGACO/1 {pop mgcMid} Transaction = {var transId = newtransid} { Context = {pop context} { Modify = {pop IPtermId} { Media { Local { v=0 c=IN IP4 $ m=audio $ RTP/AVP 99 101 100 a=rtpmap:99 EVRCB/8000 a=fmtp:99 silencesupp=0 a=rtpmap:101 telephone-event/8000 a=rtpmap:100 nortel-control/8000 a=ptime:20 }, Remote { {pop sdp2} } } } } } #; #receive MG1 MEGACO/1 {pop mgMid} Reply = {pop transId} { Context = {pop context} { Modify = {pop IPtermId} { Media { Local { {var sdp = getSDP} } }}}} #; #hold Display nsta/x vgs and check that a call is active and using p:10 //wait 2240 #hold before subtract ip #send MG1 MEGACO/1 {pop mgcMid} Transaction = {var transId = newtransid} { Context = {pop context} { Subtract = {pop IPtermId} } } #; #receive MG1 MEGACO/1 {pop mgMid} Reply = {pop transId} { Context = {pop context} { Subtract = {pop IPtermId} { Statistics { nt/dur = {var dur}, nt/os = {var os}, nt/or = {var or}, rtp/ps = {var ps}, rtp/pr = {var pr}, rtp/pl = {var pl}, rtp/jit = {var jit}, rtp/delay = {var delay}, xrtp/ct = {var ct}, xrtp/bu = {var bu}, xrtp/bo = {var bo}, xrtp/tpl = {var tpl}, xrtp/pd = {var pd}, xrtp/ir = {var ir} } } } } #; #print nt/dur = {pop dur} #hold before subtract tdm #send MG1 MEGACO/1 {pop mgcMid} Transaction = {var transId = newtransid} { Context = {pop context} { Subtract = STM/3/0/1/VC4VC12/1/1/1/1/1 } } #; #receive MG1 MEGACO/1 {pop mgMid} Reply = {pop transId} { Context = {pop context} { Subtract = STM/3/0/1/VC4VC12/1/1/1/1/1 { Statistics { nt/dur = {var dur}, nt/os = {var os}, nt/or = {var or} } } } } #; #print nt/dur = {pop dur}, nt/os = {pop os}, nt/or = {pop or} #send MG1 MEGACO/1 {pop mgcMid} Transaction = {var transId = newtransid} { Context = {pop context2} { Subtract = {pop IPtermId2} } } #; #receive MG1 MEGACO/1 {pop mgMid2} Reply = {pop transId} { Context = {pop context2} { Subtract = {pop IPtermId2} { Statistics { nt/dur = {var dur}, nt/os = {var os}, nt/or = {var or}, rtp/ps = {var ps}, rtp/pr = {var pr}, rtp/pl = {var pl}, rtp/jit = {var jit}, rtp/delay = {var delay}, xrtp/ct = {var ct}, xrtp/bu = {var bu}, xrtp/bo = {var bo}, xrtp/tpl = {var tpl}, xrtp/pd = {var pd}, xrtp/ir = {var ir} } } } } #; #print nt/dur = {pop dur} //#hold Check the deletion of {pop IPtermId2} in context {pop context2} #send MG1 MEGACO/1 {pop mgcMid} Transaction = {var transId = newtransid} { Context = {pop context2} { Subtract = STM/3/0/1/VC4VC12/1/1/1/1/2 } } #; #receive MG1 MEGACO/1 {pop mgMid2} Reply = {pop transId} { Context = {pop context2} { Subtract = STM/3/0/1/VC4VC12/1/1/1/1/2 { Statistics { nt/dur = {var dur}, nt/os = {var os}, nt/or = {var or} } } } } #; #print nt/dur = {pop dur}, nt/os = {pop os}, nt/or = {pop or} #print End of test : H248-CallFlowWithStats-002 Regards Ramesh K ------=_NextPart_000_006D_01C80034.6D388860 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hi,
 
It is possible to send Modify Request to Media Gateway for an ephemera= l=20 endpoint with "telephone-event"
 
 
 
Cheers=20 !!!
 

Yogesh= =20 Pathare

Senior= Engineer=20 - Testing

 

A R I C E N= =20 T

 =

Presid= ency=20 Tower B

Fourth= Floor= =20

Gurgao= n ,=20 India=20 122001

Main     = +91 12= 43911200=20 Ext 5512

<= /DIV>
=
 


From: ramesh ramesh=20 [mailto:ramelcom@rediffmail.com]
Sent: Wednesday, September 26= , 2007=20 9:58 AM
To: megaco@ietf.org
Subject: [Megaco]=20 telephone-event in Modify message

Hi all,

      I have a doubt. Is it possible for= us to=20 send Modify Request to Media Gateway for an ephemeral endpoint with=20 "telephone-event"? I have given the message below.Please let me know the=20 possibility!!

TestCase:
----------

@TCID    &n= bsp;=20   normal_H248-CallFlow-002.tc
@TITLE      Test a b= asic=20 call tx(IP) tx(TDM)
@AUTHOR      Ernesto=20 Abad
@TEST_PHASE  DESIGN
@KEYWORDS   =20 H.248
@RELEASE    PCR5.1
@FEATURE_ID  CD1447 - PVG -= H.248=20 (Megaco)

// Objective of test:
//    Test a basic cal= l=20 tx(IP) tx(TDM) and check end-of-call stats
//

#print Start of t= est :=20 H248-CallFlow-002

// Setup the TDM connection of the near side of t= he=20 call.
//
#send MG1
MEGACO/1 {var mgcMid =3D getMgcmId}
Transa= ction =3D=20 {var transId =3D newtransid} {
     Context =3D $ {
=  =20         Add =3D STM/3/0/1/VC4VC12/1/1/1/1/1{
=  =20              Media {LocalControl {= Mode =3D=20 SendReceive}
}}}}
#;

#receive MG1
MEGACO/1 {var mgMid =3D= =20 getMgmId}
Reply =3D {pop transId} {
     Context =3D= {var=20 context} {
          Add =3D=20 STM/3/0/1/VC4VC12/1/1/1/1/1
     }
}
#;

#h= old=20 added TDM near

// Setup the IP connection of the near side of the=20 call.
//
#send MG1
MEGACO/1 {pop mgcMid}
Transaction =3D {var= transId=20 =3D newtransid} {
     Context =3D {pop context} {
&= nbsp;=20         Add =3D $ {
      = ;  =20       Media {
        =20            O{MO=3DSR,RG=3DON,RV=3DON},=
 =20                 =20  L
               &n= bsp;=20    {
v=3D0
c=3DIN IP4 $
m=3Daudio $ RTP/AVP=20 $
a=3Dptime:20
             &nbs= p;=20       }
          &n= bsp;=20    },
             =20  E=3D102{nt/netfail}
          } =20    }
}
#;

#receive MG1
MEGACO/1 {pop mgMid}
= Reply =3D=20 {pop transId} {
     Context =3D {pop context} {
&nb= sp;=20         Add =3D {var IPtermId} {
   = ;=20            Media {
   =20                 Local=20 {
{var sdp =3D getSDP}
          &nbs= p;  =20       }
          &n= bsp;=20    }
          }
  &nb= sp;=20  }
}
#;

#hold added IP Near

// Making the TDM fa= r end=20 connection.
//
#send MG1
MEGACO/1 {pop mgcMid}
Transaction =3D= {var=20 transId =3D newtransid} {
     Context =3D $ {
 = ;  =20       Add =3D STM/3/0/1/VC4VC12/1/1/1/1/2 {
 =  =20            Media {LocalControl {Mode =3D= =20 SendReceive}
}}}}
#;

#receive MG1
MEGACO/1 {var mgMid2 =3D= =20 getMgmId}
Reply =3D {pop transId} {
     Context =3D= {var=20 context2} {
          Add =3D=20 STM/3/0/1/VC4VC12/1/1/1/1/2
     }
}
#;

#h= old=20 Added TDM Far

// Setup the IP connection of the far side of the=20 call.
//
#send MG1
MEGACO/1 {pop mgcMid}
Transaction =3D {var= transId=20 =3D newtransid} {
     Context =3D {pop context2} {
=  =20         Add =3D $ {
      = ;  =20       Media {
        =20            LocalControl {
  &n= bsp;=20                   &= nbsp;=20  Mode =3D SendReceive
            &= nbsp;=20                   },
&nbs= p;=20                     &nb= sp;=20         Local {
v=3D0
c=3DIN IP4 $
m=3Daudio= $ RTP/AVP 99=20 101 100
a=3Drtpmap:101 EVRCB/8000
a=3Dfmtp:99 silencesupp=3D0
a=3D= rtpmap:101=20 telephone-event/8000
a=3Drtpmap:100 nortel-control/8000
a=3Dptime:2= 0
 =20                     &nb= sp;=20         },
          = ; =20         Remote {
{pop sdp}
   =20                 }
&n= bsp;=20                     &nb= sp;=20 }
                }
  &= nbsp;=20     }
}
#;


#receive MG1
MEGACO/1 {pop=20 mgMid2}
Reply =3D {pop transId} {
     Context =3D {= pop=20 context2} {
          Add =3D {var IPter= mId2}=20 {
               Media=20 {
                 &= nbsp;=20  Local {
{var sdp2 =3D getSDP}
       &nbs= p;=20            }
     &n= bsp;=20         }
        =20  }
     }
}
#;

#hold Add IP Far
//=20 Tell the near end the IP address of the far end.
//

// Setup th= e IP=20 connection of the far side of the call.
//
#send MG1
MEGACO/1 {p= op=20 mgcMid}
Transaction =3D {var transId =3D newtransid} {
   = ;=20  Context =3D {pop context} {
        =20  Modify =3D {pop IPtermId} {
        =20       Media {
        =20             Local {
v=3D0
c=3DIN= IP4=20 $
m=3Daudio $ RTP/AVP 99 101 100
a=3Drtpmap:99 EVRCB/8000
a=3Dfm= tp:99=20 silencesupp=3D0
a=3Drtpmap:101 telephone-event/8000
a=3Drtpmap:100=20 nortel-control/8000
a=3Dptime:20
         =  =20                    =20 },

               &nb= sp;=20    Remote {
{pop sdp2}
        =20            }
      &= nbsp;=20                 }
   = ;=20             }
       = ;=20 }
}
#;


#receive MG1
MEGACO/1 {pop mgMid}
Reply =3D= {pop=20 transId} {
     Context =3D {pop context} {
  &= nbsp;=20       Modify =3D {pop IPtermId} {
   =20            Media {
   =20                 Local=20 {
{var sdp =3D getSDP}
     }
}}}}
#;

#= hold=20 Display nsta/x vgs and check that a call is active and using p:10

= //wait=20 2240
#hold before subtract ip

#send MG1
MEGACO/1 {pop=20 mgcMid}
Transaction =3D {var transId =3D newtransid} {
   = ;  =20   Context =3D {pop context} {
          &= nbsp;=20     Subtract =3D {pop IPtermId}
        }= =20 }
#;

#receive MG1
MEGACO/1 {pop mgMid}
Reply =3D {pop tra= nsId}=20 {
     Context =3D {pop context} {
    &nb= sp; =20    Subtract =3D {pop IPtermId} {
       &= nbsp;=20       Statistics {
       &nbs= p;=20            nt/dur =3D {var dur},
&n= bsp;=20                   = nt/os =3D=20 {var os},
               =  =20    nt/or =3D {var or},
         &nb= sp; =20         rtp/ps =3D {var ps},
   =20                 rtp/pr =3D= {var=20 pr},
                = ;=20    rtp/pl =3D {var pl},
        =20            rtp/jit =3D {var jit},
&= nbsp;=20                 =20  rtp/delay =3D {var delay},
         &nb= sp; =20         xrtp/ct =3D {var ct},
   =20                 xrtp/bu= =3D {var=20 bu},
                = ;=20    xrtp/bo =3D {var bo},
        =20            xrtp/tpl =3D {var tpl},
=  =20                   = xrtp/pd=20 =3D {var pd},
             =20       xrtp/ir =3D {var ir}
     &nb= sp;=20         }
        =20  }
     }
}
#;

#print nt/dur =3D {pop= =20 dur}
#hold before subtract tdm

#send MG1
MEGACO/1 {pop=20 mgcMid}
Transaction =3D {var transId =3D newtransid} {
   = ;=20  Context =3D {pop context} {
        =20  Subtract =3D STM/3/0/1/VC4VC12/1/1/1/1/1
     }=20 }
#;


#receive MG1
MEGACO/1 {pop mgMid}
Reply =3D {pop= transId}=20 {
     Context =3D {pop context} {
    &nb= sp; =20    Subtract =3D STM/3/0/1/VC4VC12/1/1/1/1/1 {
   =20            Statistics {
  &nbs= p;=20                 nt/dur =3D= {var=20 dur},
               &nbs= p;=20    nt/os =3D {var os},
         &nb= sp; =20         nt/or =3D {var or}
    &nbs= p; =20         }
        =20  }
     }
}
#;
#print nt/dur =3D {pop dur= }, nt/os=20 =3D {pop os}, nt/or =3D {pop or}

#send MG1
MEGACO/1 {pop=20 mgcMid}
Transaction =3D {var transId =3D newtransid} {
   = ;  =20   Context =3D {pop context2} {
         =  =20     Subtract =3D {pop IPtermId2}
       = }=20 }
#; 

#receive MG1
MEGACO/1 {pop mgMid2}
Reply =3D {= pop=20 transId} {
     Context =3D {pop context2} {
  &= nbsp;=20       Subtract =3D {pop IPtermId2} {
   = =20            Statistics {
  &nbs= p;=20                 nt/dur =3D= {var=20 dur},
               &nbs= p;=20    nt/os =3D {var os},
         &nb= sp; =20         nt/or =3D {var or},
    &nb= sp; =20              rtp/ps =3D {var=20 ps},
                = ;=20    rtp/pr =3D {var pr},
        =20            rtp/pl =3D {var pl},
&nb= sp;=20                   = rtp/jit=20 =3D {var jit},
             =20       rtp/delay =3D {var delay},
    &nb= sp; =20              xrtp/ct =3D {var=20 ct},
                = ;=20    xrtp/bu =3D {var bu},
        =20            xrtp/bo =3D {var bo},
&n= bsp;=20                 =20  xrtp/tpl =3D {var tpl},
          =  =20         xrtp/pd =3D {var pd},
   =20                 xrtp/ir= =3D {var=20 ir}
               }
&= nbsp;=20         }
   =20  }
}
#;

#print nt/dur =3D {pop dur}

//#hold Chec= k the=20 deletion of {pop IPtermId2} in context {pop context2}
#send MG1
MEG= ACO/1=20 {pop mgcMid}
Transaction =3D {var transId =3D newtransid} {
 =  =20  Context =3D {pop context2} {
        =20  Subtract =3D STM/3/0/1/VC4VC12/1/1/1/1/2
     }=20 }
#;


#receive MG1
MEGACO/1 {pop mgMid2}
Reply =3D {po= p=20 transId} {
     Context =3D {pop context2} {
  &= nbsp;=20       Subtract =3D STM/3/0/1/VC4VC12/1/1/1/1/2 {
&= nbsp;=20              Statistics {
&nbs= p;=20                   = nt/dur=20 =3D {var dur},
             =20       nt/os =3D {var os},
     &nbs= p;  =20            nt/or =3D {var or}
 = ;  =20            }
     &n= bsp;=20    }
     }
}
#;

#print nt/dur =3D= {pop=20 dur}, nt/os =3D {pop os}, nt/or =3D {pop or}


#print End of tes= t :=20 H248-CallFlowWithStats-002 



Regards
Ramesh=20 K



------=_NextPart_000_006D_01C80034.6D388860-- --===============0704565589== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============0704565589==-- From debie-Echols@gcul.org Wed Sep 26 08:28:57 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaW0f-0004IP-1o for megaco-archive@lists.ietf.org; Wed, 26 Sep 2007 08:28:57 -0400 Received: from p57b96862.dip.t-dialin.net ([87.185.104.98]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaW0V-0005OT-GV for megaco-archive@lists.ietf.org; Wed, 26 Sep 2007 08:28:47 -0400 Received: from INSANE ([146.104.91.152]:3046 "EHLO INSANE" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by p57B96862.dip.t-dialin.net with ESMTP id S22CBQXNMWSDXKLY (ORCPT ); Wed, 26 Sep 2007 14:28:15 +0200 Message-ID: <000c01c80038$acdd9330$6268b957@INSANE> From: "debie Echols" To: Subject: ioccabot Date: Wed, 26 Sep 2007 14:27:59 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C80049.70666330" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 ------=_NextPart_000_0006_01C80049.70666330 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://ccaatcu.com/ hello megaco-archive people are so shocked when they find out these herbal pills actually = work debie Echols ------=_NextPart_000_0006_01C80049.70666330 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://ccaatcu.com/
hello megaco-archive
people are so shocked when they find out these = herbal=20 pills actually work
debie Echols
------=_NextPart_000_0006_01C80049.70666330-- From janwillemParnell@afrispan.com Wed Sep 26 10:17:15 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaXhT-0004Uy-LM for megaco-archive@lists.ietf.org; Wed, 26 Sep 2007 10:17:15 -0400 Received: from i05v-87-90-190-95.d4.club-internet.fr ([87.90.190.95]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaXhS-0008VM-5i for megaco-archive@lists.ietf.org; Wed, 26 Sep 2007 10:17:15 -0400 Received: from lsd by afrispan.com with ASMTP id 4D7BCF08 for ; Wed, 26 Sep 2007 16:20:34 +0200 Received: from lsd ([193.157.91.136]) by afrispan.com with ESMTP id 777A461E37D3 for ; Wed, 26 Sep 2007 16:20:34 +0200 Message-ID: <818D6852.42818038@afrispan.com> Date: Wed, 26 Sep 2007 16:20:24 +0200 From: "janwillem Parnell" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: megaco-archive@lists.ietf.org Subject: uierdoek Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 3.5 (+++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Good evening megaco-archive ladies like em big, so i enlarged my cock just to please them.. janwillem Parnell http://www.ggaciton.com/ From Thamires-Leach@daryldavis.com Wed Sep 26 15:13:48 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IacKS-0005zU-9H for megaco-archive@lists.ietf.org; Wed, 26 Sep 2007 15:13:48 -0400 Received: from i05v-87-90-189-128.d4.club-internet.fr ([87.90.189.128]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IacKL-0005U4-PF for megaco-archive@lists.ietf.org; Wed, 26 Sep 2007 15:13:48 -0400 Received: from SN100862420005 ([151.197.103.115] helo=SN100862420005) by [87.90.189.128] ( sendmail 8.13.3/8.13.1) with esmtpa id 1SkpjG-000JAI-qd for megaco-archive@lists.ietf.org; Wed, 26 Sep 2007 21:14:20 +0200 Message-ID: <8C8D0648.916A7D10@daryldavis.com> Date: Wed, 26 Sep 2007 21:13:56 +0200 From: "Thamires Leach" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: megaco-archive@lists.ietf.org Subject: etsivitk Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 3.5 (+++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Morning megaco-archive 50,000+ satisfied customers and counting Thamires Leach http://www.cinrcm.com/ From megaco-bounces@ietf.org Wed Sep 26 19:25:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IagEb-0007vG-JU; Wed, 26 Sep 2007 19:24:01 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IagEb-0007tD-1M for megaco@ietf.org; Wed, 26 Sep 2007 19:24:01 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IagEa-0002zQ-6a for megaco@ietf.org; Wed, 26 Sep 2007 19:24:00 -0400 X-IronPort-AV: E=Sophos;i="4.21,199,1188802800"; d="scan'208,217";a="528544414" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 26 Sep 2007 16:23:57 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l8QNNvpo027513 for ; Wed, 26 Sep 2007 16:23:57 -0700 Received: from sj-webmail-3.cisco.com (sj-webmail-3.cisco.com [171.70.156.8]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8QNNv1l026789 for ; Wed, 26 Sep 2007 23:23:57 GMT Received: from sj-webmail-3.cisco.com (localhost.localdomain [127.0.0.1]) by sj-webmail-3.cisco.com (8.13.1/8.13.1) with ESMTP id l8QNNvxA001433 for ; Wed, 26 Sep 2007 16:23:57 -0700 Received: from sj-webmail-3 (root@localhost) by sj-webmail-3.cisco.com (8.13.1/8.13.1/Submit) with ESMTP id l8QNNv07001432 for ; Wed, 26 Sep 2007 16:23:57 -0700 Received: from PRNAGARWXP (dhcp-171-70-209-195.cisco.com [171.70.209.195]) by sj-webmail-3 (Scalix SMTP Relay 10.0.5.3) via ESMTP; Wed, 26 Sep 2007 16:23:56 -0700 (PDT) Date: Wed, 26 Sep 2007 16:23:56 -0700 From: "Prerna Nagar" To: Message-ID: <004a01c80094$4f886dc0$c3d146ab@apac.cisco.com> x-scalix-Hops: 1 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcgAlE9Rhaa3gfaYQPCJbTO8mGo5sQ== MIME-Version: 1.0 DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7623; t=1190849037; x=1191713037; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=prnagar@cisco.com; z=From:=20=22Prerna=20Nagar=22=20 |Subject:=20Regarding=20different=20payload=20types=20in=20local=20and=20 remote=20descriptor=20for=20same=20codec |Sender:=20; bh=eh1JSTYla6ToUhsVxrNibzePGVZZIwBsYeBRNejzmYo=; b=fhlW2io/u04k+nEc6kA43BwAVkcCn9P8qhpyeAq6/gUtusUg2osgvTIBYX2nNghAak4LKMfW W3L9OG8T3+izh1mBmNn4FvKVbgNEhEwwjt2P8Ugmc7oPKY9y7uRdGlfE; Authentication-Results: sj-dkim-2; header.From=prnagar@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee Subject: [Megaco] Regarding different payload types in local and remote descriptor for same codec X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1224400528==" Errors-To: megaco-bounces@ietf.org --===============1224400528== Content-Type: multipart/alternative; boundary="----=_NextPart_000_004B_01C80059.A32995C0" ------=_NextPart_000_004B_01C80059.A32995C0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Hi All, Consider a case when a Add request comes to media gateway and the request looks like: Add Request {Context = $ { Add = DS/1/1/2 { Media { LocalControl { Mode = SendReceive } } } , Add = $ { Media { LocalControl { Mode = SendReceive, ReservedValue = OFF } , Local { v=0 c=IN IP4 $ m=audio $ RTP/AVP $ },Remote { v=0 o=- 0 0 IN IP4 - s=- c=IN IP4 210.2.12.2 t=0 0 m=audio 16400 RTP/AVP 106 100 a=rtpmap:106 PCMU/8000/1 a=rtpmap:100 X-NSE/8000/1 a=fmtp:100 192-194 } } } }} Here "CHOOSE" in Local resolves to a list of codecs supported by the gatway(PCMU will resolve to 0) Next intersection of codecs between local and remote takes place. But here in Local PCMU has a static value "0" and remote understands "106" as PCMU (different payload types). Question is : How the codec negotiation should work and how the response should look like? Should it look like : 1. a=tgwrtp/8079 { m { Local { v=0 o=- 0 0 IN IP4 - s=- c=IN IP4 210.2.12.2 t=0 0 m=audio 16400 RTP/AVP 0 100 a=rtpmap:100 X-NSE/8000/1 a=fmtp:100 192-194 } , Remote{ v=0 o=- 0 0 IN IP4 - s=- c=IN IP4 210.2.12.2 t=0 0 m=audio 16400 RTP/AVP 106 100 a=rtpmap:106 PCMU/8000/1 a=rtpmap:100 X-NSE/8000/1 a=fmtp:100 192-194 }} } }} or 2. a=tgwrtp/8079 { m { Local { v=0 o=- 0 0 IN IP4 - s=- c=IN IP4 210.2.12.2 t=0 0 m=audio 16400 RTP/AVP 106 100 a=rtpmap:100 X-NSE/8000/1 a=fmtp:100 192-194 } , Remote{ v=0 o=- 0 0 IN IP4 - s=- c=IN IP4 210.2.12.2 t=0 0 m=audio 16400 RTP/AVP 106 100 a=rtpmap:106 PCMU/8000/1 a=rtpmap:100 X-NSE/8000/1 a=fmtp:100 192-194 }} } }} Regards, Prerna ------=_NextPart_000_004B_01C80059.A32995C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hi All,
 =
Consider a case when= a Add=20 request comes to media gateway and the request looks like:<= /DIV>
 =
Add=20 Request
{Context =3D $ { Add= =3D DS/1/1/2 {=20 Media { LocalControl { Mode =3D SendReceive } } } ,
Add =3D $ { Media { L= ocalControl=20 { Mode =3D SendReceive, ReservedValue =3D OFF } ,
Local {
v=3D0
= c=3DIN IP4=20 $
m=3Daudio $ RTP/AVP $
},Remote {
v=3D0<= BR>o=3D- 0 0 IN=20 IP4 -
s=3D-
c=3DIN IP4 210.2.12.2
t=3D0 0
m=3Daudio 16400 RTP= /AVP=20 106 100
a=3Drtpmap:106=20 PCMU/8000/1
a=3Drtpmap:100 X-NSE/8000/1
a=3Dfmtp:100 192-1= 94
} } }=20 }}
 =
Here  "CHOOSE"&= nbsp;in Local resolves to a list of codecs supported by the gatwa= y(PCMU will resolve to 0)<= /DIV>
Next intersection of codecs betwee= n local=20 and remote takes place.
But here in Local  PCMU has a static value "0" and re= mote=20 understands "106" as PCMU (different payload types).
 =
= Question is :=20 How the codec negotiation should work and how the response should look=20 like?
 
Should it look like=20 :
1.=20
a=3Dtgwrtp/8079 = ; { m {=20
Local {
v=3D0
o=3D- 0 0 IN IP4 -
= s=3D-
c=3DIN=20 IP4 210.2.12.2
t=3D0 0
m=3Daudio 16400 RTP/AVP 0=20 100
a=3Drtpmap:100 X-NSE/8000/1
a=3Dfmtp:100=20 192-194
 } ,
Remote{
v=3D0
o=3D- 0 0 I= N IP4=20 -
s=3D-
c=3DIN IP4 210.2.12.2
t=3D0 0
m=3Daudio 16400=20 RTP/AVP 106 100
a=3Drtpmap:1= 06=20 PCMU/8000/1
a=3Drtpmap:100 X-NSE/8000/1
a=3Dfmtp:100=20 192-194
 }}  } }}
 =
or
2.
a=3Dtgwrtp/8079 = ; { m {=20
Local {
v=3D0
o=3D- 0 0 IN IP4 -
= s=3D-
c=3DIN=20 IP4 210.2.12.2
t=3D0 0
m=3Daudio 16400 RTP/AVP 106=20 100
a=3Drtpmap:100 X-NSE/8000/1
a=3Dfmtp:100=20 192-194
 } ,
Remote{
v=3D0
o=3D- 0 0 I= N IP4=20 -
s=3D-
c=3DIN IP4 210.2.12.2
t=3D0 0
m=3Daudio 16400=20 RTP/AVP 106 100
a=3Drtpmap:1= 06=20 PCMU/8000/1
a=3Drtpmap:100 X-NSE/8000/1
a=3Dfmtp:100=20 192-194
 }}  } }}
 =
Regards,
Prerna

------=_NextPart_000_004B_01C80059.A32995C0-- --===============1224400528== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============1224400528==-- From megaco-bounces@ietf.org Thu Sep 27 02:52:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IanBh-0006dV-Bm; Thu, 27 Sep 2007 02:49:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IanBf-0006Qa-4u; Thu, 27 Sep 2007 02:49:27 -0400 Received: from smail5.alcatel.fr ([62.23.212.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IanBU-0004Gt-AY; Thu, 27 Sep 2007 02:49:23 -0400 Received: from FRVELSBHS04.ad2.ad.alcatel.com (frvelsbhs04.ad2.ad.alcatel.com [155.132.6.76]) by smail5.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l8R6lwPO012019; Thu, 27 Sep 2007 08:47:58 +0200 Received: from FRVELSMBS11.ad2.ad.alcatel.com ([155.132.6.31]) by FRVELSBHS04.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Thu, 27 Sep 2007 08:48:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Megaco] Regarding different payload types in local and remote descriptor for same codec Date: Thu, 27 Sep 2007 08:48:42 +0200 Message-ID: <8BB8AD9870081C42B2B309E00352E4EAD12F34@FRVELSMBS15.ad2.ad.alcatel.com> In-Reply-To: <004a01c80094$4f886dc0$c3d146ab@apac.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Megaco] Regarding different payload types in local and remote descriptor for same codec Thread-Index: AcgAlE9Rhaa3gfaYQPCJbTO8mGo5sQAPOi/w References: <004a01c80094$4f886dc0$c3d146ab@apac.cisco.com> From: "Schwarz Albrecht" To: "Prerna Nagar" , X-OriginalArrivalTime: 27 Sep 2007 06:48:44.0508 (UTC) FILETIME=[728DB1C0:01C800D2] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.13 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ba0ec39a747b7612d6a8ae66d1a873c Cc: avt@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1341309934==" Errors-To: megaco-bounces@ietf.org This is a multi-part message in MIME format. --===============1341309934== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C800D2.72678F18" This is a multi-part message in MIME format. ------_=_NextPart_001_01C800D2.72678F18 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable This is not an H.248 issue in my understanding, this relates to the "AVP Profile", thus a RFC 3550 matter (I've Cc'ed avt@ietf.org) in my understandning: =20 When RTP/AVP allows to use different PT codepoint values for the same media format, then the SDP is correct. When RTP/AVP does not allow to use different PT codepoint values for the same media format, then the SDP is incorrect (and the MG must reply with an error code because the ADD.request was incorrect). =20 -Albrecht =20 PS Different media formats per traffic direction is possible (but this was not the question). =20 PSS I guess that PCMU is not used as "VBD codec" (i.e. with a dynamic PT value). But if yes, then the SDP is incorrect. The SDP must then follow V.152, see "a=3D" line ... ________________________________ From: Prerna Nagar [mailto:prnagar@cisco.com]=20 Sent: Donnerstag, 27. September 2007 01:24 To: megaco@ietf.org Subject: [Megaco] Regarding different payload types in local and remotedescriptor for same codec =09 =09 Hi All, =20 Consider a case when a Add request comes to media gateway and the request looks like: =20 Add Request {Context =3D $ { Add =3D DS/1/1/2 { Media { LocalControl { Mode =3D SendReceive } } } , Add =3D $ { Media { LocalControl { Mode =3D SendReceive, ReservedValue =3D OFF } , Local { v=3D0 c=3DIN IP4 $ m=3Daudio $ RTP/AVP $ },Remote { v=3D0 o=3D- 0 0 IN IP4 - s=3D- c=3DIN IP4 210.2.12.2 t=3D0 0 m=3Daudio 16400 RTP/AVP 106 100 a=3Drtpmap:106 PCMU/8000/1 a=3Drtpmap:100 X-NSE/8000/1 a=3Dfmtp:100 192-194 } } } }} =20 Here "CHOOSE" in Local resolves to a list of codecs supported by the gatway(PCMU will resolve to 0) Next intersection of codecs between local and remote takes place. But here in Local PCMU has a static value "0" and remote understands "106" as PCMU (different payload types). =20 Question is : How the codec negotiation should work and how the response should look like? =20 Should it look like : 1.=20 a=3Dtgwrtp/8079 { m {=20 Local { v=3D0 o=3D- 0 0 IN IP4 - s=3D- c=3DIN IP4 210.2.12.2 t=3D0 0 m=3Daudio 16400 RTP/AVP 0 100 a=3Drtpmap:100 X-NSE/8000/1 a=3Dfmtp:100 192-194 } , Remote{ v=3D0 o=3D- 0 0 IN IP4 - s=3D- c=3DIN IP4 210.2.12.2 t=3D0 0 m=3Daudio 16400 RTP/AVP 106 100 a=3Drtpmap:106 PCMU/8000/1 a=3Drtpmap:100 X-NSE/8000/1 a=3Dfmtp:100 192-194 }} } }} =20 or 2. =09 a=3Dtgwrtp/8079 { m {=20 Local { v=3D0 o=3D- 0 0 IN IP4 - s=3D- c=3DIN IP4 210.2.12.2 t=3D0 0 m=3Daudio 16400 RTP/AVP 106 100 a=3Drtpmap:100 X-NSE/8000/1 a=3Dfmtp:100 192-194 } , Remote{ v=3D0 o=3D- 0 0 IN IP4 - s=3D- c=3DIN IP4 210.2.12.2 t=3D0 0 m=3Daudio 16400 RTP/AVP 106 100 a=3Drtpmap:106 PCMU/8000/1 a=3Drtpmap:100 X-NSE/8000/1 a=3Dfmtp:100 192-194 }} } }} =20 Regards, Prerna =09 ------_=_NextPart_001_01C800D2.72678F18 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
This is not an H.248 issue in my = understanding, this=20 relates to the "AVP Profile", thus a RFC 3550 matter (I've Cc'ed avt@ietf.org) in my=20 understandning:
 
When RTP/AVP allows to use different PT = codepoint=20 values for the same media format, then the SDP is = correct.
When RTP/AVP does not allow to use different = PT=20 codepoint values for the same media format, then the SDP is incorrect = (and the=20 MG must reply with an error code because the ADD.request was=20 incorrect).
 
-Albrecht
 
PS
Different media formats per traffic direction = is=20 possible (but this was not the question).
 
PSS
I guess that PCMU is not used as "VBD codec" = (i.e. with=20 a dynamic PT value). But if yes, then the SDP is incorrect. The SDP must = then=20 follow V.152, see "a=3D" line ...


From: Prerna Nagar = [mailto:prnagar@cisco.com]=20
Sent: Donnerstag, 27. September 2007 01:24
To:=20 megaco@ietf.org
Subject: [Megaco] Regarding different = payload types=20 in local and remotedescriptor for same codec

Hi = All,
 
Consider a case = when a Add=20 request comes to media gateway and the request looks = like:
 
Add=20 Request
{Context =3D $ { = Add =3D DS/1/1/2=20 { Media { LocalControl { Mode =3D SendReceive } } } = ,
Add =3D $ { Media = {=20 LocalControl { Mode =3D SendReceive, ReservedValue =3D OFF } = ,
Local = {
v=3D0
c=3DIN IP4=20 $
m=3Daudio $ RTP/AVP $
},Remote = {
v=3D0
o=3D- 0 0=20 IN IP4 -
s=3D-
c=3DIN IP4 210.2.12.2
t=3D0 0
m=3Daudio = 16400 RTP/AVP=20 106 100
a=3Drtpmap:106=20 PCMU/8000/1
a=3Drtpmap:100 X-NSE/8000/1
a=3Dfmtp:100 = 192-194
} }=20 } }}
 
Here =20 "CHOOSE" in Local = resolves=20 to a list of codecs = supported by=20 the gatway(PCMU will resolve to=20 0)
Next intersection of codecs = between local=20 and remote takes place.
But here in Local  PCMU has a static value "0" and = remote=20 understands "106" as PCMU (different payload = types).
 
Question is=20 : How the codec negotiation should work and how the response should = look=20 like?
 
Should it look = like=20 :
1.=20
a=3Dtgwrtp/8079  { m {=20
Local {
v=3D0
o=3D- 0 0 IN IP4 = -
s=3D-
c=3DIN=20 IP4 210.2.12.2
t=3D0 0
m=3Daudio 16400 = RTP/AVP 0=20 100
a=3Drtpmap:100 X-NSE/8000/1
a=3Dfmtp:100=20 192-194
 } ,
Remote{
v=3D0
o=3D- 0 = 0 IN IP4=20 -
s=3D-
c=3DIN IP4 210.2.12.2
t=3D0 0
m=3Daudio 16400=20 RTP/AVP 106 100
a=3Drtpmap:106=20 PCMU/8000/1
a=3Drtpmap:100 X-NSE/8000/1
a=3Dfmtp:100=20 192-194
 }}  } }}
 
or
2.
a=3Dtgwrtp/8079  { m {=20
Local {
v=3D0
o=3D- 0 0 IN IP4 = -
s=3D-
c=3DIN=20 IP4 210.2.12.2
t=3D0 0
m=3Daudio 16400 = RTP/AVP 106=20 100
a=3Drtpmap:100 X-NSE/8000/1
a=3Dfmtp:100=20 192-194
 } ,
Remote{
v=3D0
o=3D- 0 = 0 IN IP4=20 -
s=3D-
c=3DIN IP4 210.2.12.2
t=3D0 0
m=3Daudio 16400=20 RTP/AVP 106 100
a=3Drtpmap:106=20 PCMU/8000/1
a=3Drtpmap:100 X-NSE/8000/1
a=3Dfmtp:100=20 192-194
 }}  } }}
 
Regards,
Prerna

------_=_NextPart_001_01C800D2.72678F18-- --===============1341309934== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============1341309934==-- From Hoa.Henderson@lagoaemar.com.br Thu Sep 27 06:03:01 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaqCz-0000hv-Oa for megaco-archive@lists.ietf.org; Thu, 27 Sep 2007 06:03:01 -0400 Received: from [85.102.40.250] (helo=dsl85-102-10490.ttnet.net.tr) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaqCm-0002ao-Fn for megaco-archive@lists.ietf.org; Thu, 27 Sep 2007 06:02:49 -0400 Received: by 10.98.79.188 with SMTP id qTffKwvexGefF; Thu, 27 Sep 2007 13:02:43 +0300 (GMT) Received: by 192.168.120.227 with SMTP id LobVzdOidXGTaz.7714962875612; Thu, 27 Sep 2007 13:02:41 +0300 (GMT) Message-ID: <000b01c800ed$890bcc00$fa286655@akyildizbl> From: "Hoa Henderson" To: Subject: kewarmth Date: Thu, 27 Sep 2007 13:02:38 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C80106.AE590400" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 1.6 (+) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 ------=_NextPart_000_0004_01C80106.AE590400 Content-Type: text/plain; charset="iso-8859-9" Content-Transfer-Encoding: quoted-printable http://www.ghostorg.com/ Yo yo yo megaco-archive 6 out of 10 long-term relationship breakups report that sexual problems = were a major contributory factor! Hoa Henderson ------=_NextPart_000_0004_01C80106.AE590400 Content-Type: text/html; charset="iso-8859-9" Content-Transfer-Encoding: quoted-printable
http://www.ghostorg.com/
Yo yo yo megaco-archive
6 out of 10 long-term relationship breakups = report that=20 sexual problems were a major contributory factor!
Hoa Henderson
------=_NextPart_000_0004_01C80106.AE590400-- From Miriah-Oliver@daten-web.de Thu Sep 27 08:55:55 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IasuJ-0005J9-EL for megaco-archive@lists.ietf.org; Thu, 27 Sep 2007 08:55:55 -0400 Received: from [85.97.190.118] (helo=dsl.static8597190118.ttnet.net.tr) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IasuI-0007WG-NK for megaco-archive@lists.ietf.org; Thu, 27 Sep 2007 08:55:55 -0400 Received: from ebru ([183.112.153.61] helo=ebru) by dsl.static8597190118.ttnet.net.tr ( sendmail 8.13.3/8.13.1) with esmtpa id 1vndVS-000AEO-pt for megaco-archive@lists.ietf.org; Thu, 27 Sep 2007 15:56:30 +0300 Message-ID: <000d01c80105$bd1a70b0$76be6155@ebru> From: "Miriah Oliver" To: Subject: nsjongen Date: Thu, 27 Sep 2007 15:55:53 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C8011E.E267A8B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 ------=_NextPart_000_0008_01C8011E.E267A8B0 Content-Type: text/plain; charset="iso-8859-9" Content-Transfer-Encoding: quoted-printable http://www.gorasmus.com/ Morning megaco-archive Girls actually use to laugh at me! Miriah Oliver ------=_NextPart_000_0008_01C8011E.E267A8B0 Content-Type: text/html; charset="iso-8859-9" Content-Transfer-Encoding: quoted-printable
http://www.gorasmus.com/
Morning megaco-archive
Girls actually use to laugh at = me!
Miriah Oliver
------=_NextPart_000_0008_01C8011E.E267A8B0-- From megaco-bounces@ietf.org Thu Sep 27 12:02:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iavng-0006O8-FJ; Thu, 27 Sep 2007 12:01:16 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iavnf-0006IX-BN for megaco@ietf.org; Thu, 27 Sep 2007 12:01:15 -0400 Received: from prattle.redback.com ([155.53.12.9]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iavne-00062k-NB for megaco@ietf.org; Thu, 27 Sep 2007 12:01:15 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 5C0A2ADCE18; Thu, 27 Sep 2007 09:01:14 -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 06909-10; Thu, 27 Sep 2007 09:01:14 -0700 (PDT) Received: from [155.53.44.239] (cologne.redback.com [155.53.44.239]) by prattle.redback.com (Postfix) with ESMTP id 3FBC9ADCE16; Thu, 27 Sep 2007 09:01:14 -0700 (PDT) Message-ID: <46FBD3CA.20606@redback.com> Date: Thu, 27 Sep 2007 09:01:14 -0700 From: Ashish Singh User-Agent: Thunderbird 2.0.0.0 (X11/20070326) MIME-Version: 1.0 To: Prerna Nagar Subject: Re: [Megaco] Regarding different payload types in local and remote descriptor for same codec References: <004a01c80094$4f886dc0$c3d146ab@apac.cisco.com> In-Reply-To: <004a01c80094$4f886dc0$c3d146ab@apac.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Cc: megaco@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: megaco-bounces@ietf.org If gateway can support asymmetric payload type (receiving and sending media using different payload types), then option 1 seems fine. If gateway doesn't have capability to support asymmetric PT, then it should follow option 2. Gateway should not reject this call as CA has sent $. Gateway can resolve $ by its configured list of codecs, but still it can give precedence to Remote descriptor's payload type, if same codec is present in Remote desc. Afterwards, codec negotiation phase will select the PCMU with 106 as PT in both local and remote. Local desc in option2 is slightly incorrect. rtpmap attribute for 106 should also be present in local desc. Option2 should look like: a=tgwrtp/8079 { m { *Local *{ v=0 o=- 0 0 IN IP4 - s=- c=IN IP4 210.2.12.2 t=0 0 m=audio 16400 RTP/AVP *106* 100 *a=rtpmap:106 PCMU/8000/1* a=rtpmap:100 X-NSE/8000/1 a=fmtp:100 192-194 } , *Remote*{ v=0 o=- 0 0 IN IP4 - s=- c=IN IP4 210.2.12.2 t=0 0 m=audio 16400 RTP/AVP *106* 100 *a=rtpmap:106 PCMU/8000/1 *a=rtpmap:100 X-NSE/8000/1 a=fmtp:100 192-194 }} } }} Prerna Nagar wrote: > Hi All, > > Consider a case when a Add request comes to media gateway and the > request looks like: > > *Add Request* > {Context = $ { Add = DS/1/1/2 { Media { LocalControl { Mode = > SendReceive } } } , > Add = $ { Media { LocalControl { Mode = SendReceive, ReservedValue = > OFF } , > Local { > v=0 > c=IN IP4 $ > m=audio $ RTP/AVP *$* > },Remote { > v=0 > o=- 0 0 IN IP4 - > s=- > c=IN IP4 210.2.12.2 > t=0 0 > m=audio 16400 RTP/AVP *106* 100 > a=rtpmap:*106 PCMU/8000/1* > a=rtpmap:100 X-NSE/8000/1 > a=fmtp:100 192-194 > } } } }} > > Here "CHOOSE" in Local resolves to a list of codecs supported by the > gatway(PCMU will resolve to 0) > Next intersection of codecs between local and remote takes place. > But here in Local PCMU has a static value "0" and remote understands > "106" as PCMU (different payload types). > > /Question is : How the codec negotiation should work and how the > response should look like?/ > // > Should it look like : > *1.* > a=tgwrtp/8079 { m { > *Local *{ > v=0 > o=- 0 0 IN IP4 - > s=- > c=IN IP4 210.2.12.2 > t=0 0 > m=audio 16400 RTP/AVP *0* 100 > a=rtpmap:100 X-NSE/8000/1 > a=fmtp:100 192-194 > } , > *Remote*{ > v=0 > o=- 0 0 IN IP4 - > s=- > c=IN IP4 210.2.12.2 > t=0 0 > m=audio 16400 RTP/AVP *106* 100 > *a=rtpmap:106 PCMU/8000/1 > *a=rtpmap:100 X-NSE/8000/1 > a=fmtp:100 192-194 > }} } }} > > or > *2.* > a=tgwrtp/8079 { m { > *Local *{ > v=0 > o=- 0 0 IN IP4 - > s=- > c=IN IP4 210.2.12.2 > t=0 0 > m=audio 16400 RTP/AVP *106* 100 > a=rtpmap:100 X-NSE/8000/1 > a=fmtp:100 192-194 > } , > *Remote*{ > v=0 > o=- 0 0 IN IP4 - > s=- > c=IN IP4 210.2.12.2 > t=0 0 > m=audio 16400 RTP/AVP *106* 100 > *a=rtpmap:106 PCMU/8000/1 > *a=rtpmap:100 X-NSE/8000/1 > a=fmtp:100 192-194 > }} } }} > > Regards, > Prerna > ------------------------------------------------------------------------ > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From malinda.mariani@ahadirect.com Thu Sep 27 15:19:54 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iaytt-00005N-PR for megaco-archive@lists.ietf.org; Thu, 27 Sep 2007 15:19:54 -0400 Received: from [212.76.38.70] (helo=[212.76.38.70]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaytT-0003xs-26 for megaco-archive@lists.ietf.org; Thu, 27 Sep 2007 15:19:27 -0400 Received: from mama by ahadirect.com with ASMTP id 13B8DF34 for ; Thu, 27 Sep 2007 21:20:19 +0200 Received: from mama ([182.165.124.64]) by ahadirect.com with ESMTP id 511C2B7ACC6F for ; Thu, 27 Sep 2007 21:20:19 +0200 Message-ID: <000a01c8013b$6172f080$46264cd4@mama> From: "malinda mariani" To: Subject: ucidite' Date: Thu, 27 Sep 2007 21:19:52 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C8014C.24FBC080" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 4.9 (++++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0005_01C8014C.24FBC080 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable http://www.mkirs.com/ greeting megaco-archive fact: A bigger penis man gets more ladies! malinda mariani ------=_NextPart_000_0005_01C8014C.24FBC080 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
http://www.mkirs.com/
greeting megaco-archive
fact: A bigger penis man gets more = ladies!
malinda mariani
------=_NextPart_000_0005_01C8014C.24FBC080-- From promsak.sese@renee.ca Thu Sep 27 20:31:27 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ib3lP-0001fA-EI for megaco-archive@lists.ietf.org; Thu, 27 Sep 2007 20:31:27 -0400 Received: from epl242.neoplus.adsl.tpnet.pl ([83.20.53.242] helo=enz114.neoplus.adsl.tpnet.pl) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ib3l9-0006lJ-IQ for megaco-archive@lists.ietf.org; Thu, 27 Sep 2007 20:31:23 -0400 Received: from Dawid ([135.105.95.101]:26964 "EHLO Dawid" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by enz114.neoplus.adsl.tpnet.pl with ESMTP id S22XZYGBKVVXTWFR (ORCPT ); Fri, 28 Sep 2007 02:31:35 +0200 Message-ID: <000e01c80166$dd020c10$720f1453@Dawid> From: "promsak sese" To: Subject: notpyrk Date: Fri, 28 Sep 2007 02:31:08 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C80177.A08ADC10" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 4.5 (++++) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 ------=_NextPart_000_0003_01C80177.A08ADC10 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable http://www.mightyme.net/ Wazzup megaco-archive This is the website seen on the news and 60 minutes. promsak sese ------=_NextPart_000_0003_01C80177.A08ADC10 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
http://www.mightyme.net/
Wazzup megaco-archive
This is the website seen on the news and 60 = minutes.
promsak sese
------=_NextPart_000_0003_01C80177.A08ADC10-- From megaco-bounces@ietf.org Thu Sep 27 23:04:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ib67r-0002FF-My; Thu, 27 Sep 2007 23:02:47 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ib67p-0002E3-FQ for megaco@ietf.org; Thu, 27 Sep 2007 23:02:45 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ib67n-0006zO-Rx for megaco@ietf.org; Thu, 27 Sep 2007 23:02:45 -0400 X-IronPort-AV: E=Sophos;i="4.21,207,1188802800"; d="scan'208,217";a="226683363" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 27 Sep 2007 20:02:43 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l8S32hJf031633; Thu, 27 Sep 2007 20:02:43 -0700 Received: from sj-webmail-3.cisco.com (sj-webmail-3.cisco.com [171.70.156.8]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l8S32hTm001373; Fri, 28 Sep 2007 03:02:43 GMT Received: from sj-webmail-3.cisco.com (localhost.localdomain [127.0.0.1]) by sj-webmail-3.cisco.com (8.13.1/8.13.1) with ESMTP id l8S32gOn009719; Thu, 27 Sep 2007 20:02:42 -0700 Received: from sj-webmail-3 (root@localhost) by sj-webmail-3.cisco.com (8.13.1/8.13.1/Submit) with ESMTP id l8S32gdK009718; Thu, 27 Sep 2007 20:02:42 -0700 Received: from ypatharewxp01 ( [172.30.218.194]) by sj-webmail-3 (Scalix SMTP Relay 10.0.5.3) via ESMTP; Thu, 27 Sep 2007 20:02:39 -0700 (PDT) Date: Fri, 28 Sep 2007 08:37:21 +0530 From: "Yogesh" To: "'Prerna Nagar'" , Message-ID: <"25610.11321190948559.sj-webmail-3*"@MHS> In-Reply-To: <004a01c80094$4f886dc0$c3d146ab@apac.cisco.com> Subject: RE: [Megaco] Regarding different payload types in local and remote descriptor for same codec x-scalix-Hops: 1 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcgAlE9Rhaa3gfaYQPCJbTO8mGo5sQAKRx/Q MIME-Version: 1.0 DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=25633; t=1190948563; x=1191812563; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ypathare@cisco.com; z=From:=20=22Yogesh=22=20 |Subject:=20RE=3A=20[Megaco]=20Regarding=20different=20payload=20types=20 in=20local=20and=20remote=20descriptor=20for=20same=20codec |Sender:=20; bh=dMWoj0NzCwFHdYwDmYdNB9aGhOb8AduS4OxdAkvaeIc=; b=f5aQnIHohrwCSlLeADF03N6CHDmSZviFd2Vxf6QuxwZba/phOV5gaWbaSeQmI7sDPYrIqnQU hKAoxUM74a9tqzQAMntW9wRU719LSJ/BJpQDxji4kg0chEaUexDbr5+9rh23yFOcOpHQSKr/iQ zdYaX0ezdYiocp6rdzdZwPVjo=; Authentication-Results: sj-dkim-1; header.From=ypathare@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 92788d1b003e07b99aff407d30cf4598 Cc: X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1093320632==" Errors-To: megaco-bounces@ietf.org --===============1093320632== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0013_01C801AA.CC8D9CC0" ------=_NextPart_000_0013_01C801AA.CC8D9CC0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Hi Prerna, logically MG should give preference to Remote, but in most of the cases it is implementation specific. Now the question is if MG gets $ in Local, MG has to display its capabilities, if that is the case, MG should change its codec as per the remote and display it or not? if remote is present, MG should still give preference to Remote and display the capabilities accordingly, for successful negotiation. Talking about solutions you proposed, 1> In first case your negotiation will fail if Remote GW is unable to change the codec payload to 0 ( zero ) what I want to say is, your response will reach remote and now remote will see Local=106, and remote=0 so remote GW has to change its local to 0 ( zero ) for successful negotiation. ( This is nothing but Remote GW has to give preference to Remote for successful negotiation) 2> where as in second case you are giving preference to Remote and changing your Local accordingly, this looks fine as codec is negotiated as per remote payload type. 3> Third case will be change remote as per your Local and send it across for further negotiation. What I mean by this is, MG gets Local=0 (zero ) and remote = 106, MG response will be Local=zero and Remote=zero. But I dont think changing remote payload type is advisable. as I told you earlier logically preference should be given to Remote and hence, a=tgwrtp/8079 { m { Local { v=0 o=- 0 0 IN IP4 - s=- c=IN IP4 210.2.12.2 t=0 0 m=audio 16400 RTP/AVP 106 100 a=rtpmap:100 X-NSE/8000/1 a=fmtp:100 192-194 } , Remote{ v=0 o=- 0 0 IN IP4 - s=- c=IN IP4 210.2.12.2 t=0 0 m=audio 16400 RTP/AVP 106 100 a=rtpmap:106 PCMU/8000/1 a=rtpmap:100 X-NSE/8000/1 a=fmtp:100 192-194 }} } }} This looks fine to me, unless 106 is not configured for any other codec. If any one has better understanding, please suggest. Cheers !!! Yogesh Pathare Senior Engineer - Testing A R I C E N T Presidency Tower B Fourth Floor Gurgaon , India 122001 Main +91 1243911200 Ext 5512 _____ From: Prerna Nagar [mailto:prnagar@cisco.com] Sent: Thursday, September 27, 2007 4:54 AM To: megaco@ietf.org Subject: [Megaco] Regarding different payload types in local and remote descriptor for same codec Hi All, Consider a case when a Add request comes to media gateway and the request looks like: Add Request {Context = $ { Add = DS/1/1/2 { Media { LocalControl { Mode = SendReceive } } } , Add = $ { Media { LocalControl { Mode = SendReceive, ReservedValue = OFF } , Local { v=0 c=IN IP4 $ m=audio $ RTP/AVP $ },Remote { v=0 o=- 0 0 IN IP4 - s=- c=IN IP4 210.2.12.2 t=0 0 m=audio 16400 RTP/AVP 106 100 a=rtpmap:106 PCMU/8000/1 a=rtpmap:100 X-NSE/8000/1 a=fmtp:100 192-194 } } } }} Here "CHOOSE" in Local resolves to a list of codecs supported by the gatway(PCMU will resolve to 0) Next intersection of codecs between local and remote takes place. But here in Local PCMU has a static value "0" and remote understands "106" as PCMU (different payload types). Question is : How the codec negotiation should work and how the response should look like? Should it look like : 1. a=tgwrtp/8079 { m { Local { v=0 o=- 0 0 IN IP4 - s=- c=IN IP4 210.2.12.2 t=0 0 m=audio 16400 RTP/AVP 0 100 a=rtpmap:100 X-NSE/8000/1 a=fmtp:100 192-194 } , Remote{ v=0 o=- 0 0 IN IP4 - s=- c=IN IP4 210.2.12.2 t=0 0 m=audio 16400 RTP/AVP 106 100 a=rtpmap:106 PCMU/8000/1 a=rtpmap:100 X-NSE/8000/1 a=fmtp:100 192-194 }} } }} or 2. a=tgwrtp/8079 { m { Local { v=0 o=- 0 0 IN IP4 - s=- c=IN IP4 210.2.12.2 t=0 0 m=audio 16400 RTP/AVP 106 100 a=rtpmap:100 X-NSE/8000/1 a=fmtp:100 192-194 } , Remote{ v=0 o=- 0 0 IN IP4 - s=- c=IN IP4 210.2.12.2 t=0 0 m=audio 16400 RTP/AVP 106 100 a=rtpmap:106 PCMU/8000/1 a=rtpmap:100 X-NSE/8000/1 a=fmtp:100 192-194 }} } }} Regards, Prerna ------=_NextPart_000_0013_01C801AA.CC8D9CC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hi Prerna,
 
logically MG should give preference to Remote, b= ut in most=20 of the cases it is implementation specific.
 
Now the question is if MG gets $ in Local, M= G has=20 to display its capabilities,
if that is the case, MG should change its codec a= s per the=20 remote and display it or not?
 
if remote is present, MG should still give prefe= rence to=20 Remote and display the capabilities accordingly, for successful=20 negotiation.
 
Talking about solutions you proposed,
 
1> In first case your negotiation will fail i= f Remote GW=20 is unable to change the codec payload to 0 ( zero )
    what I want to say is, y= our=20 response will reach remote and now remote will see Local=3D106, and=20 remote=3D0
    so remote GW has to chan= ge its=20 local to 0 ( zero ) for successful negotiation.
    ( This is nothing but Remote G= W has to=20 give preference to Remote for successful negotiation)
=
 
2> where as in second case you are giving pre= ference to=20 Remote and changing your Local accordingly,
    this looks fine as codec= is=20 negotiated as per remote payload type.
 
3> T= hird case will=20 be change remote as per your Local and send it across for further negotia= tion.=20
     What I mean by this is,= MG=20 gets Local=3D0 (zero ) and remote =3D 106, MG response will be Local= =3Dzero and=20 Remote=3Dzero.
     But I dont think c= hanging=20 remote payload type is advisable. 
 
as I=20 told you earlier logically preference should be given to Remote and=20 hence,
 
a=3Dtgwrtp/8079 = ; { m {=20
Local {
v=3D0
o=3D- 0 0 IN IP4 -
= s=3D-
c=3DIN=20 IP4 210.2.12.2
t=3D0 0
m=3Daudio 16400 RTP/AVP 106=20 100
a=3Drtpmap:100 X-NSE/8000/1
a=3Dfmtp:100=20 192-194
 } ,
Remote{
v=3D0
o=3D- 0 0 I= N IP4=20 -
s=3D-
c=3DIN IP4 210.2.12.2
t=3D0 0
m=3Daudio 16400=20 RTP/AVP 106 100
a=3Drtpmap:1= 06=20 PCMU/8000/1
a=3Drtpmap:100 X-NSE/8000/1
a=3Dfmtp:100=20 192-194
 }}  } }}
 =
This looks fine to me, unless 106 is not configured for any othe= r=20 codec.
 
If any one has better understanding, please=20 suggest.
 
 
Cheers=20 !!!
 

Yogesh= =20 Pathare

Senior= Engineer=20 - Testing

 

A R I C E N= =20 T

 =

Presid= ency=20 Tower B

Fourth= Floor= =20

Gurgao= n ,=20 India=20 122001

Main     = +91 12= 43911200=20 Ext 5512

<= /DIV>
 


From: Prerna Nagar [mailto:prnagar@ci= sco.com]=20
Sent: Thursday, September 27, 2007 4:54 AM
To:=20 megaco@ietf.org
Subject: [Megaco] Regarding different payload t= ypes in=20 local and remote descriptor for same codec

Hi All,
 =
Consider a case when= a Add=20 request comes to media gateway and the request looks like:<= /DIV>
 =
Add=20 Request
{Context =3D $ { Add= =3D DS/1/1/2 {=20 Media { LocalControl { Mode =3D SendReceive } } } ,
Add =3D $ { Media { L= ocalControl=20 { Mode =3D SendReceive, ReservedValue =3D OFF } ,
Local {
v=3D0
= c=3DIN IP4=20 $
m=3Daudio $ RTP/AVP $
},Remote {
v=3D0<= BR>o=3D- 0 0 IN=20 IP4 -
s=3D-
c=3DIN IP4 210.2.12.2
t=3D0 0
m=3Daudio 16400 RTP= /AVP=20 106 100
a=3Drtpmap:106=20 PCMU/8000/1
a=3Drtpmap:100 X-NSE/8000/1
a=3Dfmtp:100 192-1= 94
} } }=20 }}
 =
Here  "CHOOSE"&= nbsp;in Local resolves to a list of codecs supported by the gatwa= y(PCMU will resolve to 0)<= /DIV>
Next intersection of codecs betwee= n local=20 and remote takes place.
But here in Local  PCMU has a static value "0" and re= mote=20 understands "106" as PCMU (different payload types).
 =
= Question is :=20 How the codec negotiation should work and how the response should look=20 like?
 
Should it look like=20 :
1.=20
a=3Dtgwrtp/8079 = ; { m {=20
Local {
v=3D0
o=3D- 0 0 IN IP4 -
= s=3D-
c=3DIN=20 IP4 210.2.12.2
t=3D0 0
m=3Daudio 16400 RTP/AVP 0=20 100
a=3Drtpmap:100 X-NSE/8000/1
a=3Dfmtp:100=20 192-194
 } ,
Remote{
v=3D0
o=3D- 0 0 I= N IP4=20 -
s=3D-
c=3DIN IP4 210.2.12.2
t=3D0 0
m=3Daudio 16400=20 RTP/AVP 106 100
a=3Drtpmap:1= 06=20 PCMU/8000/1
a=3Drtpmap:100 X-NSE/8000/1
a=3Dfmtp:100=20 192-194
 }}  } }}
 =
or
2.
a=3Dtgwrtp/8079 = ; { m {=20
Local {
v=3D0
o=3D- 0 0 IN IP4 -
= s=3D-
c=3DIN=20 IP4 210.2.12.2
t=3D0 0
m=3Daudio 16400 RTP/AVP 106=20 100
a=3Drtpmap:100 X-NSE/8000/1
a=3Dfmtp:100=20 192-194
 } ,
Remote{
v=3D0
o=3D- 0 0 I= N IP4=20 -
s=3D-
c=3DIN IP4 210.2.12.2
t=3D0 0
m=3Daudio 16400=20 RTP/AVP 106 100
a=3Drtpmap:1= 06=20 PCMU/8000/1
a=3Drtpmap:100 X-NSE/8000/1
a=3Dfmtp:100=20 192-194
 }}  } }}
 =
Regards,
Prerna

------=_NextPart_000_0013_01C801AA.CC8D9CC0-- --===============1093320632== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============1093320632==-- From renaf-Kostet@JAMESJONES.COM Fri Sep 28 03:24:30 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbAD8-0005Q8-Hz for megaco-archive@lists.ietf.org; Fri, 28 Sep 2007 03:24:30 -0400 Received: from host51-221-static.23-87-b.business.telecomitalia.it ([87.23.221.51]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbAD7-00050d-UZ for megaco-archive@lists.ietf.org; Fri, 28 Sep 2007 03:24:30 -0400 Received: from server ([193.139.82.114] helo=server) by [87.23.221.51] ( sendmail 8.13.3/8.13.1) with esmtpa id 1SMmOJ-000JYX-TH for megaco-archive@lists.ietf.org; Fri, 28 Sep 2007 09:24:56 +0200 Date: Fri, 28 Sep 2007 09:24:30 +0200 From: "renaf Kostet" Reply-To: "renaf Kostet" Message-ID: <371448038900.928093662857@JAMESJONES.COM> To: Subject: eipmi MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original X-Spam-Score: 3.9 (+++) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Mining Sector --- Delta Mining UPDATE HOT SECTOR: Additional information on (O_T_C: D M X C) D M X C is expected to arrive soon. For those of you who currently own this company this will be great news. For those that don't currently own this company, you need to get in on this now. The company recently traded as high as .13 and with any significant news should be able to see (if not exceed) those prices again. Contact your broker now, don't miss this opportunity in D M X C! From hillery.jerousek@winexplorer.net Fri Sep 28 07:56:30 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbESM-0007DT-BR for megaco-archive@lists.ietf.org; Fri, 28 Sep 2007 07:56:30 -0400 Received: from j47248.upc-j.chello.nl ([24.132.47.248]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbESG-0003wW-Qr for megaco-archive@lists.ietf.org; Fri, 28 Sep 2007 07:56:25 -0400 Received: from thuis ([164.107.80.189] helo=thuis) by j47248.upc-j.chello.nl ( sendmail 8.13.3/8.13.1) with esmtpa id 1OhOPC-000LBF-tK for megaco-archive@lists.ietf.org; Fri, 28 Sep 2007 13:54:23 +0200 Message-ID: <31B2F134.36B3F3EF@winexplorer.net> Date: Fri, 28 Sep 2007 13:54:10 +0200 From: "hillery jerousek" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: megaco-archive@lists.ietf.org Subject: regulkre Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 3.7 (+++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Compliments megaco-archive 1 inch, 2 inch, 3 inch, its upto you how big you want to go hillery jerousek http://chbit.com/ From c21pata@richdevelopment.com Fri Sep 28 17:57:04 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbNpY-000630-1b for megaco-archive@lists.ietf.org; Fri, 28 Sep 2007 17:57:04 -0400 Received: from [89.122.201.16] (helo=nmas) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IbNpU-0007AP-Ki for megaco-archive@lists.ietf.org; Fri, 28 Sep 2007 17:57:02 -0400 Received: from [207.122.201.26] (helo=czab) by nmas with smtp (Exim 4.62 (FreeBSD)) id 1J@2j-0005gP-Ab; Sat, 29 Sep 2007 00:59:19 +0300 Message-ID: <002e01c8021a$78e332e0$1ac97acf@czab> From: To: Subject: Take ten min out to play a game today. Date: Sat, 29 Sep 2007 00:56:50 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="windows-1250"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Spam-Score: 2.2 (++) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 Check out Arcade World, with 100's of free games. http://208.115.206.225/ From rayfieldnittala@cgi4me.de Sat Sep 29 05:36:46 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbYkg-0004R2-CJ for megaco-archive@lists.ietf.org; Sat, 29 Sep 2007 05:36:46 -0400 Received: from adsl205-17.aknet.it ([194.242.205.17]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbYkb-00074U-4N for megaco-archive@lists.ietf.org; Sat, 29 Sep 2007 05:36:42 -0400 Received: from minifabbris ([142.112.4.169]:11522 "EHLO minifabbris" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by adsl205-17.aknet.it with ESMTP id S22OPLEJTXVATQXA (ORCPT ); Sat, 29 Sep 2007 11:37:10 +0200 Message-ID: <7C39C3EB.9C573A0A@cgi4me.de> Date: Sat, 29 Sep 2007 11:36:34 +0200 From: "rayfield nittala" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: megaco-archive@lists.ietf.org Subject: knuptiez Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.6 (+) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Hi To megaco-archive Emergency report. Check DMXC! Price up 21% in 30 minutes! 5 day price: ~$0.50 From Devraj.giegerich@lesloupsbleus.com Sat Sep 29 05:48:40 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbYwC-0000pd-Fz for megaco-archive@lists.ietf.org; Sat, 29 Sep 2007 05:48:40 -0400 Received: from bho247.neoplus.adsl.tpnet.pl ([83.28.104.247] helo=[83.28.87.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IbYw6-0004U9-RK for megaco-archive@lists.ietf.org; Sat, 29 Sep 2007 05:48:36 -0400 Received: by 10.158.99.22 with SMTP id qTUSNexsAdcqa; Sat, 29 Sep 2007 11:50:23 +0200 (GMT) Received: by 192.168.87.87 with SMTP id HKMRvUDsdFkafC.5267942156264; Sat, 29 Sep 2007 11:50:21 +0200 (GMT) Message-ID: <000c01c8027e$24d5b7e0$a5571c53@dom34796c43233> From: "Devraj giegerich" To: Subject: yawnproo Date: Sat, 29 Sep 2007 11:50:18 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C8028E.E85E87E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 3.5 (+++) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a ------=_NextPart_000_0009_01C8028E.E85E87E0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Hi To megaco-archive Emergency report. Check DMXC! Price up 21% in 30 minutes! 5 day price: ~$0.50 ------=_NextPart_000_0009_01C8028E.E85E87E0 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
Hi To megaco-archive
Emergency report. Check DMXC!
Price up 21% in 30 minutes!
5 day price: ~$0.50
------=_NextPart_000_0009_01C8028E.E85E87E0-- From Teng@caifuc.cl Sat Sep 29 13:40:12 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbgIW-0007MR-64 for megaco-archive@lists.ietf.org; Sat, 29 Sep 2007 13:40:12 -0400 Received: from dpn243.neoplus.adsl.tpnet.pl ([83.24.147.243] helo=[83.24.164.195]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbgIS-0003Vq-8b for megaco-archive@lists.ietf.org; Sat, 29 Sep 2007 13:40:08 -0400 Received: by 10.124.44.22 with SMTP id KVjOPTHTcuDWB; Sat, 29 Sep 2007 19:39:55 +0200 (GMT) Received: by 192.168.50.69 with SMTP id iCnzrBFiAXpYhC.0506129368908; Sat, 29 Sep 2007 19:39:53 +0200 (GMT) Message-ID: <000301c802bf$bc8d8720$c3a41853@armatyskivqh8e> From: "Teng gildersleeve" To: Subject: 2601794 Date: Sat, 29 Sep 2007 19:39:50 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C802D0.80165720" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 1.8 (+) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 ------=_NextPart_000_0004_01C802D0.80165720 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Hi megaco-archive Emergency report. Check DMXC! 5 day price: ~$0.50 ------=_NextPart_000_0004_01C802D0.80165720 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
Hi megaco-archive
Emergency report. Check DMXC!
5 day price: ~$0.50
------=_NextPart_000_0004_01C802D0.80165720-- From EMRE-Shapiro@cincsolutions.com Sun Sep 30 05:41:16 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbvIa-0006VQ-Q0 for megaco-archive@lists.ietf.org; Sun, 30 Sep 2007 05:41:16 -0400 Received: from cpc1-shep2-0-0-cust224.lei3.cable.ntl.com ([81.110.76.225]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbvIY-00057m-3s for megaco-archive@lists.ietf.org; Sun, 30 Sep 2007 05:41:14 -0400 Received: from home-845770bb0a ([143.162.23.162] helo=home-845770bb0a) by cpc1-shep2-0-0-cust224.lei3.cable.ntl.com ( sendmail 8.13.3/8.13.1) with esmtpa id 1Bphdg-000LSO-NM for megaco-archive@lists.ietf.org; Sun, 30 Sep 2007 10:41:40 +0100 Message-ID: <000401c80346$0a115040$e14c6e51@home845770bb0a> From: "EMRE Shapiro" To: Subject: okgnobob Date: Sun, 30 Sep 2007 10:41:13 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C8034E.6BD5B840" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 4.4 (++++) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 ------=_NextPart_000_0004_01C8034E.6BD5B840 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello megaco-archive Urgent alert. Look at DM XC! 5-day price: ~$0.50 Get it at monday ol-ecnad okuuynik ologiana olkimajo ------=_NextPart_000_0004_01C8034E.6BD5B840 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello megaco-archive
Urgent alert.
Look at DM XC!
5-day price: ~$0.50
Get it at monday
ol-ecnad
okuuynik
ologiana
olkimajo
------=_NextPart_000_0004_01C8034E.6BD5B840-- From Persa@npdhomes.com Sun Sep 30 07:14:45 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ibwl3-0001J3-Pz for megaco-archive@lists.ietf.org; Sun, 30 Sep 2007 07:14:45 -0400 Received: from e179134181.adsl.alicedsl.de ([85.179.134.181] helo=[85.179.129.68]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ibwl3-0000KJ-9r for megaco-archive@lists.ietf.org; Sun, 30 Sep 2007 07:14:45 -0400 Received: from your-kwungnzgrf ([142.183.37.178] helo=your-kwungnzgrf) by [85.179.129.68] ( sendmail 8.13.3/8.13.1) with esmtpa id 1ZBpfV-000IRU-eG for megaco-archive@lists.ietf.org; Sun, 30 Sep 2007 13:14:54 +0200 Date: Sun, 30 Sep 2007 13:14:44 +0200 From: "darline Persa" Reply-To: "darline Persa" Message-ID: <484715412601.937514967581@npdhomes.com> To: Subject: arecroma MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original X-Spam-Score: 3.9 (+++) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Good day megaco-archive Alert to all investors! Look at D-M-X-C! 5-day price: ~$0.50 Check it at 31.09.2007 arefilor arihsak argarito arleston From Belina@usa.name Sun Sep 30 08:08:03 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ibxad-00078W-OK for megaco-archive@lists.ietf.org; Sun, 30 Sep 2007 08:08:03 -0400 Received: from chello087207184190.chello.pl ([87.207.184.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IbxaU-0001Jw-Tb for megaco-archive@lists.ietf.org; Sun, 30 Sep 2007 08:08:01 -0400 Received: from dom-48fd29208a0 by usa.name with ASMTP id AF5554A2 for ; Sun, 30 Sep 2007 14:08:25 +0200 Received: from dom-48fd29208a0 ([128.192.193.151]) by usa.name with ESMTP id 78F09E89C14E for ; Sun, 30 Sep 2007 14:08:25 +0200 Message-ID: <000701c8035a$86880420$beb8cf57@dom48fd29208a0> From: "Belina Jarreau" To: megaco-archive@lists.ietf.org Subject: rhododen Date: Sun, 30 Sep 2007 14:07:51 +0200 Message-ID: <000701c8035a$86880420$beb8cf57@dom48fd29208a0> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 3.1 (+++) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Good day megaco-archive Alert to all investors! Look at D-M-X-C! 5-day price: ~$0.50 Check it at 31.09.2007 revebnon r`et^uov rfigsten rgelboek From nunzio.Malbon@jsalimi.com Sun Sep 30 08:32:38 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbxyQ-0005V1-RA for megaco-archive@lists.ietf.org; Sun, 30 Sep 2007 08:32:38 -0400 Received: from atoulon-256-1-29-102.w86-216.abo.wanadoo.fr ([86.216.224.102] helo=[90.14.36.43]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbxyQ-0002iO-8S for megaco-archive@lists.ietf.org; Sun, 30 Sep 2007 08:32:38 -0400 Received: from nom-0jyrseoy3so by jsalimi.com with ASMTP id AC49D3E9 for ; Sun, 30 Sep 2007 14:33:00 +0200 Received: from nom-0jyrseoy3so ([109.146.17.27]) by jsalimi.com with ESMTP id 91E52378F36F for ; Sun, 30 Sep 2007 14:33:00 +0200 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 30 Sep 2007 14:32:36 +0200 To: megaco-archive@lists.ietf.org From: "nunzio Malbon" Subject: ylirotca Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Good day megaco-archive Alert to all investors! Look at D-M-X-C! 5-day price: ~$0.50 Check it at 31.09.2007 yhdistms ylgnitou ylihsa ylimoh