From owner-megaco@fore.com Fri Jun 1 00:44:20 2001 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA16612 for ; Fri, 1 Jun 2001 00:44:20 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id AAA08817; Fri, 1 Jun 2001 00:36:51 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id AAA09570 for megaco-list; Fri, 1 Jun 2001 00:29:41 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id AAA09557 for ; Fri, 1 Jun 2001 00:29:39 -0400 (EDT) Received: from brahma01.netbrahma.com ([164.164.70.67]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id AAA08595 for ; Fri, 1 Jun 2001 00:29:22 -0400 (EDT) Received: from ATANU ([172.16.72.98]) by brahma01.netbrahma.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LQ032TA1; Fri, 1 Jun 2001 09:58:41 +0530 Message-ID: <009701c0ea54$765be420$624810ac@netbrahma.com> Reply-To: "Atanum" From: "Atanum" To: Cc: "Madhu Babu Brahmanapally" , "Rosen, Brian" Subject: Re-transmission of messages...... Date: Fri, 1 Jun 2001 10:06:29 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0092_01C0EA82.86E77E20" 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 Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0092_01C0EA82.86E77E20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I have some doubt regarding the re-transmission of messages.... If I understand correctly.. the transactions inside a megaco message are = treated seperately and reply and reply-acknowledgement are send seperately for each transactions(reply-acknowledgement can be = sent for a series in one shot).=20 My question is that whether a timer is to be maintained for each = seperate transactions ? If that is so then if reply comes for some transaction in a message and = for the other if the timer times out, then whether the transaction for which the timer timed out will be again formed into seperate message = and sent....and if that be so, then whether the message header remains same as before... I will be thankful if somebody please answer this query of mine Regards Atanu Mondal Net Brahma Technologies Internext Networking Software A Microland Group Venture atanum@netbrahma.com www.netbrahma.com Tel : 91.80. 552 1451 Fax : 91.80. 553 7233 ------=_NextPart_000_0092_01C0EA82.86E77E20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
I have some doubt regarding the = re-transmission of=20 messages....
If I understand correctly.. the = transactions inside=20 a megaco message are treated seperately and reply and=20 reply-acknowledgement
are send seperately for each=20 transactions(reply-acknowledgement can be sent for a series in one = shot).=20
 
My question is that whether a timer is = to be=20 maintained for each seperate transactions ?
 
If that is so then if reply comes for = some=20 transaction in a message and for the other if the timer times out, then = whether=20 the transaction
for which the timer timed out will be = again formed=20 into seperate message and sent....and if that be so, then whether the = message=20 header remains
same as before...
 
I will be thankful if somebody please = answer this=20 query of mine
 
Regards
Atanu Mondal
Net Brahma=20 Technologies
Internext Networking Software
A Microland Group = Venture
atanum@netbrahma.com
www.netbrahma.com
Tel : 91.80. = 552=20 1451
Fax : 91.80. 553 7233
------=_NextPart_000_0092_01C0EA82.86E77E20-- From owner-megaco@fore.com Fri Jun 1 06:11:03 2001 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA03553 for ; Fri, 1 Jun 2001 06:11:03 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id FAA16946; Fri, 1 Jun 2001 05:58:52 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id FAA01522 for megaco-list; Fri, 1 Jun 2001 05:50:52 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id FAA01518 for ; Fri, 1 Jun 2001 05:50:50 -0400 (EDT) From: Stealth24@libero.it Received: from mars. ([210.109.226.220]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with SMTP id FAA16576 for ; Fri, 1 Jun 2001 05:50:45 -0400 (EDT) Received: from lovesence.co.kr by mars. (SMI-8.6/SMI-SVR4) id SAA02064; Sat, 1 Jun 1996 18:49:28 +0900 Message-Id: <199606010949.SAA02064@mars.> To: Subject: Stealth Mass Mailer, 10 Million Email Addresses & More.. 13871 Date: Fri, 01 Jun 2001 02:51:04 -0700 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal Reply-To: Stealth24@libero.it Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: quoted-printable
Email advertising WORKS!
Email Advertise your product or website to millions for only $99.

For $99.00 you will receive the Stealth Bulk Mailing Software,
List Manager, Over 10 Million E-Mail Addresses, Targeted Email
Address Harvesting Software, and as a FREE BONUS, a special Mail
Server to send your mail through!

Its only $99 for everything, and you can download it all, today!

FOR MORE INFO:
Simply REPLY to this Email, with "99" in the "SUBJECT" Line.

To be PERMANENTLY REMOVED from our mail list, YOU MUST SIMPLY
REPLY, with "REMOVE" in the --> "SUBJECT" Line!


 From owner-megaco@fore.com Fri Jun 1 07:38:36 2001 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA05084 for ; Fri, 1 Jun 2001 07:38:36 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id HAA19036; Fri, 1 Jun 2001 07:02:11 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id GAA07665 for megaco-list; Fri, 1 Jun 2001 06:55:58 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id GAA07655 for ; Fri, 1 Jun 2001 06:55:56 -0400 (EDT) Received: from zcars0m9.ca.nortel.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id GAA18753 for ; Fri, 1 Jun 2001 06:55:53 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f51AtkE12731 for ; Fri, 1 Jun 2001 06:55:46 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Fri, 1 Jun 2001 06:55:47 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 1 Jun 2001 06:55:52 -0400 Message-ID: <28560036253BD41191A10000F8BCBD110250CC1E@zcard00g.ca.nortel.com> From: "Tom-PT Taylor" To: "'Atanum'" , "'megaco'" Subject: RE: Re-transmission of messages...... Date: Fri, 1 Jun 2001 06:55:50 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) X-Orig: Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Each message header is formed independently, regardless of the contents. -----Original Message----- From: Atanum [mailto:atanum@netbrahma.com] Sent: Friday, June 01, 2001 12:36 AM To: megaco Cc: Madhu Babu Brahmanapally; Rosen, Brian Subject: Re-transmission of messages...... Hi, I have some doubt regarding the re-transmission of messages.... If I understand correctly.. the transactions inside a megaco message are treated seperately and reply and reply-acknowledgement are send seperately for each transactions(reply-acknowledgement can be sent for a series in one shot). My question is that whether a timer is to be maintained for each seperate transactions ? If that is so then if reply comes for some transaction in a message and for the other if the timer times out, then whether the transaction for which the timer timed out will be again formed into seperate message and sent....and if that be so, then whether the message header remains same as before... I will be thankful if somebody please answer this query of mine Regards Atanu Mondal Net Brahma Technologies Internext Networking Software A Microland Group Venture atanum@netbrahma.com www.netbrahma.com Tel : 91.80. 552 1451 Fax : 91.80. 553 7233 From owner-megaco@fore.com Fri Jun 1 09:13:13 2001 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA07558 for ; Fri, 1 Jun 2001 09:13:12 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA28796; Fri, 1 Jun 2001 08:44:01 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id IAA22957 for megaco-list; Fri, 1 Jun 2001 08:37:52 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA22944 for ; Fri, 1 Jun 2001 08:37:50 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Fri, 1 Jun 2001 08:37:49 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF044654E6@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Atanum'" , "'megaco'" Subject: RE: Re-transmission of messages...... Date: Fri, 1 Jun 2001 08:37:48 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk And each transaction has a separate timer. Brian > -----Original Message----- > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] > Sent: Friday, June 01, 2001 6:56 AM > To: 'Atanum'; 'megaco' > Subject: RE: Re-transmission of messages...... > > > Each message header is formed independently, regardless of > the contents. > > -----Original Message----- > From: Atanum [mailto:atanum@netbrahma.com] > Sent: Friday, June 01, 2001 12:36 AM > To: megaco > Cc: Madhu Babu Brahmanapally; Rosen, Brian > Subject: Re-transmission of messages...... > > > Hi, > I have some doubt regarding the re-transmission of messages.... > If I understand correctly.. the transactions inside a megaco > message are > treated seperately and reply and reply-acknowledgement > are send seperately for each > transactions(reply-acknowledgement can be sent > for a series in one shot). > > My question is that whether a timer is to be maintained for > each seperate > transactions ? > > If that is so then if reply comes for some transaction in a > message and for > the other if the timer times out, then whether the transaction > for which the timer timed out will be again formed into > seperate message and > sent....and if that be so, then whether the message header remains > same as before... > > I will be thankful if somebody please answer this query of mine > > Regards > Atanu Mondal > Net Brahma Technologies > Internext Networking Software > A Microland Group Venture > atanum@netbrahma.com > www.netbrahma.com > Tel : 91.80. 552 1451 > Fax : 91.80. 553 7233 > From owner-megaco@fore.com Fri Jun 1 11:53:49 2001 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10506 for ; Fri, 1 Jun 2001 11:53:48 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA15826; Fri, 1 Jun 2001 11:34:10 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id LAA04853 for megaco-list; Fri, 1 Jun 2001 11:23:57 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA04848 for ; Fri, 1 Jun 2001 11:23:55 -0400 (EDT) Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA14956 for ; Fri, 1 Jun 2001 11:23:46 -0400 (EDT) Received: from ihemail1.firewall.lucent.com (localhost [127.0.0.1]) by ihemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f51FNgj25998 for ; Fri, 1 Jun 2001 11:23:42 -0400 (EDT) Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3]) by ihemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f51FNg625985 for ; Fri, 1 Jun 2001 11:23:42 -0400 (EDT) Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id LAA08967; Fri, 1 Jun 2001 11:23:40 -0400 (EDT) Received: from lucent.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id LAA08963; Fri, 1 Jun 2001 11:23:37 -0400 (EDT) Message-ID: <3B17B302.672B55CB@lucent.com> Date: Fri, 01 Jun 2001 11:21:38 -0400 From: Troy Cauble Reply-To: Troy Cauble X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Megaco Mailing List (E-mail)" Subject: Re: ABNF Question: digit maps embedded in events References: <28560036253BD41191A10000F8BCBD110250CC06@zcard00g.ca.nortel.com> <3B168A5E.C71F6FA2@ericsson.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: 7bit Just curious, but why doesn't this get squashed for being an unnecessary change? Nothing's broken except the symmetry. More useful changes have been delayed to v2. Please treat this as a question, not a complaint! Christian, Tom, Brian, et. al. are doing a great job. -troy Christian Groves wrote: > > Just in time. I'll add it to the implementors' guide. > > Christian > > Tom-PT Taylor wrote: > > > > Yes, and I suspect I'm the guilty typist. > > > > > -----Original Message----- > > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > Sent: Wednesday, May 30, 2001 3:44 PM > > > To: 'Steven Weisz'; Megaco Mailing List (E-mail) > > > Cc: Taylor, Tom-PT [NORSE:B881:EXCH] > > > Subject: RE: ABNF Question: digit maps embedded in events > > > > > > > > > I usually defer to Tom on any digitMap questions. > > > I can't tell you how many hours I (and several others > > > including Abdullah Rayhan) spent pouring over the > > > ABNF to ferret out such problems. > > > > > > Yes, I agree, it should be > > > digitMap={... > > > and not > > > digitMap{... > > > > > > I think this qualifies as a typo and deserves an IG entry. > > > Tom, do you agree? > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: Steven Weisz [mailto:sweisz@mediatrix.com] > > > > Sent: Wednesday, May 30, 2001 3:08 PM > > > > To: Megaco Mailing List (E-mail) > > > > Subject: ABNF Question: digit maps embedded in events > > > > > > > > > > > > Hi List, > > > > > > > > I asked this question a few weeks ago and still have not > > > > found an answer. > > > > Does anyone have an opinion? > > > > > > > > It is a quick question concerning a digit map embedded in a > > > > requested event. > > > > Specifically, if you look at the ABNF the embedded digit map > > > > is defined as > > > > > > > > eventDM = DigitMapToken (( EQUAL digitMapName ) / (LBRKT > > > digitMapValue > > > > RBRKT)) > > > > > > > > and a digit map descriptor is defined as: > > > > > > > > digitMapDescriptor = DigitMapToken EQUAL (( LBRKT > > > > digitMapValue RBRKT ) / > > > > ( digitMapName [LBRKT digitMapValue RBRKT] )) > > > > > > > > > > It obvious that they are very similar, as I believe was > > > > intended but there > > > > is one thing that is bothering me in eventDM. That is it > > > > seems to me that > > > > the EQUAL should be right after DigitMapToken as is the case in > > > > digitMapDescriptor. So we would instead have: > > > > > > > > eventDM = DigitMapToken EQUAL (( digitMapName ) / (LBRKT > > > digitMapValue > > > > RBRKT)) > > > > > > > > Does this make sense? > > > > > > > > Thanks, > > > > > > > > Steve > > > > > > > From owner-megaco@fore.com Fri Jun 1 12:13:00 2001 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10980 for ; Fri, 1 Jun 2001 12:13:00 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA17473; Fri, 1 Jun 2001 11:53:02 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id LAA10881 for megaco-list; Fri, 1 Jun 2001 11:49:34 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA10873 for ; Fri, 1 Jun 2001 11:49:32 -0400 (EDT) Received: from sm10.texas.rr.com (sm10.texas.rr.com [24.93.35.222]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA17148 for ; Fri, 1 Jun 2001 11:49:23 -0400 (EDT) Received: from plong (cs666831-163.austin.rr.com [66.68.31.163]) by sm10.texas.rr.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f51FnBu3009046 for ; Fri, 1 Jun 2001 10:49:13 -0500 From: "Paul Long" To: "Megaco Mailing List \(E-mail\)" Subject: RE: ABNF Question: digit maps embedded in events Date: Fri, 1 Jun 2001 10:49:14 -0500 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal In-Reply-To: <3B17B302.672B55CB@lucent.com> Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: 7bit Yeah, what are the criteria for what gets changed in v1 and what gets put off to v2? Also, when is v1 officially "done" and can no longer be changed? Like Troy, I'm not complaining--I really want to know. As you can tell from my earlier response to Steve's query, I thought it was already too late to change v1. Paul Long ipDialog, Inc. -----Original Message----- From: owner-megaco@pit.comms.marconi.com [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Troy Cauble Sent: Friday, June 01, 2001 10:22 AM To: Megaco Mailing List (E-mail) Subject: Re: ABNF Question: digit maps embedded in events Just curious, but why doesn't this get squashed for being an unnecessary change? Nothing's broken except the symmetry. More useful changes have been delayed to v2. Please treat this as a question, not a complaint! Christian, Tom, Brian, et. al. are doing a great job. -troy From owner-megaco@fore.com Fri Jun 1 12:55:43 2001 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12373 for ; Fri, 1 Jun 2001 12:55:42 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA21220; Fri, 1 Jun 2001 12:45:33 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id MAA21644 for megaco-list; Fri, 1 Jun 2001 12:44:37 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA21630; Fri, 1 Jun 2001 12:44:35 -0400 (EDT) From: direct@courses2careers.com Received: from courses2careers.com ([202.181.76.100]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with SMTP id MAA21084; Fri, 1 Jun 2001 12:44:26 -0400 (EDT) Subject: Keep 100% of the revenue your generate! Date: Sat, 2 Jun 2001 00:41:02 Message-Id: <275.700577.701457@courses2careers.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Dear Friend, AS SEEN ON NATIONAL TV : ''Making over half million dollars every 4 to 5 months from your home for an investment of only $25 US Dollars expense one time'' THANKS TO THE COMPUTER AGE AND THE INTERNET! ================================================= BE A MILLIONAIRE LIKE OTHERS WITHIN A YEAR!!! Before you say ''Bull'', please read the following. This is the letter you have been hearing about on the news lately. Due to the popularity of this letter on the Internet, a national weekly news program recently devoted an entire show to the investigation of this program described below, to see if it really can make people money. The show also investigated whether or not the program was legal. Their findings proved once and for all that there are ''absolutely NO laws prohibiting the participation in the program and if people can follow the simple instructions, they are bound to make some mega bucks with only $25 out of pocket cost''. DUE TO THE RECENT INCREASE OF POPULARITY & RESPECT THIS PROGRAM HAS ATTAINED, IT IS CURRENTLY WORKING BETTER THAN EVER. This is what one had to say: ''Thanks to this profitable opportunity. I was approached many times before but each time I passed on it. I am so glad I finally joined just to see what one could expect in return for the minimal effort and money required. To my astonishment, I received total $ 610,470.00 in 21 weeks, with money still coming in''. Pam Hedland, Fort Lee, New Jersey. ------------------------------------------------------------------------- Here is another testimonial: ''This program has been around for a long time but I never believed in it. But one day when I received this again in the mail I decided to gamble my $25 on it. I followed the simple instructions and voila' - 3 weeks later the money started to come in. First month I only made $240.00 but the next 2 months after that I made a total of $290,000.00. So far, in the past 8 months by re-entering the program, I have made over $710,000.00 and I am playing it again. The key to success in this program is to follow the simple steps and NOT change anything'' More testimonials later but first, ****PRINT THIS NOW FOR YOUR FUTURE REFERENCE**** $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ If you would like to make at least $500,000 every 4 to 5 months easily and comfortably, please read the following...THEN READ IT AGAIN and AGAIN!!! $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ FOLLOW THE SIMPLE INSTRUCTION BELOW AND YOUR FINANCIAL DREAMS WILL COME TRUE, GUARANTEED! INSTRUCTIONS: ****Order all 5 reports shown on the list below. ****For each report, send $5 CASH, THE NAME & NUMBER OF THE REPORT YOU ARE ORDERING and YOUR E-MAIL ADDRESS to the person whose name appears ON THAT LIST next to the report. MAKE SURE YOUR RETURN ADDRESS IS ON YOUR ENVELOPE TOP LEFT CORNER in case of any mail problems. ****When you place your order, make sure you order each of the 5 reports. You will need all 5 reports so that you can save them on your computer and resell them. YOUR TOTAL COST $5 X 5 = $25.00. ****You will receive, vie e-mail, each of the 5 reports from these 5 different individuals. Save them on your computer so they will be accessible for you to send to the 1,000's of people who will order them from you. Also make a floppy of these reports and keep it on your desk in case something happen to your computer. ****IMPORTANT __ DO NOT alter the names of the people who are listed next to each report, or their sequence on the list, in any way other than what is instructed below in step '' 1 through 6 '' or you will loose out on majority of your profits. Once you understand the way this works, you will also see how it does not work if you change it. Remember, this method has been tested, and if you alter, it will NOT work!!! People have tried to put their friends/relatives names on all five thinking they could get all the money. But it does not work this way. Believe us, we all have tried to be greedy and then nothing happened. So Do Not try to change anything other than what is instructed. Because if you do, it will not work for you. Remember, honesty reaps the reward!!! 1....After you have ordered all 5 reports, take this advertisement and REMOVE the name & address of the person in REPORT #5. This person has made it through the cycle and is no doubt counting their fortune. 2....Move the name & address in REPORT #4 down TO REPORT #5. 3....Move the name & address in REPORT #3 down TO REPORT #4. 4....Move the name & address in REPORT #2 down TO REPORT #3. 5....Move the name & address in REPORT #1 down TO REPORT #2 6....Insert YOUR name & address in the REPORT #1 Position. PLEASE MAKE SURE you copy every name & address ACCURATELY! ================================================= ****Take this entire letter, with the modified list of names, and save it on your computer. DO NOT MAKE ANY OTHER CHANGES. Save this on a disk as well just in case if you loose any data. ****To assist you with marketing your business on the Internet, the 5 reports you purchase will provide you with invaluable marketing information which includes how to send bulk e-mails legally, where to find thousands of free classified ads and much more. There are 2 Primary methods to get this venture going: METHOD #1 : BY SENDING BULK E-MAIL LEGALLY ================================================= Let's say that you decide to start small, just to see how it goes, and we will assume You and those involved send out only 5,000 e-mails each. Let's also assume that the mailing receive only a 0.2% response (the response could be much better but lets just say it is only 0.2% . Also many people will send out hundreds of thousands e-mails instead of only 5,000 each). Continuing with this example, you send out only 5,000 e-mails. With a 0.2% response, that is only 10 orders for report # 1.Those 10 people responded by sending out 5,000 e-mail each for a total of 50,000. Out of those 50,000 e-mails only 0.2% responded with orders. That's = 100 people responded and ordered Report # 2. Those 100 people mail out 5,000 e-mails each for a total of 500,000 e-mails. The 0.2% response to that is 1000 orders for Report # 3. Those 1000 people send out 5,000 e-mails each for a total of 5 million e-mails sent out. The 0.2% response to that is 10,000 orders for Report # 4. Those 10,000 people send out 5,000 e-mails each for a total of 50,000,000 (50 million) e-mails. The 0.2% response to that is 100,000 orders for Report #5 THAT'S 100,000 ORDERS TIMES $5 EACH = $500,000.00 (half million). Your total income in this example is: 1..... $50 + 2..... $500 + 3..... $5,000 + 4..... $50,000 + 5..... $500,000 ......... Grand Total = $555,550.00 NUMBERS DO NOT LIE. GET A PENCIL & PAPER AND FIGURE OUT THE WORST POSSIBLE RESPONSES AND NO MATTER HOW YOU CALCULATE IT, YOU WILL STILL MAKE A LOT OF MONEY! -------------------------------------------------------------------------- REMEMBER FRIEND, THIS IS ASSUMING ONLY 10 PEOPLE ORDERING OUT OF 5,000 YOU MAILED TO. Dare to think for a moment what would happen if everyone, or half or even one 4th of those people mailed 100,000 e-mails each or more? There are over 150 million people on the Internet worldwide and counting. Believe me, any people will do just that, and more! METHOD #2 : BY PLACING FREE ADS ON THE INTERNET ================================================= Advertising on the net is very very inexpensive and there are hundreds of FREE places to advertise. Placing a lot of free ads on the Internet will easily get a larger response. We strongly suggest you start with method #1 and add METHOD #2 as you go along. For every $5 you receive, all you must do is e-mail them the Report they ordered. That's it . Always provide same day service on all orders. This will guarantee that the e-mail they send out, with your name and address on it, will be prompt because they can not advertise until they receive the report. _________________AVAILABLE REPORTS__________________ ORDER EACH REPORT BY ITS NUMBER & NAME ONLY. Notes: Always send $5 cash (US CURRENCY) for each Report. Checks NOT accepted. Make sure the cash is concealed by wrapping it in at least 2 sheets of paper. _________________________________________________________ *PLEASE USE THIS REPORT ORDER FORM FOR EACH REPORT* START OF REPORT ORDER FORM COPY FROM HERE TO WHERE IT SAYS "END OF REPORT ORDER FORM" BELOW-------Copy & Paste this form to your word processor 5 times, then fill out & send for each report ---------------- Ordering Report Name & Number : My E-mail Address : My Name & Mailing Address : REMEMBER WITHOUT AN E-MAIL ADDRESS THE ORDERS CAN NOT BE PROCESSED!! ****************************************************** WHEN COPYING DONT CHANGE ANY OF THE DETAILS BELOW THIS LINE. JUST ENTER THE RELEVANT REPORT YOU ARE ORDERING IN THE SPACES ABOVE AND COPY THE LIST BELOW UNCHANGED. PLACE YOUR ORDER FOR THESE REPORTS NOW : ================================================= REPORT #1 ''The Insider's Guide to Advertising for Free on the Net'' Order Report #1 from: Stanley Davidson Box 1082 Nedlands 6909 Australia ______________________________________________________ REPORT #2 ''The Insider's Guide to Sending Bulk e-mail on the Net'' Order Report #2 from : Tom Sutton 42 Charles Kurz Drive Worongary 4213 Queensland Australia ______________________________________________________ REPORT #3 ''The Secret to Multilevel marketing on the net'' Order Report #3 from: Dianne Wells PO Box 609 Kingscote 5223 South Australia ______________________________________________________ REPORT #4 ''How to become a millionaire utilizing MLM & the Net'' Order Report #4 from: Frank Stewart 10 Mcatuur Street Cottesloe Perth, Western Australia. ______________________________________________________ REPORT #5 ''HOW TO SEND 1 MILLION E-MAILS FOR FREE'' Order Report #5 from: Nancy Yager 19 C Crownview Terraace Hamburg, New York 14075 USA **************************************************** COPY TO HERE FOR THE FULL ORDER FORM *****END OF REPORT ORDER FORM**** **************************************************** $$$$$$$$$$$$ YOUR SUCCESS GUIDELINES $$$$$$$$$$$$$ Follow these guidelines to guarantee your success: ***If you do not receive at least 10 orders for Report #1 within 2 weeks, continue sending e-mails until you do. ***After you have received 10 orders, 2 to 3 weeks after that you should receive 100 orders or more for REPORT #2. If you did not, continue advertising or sending e-mails until you do. ***Once you have received 100 or more orders for Report #2, YOU CAN RELAX, because the system is already working for you , and the cash will continue to roll in! THIS IS IMPORTANT TO REMEMBER : Every time your name is moved down on the list, you are placed in front of a Different report. You can KEEP TRACK of your PROGRESS by watching which report people are ordering from you. IF YOU WANT TO GENERATE MORE INCOME SEND ANOTHER BATCH OF E-MAILS AND START THE WHOLE PROCESS AGAIN. There is NO LIMIT to the income you can generate from this business!!! ______________________________________________________ FOLLOWING IS A NOTE FROM THE ORIGINATOR OF THIS PROGRAM: "You have just received information that can give you financial freedom for the rest of your life, with NO RISK and JUST A LITTLE BIT OF EFFORT. You can make more money in the next few weeks and months than you have ever imagined. Follow the program EXACTLY AS INSTRUCTED. Do Not change it in any way. It works exceedingly well as it is now. Remember to e-mail a copy of this exciting report after you have put your name and address in Report #1 and moved others to #2 ...........#5 as instructed above. One of the people you send this to may send out 100,000 or more e-mails and your name will be on everyone of them. Remember though, the more you send out the more potential customers you will reach. So my friend, I have given you the ideas, information, materials and opportunity to become financially independent. IT IS UP TO YOU NOW! ****************MORE TESTIMONIALS***************** 'My name is Mitchell. My wife, Jody and I live in Chicago. I am an accountant with a major US Corporation and I make pretty good money. When I received this program I grumbled to Jody about receiving ''junk mail''. I made fun of the whole thing, spouting my knowledge of the population and percentages involved. I ''knew'' it wouldn't work. Jody totally ignored my supposed intelligence and few days later she jumped in with both feet. I made merciless fun of her, and was ready to lay the old ''I told you so'' on her when the thing didn't work. Well, the laugh was on me! Within 3 weeks she had received 50 responses. Within the next 45 days she had received total $ 147,200.00 ......... all cash! I was shocked. I have joined Jody in her ''hobby''. Mitchell Wolf, MD , Chicago, Illinois -------------------------------------------------------------------------- ''Not being the gambling type, it took me several weeks to make up my mind to participate in this plan. But conservative that I am, I decided that the initial investment was so little that there was just no way that I wouldn't get enough orders to at least get my money back''. ''I was surprised when I found my medium size post office box crammed with orders. I made $319,210.00 in the first 12 weeks. The nice thing about this deal is that it does not matter where people live. There simply isn't a better investment with a faster return and so big''. Dan Sondstrom, Alberta, Canada -------------------------------------------------------------------------- ''I had received this program before. I deleted it, but later I wondered if I should have given it a try. Of course, I had no idea who to contact to get another copy, so I had to wait until I was e-mailed again by someone else.........11 months passed then it luckily came again...... I did not delete this one! I made more than $490,000 on my first try and all the money came within 22 weeks''. Susan De Suza, Sydney, Australia -------------------------------------------------------------------------- ''It really is a great opportunity to make relatively easy money with little cost to you. I followed the simple instructions carefully and within 10 days the money started to come in. My first month I made $ 20, 560.00 and by the end of third month my total cash count was $ 362,840.00. Life is beautiful, Thanx to Internet''. Fred Dellaca, Westport, New Zealand -------------------------------------------------------------------------- ORDER YOUR REPORTS TODAY AND GET STARTED ON YOUR ROAD TO FINANCIAL FREEDOM! ================================================== If you have any questions of the legality of this program, contact the Office of Associate Director for Marketing Practices, Federal Trade Commission, Bureau of Consumer Protection, Washington, DC /////////////////////////////////////////////////////////////////////////////// ONE TIME MAILING, NO NEED TO REMOVE /////////////////////////////////////////////////////////////////////////////// This message is sent in compliance of the proposed bill SECTION 301. per Section 301, Paragraph (a)(2)(C) of S. 1618. Further transmission to you by the sender of this e-mail may be stopped at no cost to you by sending a reply to : remove@courses2careers.com with the word Remove in the subject line. This message is not intended for residents in the State of Washington, screening of addresses has been done to the best of our technical ability. ******************************************************* THIS LETTER CONSTITUTES NO GUARANTEES STATED NOR IMPLIED. IN THE EVENT THAT IT IS DETERMINED THAT THIS LETTER CONSTITUTES A GUARANTEE OF ANY KIND, THAT GUARANTEE IS NOW VOID. ANY TESTIMONIALS OR AMOUNTS OF EARNINGS LISTED IN THIS LETTER MAY BE FACTUAL OR FICTITIOUS. ******************************************************** From owner-megaco@fore.com Fri Jun 1 14:58:56 2001 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA16286 for ; Fri, 1 Jun 2001 14:58:56 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA00452; Fri, 1 Jun 2001 14:49:44 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id NAA07174 for megaco-list; Fri, 1 Jun 2001 13:51:26 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA07159 for ; Fri, 1 Jun 2001 13:51:23 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Fri, 1 Jun 2001 13:51:21 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF044654EC@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Troy Cauble'" , "Megaco Mailing List (E-mail)" Subject: RE: ABNF Question: digit maps embedded in events Date: Fri, 1 Jun 2001 13:51:19 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Because it was intended to be symmetric in the beginning, what is written is incorrect. We have caught and fixed several of these. When a proposal actually changes what the original intention/documentation/text vs ABNF(ASN.1) is, then we defer it. Brian > -----Original Message----- > From: Troy Cauble [mailto:troy@lucent.com] > Sent: Friday, June 01, 2001 11:22 AM > To: Megaco Mailing List (E-mail) > Subject: Re: ABNF Question: digit maps embedded in events > > > > Just curious, but why doesn't this get squashed for > being an unnecessary change? Nothing's broken except > the symmetry. > > More useful changes have been delayed to v2. > > Please treat this as a question, not a complaint! > Christian, Tom, Brian, et. al. are doing a great job. > > -troy > > > Christian Groves wrote: > > > > Just in time. I'll add it to the implementors' guide. > > > > Christian > > > > Tom-PT Taylor wrote: > > > > > > Yes, and I suspect I'm the guilty typist. > > > > > > > -----Original Message----- > > > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > > Sent: Wednesday, May 30, 2001 3:44 PM > > > > To: 'Steven Weisz'; Megaco Mailing List (E-mail) > > > > Cc: Taylor, Tom-PT [NORSE:B881:EXCH] > > > > Subject: RE: ABNF Question: digit maps embedded in events > > > > > > > > > > > > I usually defer to Tom on any digitMap questions. > > > > I can't tell you how many hours I (and several others > > > > including Abdullah Rayhan) spent pouring over the > > > > ABNF to ferret out such problems. > > > > > > > > Yes, I agree, it should be > > > > digitMap={... > > > > and not > > > > digitMap{... > > > > > > > > I think this qualifies as a typo and deserves an IG entry. > > > > Tom, do you agree? > > > > > > > > Brian > > > > > > > > > -----Original Message----- > > > > > From: Steven Weisz [mailto:sweisz@mediatrix.com] > > > > > Sent: Wednesday, May 30, 2001 3:08 PM > > > > > To: Megaco Mailing List (E-mail) > > > > > Subject: ABNF Question: digit maps embedded in events > > > > > > > > > > > > > > > Hi List, > > > > > > > > > > I asked this question a few weeks ago and still have not > > > > > found an answer. > > > > > Does anyone have an opinion? > > > > > > > > > > It is a quick question concerning a digit map embedded in a > > > > > requested event. > > > > > Specifically, if you look at the ABNF the embedded digit map > > > > > is defined as > > > > > > > > > > eventDM = DigitMapToken (( EQUAL digitMapName ) / (LBRKT > > > > digitMapValue > > > > > RBRKT)) > > > > > > > > > > and a digit map descriptor is defined as: > > > > > > > > > > digitMapDescriptor = DigitMapToken EQUAL (( LBRKT > > > > > digitMapValue RBRKT ) / > > > > > ( digitMapName [LBRKT > digitMapValue RBRKT] )) > > > > > > > > > > > > > It obvious that they are very similar, as I believe was > > > > > intended but there > > > > > is one thing that is bothering me in eventDM. That is it > > > > > seems to me that > > > > > the EQUAL should be right after DigitMapToken as is > the case in > > > > > digitMapDescriptor. So we would instead have: > > > > > > > > > > eventDM = DigitMapToken EQUAL (( digitMapName ) / (LBRKT > > > > digitMapValue > > > > > RBRKT)) > > > > > > > > > > Does this make sense? > > > > > > > > > > Thanks, > > > > > > > > > > Steve > > > > > > > > > > From owner-megaco@fore.com Fri Jun 1 15:25:36 2001 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16699 for ; Fri, 1 Jun 2001 15:25:33 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA03394; Fri, 1 Jun 2001 15:16:33 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id PAA26149 for megaco-list; Fri, 1 Jun 2001 15:15:00 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA26145 for ; Fri, 1 Jun 2001 15:14:58 -0400 (EDT) Received: from zcars0m9.ca.nortel.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA03223 for ; Fri, 1 Jun 2001 15:14:54 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f51JElE25785 for ; Fri, 1 Jun 2001 15:14:47 -0400 (EDT) Received: from ztcfd004.ca.nortel.com by zcars04f.ca.nortel.com; Fri, 1 Jun 2001 15:14:35 -0400 Received: by ztcfd004.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 1 Jun 2001 15:14:33 -0400 Message-ID: <45D2A43C1913D51180F40000F89CB874062E67@nrtpde0a.us.nortel.com> From: "Michael Brown" To: megaco@fore.com Subject: Update : Megaco MIB - RE: I-D ACTION:draft-ietf-megaco-mib-02.txt Date: Fri, 1 Jun 2001 15:14:36 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0EACF.18CCAAD0" X-Orig: Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0EACF.18CCAAD0 Content-Type: text/plain; charset="iso-8859-1" Matt, thanks for posting the location of the presentation. This will be very helpful for focusing discussion on the MIB. My intention is to give interested parties time look at the MIB draft and the issues presented by Matt. Early next week I will start posting these issues one or two at a time with clarification and where possible, a proposal for resolution to try to keep the discussion focused. Of course, if you identify other questions or issues, please don't hesitate to send them directly to me and/or post to the list. As Tom has pointed out this needs to move quickly to finish up the last of the original Megaco charter work items. My plan is that the MIB will be completed prior to (hopefully well ahead of) the upcoming meeting in August. Michael Brown -----Original Message----- From: Matt Holdrege [mailto:matt@ipverse.com] Sent: Wednesday, May 30, 2001 3:43 PM To: Taylor, Tom-PT [NORSE:B881:EXCH]; megaco@fore.com Subject: RE: I-D ACTION:draft-ietf-megaco-mib-02.txt The issues I presented can be viewed here http://www.net-standards.org/MEGACO-mib.ppt At 06:34 AM 5/30/2001, Tom-PT Taylor wrote: >I would like to explain briefly what has happened with this >draft. Basically it consists of a reorganization and extension of >material available in the initial draft (mib-00). As such, it presents a >coherent view and may be the basis of a working MIB. A word of warning >comes along with this: Matt Holdrege identified a lot of open issues two >meetings ago, and a number of these undoubtedly remain open. I will get >Matt's meeting presentation and post it on the Megaco web site for people >to examine. > >Given the large effort Michael Brown and colleagues put into the latest >draft, Michael's name has been added to the authors' list and Michael has >taken over primary editorial responsibilities from Matt. I know that this >has been a frustrating task for Matt due to lack of input from the >WG. Thanks to him and Ilya Akramovich for getting us started. Now let's >get this done so we can stop showing a milestone that's two years late! > >Tom Taylor >Multimedia Control and Applications Standards >Ph. +1 613 736 0961 >taylor@nortelnetworks.com > > > -----Original Message----- > > From: Internet-Drafts@ietf.org > [mailto:Internet-Drafts@ietf.org] > > Sent: Wednesday, May 30, 2001 6:47 AM > > To: IETF-Announce > > Cc: megaco@fore.com > > Subject: I-D ACTION:draft-ietf-megaco-mib-02.txt > > > > > > A New Internet-Draft is available from the on-line > > Internet-Drafts directories. > > This draft is a work item of the Media Gateway Control > > Working Group of the IETF. > > > > Title : MEGACO MIB > > Author(s) : M. Holdrege, I. Akramovich, C. Brown > > Filename : draft-ietf-megaco-mib-02.txt > > Pages : 25 > > Date : 29-May-01 > > > > This memo defines a portion of the Management Information Base (MIB) > > for use with network management protocols in the Internet community. > > In particular, it defines objects for use by the MEGACO/H.248 > > protocol operating on Media Gateways and Media Gateway Controllers. > > > > A URL for this Internet-Draft is: > > > http://www .ietf.org/internet-drafts/draft-ietf-megaco-mib-02.txt > > > > > Internet-Drafts are also available by anonymous FTP. Login > > with the username > > "anonymous" and a password of your e-mail address. After logging in, > > type "cd internet-drafts" and then > > "get draft-ietf-megaco-mib-02.txt". > > > > A list of Internet-Drafts directories can be found in > > http://www.ietf.org/shadow.html > > or > ftp://ftp.ietf.org/ietf/1shadow-s ites.txt > > > > > > > Internet-Drafts can also be obtained by e-mail. > > > > Send a message to: > > mailserv@ietf.org. > > In the body type: > > "FILE /internet-drafts/draft-ietf-megaco-mib-02.txt". > > > > NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use this > > feature, insert the command "ENCODING mime" before the "FILE" > > command. To decode the response(s), you will need "munpack" or > > a MIME-compliant mail reader. Different MIME-compliant > > mail readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which have been split > > up into multiple messages), so check your local documentation on > > how to manipulate these messages. > > > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > ------_=_NextPart_001_01C0EACF.18CCAAD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Update : Megaco MIB - RE: I-D = ACTION:draft-ietf-megaco-mib-02.txt

Matt, thanks for posting the location of the = presentation. This will be very helpful for focusing discussion on the = MIB.

My intention is to give interested parties time look = at the MIB draft and the issues presented by Matt. Early next week I = will start posting these issues one or two at a time with clarification = and where possible, a proposal for resolution to try to keep the = discussion focused.

Of course, if you identify other questions or issues, = please don't hesitate to send them directly to me and/or post to the = list.

As Tom has pointed out this needs to move quickly to = finish up the last of the original Megaco charter work items. My plan = is that the MIB will be completed prior to (hopefully well ahead of) = the upcoming meeting in August.

Michael Brown

-----Original Message-----
From: Matt Holdrege [mailto:matt@ipverse.com]
Sent: Wednesday, May 30, 2001 3:43 PM
To: Taylor, Tom-PT [NORSE:B881:EXCH]; = megaco@fore.com
Subject: RE: I-D = ACTION:draft-ietf-megaco-mib-02.txt


The issues I presented can be viewed here
http://www.net-standards.org/MEGACO-mib.ppt=


At 06:34 AM 5/30/2001, Tom-PT Taylor wrote:

>I would like to explain briefly what has happened = with this
>draft.  Basically it consists of a = reorganization and extension of
>material available in the initial draft = (mib-00).  As such, it presents a
>coherent view and may be the basis of a working = MIB.  A word of warning
>comes along with this: Matt Holdrege identified = a lot of open issues two
>meetings ago, and a number of these undoubtedly = remain open.  I will get
>Matt's meeting presentation and post it on the = Megaco web site for people
>to examine.
>
>Given the large effort Michael Brown and = colleagues put into the latest
>draft, Michael's name has been added to the = authors' list and Michael has
>taken over primary editorial responsibilities = from Matt.  I know that this
>has been a frustrating task for Matt due to lack = of input from the
>WG.  Thanks to him and Ilya Akramovich for = getting us started.  Now let's
>get this done so we can stop showing a milestone = that's two years late!
>
>Tom Taylor
>Multimedia Control and Applications = Standards
>Ph.  +1 613 736 0961
>taylor@nortelnetworks.com
>
> > -----Original Message-----
> > From: Internet-Drafts@ietf.org
> [<mailto:Internet-Drafts@ietf.org= >mailto:Internet-Drafts@ietf.org= ]
> > Sent: Wednesday, May 30, 2001 6:47 = AM
> > To: IETF-Announce
> > Cc: megaco@fore.com
> > Subject: I-D = ACTION:draft-ietf-megaco-mib-02.txt
> >
> >
> > A New Internet-Draft is available from the = on-line
> > Internet-Drafts directories.
> > This draft is a work item of the Media = Gateway Control
> > Working Group of the IETF.
> >
> >       = Title           : = MEGACO MIB
> >       = Author(s)       : M. Holdrege, I. = Akramovich, C. Brown
> >       = Filename        : = draft-ietf-megaco-mib-02.txt
> >       = Pages           : = 25
> >       = Date            = : 29-May-01
> >
> > This memo defines a portion of the = Management Information Base (MIB)
> > for use with network management protocols = in the Internet community.
> > In particular, it defines objects for use = by the MEGACO/H.248
> > protocol operating on Media Gateways and = Media Gateway Controllers.
> >
> > A URL for this Internet-Draft is:
> >
> <http://www.ietf.org/internet-drafts/draft-ietf-megaco-= mib-02.txt>http://www.ietf.org/internet-drafts/draft-ietf-megaco-= mib-02.txt

>
> >
> > Internet-Drafts are also available by = anonymous FTP. Login
> > with the username
> > "anonymous" and a password of = your e-mail address. After logging in,
> > type "cd internet-drafts" and = then
> >       = "get draft-ietf-megaco-mib-02.txt".
> >
> > A list of Internet-Drafts directories can = be found in
> > <http://www.ietf.org/shadow.html>http://www.ietf.org/shadow.html
> > or
> <ftp://ftp.ietf.org/ietf/1shadow-sites.txt>ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
> >
> >
> > Internet-Drafts can also be obtained by = e-mail.
> >
> > Send a message to:
> >       = mailserv@ietf.org.
> > In the body type:
> >       = "FILE /internet-drafts/draft-ietf-megaco-mib-02.txt".
> >
> > NOTE: The mail server at ietf.org can = return the document in
> >       = MIME-encoded form by using the "mpack" utility.  To use = this
> >       = feature, insert the command "ENCODING mime" before the = "FILE"
> >       = command.  To decode the response(s), you will need = "munpack" or
> >       a = MIME-compliant mail reader.  Different MIME-compliant
> > mail readers
> >       = exhibit different behavior, especially when dealing with
> >       = "multipart" MIME messages (i.e. documents which have been = split
> >       up = into multiple messages), so check your local documentation on
> >       how to = manipulate these messages.
> >
> >
> > Below is the data which will enable a MIME = compliant mail reader
> > implementation to automatically retrieve = the ASCII version of the
> > Internet-Draft.
> >

------_=_NextPart_001_01C0EACF.18CCAAD0-- From owner-megaco@fore.com Fri Jun 1 20:50:15 2001 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA20097 for ; Fri, 1 Jun 2001 20:50:15 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA21678; Fri, 1 Jun 2001 20:40:45 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id UAA15401 for megaco-list; Fri, 1 Jun 2001 20:35:47 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA15397 for ; Fri, 1 Jun 2001 20:35:45 -0400 (EDT) Received: from gateway.hearme.com (gateway.hearme.com [204.242.182.129]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA21284 for ; Fri, 1 Jun 2001 20:35:04 -0400 (EDT) Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01068; Fri, 1 Jun 2001 17:32:34 -0700 (PDT) Received: (from corey@localhost) by nodserv.hearme.com (8.9.1/8.9.1) id RAA28416 for corey@hearme.com; Fri, 1 Jun 2001 17:31:45 -0700 (PDT) Received: from gateway.hearme.com (localhost [127.0.0.1]) by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id GAA09027 for ; Thu, 31 May 2001 06:17:31 -0700 (PDT) Received: from optimus.ietf.org ([132.151.1.19]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id GAA12911 for ; Thu, 31 May 2001 06:17:29 -0700 (PDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA06115; Thu, 31 May 2001 09:16:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA00835 for ; Wed, 30 May 2001 19:39:29 -0400 (EDT) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA27486; Wed, 30 May 2001 19:39:09 -0400 (EDT) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f4UNdHZ03453; Wed, 30 May 2001 16:39:17 -0700 (PDT) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id XAA13198; Wed, 30 May 2001 23:39:17 GMT Date: Wed, 30 May 2001 23:39:17 GMT Message-Id: <200105302339.XAA13198@gra.isi.edu> To: gratta@lucent.com, sob@harvard.edu, mankin@isi.edu, rrroy@att.com Cc: diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org, hiramatsu.yukio@lab.ntt.co.jp, rbuhrke@lucent.com, tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch, ITU-SG16@mailbag.cps.INTEL.COM X-Sun-Charset: US-ASCII Subject: [Sipping] RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL X-Mailman-Version: 1.0 List-Id: Official IETF Mailing List for the SIPPING Working Group X-BeenThere: sipping@ietf.org Content-Type: text Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk *> From owner-issll@mercury.lcs.mit.edu Wed May 30 14:59:58 2001 *> From: "Roy, Radhika R, ALCTA" *> To: gratta@lucent.com, sob@harvard.edu, mankin@ISI.EDU *> Cc: diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, *> megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org, *> Yukio Hiramatsu *> , rbuhrke@lucent.com, *> tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch, ITU-SG16@mailbag.cps.INTEL.COM *> Subject: RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E *> ND-TO-END QOS SERVICE CONTROL *> Date: Wed, 30 May 2001 17:21:14 -0400 *> MIME-Version: 1.0 *> *> Hi, Everyone: *> *> Question Q.F/16 of ITU-T SG16 is fully dedicated for developing standards *> for "End-to-End QOS for Multimedia Applications". Contributions are also *> being under discussion in the ITU-T SG16 Brazil May 28 - June 8, 2001 *> meeting. This is very confusing. "End-to-End QOS for Multimedia Applications" is an really important topic, but this topic must be a superset of "End-to-End QOS signaling". There are much harder problems than signaling in providing E2E QoS. Can you explain how signaling relates to the title of this working party? Thanks, Bob Braden *> *> Applications like H.323, SIP, H.324, H.310, and others will also be able to *> use this Q.F/16's QOS signaling protocol. MEGACO/H.248 and BICC will also be *> able to use this when specs are fully developed and, TIPHON's QOS mechanisms *> can also be used as one of the mechanisms for implementations. _______________________________________________ Sipping mailing list Sipping@ietf.org http://www.ietf.org/mailman/listinfo/sipping From owner-megaco@fore.com Fri Jun 1 20:50:32 2001 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA20107 for ; Fri, 1 Jun 2001 20:50:31 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA21902; Fri, 1 Jun 2001 20:42:18 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id UAA15504 for megaco-list; Fri, 1 Jun 2001 20:37:27 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA15472 for ; Fri, 1 Jun 2001 20:37:15 -0400 (EDT) Received: from gateway.hearme.com (gateway.hearme.com [204.242.182.129]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA21328 for ; Fri, 1 Jun 2001 20:37:10 -0400 (EDT) Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01110; Fri, 1 Jun 2001 17:34:44 -0700 (PDT) Received: (from corey@localhost) by nodserv.hearme.com (8.9.1/8.9.1) id RAA28443 for corey@hearme.com; Fri, 1 Jun 2001 17:33:23 -0700 (PDT) Received: from gateway.hearme.com (localhost [127.0.0.1]) by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id GAA09035 for ; Thu, 31 May 2001 06:17:37 -0700 (PDT) Received: from optimus.ietf.org ([132.151.1.19]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id GAA12919 for ; Thu, 31 May 2001 06:17:35 -0700 (PDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA06076; Thu, 31 May 2001 09:16:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA28632 for ; Wed, 30 May 2001 18:31:19 -0400 (EDT) Received: from sj-msg-core-4.cisco.com ([171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA26407; Wed, 30 May 2001 18:30:53 -0400 (EDT) Received: from FRED-W2K.cisco.com (fred-hm-dhcp3.cisco.com [171.69.128.118]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f4UMUBU11655; Wed, 30 May 2001 15:30:11 -0700 (PDT) Message-Id: <5.1.0.14.2.20010530152432.043b8ec0@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 30 May 2001 15:30:00 -0700 To: gratta@lucent.com From: Fred Baker Cc: sob@harvard.edu, mankin@isi.edu, diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org, Yukio Hiramatsu , rbuhrke@lucent.com, tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch, John C Klensin , chair@ietf.org In-Reply-To: <200105302022.QAA03855@hotair.hobl.lucent.com> Mime-Version: 1.0 Subject: [Sipping] Re: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR END-TO-END QOS SERVICE CONTROL X-Mailman-Version: 1.0 List-Id: Official IETF Mailing List for the SIPPING Working Group X-BeenThere: sipping@ietf.org Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Greg: The URLs in this note were all sent with what the ETSI machine considered to be 'malformed syntax'. Could you resend the correct URLs? Fred _______________________________________________ Sipping mailing list Sipping@ietf.org http://www.ietf.org/mailman/listinfo/sipping From owner-megaco@fore.com Fri Jun 1 20:50:45 2001 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA20123 for ; Fri, 1 Jun 2001 20:50:44 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA21913; Fri, 1 Jun 2001 20:42:24 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id UAA15443 for megaco-list; Fri, 1 Jun 2001 20:36:12 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA15438 for ; Fri, 1 Jun 2001 20:36:10 -0400 (EDT) Received: from gateway.hearme.com (gateway.hearme.com [204.242.182.129]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA21297 for ; Fri, 1 Jun 2001 20:35:57 -0400 (EDT) Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01087; Fri, 1 Jun 2001 17:33:23 -0700 (PDT) Received: (from corey@localhost) by nodserv.hearme.com (8.9.1/8.9.1) id RAA28433 for corey@hearme.com; Fri, 1 Jun 2001 17:32:34 -0700 (PDT) Received: from gateway.hearme.com (localhost [127.0.0.1]) by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id GAA09029 for ; Thu, 31 May 2001 06:17:33 -0700 (PDT) Received: from optimus.ietf.org ([132.151.1.19]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id GAA12913 for ; Thu, 31 May 2001 06:17:30 -0700 (PDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA06184; Thu, 31 May 2001 09:17:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA05686 for ; Thu, 31 May 2001 09:10:49 -0400 (EDT) Received: from ckmso1.proxy.att.com ([12.20.58.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA23528; Thu, 31 May 2001 09:10:29 -0400 (EDT) Received: from gab200r1.ems.att.com ([135.37.94.32]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id f4VD8wC16127; Thu, 31 May 2001 09:08:58 -0400 (EDT) Received: from njb140bh1.ems.att.com by gab200r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id JAA04890; Thu, 31 May 2001 09:08:30 -0400 (EDT) Received: by njb140bh1.ems.att.com with Internet Mail Service (5.5.2653.19) id ; Thu, 31 May 2001 09:08:52 -0400 Message-ID: From: "Roy, Radhika R, ALCTA" To: Bob Braden , gratta@lucent.com, sob@harvard.edu, mankin@isi.edu Cc: diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org, hiramatsu.yukio@lab.ntt.co.jp, rbuhrke@lucent.com, tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch, ITU-SG16@mailbag.cps.INTEL.COM Date: Thu, 31 May 2001 09:08:45 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: [Sipping] RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL X-Mailman-Version: 1.0 List-Id: Official IETF Mailing List for the SIPPING Working Group X-BeenThere: sipping@ietf.org Content-Type: text/plain; charset="iso-8859-1" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Hi, Bob: All applications (e.g., H.323, SIP) uses signaling messages among its functional entities (e.g., terminal, agents, gatekeepers, proxies, gateways) for communications. The signaling messages that carry QOS parameters are treated as QOS signaling messages. The applications like SIP and H.323 send signaling messages end-to-end. H.323 uses H.225.0 RAS, Q.931, Annex G, and H.245 signaling protocols. SIP also uses SDP as a part of the signaling messages. The signaling messages that carry QOS related information can be treated as "End-to-End QOS signaling" messages. Kindly see the ongoing works of Q.F/16 of SG16. This will provide more information related to your questions. Hope this helps. Best regards, Radhika R. Roy -----Original Message----- From: Bob Braden [mailto:braden@ISI.EDU] Sent: Wednesday, May 30, 2001 7:39 PM To: gratta@lucent.com; sob@harvard.edu; mankin@ISI.EDU; Roy, Radhika R, ALCTA Cc: diffserv@ietf.org; iptel@lists.bell-labs.com; issll@mercury.lcs.mit.edu; megaco@fore.com; sip@lists.bell-labs.com; sipping@ietf.org; tsvwg@ietf.org; hiramatsu.yukio@lab.ntt.co.jp; rbuhrke@lucent.com; tsg11q8@ties.itu.ch; tsg11q9@ties.itu.ch; ITU-SG16@mailbag.cps.INTEL.COM Subject: RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL *> From owner-issll@mercury.lcs.mit.edu Wed May 30 14:59:58 2001 *> From: "Roy, Radhika R, ALCTA" *> To: gratta@lucent.com, sob@harvard.edu, mankin@ISI.EDU *> Cc: diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, *> megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org, *> Yukio Hiramatsu *> , rbuhrke@lucent.com, *> tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch, ITU-SG16@mailbag.cps.INTEL.COM *> Subject: RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E *> ND-TO-END QOS SERVICE CONTROL *> Date: Wed, 30 May 2001 17:21:14 -0400 *> MIME-Version: 1.0 *> *> Hi, Everyone: *> *> Question Q.F/16 of ITU-T SG16 is fully dedicated for developing standards *> for "End-to-End QOS for Multimedia Applications". Contributions are also *> being under discussion in the ITU-T SG16 Brazil May 28 - June 8, 2001 *> meeting. This is very confusing. "End-to-End QOS for Multimedia Applications" is an really important topic, but this topic must be a superset of "End-to-End QOS signaling". There are much harder problems than signaling in providing E2E QoS. Can you explain how signaling relates to the title of this working party? Thanks, Bob Braden *> *> Applications like H.323, SIP, H.324, H.310, and others will also be able to *> use this Q.F/16's QOS signaling protocol. MEGACO/H.248 and BICC will also be *> able to use this when specs are fully developed and, TIPHON's QOS mechanisms *> can also be used as one of the mechanisms for implementations. _______________________________________________ Sipping mailing list Sipping@ietf.org http://www.ietf.org/mailman/listinfo/sipping From owner-megaco@fore.com Fri Jun 1 20:53:24 2001 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA20174 for ; Fri, 1 Jun 2001 20:53:23 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA22286; Fri, 1 Jun 2001 20:44:36 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id UAA15592 for megaco-list; Fri, 1 Jun 2001 20:39:31 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA15576 for ; Fri, 1 Jun 2001 20:39:19 -0400 (EDT) Received: from gateway.hearme.com (gateway.hearme.com [204.242.182.129]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA21464 for ; Fri, 1 Jun 2001 20:39:09 -0400 (EDT) Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01148; Fri, 1 Jun 2001 17:36:30 -0700 (PDT) Received: (from corey@localhost) by nodserv.hearme.com (8.9.1/8.9.1) id RAA28465 for corey@hearme.com; Fri, 1 Jun 2001 17:35:23 -0700 (PDT) Received: from gateway.hearme.com (localhost [127.0.0.1]) by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id HAA09618 for ; Thu, 31 May 2001 07:07:47 -0700 (PDT) Received: from lists.bell-labs.com ([204.178.16.58]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id HAA13655 for ; Thu, 31 May 2001 07:07:46 -0700 (PDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1299A44340; Thu, 31 May 2001 10:07:05 -0400 (EDT) Delivered-To: iptel@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id 194AD4433C for ; Wed, 30 May 2001 16:50:45 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Wed May 30 16:46:04 EDT 2001 Received: by lists.bell-labs.com (Postfix) id ED5254437D; Wed, 30 May 2001 16:22:27 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from hotair.hobl.lucent.com (hotair.hobl.lucent.com [199.118.135.2]) by lists.bell-labs.com (Postfix) with SMTP id 0575844384; Wed, 30 May 2001 16:22:26 -0400 (EDT) Received: from 7460gratta.ho.lucent.com by hotair.hobl.lucent.com (SMI-8.6/EMS-1.5 sol2) id QAA03855; Wed, 30 May 2001 16:22:23 -0400 Message-Id: <200105302022.QAA03855@hotair.hobl.lucent.com> From: "Greg Ratta" To: sob@harvard.edu, mankin@isi.edu MIME-Version: 1.0 Content-transfer-encoding: Quoted-printable Reply-To: gratta@lucent.com Cc: diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org, Yukio Hiramatsu , rbuhrke@lucent.com, tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch X-mailer: Pegasus Mail for Win32 (v3.01d) Subject: [IPTEL] PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR END-TO-END QOS SERVICE CONTROL X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Wed, 30 May 2001 16:22:23 -0400 Content-Type: text/enriched; charset=ISO-8859-1 Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: Quoted-printable This message was agreed to at ITU-T Study Group 11 meeting (Geneva, May 2001) and is being transmitted on behalf of Yukio Hiramatsu, Chairman of ITU-T SG 11. For further technical clarification, contact the Rapporteur for Q9/11 (Rolfe Buhrke, Tel: + 1 630 713 7022, { HYPERLINK mailto:rburke@lucent.com }rbuhrke@lucent.com) FULL TITLE: Times New RomanPROPOSED JOINT ACTI= VITY ON A GENERIC PROTOCOL MECHANISM FOR END-TO-END QOS SERVICE CONTROL AND 0100,0100,0100SIGNALLING PROTOCOL DEVELO= PMENT BASED ON IP TRANSFER CAPABILITIES AND IP QOS CLASSES rightCourier NewGene= ral rightWithin ITU-T SG11 work has started on requirements for a generic protocol mechanism for end-to-end QoS service control. It was agreed within SG11 to proceed with this work utilising deliverables of ETSI TIPHON on end- to-end QoS service control as base material. It is the opinion of SG11 that this generic protocol mechanism for BICC intends to apply also to other protocols like SIP/SDP and H.323 next to generic extensions to the H.248/MEGACO protocol. rightIt was noted that also QoS related work is= in progress in IETF. Please find attached an initial draft of the BICC CS3 signalling requirements for end-to-end QoS service control. Please note the rationale for this activity and the framework for end-to-end QoS service control and network QoS control. The framework illustrates the field of application of the QoS handling at different levels and the different protocols involved. rightProposals on end-to-end QoS service contro= l rightIt is proposed to start a joint activity w= ith IETF on a generic protocol mechanism for end- to-end QoS service control. This refers to the potential work in IETF on the following topics: right- Identification of the signalling requirements based on the ETSI TIPHON defined speech QoS service classes for VoIP and the signalling and control of end-to-end QoS for VoIP. The attachment provides the initial draft of the BICC CS3 signalling requirements for end-to-end QoS service control. right- The definition of a generic call/bearer control mechanism in H.225/H.245, SIP/SDP and BICC CS3 for end-to-end QoS service control in the application plane. right- The definition of generic extensions to H.248/MEGACO for end-to-end QoS service control between the application plane and the transport plane. right- The translation between the generic protocol QoS information elements in H.248/MEGACO and the technology specific QoS parameters and QoS mechanisms in IP, ATM, MPLS, etc. rightProposals on IP QoS classes and IP Transfe= r Capabilities rightITU-T SG11 would like to inform IETF that = it is investigating signalling requirements for protocol development based on the IP Transfer Capabilities and IP QoS classes, as being defined by ITU-T SG13 in Y.1541 and Y.iptc. The plan is to build upon signalling approaches developed by IETF. We would like to stress that the work on IP QoS classes and IP Transfer Capabilities by ITU-T SG13 is co- ordinated with IETF. rightATTACHMENT Initial draft text of the BICC CS3 signalling requirements for end-to-end QoS service control. rightThe ETSI specifications referenced as base= material are available at the following URLs: outETSI TS 301 329 part 2, http://docbox.etsi.org/tech- org/tiphon/Document/tiphon/07- drafts/wg5/_Published/DTS05009/V1.1.1/ts_10 1329-2v111p.doc right- ETSI TS 301 329 part 3 see http://docbox.etsi.org/tech- org/tiphon/Document/tiphon/07- drafts/wg5/_Published/DTS05003/DTS05003v096.zi p rightFurther information about the ETSI TIPHON project is available at the following URL: right- http://webapp.etsi.org/tbhomepage/TBDetails.as p?TB_ID=3D291&TB_NAME=3DTIPHON right__________________ rightBICC CS3 signalling requirements for end-t= o- end QoS service control rightEDITORS=92 NOTE: This requirements text fo= r end-to-end QoS service control is a first draft text and requires extensive updating based on liaison activities with other groups right1 Rationale rightThe rationale of the BICC CS3 requirements= for end-to-end service control is based on the analysis made by ETSI TIPHON (see the presentation available at the URL: http://docbox.etsi.org/tech- org/tiphon/Document/tiphon/ARCHIVES/2000/05- 200012- Kyoto/WG5%20TIPHON21%20presentation%20Rev1.ppt ). It shows the inter-relationship between the different QoS factors that finally determine rightthe perceived speech quality by the end- users. This perceived speech quality does not only depend on network quality of service (network packet loss, network jitter and network delay) but on the terminal implementation (jitter buffers and codec performance) as well. right rightA second rationale is that end-to-end QoS requirements can be regarded as end-to-end quality budgets related to the media flows. To achieve the required end-to-end QoS these quality budgets must be allocated between the domains, including the user equipment (see Figure 7 in ETSI TS 301 329 part 3). The Transport QoS Parameters specify the QoS budgets for each Transport Domain. It is assumed that the performance of each domain is statistically independent from any other. right rightTherefore end-to-end QoS service control a= t the call control level (i.e. application plane) is required based on generic signalling procedures in protocols like BICC, SIP/SDP, H.323 and H.248/MEGACO for end-to- end QoS service control. right2 Framework for end-to-end QoS service control and network QoS control. rightA framework for QoS control may be conside= red at different levels: call control (BICC, SIP/SDP, H.323), vertical control (H.248/MEGACO, CBC), bearer control (IP BCP) and bearer (DiffServ, IntServ/RSVP or MPLS/LDP). right1) Call-control righta) End-to-end QoS service control is negotiated/communicated end-to-end at the call control level. ETSI TIPHON has defined a set of speech QoS classes, and signalling requirements and flows for this purpose. rightThe idea is that call control protocols ar= e enhanced with a generic end-to-end QoS service control mechanism to negotiate these speech QoS classes and associated parameters (Maximum delay, Maximum packet delay variation, Maximum packet loss, Peak bit rate and Maximum packet size). rightSuch a generic end-to-end QoS service cont= rol mechanism should be defined independent of the underlying technology (ATM or IP) and operate across network domains and including terminal characteristics to negotiate/communicate the requested listener speech quality that will be perceived by the end-users (i.e. "mouth-to-ear"). rightb) BICC (Q.190x) is one of the call contro= l protocols that may be enhanced this way. Similar enhancements may be applicable to other call-control protocols like SIP/SDP and H.323. right2) Vertical control righta) QoS service control is also negotiated/communicated at the vertical control level. The ETSI TIPHON defined signalling requirements and flows include the vertical interface. The idea is that vertical control protocols are enhanced to negotiate/communicate the QoS settings (Maximum delay, Maximum packet delay variation, Maximum packet loss, Peak bit rate and Maximum packet size) in the bearer core network based on generic H.248/MEGACO extensions. rightThese QoS settings should be defined independent of the underlying technology (ATM or IP) of the bearer core network. rightb) CBC (Q.1950) is one of the vertical control protocols that may be enhanced this way. right3) Bearer control righta) Network QoS is negotiated/communicated = at the bearer control level. ATM signalling does already intrinsically support network QoS. SG13 has recently defined IP QoS classes and IP Transfer Capabilities. rightThe idea is that bearer control protocols = for IP are enhanced with a mechanism to negotiate the network QoS by using IP QoS classes and IP Transfer Capabilities. rightb) IP BCP (Q.1970) is an IP bearer control= protocol that may be enhanced this way. right4) Bearer righta) Network QoS is negotiated/communicated = at the bearer level, i.e. as part of the protocols associated with the bearers in the core network. The idea is that IP QoS classes and IP Transfer Capabilties, as defined by SG13, are used to differentiate between different types of IP traffic. rightb) IP QoS classes and IP Transfer Capabilities may be used to enhance existing IP mechanisms like DiffServ, IntServ/RSVP and MPLS/LDP. right right3 QoS information flows applicable to BICC= rightA general model is considered for QoS information flows with BICC when making a translation of the relevant parts in Figure 8 in ETSI TS 301 329 part 3. right rightSection 4 details the Q.BICC related QoS primitives and parameters based on the QoS primitives and parameters in the ETSI deliverable. Similarly, section 5 provides the Q.CBC related QoS primitives and parameters. right4 Q.BICC related QoS primitives and parame= ters rightThe Q.BICC related QoS primitives and parameters are extracted from clause 8.1 and clause 8.2 of ETSI TS 101 329 part 3. right4.1 Q.BICC related QoS primitives rightThis information flow (QC2 in ETSI TS 101 = 329 part 3) communicates the QoS related bearer information between the domains of different service providers. rightQ.BICC QoS request (Qbicc.QoSreq) requests= the establishment of a bearer conforming to a particular ETSI TIPHON Class of Service or with defined QoS characteristics. rightNOTE Identical to QoSM request (QC2.QoSMre= q) in ETSI TS 101 329 part 3 clause 8.1.1. rightQ.BICC QoS confirm (Qbicc.QoSconf) acknowledges the creation of a bearer conforming to a requested ETSI TIPHON QoS Class or with specified QoS characteristics. rightNOTE Identical to QoSM confirm (QC2.QoSMconf) in ETSI TS 101 329 part 3 clause 8.1.1. rightQ.BICC QoS reject (Qbicc.QoSrej) rejects t= he creation of a bearer conforming to a requested ETSI TIPHON QoS Class or with specified QoS characteristics. rightNOTE Identical to QoSM reject (QC2.QoSMrej= ) in ETSI TS 101 329 part 3 clause 8.1.1. rightQ.BICC release request (Qbicc.QoSrelreq) requests the release of a bearer. rightNOTE Identical to QoSM release request (QC2.QoSMrelreq) in ETSI TS 101 329 part 3 clause 8.1.1 and the release of a transport flow is already covered by existing Q.BICC procedures in Q.1902 series. rightQoSM release confirm (Qbicc.QoSrelconf) confirms the release of a bearer. rightNOTE Identical to QoSM release confirm (QC2.QoSMrelconf) in ETSI TS 101 329 part 3 clause 8.1.1 and the release of a transport flow is already covered by existing Q.BICC procedures in Q.1902 series. right4.2 Q.BICC related QoS parameters rightTable 1 lists the parameters used in the Q.BICC related QoS primitives not yet covered by the Q.BICC protocol. The deleted items refer to the information elements already covered by the BICC CS2 protocol in the Q.1902 series. rightNOTE The contents of Table 1 is an interpretation of the table in ETSI TS 101 329 part 3 clause 8.2.3. rightTable 1: Identification of Q.BICC related parameters for end-to-end QoS service control rightQbicc.QoSreq QoS Service Class Optional right Codec Type and Packetisation Mandatory right Transport QoS Parameters Mandatory right Traffic Descriptor Optional right Transport Addresses Mandatory right Application Data Transport Protocol Optional [Default RTP] right Packet Transport Protocol Optional [Default UDP] right QoS Mechanism Optional rightQbicc.QoSconf QoS Service Class Optional right Codec Type and Packetisation Mandatory right Transport QoS Parameters Mandatory right Transport Addresses Mandatory right Application Data Transport Protocol Optional [Default RTP] right Packet Transport Protocol Optional [Default UDP] rightQbicc.QoSrej Reason [TBD] Mandatory right5 Q.CBC related QoS primitives and paramet= ers rightThe Q.CBC related QoS primitives and parameters are extracted from clause 8.1 and clause 8.2 of ETSI TS 101 329 part 3. right5.1 Q.CBC related QoS primitives rightThis information flow (QT2 in ETSI TS 101 = 329 part 3) communicates the QoS related transport flow information between a service domain and an associated transport domain. This information contains the QoS related characteristics required of the transport flows that will carry the media flow and the properties of the media flow. rightQ.CBC QoS request (Qcbc.QoSreq) requests t= he establishment of a transport flow with defined QoS characteristics across a Transport Domain or the reservation of Transport Domain resource. rightNOTE Identical to TRM QoS request (QT2.TRMQreq) in ETSI TS 101 329 part 3 clause 8.1.3. rightQ.CBC QoS confirm (Qcbc.QoSconf) acknowled= ges the creation of a requested transport flow or the reservation of Transport Domain resource. rightNOTE Identical to TRM QoS confirm (QT2.TRMQconf) in ETSI TS 101 329 part 3 clause 8.1.3. rightQ.CBC QoS reject (Qcbc.QoSrej) rejects the= creation of a requested transport flow or the reservation of Transport Domain resource. rightNOTE Identical to TRM QoS reject (QT2.TRMQrej) in ETSI TS 101 329 part 3 clause 8.1.3. rightQ.CBC QoS release request (Qcbc.QoSrelreq)= requests the release of a transport flow. rightNOTE Identical to TRM QoS release request (QT2.TRM QoS relreq) in ETSI TS 101 329 part 3 clause 8.1.3. The release of a transport flow is already covered by the existing Q.CBC procedures in Q.1950. rightQ.CBC QoS release confirm (Qcbc.QoSrelconf= ) confirms the release of a transport flow. rightNOTE Identical to TRM QoS release confirm (QT2.TRM QoS relconf) in ETSI TS 101 329 part 3 clause 8.1.3. The release of a transport flow is already covered by the existing Q.CBC procedures in Q.1950. rightQ.CBC QoS performance notification (Qcbc.QoSperfnotif) notifies the Service Domain of the performance of the Transport Domain in meeting the requested QoS levels. This may be a periodic event or an urgent alarm. Note: this primitive is a management primitive and its use is for further study. rightNOTE Identical to TRM QoS performance notification (QT2.TRM QoS perfnotif) in ETSI TS 101 329 part 3 clause 8.1.3. For further study. right5.2 Q.CBC related QoS parameters rightTable 2 lists the parameters used in the Q.CBC related QoS primitives not yet covered by the Q.CBC protocol. The deleted items refer to the information elements already covered by the BICC CS2 protocol in Q.1950. rightNOTE The contents of Table 2 is an interpretation of the table in ETSI TS 101 329 part 3 clause 8.2.5. rightTable 2: Identification of Q.CBC related parameters for end-to-end QoS service control rightQT2.TRMQreq Transport QoS Parameters Mandatory right Traffic Descriptor Mandatory right Transport Addresses Mandatory right Packet Transport Protocol Optional [Default UDP] rightQT2.TRMQconf Transport QoS Parameters Mandatory right Transport Addresses Mandatory right Packet Transport Protocol Optional [Default UDP] right QoS Mechanism Optional rightQT2.TRMQrej Reason [TBD] Mandatory right6 Parameter contents rightTable 3 specifies the information to be covered by the parameters listed in sections 4.2 and 5.2 based on the QoS parameter groups in ETSI TS 101 329 part 3 clause 8.2.1. rightTable 3: Identification of parameter conte= nts for end-to-end QoS service control rightQoS Service Class Describes the end-to-end= ETSI TIPHON Best, High, Medium right class of a bearer or Best Effort rightTransport QoS Specifies the QoS characteristics Maximum Delay rightParameters required of the transport flow= right carrying the media flow. Maximum Packet Delay Variation right Maximum Packet Loss rightTraffic Descriptor Characterises the resource Peak Bit right requirements of an application data right flow (excludes transport flow Maximum Packet Size right resource requirements). rightParameters specifying the ETSI TIPHON QoS Class as defined in ETSI TS 101 329 Part 2 rightThe maximum delay permitted (ms) over eith= er a segment of the transport flow or the remaining part of the transport flow. rightThe maximum packet delay variation permitt= ed (ms) over either a segment of the transport flow or the remaining part of the transport flow. rightThe maximum packet loss permitted (%) over= either a segment of the transport flow or the remaining part of the transport flow. [N.B. This measure assumes randomly distributed packet loss] rightMaximum bit rate (bit/s) of the media flow= . rightMaximum size of the media packets right7 Information flows and signalling procedu= res for end-to-end QoS service control rightEDITORS=92 NOTE The information flows and signalling procedures for end-to-end QoS service control may be considered to follow the same principles as the already existing procedures for end-to-end codec negotiation in BICC CS1 and BICC CS2. Similarly mid-call procedures for end-to-end QoS modification and mid-call QoS modification may be considered because the perceived QoS is highly related to the codec type employed end- to-end as part of the connection. The exact scope and properties of these procedures and protocol message flows needs further discussion. Greg Ratta, Vice Chairman, ITU-T SG 11, Signalling requirements and protoc= ols Lucent Technologies Tel: +1 732 332 5174, Fax: +1 732 949 1196, gratta@lucent.com _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From owner-megaco@fore.com Fri Jun 1 20:54:05 2001 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA20189 for ; Fri, 1 Jun 2001 20:54:04 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA22191; Fri, 1 Jun 2001 20:43:53 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id UAA15567 for megaco-list; Fri, 1 Jun 2001 20:39:09 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA15558 for ; Fri, 1 Jun 2001 20:39:02 -0400 (EDT) Received: from gateway.hearme.com (gateway.hearme.com [204.242.182.129]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA21437 for ; Fri, 1 Jun 2001 20:38:51 -0400 (EDT) Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01176; Fri, 1 Jun 2001 17:37:00 -0700 (PDT) Received: (from corey@localhost) by nodserv.hearme.com (8.9.1/8.9.1) id RAA28488 for corey@hearme.com; Fri, 1 Jun 2001 17:36:01 -0700 (PDT) Received: from gateway.hearme.com (localhost [127.0.0.1]) by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id HAA09651 for ; Thu, 31 May 2001 07:10:47 -0700 (PDT) Received: from lists.bell-labs.com ([204.178.16.58]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id HAA13698 for ; Thu, 31 May 2001 07:10:45 -0700 (PDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 262ED44358; Thu, 31 May 2001 10:07:12 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from kcmso1.proxy.att.com (kcmso1.att.com [192.128.133.69]) by lists.bell-labs.com (Postfix) with ESMTP id 789E544336; Wed, 30 May 2001 17:23:12 -0400 (EDT) Received: from njb140r1.ems.att.com ([135.65.202.58]) by kcmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id f4ULLMD18676; Wed, 30 May 2001 17:21:22 -0400 (EDT) Received: from njb140bh2.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id RAA19071; Wed, 30 May 2001 17:20:06 -0400 (EDT) Received: by njb140bh2.ems.att.com with Internet Mail Service (5.5.2653.19) id ; Wed, 30 May 2001 17:21:20 -0400 Message-ID: From: "Roy, Radhika R, ALCTA" To: gratta@lucent.com, sob@harvard.edu, mankin@isi.edu Cc: diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org, Yukio Hiramatsu , rbuhrke@lucent.com, tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch, ITU-SG16@mailbag.cps.INTEL.COM MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: [IPTEL] RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Wed, 30 May 2001 17:21:14 -0400 Content-Type: text/plain; charset="iso-8859-1" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Hi, Everyone: Question Q.F/16 of ITU-T SG16 is fully dedicated for developing standards for "End-to-End QOS for Multimedia Applications". Contributions are also being under discussion in the ITU-T SG16 Brazil May 28 - June 8, 2001 meeting. Applications like H.323, SIP, H.324, H.310, and others will also be able to use this Q.F/16's QOS signaling protocol. MEGACO/H.248 and BICC will also be able to use this when specs are fully developed and, TIPHON's QOS mechanisms can also be used as one of the mechanisms for implementations. BICC and MEGCAO/H.248 are only used as the protocol between the gateways, NOT end-to-end (although SIP/H.323 or other protocols may be used between the gateways). The "End-to-End QOS for Multimedia Applications" of SG16 can also be termed as "Application Layer QOS." Q.F/16's end-to-end application layer QOS can also be implemented over the network layer QOS like RSVP, DiffServe, and/or MPLS after proper mapping. Similar is the case for the ATM network. Please note that the network layer QOS (e.g., RSVP, DiffServe, and/or MPLS) may or may not have the end-to-end significance. For example, an IP network may implement different QOS schemes in different domains (e.g., RVSP in one domain, DiffServ in another domain). However, the application layer QOS is end-to-end that remains the same. For example, an H.323 or SIP call that can traverse several IP domains where each domain may implement its own network layer QOS schemes while the H.323/SIP call carry the signaling messages and QOS parameters end-to-end independent of the underlying network layer QOS mechanisms. Let us work together. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Greg Ratta [mailto:gratta@lucent.com] Sent: Wednesday, May 30, 2001 4:22 PM To: sob@harvard.edu; mankin@isi.edu Cc: diffserv@ietf.org; iptel@lists.bell-labs.com; issll@mercury.lcs.mit.edu; megaco@fore.com; sip@lists.bell-labs.com; sipping@ietf.org; tsvwg@ietf.org; Yukio Hiramatsu; rbuhrke@lucent.com; tsg11q8@ties.itu.ch; tsg11q9@ties.itu.ch Subject: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR END-TO-END QOS SERVICE CONTROL This message was agreed to at ITU-T Study Group 11 meeting (Geneva, May 2001) and is being transmitted on behalf of Yukio Hiramatsu, Chairman of ITU-T SG 11. For further technical clarification, contact the Rapporteur for Q9/11 (Rolfe Buhrke, Tel: + 1 630 713 7022, { HYPERLINK mailto:rburke@lucent.com }rbuhrke@lucent.com) FULL TITLE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR END-TO-END QOS SERVICE CONTROL AND SIGNALLING PROTOCOL DEVELOPMENT BASED ON IP TRANSFER CAPABILITIES AND IP QOS CLASSES General Within ITU-T SG11 work has started on requirements for a generic protocol mechanism for end-to-end QoS service control. It was agreed within SG11 to proceed with this work utilising deliverables of ETSI TIPHON on end- to-end QoS service control as base material. It is the opinion of SG11 that this generic protocol mechanism for BICC intends to apply also to other protocols like SIP/SDP and H.323 next to generic extensions to the H.248/MEGACO protocol. It was noted that also QoS related work is in progress in IETF. Please find attached an initial draft of the BICC CS3 signalling requirements for end-to-end QoS service control. Please note the rationale for this activity and the framework for end-to-end QoS service control and network QoS control. The framework illustrates the field of application of the QoS handling at different levels and the different protocols involved. Proposals on end-to-end QoS service control It is proposed to start a joint activity with IETF on a generic protocol mechanism for end- to-end QoS service control. This refers to the potential work in IETF on the following topics: - Identification of the signalling requirements based on the ETSI TIPHON defined speech QoS service classes for VoIP and the signalling and control of end-to-end QoS for VoIP. The attachment provides the initial draft of the BICC CS3 signalling requirements for end-to-end QoS service control. - The definition of a generic call/bearer control mechanism in H.225/H.245, SIP/SDP and BICC CS3 for end-to-end QoS service control in the application plane. - The definition of generic extensions to H.248/MEGACO for end-to-end QoS service control between the application plane and the transport plane. - The translation between the generic protocol QoS information elements in H.248/MEGACO and the technology specific QoS parameters and QoS mechanisms in IP, ATM, MPLS, etc. Proposals on IP QoS classes and IP Transfer Capabilities ITU-T SG11 would like to inform IETF that it is investigating signalling requirements for protocol development based on the IP Transfer Capabilities and IP QoS classes, as being defined by ITU-T SG13 in Y.1541 and Y.iptc. The plan is to build upon signalling approaches developed by IETF. We would like to stress that the work on IP QoS classes and IP Transfer Capabilities by ITU-T SG13 is co- ordinated with IETF. ATTACHMENT Initial draft text of the BICC CS3 signalling requirements for end-to-end QoS service control. The ETSI specifications referenced as base material are available at the following URLs: ETSI TS 301 329 part 2, http://docbox.etsi.org/tech- org/tiphon/Document/tiphon/07- drafts/wg5/_Published/DTS05009/V1.1.1/ts_10 1329-2v111p.doc - ETSI TS 301 329 part 3 see http://docbox.etsi.org/tech- org/tiphon/Document/tiphon/07- drafts/wg5/_Published/DTS05003/DTS05003v096.zi p Further information about the ETSI TIPHON project is available at the following URL: - http://webapp.etsi.org/tbhomepage/TBDetails.as p?TB_ID=291&TB_NAME=TIPHON __________________ BICC CS3 signalling requirements for end-to- end QoS service control EDITORS' NOTE: This requirements text for end-to-end QoS service control is a first draft text and requires extensive updating based on liaison activities with other groups 1 Rationale The rationale of the BICC CS3 requirements for end-to-end service control is based on the analysis made by ETSI TIPHON (see the presentation available at the URL: http://docbox.etsi.org/tech- org/tiphon/Document/tiphon/ARCHIVES/2000/05- 200012- Kyoto/WG5%20TIPHON21%20presentation%20Rev1.ppt ). It shows the inter-relationship between the different QoS factors that finally determine the perceived speech quality by the end- users. This perceived speech quality does not only depend on network quality of service (network packet loss, network jitter and network delay) but on the terminal implementation (jitter buffers and codec performance) as well. A second rationale is that end-to-end QoS requirements can be regarded as end-to-end quality budgets related to the media flows. To achieve the required end-to-end QoS these quality budgets must be allocated between the domains, including the user equipment (see Figure 7 in ETSI TS 301 329 part 3). The Transport QoS Parameters specify the QoS budgets for each Transport Domain. It is assumed that the performance of each domain is statistically independent from any other. Therefore end-to-end QoS service control at the call control level (i.e. application plane) is required based on generic signalling procedures in protocols like BICC, SIP/SDP, H.323 and H.248/MEGACO for end-to- end QoS service control. 2 Framework for end-to-end QoS service control and network QoS control. A framework for QoS control may be considered at different levels: call control (BICC, SIP/SDP, H.323), vertical control (H.248/MEGACO, CBC), bearer control (IP BCP) and bearer (DiffServ, IntServ/RSVP or MPLS/LDP). 1) Call-control a) End-to-end QoS service control is negotiated/communicated end-to-end at the call control level. ETSI TIPHON has defined a set of speech QoS classes, and signalling requirements and flows for this purpose. The idea is that call control protocols are enhanced with a generic end-to-end QoS service control mechanism to negotiate these speech QoS classes and associated parameters (Maximum delay, Maximum packet delay variation, Maximum packet loss, Peak bit rate and Maximum packet size). Such a generic end-to-end QoS service control mechanism should be defined independent of the underlying technology (ATM or IP) and operate across network domains and including terminal characteristics to negotiate/communicate the requested listener speech quality that will be perceived by the end-users (i.e. "mouth-to-ear"). b) BICC (Q.190x) is one of the call control protocols that may be enhanced this way. Similar enhancements may be applicable to other call-control protocols like SIP/SDP and H.323. 2) Vertical control a) QoS service control is also negotiated/communicated at the vertical control level. The ETSI TIPHON defined signalling requirements and flows include the vertical interface. The idea is that vertical control protocols are enhanced to negotiate/communicate the QoS settings (Maximum delay, Maximum packet delay variation, Maximum packet loss, Peak bit rate and Maximum packet size) in the bearer core network based on generic H.248/MEGACO extensions. These QoS settings should be defined independent of the underlying technology (ATM or IP) of the bearer core network. b) CBC (Q.1950) is one of the vertical control protocols that may be enhanced this way. 3) Bearer control a) Network QoS is negotiated/communicated at the bearer control level. ATM signalling does already intrinsically support network QoS. SG13 has recently defined IP QoS classes and IP Transfer Capabilities. The idea is that bearer control protocols for IP are enhanced with a mechanism to negotiate the network QoS by using IP QoS classes and IP Transfer Capabilities. b) IP BCP (Q.1970) is an IP bearer control protocol that may be enhanced this way. 4) Bearer a) Network QoS is negotiated/communicated at the bearer level, i.e. as part of the protocols associated with the bearers in the core network. The idea is that IP QoS classes and IP Transfer Capabilties, as defined by SG13, are used to differentiate between different types of IP traffic. b) IP QoS classes and IP Transfer Capabilities may be used to enhance existing IP mechanisms like DiffServ, IntServ/RSVP and MPLS/LDP. 3 QoS information flows applicable to BICC A general model is considered for QoS information flows with BICC when making a translation of the relevant parts in Figure 8 in ETSI TS 301 329 part 3. Section 4 details the Q.BICC related QoS primitives and parameters based on the QoS primitives and parameters in the ETSI deliverable. Similarly, section 5 provides the Q.CBC related QoS primitives and parameters. 4 Q.BICC related QoS primitives and parameters The Q.BICC related QoS primitives and parameters are extracted from clause 8.1 and clause 8.2 of ETSI TS 101 329 part 3. 4.1 Q.BICC related QoS primitives This information flow (QC2 in ETSI TS 101 329 part 3) communicates the QoS related bearer information between the domains of different service providers. Q.BICC QoS request (Qbicc.QoSreq) requests the establishment of a bearer conforming to a particular ETSI TIPHON Class of Service or with defined QoS characteristics. NOTE Identical to QoSM request (QC2.QoSMreq) in ETSI TS 101 329 part 3 clause 8.1.1. Q.BICC QoS confirm (Qbicc.QoSconf) acknowledges the creation of a bearer conforming to a requested ETSI TIPHON QoS Class or with specified QoS characteristics. NOTE Identical to QoSM confirm (QC2.QoSMconf) in ETSI TS 101 329 part 3 clause 8.1.1. Q.BICC QoS reject (Qbicc.QoSrej) rejects the creation of a bearer conforming to a requested ETSI TIPHON QoS Class or with specified QoS characteristics. NOTE Identical to QoSM reject (QC2.QoSMrej) in ETSI TS 101 329 part 3 clause 8.1.1. Q.BICC release request (Qbicc.QoSrelreq) requests the release of a bearer. NOTE Identical to QoSM release request (QC2.QoSMrelreq) in ETSI TS 101 329 part 3 clause 8.1.1 and the release of a transport flow is already covered by existing Q.BICC procedures in Q.1902 series. QoSM release confirm (Qbicc.QoSrelconf) confirms the release of a bearer. NOTE Identical to QoSM release confirm (QC2.QoSMrelconf) in ETSI TS 101 329 part 3 clause 8.1.1 and the release of a transport flow is already covered by existing Q.BICC procedures in Q.1902 series. 4.2 Q.BICC related QoS parameters Table 1 lists the parameters used in the Q.BICC related QoS primitives not yet covered by the Q.BICC protocol. The deleted items refer to the information elements already covered by the BICC CS2 protocol in the Q.1902 series. NOTE The contents of Table 1 is an interpretation of the table in ETSI TS 101 329 part 3 clause 8.2.3. Table 1: Identification of Q.BICC related parameters for end-to-end QoS service control Qbicc.QoSreq QoS Service Class Optional Codec Type and Packetisation Mandatory Transport QoS Parameters Mandatory Traffic Descriptor Optional Transport Addresses Mandatory Application Data Transport Protocol Optional [Default RTP] Packet Transport Protocol Optional [Default UDP] QoS Mechanism Optional Qbicc.QoSconf QoS Service Class Optional Codec Type and Packetisation Mandatory Transport QoS Parameters Mandatory Transport Addresses Mandatory Application Data Transport Protocol Optional [Default RTP] Packet Transport Protocol Optional [Default UDP] Qbicc.QoSrej Reason [TBD] Mandatory 5 Q.CBC related QoS primitives and parameters The Q.CBC related QoS primitives and parameters are extracted from clause 8.1 and clause 8.2 of ETSI TS 101 329 part 3. 5.1 Q.CBC related QoS primitives This information flow (QT2 in ETSI TS 101 329 part 3) communicates the QoS related transport flow information between a service domain and an associated transport domain. This information contains the QoS related characteristics required of the transport flows that will carry the media flow and the properties of the media flow. Q.CBC QoS request (Qcbc.QoSreq) requests the establishment of a transport flow with defined QoS characteristics across a Transport Domain or the reservation of Transport Domain resource. NOTE Identical to TRM QoS request (QT2.TRMQreq) in ETSI TS 101 329 part 3 clause 8.1.3. Q.CBC QoS confirm (Qcbc.QoSconf) acknowledges the creation of a requested transport flow or the reservation of Transport Domain resource. NOTE Identical to TRM QoS confirm (QT2.TRMQconf) in ETSI TS 101 329 part 3 clause 8.1.3. Q.CBC QoS reject (Qcbc.QoSrej) rejects the creation of a requested transport flow or the reservation of Transport Domain resource. NOTE Identical to TRM QoS reject (QT2.TRMQrej) in ETSI TS 101 329 part 3 clause 8.1.3. Q.CBC QoS release request (Qcbc.QoSrelreq) requests the release of a transport flow. NOTE Identical to TRM QoS release request (QT2.TRM QoS relreq) in ETSI TS 101 329 part 3 clause 8.1.3. The release of a transport flow is already covered by the existing Q.CBC procedures in Q.1950. Q.CBC QoS release confirm (Qcbc.QoSrelconf) confirms the release of a transport flow. NOTE Identical to TRM QoS release confirm (QT2.TRM QoS relconf) in ETSI TS 101 329 part 3 clause 8.1.3. The release of a transport flow is already covered by the existing Q.CBC procedures in Q.1950. Q.CBC QoS performance notification (Qcbc.QoSperfnotif) notifies the Service Domain of the performance of the Transport Domain in meeting the requested QoS levels. This may be a periodic event or an urgent alarm. Note: this primitive is a management primitive and its use is for further study. NOTE Identical to TRM QoS performance notification (QT2.TRM QoS perfnotif) in ETSI TS 101 329 part 3 clause 8.1.3. For further study. 5.2 Q.CBC related QoS parameters Table 2 lists the parameters used in the Q.CBC related QoS primitives not yet covered by the Q.CBC protocol. The deleted items refer to the information elements already covered by the BICC CS2 protocol in Q.1950. NOTE The contents of Table 2 is an interpretation of the table in ETSI TS 101 329 part 3 clause 8.2.5. Table 2: Identification of Q.CBC related parameters for end-to-end QoS service control QT2.TRMQreq Transport QoS Parameters Mandatory Traffic Descriptor Mandatory Transport Addresses Mandatory Packet Transport Protocol Optional [Default UDP] QT2.TRMQconf Transport QoS Parameters Mandatory Transport Addresses Mandatory Packet Transport Protocol Optional [Default UDP] QoS Mechanism Optional QT2.TRMQrej Reason [TBD] Mandatory 6 Parameter contents Table 3 specifies the information to be covered by the parameters listed in sections 4.2 and 5.2 based on the QoS parameter groups in ETSI TS 101 329 part 3 clause 8.2.1. Table 3: Identification of parameter contents for end-to-end QoS service control QoS Service Class Describes the end-to-end ETSI TIPHON Best, High, Medium class of a beareror Best Effort Transport QoS Specifies the QoS characteristics Maximum Delay Parameters required of the transport flow carrying the media flow. Maximum Packet Delay Variation Maximum Packet Loss Traffic Descriptor Characterises the resource Peak Bit requirements of an application data flow (excludes transport flow Maximum Packet Size resource requirements). Parameters specifying the ETSI TIPHON QoS Class as defined in ETSI TS 101 329 Part 2 The maximum delay permitted (ms) over either a segment of the transport flow or the remaining part of the transport flow. The maximum packet delay variation permitted (ms) over either a segment of the transport flow or the remaining part of the transport flow. The maximum packet loss permitted (%) over either a segment of the transport flow or the remaining part of the transport flow. [N.B. This measure assumes randomly distributed packet loss] Maximum bit rate (bit/s) of the media flow. Maximum size of the media packets 7 Information flows and signalling procedures for end-to-end QoS service control EDITORS' NOTE The information flows and signalling procedures for end-to-end QoS service control may be considered to follow the same principles as the already existing procedures for end-to-end codec negotiation in BICC CS1 and BICC CS2. Similarly mid-call procedures for end-to-end QoS modification and mid-call QoS modification may be considered because the perceived QoS is highly related to the codec type employed end- to-end as part of the connection. The exact scope and properties of these procedures and protocol message flows needs further discussion. Greg Ratta, Vice Chairman, ITU-T SG 11, Signalling requirements and protocols Lucent Technologies Tel: +1 732 332 5174, Fax: +1 732 949 1196, gratta@lucent.com _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From owner-megaco@fore.com Fri Jun 1 20:55:50 2001 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA20263 for ; Fri, 1 Jun 2001 20:55:48 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA22482; Fri, 1 Jun 2001 20:46:04 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id UAA15631 for megaco-list; Fri, 1 Jun 2001 20:40:13 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA15625 for ; Fri, 1 Jun 2001 20:40:10 -0400 (EDT) Received: from gateway.hearme.com (gateway.hearme.com [204.242.182.129]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA21581 for ; Fri, 1 Jun 2001 20:40:05 -0400 (EDT) Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01211; Fri, 1 Jun 2001 17:37:49 -0700 (PDT) Received: (from corey@localhost) by nodserv.hearme.com (8.9.1/8.9.1) id RAA28511 for corey@hearme.com; Fri, 1 Jun 2001 17:37:00 -0700 (PDT) Received: from gateway.hearme.com (localhost [127.0.0.1]) by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id HAA09729 for ; Thu, 31 May 2001 07:19:04 -0700 (PDT) Received: from lists.bell-labs.com ([204.178.16.58]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id HAA13804 for ; Thu, 31 May 2001 07:19:04 -0700 (PDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0729444392; Thu, 31 May 2001 10:07:19 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by lists.bell-labs.com (Postfix) with ESMTP id 6CA7044336; Wed, 30 May 2001 18:31:17 -0400 (EDT) Received: from FRED-W2K.cisco.com (fred-hm-dhcp3.cisco.com [171.69.128.118]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f4UMUBU11655; Wed, 30 May 2001 15:30:11 -0700 (PDT) Message-Id: <5.1.0.14.2.20010530152432.043b8ec0@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 To: gratta@lucent.com From: Fred Baker Cc: sob@harvard.edu, mankin@isi.edu, diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org, Yukio Hiramatsu , rbuhrke@lucent.com, tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch, John C Klensin , chair@ietf.org In-Reply-To: <200105302022.QAA03855@hotair.hobl.lucent.com> Mime-Version: 1.0 Subject: [IPTEL] Re: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR END-TO-END QOS SERVICE CONTROL X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Wed, 30 May 2001 15:30:00 -0700 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Greg: The URLs in this note were all sent with what the ETSI machine considered to be 'malformed syntax'. Could you resend the correct URLs? Fred _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From owner-megaco@fore.com Fri Jun 1 20:56:07 2001 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA20274 for ; Fri, 1 Jun 2001 20:56:07 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA22604; Fri, 1 Jun 2001 20:46:57 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id UAA15659 for megaco-list; Fri, 1 Jun 2001 20:40:48 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA15647 for ; Fri, 1 Jun 2001 20:40:40 -0400 (EDT) Received: from gateway.hearme.com (gateway.hearme.com [204.242.182.129]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA21622 for ; Fri, 1 Jun 2001 20:40:25 -0400 (EDT) Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01217; Fri, 1 Jun 2001 17:38:28 -0700 (PDT) Received: (from corey@localhost) by nodserv.hearme.com (8.9.1/8.9.1) id RAA28532 for corey@hearme.com; Fri, 1 Jun 2001 17:37:49 -0700 (PDT) Received: from gateway.hearme.com (localhost [127.0.0.1]) by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id HAA09779 for ; Thu, 31 May 2001 07:25:19 -0700 (PDT) Received: from lists.bell-labs.com ([204.178.16.58]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id HAA13879 for ; Thu, 31 May 2001 07:25:18 -0700 (PDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B28F3443AB; Thu, 31 May 2001 10:07:24 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by lists.bell-labs.com (Postfix) with ESMTP id B9C0B44336; Wed, 30 May 2001 19:39:31 -0400 (EDT) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f4UNdHZ03453; Wed, 30 May 2001 16:39:17 -0700 (PDT) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id XAA13198; Wed, 30 May 2001 23:39:17 GMT Message-Id: <200105302339.XAA13198@gra.isi.edu> To: gratta@lucent.com, sob@harvard.edu, mankin@isi.edu, rrroy@att.com Cc: diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org, hiramatsu.yukio@lab.ntt.co.jp, rbuhrke@lucent.com, tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch, ITU-SG16@mailbag.cps.INTEL.COM X-Sun-Charset: US-ASCII Subject: [IPTEL] RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Wed, 30 May 2001 23:39:17 GMT Content-Type: text Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk *> From owner-issll@mercury.lcs.mit.edu Wed May 30 14:59:58 2001 *> From: "Roy, Radhika R, ALCTA" *> To: gratta@lucent.com, sob@harvard.edu, mankin@ISI.EDU *> Cc: diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, *> megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org, *> Yukio Hiramatsu *> , rbuhrke@lucent.com, *> tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch, ITU-SG16@mailbag.cps.INTEL.COM *> Subject: RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E *> ND-TO-END QOS SERVICE CONTROL *> Date: Wed, 30 May 2001 17:21:14 -0400 *> MIME-Version: 1.0 *> *> Hi, Everyone: *> *> Question Q.F/16 of ITU-T SG16 is fully dedicated for developing standards *> for "End-to-End QOS for Multimedia Applications". Contributions are also *> being under discussion in the ITU-T SG16 Brazil May 28 - June 8, 2001 *> meeting. This is very confusing. "End-to-End QOS for Multimedia Applications" is an really important topic, but this topic must be a superset of "End-to-End QOS signaling". There are much harder problems than signaling in providing E2E QoS. Can you explain how signaling relates to the title of this working party? Thanks, Bob Braden *> *> Applications like H.323, SIP, H.324, H.310, and others will also be able to *> use this Q.F/16's QOS signaling protocol. MEGACO/H.248 and BICC will also be *> able to use this when specs are fully developed and, TIPHON's QOS mechanisms *> can also be used as one of the mechanisms for implementations. _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From owner-megaco@fore.com Fri Jun 1 20:57:03 2001 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA20303 for ; Fri, 1 Jun 2001 20:57:02 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA22744; Fri, 1 Jun 2001 20:48:35 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id UAA15761 for megaco-list; Fri, 1 Jun 2001 20:42:11 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA15757 for ; Fri, 1 Jun 2001 20:42:04 -0400 (EDT) Received: from gateway.hearme.com (gateway.hearme.com [204.242.182.129]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA21858 for ; Fri, 1 Jun 2001 20:41:58 -0400 (EDT) Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01242; Fri, 1 Jun 2001 17:39:53 -0700 (PDT) Received: (from corey@localhost) by nodserv.hearme.com (8.9.1/8.9.1) id RAA28538 for corey@hearme.com; Fri, 1 Jun 2001 17:38:42 -0700 (PDT) Received: from gateway.hearme.com (localhost [127.0.0.1]) by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id HAA09857 for ; Thu, 31 May 2001 07:34:35 -0700 (PDT) Received: from lists.bell-labs.com ([204.178.16.58]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id HAA13986 for ; Thu, 31 May 2001 07:34:34 -0700 (PDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CBDDA443B7; Thu, 31 May 2001 10:07:29 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69]) by lists.bell-labs.com (Postfix) with ESMTP id 6A90144336; Thu, 31 May 2001 09:10:54 -0400 (EDT) Received: from gab200r1.ems.att.com ([135.37.94.32]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id f4VD8wC16127; Thu, 31 May 2001 09:08:58 -0400 (EDT) Received: from njb140bh1.ems.att.com by gab200r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id JAA04890; Thu, 31 May 2001 09:08:30 -0400 (EDT) Received: by njb140bh1.ems.att.com with Internet Mail Service (5.5.2653.19) id ; Thu, 31 May 2001 09:08:52 -0400 Message-ID: From: "Roy, Radhika R, ALCTA" To: Bob Braden , gratta@lucent.com, sob@harvard.edu, mankin@isi.edu Cc: diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org, hiramatsu.yukio@lab.ntt.co.jp, rbuhrke@lucent.com, tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch, ITU-SG16@mailbag.cps.INTEL.COM MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: [IPTEL] RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Thu, 31 May 2001 09:08:45 -0400 Content-Type: text/plain; charset="iso-8859-1" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Hi, Bob: All applications (e.g., H.323, SIP) uses signaling messages among its functional entities (e.g., terminal, agents, gatekeepers, proxies, gateways) for communications. The signaling messages that carry QOS parameters are treated as QOS signaling messages. The applications like SIP and H.323 send signaling messages end-to-end. H.323 uses H.225.0 RAS, Q.931, Annex G, and H.245 signaling protocols. SIP also uses SDP as a part of the signaling messages. The signaling messages that carry QOS related information can be treated as "End-to-End QOS signaling" messages. Kindly see the ongoing works of Q.F/16 of SG16. This will provide more information related to your questions. Hope this helps. Best regards, Radhika R. Roy -----Original Message----- From: Bob Braden [mailto:braden@ISI.EDU] Sent: Wednesday, May 30, 2001 7:39 PM To: gratta@lucent.com; sob@harvard.edu; mankin@ISI.EDU; Roy, Radhika R, ALCTA Cc: diffserv@ietf.org; iptel@lists.bell-labs.com; issll@mercury.lcs.mit.edu; megaco@fore.com; sip@lists.bell-labs.com; sipping@ietf.org; tsvwg@ietf.org; hiramatsu.yukio@lab.ntt.co.jp; rbuhrke@lucent.com; tsg11q8@ties.itu.ch; tsg11q9@ties.itu.ch; ITU-SG16@mailbag.cps.INTEL.COM Subject: RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL *> From owner-issll@mercury.lcs.mit.edu Wed May 30 14:59:58 2001 *> From: "Roy, Radhika R, ALCTA" *> To: gratta@lucent.com, sob@harvard.edu, mankin@ISI.EDU *> Cc: diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, *> megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org, *> Yukio Hiramatsu *> , rbuhrke@lucent.com, *> tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch, ITU-SG16@mailbag.cps.INTEL.COM *> Subject: RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E *> ND-TO-END QOS SERVICE CONTROL *> Date: Wed, 30 May 2001 17:21:14 -0400 *> MIME-Version: 1.0 *> *> Hi, Everyone: *> *> Question Q.F/16 of ITU-T SG16 is fully dedicated for developing standards *> for "End-to-End QOS for Multimedia Applications". Contributions are also *> being under discussion in the ITU-T SG16 Brazil May 28 - June 8, 2001 *> meeting. This is very confusing. "End-to-End QOS for Multimedia Applications" is an really important topic, but this topic must be a superset of "End-to-End QOS signaling". There are much harder problems than signaling in providing E2E QoS. Can you explain how signaling relates to the title of this working party? Thanks, Bob Braden *> *> Applications like H.323, SIP, H.324, H.310, and others will also be able to *> use this Q.F/16's QOS signaling protocol. MEGACO/H.248 and BICC will also be *> able to use this when specs are fully developed and, TIPHON's QOS mechanisms *> can also be used as one of the mechanisms for implementations. _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From owner-megaco@fore.com Fri Jun 1 21:09:31 2001 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA20470 for ; Fri, 1 Jun 2001 21:09:26 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id VAA24218; Fri, 1 Jun 2001 21:01:39 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id UAA16726 for megaco-list; Fri, 1 Jun 2001 20:57:05 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA16678 for ; Fri, 1 Jun 2001 20:56:56 -0400 (EDT) Received: from gateway.hearme.com (gateway.hearme.com [204.242.182.129]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA23625 for ; Fri, 1 Jun 2001 20:56:48 -0400 (EDT) Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01644; Fri, 1 Jun 2001 17:54:49 -0700 (PDT) Received: (from corey@localhost) by nodserv.hearme.com (8.9.1/8.9.1) id RAA28810 for corey@hearme.com; Fri, 1 Jun 2001 17:53:44 -0700 (PDT) Received: from gateway.hearme.com (localhost [127.0.0.1]) by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id LAA13663 for ; Thu, 31 May 2001 11:28:59 -0700 (PDT) Received: from lists.bell-labs.com ([204.178.16.58]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id LAA18167 for ; Thu, 31 May 2001 11:28:54 -0700 (PDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 12FC944472; Thu, 31 May 2001 14:11:10 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69]) by lists.bell-labs.com (Postfix) with ESMTP id 9BDA5443A3; Thu, 31 May 2001 13:53:46 -0400 (EDT) Received: from gab200r1.ems.att.com ([135.37.94.32]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id f4VHpPC24217; Thu, 31 May 2001 13:51:25 -0400 (EDT) Received: from njb140bh1.ems.att.com by gab200r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id NAA00157; Thu, 31 May 2001 13:51:00 -0400 (EDT) Received: by njb140bh1.ems.att.com with Internet Mail Service (5.5.2653.19) id ; Thu, 31 May 2001 13:51:22 -0400 Message-ID: From: "Roy, Radhika R, ALCTA" To: Fred Baker Cc: Bob Braden , gratta@lucent.com, sob@harvard.edu, mankin@isi.edu, diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org, hiramatsu.yukio@lab.ntt.co.jp, rbuhrke@lucent.com, tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch, ITU-SG16@mailbag.cps.INTEL.COM MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: [IPTEL] RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Thu, 31 May 2001 13:51:09 -0400 Content-Type: text/plain; charset="iso-8859-1" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Hi, Baker: It appears that a good amount discussion can be started to answer your questions (what has being discussed for the last couple of years in the ITU-T and TIPHON in particular). I am not trying to do so. Let me answer your questions summarizing the key points as follows: 1. Broadly, all applications can be considered in two categories: a. Real-time (e.g., audio, video [of H.323/SIP]) and b. Non-Real-time (e.g., data applications like file transfer, WWW, Mail, etc. - can a part of H.323/SIP). The performance parameters of both real-time (audio, video) and non-real-time (data) traffic can be abstracted in an universal way that can be used by all applications (e.g., H.323, SIP, WWW, mail, etc). However, the signaling messages used by each application are application-specific although the QOS parameters used by all of them still remain same (e.g., H.323 might use RAS/Q.931/Annex-G/H.245 signaling messages, SIP might use SDP). The QOS signaling messages that use QOS parameters can be termed as the application layer QOS signaling messages and are sent on end-to-end basis and the values of those QOS parameters do not change no matter what may be the underlying transport networks (e.g., IP, ATM). 2. The network layer QOS signaling messages carried over the network may not be end-to-end significance. For example, an end-to-end path of an IP network may consist of RSVP, DiffServ, MPLS, and RSVP. So, the network layer QOS parameters may get translated between the source-destination path and may not remain the same what has been negotiated on end-to-end basis in the application layer (item 1). The problems that are being addressed are as follows: A. How to develop the end-to-end QOS signaling mechanisms in the application layer B. How to relate the application layer QOS signaling to the network layer QOS signaling (e.g., RSVP, DifServ, MPLS, etc.) so that one-to-one consistency remain between the application and network layer QOS parameters. Hope this may clarify some of your questions. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Fred Baker [mailto:fred@cisco.com] Sent: Thursday, May 31, 2001 1:09 PM To: Roy, Radhika R, ALCTA Cc: Bob Braden; gratta@lucent.com; sob@harvard.edu; mankin@isi.edu; diffserv@ietf.org; iptel@lists.bell-labs.com; issll@mercury.lcs.mit.edu; megaco@fore.com; sip@lists.bell-labs.com; sipping@ietf.org; tsvwg@ietf.org; hiramatsu.yukio@lab.ntt.co.jp; rbuhrke@lucent.com; tsg11q8@ties.itu.ch; tsg11q9@ties.itu.ch; ITU-SG16@mailbag.cps.INTEL.COM Subject: RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL At 06:08 AM 5/31/2001, Roy, Radhika R, ALCTA wrote: >All applications (e.g., H.323, SIP) uses signaling messages >among its functional entities (e.g., terminal, agents, >gatekeepers, proxies, gateways) for communications. I'm not sure we're on the same planet. Please help me out here. I can think of a few applications that have agents, gatekeepers, proxies, and gateways, mostly resulting from the imposition of firewalls or authentication systems, or from legacy applications like imitating the telephone system in a data network. The only one that *requires* any kind of gateway, to my knowledge, is H.323 teleconferencing, which represents a paltry fraction of traffic according to most current measurements. Anything else (75% of Internet traffic is http or FTP, most of the rest is mail, on private LANs applications like NFS are pretty common, and even SIP can be done without a gateway between consenting systems) could be hooked up in separate systems on a LAN and made to work without any such signalling at all. Could you be more specific on what QoS signalling is required by the world wide web, mail, FTP, common ERP applications like ERP and PeopleSoft, calendaring, and so on? If not, could you be more specific about what "all" applications you have in mind? And could you be more specific about what issues this proposal is addressing that have not already been addressed in de facto standards and deployed in operational systems? It would be very nice to understand what you are preparing to ask vendors to do, and whether operators are interested in deploying them. _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From owner-megaco@fore.com Fri Jun 1 21:11:39 2001 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA20535 for ; Fri, 1 Jun 2001 21:11:38 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id VAA24269; Fri, 1 Jun 2001 21:02:01 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id UAA16604 for megaco-list; Fri, 1 Jun 2001 20:56:06 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA16594 for ; Fri, 1 Jun 2001 20:56:03 -0400 (EDT) Received: from gateway.hearme.com (gateway.hearme.com [204.242.182.129]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA23535 for ; Fri, 1 Jun 2001 20:55:55 -0400 (EDT) Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01628; Fri, 1 Jun 2001 17:53:43 -0700 (PDT) Received: (from corey@localhost) by nodserv.hearme.com (8.9.1/8.9.1) id RAA28792 for corey@hearme.com; Fri, 1 Jun 2001 17:52:27 -0700 (PDT) Received: from gateway.hearme.com (localhost [127.0.0.1]) by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id LAA13287 for ; Thu, 31 May 2001 11:03:42 -0700 (PDT) Received: from optimus.ietf.org ([132.151.1.19]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id LAA17729 for ; Thu, 31 May 2001 11:03:40 -0700 (PDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA26657; Thu, 31 May 2001 14:01:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA25888 for ; Thu, 31 May 2001 13:53:44 -0400 (EDT) Received: from ckmso1.proxy.att.com ([12.20.58.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA03801; Thu, 31 May 2001 13:53:19 -0400 (EDT) Received: from gab200r1.ems.att.com ([135.37.94.32]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id f4VHpPC24217; Thu, 31 May 2001 13:51:25 -0400 (EDT) Received: from njb140bh1.ems.att.com by gab200r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id NAA00157; Thu, 31 May 2001 13:51:00 -0400 (EDT) Received: by njb140bh1.ems.att.com with Internet Mail Service (5.5.2653.19) id ; Thu, 31 May 2001 13:51:22 -0400 Message-ID: From: "Roy, Radhika R, ALCTA" To: Fred Baker Cc: Bob Braden , gratta@lucent.com, sob@harvard.edu, mankin@isi.edu, diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org, hiramatsu.yukio@lab.ntt.co.jp, rbuhrke@lucent.com, tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch, ITU-SG16@mailbag.cps.INTEL.COM Date: Thu, 31 May 2001 13:51:09 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: [Sipping] RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL X-Mailman-Version: 1.0 List-Id: SIPPING Working Group (applications of SIP) X-BeenThere: sipping@ietf.org Content-Type: text/plain; charset="iso-8859-1" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Hi, Baker: It appears that a good amount discussion can be started to answer your questions (what has being discussed for the last couple of years in the ITU-T and TIPHON in particular). I am not trying to do so. Let me answer your questions summarizing the key points as follows: 1. Broadly, all applications can be considered in two categories: a. Real-time (e.g., audio, video [of H.323/SIP]) and b. Non-Real-time (e.g., data applications like file transfer, WWW, Mail, etc. - can a part of H.323/SIP). The performance parameters of both real-time (audio, video) and non-real-time (data) traffic can be abstracted in an universal way that can be used by all applications (e.g., H.323, SIP, WWW, mail, etc). However, the signaling messages used by each application are application-specific although the QOS parameters used by all of them still remain same (e.g., H.323 might use RAS/Q.931/Annex-G/H.245 signaling messages, SIP might use SDP). The QOS signaling messages that use QOS parameters can be termed as the application layer QOS signaling messages and are sent on end-to-end basis and the values of those QOS parameters do not change no matter what may be the underlying transport networks (e.g., IP, ATM). 2. The network layer QOS signaling messages carried over the network may not be end-to-end significance. For example, an end-to-end path of an IP network may consist of RSVP, DiffServ, MPLS, and RSVP. So, the network layer QOS parameters may get translated between the source-destination path and may not remain the same what has been negotiated on end-to-end basis in the application layer (item 1). The problems that are being addressed are as follows: A. How to develop the end-to-end QOS signaling mechanisms in the application layer B. How to relate the application layer QOS signaling to the network layer QOS signaling (e.g., RSVP, DifServ, MPLS, etc.) so that one-to-one consistency remain between the application and network layer QOS parameters. Hope this may clarify some of your questions. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Fred Baker [mailto:fred@cisco.com] Sent: Thursday, May 31, 2001 1:09 PM To: Roy, Radhika R, ALCTA Cc: Bob Braden; gratta@lucent.com; sob@harvard.edu; mankin@isi.edu; diffserv@ietf.org; iptel@lists.bell-labs.com; issll@mercury.lcs.mit.edu; megaco@fore.com; sip@lists.bell-labs.com; sipping@ietf.org; tsvwg@ietf.org; hiramatsu.yukio@lab.ntt.co.jp; rbuhrke@lucent.com; tsg11q8@ties.itu.ch; tsg11q9@ties.itu.ch; ITU-SG16@mailbag.cps.INTEL.COM Subject: RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL At 06:08 AM 5/31/2001, Roy, Radhika R, ALCTA wrote: >All applications (e.g., H.323, SIP) uses signaling messages >among its functional entities (e.g., terminal, agents, >gatekeepers, proxies, gateways) for communications. I'm not sure we're on the same planet. Please help me out here. I can think of a few applications that have agents, gatekeepers, proxies, and gateways, mostly resulting from the imposition of firewalls or authentication systems, or from legacy applications like imitating the telephone system in a data network. The only one that *requires* any kind of gateway, to my knowledge, is H.323 teleconferencing, which represents a paltry fraction of traffic according to most current measurements. Anything else (75% of Internet traffic is http or FTP, most of the rest is mail, on private LANs applications like NFS are pretty common, and even SIP can be done without a gateway between consenting systems) could be hooked up in separate systems on a LAN and made to work without any such signalling at all. Could you be more specific on what QoS signalling is required by the world wide web, mail, FTP, common ERP applications like ERP and PeopleSoft, calendaring, and so on? If not, could you be more specific about what "all" applications you have in mind? And could you be more specific about what issues this proposal is addressing that have not already been addressed in de facto standards and deployed in operational systems? It would be very nice to understand what you are preparing to ask vendors to do, and whether operators are interested in deploying them. _______________________________________________ Sipping mailing list Sipping@ietf.org http://www.ietf.org/mailman/listinfo/sipping From owner-megaco@fore.com Fri Jun 1 21:12:36 2001 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA20547 for ; Fri, 1 Jun 2001 21:12:35 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id VAA24513; Fri, 1 Jun 2001 21:03:28 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id UAA16832 for megaco-list; Fri, 1 Jun 2001 20:58:17 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA16816 for ; Fri, 1 Jun 2001 20:58:03 -0400 (EDT) Received: from gateway.hearme.com (gateway.hearme.com [204.242.182.129]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA23725 for ; Fri, 1 Jun 2001 20:57:39 -0400 (EDT) Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01666; Fri, 1 Jun 2001 17:55:49 -0700 (PDT) Received: (from corey@localhost) by nodserv.hearme.com (8.9.1/8.9.1) id RAA28823 for corey@hearme.com; Fri, 1 Jun 2001 17:54:50 -0700 (PDT) Received: from gateway.hearme.com (localhost [127.0.0.1]) by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id LAA13983 for ; Thu, 31 May 2001 11:49:27 -0700 (PDT) Received: from lists.bell-labs.com ([204.178.16.58]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id LAA18575 for ; Thu, 31 May 2001 11:49:26 -0700 (PDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A64184442D; Thu, 31 May 2001 10:29:15 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from kcmso1.proxy.att.com (kcmso1.att.com [192.128.133.69]) by lists.bell-labs.com (Postfix) with ESMTP id 789E544336; Wed, 30 May 2001 17:23:12 -0400 (EDT) Received: from njb140r1.ems.att.com ([135.65.202.58]) by kcmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id f4ULLMD18676; Wed, 30 May 2001 17:21:22 -0400 (EDT) Received: from njb140bh2.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id RAA19071; Wed, 30 May 2001 17:20:06 -0400 (EDT) Received: by njb140bh2.ems.att.com with Internet Mail Service (5.5.2653.19) id ; Wed, 30 May 2001 17:21:20 -0400 Message-ID: From: "Roy, Radhika R, ALCTA" To: gratta@lucent.com, sob@harvard.edu, mankin@isi.edu Cc: diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org, Yukio Hiramatsu , rbuhrke@lucent.com, tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch, ITU-SG16@mailbag.cps.INTEL.COM MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: [SIP] RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 30 May 2001 17:21:14 -0400 Content-Type: text/plain; charset="iso-8859-1" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Hi, Everyone: Question Q.F/16 of ITU-T SG16 is fully dedicated for developing standards for "End-to-End QOS for Multimedia Applications". Contributions are also being under discussion in the ITU-T SG16 Brazil May 28 - June 8, 2001 meeting. Applications like H.323, SIP, H.324, H.310, and others will also be able to use this Q.F/16's QOS signaling protocol. MEGACO/H.248 and BICC will also be able to use this when specs are fully developed and, TIPHON's QOS mechanisms can also be used as one of the mechanisms for implementations. BICC and MEGCAO/H.248 are only used as the protocol between the gateways, NOT end-to-end (although SIP/H.323 or other protocols may be used between the gateways). The "End-to-End QOS for Multimedia Applications" of SG16 can also be termed as "Application Layer QOS." Q.F/16's end-to-end application layer QOS can also be implemented over the network layer QOS like RSVP, DiffServe, and/or MPLS after proper mapping. Similar is the case for the ATM network. Please note that the network layer QOS (e.g., RSVP, DiffServe, and/or MPLS) may or may not have the end-to-end significance. For example, an IP network may implement different QOS schemes in different domains (e.g., RVSP in one domain, DiffServ in another domain). However, the application layer QOS is end-to-end that remains the same. For example, an H.323 or SIP call that can traverse several IP domains where each domain may implement its own network layer QOS schemes while the H.323/SIP call carry the signaling messages and QOS parameters end-to-end independent of the underlying network layer QOS mechanisms. Let us work together. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Greg Ratta [mailto:gratta@lucent.com] Sent: Wednesday, May 30, 2001 4:22 PM To: sob@harvard.edu; mankin@isi.edu Cc: diffserv@ietf.org; iptel@lists.bell-labs.com; issll@mercury.lcs.mit.edu; megaco@fore.com; sip@lists.bell-labs.com; sipping@ietf.org; tsvwg@ietf.org; Yukio Hiramatsu; rbuhrke@lucent.com; tsg11q8@ties.itu.ch; tsg11q9@ties.itu.ch Subject: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR END-TO-END QOS SERVICE CONTROL This message was agreed to at ITU-T Study Group 11 meeting (Geneva, May 2001) and is being transmitted on behalf of Yukio Hiramatsu, Chairman of ITU-T SG 11. For further technical clarification, contact the Rapporteur for Q9/11 (Rolfe Buhrke, Tel: + 1 630 713 7022, { HYPERLINK mailto:rburke@lucent.com }rbuhrke@lucent.com) FULL TITLE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR END-TO-END QOS SERVICE CONTROL AND SIGNALLING PROTOCOL DEVELOPMENT BASED ON IP TRANSFER CAPABILITIES AND IP QOS CLASSES General Within ITU-T SG11 work has started on requirements for a generic protocol mechanism for end-to-end QoS service control. It was agreed within SG11 to proceed with this work utilising deliverables of ETSI TIPHON on end- to-end QoS service control as base material. It is the opinion of SG11 that this generic protocol mechanism for BICC intends to apply also to other protocols like SIP/SDP and H.323 next to generic extensions to the H.248/MEGACO protocol. It was noted that also QoS related work is in progress in IETF. Please find attached an initial draft of the BICC CS3 signalling requirements for end-to-end QoS service control. Please note the rationale for this activity and the framework for end-to-end QoS service control and network QoS control. The framework illustrates the field of application of the QoS handling at different levels and the different protocols involved. Proposals on end-to-end QoS service control It is proposed to start a joint activity with IETF on a generic protocol mechanism for end- to-end QoS service control. This refers to the potential work in IETF on the following topics: - Identification of the signalling requirements based on the ETSI TIPHON defined speech QoS service classes for VoIP and the signalling and control of end-to-end QoS for VoIP. The attachment provides the initial draft of the BICC CS3 signalling requirements for end-to-end QoS service control. - The definition of a generic call/bearer control mechanism in H.225/H.245, SIP/SDP and BICC CS3 for end-to-end QoS service control in the application plane. - The definition of generic extensions to H.248/MEGACO for end-to-end QoS service control between the application plane and the transport plane. - The translation between the generic protocol QoS information elements in H.248/MEGACO and the technology specific QoS parameters and QoS mechanisms in IP, ATM, MPLS, etc. Proposals on IP QoS classes and IP Transfer Capabilities ITU-T SG11 would like to inform IETF that it is investigating signalling requirements for protocol development based on the IP Transfer Capabilities and IP QoS classes, as being defined by ITU-T SG13 in Y.1541 and Y.iptc. The plan is to build upon signalling approaches developed by IETF. We would like to stress that the work on IP QoS classes and IP Transfer Capabilities by ITU-T SG13 is co- ordinated with IETF. ATTACHMENT Initial draft text of the BICC CS3 signalling requirements for end-to-end QoS service control. The ETSI specifications referenced as base material are available at the following URLs: ETSI TS 301 329 part 2, http://docbox.etsi.org/tech- org/tiphon/Document/tiphon/07- drafts/wg5/_Published/DTS05009/V1.1.1/ts_10 1329-2v111p.doc - ETSI TS 301 329 part 3 see http://docbox.etsi.org/tech- org/tiphon/Document/tiphon/07- drafts/wg5/_Published/DTS05003/DTS05003v096.zi p Further information about the ETSI TIPHON project is available at the following URL: - http://webapp.etsi.org/tbhomepage/TBDetails.as p?TB_ID=291&TB_NAME=TIPHON __________________ BICC CS3 signalling requirements for end-to- end QoS service control EDITORS' NOTE: This requirements text for end-to-end QoS service control is a first draft text and requires extensive updating based on liaison activities with other groups 1 Rationale The rationale of the BICC CS3 requirements for end-to-end service control is based on the analysis made by ETSI TIPHON (see the presentation available at the URL: http://docbox.etsi.org/tech- org/tiphon/Document/tiphon/ARCHIVES/2000/05- 200012- Kyoto/WG5%20TIPHON21%20presentation%20Rev1.ppt ). It shows the inter-relationship between the different QoS factors that finally determine the perceived speech quality by the end- users. This perceived speech quality does not only depend on network quality of service (network packet loss, network jitter and network delay) but on the terminal implementation (jitter buffers and codec performance) as well. A second rationale is that end-to-end QoS requirements can be regarded as end-to-end quality budgets related to the media flows. To achieve the required end-to-end QoS these quality budgets must be allocated between the domains, including the user equipment (see Figure 7 in ETSI TS 301 329 part 3). The Transport QoS Parameters specify the QoS budgets for each Transport Domain. It is assumed that the performance of each domain is statistically independent from any other. Therefore end-to-end QoS service control at the call control level (i.e. application plane) is required based on generic signalling procedures in protocols like BICC, SIP/SDP, H.323 and H.248/MEGACO for end-to- end QoS service control. 2 Framework for end-to-end QoS service control and network QoS control. A framework for QoS control may be considered at different levels: call control (BICC, SIP/SDP, H.323), vertical control (H.248/MEGACO, CBC), bearer control (IP BCP) and bearer (DiffServ, IntServ/RSVP or MPLS/LDP). 1) Call-control a) End-to-end QoS service control is negotiated/communicated end-to-end at the call control level. ETSI TIPHON has defined a set of speech QoS classes, and signalling requirements and flows for this purpose. The idea is that call control protocols are enhanced with a generic end-to-end QoS service control mechanism to negotiate these speech QoS classes and associated parameters (Maximum delay, Maximum packet delay variation, Maximum packet loss, Peak bit rate and Maximum packet size). Such a generic end-to-end QoS service control mechanism should be defined independent of the underlying technology (ATM or IP) and operate across network domains and including terminal characteristics to negotiate/communicate the requested listener speech quality that will be perceived by the end-users (i.e. "mouth-to-ear"). b) BICC (Q.190x) is one of the call control protocols that may be enhanced this way. Similar enhancements may be applicable to other call-control protocols like SIP/SDP and H.323. 2) Vertical control a) QoS service control is also negotiated/communicated at the vertical control level. The ETSI TIPHON defined signalling requirements and flows include the vertical interface. The idea is that vertical control protocols are enhanced to negotiate/communicate the QoS settings (Maximum delay, Maximum packet delay variation, Maximum packet loss, Peak bit rate and Maximum packet size) in the bearer core network based on generic H.248/MEGACO extensions. These QoS settings should be defined independent of the underlying technology (ATM or IP) of the bearer core network. b) CBC (Q.1950) is one of the vertical control protocols that may be enhanced this way. 3) Bearer control a) Network QoS is negotiated/communicated at the bearer control level. ATM signalling does already intrinsically support network QoS. SG13 has recently defined IP QoS classes and IP Transfer Capabilities. The idea is that bearer control protocols for IP are enhanced with a mechanism to negotiate the network QoS by using IP QoS classes and IP Transfer Capabilities. b) IP BCP (Q.1970) is an IP bearer control protocol that may be enhanced this way. 4) Bearer a) Network QoS is negotiated/communicated at the bearer level, i.e. as part of the protocols associated with the bearers in the core network. The idea is that IP QoS classes and IP Transfer Capabilties, as defined by SG13, are used to differentiate between different types of IP traffic. b) IP QoS classes and IP Transfer Capabilities may be used to enhance existing IP mechanisms like DiffServ, IntServ/RSVP and MPLS/LDP. 3 QoS information flows applicable to BICC A general model is considered for QoS information flows with BICC when making a translation of the relevant parts in Figure 8 in ETSI TS 301 329 part 3. Section 4 details the Q.BICC related QoS primitives and parameters based on the QoS primitives and parameters in the ETSI deliverable. Similarly, section 5 provides the Q.CBC related QoS primitives and parameters. 4 Q.BICC related QoS primitives and parameters The Q.BICC related QoS primitives and parameters are extracted from clause 8.1 and clause 8.2 of ETSI TS 101 329 part 3. 4.1 Q.BICC related QoS primitives This information flow (QC2 in ETSI TS 101 329 part 3) communicates the QoS related bearer information between the domains of different service providers. Q.BICC QoS request (Qbicc.QoSreq) requests the establishment of a bearer conforming to a particular ETSI TIPHON Class of Service or with defined QoS characteristics. NOTE Identical to QoSM request (QC2.QoSMreq) in ETSI TS 101 329 part 3 clause 8.1.1. Q.BICC QoS confirm (Qbicc.QoSconf) acknowledges the creation of a bearer conforming to a requested ETSI TIPHON QoS Class or with specified QoS characteristics. NOTE Identical to QoSM confirm (QC2.QoSMconf) in ETSI TS 101 329 part 3 clause 8.1.1. Q.BICC QoS reject (Qbicc.QoSrej) rejects the creation of a bearer conforming to a requested ETSI TIPHON QoS Class or with specified QoS characteristics. NOTE Identical to QoSM reject (QC2.QoSMrej) in ETSI TS 101 329 part 3 clause 8.1.1. Q.BICC release request (Qbicc.QoSrelreq) requests the release of a bearer. NOTE Identical to QoSM release request (QC2.QoSMrelreq) in ETSI TS 101 329 part 3 clause 8.1.1 and the release of a transport flow is already covered by existing Q.BICC procedures in Q.1902 series. QoSM release confirm (Qbicc.QoSrelconf) confirms the release of a bearer. NOTE Identical to QoSM release confirm (QC2.QoSMrelconf) in ETSI TS 101 329 part 3 clause 8.1.1 and the release of a transport flow is already covered by existing Q.BICC procedures in Q.1902 series. 4.2 Q.BICC related QoS parameters Table 1 lists the parameters used in the Q.BICC related QoS primitives not yet covered by the Q.BICC protocol. The deleted items refer to the information elements already covered by the BICC CS2 protocol in the Q.1902 series. NOTE The contents of Table 1 is an interpretation of the table in ETSI TS 101 329 part 3 clause 8.2.3. Table 1: Identification of Q.BICC related parameters for end-to-end QoS service control Qbicc.QoSreq QoS Service Class Optional Codec Type and Packetisation Mandatory Transport QoS Parameters Mandatory Traffic Descriptor Optional Transport Addresses Mandatory Application Data Transport Protocol Optional [Default RTP] Packet Transport Protocol Optional [Default UDP] QoS Mechanism Optional Qbicc.QoSconf QoS Service Class Optional Codec Type and Packetisation Mandatory Transport QoS Parameters Mandatory Transport Addresses Mandatory Application Data Transport Protocol Optional [Default RTP] Packet Transport Protocol Optional [Default UDP] Qbicc.QoSrej Reason [TBD] Mandatory 5 Q.CBC related QoS primitives and parameters The Q.CBC related QoS primitives and parameters are extracted from clause 8.1 and clause 8.2 of ETSI TS 101 329 part 3. 5.1 Q.CBC related QoS primitives This information flow (QT2 in ETSI TS 101 329 part 3) communicates the QoS related transport flow information between a service domain and an associated transport domain. This information contains the QoS related characteristics required of the transport flows that will carry the media flow and the properties of the media flow. Q.CBC QoS request (Qcbc.QoSreq) requests the establishment of a transport flow with defined QoS characteristics across a Transport Domain or the reservation of Transport Domain resource. NOTE Identical to TRM QoS request (QT2.TRMQreq) in ETSI TS 101 329 part 3 clause 8.1.3. Q.CBC QoS confirm (Qcbc.QoSconf) acknowledges the creation of a requested transport flow or the reservation of Transport Domain resource. NOTE Identical to TRM QoS confirm (QT2.TRMQconf) in ETSI TS 101 329 part 3 clause 8.1.3. Q.CBC QoS reject (Qcbc.QoSrej) rejects the creation of a requested transport flow or the reservation of Transport Domain resource. NOTE Identical to TRM QoS reject (QT2.TRMQrej) in ETSI TS 101 329 part 3 clause 8.1.3. Q.CBC QoS release request (Qcbc.QoSrelreq) requests the release of a transport flow. NOTE Identical to TRM QoS release request (QT2.TRM QoS relreq) in ETSI TS 101 329 part 3 clause 8.1.3. The release of a transport flow is already covered by the existing Q.CBC procedures in Q.1950. Q.CBC QoS release confirm (Qcbc.QoSrelconf) confirms the release of a transport flow. NOTE Identical to TRM QoS release confirm (QT2.TRM QoS relconf) in ETSI TS 101 329 part 3 clause 8.1.3. The release of a transport flow is already covered by the existing Q.CBC procedures in Q.1950. Q.CBC QoS performance notification (Qcbc.QoSperfnotif) notifies the Service Domain of the performance of the Transport Domain in meeting the requested QoS levels. This may be a periodic event or an urgent alarm. Note: this primitive is a management primitive and its use is for further study. NOTE Identical to TRM QoS performance notification (QT2.TRM QoS perfnotif) in ETSI TS 101 329 part 3 clause 8.1.3. For further study. 5.2 Q.CBC related QoS parameters Table 2 lists the parameters used in the Q.CBC related QoS primitives not yet covered by the Q.CBC protocol. The deleted items refer to the information elements already covered by the BICC CS2 protocol in Q.1950. NOTE The contents of Table 2 is an interpretation of the table in ETSI TS 101 329 part 3 clause 8.2.5. Table 2: Identification of Q.CBC related parameters for end-to-end QoS service control QT2.TRMQreq Transport QoS Parameters Mandatory Traffic Descriptor Mandatory Transport Addresses Mandatory Packet Transport Protocol Optional [Default UDP] QT2.TRMQconf Transport QoS Parameters Mandatory Transport Addresses Mandatory Packet Transport Protocol Optional [Default UDP] QoS Mechanism Optional QT2.TRMQrej Reason [TBD] Mandatory 6 Parameter contents Table 3 specifies the information to be covered by the parameters listed in sections 4.2 and 5.2 based on the QoS parameter groups in ETSI TS 101 329 part 3 clause 8.2.1. Table 3: Identification of parameter contents for end-to-end QoS service control QoS Service Class Describes the end-to-end ETSI TIPHON Best, High, Medium class of a beareror Best Effort Transport QoS Specifies the QoS characteristics Maximum Delay Parameters required of the transport flow carrying the media flow. Maximum Packet Delay Variation Maximum Packet Loss Traffic Descriptor Characterises the resource Peak Bit requirements of an application data flow (excludes transport flow Maximum Packet Size resource requirements). Parameters specifying the ETSI TIPHON QoS Class as defined in ETSI TS 101 329 Part 2 The maximum delay permitted (ms) over either a segment of the transport flow or the remaining part of the transport flow. The maximum packet delay variation permitted (ms) over either a segment of the transport flow or the remaining part of the transport flow. The maximum packet loss permitted (%) over either a segment of the transport flow or the remaining part of the transport flow. [N.B. This measure assumes randomly distributed packet loss] Maximum bit rate (bit/s) of the media flow. Maximum size of the media packets 7 Information flows and signalling procedures for end-to-end QoS service control EDITORS' NOTE The information flows and signalling procedures for end-to-end QoS service control may be considered to follow the same principles as the already existing procedures for end-to-end codec negotiation in BICC CS1 and BICC CS2. Similarly mid-call procedures for end-to-end QoS modification and mid-call QoS modification may be considered because the perceived QoS is highly related to the codec type employed end- to-end as part of the connection. The exact scope and properties of these procedures and protocol message flows needs further discussion. Greg Ratta, Vice Chairman, ITU-T SG 11, Signalling requirements and protocols Lucent Technologies Tel: +1 732 332 5174, Fax: +1 732 949 1196, gratta@lucent.com _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From owner-megaco@fore.com Fri Jun 1 21:13:05 2001 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA20557 for ; Fri, 1 Jun 2001 21:13:03 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id VAA24527; Fri, 1 Jun 2001 21:03:33 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id UAA16863 for megaco-list; Fri, 1 Jun 2001 20:59:13 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA16853 for ; Fri, 1 Jun 2001 20:59:04 -0400 (EDT) Received: from gateway.hearme.com (gateway.hearme.com [204.242.182.129]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA23859 for ; Fri, 1 Jun 2001 20:58:53 -0400 (EDT) Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01690; Fri, 1 Jun 2001 17:56:55 -0700 (PDT) Received: (from corey@localhost) by nodserv.hearme.com (8.9.1/8.9.1) id RAA28836 for corey@hearme.com; Fri, 1 Jun 2001 17:55:50 -0700 (PDT) Received: from gateway.hearme.com (localhost [127.0.0.1]) by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id NAA15207 for ; Thu, 31 May 2001 13:36:17 -0700 (PDT) Received: from lists.bell-labs.com ([204.178.16.58]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id NAA20219 for ; Thu, 31 May 2001 13:36:16 -0700 (PDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 308CF44374; Thu, 31 May 2001 11:31:05 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from prue.eim.surrey.ac.uk (prue.eim.surrey.ac.uk [131.227.76.5]) by lists.bell-labs.com (Postfix) with ESMTP id 16760443FA; Thu, 31 May 2001 11:14:11 -0400 (EDT) Received: from phaestos.ee.surrey.ac.uk ([131.227.88.14] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.16 #1) id 155U91-00045U-00; Thu, 31 May 2001 16:13:51 +0100 From: Lloyd Wood X-Sender: eep1lw@phaestos.ee.surrey.ac.uk Reply-To: Lloyd Wood To: Fred Baker Cc: gratta@lucent.com, sob@harvard.edu, mankin@isi.edu, diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org, Yukio Hiramatsu , rbuhrke@lucent.com, tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch, John C Klensin , chair@ietf.org In-Reply-To: <5.1.0.14.2.20010530152432.043b8ec0@mira-sjcm-2.cisco.com> Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 X-Scanner: exiscan *155U91-00045U-00*ZWgRfZ3Wo52* http://duncanthrax.net/exiscan/ Subject: [IPTEL] Re: [Diffserv] Re: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR END-TO-END QOS SERVICE CONTROL X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Thu, 31 May 2001 16:13:43 +0100 (BST) Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk On Wed, 30 May 2001, Fred Baker wrote: > Greg: > > The URLs in this note were all sent with what the ETSI machine considered > to be 'malformed syntax'. Could you resend the correct URLs? Just put all the parts together, removing unencoded spaces; the reason for the breaks after the hyphens seems obvious enough, but I'm at a loss to explain others. Here we go: http://docbox.etsi.org/tech-org/tiphon/Document/tiphon/07-drafts/wg5/_Published/DTS05009/V1.1.1/ts_101329-2v111p.doc http://docbox.etsi.org/tech-org/tiphon/Document/tiphon/07-drafts/wg5/_Published/DTS05003/DTS05003v096.zip http://webapp.etsi.org/tbhomepage/TBDetails.asp?TB_ID=291&TB_NAME=TIPHON http://docbox.etsi.org/tech-org/tiphon/Document/tiphon/ARCHIVES/2000/05-200012-Kyoto/WG5%20TIPHON21%20presentation%20Rev1.ppt So http://docbox.etsi.org/ is passworded but docs can be retrieved by advertised public direct url? Bizarre. L. PGP _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From owner-megaco@fore.com Fri Jun 1 21:22:17 2001 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA20877 for ; Fri, 1 Jun 2001 21:22:16 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id VAA25756; Fri, 1 Jun 2001 21:12:24 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id VAA17287 for megaco-list; Fri, 1 Jun 2001 21:05:09 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id VAA17274 for ; Fri, 1 Jun 2001 21:04:59 -0400 (EDT) Received: from gateway.hearme.com (gateway.hearme.com [204.242.182.129]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id VAA24709 for ; Fri, 1 Jun 2001 21:04:52 -0400 (EDT) Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id SAA01831; Fri, 1 Jun 2001 18:01:53 -0700 (PDT) Received: (from corey@localhost) by nodserv.hearme.com (8.9.1/8.9.1) id SAA28925 for corey@hearme.com; Fri, 1 Jun 2001 18:01:04 -0700 (PDT) Received: from gateway.hearme.com (localhost [127.0.0.1]) by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id PAA16573 for ; Thu, 31 May 2001 15:14:18 -0700 (PDT) Received: from lists.bell-labs.com ([204.178.16.58]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id PAA22048 for ; Thu, 31 May 2001 15:14:17 -0700 (PDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9250344493; Thu, 31 May 2001 17:56:31 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by lists.bell-labs.com (Postfix) with SMTP id 55964443C5; Thu, 31 May 2001 12:12:00 -0400 (EDT) Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 31 May 2001 17:11:33 +0100 To: Lloyd Wood Cc: Fred Baker , gratta@lucent.com, sob@harvard.edu, mankin@isi.edu, diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org, Yukio Hiramatsu , rbuhrke@lucent.com, tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch, John C Klensin , chair@ietf.org, J.Crowcroft@cs.ucl.ac.uk In-reply-to: Your message of "Thu, 31 May 2001 16:13:43 BST." Message-ID: <922.991325489@cs.ucl.ac.uk> From: Jon Crowcroft Subject: [SIP] Re: [Diffserv] Re: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR END-TO-END QOS SERVICE CONTROL X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 31 May 2001 17:11:29 +0100 Content-Type: text Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk so the talk seems to be dated dec 2001, and makes me wonder if the tiphon folks have achieved a breakthru in QOS with e2e delays better than 0ms..... meanwhile, i stuck html versions of the files below at ftp://cs.ucl.ac.uk/darpa/tiphon/ (prob. doesnt help non windoze users since the html is generated by office 2000 apps so unless you have the unix internet explorer, too bad) In message , Lloyd Wood typed: >>On Wed, 30 May 2001, Fred Baker wrote: >> >>> Greg: >>> >>> The URLs in this note were all sent with what the ETSI machine considered >>> to be 'malformed syntax'. Could you resend the correct URLs? >> >>Just put all the parts together, removing unencoded >>spaces; the reason for the breaks after the hyphens seems >>obvious enough, but I'm at a loss to explain others. Here we go: >> >>http://docbox.etsi.org/tech-org/tiphon/Document/tiphon/07-drafts/wg5/_Published/DTS05009/V1.1.1/ts_101329-2v111p.doc >> >>http://docbox.etsi.org/tech-org/tiphon/Document/tiphon/07-drafts/wg5/_Published/DTS05003/DTS05003v096.zip >> >>http://webapp.etsi.org/tbhomepage/TBDetails.asp?TB_ID=291&TB_NAME=TIPHON >> >>http://docbox.etsi.org/tech-org/tiphon/Document/tiphon/ARCHIVES/2000/05-200012-Kyoto/WG5%20TIPHON21%20presentation%20Rev1.ppt >> >>So http://docbox.etsi.org/ is passworded but docs can be retrieved by >>advertised public direct url? Bizarre. >> >>L. >> >>PGP >> >> >> >> >> >> >> cheers jon _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From owner-megaco@fore.com Fri Jun 1 21:24:57 2001 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA20907 for ; Fri, 1 Jun 2001 21:24:55 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id VAA25947; Fri, 1 Jun 2001 21:14:20 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id VAA17595 for megaco-list; Fri, 1 Jun 2001 21:07:23 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id VAA17581 for ; Fri, 1 Jun 2001 21:07:15 -0400 (EDT) Received: from gateway.hearme.com (gateway.hearme.com [204.242.182.129]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA23414 for ; Fri, 1 Jun 2001 20:54:29 -0400 (EDT) Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01598; Fri, 1 Jun 2001 17:52:26 -0700 (PDT) Received: (from corey@localhost) by nodserv.hearme.com (8.9.1/8.9.1) id RAA28774 for corey@hearme.com; Fri, 1 Jun 2001 17:51:37 -0700 (PDT) Received: from gateway.hearme.com (localhost [127.0.0.1]) by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id KAA12873 for ; Thu, 31 May 2001 10:44:35 -0700 (PDT) Received: from optimus.ietf.org ([132.151.1.19]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id KAA16691 for ; Thu, 31 May 2001 10:12:29 -0700 (PDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23860; Thu, 31 May 2001 13:08:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA21135 for ; Thu, 31 May 2001 12:06:43 -0400 (EDT) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA00226; Thu, 31 May 2001 12:06:20 -0400 (EDT) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id JAA34990; Thu, 31 May 2001 09:04:55 -0700 Received: from hursley.ibm.com ([9.29.3.174]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id JAA20120; Thu, 31 May 2001 09:04:54 -0700 Message-ID: <3B166AFC.9DF4CD05@hursley.ibm.com> Date: Thu, 31 May 2001 11:02:04 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: gratta@lucent.com CC: sob@harvard.edu, mankin@isi.edu, diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org, Yukio Hiramatsu , rbuhrke@lucent.com, tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch References: <200105302022.QAA03855@hotair.hobl.lucent.com> X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA21136 Subject: [Sipping] Re: [Diffserv] PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR END-TO-END QOS SERVICE CONTROL X-Mailman-Version: 1.0 List-Id: Official IETF Mailing List for the SIPPING Working Group X-BeenThere: sipping@ietf.org Content-Type: text/plain; charset=iso-8859-1 Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by mailgate.pit.comms.marconi.com id VAA25947 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id VAA20907 Folks, This is *not* a discussion item for the diffserv WG mailing list. This WG is not chartered to discuss signalling issues. Whether the ITU should work on this and if so how it should collaborate with the IETF should be discussed at liaison level, not on a list with a few hundred people. So please everybody drop this discussion on the diffserv list and continue elswhere. Regards Brian Carpenter diffserv co-chair Greg Ratta wrote: > > This message was agreed to at ITU-T Study Group 11 meeting (Geneva, May 2001) and is being transmitted on behalf of Yukio Hiramatsu, Chairman of ITU-T SG 11. For further technical clarification, contact the Rapporteur for Q9/11 (Rolfe Buhrke, Tel: + 1 630 713 7022, { HYPERLINK mailto:rburke@lucent.com }rbuhrke@lucent.com) > > FULL TITLE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR END-TO-END QOS SERVICE CONTROL AND SIGNALLING PROTOCOL DEVELOPMENT BASED ON IP TRANSFER CAPABILITIES AND IP QOS CLASSES > > General > > Within ITU-T SG11 work has started on requirements for a generic protocol mechanism for end-to-end QoS service control. It was agreed within SG11 to proceed with this work utilising deliverables of ETSI TIPHON on end- to-end QoS service control as base material. It is the opinion of SG11 that this generic protocol mechanism for BICC intends to apply also to other protocols like SIP/SDP and H.323 next to generic extensions to the H.248/MEGACO protocol. > > It was noted that also QoS related work is in progress in IETF. Please find attached an initial draft of the BICC CS3 signalling requirements for end-to-end QoS service control. Please note the rationale for this activity and the framework for end-to-end QoS service control and network QoS control. The framework illustrates the field of application of the QoS handling at different levels and the different protocols involved. > > Proposals on end-to-end QoS service control > > It is proposed to start a joint activity with IETF on a generic protocol mechanism for end- to-end QoS service control. This refers to the potential work in IETF on the following topics: > > - Identification of the signalling requirements based on the ETSI TIPHON defined speech QoS service classes for VoIP and the signalling and control of end-to-end QoS for VoIP. The attachment provides the initial draft of the BICC CS3 signalling requirements for end-to-end QoS service control. > > - The definition of a generic call/bearer control mechanism in H.225/H.245, SIP/SDP and BICC CS3 for end-to-end QoS service control in the application plane. > > - The definition of generic extensions to H.248/MEGACO for end-to-end QoS service control between the application plane and the transport plane. > > - The translation between the generic protocol QoS information elements in H.248/MEGACO and the technology specific QoS parameters and QoS mechanisms in IP, ATM, MPLS, etc. > > Proposals on IP QoS classes and IP Transfer Capabilities > > ITU-T SG11 would like to inform IETF that it is investigating signalling requirements for protocol development based on the IP Transfer Capabilities and IP QoS classes, as being defined by ITU-T SG13 in Y.1541 and Y.iptc. The plan is to build upon signalling approaches developed by IETF. We would like to stress that the work on IP QoS classes and IP Transfer Capabilities by ITU-T SG13 is co- ordinated with IETF. > > ATTACHMENT Initial draft text of the BICC CS3 signalling requirements for end-to-end QoS service control. > > The ETSI specifications referenced as base material are available at the following URLs: > > ETSI TS 301 329 part 2, http://docbox.etsi.org/tech- org/tiphon/Document/tiphon/07- drafts/wg5/_Published/DTS05009/V1.1.1/ts_10 1329-2v111p.doc > > - ETSI TS 301 329 part 3 see http://docbox.etsi.org/tech- org/tiphon/Document/tiphon/07- drafts/wg5/_Published/DTS05003/DTS05003v096.zi p > > Further information about the ETSI TIPHON project is available at the following URL: > > - http://webapp.etsi.org/tbhomepage/TBDetails.as p?TB_ID=291&TB_NAME=TIPHON > __________________ > > BICC CS3 signalling requirements for end-to- end QoS service control > > EDITORS’ NOTE: This requirements text for end-to-end QoS service control is a first draft text and requires extensive updating based on liaison activities with other groups > > 1 Rationale > > The rationale of the BICC CS3 requirements for end-to-end service control is based on the analysis made by ETSI TIPHON (see the presentation available at the URL: http://docbox.etsi.org/tech- org/tiphon/Document/tiphon/ARCHIVES/2000/05- 200012- Kyoto/WG5%20TIPHON21%20presentation%20Rev1.ppt ). It shows the inter-relationship between the different QoS factors that finally determine > the perceived speech quality by the end- users. This perceived speech quality does not only depend on network quality of service (network packet loss, network jitter and network delay) but on the terminal implementation (jitter buffers and codec performance) as well. > > A second rationale is that end-to-end QoS requirements can be regarded as end-to-end quality budgets related to the media flows. To achieve the required end-to-end QoS these quality budgets must be allocated between the domains, including the user equipment (see Figure 7 in ETSI TS 301 329 part 3). The Transport QoS Parameters specify the QoS budgets for each Transport Domain. It is assumed that the performance of each domain is statistically independent from any other. > > Therefore end-to-end QoS service control at the call control level (i.e. application plane) is required based on generic signalling procedures in protocols like BICC, SIP/SDP, H.323 and H.248/MEGACO for end-to- end QoS service control. > > 2 Framework for end-to-end QoS service control and network QoS control. > > A framework for QoS control may be considered at different levels: call control (BICC, SIP/SDP, H.323), vertical control (H.248/MEGACO, CBC), bearer control (IP BCP) and bearer (DiffServ, IntServ/RSVP or MPLS/LDP). > > 1) Call-control > > a) End-to-end QoS service control is negotiated/communicated end-to-end at the call control level. ETSI TIPHON has defined a set of speech QoS classes, and signalling requirements and flows for this purpose. > > The idea is that call control protocols are enhanced with a generic end-to-end QoS service control mechanism to negotiate these speech QoS classes and associated parameters (Maximum delay, Maximum packet delay variation, Maximum packet loss, Peak bit rate and Maximum packet size). > > Such a generic end-to-end QoS service control mechanism should be defined independent of the underlying technology (ATM or IP) and operate across network domains and including terminal characteristics to negotiate/communicate the requested listener speech quality that will be perceived by the end-users (i.e. "mouth-to-ear"). > > b) BICC (Q.190x) is one of the call control protocols that may be enhanced this way. Similar enhancements may be applicable to other call-control protocols like SIP/SDP and H.323. > > 2) Vertical control > > a) QoS service control is also negotiated/communicated at the vertical control level. The ETSI TIPHON defined signalling requirements and flows include the vertical interface. The idea is that vertical control protocols are enhanced to negotiate/communicate the QoS settings (Maximum delay, Maximum packet delay variation, Maximum packet loss, Peak bit rate and Maximum packet size) in the bearer core network based on generic H.248/MEGACO extensions. > > These QoS settings should be defined independent of the underlying technology (ATM or IP) of the bearer core network. > > b) CBC (Q.1950) is one of the vertical control protocols that may be enhanced this way. > > 3) Bearer control > > a) Network QoS is negotiated/communicated at the bearer control level. ATM signalling does already intrinsically support network QoS. SG13 has recently defined IP QoS classes and IP Transfer Capabilities. > > The idea is that bearer control protocols for IP are enhanced with a mechanism to negotiate the network QoS by using IP QoS classes and IP Transfer Capabilities. > > b) IP BCP (Q.1970) is an IP bearer control protocol that may be enhanced this way. > > 4) Bearer > > a) Network QoS is negotiated/communicated at the bearer level, i.e. as part of the protocols associated with the bearers in the core network. The idea is that IP QoS classes and IP Transfer Capabilties, as defined by SG13, are used to differentiate between different types of IP traffic. > > b) IP QoS classes and IP Transfer Capabilities may be used to enhance existing IP mechanisms like DiffServ, IntServ/RSVP and MPLS/LDP. > > 3 QoS information flows applicable to BICC > > A general model is considered for QoS information flows with BICC when making a translation of the relevant parts in Figure 8 in ETSI TS 301 329 part 3. > > Section 4 details the Q.BICC related QoS primitives and parameters based on the QoS primitives and parameters in the ETSI deliverable. Similarly, section 5 provides the Q.CBC related QoS primitives and parameters. > > 4 Q.BICC related QoS primitives and parameters > > The Q.BICC related QoS primitives and parameters are extracted from clause 8.1 and clause 8.2 of ETSI TS 101 329 part 3. > > 4.1 Q.BICC related QoS primitives > > This information flow (QC2 in ETSI TS 101 329 part 3) communicates the QoS related bearer information between the domains of different service providers. > > Q.BICC QoS request (Qbicc.QoSreq) requests the establishment of a bearer conforming to a particular ETSI TIPHON Class of Service or with defined QoS characteristics. > > NOTE Identical to QoSM request (QC2.QoSMreq) in ETSI TS 101 329 part 3 clause 8.1.1. > > Q.BICC QoS confirm (Qbicc.QoSconf) acknowledges the creation of a bearer conforming to a requested ETSI TIPHON QoS Class or with specified QoS characteristics. > > NOTE Identical to QoSM confirm (QC2.QoSMconf) in ETSI TS 101 329 part 3 clause 8.1.1. > > Q.BICC QoS reject (Qbicc.QoSrej) rejects the creation of a bearer conforming to a requested ETSI TIPHON QoS Class or with specified QoS characteristics. > > NOTE Identical to QoSM reject (QC2.QoSMrej) in ETSI TS 101 329 part 3 clause 8.1.1. > > Q.BICC release request (Qbicc.QoSrelreq) requests the release of a bearer. > > NOTE Identical to QoSM release request (QC2.QoSMrelreq) in ETSI TS 101 329 part 3 clause 8.1.1 and the release of a transport flow is already covered by existing Q.BICC procedures in Q.1902 series. > > QoSM release confirm (Qbicc.QoSrelconf) confirms the release of a bearer. > > NOTE Identical to QoSM release confirm (QC2.QoSMrelconf) in ETSI TS 101 329 part 3 clause 8.1.1 and the release of a transport flow is already covered by existing Q.BICC procedures in Q.1902 series. > > 4.2 Q.BICC related QoS parameters > > Table 1 lists the parameters used in the Q.BICC related QoS primitives not yet covered by the Q.BICC protocol. The deleted items refer to the information elements already covered by the BICC CS2 protocol in the Q.1902 series. > > NOTE The contents of Table 1 is an interpretation of the table in ETSI TS 101 329 part 3 clause 8.2.3. > > Table 1: Identification of Q.BICC related parameters for end-to-end QoS service control > Qbicc.QoSreq QoS Service Class Optional > > Codec Type and Packetisation Mandatory > > Transport QoS Parameters Mandatory > > Traffic Descriptor Optional > > Transport Addresses Mandatory > > Application Data Transport Protocol Optional [Default RTP] > > Packet Transport Protocol Optional [Default UDP] > > QoS Mechanism Optional > > Qbicc.QoSconf QoS Service Class Optional > > Codec Type and Packetisation Mandatory > > Transport QoS Parameters Mandatory > > Transport Addresses Mandatory > > Application Data Transport Protocol Optional [Default RTP] > > Packet Transport Protocol Optional [Default UDP] > > Qbicc.QoSrej Reason [TBD] Mandatory > > 5 Q.CBC related QoS primitives and parameters > > The Q.CBC related QoS primitives and parameters are extracted from clause 8.1 and clause 8.2 of ETSI TS 101 329 part 3. > > 5.1 Q.CBC related QoS primitives > > This information flow (QT2 in ETSI TS 101 329 part 3) communicates the QoS related transport flow information between a service domain and an associated transport domain. This information contains the QoS related characteristics required of the transport flows that will carry the media flow and the properties of the media flow. > > Q.CBC QoS request (Qcbc.QoSreq) requests the establishment of a transport flow with defined QoS characteristics across a Transport Domain or the reservation of Transport Domain resource. > > NOTE Identical to TRM QoS request (QT2.TRMQreq) in ETSI TS 101 329 part 3 clause 8.1.3. > > Q.CBC QoS confirm (Qcbc.QoSconf) acknowledges the creation of a requested transport flow or the reservation of Transport Domain resource. > > NOTE Identical to TRM QoS confirm (QT2.TRMQconf) in ETSI TS 101 329 part 3 clause 8.1.3. > > Q.CBC QoS reject (Qcbc.QoSrej) rejects the creation of a requested transport flow or the reservation of Transport Domain resource. > > NOTE Identical to TRM QoS reject (QT2.TRMQrej) in ETSI TS 101 329 part 3 clause 8.1.3. > > Q.CBC QoS release request (Qcbc.QoSrelreq) requests the release of a transport flow. > > NOTE Identical to TRM QoS release request (QT2.TRM QoS relreq) in ETSI TS 101 329 part 3 clause 8.1.3. The release of a transport flow is already covered by the existing Q.CBC procedures in Q.1950. > > Q.CBC QoS release confirm (Qcbc.QoSrelconf) confirms the release of a transport flow. > > NOTE Identical to TRM QoS release confirm (QT2.TRM QoS relconf) in ETSI TS 101 329 part 3 clause 8.1.3. The release of a transport flow is already covered by the existing Q.CBC procedures in Q.1950. > > Q.CBC QoS performance notification (Qcbc.QoSperfnotif) notifies the Service Domain of the performance of the Transport Domain in meeting the requested QoS levels. This may be a periodic event or an urgent alarm. Note: this primitive is a management primitive and its use is for further study. > > NOTE Identical to TRM QoS performance notification (QT2.TRM QoS perfnotif) in ETSI TS 101 329 part 3 clause 8.1.3. For further study. > > 5.2 Q.CBC related QoS parameters > > Table 2 lists the parameters used in the Q.CBC related QoS primitives not yet covered by the Q.CBC protocol. The deleted items refer to the information elements already covered by the BICC CS2 protocol in Q.1950. > > NOTE The contents of Table 2 is an interpretation of the table in ETSI TS 101 329 part 3 clause 8.2.5. > > Table 2: Identification of Q.CBC related parameters for end-to-end QoS service control > > QT2.TRMQreq Transport QoS Parameters Mandatory > > Traffic Descriptor Mandatory > > Transport Addresses Mandatory > > Packet Transport Protocol Optional [Default UDP] > > QT2.TRMQconf Transport QoS Parameters Mandatory > > Transport Addresses Mandatory > > Packet Transport Protocol Optional [Default UDP] > > QoS Mechanism Optional > > QT2.TRMQrej Reason [TBD] Mandatory > > 6 Parameter contents > > Table 3 specifies the information to be covered by the parameters listed in sections 4.2 and 5.2 based on the QoS parameter groups in ETSI TS 101 329 part 3 clause 8.2.1. > > Table 3: Identification of parameter contents for end-to-end QoS service control > > QoS Service Class Describes the end-to-end ETSI TIPHON Best, High, Medium > class of a bearer or Best Effort > > Transport QoS Specifies the QoS characteristics Maximum Delay > Parameters required of the transport flow > carrying the media flow. Maximum Packet Delay Variation > > Maximum Packet Loss > > Traffic Descriptor Characterises the resource Peak Bit > requirements of an application data > flow (excludes transport flow Maximum Packet Size > resource requirements). > > Parameters specifying the ETSI TIPHON QoS Class as defined in ETSI TS 101 329 Part 2 > > The maximum delay permitted (ms) over either a segment of the transport flow or the remaining part of the transport flow. > > The maximum packet delay variation permitted (ms) over either a segment of the transport flow or the remaining part of the transport flow. > > The maximum packet loss permitted (%) over either a segment of the transport flow or the remaining part of the transport flow. [N.B. This measure assumes randomly distributed packet loss] > Maximum bit rate (bit/s) of the media flow. > > Maximum size of the media packets > > 7 Information flows and signalling procedures for end-to-end QoS service control > > EDITORS’ NOTE The information flows and signalling procedures for end-to-end QoS service control may be considered to follow the same principles as the already existing procedures for end-to-end codec negotiation in BICC CS1 and BICC CS2. Similarly mid-call procedures for end-to-end QoS modification and mid-call QoS modification may be considered because the perceived QoS is highly related to the codec type employed end- to-end as part of the connection. The exact scope and properties of these procedures and protocol message flows needs further discussion. > > Greg Ratta, Vice Chairman, ITU-T SG 11, Signalling requirements and protocols > Lucent Technologies Tel: +1 732 332 5174, Fax: +1 732 949 1196, gratta@lucent.com > > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Board Chairman, Internet Society http://www.isoc.org _______________________________________________ Sipping mailing list Sipping@ietf.org http://www.ietf.org/mailman/listinfo/sipping From owner-megaco@fore.com Fri Jun 1 21:27:16 2001 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA20951 for ; Fri, 1 Jun 2001 21:27:16 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id VAA25909; Fri, 1 Jun 2001 21:13:55 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id VAA17329 for megaco-list; Fri, 1 Jun 2001 21:05:47 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id VAA17321 for ; Fri, 1 Jun 2001 21:05:41 -0400 (EDT) Received: from gateway.hearme.com (gateway.hearme.com [204.242.182.129]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id VAA24822 for ; Fri, 1 Jun 2001 21:05:33 -0400 (EDT) Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id SAA01881; Fri, 1 Jun 2001 18:03:04 -0700 (PDT) Received: (from corey@localhost) by nodserv.hearme.com (8.9.1/8.9.1) id SAA28947 for corey@hearme.com; Fri, 1 Jun 2001 18:01:53 -0700 (PDT) Received: from gateway.hearme.com (localhost [127.0.0.1]) by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id PAA16766 for ; Thu, 31 May 2001 15:25:22 -0700 (PDT) Received: from lists.bell-labs.com ([204.178.16.58]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id PAA22255 for ; Thu, 31 May 2001 15:25:21 -0700 (PDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F0889444AA; Thu, 31 May 2001 17:56:48 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by lists.bell-labs.com (Postfix) with ESMTP id 21E354434B; Thu, 31 May 2001 13:12:28 -0400 (EDT) Received: from FRED-W2K.cisco.com (fred-hm-dhcp3.cisco.com [171.69.128.118]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f4VHBBU27133; Thu, 31 May 2001 10:11:12 -0700 (PDT) Message-Id: <5.1.0.14.2.20010531095817.04c50ea8@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 To: "Roy, Radhika R, ALCTA" From: Fred Baker Cc: Bob Braden , gratta@lucent.com, sob@harvard.edu, mankin@isi.edu, diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org, hiramatsu.yukio@lab.ntt.co.jp, rbuhrke@lucent.com, tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch, ITU-SG16@mailbag.cps.INTEL.COM In-Reply-To: Mime-Version: 1.0 Subject: [SIP] RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 31 May 2001 10:09:10 -0700 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk At 06:08 AM 5/31/2001, Roy, Radhika R, ALCTA wrote: >All applications (e.g., H.323, SIP) uses signaling messages >among its functional entities (e.g., terminal, agents, >gatekeepers, proxies, gateways) for communications. I'm not sure we're on the same planet. Please help me out here. I can think of a few applications that have agents, gatekeepers, proxies, and gateways, mostly resulting from the imposition of firewalls or authentication systems, or from legacy applications like imitating the telephone system in a data network. The only one that *requires* any kind of gateway, to my knowledge, is H.323 teleconferencing, which represents a paltry fraction of traffic according to most current measurements. Anything else (75% of Internet traffic is http or FTP, most of the rest is mail, on private LANs applications like NFS are pretty common, and even SIP can be done without a gateway between consenting systems) could be hooked up in separate systems on a LAN and made to work without any such signalling at all. Could you be more specific on what QoS signalling is required by the world wide web, mail, FTP, common ERP applications like ERP and PeopleSoft, calendaring, and so on? If not, could you be more specific about what "all" applications you have in mind? And could you be more specific about what issues this proposal is addressing that have not already been addressed in de facto standards and deployed in operational systems? It would be very nice to understand what you are preparing to ask vendors to do, and whether operators are interested in deploying them. _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From owner-megaco@fore.com Fri Jun 1 21:29:11 2001 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA20987 for ; Fri, 1 Jun 2001 21:29:10 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id VAA25427; Fri, 1 Jun 2001 21:09:24 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id VAA17153 for megaco-list; Fri, 1 Jun 2001 21:02:27 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id VAA17140 for ; Fri, 1 Jun 2001 21:02:18 -0400 (EDT) Received: from gateway.hearme.com (gateway.hearme.com [204.242.182.129]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id VAA24298 for ; Fri, 1 Jun 2001 21:02:12 -0400 (EDT) Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id SAA01762; Fri, 1 Jun 2001 18:00:15 -0700 (PDT) Received: (from corey@localhost) by nodserv.hearme.com (8.9.1/8.9.1) id RAA28891 for corey@hearme.com; Fri, 1 Jun 2001 17:59:05 -0700 (PDT) Received: from gateway.hearme.com (localhost [127.0.0.1]) by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id OAA16321 for ; Thu, 31 May 2001 14:58:11 -0700 (PDT) Received: from lists.bell-labs.com ([204.178.16.58]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id OAA21799 for ; Thu, 31 May 2001 14:58:10 -0700 (PDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 538BF44401; Thu, 31 May 2001 17:56:08 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from prue.eim.surrey.ac.uk (prue.eim.surrey.ac.uk [131.227.76.5]) by lists.bell-labs.com (Postfix) with ESMTP id 16760443FA; Thu, 31 May 2001 11:14:11 -0400 (EDT) Received: from phaestos.ee.surrey.ac.uk ([131.227.88.14] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.16 #1) id 155U91-00045U-00; Thu, 31 May 2001 16:13:51 +0100 From: Lloyd Wood X-Sender: eep1lw@phaestos.ee.surrey.ac.uk Reply-To: Lloyd Wood To: Fred Baker Cc: gratta@lucent.com, sob@harvard.edu, mankin@isi.edu, diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org, Yukio Hiramatsu , rbuhrke@lucent.com, tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch, John C Klensin , chair@ietf.org In-Reply-To: <5.1.0.14.2.20010530152432.043b8ec0@mira-sjcm-2.cisco.com> Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 X-Scanner: exiscan *155U91-00045U-00*ZWgRfZ3Wo52* http://duncanthrax.net/exiscan/ Subject: [SIP] Re: [Diffserv] Re: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR END-TO-END QOS SERVICE CONTROL X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 31 May 2001 16:13:43 +0100 (BST) Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk On Wed, 30 May 2001, Fred Baker wrote: > Greg: > > The URLs in this note were all sent with what the ETSI machine considered > to be 'malformed syntax'. Could you resend the correct URLs? Just put all the parts together, removing unencoded spaces; the reason for the breaks after the hyphens seems obvious enough, but I'm at a loss to explain others. Here we go: http://docbox.etsi.org/tech-org/tiphon/Document/tiphon/07-drafts/wg5/_Published/DTS05009/V1.1.1/ts_101329-2v111p.doc http://docbox.etsi.org/tech-org/tiphon/Document/tiphon/07-drafts/wg5/_Published/DTS05003/DTS05003v096.zip http://webapp.etsi.org/tbhomepage/TBDetails.asp?TB_ID=291&TB_NAME=TIPHON http://docbox.etsi.org/tech-org/tiphon/Document/tiphon/ARCHIVES/2000/05-200012-Kyoto/WG5%20TIPHON21%20presentation%20Rev1.ppt So http://docbox.etsi.org/ is passworded but docs can be retrieved by advertised public direct url? Bizarre. L. PGP _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From owner-megaco@fore.com Fri Jun 1 22:19:19 2001 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA22684 for ; Fri, 1 Jun 2001 22:19:19 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id VAA25583; Fri, 1 Jun 2001 21:10:47 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id VAA17199 for megaco-list; Fri, 1 Jun 2001 21:03:15 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id VAA17195 for ; Fri, 1 Jun 2001 21:03:11 -0400 (EDT) Received: from gateway.hearme.com (gateway.hearme.com [204.242.182.129]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id VAA24437 for ; Fri, 1 Jun 2001 21:03:01 -0400 (EDT) Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id SAA01796; Fri, 1 Jun 2001 18:01:04 -0700 (PDT) Received: (from corey@localhost) by nodserv.hearme.com (8.9.1/8.9.1) id SAA28908 for corey@hearme.com; Fri, 1 Jun 2001 18:00:15 -0700 (PDT) Received: from gateway.hearme.com (localhost [127.0.0.1]) by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id PAA16432 for ; Thu, 31 May 2001 15:04:51 -0700 (PDT) Received: from lists.bell-labs.com ([204.178.16.58]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id PAA21898 for ; Thu, 31 May 2001 15:04:50 -0700 (PDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2B71D44471; Thu, 31 May 2001 17:56:20 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by lists.bell-labs.com (Postfix) with ESMTP id 47E5B443C5; Thu, 31 May 2001 12:06:44 -0400 (EDT) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id JAA34990; Thu, 31 May 2001 09:04:55 -0700 Received: from hursley.ibm.com ([9.29.3.174]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id JAA20120; Thu, 31 May 2001 09:04:54 -0700 Message-ID: <3B166AFC.9DF4CD05@hursley.ibm.com> From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: gratta@lucent.com Cc: sob@harvard.edu, mankin@isi.edu, diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org, Yukio Hiramatsu , rbuhrke@lucent.com, tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch References: <200105302022.QAA03855@hotair.hobl.lucent.com> Subject: [SIP] Re: [Diffserv] PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR END-TO-END QOS SERVICE CONTROL X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 31 May 2001 11:02:04 -0500 X-MIME-Autoconverted: from quoted-printable to 8bit by nodserv.hearme.com id PAA16432 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by mailgate.pit.comms.marconi.com id VAA25583 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id WAA22684 Folks, This is *not* a discussion item for the diffserv WG mailing list. This WG is not chartered to discuss signalling issues. Whether the ITU should work on this and if so how it should collaborate with the IETF should be discussed at liaison level, not on a list with a few hundred people. So please everybody drop this discussion on the diffserv list and continue elswhere. Regards Brian Carpenter diffserv co-chair Greg Ratta wrote: > > This message was agreed to at ITU-T Study Group 11 meeting (Geneva, May 2001) and is being transmitted on behalf of Yukio Hiramatsu, Chairman of ITU-T SG 11. For further technical clarification, contact the Rapporteur for Q9/11 (Rolfe Buhrke, Tel: + 1 630 713 7022, { HYPERLINK mailto:rburke@lucent.com }rbuhrke@lucent.com) > > FULL TITLE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR END-TO-END QOS SERVICE CONTROL AND SIGNALLING PROTOCOL DEVELOPMENT BASED ON IP TRANSFER CAPABILITIES AND IP QOS CLASSES > > General > > Within ITU-T SG11 work has started on requirements for a generic protocol mechanism for end-to-end QoS service control. It was agreed within SG11 to proceed with this work utilising deliverables of ETSI TIPHON on end- to-end QoS service control as base material. It is the opinion of SG11 that this generic protocol mechanism for BICC intends to apply also to other protocols like SIP/SDP and H.323 next to generic extensions to the H.248/MEGACO protocol. > > It was noted that also QoS related work is in progress in IETF. Please find attached an initial draft of the BICC CS3 signalling requirements for end-to-end QoS service control. Please note the rationale for this activity and the framework for end-to-end QoS service control and network QoS control. The framework illustrates the field of application of the QoS handling at different levels and the different protocols involved. > > Proposals on end-to-end QoS service control > > It is proposed to start a joint activity with IETF on a generic protocol mechanism for end- to-end QoS service control. This refers to the potential work in IETF on the following topics: > > - Identification of the signalling requirements based on the ETSI TIPHON defined speech QoS service classes for VoIP and the signalling and control of end-to-end QoS for VoIP. The attachment provides the initial draft of the BICC CS3 signalling requirements for end-to-end QoS service control. > > - The definition of a generic call/bearer control mechanism in H.225/H.245, SIP/SDP and BICC CS3 for end-to-end QoS service control in the application plane. > > - The definition of generic extensions to H.248/MEGACO for end-to-end QoS service control between the application plane and the transport plane. > > - The translation between the generic protocol QoS information elements in H.248/MEGACO and the technology specific QoS parameters and QoS mechanisms in IP, ATM, MPLS, etc. > > Proposals on IP QoS classes and IP Transfer Capabilities > > ITU-T SG11 would like to inform IETF that it is investigating signalling requirements for protocol development based on the IP Transfer Capabilities and IP QoS classes, as being defined by ITU-T SG13 in Y.1541 and Y.iptc. The plan is to build upon signalling approaches developed by IETF. We would like to stress that the work on IP QoS classes and IP Transfer Capabilities by ITU-T SG13 is co- ordinated with IETF. > > ATTACHMENT Initial draft text of the BICC CS3 signalling requirements for end-to-end QoS service control. > > The ETSI specifications referenced as base material are available at the following URLs: > > ETSI TS 301 329 part 2, http://docbox.etsi.org/tech- org/tiphon/Document/tiphon/07- drafts/wg5/_Published/DTS05009/V1.1.1/ts_10 1329-2v111p.doc > > - ETSI TS 301 329 part 3 see http://docbox.etsi.org/tech- org/tiphon/Document/tiphon/07- drafts/wg5/_Published/DTS05003/DTS05003v096.zi p > > Further information about the ETSI TIPHON project is available at the following URL: > > - http://webapp.etsi.org/tbhomepage/TBDetails.as p?TB_ID=291&TB_NAME=TIPHON > __________________ > > BICC CS3 signalling requirements for end-to- end QoS service control > > EDITORS’ NOTE: This requirements text for end-to-end QoS service control is a first draft text and requires extensive updating based on liaison activities with other groups > > 1 Rationale > > The rationale of the BICC CS3 requirements for end-to-end service control is based on the analysis made by ETSI TIPHON (see the presentation available at the URL: http://docbox.etsi.org/tech- org/tiphon/Document/tiphon/ARCHIVES/2000/05- 200012- Kyoto/WG5%20TIPHON21%20presentation%20Rev1.ppt ). It shows the inter-relationship between the different QoS factors that finally determine > the perceived speech quality by the end- users. This perceived speech quality does not only depend on network quality of service (network packet loss, network jitter and network delay) but on the terminal implementation (jitter buffers and codec performance) as well. > > A second rationale is that end-to-end QoS requirements can be regarded as end-to-end quality budgets related to the media flows. To achieve the required end-to-end QoS these quality budgets must be allocated between the domains, including the user equipment (see Figure 7 in ETSI TS 301 329 part 3). The Transport QoS Parameters specify the QoS budgets for each Transport Domain. It is assumed that the performance of each domain is statistically independent from any other. > > Therefore end-to-end QoS service control at the call control level (i.e. application plane) is required based on generic signalling procedures in protocols like BICC, SIP/SDP, H.323 and H.248/MEGACO for end-to- end QoS service control. > > 2 Framework for end-to-end QoS service control and network QoS control. > > A framework for QoS control may be considered at different levels: call control (BICC, SIP/SDP, H.323), vertical control (H.248/MEGACO, CBC), bearer control (IP BCP) and bearer (DiffServ, IntServ/RSVP or MPLS/LDP). > > 1) Call-control > > a) End-to-end QoS service control is negotiated/communicated end-to-end at the call control level. ETSI TIPHON has defined a set of speech QoS classes, and signalling requirements and flows for this purpose. > > The idea is that call control protocols are enhanced with a generic end-to-end QoS service control mechanism to negotiate these speech QoS classes and associated parameters (Maximum delay, Maximum packet delay variation, Maximum packet loss, Peak bit rate and Maximum packet size). > > Such a generic end-to-end QoS service control mechanism should be defined independent of the underlying technology (ATM or IP) and operate across network domains and including terminal characteristics to negotiate/communicate the requested listener speech quality that will be perceived by the end-users (i.e. "mouth-to-ear"). > > b) BICC (Q.190x) is one of the call control protocols that may be enhanced this way. Similar enhancements may be applicable to other call-control protocols like SIP/SDP and H.323. > > 2) Vertical control > > a) QoS service control is also negotiated/communicated at the vertical control level. The ETSI TIPHON defined signalling requirements and flows include the vertical interface. The idea is that vertical control protocols are enhanced to negotiate/communicate the QoS settings (Maximum delay, Maximum packet delay variation, Maximum packet loss, Peak bit rate and Maximum packet size) in the bearer core network based on generic H.248/MEGACO extensions. > > These QoS settings should be defined independent of the underlying technology (ATM or IP) of the bearer core network. > > b) CBC (Q.1950) is one of the vertical control protocols that may be enhanced this way. > > 3) Bearer control > > a) Network QoS is negotiated/communicated at the bearer control level. ATM signalling does already intrinsically support network QoS. SG13 has recently defined IP QoS classes and IP Transfer Capabilities. > > The idea is that bearer control protocols for IP are enhanced with a mechanism to negotiate the network QoS by using IP QoS classes and IP Transfer Capabilities. > > b) IP BCP (Q.1970) is an IP bearer control protocol that may be enhanced this way. > > 4) Bearer > > a) Network QoS is negotiated/communicated at the bearer level, i.e. as part of the protocols associated with the bearers in the core network. The idea is that IP QoS classes and IP Transfer Capabilties, as defined by SG13, are used to differentiate between different types of IP traffic. > > b) IP QoS classes and IP Transfer Capabilities may be used to enhance existing IP mechanisms like DiffServ, IntServ/RSVP and MPLS/LDP. > > 3 QoS information flows applicable to BICC > > A general model is considered for QoS information flows with BICC when making a translation of the relevant parts in Figure 8 in ETSI TS 301 329 part 3. > > Section 4 details the Q.BICC related QoS primitives and parameters based on the QoS primitives and parameters in the ETSI deliverable. Similarly, section 5 provides the Q.CBC related QoS primitives and parameters. > > 4 Q.BICC related QoS primitives and parameters > > The Q.BICC related QoS primitives and parameters are extracted from clause 8.1 and clause 8.2 of ETSI TS 101 329 part 3. > > 4.1 Q.BICC related QoS primitives > > This information flow (QC2 in ETSI TS 101 329 part 3) communicates the QoS related bearer information between the domains of different service providers. > > Q.BICC QoS request (Qbicc.QoSreq) requests the establishment of a bearer conforming to a particular ETSI TIPHON Class of Service or with defined QoS characteristics. > > NOTE Identical to QoSM request (QC2.QoSMreq) in ETSI TS 101 329 part 3 clause 8.1.1. > > Q.BICC QoS confirm (Qbicc.QoSconf) acknowledges the creation of a bearer conforming to a requested ETSI TIPHON QoS Class or with specified QoS characteristics. > > NOTE Identical to QoSM confirm (QC2.QoSMconf) in ETSI TS 101 329 part 3 clause 8.1.1. > > Q.BICC QoS reject (Qbicc.QoSrej) rejects the creation of a bearer conforming to a requested ETSI TIPHON QoS Class or with specified QoS characteristics. > > NOTE Identical to QoSM reject (QC2.QoSMrej) in ETSI TS 101 329 part 3 clause 8.1.1. > > Q.BICC release request (Qbicc.QoSrelreq) requests the release of a bearer. > > NOTE Identical to QoSM release request (QC2.QoSMrelreq) in ETSI TS 101 329 part 3 clause 8.1.1 and the release of a transport flow is already covered by existing Q.BICC procedures in Q.1902 series. > > QoSM release confirm (Qbicc.QoSrelconf) confirms the release of a bearer. > > NOTE Identical to QoSM release confirm (QC2.QoSMrelconf) in ETSI TS 101 329 part 3 clause 8.1.1 and the release of a transport flow is already covered by existing Q.BICC procedures in Q.1902 series. > > 4.2 Q.BICC related QoS parameters > > Table 1 lists the parameters used in the Q.BICC related QoS primitives not yet covered by the Q.BICC protocol. The deleted items refer to the information elements already covered by the BICC CS2 protocol in the Q.1902 series. > > NOTE The contents of Table 1 is an interpretation of the table in ETSI TS 101 329 part 3 clause 8.2.3. > > Table 1: Identification of Q.BICC related parameters for end-to-end QoS service control > Qbicc.QoSreq QoS Service Class Optional > > Codec Type and Packetisation Mandatory > > Transport QoS Parameters Mandatory > > Traffic Descriptor Optional > > Transport Addresses Mandatory > > Application Data Transport Protocol Optional [Default RTP] > > Packet Transport Protocol Optional [Default UDP] > > QoS Mechanism Optional > > Qbicc.QoSconf QoS Service Class Optional > > Codec Type and Packetisation Mandatory > > Transport QoS Parameters Mandatory > > Transport Addresses Mandatory > > Application Data Transport Protocol Optional [Default RTP] > > Packet Transport Protocol Optional [Default UDP] > > Qbicc.QoSrej Reason [TBD] Mandatory > > 5 Q.CBC related QoS primitives and parameters > > The Q.CBC related QoS primitives and parameters are extracted from clause 8.1 and clause 8.2 of ETSI TS 101 329 part 3. > > 5.1 Q.CBC related QoS primitives > > This information flow (QT2 in ETSI TS 101 329 part 3) communicates the QoS related transport flow information between a service domain and an associated transport domain. This information contains the QoS related characteristics required of the transport flows that will carry the media flow and the properties of the media flow. > > Q.CBC QoS request (Qcbc.QoSreq) requests the establishment of a transport flow with defined QoS characteristics across a Transport Domain or the reservation of Transport Domain resource. > > NOTE Identical to TRM QoS request (QT2.TRMQreq) in ETSI TS 101 329 part 3 clause 8.1.3. > > Q.CBC QoS confirm (Qcbc.QoSconf) acknowledges the creation of a requested transport flow or the reservation of Transport Domain resource. > > NOTE Identical to TRM QoS confirm (QT2.TRMQconf) in ETSI TS 101 329 part 3 clause 8.1.3. > > Q.CBC QoS reject (Qcbc.QoSrej) rejects the creation of a requested transport flow or the reservation of Transport Domain resource. > > NOTE Identical to TRM QoS reject (QT2.TRMQrej) in ETSI TS 101 329 part 3 clause 8.1.3. > > Q.CBC QoS release request (Qcbc.QoSrelreq) requests the release of a transport flow. > > NOTE Identical to TRM QoS release request (QT2.TRM QoS relreq) in ETSI TS 101 329 part 3 clause 8.1.3. The release of a transport flow is already covered by the existing Q.CBC procedures in Q.1950. > > Q.CBC QoS release confirm (Qcbc.QoSrelconf) confirms the release of a transport flow. > > NOTE Identical to TRM QoS release confirm (QT2.TRM QoS relconf) in ETSI TS 101 329 part 3 clause 8.1.3. The release of a transport flow is already covered by the existing Q.CBC procedures in Q.1950. > > Q.CBC QoS performance notification (Qcbc.QoSperfnotif) notifies the Service Domain of the performance of the Transport Domain in meeting the requested QoS levels. This may be a periodic event or an urgent alarm. Note: this primitive is a management primitive and its use is for further study. > > NOTE Identical to TRM QoS performance notification (QT2.TRM QoS perfnotif) in ETSI TS 101 329 part 3 clause 8.1.3. For further study. > > 5.2 Q.CBC related QoS parameters > > Table 2 lists the parameters used in the Q.CBC related QoS primitives not yet covered by the Q.CBC protocol. The deleted items refer to the information elements already covered by the BICC CS2 protocol in Q.1950. > > NOTE The contents of Table 2 is an interpretation of the table in ETSI TS 101 329 part 3 clause 8.2.5. > > Table 2: Identification of Q.CBC related parameters for end-to-end QoS service control > > QT2.TRMQreq Transport QoS Parameters Mandatory > > Traffic Descriptor Mandatory > > Transport Addresses Mandatory > > Packet Transport Protocol Optional [Default UDP] > > QT2.TRMQconf Transport QoS Parameters Mandatory > > Transport Addresses Mandatory > > Packet Transport Protocol Optional [Default UDP] > > QoS Mechanism Optional > > QT2.TRMQrej Reason [TBD] Mandatory > > 6 Parameter contents > > Table 3 specifies the information to be covered by the parameters listed in sections 4.2 and 5.2 based on the QoS parameter groups in ETSI TS 101 329 part 3 clause 8.2.1. > > Table 3: Identification of parameter contents for end-to-end QoS service control > > QoS Service Class Describes the end-to-end ETSI TIPHON Best, High, Medium > class of a bearer or Best Effort > > Transport QoS Specifies the QoS characteristics Maximum Delay > Parameters required of the transport flow > carrying the media flow. Maximum Packet Delay Variation > > Maximum Packet Loss > > Traffic Descriptor Characterises the resource Peak Bit > requirements of an application data > flow (excludes transport flow Maximum Packet Size > resource requirements). > > Parameters specifying the ETSI TIPHON QoS Class as defined in ETSI TS 101 329 Part 2 > > The maximum delay permitted (ms) over either a segment of the transport flow or the remaining part of the transport flow. > > The maximum packet delay variation permitted (ms) over either a segment of the transport flow or the remaining part of the transport flow. > > The maximum packet loss permitted (%) over either a segment of the transport flow or the remaining part of the transport flow. [N.B. This measure assumes randomly distributed packet loss] > Maximum bit rate (bit/s) of the media flow. > > Maximum size of the media packets > > 7 Information flows and signalling procedures for end-to-end QoS service control > > EDITORS’ NOTE The information flows and signalling procedures for end-to-end QoS service control may be considered to follow the same principles as the already existing procedures for end-to-end codec negotiation in BICC CS1 and BICC CS2. Similarly mid-call procedures for end-to-end QoS modification and mid-call QoS modification may be considered because the perceived QoS is highly related to the codec type employed end- to-end as part of the connection. The exact scope and properties of these procedures and protocol message flows needs further discussion. > > Greg Ratta, Vice Chairman, ITU-T SG 11, Signalling requirements and protocols > Lucent Technologies Tel: +1 732 332 5174, Fax: +1 732 949 1196, gratta@lucent.com > > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Board Chairman, Internet Society http://www.isoc.org _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From owner-megaco@fore.com Fri Jun 1 22:19:35 2001 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA22694 for ; Fri, 1 Jun 2001 22:19:35 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id WAA27540; Fri, 1 Jun 2001 22:00:53 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id VAA19731 for megaco-list; Fri, 1 Jun 2001 21:55:52 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id VAA19727 for ; Fri, 1 Jun 2001 21:55:50 -0400 (EDT) Received: from newish7.ericsson.com.au ([203.61.155.116]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id VAA27389 for ; Fri, 1 Jun 2001 21:55:44 -0400 (EDT) Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10]) by newish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id LAA24961; Sat, 2 Jun 2001 11:54:21 +1000 (EST) Received: from ericsson.com ([130.100.249.243]) by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id LAA06693; Sat, 2 Jun 2001 11:55:06 +1000 (EST) Message-ID: <3B1802B5.D0077BE9@ericsson.com> Date: Sat, 02 Jun 2001 07:01:41 +1000 From: Christian Groves X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Paul Long CC: "Megaco Mailing List (E-mail)" Subject: Re: ABNF Question: digit maps embedded in events References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: 7bit G'Day Paul and Troy, If the change is new functionality then it goes to v2. If its to fix an error then it goes to the implementors' guide (IG) If its to align between ABNF and ASN1 it goes in the IG If its to fix inconsistencies between procedures and syntax it goes in the IG This is broadly how I interpret things. There aren't really any solid rules except for the first one. With regards to the EQUALS change I believe it was a syntax irregularity. I assume the intention when the syntax was written it was meant to be the way that it was fixed to. Cheers, Christian Paul Long wrote: > > Yeah, what are the criteria for what gets changed in v1 and what gets put > off to v2? Also, when is v1 officially "done" and can no longer be changed? > Like Troy, I'm not complaining--I really want to know. As you can tell from > my earlier response to Steve's query, I thought it was already too late to > change v1. > > Paul Long > ipDialog, Inc. > > -----Original Message----- > From: owner-megaco@pit.comms.marconi.com > [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Troy Cauble > Sent: Friday, June 01, 2001 10:22 AM > To: Megaco Mailing List (E-mail) > Subject: Re: ABNF Question: digit maps embedded in events > > Just curious, but why doesn't this get squashed for > being an unnecessary change? Nothing's broken except > the symmetry. > > More useful changes have been delayed to v2. > > Please treat this as a question, not a complaint! > Christian, Tom, Brian, et. al. are doing a great job. > > -troy From owner-megaco@fore.com Fri Jun 1 22:24:22 2001 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA22749 for ; Fri, 1 Jun 2001 22:24:21 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id WAA27908; Fri, 1 Jun 2001 22:07:46 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id WAA20049 for megaco-list; Fri, 1 Jun 2001 22:03:01 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id WAA20040 for ; Fri, 1 Jun 2001 22:02:59 -0400 (EDT) Received: from gateway.hearme.com (gateway.hearme.com [204.242.182.129]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id WAA27624 for ; Fri, 1 Jun 2001 22:02:53 -0400 (EDT) Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01600; Fri, 1 Jun 2001 17:52:27 -0700 (PDT) Received: (from corey@localhost) by nodserv.hearme.com (8.9.1/8.9.1) id RAA28786 for corey@hearme.com; Fri, 1 Jun 2001 17:52:26 -0700 (PDT) Received: from gateway.hearme.com (localhost [127.0.0.1]) by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id KAA12914 for ; Thu, 31 May 2001 10:46:33 -0700 (PDT) Received: from lists.bell-labs.com ([204.178.16.58]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id KAA17387 for ; Thu, 31 May 2001 10:46:32 -0700 (PDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F2BC444427; Thu, 31 May 2001 13:43:14 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by lists.bell-labs.com (Postfix) with ESMTP id 0D860443A3; Thu, 31 May 2001 13:42:05 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA07898; Thu, 31 May 2001 13:41:29 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA14833; Thu, 31 May 2001 13:41:31 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 31 May 2001 13:41:30 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF044654D4@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: diffserv@ietf.org, iptel@lists.bell-labs.com, megaco@fore.com, sip@lists.bell-labs.com, tsvwg@ietf.org Cc: gratta@lucent.com, ITU-SG16@mailbag.cps.INTEL.COM MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Subject: [SIP] RE: [Sipping] RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL M ECHANISM FOR E ND-TO-END QOS SERVICE CONTROL X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 31 May 2001 13:41:29 -0400 Content-Type: text/plain; charset="iso-8859-1" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Folks, this thread may or may not be the start of something good or evil, but it is going out to too many lists! Please, as of now, let's move it to one, and only one list. I nominate tsvwg. If you are replying to any message on this thread, PLEASE edit the to/cc to limit it to tsvwg@ietf.org Brian > -----Original Message----- > From: Fred Baker [mailto:fred@cisco.com] > Sent: Thursday, May 31, 2001 1:09 PM > To: Roy, Radhika R, ALCTA > Cc: Bob Braden; gratta@lucent.com; sob@harvard.edu; mankin@isi.edu; > diffserv@ietf.org; iptel@lists.bell-labs.com; > issll@mercury.lcs.mit.edu; > megaco@fore.com; sip@lists.bell-labs.com; sipping@ietf.org; > tsvwg@ietf.org; hiramatsu.yukio@lab.ntt.co.jp; rbuhrke@lucent.com; > tsg11q8@ties.itu.ch; tsg11q9@ties.itu.ch; > ITU-SG16@mailbag.cps.INTEL.COM > Subject: [Sipping] RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL > MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL > > > At 06:08 AM 5/31/2001, Roy, Radhika R, ALCTA wrote: > >All applications (e.g., H.323, SIP) uses signaling messages > >among its functional entities (e.g., terminal, agents, > >gatekeepers, proxies, gateways) for communications. > > I'm not sure we're on the same planet. Please help me out here. > > I can think of a few applications that have agents, > gatekeepers, proxies, > and gateways, mostly resulting from the imposition of firewalls or > authentication systems, or from legacy applications like > imitating the > telephone system in a data network. The only one that > *requires* any kind > of gateway, to my knowledge, is H.323 teleconferencing, which > represents a > paltry fraction of traffic according to most current > measurements. Anything > else (75% of Internet traffic is http or FTP, most of the > rest is mail, on > private LANs applications like NFS are pretty common, and > even SIP can be > done without a gateway between consenting systems) could be > hooked up in > separate systems on a LAN and made to work without any such > signalling at all. > > Could you be more specific on what QoS signalling is required > by the world > wide web, mail, FTP, common ERP applications like ERP and PeopleSoft, > calendaring, and so on? If not, could you be more specific > about what "all" > applications you have in mind? > > And could you be more specific about what issues this proposal is > addressing that have not already been addressed in de facto > standards and > deployed in operational systems? It would be very nice to > understand what > you are preparing to ask vendors to do, and whether operators are > interested in deploying them. > > > > _______________________________________________ > Sipping mailing list > Sipping@ietf.org > http://www.ietf.org/mailman/listinfo/sipping > _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From owner-megaco@fore.com Fri Jun 1 22:24:47 2001 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA22781 for ; Fri, 1 Jun 2001 22:24:46 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id VAA26022; Fri, 1 Jun 2001 21:15:12 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id VAA17614 for megaco-list; Fri, 1 Jun 2001 21:07:49 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id VAA17605 for ; Fri, 1 Jun 2001 21:07:40 -0400 (EDT) Received: from gateway.hearme.com (gateway.hearme.com [204.242.182.129]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id VAA25159 for ; Fri, 1 Jun 2001 21:07:32 -0400 (EDT) Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id SAA01919; Fri, 1 Jun 2001 18:05:06 -0700 (PDT) Received: (from corey@localhost) by nodserv.hearme.com (8.9.1/8.9.1) id SAA28982 for corey@hearme.com; Fri, 1 Jun 2001 18:03:04 -0700 (PDT) Received: from gateway.hearme.com (localhost [127.0.0.1]) by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id QAA17653 for ; Thu, 31 May 2001 16:02:12 -0700 (PDT) Received: from lists.bell-labs.com ([204.178.16.58]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id QAA23572 for ; Thu, 31 May 2001 16:02:11 -0700 (PDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9792E444AF; Thu, 31 May 2001 17:56:56 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69]) by lists.bell-labs.com (Postfix) with ESMTP id 9BDA5443A3; Thu, 31 May 2001 13:53:46 -0400 (EDT) Received: from gab200r1.ems.att.com ([135.37.94.32]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id f4VHpPC24217; Thu, 31 May 2001 13:51:25 -0400 (EDT) Received: from njb140bh1.ems.att.com by gab200r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id NAA00157; Thu, 31 May 2001 13:51:00 -0400 (EDT) Received: by njb140bh1.ems.att.com with Internet Mail Service (5.5.2653.19) id ; Thu, 31 May 2001 13:51:22 -0400 Message-ID: From: "Roy, Radhika R, ALCTA" To: Fred Baker Cc: Bob Braden , gratta@lucent.com, sob@harvard.edu, mankin@isi.edu, diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org, hiramatsu.yukio@lab.ntt.co.jp, rbuhrke@lucent.com, tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch, ITU-SG16@mailbag.cps.INTEL.COM MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: [SIP] RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 31 May 2001 13:51:09 -0400 Content-Type: text/plain; charset="iso-8859-1" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Hi, Baker: It appears that a good amount discussion can be started to answer your questions (what has being discussed for the last couple of years in the ITU-T and TIPHON in particular). I am not trying to do so. Let me answer your questions summarizing the key points as follows: 1. Broadly, all applications can be considered in two categories: a. Real-time (e.g., audio, video [of H.323/SIP]) and b. Non-Real-time (e.g., data applications like file transfer, WWW, Mail, etc. - can a part of H.323/SIP). The performance parameters of both real-time (audio, video) and non-real-time (data) traffic can be abstracted in an universal way that can be used by all applications (e.g., H.323, SIP, WWW, mail, etc). However, the signaling messages used by each application are application-specific although the QOS parameters used by all of them still remain same (e.g., H.323 might use RAS/Q.931/Annex-G/H.245 signaling messages, SIP might use SDP). The QOS signaling messages that use QOS parameters can be termed as the application layer QOS signaling messages and are sent on end-to-end basis and the values of those QOS parameters do not change no matter what may be the underlying transport networks (e.g., IP, ATM). 2. The network layer QOS signaling messages carried over the network may not be end-to-end significance. For example, an end-to-end path of an IP network may consist of RSVP, DiffServ, MPLS, and RSVP. So, the network layer QOS parameters may get translated between the source-destination path and may not remain the same what has been negotiated on end-to-end basis in the application layer (item 1). The problems that are being addressed are as follows: A. How to develop the end-to-end QOS signaling mechanisms in the application layer B. How to relate the application layer QOS signaling to the network layer QOS signaling (e.g., RSVP, DifServ, MPLS, etc.) so that one-to-one consistency remain between the application and network layer QOS parameters. Hope this may clarify some of your questions. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Fred Baker [mailto:fred@cisco.com] Sent: Thursday, May 31, 2001 1:09 PM To: Roy, Radhika R, ALCTA Cc: Bob Braden; gratta@lucent.com; sob@harvard.edu; mankin@isi.edu; diffserv@ietf.org; iptel@lists.bell-labs.com; issll@mercury.lcs.mit.edu; megaco@fore.com; sip@lists.bell-labs.com; sipping@ietf.org; tsvwg@ietf.org; hiramatsu.yukio@lab.ntt.co.jp; rbuhrke@lucent.com; tsg11q8@ties.itu.ch; tsg11q9@ties.itu.ch; ITU-SG16@mailbag.cps.INTEL.COM Subject: RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL At 06:08 AM 5/31/2001, Roy, Radhika R, ALCTA wrote: >All applications (e.g., H.323, SIP) uses signaling messages >among its functional entities (e.g., terminal, agents, >gatekeepers, proxies, gateways) for communications. I'm not sure we're on the same planet. Please help me out here. I can think of a few applications that have agents, gatekeepers, proxies, and gateways, mostly resulting from the imposition of firewalls or authentication systems, or from legacy applications like imitating the telephone system in a data network. The only one that *requires* any kind of gateway, to my knowledge, is H.323 teleconferencing, which represents a paltry fraction of traffic according to most current measurements. Anything else (75% of Internet traffic is http or FTP, most of the rest is mail, on private LANs applications like NFS are pretty common, and even SIP can be done without a gateway between consenting systems) could be hooked up in separate systems on a LAN and made to work without any such signalling at all. Could you be more specific on what QoS signalling is required by the world wide web, mail, FTP, common ERP applications like ERP and PeopleSoft, calendaring, and so on? If not, could you be more specific about what "all" applications you have in mind? And could you be more specific about what issues this proposal is addressing that have not already been addressed in de facto standards and deployed in operational systems? It would be very nice to understand what you are preparing to ask vendors to do, and whether operators are interested in deploying them. _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From owner-megaco@fore.com Fri Jun 1 22:27:41 2001 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA22798 for ; Fri, 1 Jun 2001 22:27:40 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id WAA28047; Fri, 1 Jun 2001 22:09:20 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id WAA20155 for megaco-list; Fri, 1 Jun 2001 22:05:12 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id WAA20151 for ; Fri, 1 Jun 2001 22:05:11 -0400 (EDT) Received: from gateway.hearme.com (gateway.hearme.com [204.242.182.129]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id WAA27689 for ; Fri, 1 Jun 2001 22:04:09 -0400 (EDT) Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01431; Fri, 1 Jun 2001 17:46:24 -0700 (PDT) Received: (from corey@localhost) by nodserv.hearme.com (8.9.1/8.9.1) id RAA28669 for corey@hearme.com; Fri, 1 Jun 2001 17:45:13 -0700 (PDT) Received: from gateway.hearme.com (localhost [127.0.0.1]) by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id KAA12157 for ; Thu, 31 May 2001 10:14:38 -0700 (PDT) Received: from lists.bell-labs.com ([204.178.16.58]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id KAA16731 for ; Thu, 31 May 2001 10:14:37 -0700 (PDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 35C504434B; Thu, 31 May 2001 13:14:05 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by lists.bell-labs.com (Postfix) with ESMTP id 47E5B443C5; Thu, 31 May 2001 12:06:44 -0400 (EDT) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id JAA34990; Thu, 31 May 2001 09:04:55 -0700 Received: from hursley.ibm.com ([9.29.3.174]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id JAA20120; Thu, 31 May 2001 09:04:54 -0700 Message-ID: <3B166AFC.9DF4CD05@hursley.ibm.com> From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: gratta@lucent.com Cc: sob@harvard.edu, mankin@isi.edu, diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org, Yukio Hiramatsu , rbuhrke@lucent.com, tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch References: <200105302022.QAA03855@hotair.hobl.lucent.com> Subject: [IPTEL] Re: [Diffserv] PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR END-TO-END QOS SERVICE CONTROL X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Thu, 31 May 2001 11:02:04 -0500 X-MIME-Autoconverted: from quoted-printable to 8bit by nodserv.hearme.com id KAA12157 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by mailgate.pit.comms.marconi.com id WAA28047 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id WAA22798 Folks, This is *not* a discussion item for the diffserv WG mailing list. This WG is not chartered to discuss signalling issues. Whether the ITU should work on this and if so how it should collaborate with the IETF should be discussed at liaison level, not on a list with a few hundred people. So please everybody drop this discussion on the diffserv list and continue elswhere. Regards Brian Carpenter diffserv co-chair Greg Ratta wrote: > > This message was agreed to at ITU-T Study Group 11 meeting (Geneva, May 2001) and is being transmitted on behalf of Yukio Hiramatsu, Chairman of ITU-T SG 11. For further technical clarification, contact the Rapporteur for Q9/11 (Rolfe Buhrke, Tel: + 1 630 713 7022, { HYPERLINK mailto:rburke@lucent.com }rbuhrke@lucent.com) > > FULL TITLE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR END-TO-END QOS SERVICE CONTROL AND SIGNALLING PROTOCOL DEVELOPMENT BASED ON IP TRANSFER CAPABILITIES AND IP QOS CLASSES > > General > > Within ITU-T SG11 work has started on requirements for a generic protocol mechanism for end-to-end QoS service control. It was agreed within SG11 to proceed with this work utilising deliverables of ETSI TIPHON on end- to-end QoS service control as base material. It is the opinion of SG11 that this generic protocol mechanism for BICC intends to apply also to other protocols like SIP/SDP and H.323 next to generic extensions to the H.248/MEGACO protocol. > > It was noted that also QoS related work is in progress in IETF. Please find attached an initial draft of the BICC CS3 signalling requirements for end-to-end QoS service control. Please note the rationale for this activity and the framework for end-to-end QoS service control and network QoS control. The framework illustrates the field of application of the QoS handling at different levels and the different protocols involved. > > Proposals on end-to-end QoS service control > > It is proposed to start a joint activity with IETF on a generic protocol mechanism for end- to-end QoS service control. This refers to the potential work in IETF on the following topics: > > - Identification of the signalling requirements based on the ETSI TIPHON defined speech QoS service classes for VoIP and the signalling and control of end-to-end QoS for VoIP. The attachment provides the initial draft of the BICC CS3 signalling requirements for end-to-end QoS service control. > > - The definition of a generic call/bearer control mechanism in H.225/H.245, SIP/SDP and BICC CS3 for end-to-end QoS service control in the application plane. > > - The definition of generic extensions to H.248/MEGACO for end-to-end QoS service control between the application plane and the transport plane. > > - The translation between the generic protocol QoS information elements in H.248/MEGACO and the technology specific QoS parameters and QoS mechanisms in IP, ATM, MPLS, etc. > > Proposals on IP QoS classes and IP Transfer Capabilities > > ITU-T SG11 would like to inform IETF that it is investigating signalling requirements for protocol development based on the IP Transfer Capabilities and IP QoS classes, as being defined by ITU-T SG13 in Y.1541 and Y.iptc. The plan is to build upon signalling approaches developed by IETF. We would like to stress that the work on IP QoS classes and IP Transfer Capabilities by ITU-T SG13 is co- ordinated with IETF. > > ATTACHMENT Initial draft text of the BICC CS3 signalling requirements for end-to-end QoS service control. > > The ETSI specifications referenced as base material are available at the following URLs: > > ETSI TS 301 329 part 2, http://docbox.etsi.org/tech- org/tiphon/Document/tiphon/07- drafts/wg5/_Published/DTS05009/V1.1.1/ts_10 1329-2v111p.doc > > - ETSI TS 301 329 part 3 see http://docbox.etsi.org/tech- org/tiphon/Document/tiphon/07- drafts/wg5/_Published/DTS05003/DTS05003v096.zi p > > Further information about the ETSI TIPHON project is available at the following URL: > > - http://webapp.etsi.org/tbhomepage/TBDetails.as p?TB_ID=291&TB_NAME=TIPHON > __________________ > > BICC CS3 signalling requirements for end-to- end QoS service control > > EDITORS’ NOTE: This requirements text for end-to-end QoS service control is a first draft text and requires extensive updating based on liaison activities with other groups > > 1 Rationale > > The rationale of the BICC CS3 requirements for end-to-end service control is based on the analysis made by ETSI TIPHON (see the presentation available at the URL: http://docbox.etsi.org/tech- org/tiphon/Document/tiphon/ARCHIVES/2000/05- 200012- Kyoto/WG5%20TIPHON21%20presentation%20Rev1.ppt ). It shows the inter-relationship between the different QoS factors that finally determine > the perceived speech quality by the end- users. This perceived speech quality does not only depend on network quality of service (network packet loss, network jitter and network delay) but on the terminal implementation (jitter buffers and codec performance) as well. > > A second rationale is that end-to-end QoS requirements can be regarded as end-to-end quality budgets related to the media flows. To achieve the required end-to-end QoS these quality budgets must be allocated between the domains, including the user equipment (see Figure 7 in ETSI TS 301 329 part 3). The Transport QoS Parameters specify the QoS budgets for each Transport Domain. It is assumed that the performance of each domain is statistically independent from any other. > > Therefore end-to-end QoS service control at the call control level (i.e. application plane) is required based on generic signalling procedures in protocols like BICC, SIP/SDP, H.323 and H.248/MEGACO for end-to- end QoS service control. > > 2 Framework for end-to-end QoS service control and network QoS control. > > A framework for QoS control may be considered at different levels: call control (BICC, SIP/SDP, H.323), vertical control (H.248/MEGACO, CBC), bearer control (IP BCP) and bearer (DiffServ, IntServ/RSVP or MPLS/LDP). > > 1) Call-control > > a) End-to-end QoS service control is negotiated/communicated end-to-end at the call control level. ETSI TIPHON has defined a set of speech QoS classes, and signalling requirements and flows for this purpose. > > The idea is that call control protocols are enhanced with a generic end-to-end QoS service control mechanism to negotiate these speech QoS classes and associated parameters (Maximum delay, Maximum packet delay variation, Maximum packet loss, Peak bit rate and Maximum packet size). > > Such a generic end-to-end QoS service control mechanism should be defined independent of the underlying technology (ATM or IP) and operate across network domains and including terminal characteristics to negotiate/communicate the requested listener speech quality that will be perceived by the end-users (i.e. "mouth-to-ear"). > > b) BICC (Q.190x) is one of the call control protocols that may be enhanced this way. Similar enhancements may be applicable to other call-control protocols like SIP/SDP and H.323. > > 2) Vertical control > > a) QoS service control is also negotiated/communicated at the vertical control level. The ETSI TIPHON defined signalling requirements and flows include the vertical interface. The idea is that vertical control protocols are enhanced to negotiate/communicate the QoS settings (Maximum delay, Maximum packet delay variation, Maximum packet loss, Peak bit rate and Maximum packet size) in the bearer core network based on generic H.248/MEGACO extensions. > > These QoS settings should be defined independent of the underlying technology (ATM or IP) of the bearer core network. > > b) CBC (Q.1950) is one of the vertical control protocols that may be enhanced this way. > > 3) Bearer control > > a) Network QoS is negotiated/communicated at the bearer control level. ATM signalling does already intrinsically support network QoS. SG13 has recently defined IP QoS classes and IP Transfer Capabilities. > > The idea is that bearer control protocols for IP are enhanced with a mechanism to negotiate the network QoS by using IP QoS classes and IP Transfer Capabilities. > > b) IP BCP (Q.1970) is an IP bearer control protocol that may be enhanced this way. > > 4) Bearer > > a) Network QoS is negotiated/communicated at the bearer level, i.e. as part of the protocols associated with the bearers in the core network. The idea is that IP QoS classes and IP Transfer Capabilties, as defined by SG13, are used to differentiate between different types of IP traffic. > > b) IP QoS classes and IP Transfer Capabilities may be used to enhance existing IP mechanisms like DiffServ, IntServ/RSVP and MPLS/LDP. > > 3 QoS information flows applicable to BICC > > A general model is considered for QoS information flows with BICC when making a translation of the relevant parts in Figure 8 in ETSI TS 301 329 part 3. > > Section 4 details the Q.BICC related QoS primitives and parameters based on the QoS primitives and parameters in the ETSI deliverable. Similarly, section 5 provides the Q.CBC related QoS primitives and parameters. > > 4 Q.BICC related QoS primitives and parameters > > The Q.BICC related QoS primitives and parameters are extracted from clause 8.1 and clause 8.2 of ETSI TS 101 329 part 3. > > 4.1 Q.BICC related QoS primitives > > This information flow (QC2 in ETSI TS 101 329 part 3) communicates the QoS related bearer information between the domains of different service providers. > > Q.BICC QoS request (Qbicc.QoSreq) requests the establishment of a bearer conforming to a particular ETSI TIPHON Class of Service or with defined QoS characteristics. > > NOTE Identical to QoSM request (QC2.QoSMreq) in ETSI TS 101 329 part 3 clause 8.1.1. > > Q.BICC QoS confirm (Qbicc.QoSconf) acknowledges the creation of a bearer conforming to a requested ETSI TIPHON QoS Class or with specified QoS characteristics. > > NOTE Identical to QoSM confirm (QC2.QoSMconf) in ETSI TS 101 329 part 3 clause 8.1.1. > > Q.BICC QoS reject (Qbicc.QoSrej) rejects the creation of a bearer conforming to a requested ETSI TIPHON QoS Class or with specified QoS characteristics. > > NOTE Identical to QoSM reject (QC2.QoSMrej) in ETSI TS 101 329 part 3 clause 8.1.1. > > Q.BICC release request (Qbicc.QoSrelreq) requests the release of a bearer. > > NOTE Identical to QoSM release request (QC2.QoSMrelreq) in ETSI TS 101 329 part 3 clause 8.1.1 and the release of a transport flow is already covered by existing Q.BICC procedures in Q.1902 series. > > QoSM release confirm (Qbicc.QoSrelconf) confirms the release of a bearer. > > NOTE Identical to QoSM release confirm (QC2.QoSMrelconf) in ETSI TS 101 329 part 3 clause 8.1.1 and the release of a transport flow is already covered by existing Q.BICC procedures in Q.1902 series. > > 4.2 Q.BICC related QoS parameters > > Table 1 lists the parameters used in the Q.BICC related QoS primitives not yet covered by the Q.BICC protocol. The deleted items refer to the information elements already covered by the BICC CS2 protocol in the Q.1902 series. > > NOTE The contents of Table 1 is an interpretation of the table in ETSI TS 101 329 part 3 clause 8.2.3. > > Table 1: Identification of Q.BICC related parameters for end-to-end QoS service control > Qbicc.QoSreq QoS Service Class Optional > > Codec Type and Packetisation Mandatory > > Transport QoS Parameters Mandatory > > Traffic Descriptor Optional > > Transport Addresses Mandatory > > Application Data Transport Protocol Optional [Default RTP] > > Packet Transport Protocol Optional [Default UDP] > > QoS Mechanism Optional > > Qbicc.QoSconf QoS Service Class Optional > > Codec Type and Packetisation Mandatory > > Transport QoS Parameters Mandatory > > Transport Addresses Mandatory > > Application Data Transport Protocol Optional [Default RTP] > > Packet Transport Protocol Optional [Default UDP] > > Qbicc.QoSrej Reason [TBD] Mandatory > > 5 Q.CBC related QoS primitives and parameters > > The Q.CBC related QoS primitives and parameters are extracted from clause 8.1 and clause 8.2 of ETSI TS 101 329 part 3. > > 5.1 Q.CBC related QoS primitives > > This information flow (QT2 in ETSI TS 101 329 part 3) communicates the QoS related transport flow information between a service domain and an associated transport domain. This information contains the QoS related characteristics required of the transport flows that will carry the media flow and the properties of the media flow. > > Q.CBC QoS request (Qcbc.QoSreq) requests the establishment of a transport flow with defined QoS characteristics across a Transport Domain or the reservation of Transport Domain resource. > > NOTE Identical to TRM QoS request (QT2.TRMQreq) in ETSI TS 101 329 part 3 clause 8.1.3. > > Q.CBC QoS confirm (Qcbc.QoSconf) acknowledges the creation of a requested transport flow or the reservation of Transport Domain resource. > > NOTE Identical to TRM QoS confirm (QT2.TRMQconf) in ETSI TS 101 329 part 3 clause 8.1.3. > > Q.CBC QoS reject (Qcbc.QoSrej) rejects the creation of a requested transport flow or the reservation of Transport Domain resource. > > NOTE Identical to TRM QoS reject (QT2.TRMQrej) in ETSI TS 101 329 part 3 clause 8.1.3. > > Q.CBC QoS release request (Qcbc.QoSrelreq) requests the release of a transport flow. > > NOTE Identical to TRM QoS release request (QT2.TRM QoS relreq) in ETSI TS 101 329 part 3 clause 8.1.3. The release of a transport flow is already covered by the existing Q.CBC procedures in Q.1950. > > Q.CBC QoS release confirm (Qcbc.QoSrelconf) confirms the release of a transport flow. > > NOTE Identical to TRM QoS release confirm (QT2.TRM QoS relconf) in ETSI TS 101 329 part 3 clause 8.1.3. The release of a transport flow is already covered by the existing Q.CBC procedures in Q.1950. > > Q.CBC QoS performance notification (Qcbc.QoSperfnotif) notifies the Service Domain of the performance of the Transport Domain in meeting the requested QoS levels. This may be a periodic event or an urgent alarm. Note: this primitive is a management primitive and its use is for further study. > > NOTE Identical to TRM QoS performance notification (QT2.TRM QoS perfnotif) in ETSI TS 101 329 part 3 clause 8.1.3. For further study. > > 5.2 Q.CBC related QoS parameters > > Table 2 lists the parameters used in the Q.CBC related QoS primitives not yet covered by the Q.CBC protocol. The deleted items refer to the information elements already covered by the BICC CS2 protocol in Q.1950. > > NOTE The contents of Table 2 is an interpretation of the table in ETSI TS 101 329 part 3 clause 8.2.5. > > Table 2: Identification of Q.CBC related parameters for end-to-end QoS service control > > QT2.TRMQreq Transport QoS Parameters Mandatory > > Traffic Descriptor Mandatory > > Transport Addresses Mandatory > > Packet Transport Protocol Optional [Default UDP] > > QT2.TRMQconf Transport QoS Parameters Mandatory > > Transport Addresses Mandatory > > Packet Transport Protocol Optional [Default UDP] > > QoS Mechanism Optional > > QT2.TRMQrej Reason [TBD] Mandatory > > 6 Parameter contents > > Table 3 specifies the information to be covered by the parameters listed in sections 4.2 and 5.2 based on the QoS parameter groups in ETSI TS 101 329 part 3 clause 8.2.1. > > Table 3: Identification of parameter contents for end-to-end QoS service control > > QoS Service Class Describes the end-to-end ETSI TIPHON Best, High, Medium > class of a bearer or Best Effort > > Transport QoS Specifies the QoS characteristics Maximum Delay > Parameters required of the transport flow > carrying the media flow. Maximum Packet Delay Variation > > Maximum Packet Loss > > Traffic Descriptor Characterises the resource Peak Bit > requirements of an application data > flow (excludes transport flow Maximum Packet Size > resource requirements). > > Parameters specifying the ETSI TIPHON QoS Class as defined in ETSI TS 101 329 Part 2 > > The maximum delay permitted (ms) over either a segment of the transport flow or the remaining part of the transport flow. > > The maximum packet delay variation permitted (ms) over either a segment of the transport flow or the remaining part of the transport flow. > > The maximum packet loss permitted (%) over either a segment of the transport flow or the remaining part of the transport flow. [N.B. This measure assumes randomly distributed packet loss] > Maximum bit rate (bit/s) of the media flow. > > Maximum size of the media packets > > 7 Information flows and signalling procedures for end-to-end QoS service control > > EDITORS’ NOTE The information flows and signalling procedures for end-to-end QoS service control may be considered to follow the same principles as the already existing procedures for end-to-end codec negotiation in BICC CS1 and BICC CS2. Similarly mid-call procedures for end-to-end QoS modification and mid-call QoS modification may be considered because the perceived QoS is highly related to the codec type employed end- to-end as part of the connection. The exact scope and properties of these procedures and protocol message flows needs further discussion. > > Greg Ratta, Vice Chairman, ITU-T SG 11, Signalling requirements and protocols > Lucent Technologies Tel: +1 732 332 5174, Fax: +1 732 949 1196, gratta@lucent.com > > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Board Chairman, Internet Society http://www.isoc.org _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From owner-megaco@fore.com Fri Jun 1 22:29:45 2001 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA22809 for ; Fri, 1 Jun 2001 22:29:45 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id WAA28222; Fri, 1 Jun 2001 22:11:25 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id WAA20193 for megaco-list; Fri, 1 Jun 2001 22:06:10 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id WAA20169 for ; Fri, 1 Jun 2001 22:05:57 -0400 (EDT) Received: from gateway.hearme.com (gateway.hearme.com [204.242.182.129]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id WAA27778 for ; Fri, 1 Jun 2001 22:05:46 -0400 (EDT) Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01400; Fri, 1 Jun 2001 17:45:02 -0700 (PDT) Received: (from corey@localhost) by nodserv.hearme.com (8.9.1/8.9.1) id RAA28652 for corey@hearme.com; Fri, 1 Jun 2001 17:44:03 -0700 (PDT) Received: from gateway.hearme.com (localhost [127.0.0.1]) by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id IAA10535 for ; Thu, 31 May 2001 08:19:41 -0700 (PDT) Received: from lists.bell-labs.com ([204.178.16.58]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id IAA14880 for ; Thu, 31 May 2001 08:19:40 -0700 (PDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5E55A44437; Thu, 31 May 2001 10:29:25 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by lists.bell-labs.com (Postfix) with ESMTP id 6CA7044336; Wed, 30 May 2001 18:31:17 -0400 (EDT) Received: from FRED-W2K.cisco.com (fred-hm-dhcp3.cisco.com [171.69.128.118]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f4UMUBU11655; Wed, 30 May 2001 15:30:11 -0700 (PDT) Message-Id: <5.1.0.14.2.20010530152432.043b8ec0@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 To: gratta@lucent.com From: Fred Baker Cc: sob@harvard.edu, mankin@isi.edu, diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org, Yukio Hiramatsu , rbuhrke@lucent.com, tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch, John C Klensin , chair@ietf.org In-Reply-To: <200105302022.QAA03855@hotair.hobl.lucent.com> Mime-Version: 1.0 Subject: [SIP] Re: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR END-TO-END QOS SERVICE CONTROL X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 30 May 2001 15:30:00 -0700 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Greg: The URLs in this note were all sent with what the ETSI machine considered to be 'malformed syntax'. Could you resend the correct URLs? Fred _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From owner-megaco@fore.com Fri Jun 1 22:31:46 2001 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA23420 for ; Fri, 1 Jun 2001 22:31:45 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id WAA28463; Fri, 1 Jun 2001 22:13:46 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id WAA20296 for megaco-list; Fri, 1 Jun 2001 22:08:12 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id WAA20290 for ; Fri, 1 Jun 2001 22:08:10 -0400 (EDT) Received: from gateway.hearme.com (gateway.hearme.com [204.242.182.129]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id WAA27918 for ; Fri, 1 Jun 2001 22:07:59 -0400 (EDT) Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01442; Fri, 1 Jun 2001 17:48:05 -0700 (PDT) Received: (from corey@localhost) by nodserv.hearme.com (8.9.1/8.9.1) id RAA28684 for corey@hearme.com; Fri, 1 Jun 2001 17:46:24 -0700 (PDT) Received: from gateway.hearme.com (localhost [127.0.0.1]) by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id KAA12193 for ; Thu, 31 May 2001 10:16:21 -0700 (PDT) Received: from lists.bell-labs.com ([204.178.16.58]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id KAA16755 for ; Thu, 31 May 2001 10:16:20 -0700 (PDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0515B443E1; Thu, 31 May 2001 13:14:13 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by lists.bell-labs.com (Postfix) with SMTP id 55964443C5; Thu, 31 May 2001 12:12:00 -0400 (EDT) Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 31 May 2001 17:11:33 +0100 To: Lloyd Wood Cc: Fred Baker , gratta@lucent.com, sob@harvard.edu, mankin@isi.edu, diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org, Yukio Hiramatsu , rbuhrke@lucent.com, tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch, John C Klensin , chair@ietf.org, J.Crowcroft@cs.ucl.ac.uk In-reply-to: Your message of "Thu, 31 May 2001 16:13:43 BST." Message-ID: <922.991325489@cs.ucl.ac.uk> From: Jon Crowcroft Subject: [IPTEL] Re: [Diffserv] Re: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR END-TO-END QOS SERVICE CONTROL X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Thu, 31 May 2001 17:11:29 +0100 Content-Type: text Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk so the talk seems to be dated dec 2001, and makes me wonder if the tiphon folks have achieved a breakthru in QOS with e2e delays better than 0ms..... meanwhile, i stuck html versions of the files below at ftp://cs.ucl.ac.uk/darpa/tiphon/ (prob. doesnt help non windoze users since the html is generated by office 2000 apps so unless you have the unix internet explorer, too bad) In message , Lloyd Wood typed: >>On Wed, 30 May 2001, Fred Baker wrote: >> >>> Greg: >>> >>> The URLs in this note were all sent with what the ETSI machine considered >>> to be 'malformed syntax'. Could you resend the correct URLs? >> >>Just put all the parts together, removing unencoded >>spaces; the reason for the breaks after the hyphens seems >>obvious enough, but I'm at a loss to explain others. Here we go: >> >>http://docbox.etsi.org/tech-org/tiphon/Document/tiphon/07-drafts/wg5/_Published/DTS05009/V1.1.1/ts_101329-2v111p.doc >> >>http://docbox.etsi.org/tech-org/tiphon/Document/tiphon/07-drafts/wg5/_Published/DTS05003/DTS05003v096.zip >> >>http://webapp.etsi.org/tbhomepage/TBDetails.asp?TB_ID=291&TB_NAME=TIPHON >> >>http://docbox.etsi.org/tech-org/tiphon/Document/tiphon/ARCHIVES/2000/05-200012-Kyoto/WG5%20TIPHON21%20presentation%20Rev1.ppt >> >>So http://docbox.etsi.org/ is passworded but docs can be retrieved by >>advertised public direct url? Bizarre. >> >>L. >> >>PGP >> >> >> >> >> >> >> cheers jon _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From owner-megaco@fore.com Sat Jun 2 00:41:53 2001 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA24841 for ; Sat, 2 Jun 2001 00:41:53 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA23834; Fri, 1 Jun 2001 20:58:37 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id UAA16449 for megaco-list; Fri, 1 Jun 2001 20:53:04 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA16442 for ; Fri, 1 Jun 2001 20:53:01 -0400 (EDT) Received: from gateway.hearme.com (gateway.hearme.com [204.242.182.129]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA23194 for ; Fri, 1 Jun 2001 20:52:40 -0400 (EDT) Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01527; Fri, 1 Jun 2001 17:50:42 -0700 (PDT) Received: (from corey@localhost) by nodserv.hearme.com (8.9.1/8.9.1) id RAA28732 for corey@hearme.com; Fri, 1 Jun 2001 17:50:03 -0700 (PDT) Received: from gateway.hearme.com (localhost [127.0.0.1]) by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id KAA12742 for ; Thu, 31 May 2001 10:40:20 -0700 (PDT) Received: from optimus.ietf.org ([132.151.1.19]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id KAA16681 for ; Thu, 31 May 2001 10:12:15 -0700 (PDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23823; Thu, 31 May 2001 13:08:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA18138 for ; Thu, 31 May 2001 11:14:09 -0400 (EDT) Received: from prue.eim.surrey.ac.uk (IDENT:exim@prue.eim.surrey.ac.uk [131.227.76.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA28182; Thu, 31 May 2001 11:13:46 -0400 (EDT) Received: from phaestos.ee.surrey.ac.uk ([131.227.88.14] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.16 #1) id 155U91-00045U-00; Thu, 31 May 2001 16:13:51 +0100 Date: Thu, 31 May 2001 16:13:43 +0100 (BST) From: Lloyd Wood X-Sender: eep1lw@phaestos.ee.surrey.ac.uk Reply-To: Lloyd Wood To: Fred Baker cc: gratta@lucent.com, sob@harvard.edu, mankin@isi.edu, diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org, Yukio Hiramatsu , rbuhrke@lucent.com, tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch, John C Klensin , chair@ietf.org In-Reply-To: <5.1.0.14.2.20010530152432.043b8ec0@mira-sjcm-2.cisco.com> Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 X-Scanner: exiscan *155U91-00045U-00*ZWgRfZ3Wo52* http://duncanthrax.net/exiscan/ Subject: [Sipping] Re: [Diffserv] Re: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR END-TO-END QOS SERVICE CONTROL X-Mailman-Version: 1.0 List-Id: Official IETF Mailing List for the SIPPING Working Group X-BeenThere: sipping@ietf.org Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk On Wed, 30 May 2001, Fred Baker wrote: > Greg: > > The URLs in this note were all sent with what the ETSI machine considered > to be 'malformed syntax'. Could you resend the correct URLs? Just put all the parts together, removing unencoded spaces; the reason for the breaks after the hyphens seems obvious enough, but I'm at a loss to explain others. Here we go: http://docbox.etsi.org/tech-org/tiphon/Document/tiphon/07-drafts/wg5/_Published/DTS05009/V1.1.1/ts_101329-2v111p.doc http://docbox.etsi.org/tech-org/tiphon/Document/tiphon/07-drafts/wg5/_Published/DTS05003/DTS05003v096.zip http://webapp.etsi.org/tbhomepage/TBDetails.asp?TB_ID=291&TB_NAME=TIPHON http://docbox.etsi.org/tech-org/tiphon/Document/tiphon/ARCHIVES/2000/05-200012-Kyoto/WG5%20TIPHON21%20presentation%20Rev1.ppt So http://docbox.etsi.org/ is passworded but docs can be retrieved by advertised public direct url? Bizarre. L. PGP _______________________________________________ Sipping mailing list Sipping@ietf.org http://www.ietf.org/mailman/listinfo/sipping From owner-megaco@fore.com Sat Jun 2 00:52:21 2001 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA24871 for ; Sat, 2 Jun 2001 00:52:21 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA23926; Fri, 1 Jun 2001 20:59:24 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id UAA16544 for megaco-list; Fri, 1 Jun 2001 20:54:18 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA16536 for ; Fri, 1 Jun 2001 20:54:14 -0400 (EDT) Received: from gateway.hearme.com (gateway.hearme.com [204.242.182.129]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA23361 for ; Fri, 1 Jun 2001 20:54:01 -0400 (EDT) Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01578; Fri, 1 Jun 2001 17:51:36 -0700 (PDT) Received: (from corey@localhost) by nodserv.hearme.com (8.9.1/8.9.1) id RAA28745 for corey@hearme.com; Fri, 1 Jun 2001 17:50:42 -0700 (PDT) Received: from gateway.hearme.com (localhost [127.0.0.1]) by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id KAA12744 for ; Thu, 31 May 2001 10:40:27 -0700 (PDT) Received: from optimus.ietf.org ([132.151.1.19]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id KAA16683 for ; Thu, 31 May 2001 10:12:15 -0700 (PDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23907; Thu, 31 May 2001 13:08:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA21446 for ; Thu, 31 May 2001 12:11:54 -0400 (EDT) Received: from bells.cs.ucl.ac.uk ([128.16.5.31]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA00447; Thu, 31 May 2001 12:11:31 -0400 (EDT) Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 31 May 2001 17:11:33 +0100 To: Lloyd Wood cc: Fred Baker , gratta@lucent.com, sob@harvard.edu, mankin@isi.edu, diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org, Yukio Hiramatsu , rbuhrke@lucent.com, tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch, John C Klensin , chair@ietf.org, J.Crowcroft@cs.ucl.ac.uk In-reply-to: Your message of "Thu, 31 May 2001 16:13:43 BST." Date: Thu, 31 May 2001 17:11:29 +0100 Message-ID: <922.991325489@cs.ucl.ac.uk> From: Jon Crowcroft Subject: [Sipping] Re: [Diffserv] Re: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR END-TO-END QOS SERVICE CONTROL X-Mailman-Version: 1.0 List-Id: Official IETF Mailing List for the SIPPING Working Group X-BeenThere: sipping@ietf.org Content-Type: text Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk so the talk seems to be dated dec 2001, and makes me wonder if the tiphon folks have achieved a breakthru in QOS with e2e delays better than 0ms..... meanwhile, i stuck html versions of the files below at ftp://cs.ucl.ac.uk/darpa/tiphon/ (prob. doesnt help non windoze users since the html is generated by office 2000 apps so unless you have the unix internet explorer, too bad) In message , Lloyd Wood typed: >>On Wed, 30 May 2001, Fred Baker wrote: >> >>> Greg: >>> >>> The URLs in this note were all sent with what the ETSI machine considered >>> to be 'malformed syntax'. Could you resend the correct URLs? >> >>Just put all the parts together, removing unencoded >>spaces; the reason for the breaks after the hyphens seems >>obvious enough, but I'm at a loss to explain others. Here we go: >> >>http://docbox.etsi.org/tech-org/tiphon/Document/tiphon/07-drafts/wg5/_Published/DTS05009/V1.1.1/ts_101329-2v111p.doc >> >>http://docbox.etsi.org/tech-org/tiphon/Document/tiphon/07-drafts/wg5/_Published/DTS05003/DTS05003v096.zip >> >>http://webapp.etsi.org/tbhomepage/TBDetails.asp?TB_ID=291&TB_NAME=TIPHON >> >>http://docbox.etsi.org/tech-org/tiphon/Document/tiphon/ARCHIVES/2000/05-200012-Kyoto/WG5%20TIPHON21%20presentation%20Rev1.ppt >> >>So http://docbox.etsi.org/ is passworded but docs can be retrieved by >>advertised public direct url? Bizarre. >> >>L. >> >>PGP >> >> >> >> >> >> >> cheers jon _______________________________________________ Sipping mailing list Sipping@ietf.org http://www.ietf.org/mailman/listinfo/sipping From owner-megaco@fore.com Sat Jun 2 01:10:12 2001 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA25245 for ; Sat, 2 Jun 2001 01:10:11 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA23697; Fri, 1 Jun 2001 20:57:20 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id UAA16303 for megaco-list; Fri, 1 Jun 2001 20:51:39 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA16291 for ; Fri, 1 Jun 2001 20:51:16 -0400 (EDT) Received: from gateway.hearme.com (gateway.hearme.com [204.242.182.129]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA22983 for ; Fri, 1 Jun 2001 20:51:09 -0400 (EDT) Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01477; Fri, 1 Jun 2001 17:49:04 -0700 (PDT) Received: (from corey@localhost) by nodserv.hearme.com (8.9.1/8.9.1) id RAA28692 for corey@hearme.com; Fri, 1 Jun 2001 17:48:05 -0700 (PDT) Received: from gateway.hearme.com (localhost [127.0.0.1]) by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id KAA12283 for ; Thu, 31 May 2001 10:20:10 -0700 (PDT) Received: from optimus.ietf.org ([132.151.1.19]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id KAA16829 for ; Thu, 31 May 2001 10:20:09 -0700 (PDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24344; Thu, 31 May 2001 13:19:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24030 for ; Thu, 31 May 2001 13:12:24 -0400 (EDT) Received: from sj-msg-core-4.cisco.com ([171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA02436; Thu, 31 May 2001 13:12:02 -0400 (EDT) Received: from FRED-W2K.cisco.com (fred-hm-dhcp3.cisco.com [171.69.128.118]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f4VHBBU27133; Thu, 31 May 2001 10:11:12 -0700 (PDT) Message-Id: <5.1.0.14.2.20010531095817.04c50ea8@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 31 May 2001 10:09:10 -0700 To: "Roy, Radhika R, ALCTA" From: Fred Baker Cc: Bob Braden , gratta@lucent.com, sob@harvard.edu, mankin@isi.edu, diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org, hiramatsu.yukio@lab.ntt.co.jp, rbuhrke@lucent.com, tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch, ITU-SG16@mailbag.cps.INTEL.COM In-Reply-To: Mime-Version: 1.0 Subject: [Sipping] RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL X-Mailman-Version: 1.0 List-Id: Official IETF Mailing List for the SIPPING Working Group X-BeenThere: sipping@ietf.org Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk At 06:08 AM 5/31/2001, Roy, Radhika R, ALCTA wrote: >All applications (e.g., H.323, SIP) uses signaling messages >among its functional entities (e.g., terminal, agents, >gatekeepers, proxies, gateways) for communications. I'm not sure we're on the same planet. Please help me out here. I can think of a few applications that have agents, gatekeepers, proxies, and gateways, mostly resulting from the imposition of firewalls or authentication systems, or from legacy applications like imitating the telephone system in a data network. The only one that *requires* any kind of gateway, to my knowledge, is H.323 teleconferencing, which represents a paltry fraction of traffic according to most current measurements. Anything else (75% of Internet traffic is http or FTP, most of the rest is mail, on private LANs applications like NFS are pretty common, and even SIP can be done without a gateway between consenting systems) could be hooked up in separate systems on a LAN and made to work without any such signalling at all. Could you be more specific on what QoS signalling is required by the world wide web, mail, FTP, common ERP applications like ERP and PeopleSoft, calendaring, and so on? If not, could you be more specific about what "all" applications you have in mind? And could you be more specific about what issues this proposal is addressing that have not already been addressed in de facto standards and deployed in operational systems? It would be very nice to understand what you are preparing to ask vendors to do, and whether operators are interested in deploying them. _______________________________________________ Sipping mailing list Sipping@ietf.org http://www.ietf.org/mailman/listinfo/sipping From owner-megaco@fore.com Sat Jun 2 01:18:28 2001 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA25717 for ; Sat, 2 Jun 2001 01:18:27 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA22833; Fri, 1 Jun 2001 20:49:35 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id UAA15825 for megaco-list; Fri, 1 Jun 2001 20:43:10 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA15812 for ; Fri, 1 Jun 2001 20:43:01 -0400 (EDT) Received: from gateway.hearme.com (gateway.hearme.com [204.242.182.129]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA22008 for ; Fri, 1 Jun 2001 20:42:52 -0400 (EDT) Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01264; Fri, 1 Jun 2001 17:40:52 -0700 (PDT) Received: (from corey@localhost) by nodserv.hearme.com (8.9.1/8.9.1) id RAA28567 for corey@hearme.com; Fri, 1 Jun 2001 17:40:03 -0700 (PDT) Received: from gateway.hearme.com (localhost [127.0.0.1]) by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id HAA09977 for ; Thu, 31 May 2001 07:44:31 -0700 (PDT) Received: from lists.bell-labs.com ([204.178.16.58]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id HAA14130 for ; Thu, 31 May 2001 07:44:30 -0700 (PDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CA5C044440; Thu, 31 May 2001 10:29:33 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by lists.bell-labs.com (Postfix) with ESMTP id B9C0B44336; Wed, 30 May 2001 19:39:31 -0400 (EDT) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f4UNdHZ03453; Wed, 30 May 2001 16:39:17 -0700 (PDT) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id XAA13198; Wed, 30 May 2001 23:39:17 GMT Message-Id: <200105302339.XAA13198@gra.isi.edu> To: gratta@lucent.com, sob@harvard.edu, mankin@isi.edu, rrroy@att.com Cc: diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org, hiramatsu.yukio@lab.ntt.co.jp, rbuhrke@lucent.com, tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch, ITU-SG16@mailbag.cps.INTEL.COM X-Sun-Charset: US-ASCII Subject: [SIP] RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 30 May 2001 23:39:17 GMT Content-Type: text Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk *> From owner-issll@mercury.lcs.mit.edu Wed May 30 14:59:58 2001 *> From: "Roy, Radhika R, ALCTA" *> To: gratta@lucent.com, sob@harvard.edu, mankin@ISI.EDU *> Cc: diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, *> megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org, *> Yukio Hiramatsu *> , rbuhrke@lucent.com, *> tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch, ITU-SG16@mailbag.cps.INTEL.COM *> Subject: RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E *> ND-TO-END QOS SERVICE CONTROL *> Date: Wed, 30 May 2001 17:21:14 -0400 *> MIME-Version: 1.0 *> *> Hi, Everyone: *> *> Question Q.F/16 of ITU-T SG16 is fully dedicated for developing standards *> for "End-to-End QOS for Multimedia Applications". Contributions are also *> being under discussion in the ITU-T SG16 Brazil May 28 - June 8, 2001 *> meeting. This is very confusing. "End-to-End QOS for Multimedia Applications" is an really important topic, but this topic must be a superset of "End-to-End QOS signaling". There are much harder problems than signaling in providing E2E QoS. Can you explain how signaling relates to the title of this working party? Thanks, Bob Braden *> *> Applications like H.323, SIP, H.324, H.310, and others will also be able to *> use this Q.F/16's QOS signaling protocol. MEGACO/H.248 and BICC will also be *> able to use this when specs are fully developed and, TIPHON's QOS mechanisms *> can also be used as one of the mechanisms for implementations. _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From owner-megaco@fore.com Sat Jun 2 01:18:44 2001 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA25742 for ; Sat, 2 Jun 2001 01:18:43 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA23717; Fri, 1 Jun 2001 20:57:31 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id UAA16359 for megaco-list; Fri, 1 Jun 2001 20:52:21 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA16350 for ; Fri, 1 Jun 2001 20:52:18 -0400 (EDT) Received: from gateway.hearme.com (gateway.hearme.com [204.242.182.129]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA23112 for ; Fri, 1 Jun 2001 20:52:11 -0400 (EDT) Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01500; Fri, 1 Jun 2001 17:50:03 -0700 (PDT) Received: (from corey@localhost) by nodserv.hearme.com (8.9.1/8.9.1) id RAA28712 for corey@hearme.com; Fri, 1 Jun 2001 17:49:04 -0700 (PDT) Received: from gateway.hearme.com (localhost [127.0.0.1]) by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id KAA12310 for ; Thu, 31 May 2001 10:21:02 -0700 (PDT) Received: from lists.bell-labs.com ([204.178.16.58]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id KAA16857 for ; Thu, 31 May 2001 10:21:01 -0700 (PDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2574A443FC; Thu, 31 May 2001 13:14:18 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by lists.bell-labs.com (Postfix) with ESMTP id 21E354434B; Thu, 31 May 2001 13:12:28 -0400 (EDT) Received: from FRED-W2K.cisco.com (fred-hm-dhcp3.cisco.com [171.69.128.118]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f4VHBBU27133; Thu, 31 May 2001 10:11:12 -0700 (PDT) Message-Id: <5.1.0.14.2.20010531095817.04c50ea8@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 To: "Roy, Radhika R, ALCTA" From: Fred Baker Cc: Bob Braden , gratta@lucent.com, sob@harvard.edu, mankin@isi.edu, diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org, hiramatsu.yukio@lab.ntt.co.jp, rbuhrke@lucent.com, tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch, ITU-SG16@mailbag.cps.INTEL.COM In-Reply-To: Mime-Version: 1.0 Subject: [IPTEL] RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Thu, 31 May 2001 10:09:10 -0700 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk At 06:08 AM 5/31/2001, Roy, Radhika R, ALCTA wrote: >All applications (e.g., H.323, SIP) uses signaling messages >among its functional entities (e.g., terminal, agents, >gatekeepers, proxies, gateways) for communications. I'm not sure we're on the same planet. Please help me out here. I can think of a few applications that have agents, gatekeepers, proxies, and gateways, mostly resulting from the imposition of firewalls or authentication systems, or from legacy applications like imitating the telephone system in a data network. The only one that *requires* any kind of gateway, to my knowledge, is H.323 teleconferencing, which represents a paltry fraction of traffic according to most current measurements. Anything else (75% of Internet traffic is http or FTP, most of the rest is mail, on private LANs applications like NFS are pretty common, and even SIP can be done without a gateway between consenting systems) could be hooked up in separate systems on a LAN and made to work without any such signalling at all. Could you be more specific on what QoS signalling is required by the world wide web, mail, FTP, common ERP applications like ERP and PeopleSoft, calendaring, and so on? If not, could you be more specific about what "all" applications you have in mind? And could you be more specific about what issues this proposal is addressing that have not already been addressed in de facto standards and deployed in operational systems? It would be very nice to understand what you are preparing to ask vendors to do, and whether operators are interested in deploying them. _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From owner-megaco@fore.com Sat Jun 2 01:29:42 2001 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA26366 for ; Sat, 2 Jun 2001 01:29:41 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA23840; Fri, 1 Jun 2001 20:58:41 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id UAA16356 for megaco-list; Fri, 1 Jun 2001 20:52:20 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA16348 for ; Fri, 1 Jun 2001 20:52:18 -0400 (EDT) Received: from gateway.hearme.com (gateway.hearme.com [204.242.182.129]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA23108 for ; Fri, 1 Jun 2001 20:52:10 -0400 (EDT) Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01580; Fri, 1 Jun 2001 17:51:37 -0700 (PDT) Received: (from corey@localhost) by nodserv.hearme.com (8.9.1/8.9.1) id RAA28771 for corey@hearme.com; Fri, 1 Jun 2001 17:51:36 -0700 (PDT) Received: from gateway.hearme.com (localhost [127.0.0.1]) by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id KAA12836 for ; Thu, 31 May 2001 10:43:43 -0700 (PDT) Received: from lists.bell-labs.com ([204.178.16.58]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id KAA17308 for ; Thu, 31 May 2001 10:43:42 -0700 (PDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7C8C444400; Thu, 31 May 2001 13:43:04 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by lists.bell-labs.com (Postfix) with ESMTP id 0D860443A3; Thu, 31 May 2001 13:42:05 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA07898; Thu, 31 May 2001 13:41:29 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA14833; Thu, 31 May 2001 13:41:31 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 31 May 2001 13:41:30 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF044654D4@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: diffserv@ietf.org, iptel@lists.bell-labs.com, megaco@fore.com, sip@lists.bell-labs.com, tsvwg@ietf.org Cc: gratta@lucent.com, ITU-SG16@mailbag.cps.INTEL.COM MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Subject: [IPTEL] RE: [Sipping] RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL M ECHANISM FOR E ND-TO-END QOS SERVICE CONTROL X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Thu, 31 May 2001 13:41:29 -0400 Content-Type: text/plain; charset="iso-8859-1" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Folks, this thread may or may not be the start of something good or evil, but it is going out to too many lists! Please, as of now, let's move it to one, and only one list. I nominate tsvwg. If you are replying to any message on this thread, PLEASE edit the to/cc to limit it to tsvwg@ietf.org Brian > -----Original Message----- > From: Fred Baker [mailto:fred@cisco.com] > Sent: Thursday, May 31, 2001 1:09 PM > To: Roy, Radhika R, ALCTA > Cc: Bob Braden; gratta@lucent.com; sob@harvard.edu; mankin@isi.edu; > diffserv@ietf.org; iptel@lists.bell-labs.com; > issll@mercury.lcs.mit.edu; > megaco@fore.com; sip@lists.bell-labs.com; sipping@ietf.org; > tsvwg@ietf.org; hiramatsu.yukio@lab.ntt.co.jp; rbuhrke@lucent.com; > tsg11q8@ties.itu.ch; tsg11q9@ties.itu.ch; > ITU-SG16@mailbag.cps.INTEL.COM > Subject: [Sipping] RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL > MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL > > > At 06:08 AM 5/31/2001, Roy, Radhika R, ALCTA wrote: > >All applications (e.g., H.323, SIP) uses signaling messages > >among its functional entities (e.g., terminal, agents, > >gatekeepers, proxies, gateways) for communications. > > I'm not sure we're on the same planet. Please help me out here. > > I can think of a few applications that have agents, > gatekeepers, proxies, > and gateways, mostly resulting from the imposition of firewalls or > authentication systems, or from legacy applications like > imitating the > telephone system in a data network. The only one that > *requires* any kind > of gateway, to my knowledge, is H.323 teleconferencing, which > represents a > paltry fraction of traffic according to most current > measurements. Anything > else (75% of Internet traffic is http or FTP, most of the > rest is mail, on > private LANs applications like NFS are pretty common, and > even SIP can be > done without a gateway between consenting systems) could be > hooked up in > separate systems on a LAN and made to work without any such > signalling at all. > > Could you be more specific on what QoS signalling is required > by the world > wide web, mail, FTP, common ERP applications like ERP and PeopleSoft, > calendaring, and so on? If not, could you be more specific > about what "all" > applications you have in mind? > > And could you be more specific about what issues this proposal is > addressing that have not already been addressed in de facto > standards and > deployed in operational systems? It would be very nice to > understand what > you are preparing to ask vendors to do, and whether operators are > interested in deploying them. > > > > _______________________________________________ > Sipping mailing list > Sipping@ietf.org > http://www.ietf.org/mailman/listinfo/sipping > _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From owner-megaco@fore.com Sat Jun 2 01:34:44 2001 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA26729 for ; Sat, 2 Jun 2001 01:34:44 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA23301; Fri, 1 Jun 2001 20:53:36 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id UAA16068 for megaco-list; Fri, 1 Jun 2001 20:46:34 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA16057 for ; Fri, 1 Jun 2001 20:46:27 -0400 (EDT) Received: from gateway.hearme.com (gateway.hearme.com [204.242.182.129]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA22512 for ; Fri, 1 Jun 2001 20:46:14 -0400 (EDT) Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01335; Fri, 1 Jun 2001 17:43:14 -0700 (PDT) Received: (from corey@localhost) by nodserv.hearme.com (8.9.1/8.9.1) id RAA28611 for corey@hearme.com; Fri, 1 Jun 2001 17:42:25 -0700 (PDT) Received: from gateway.hearme.com (localhost [127.0.0.1]) by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id HAA10127 for ; Thu, 31 May 2001 07:52:27 -0700 (PDT) Received: from lists.bell-labs.com ([204.178.16.58]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id HAA14333 for ; Thu, 31 May 2001 07:52:26 -0700 (PDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C84EE4445E; Thu, 31 May 2001 10:30:07 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69]) by lists.bell-labs.com (Postfix) with ESMTP id 6A90144336; Thu, 31 May 2001 09:10:54 -0400 (EDT) Received: from gab200r1.ems.att.com ([135.37.94.32]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id f4VD8wC16127; Thu, 31 May 2001 09:08:58 -0400 (EDT) Received: from njb140bh1.ems.att.com by gab200r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id JAA04890; Thu, 31 May 2001 09:08:30 -0400 (EDT) Received: by njb140bh1.ems.att.com with Internet Mail Service (5.5.2653.19) id ; Thu, 31 May 2001 09:08:52 -0400 Message-ID: From: "Roy, Radhika R, ALCTA" To: Bob Braden , gratta@lucent.com, sob@harvard.edu, mankin@isi.edu Cc: diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org, hiramatsu.yukio@lab.ntt.co.jp, rbuhrke@lucent.com, tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch, ITU-SG16@mailbag.cps.INTEL.COM MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: [SIP] RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 31 May 2001 09:08:45 -0400 Content-Type: text/plain; charset="iso-8859-1" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Hi, Bob: All applications (e.g., H.323, SIP) uses signaling messages among its functional entities (e.g., terminal, agents, gatekeepers, proxies, gateways) for communications. The signaling messages that carry QOS parameters are treated as QOS signaling messages. The applications like SIP and H.323 send signaling messages end-to-end. H.323 uses H.225.0 RAS, Q.931, Annex G, and H.245 signaling protocols. SIP also uses SDP as a part of the signaling messages. The signaling messages that carry QOS related information can be treated as "End-to-End QOS signaling" messages. Kindly see the ongoing works of Q.F/16 of SG16. This will provide more information related to your questions. Hope this helps. Best regards, Radhika R. Roy -----Original Message----- From: Bob Braden [mailto:braden@ISI.EDU] Sent: Wednesday, May 30, 2001 7:39 PM To: gratta@lucent.com; sob@harvard.edu; mankin@ISI.EDU; Roy, Radhika R, ALCTA Cc: diffserv@ietf.org; iptel@lists.bell-labs.com; issll@mercury.lcs.mit.edu; megaco@fore.com; sip@lists.bell-labs.com; sipping@ietf.org; tsvwg@ietf.org; hiramatsu.yukio@lab.ntt.co.jp; rbuhrke@lucent.com; tsg11q8@ties.itu.ch; tsg11q9@ties.itu.ch; ITU-SG16@mailbag.cps.INTEL.COM Subject: RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL *> From owner-issll@mercury.lcs.mit.edu Wed May 30 14:59:58 2001 *> From: "Roy, Radhika R, ALCTA" *> To: gratta@lucent.com, sob@harvard.edu, mankin@ISI.EDU *> Cc: diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, *> megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org, *> Yukio Hiramatsu *> , rbuhrke@lucent.com, *> tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch, ITU-SG16@mailbag.cps.INTEL.COM *> Subject: RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E *> ND-TO-END QOS SERVICE CONTROL *> Date: Wed, 30 May 2001 17:21:14 -0400 *> MIME-Version: 1.0 *> *> Hi, Everyone: *> *> Question Q.F/16 of ITU-T SG16 is fully dedicated for developing standards *> for "End-to-End QOS for Multimedia Applications". Contributions are also *> being under discussion in the ITU-T SG16 Brazil May 28 - June 8, 2001 *> meeting. This is very confusing. "End-to-End QOS for Multimedia Applications" is an really important topic, but this topic must be a superset of "End-to-End QOS signaling". There are much harder problems than signaling in providing E2E QoS. Can you explain how signaling relates to the title of this working party? Thanks, Bob Braden *> *> Applications like H.323, SIP, H.324, H.310, and others will also be able to *> use this Q.F/16's QOS signaling protocol. MEGACO/H.248 and BICC will also be *> able to use this when specs are fully developed and, TIPHON's QOS mechanisms *> can also be used as one of the mechanisms for implementations. _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From owner-megaco@fore.com Sat Jun 2 01:50:57 2001 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA27531 for ; Sat, 2 Jun 2001 01:50:57 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA23362; Fri, 1 Jun 2001 20:54:02 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id UAA16064 for megaco-list; Fri, 1 Jun 2001 20:46:30 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA16060 for ; Fri, 1 Jun 2001 20:46:28 -0400 (EDT) Received: from gateway.hearme.com (gateway.hearme.com [204.242.182.129]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA22505 for ; Fri, 1 Jun 2001 20:46:12 -0400 (EDT) Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01376; Fri, 1 Jun 2001 17:44:03 -0700 (PDT) Received: (from corey@localhost) by nodserv.hearme.com (8.9.1/8.9.1) id RAA28624 for corey@hearme.com; Fri, 1 Jun 2001 17:43:14 -0700 (PDT) Received: from gateway.hearme.com (localhost [127.0.0.1]) by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id HAA10149 for ; Thu, 31 May 2001 07:53:59 -0700 (PDT) Received: from lists.bell-labs.com ([204.178.16.58]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id HAA14370 for ; Thu, 31 May 2001 07:53:58 -0700 (PDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AAFEA44466; Thu, 31 May 2001 10:31:09 -0400 (EDT) Delivered-To: sip@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id B6A2344336 for ; Wed, 30 May 2001 16:50:44 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Wed May 30 16:46:04 EDT 2001 Received: by lists.bell-labs.com (Postfix) id 0314944380; Wed, 30 May 2001 16:22:28 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from hotair.hobl.lucent.com (hotair.hobl.lucent.com [199.118.135.2]) by lists.bell-labs.com (Postfix) with SMTP id 0575844384; Wed, 30 May 2001 16:22:26 -0400 (EDT) Received: from 7460gratta.ho.lucent.com by hotair.hobl.lucent.com (SMI-8.6/EMS-1.5 sol2) id QAA03855; Wed, 30 May 2001 16:22:23 -0400 Message-Id: <200105302022.QAA03855@hotair.hobl.lucent.com> From: "Greg Ratta" To: sob@harvard.edu, mankin@isi.edu MIME-Version: 1.0 Content-transfer-encoding: Quoted-printable Reply-To: gratta@lucent.com Cc: diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org, Yukio Hiramatsu , rbuhrke@lucent.com, tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch X-mailer: Pegasus Mail for Win32 (v3.01d) Subject: [SIP] PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR END-TO-END QOS SERVICE CONTROL X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 30 May 2001 16:22:23 -0400 Content-Type: text/enriched; charset=ISO-8859-1 Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: Quoted-printable This message was agreed to at ITU-T Study Group 11 meeting (Geneva, May 2001) and is being transmitted on behalf of Yukio Hiramatsu, Chairman of ITU-T SG 11. For further technical clarification, contact the Rapporteur for Q9/11 (Rolfe Buhrke, Tel: + 1 630 713 7022, { HYPERLINK mailto:rburke@lucent.com }rbuhrke@lucent.com) FULL TITLE: Times New RomanPROPOSED JOINT ACTI= VITY ON A GENERIC PROTOCOL MECHANISM FOR END-TO-END QOS SERVICE CONTROL AND 0100,0100,0100SIGNALLING PROTOCOL DEVELO= PMENT BASED ON IP TRANSFER CAPABILITIES AND IP QOS CLASSES rightCourier NewGene= ral rightWithin ITU-T SG11 work has started on requirements for a generic protocol mechanism for end-to-end QoS service control. It was agreed within SG11 to proceed with this work utilising deliverables of ETSI TIPHON on end- to-end QoS service control as base material. It is the opinion of SG11 that this generic protocol mechanism for BICC intends to apply also to other protocols like SIP/SDP and H.323 next to generic extensions to the H.248/MEGACO protocol. rightIt was noted that also QoS related work is= in progress in IETF. Please find attached an initial draft of the BICC CS3 signalling requirements for end-to-end QoS service control. Please note the rationale for this activity and the framework for end-to-end QoS service control and network QoS control. The framework illustrates the field of application of the QoS handling at different levels and the different protocols involved. rightProposals on end-to-end QoS service contro= l rightIt is proposed to start a joint activity w= ith IETF on a generic protocol mechanism for end- to-end QoS service control. This refers to the potential work in IETF on the following topics: right- Identification of the signalling requirements based on the ETSI TIPHON defined speech QoS service classes for VoIP and the signalling and control of end-to-end QoS for VoIP. The attachment provides the initial draft of the BICC CS3 signalling requirements for end-to-end QoS service control. right- The definition of a generic call/bearer control mechanism in H.225/H.245, SIP/SDP and BICC CS3 for end-to-end QoS service control in the application plane. right- The definition of generic extensions to H.248/MEGACO for end-to-end QoS service control between the application plane and the transport plane. right- The translation between the generic protocol QoS information elements in H.248/MEGACO and the technology specific QoS parameters and QoS mechanisms in IP, ATM, MPLS, etc. rightProposals on IP QoS classes and IP Transfe= r Capabilities rightITU-T SG11 would like to inform IETF that = it is investigating signalling requirements for protocol development based on the IP Transfer Capabilities and IP QoS classes, as being defined by ITU-T SG13 in Y.1541 and Y.iptc. The plan is to build upon signalling approaches developed by IETF. We would like to stress that the work on IP QoS classes and IP Transfer Capabilities by ITU-T SG13 is co- ordinated with IETF. rightATTACHMENT Initial draft text of the BICC CS3 signalling requirements for end-to-end QoS service control. rightThe ETSI specifications referenced as base= material are available at the following URLs: outETSI TS 301 329 part 2, http://docbox.etsi.org/tech- org/tiphon/Document/tiphon/07- drafts/wg5/_Published/DTS05009/V1.1.1/ts_10 1329-2v111p.doc right- ETSI TS 301 329 part 3 see http://docbox.etsi.org/tech- org/tiphon/Document/tiphon/07- drafts/wg5/_Published/DTS05003/DTS05003v096.zi p rightFurther information about the ETSI TIPHON project is available at the following URL: right- http://webapp.etsi.org/tbhomepage/TBDetails.as p?TB_ID=3D291&TB_NAME=3DTIPHON right__________________ rightBICC CS3 signalling requirements for end-t= o- end QoS service control rightEDITORS=92 NOTE: This requirements text fo= r end-to-end QoS service control is a first draft text and requires extensive updating based on liaison activities with other groups right1 Rationale rightThe rationale of the BICC CS3 requirements= for end-to-end service control is based on the analysis made by ETSI TIPHON (see the presentation available at the URL: http://docbox.etsi.org/tech- org/tiphon/Document/tiphon/ARCHIVES/2000/05- 200012- Kyoto/WG5%20TIPHON21%20presentation%20Rev1.ppt ). It shows the inter-relationship between the different QoS factors that finally determine rightthe perceived speech quality by the end- users. This perceived speech quality does not only depend on network quality of service (network packet loss, network jitter and network delay) but on the terminal implementation (jitter buffers and codec performance) as well. right rightA second rationale is that end-to-end QoS requirements can be regarded as end-to-end quality budgets related to the media flows. To achieve the required end-to-end QoS these quality budgets must be allocated between the domains, including the user equipment (see Figure 7 in ETSI TS 301 329 part 3). The Transport QoS Parameters specify the QoS budgets for each Transport Domain. It is assumed that the performance of each domain is statistically independent from any other. right rightTherefore end-to-end QoS service control a= t the call control level (i.e. application plane) is required based on generic signalling procedures in protocols like BICC, SIP/SDP, H.323 and H.248/MEGACO for end-to- end QoS service control. right2 Framework for end-to-end QoS service control and network QoS control. rightA framework for QoS control may be conside= red at different levels: call control (BICC, SIP/SDP, H.323), vertical control (H.248/MEGACO, CBC), bearer control (IP BCP) and bearer (DiffServ, IntServ/RSVP or MPLS/LDP). right1) Call-control righta) End-to-end QoS service control is negotiated/communicated end-to-end at the call control level. ETSI TIPHON has defined a set of speech QoS classes, and signalling requirements and flows for this purpose. rightThe idea is that call control protocols ar= e enhanced with a generic end-to-end QoS service control mechanism to negotiate these speech QoS classes and associated parameters (Maximum delay, Maximum packet delay variation, Maximum packet loss, Peak bit rate and Maximum packet size). rightSuch a generic end-to-end QoS service cont= rol mechanism should be defined independent of the underlying technology (ATM or IP) and operate across network domains and including terminal characteristics to negotiate/communicate the requested listener speech quality that will be perceived by the end-users (i.e. "mouth-to-ear"). rightb) BICC (Q.190x) is one of the call contro= l protocols that may be enhanced this way. Similar enhancements may be applicable to other call-control protocols like SIP/SDP and H.323. right2) Vertical control righta) QoS service control is also negotiated/communicated at the vertical control level. The ETSI TIPHON defined signalling requirements and flows include the vertical interface. The idea is that vertical control protocols are enhanced to negotiate/communicate the QoS settings (Maximum delay, Maximum packet delay variation, Maximum packet loss, Peak bit rate and Maximum packet size) in the bearer core network based on generic H.248/MEGACO extensions. rightThese QoS settings should be defined independent of the underlying technology (ATM or IP) of the bearer core network. rightb) CBC (Q.1950) is one of the vertical control protocols that may be enhanced this way. right3) Bearer control righta) Network QoS is negotiated/communicated = at the bearer control level. ATM signalling does already intrinsically support network QoS. SG13 has recently defined IP QoS classes and IP Transfer Capabilities. rightThe idea is that bearer control protocols = for IP are enhanced with a mechanism to negotiate the network QoS by using IP QoS classes and IP Transfer Capabilities. rightb) IP BCP (Q.1970) is an IP bearer control= protocol that may be enhanced this way. right4) Bearer righta) Network QoS is negotiated/communicated = at the bearer level, i.e. as part of the protocols associated with the bearers in the core network. The idea is that IP QoS classes and IP Transfer Capabilties, as defined by SG13, are used to differentiate between different types of IP traffic. rightb) IP QoS classes and IP Transfer Capabilities may be used to enhance existing IP mechanisms like DiffServ, IntServ/RSVP and MPLS/LDP. right right3 QoS information flows applicable to BICC= rightA general model is considered for QoS information flows with BICC when making a translation of the relevant parts in Figure 8 in ETSI TS 301 329 part 3. right rightSection 4 details the Q.BICC related QoS primitives and parameters based on the QoS primitives and parameters in the ETSI deliverable. Similarly, section 5 provides the Q.CBC related QoS primitives and parameters. right4 Q.BICC related QoS primitives and parame= ters rightThe Q.BICC related QoS primitives and parameters are extracted from clause 8.1 and clause 8.2 of ETSI TS 101 329 part 3. right4.1 Q.BICC related QoS primitives rightThis information flow (QC2 in ETSI TS 101 = 329 part 3) communicates the QoS related bearer information between the domains of different service providers. rightQ.BICC QoS request (Qbicc.QoSreq) requests= the establishment of a bearer conforming to a particular ETSI TIPHON Class of Service or with defined QoS characteristics. rightNOTE Identical to QoSM request (QC2.QoSMre= q) in ETSI TS 101 329 part 3 clause 8.1.1. rightQ.BICC QoS confirm (Qbicc.QoSconf) acknowledges the creation of a bearer conforming to a requested ETSI TIPHON QoS Class or with specified QoS characteristics. rightNOTE Identical to QoSM confirm (QC2.QoSMconf) in ETSI TS 101 329 part 3 clause 8.1.1. rightQ.BICC QoS reject (Qbicc.QoSrej) rejects t= he creation of a bearer conforming to a requested ETSI TIPHON QoS Class or with specified QoS characteristics. rightNOTE Identical to QoSM reject (QC2.QoSMrej= ) in ETSI TS 101 329 part 3 clause 8.1.1. rightQ.BICC release request (Qbicc.QoSrelreq) requests the release of a bearer. rightNOTE Identical to QoSM release request (QC2.QoSMrelreq) in ETSI TS 101 329 part 3 clause 8.1.1 and the release of a transport flow is already covered by existing Q.BICC procedures in Q.1902 series. rightQoSM release confirm (Qbicc.QoSrelconf) confirms the release of a bearer. rightNOTE Identical to QoSM release confirm (QC2.QoSMrelconf) in ETSI TS 101 329 part 3 clause 8.1.1 and the release of a transport flow is already covered by existing Q.BICC procedures in Q.1902 series. right4.2 Q.BICC related QoS parameters rightTable 1 lists the parameters used in the Q.BICC related QoS primitives not yet covered by the Q.BICC protocol. The deleted items refer to the information elements already covered by the BICC CS2 protocol in the Q.1902 series. rightNOTE The contents of Table 1 is an interpretation of the table in ETSI TS 101 329 part 3 clause 8.2.3. rightTable 1: Identification of Q.BICC related parameters for end-to-end QoS service control rightQbicc.QoSreq QoS Service Class Optional right Codec Type and Packetisation Mandatory right Transport QoS Parameters Mandatory right Traffic Descriptor Optional right Transport Addresses Mandatory right Application Data Transport Protocol Optional [Default RTP] right Packet Transport Protocol Optional [Default UDP] right QoS Mechanism Optional rightQbicc.QoSconf QoS Service Class Optional right Codec Type and Packetisation Mandatory right Transport QoS Parameters Mandatory right Transport Addresses Mandatory right Application Data Transport Protocol Optional [Default RTP] right Packet Transport Protocol Optional [Default UDP] rightQbicc.QoSrej Reason [TBD] Mandatory right5 Q.CBC related QoS primitives and paramet= ers rightThe Q.CBC related QoS primitives and parameters are extracted from clause 8.1 and clause 8.2 of ETSI TS 101 329 part 3. right5.1 Q.CBC related QoS primitives rightThis information flow (QT2 in ETSI TS 101 = 329 part 3) communicates the QoS related transport flow information between a service domain and an associated transport domain. This information contains the QoS related characteristics required of the transport flows that will carry the media flow and the properties of the media flow. rightQ.CBC QoS request (Qcbc.QoSreq) requests t= he establishment of a transport flow with defined QoS characteristics across a Transport Domain or the reservation of Transport Domain resource. rightNOTE Identical to TRM QoS request (QT2.TRMQreq) in ETSI TS 101 329 part 3 clause 8.1.3. rightQ.CBC QoS confirm (Qcbc.QoSconf) acknowled= ges the creation of a requested transport flow or the reservation of Transport Domain resource. rightNOTE Identical to TRM QoS confirm (QT2.TRMQconf) in ETSI TS 101 329 part 3 clause 8.1.3. rightQ.CBC QoS reject (Qcbc.QoSrej) rejects the= creation of a requested transport flow or the reservation of Transport Domain resource. rightNOTE Identical to TRM QoS reject (QT2.TRMQrej) in ETSI TS 101 329 part 3 clause 8.1.3. rightQ.CBC QoS release request (Qcbc.QoSrelreq)= requests the release of a transport flow. rightNOTE Identical to TRM QoS release request (QT2.TRM QoS relreq) in ETSI TS 101 329 part 3 clause 8.1.3. The release of a transport flow is already covered by the existing Q.CBC procedures in Q.1950. rightQ.CBC QoS release confirm (Qcbc.QoSrelconf= ) confirms the release of a transport flow. rightNOTE Identical to TRM QoS release confirm (QT2.TRM QoS relconf) in ETSI TS 101 329 part 3 clause 8.1.3. The release of a transport flow is already covered by the existing Q.CBC procedures in Q.1950. rightQ.CBC QoS performance notification (Qcbc.QoSperfnotif) notifies the Service Domain of the performance of the Transport Domain in meeting the requested QoS levels. This may be a periodic event or an urgent alarm. Note: this primitive is a management primitive and its use is for further study. rightNOTE Identical to TRM QoS performance notification (QT2.TRM QoS perfnotif) in ETSI TS 101 329 part 3 clause 8.1.3. For further study. right5.2 Q.CBC related QoS parameters rightTable 2 lists the parameters used in the Q.CBC related QoS primitives not yet covered by the Q.CBC protocol. The deleted items refer to the information elements already covered by the BICC CS2 protocol in Q.1950. rightNOTE The contents of Table 2 is an interpretation of the table in ETSI TS 101 329 part 3 clause 8.2.5. rightTable 2: Identification of Q.CBC related parameters for end-to-end QoS service control rightQT2.TRMQreq Transport QoS Parameters Mandatory right Traffic Descriptor Mandatory right Transport Addresses Mandatory right Packet Transport Protocol Optional [Default UDP] rightQT2.TRMQconf Transport QoS Parameters Mandatory right Transport Addresses Mandatory right Packet Transport Protocol Optional [Default UDP] right QoS Mechanism Optional rightQT2.TRMQrej Reason [TBD] Mandatory right6 Parameter contents rightTable 3 specifies the information to be covered by the parameters listed in sections 4.2 and 5.2 based on the QoS parameter groups in ETSI TS 101 329 part 3 clause 8.2.1. rightTable 3: Identification of parameter conte= nts for end-to-end QoS service control rightQoS Service Class Describes the end-to-end= ETSI TIPHON Best, High, Medium right class of a bearer or Best Effort rightTransport QoS Specifies the QoS characteristics Maximum Delay rightParameters required of the transport flow= right carrying the media flow. Maximum Packet Delay Variation right Maximum Packet Loss rightTraffic Descriptor Characterises the resource Peak Bit right requirements of an application data right flow (excludes transport flow Maximum Packet Size right resource requirements). rightParameters specifying the ETSI TIPHON QoS Class as defined in ETSI TS 101 329 Part 2 rightThe maximum delay permitted (ms) over eith= er a segment of the transport flow or the remaining part of the transport flow. rightThe maximum packet delay variation permitt= ed (ms) over either a segment of the transport flow or the remaining part of the transport flow. rightThe maximum packet loss permitted (%) over= either a segment of the transport flow or the remaining part of the transport flow. [N.B. This measure assumes randomly distributed packet loss] rightMaximum bit rate (bit/s) of the media flow= . rightMaximum size of the media packets right7 Information flows and signalling procedu= res for end-to-end QoS service control rightEDITORS=92 NOTE The information flows and signalling procedures for end-to-end QoS service control may be considered to follow the same principles as the already existing procedures for end-to-end codec negotiation in BICC CS1 and BICC CS2. Similarly mid-call procedures for end-to-end QoS modification and mid-call QoS modification may be considered because the perceived QoS is highly related to the codec type employed end- to-end as part of the connection. The exact scope and properties of these procedures and protocol message flows needs further discussion. Greg Ratta, Vice Chairman, ITU-T SG 11, Signalling requirements and protoc= ols Lucent Technologies Tel: +1 732 332 5174, Fax: +1 732 949 1196, gratta@lucent.com _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From owner-megaco@fore.com Sat Jun 2 04:01:40 2001 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA10026 for ; Sat, 2 Jun 2001 04:01:40 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id DAA04842; Sat, 2 Jun 2001 03:53:11 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id DAA01966 for megaco-list; Sat, 2 Jun 2001 03:49:00 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id DAA01958; Sat, 2 Jun 2001 03:48:57 -0400 (EDT) From: skofax@logonlv.com Received: from new.golan.org.il (pc4.golan.org.il [212.150.20.4]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id DAA04690; Sat, 2 Jun 2001 03:48:43 -0400 (EDT) Received: from 1yG3X16st (unverified [63.53.190.249]) by new.golan.org.il (Vircom SMTPRS 4.4.184) with SMTP id ; Sat, 2 Jun 2001 10:48:51 +0100 Message-ID: DATE: 02 Jun 01 12:48:28 AM Reply-to: skofax@logonlv.com TO: skofax@logonlv.com SUBJECT: 200 Million Email Addresses - $149 Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk TO BE REMOVED FROM FUTURE MAILINGS, SIMPLY REPLY TO THIS MESSAGE AND PUT "REMOVE" IN THE SUBJECT. 200 MILLION EMAIL ADDRESSES FOR ONLY $149 You want to make some money? I can put you in touch with over 200 million people at virtually no cost. Can you make one cent from each of theses names? If you can you have a profit of over $2,000,000.00 That's right, I have over 200 Million Fresh email addresses that I will sell for only $149. These are all fresh addresses that include almost every person on the Internet today, with no duplications. They are all sorted and ready to be mailed. That is the best deal anywhere today! Imagine selling a product for only $5 and getting only a 1% response. That's OVER $10,000,000 IN YOUR POCKET !!! Don't believe it? People are making that kind of money right now by doing the same thing, that is why you get so much email from people selling you their product....it works! I will even tell you how to mail them with easy to follow step-by-step instructions I include with every order. I will send you a copy of every law concerning email. It is easy to obey the law and make a fortune. These 200 Million email addresses are yours to keep, so you can use them over and over. They come on a collection of several CDs. This offer is not for everyone. If you can not see the just how excellent the risk / reward ratio in this offer is then there is nothing I can do for you. To make money you must stop dreaming and TAKE ACTION. FOUR PACKAGES - BRONZE (addresses ONLY) SILVER (mailing software included) GOLD (everything to make the Internet your personal bank account) PLATINUM (ALL of the above, PLUS UNLIMITED TECH SUPPORT!) PACKAGE DESCRIPTIONS BELOW; **************************************** THE BRONZE MARKETING SETUP (addresses ONLY) 200,000,000 email addresses on CD These name are all in text files ready to mail!!! $149.00 SEVERAL WAYS TO ORDER !!! TO ORDER BY PHONE - CALL 530-343-9681 OTHER PACKAGES AND OTHER METHODS - SEE BELOW **************************************** THE SILVER MARKETING SETUP 200,000,000 email addresses on CD These name are all in text files ready to mail!!! AND Several different email programs and tools to help with your mailings and list management. $ 189.00 SEVERAL WAYS TO ORDER !!! TO ORDER BY PHONE - CALL 530-343-9681 OTHER PACKAGES AND OTHER METHODS - SEE BELOW **************************************** THE GOLD MARKETING SETUP VIRTUALLY EVERYTHING!! 200,000,000 email addresses on CD These name are all in text files ready to mail!!! AND Several different email programs and tools to help with your mailings and list management. AND Over 500 different Business Reports now being sold on the Internet for up to $100 each. You get full rights to resell these reports. With this package you get the email addresses, the software to mail them AND ready to sell information products. AND ...... . a collection of the 100 best money making adds currently floating around on the Internet. $ 249 SEVERAL WAYS TO ORDER !!! TO ORDER BY PHONE - CALL 530-343-9681 OTHER METHODS - SEE BELOW ************************************************************* THE PLATINUM MARKETING SETUP VIRTUALLY EVERYTHING!! 200,000,000 email addresses on CD These name are all in text files ready to mail!!! AND Several different email programs and tools to help with your mailings and list management. AND Over 500 different Business Reports now being sold on the Internet for up to $100 each. You get full rights to resell these reports. With this package you get the email addresses, the software to mail them AND ready to sell information products. AND ...... . a collection of the 100 best money making adds currently floating around on the Internet. AND..... LIVE TECH SUPPORT... WHENEVER YOU NEED IT... FOR AS LONG AS YOU NEED IT!!! $339 ********************************************************** SEVERAL WAYS TO ORDER !!! TO ORDER BY PHONE - CALL 530-343-9681 OTHER METHODS - SEE BELOW IF YOU ORDER BY PHONE OR FAX WE WILL SHIP YOUR CD CONTAINING THE 200 MILLION + NAMES WITHIN 12 HOURS OF YOUR ORDER!!! WE ACCEPT: AMERICAN EXPRESS, VISA & MASTERCARD TYPE OF CARD AMX / VISA / MC??_______________ EXPIRATION DATE ___________________________ NAME ON CREDIT CARD________________________ CREDIT CARD #_______________________________ BILLING ADDRESS ____________________________ CITY_________________________________________ STATE___________________ZIP__________________ COUNTRY____________________________________ PHONE INCLUDE AREA CODE___________________ EMAIL ADDRESS______________________________ WE WILL BILL selected amount to your account PLUS one of the following shipping costs: SHIPPING COST OF $3.85 FIRST CLASS MAIL SHIPPING COST OF $15.00 FEDERAL EXPRESS INTERNATIONAL SHIPPING CHARGE $25.00 + SALES TAX added where required 1) FAX your order and a copy of your SIGNED check payable to Cyber FirePower! for the appropriate amount to FAX # 530-343-1808. 2) Fax the same above requested credit card information to FAX # 530-343-1808. 3) Call phone # 530-343-9681. This is a 24 hour phone number to place a CREDIT CARD order. This is an ORDER LINE only. ALL INFORMATION NECESSARY FOR YOU TO SUCCESSFULLY MAIL QUICKLY, PROPERLY, & LEGALLY IS PROVIDED WITH YOUR ORDER. Copyright 2000, 2001 Please NOTE: This advertisement is NOT sponsored by ANY Internet Service Provider. This is an advertisement that is produced and sponsored by Cyber FirePower! for Cyber FirePower! to reach potential customers. ALSO TAKE NOTE: At the time of this mailing the return email address is a bonafide legitimate return email address that was signed up for with the express purpose of receiving all undeliverable emails as well as remove requests. On occasion the return email address provided may become disrupted by the efforts of, what we define as, Internet terrorists. If this is the case and you wish removal please call us. If you fax a copy of your phone bill where you called us for removal we will reimburse you via PayPal. Congress shall make no law respecting an establishment of religion, or prohibiting the free exercise thereof, or abridging the freedom of speech or of the press; or the right of the people peaceably to assemble, and to petition the Government for a redress of grievances. Amendment I, The US Constitution From owner-megaco@fore.com Sat Jun 2 05:31:05 2001 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA10440 for ; Sat, 2 Jun 2001 05:31:03 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id FAA06836; Sat, 2 Jun 2001 05:22:06 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id FAA05378 for megaco-list; Sat, 2 Jun 2001 05:17:23 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id FAA05374 for ; Sat, 2 Jun 2001 05:17:17 -0400 (EDT) Received: from mail.bhartitelesoft.com ([202.56.229.147]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id FAA06696 for ; Sat, 2 Jun 2001 05:16:55 -0400 (EDT) Received: from sarju (taquila [202.56.229.146]) by mail.bhartitelesoft.com (8.11.0/8.11.0) with SMTP id f529G2Y30394; Sat, 2 Jun 2001 14:46:04 +0530 Message-ID: <007101c0eb45$55291380$240310ac@bhartitelesoft.com> Reply-To: "Sarju Garg" From: "Sarju Garg" To: "YouLing Sha" Cc: "'megaco'" References: <01C0DFB0.0274C8A0@YSHA> Subject: Re: If resource of a termination is busy on a Non-Megaco call, what should MG do ? Date: Sat, 2 Jun 2001 14:50:53 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: 7bit Does in MEGACO paradigm, can a single termination in a MG be controlled by multiple MGC. I think that is not possible and that answers the question. Sarju ----- Original Message ----- From: YouLing Sha To: Sent: Saturday, May 19, 2001 1:04 AM Subject: If resource of a termination is busy on a Non-Megaco call, what should MG do ? > Hi, > > If a residentail gateway has a group of subscribers provisioned on the access side; > and on the network side, it has GR-303 to the PSTN and Megaco to IP. The calls made > by the subscribers from the access side can be routed to PSTN (using GR-303 not Megaco) > or IP (using Megaco) based on some pre-defined routing creteria (say time based, > digit based, or resource based). > > In MEGACO environment. MGC is the master and MG behaves as a slave. > Assuming the gateway has a subscriber (say A). Now if "A" is busy with a GR-303 > call to the PSTN (not going through the Megaco/MG on the gateway), > and the MGC being unaware of it, sends an incoming call request to the gateway for "A", > then the call has to be rejected because A is actually busy. > > The questions are: > > 1. What could be the error cause so that we could avoid any audit triggering > from the MGC. Because the audit correction might be termination out of > service or hook status change? > 2. Could we make the Termination Out of service temporarily (during the > period it's in a call with some other interface) by sending a Service > change to the MGC so that no incoming call request will come from MGC? > > Your advise is highly appreciated. > > Regards, > YouLing Sha > From owner-megaco@fore.com Sat Jun 2 06:57:45 2001 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA10725 for ; Sat, 2 Jun 2001 06:57:45 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id GAA08039; Sat, 2 Jun 2001 06:47:47 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id GAA07658 for megaco-list; Sat, 2 Jun 2001 06:43:00 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id GAA07654 for ; Sat, 2 Jun 2001 06:42:58 -0400 (EDT) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with SMTP id GAA07918 for ; Sat, 2 Jun 2001 06:42:54 -0400 (EDT) Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sat, 2 Jun 2001 11:42:33 +0100 to: rrroy@att.com cc: gratta@lucent.com, sob@harvard.edu, mankin@isi.edu, iptel@lists.bell-labs.com, megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org, hiramatsu.yukio@lab.ntt.co.jp, rbuhrke@lucent.com, tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch, ITU-SG16@mailbag.cps.INTEL.COM, J.Crowcroft@cs.ucl.ac.uk Subject: Re: [SIP] RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL In-reply-to: Your message of "Wed, 30 May 2001 23:39:17 GMT." <200105302339.XAA13198@gra.isi.edu> Date: Sat, 02 Jun 2001 11:42:30 +0100 Message-ID: <1723.991478550@cs.ucl.ac.uk> From: Jon Crowcroft Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk 1/ please stop copying all the lists. most of us are on all of them 2/ this is a layering question and is clearly indpenenant of mapping qos at lower layers (if it isnt its severely broken) - its clear that diffserve and issll sit several layeres BELOW what you want to do and that the signaling mechanisms for both are indpeennsdat and much lower - i notice for example you dont include 802.1p and q - similar layer type stuff... 3/ the docs cited are telpeony specific EXTREMELY and in fact dont relate to results that show that people have broader tolerances than yo umight expect when using different ways to get voice around - while its reasoanble to have a subset of QoS parameters signaled fro mapps that are application specific, a better way to do it is through a profiling mechanisms, which has a code point scheme, that then uses more general means to signal the actual QoS parameters 4/ the IETF has several appropriate signaling protocol efforts and paramerter specification schemes...although i believe its not well architectured across all the layers right now and its not clear we have a profile mechansism/language/syntax/semantics 5/ there's the siglite discussio ngoing on and there was the bof to talk about new signaling protocols at the last IETF _ this seems to be somewhat ignoring that activity - is that intentional? if so why? j. From owner-megaco@fore.com Mon Jun 4 11:51:42 2001 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10845 for ; Mon, 4 Jun 2001 11:51:42 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA15096; Mon, 4 Jun 2001 10:47:06 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA00321 for megaco-list; Mon, 4 Jun 2001 10:39:38 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA00302 for ; Mon, 4 Jun 2001 10:39:35 -0400 (EDT) Received: from auemail1.firewall.lucent.com (auemail1.lucent.com [192.11.223.161]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA14204 for ; Mon, 4 Jun 2001 10:39:32 -0400 (EDT) Received: from auemail1.firewall.lucent.com (localhost [127.0.0.1]) by auemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f54EdY203805 for ; Mon, 4 Jun 2001 10:39:34 -0400 (EDT) Received: from openetsrv.ho.lucent.com (h135-17-127-229.lucent.com [135.17.127.229]) by auemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f54EdXs03795 for ; Mon, 4 Jun 2001 10:39:33 -0400 (EDT) Received: from openetpc011 by openetsrv.ho.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id KAA18472; Mon, 4 Jun 2001 10:33:57 -0400 (EDT) Reply-To: From: "Raju" To: Subject: H.248 mail archival Date: Mon, 4 Jun 2001 10:47:34 -0400 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0164_01C0ECE3.C325CE60" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0164_01C0ECE3.C325CE60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi all, Where can I get the latest h.248 mail archivals? Nortel site has archivals till Feb'2001 only. Thanks Raju ------=_NextPart_000_0164_01C0ECE3.C325CE60 Content-Type: text/x-vcard; name="Makaraju,Maridi Raju.vcf" Content-Disposition: attachment; filename="Makaraju,Maridi Raju.vcf" Content-Transfer-Encoding: quoted-printable BEGIN:VCARD VERSION:2.1 N:Makaraju;Maridi;Raju FN:Makaraju,Maridi Raju NICKNAME:Maridi ORG:Lucent [Lucent Technologies Inc.];SGUS-CNS R&D (10033333) TITLE:Software Developer NOTE:Refresh data from POST TEL;WORK;VOICE:+1 732 949 2887 ADR;WORK:;;101 Crawfords Corner Rd;Holmdel;NJ;07733-3030;U S LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:101 Crawfords Corner = Rd=3D0D=3D0AHolmdel, NJ 07733-3030=3D0D=3D0AU S URL:http://www.post.lucent.com/cgi-bin/htpq?qtype=3Dmult&id=3Dmmraju EMAIL;PREF;INTERNET:mmraju@lucent.com REV:20010524T201447Z END:VCARD ------=_NextPart_000_0164_01C0ECE3.C325CE60-- From owner-megaco@fore.com Mon Jun 4 13:13:29 2001 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13307 for ; Mon, 4 Jun 2001 13:13:24 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA28098; Mon, 4 Jun 2001 13:02:51 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id NAA04959 for megaco-list; Mon, 4 Jun 2001 13:00:22 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA04952 for ; Mon, 4 Jun 2001 13:00:21 -0400 (EDT) Received: from hotmail.com (f91.law12.hotmail.com [64.4.19.91]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA27880 for ; Mon, 4 Jun 2001 13:00:19 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 4 Jun 2001 10:00:10 -0700 Received: from 129.192.63.5 by lw12fd.law12.hotmail.msn.com with HTTP; Mon, 04 Jun 2001 17:00:09 GMT X-Originating-IP: [129.192.63.5] From: "Hari Prasada babu Yenikapati" To: megaco@fore.com Subject: Megaco Grammar Date: Mon, 04 Jun 2001 10:00:09 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 04 Jun 2001 17:00:10.0031 (UTC) FILETIME=[D040C3F0:01C0ED17] Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Hi, Can anybody give me the Bison(yacc) grammar file for Megaco/H.248?. Thanks & Regards., -hari. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From owner-megaco@fore.com Mon Jun 4 15:16:52 2001 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA15994 for ; Mon, 4 Jun 2001 15:16:51 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA07225; Mon, 4 Jun 2001 14:50:05 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id OAA27327 for megaco-list; Mon, 4 Jun 2001 14:30:45 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA26970 for ; Mon, 4 Jun 2001 14:29:30 -0400 (EDT) Received: from huginn.ctccom.net (Huginn.CTCCom.net [207.190.194.11]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA05490 for ; Mon, 4 Jun 2001 14:29:07 -0400 (EDT) Received: from MBRAHMANAPALLY ([64.69.123.121]) by huginn.ctccom.net (Mirapoint) with SMTP id ACP77249; Mon, 4 Jun 2001 14:28:38 -0400 (EDT) From: "Madhu Babu Brahmanapally" To: , Subject: RE: H.248 mail archival Date: Thu, 4 Jan 2001 14:31:08 -0500 Message-ID: <02a901c07684$e3c6c870$c500a8c0@MBRAHMANAPALLY> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: 7bit Hi Raju, The official IETF archive of the Megaco list is available at ftp://ftp.ietf.org/ietf-mail-archive/megaco/ Regards Madhubabu -----Original Message----- From: owner-megaco@pit.comms.marconi.com [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Raju Sent: Monday, June 04, 2001 10:48 AM To: megaco@fore.com Subject: H.248 mail archival Hi all, Where can I get the latest h.248 mail archivals? Nortel site has archivals till Feb'2001 only. Thanks Raju From owner-megaco@fore.com Mon Jun 4 20:49:59 2001 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA22263 for ; Mon, 4 Jun 2001 20:49:59 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA26249; Mon, 4 Jun 2001 20:43:28 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id UAA09751 for megaco-list; Mon, 4 Jun 2001 20:41:34 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA09747 for ; Mon, 4 Jun 2001 20:41:33 -0400 (EDT) Received: from zcars0m9.ca.nortel.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA26130 for ; Mon, 4 Jun 2001 20:41:31 -0400 (EDT) Received: from zcars04e.nortelnetworks.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f550fNE00224 for ; Mon, 4 Jun 2001 20:41:23 -0400 (EDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.nortelnetworks.com; Mon, 4 Jun 2001 20:41:31 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 4 Jun 2001 20:41:37 -0400 Message-ID: <28560036253BD41191A10000F8BCBD1104C1263F@zcard00g.ca.nortel.com> From: "Tom-PT Taylor" To: megaco Subject: Cross-Posting Date: Mon, 4 Jun 2001 20:41:32 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) X-Orig: Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Speaking as list list administrator, I REALLY hope we don't get another series of exchanges cross-posted to many lists. I had to process several hundred bounces: too many headers, diagnosed (perhaps correctly) as a mail loop. Tom Taylor Multimedia Control and Applications Standards Ph. +1 613 736 0961 taylor@nortelnetworks.com From owner-megaco@fore.com Tue Jun 5 01:38:26 2001 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA29122 for ; Tue, 5 Jun 2001 01:38:26 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id BAA03297; Tue, 5 Jun 2001 01:31:42 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id BAA26599 for megaco-list; Tue, 5 Jun 2001 01:29:34 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id BAA26595 for ; Tue, 5 Jun 2001 01:29:31 -0400 (EDT) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id BAA03154 for ; Tue, 5 Jun 2001 01:29:28 -0400 (EDT) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id WAA09672; Mon, 4 Jun 2001 22:27:30 -0700 Received: from hursley.ibm.com (gsine05.us.sine.ibm.com [9.14.6.45]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id WAA20780; Mon, 4 Jun 2001 22:27:29 -0700 Message-ID: <3B1C6DEA.477A8786@hursley.ibm.com> Date: Tue, 05 Jun 2001 00:28:10 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: "Roy, Radhika R, ALCTA" CC: gratta@lucent.com, sob@harvard.edu, mankin@isi.edu, diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org, Yukio Hiramatsu , rbuhrke@lucent.com, tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch, ITU-SG16@mailbag.cps.INTEL.COM Subject: Re: [Diffserv] [IPTEL] RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR END-TO-END QOS SERVICE CONTROL References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: 7bit Hey! I asked people to STOP including diffserv@ietf.org on this thread. Please take notice everybody. Diffserv doesn't want to know. It is not our business. Talk about this somewhere else. Really. Brian Carpenter diffserv co-chair "Roy, Radhika R, ALCTA" wrote: > > Hi, Everyone: > > Question Q.F/16 of ITU-T SG16 is fully dedicated for developing standards > for "End-to-End QOS for Multimedia Applications". Contributions are also > being under discussion in the ITU-T SG16 Brazil May 28 - June 8, 2001 > meeting. > > Applications like H.323, SIP, H.324, H.310, and others will also be able to > use this Q.F/16's QOS signaling protocol. MEGACO/H.248 and BICC will also be > able to use this when specs are fully developed and, TIPHON's QOS mechanisms > can also be used as one of the mechanisms for implementations. > > BICC and MEGCAO/H.248 are only used as the protocol between the gateways, > NOT end-to-end (although SIP/H.323 or other protocols may be used between > the gateways). > > The "End-to-End QOS for Multimedia Applications" of SG16 can also be termed > as "Application Layer QOS." > > Q.F/16's end-to-end application layer QOS can also be implemented over the > network layer QOS like RSVP, DiffServe, and/or MPLS after proper mapping. > Similar is the case for the ATM network. > > Please note that the network layer QOS (e.g., RSVP, DiffServe, and/or MPLS) > may or may not have the end-to-end significance. For example, an IP network > may implement different QOS schemes in different domains (e.g., RVSP in one > domain, DiffServ in another domain). > > However, the application layer QOS is end-to-end that remains the same. For > example, an H.323 or SIP call that can traverse several IP domains where > each domain may implement its own network layer QOS schemes while the > H.323/SIP call carry the signaling messages and QOS parameters end-to-end > independent of the underlying network layer QOS mechanisms. > > Let us work together. > > Best regards, > Radhika R. Roy > AT&T > > -----Original Message----- > From: Greg Ratta [mailto:gratta@lucent.com] > Sent: Wednesday, May 30, 2001 4:22 PM > To: sob@harvard.edu; mankin@isi.edu > Cc: diffserv@ietf.org; iptel@lists.bell-labs.com; issll@mercury.lcs.mit.edu; > megaco@fore.com; sip@lists.bell-labs.com; sipping@ietf.org; tsvwg@ietf.org; > Yukio Hiramatsu; rbuhrke@lucent.com; tsg11q8@ties.itu.ch; > tsg11q9@ties.itu.ch > Subject: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR > END-TO-END QOS SERVICE CONTROL > > This message was agreed to at ITU-T Study Group 11 meeting (Geneva, May > 2001) and is being transmitted on behalf of Yukio Hiramatsu, Chairman of > ITU-T SG 11. For further technical clarification, contact the Rapporteur for > Q9/11 (Rolfe Buhrke, Tel: + 1 630 713 7022, { HYPERLINK > mailto:rburke@lucent.com }rbuhrke@lucent.com) > > FULL TITLE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR > END-TO-END QOS SERVICE CONTROL AND SIGNALLING PROTOCOL DEVELOPMENT BASED ON > IP TRANSFER CAPABILITIES AND IP QOS CLASSES > > General > > Within ITU-T SG11 work has started on requirements for a generic protocol > mechanism for end-to-end QoS service control. It was agreed within SG11 to > proceed with this work utilising deliverables of ETSI TIPHON on end- to-end > QoS service control as base material. It is the opinion of SG11 that this > generic protocol mechanism for BICC intends to apply also to other protocols > like SIP/SDP and H.323 next to generic extensions to the H.248/MEGACO > protocol. > > It was noted that also QoS related work is in progress in IETF. Please find > attached an initial draft of the BICC CS3 signalling requirements for > end-to-end QoS service control. Please note the rationale for this activity > and the framework for end-to-end QoS service control and network QoS > control. The framework illustrates the field of application of the QoS > handling at different levels and the different protocols involved. > > Proposals on end-to-end QoS service control > > It is proposed to start a joint activity with IETF on a generic protocol > mechanism for end- to-end QoS service control. This refers to the potential > work in IETF on the following topics: > > - Identification of the signalling requirements based on the ETSI TIPHON > defined speech QoS service classes for VoIP and the signalling and control > of end-to-end QoS for VoIP. The attachment provides the initial draft of the > BICC CS3 signalling requirements for end-to-end QoS service control. > > - The definition of a generic call/bearer control mechanism in H.225/H.245, > SIP/SDP and BICC CS3 for end-to-end QoS service control in the application > plane. > > - The definition of generic extensions to H.248/MEGACO for end-to-end QoS > service control between the application plane and the transport plane. > > - The translation between the generic protocol QoS information elements in > H.248/MEGACO and the technology specific QoS parameters and QoS mechanisms > in IP, ATM, MPLS, etc. > > Proposals on IP QoS classes and IP Transfer Capabilities > > ITU-T SG11 would like to inform IETF that it is investigating signalling > requirements for protocol development based on the IP Transfer Capabilities > and IP QoS classes, as being defined by ITU-T SG13 in Y.1541 and Y.iptc. The > plan is to build upon signalling approaches developed by IETF. We would like > to stress that the work on IP QoS classes and IP Transfer Capabilities by > ITU-T SG13 is co- ordinated with IETF. > > ATTACHMENT Initial draft text of the BICC CS3 signalling requirements > for end-to-end QoS service control. > > The ETSI specifications referenced as base material are available at the > following URLs: > > ETSI TS 301 329 part 2, http://docbox.etsi.org/tech- > org/tiphon/Document/tiphon/07- drafts/wg5/_Published/DTS05009/V1.1.1/ts_10 > 1329-2v111p.doc > > - ETSI TS 301 329 part 3 see http://docbox.etsi.org/tech- > org/tiphon/Document/tiphon/07- > drafts/wg5/_Published/DTS05003/DTS05003v096.zi p > > Further information about the ETSI TIPHON project is available at the > following URL: > > - http://webapp.etsi.org/tbhomepage/TBDetails.as p?TB_ID=291&TB_NAME=TIPHON > > __________________ > > BICC CS3 signalling requirements for end-to- end QoS service control > > EDITORS' NOTE: This requirements text for end-to-end QoS service control is > a first draft text and requires extensive updating based on liaison > activities with other groups > > 1 Rationale > > The rationale of the BICC CS3 requirements for end-to-end service control is > based on the analysis made by ETSI TIPHON (see the presentation available at > the URL: http://docbox.etsi.org/tech- > org/tiphon/Document/tiphon/ARCHIVES/2000/05- 200012- > Kyoto/WG5%20TIPHON21%20presentation%20Rev1.ppt ). It shows the > inter-relationship between the different QoS factors that finally determine > > the perceived speech quality by the end- users. This perceived speech > quality does not only depend on network quality of service (network packet > loss, network jitter and network delay) but on the terminal implementation > (jitter buffers and codec performance) as well. > > A second rationale is that end-to-end QoS requirements can be regarded as > end-to-end quality budgets related to the media flows. To achieve the > required end-to-end QoS these quality budgets must be allocated between the > domains, including the user equipment (see Figure 7 in ETSI TS 301 329 part > 3). The Transport QoS Parameters specify the QoS budgets for each Transport > Domain. It is assumed that the performance of each domain is statistically > independent from any other. > > Therefore end-to-end QoS service control at the call control level (i.e. > application plane) is required based on generic signalling procedures in > protocols like BICC, SIP/SDP, H.323 and H.248/MEGACO for end-to- end QoS > service control. > > 2 Framework for end-to-end QoS service control and network QoS control. > > A framework for QoS control may be considered at different levels: call > control (BICC, SIP/SDP, H.323), vertical control (H.248/MEGACO, CBC), bearer > control (IP BCP) and bearer (DiffServ, IntServ/RSVP or MPLS/LDP). > > 1) Call-control > > a) End-to-end QoS service control is negotiated/communicated end-to-end at > the call control level. ETSI TIPHON has defined a set of speech QoS classes, > and signalling requirements and flows for this purpose. > > The idea is that call control protocols are enhanced with a generic > end-to-end QoS service control mechanism to negotiate these speech QoS > classes and associated parameters (Maximum delay, Maximum packet delay > variation, Maximum packet loss, Peak bit rate and Maximum packet size). > > Such a generic end-to-end QoS service control mechanism should be defined > independent of the underlying technology (ATM or IP) and operate across > network domains and including terminal characteristics to > negotiate/communicate the requested listener speech quality that will be > perceived by the end-users (i.e. "mouth-to-ear"). > > b) BICC (Q.190x) is one of the call control protocols that may be enhanced > this way. Similar enhancements may be applicable to other call-control > protocols like SIP/SDP and H.323. > > 2) Vertical control > > a) QoS service control is also negotiated/communicated at the vertical > control level. The ETSI TIPHON defined signalling requirements and flows > include the vertical interface. The idea is that vertical control protocols > are enhanced to negotiate/communicate the QoS settings (Maximum delay, > Maximum packet delay variation, Maximum packet loss, Peak bit rate and > Maximum packet size) in the bearer core network based on generic > H.248/MEGACO extensions. > > These QoS settings should be defined independent of the underlying > technology (ATM or IP) of the bearer core network. > > b) CBC (Q.1950) is one of the vertical control protocols that may be > enhanced this way. > > 3) Bearer control > > a) Network QoS is negotiated/communicated at the bearer control level. ATM > signalling does already intrinsically support network QoS. SG13 has recently > defined IP QoS classes and IP Transfer Capabilities. > > The idea is that bearer control protocols for IP are enhanced with a > mechanism to negotiate the network QoS by using IP QoS classes and IP > Transfer Capabilities. > > b) IP BCP (Q.1970) is an IP bearer control protocol that may be enhanced > this way. > > 4) Bearer > > a) Network QoS is negotiated/communicated at the bearer level, i.e. as part > of the protocols associated with the bearers in the core network. The idea > is that IP QoS classes and IP Transfer Capabilties, as defined by SG13, are > used to differentiate between different types of IP traffic. > > b) IP QoS classes and IP Transfer Capabilities may be used to enhance > existing IP mechanisms like DiffServ, IntServ/RSVP and MPLS/LDP. > > 3 QoS information flows applicable to BICC > > A general model is considered for QoS information flows with BICC when > making a translation of the relevant parts in Figure 8 in ETSI TS 301 329 > part 3. > > Section 4 details the Q.BICC related QoS primitives and parameters based on > the QoS primitives and parameters in the ETSI deliverable. Similarly, > section 5 provides the Q.CBC related QoS primitives and parameters. > > 4 Q.BICC related QoS primitives and parameters > > The Q.BICC related QoS primitives and parameters are extracted from clause > 8.1 and clause 8.2 of ETSI TS 101 329 part 3. > > 4.1 Q.BICC related QoS primitives > > This information flow (QC2 in ETSI TS 101 329 part 3) communicates the QoS > related bearer information between the domains of different service > providers. > > Q.BICC QoS request (Qbicc.QoSreq) requests the establishment of a bearer > conforming to a particular ETSI TIPHON Class of Service or with defined QoS > characteristics. > > NOTE Identical to QoSM request (QC2.QoSMreq) in ETSI TS 101 329 part 3 > clause 8.1.1. > > Q.BICC QoS confirm (Qbicc.QoSconf) acknowledges the creation of a bearer > conforming to a requested ETSI TIPHON QoS Class or with specified QoS > characteristics. > > NOTE Identical to QoSM confirm (QC2.QoSMconf) in ETSI TS 101 329 part 3 > clause 8.1.1. > > Q.BICC QoS reject (Qbicc.QoSrej) rejects the creation of a bearer conforming > to a requested ETSI TIPHON QoS Class or with specified QoS characteristics. > > NOTE Identical to QoSM reject (QC2.QoSMrej) in ETSI TS 101 329 part 3 > clause 8.1.1. > > Q.BICC release request (Qbicc.QoSrelreq) requests the release of a bearer. > > NOTE Identical to QoSM release request (QC2.QoSMrelreq) in ETSI TS 101 > 329 part 3 clause 8.1.1 and the release of a transport flow is already > covered by existing Q.BICC procedures in Q.1902 series. > > QoSM release confirm (Qbicc.QoSrelconf) confirms the release of a bearer. > > NOTE Identical to QoSM release confirm (QC2.QoSMrelconf) in ETSI TS 101 > 329 part 3 clause 8.1.1 and the release of a transport flow is already > covered by existing Q.BICC procedures in Q.1902 series. > > 4.2 Q.BICC related QoS parameters > > Table 1 lists the parameters used in the Q.BICC related QoS primitives not > yet covered by the Q.BICC protocol. The deleted items refer to the > information elements already covered by the BICC CS2 protocol in the Q.1902 > series. > > NOTE The contents of Table 1 is an interpretation of the table in ETSI TS > 101 329 part 3 clause 8.2.3. > > Table 1: Identification of Q.BICC related parameters for end-to-end QoS > service control > > Qbicc.QoSreq QoS Service Class Optional > > Codec Type and Packetisation Mandatory > > Transport QoS Parameters Mandatory > > Traffic Descriptor Optional > > Transport Addresses Mandatory > > Application Data Transport Protocol Optional > [Default RTP] > > Packet Transport Protocol Optional [Default UDP] > > QoS Mechanism Optional > > Qbicc.QoSconf QoS Service Class Optional > > Codec Type and Packetisation Mandatory > > Transport QoS Parameters Mandatory > > Transport Addresses Mandatory > > Application Data Transport Protocol Optional > [Default RTP] > > Packet Transport Protocol Optional [Default UDP] > > Qbicc.QoSrej Reason [TBD] Mandatory > > 5 Q.CBC related QoS primitives and parameters > > The Q.CBC related QoS primitives and parameters are extracted from clause > 8.1 and clause 8.2 of ETSI TS 101 329 part 3. > > 5.1 Q.CBC related QoS primitives > > This information flow (QT2 in ETSI TS 101 329 part 3) communicates the QoS > related transport flow information between a service domain and an > associated transport domain. This information contains the QoS related > characteristics required of the transport flows that will carry the media > flow and the properties of the media flow. > > Q.CBC QoS request (Qcbc.QoSreq) requests the establishment of a transport > flow with defined QoS characteristics across a Transport Domain or the > reservation of Transport Domain resource. > > NOTE Identical to TRM QoS request (QT2.TRMQreq) in ETSI TS 101 329 part 3 > clause 8.1.3. > > Q.CBC QoS confirm (Qcbc.QoSconf) acknowledges the creation of a requested > transport flow or the reservation of Transport Domain resource. > > NOTE Identical to TRM QoS confirm (QT2.TRMQconf) in ETSI TS 101 329 part > 3 clause 8.1.3. > > Q.CBC QoS reject (Qcbc.QoSrej) rejects the creation of a requested transport > flow or the reservation of Transport Domain resource. > > NOTE Identical to TRM QoS reject (QT2.TRMQrej) in ETSI TS 101 329 part 3 > clause 8.1.3. > > Q.CBC QoS release request (Qcbc.QoSrelreq) requests the release of a > transport flow. > > NOTE Identical to TRM QoS release request (QT2.TRM QoS relreq) in ETSI TS > 101 329 part 3 clause 8.1.3. The release of a transport flow is already > covered by the existing Q.CBC procedures in Q.1950. > > Q.CBC QoS release confirm (Qcbc.QoSrelconf) confirms the release of a > transport flow. > > NOTE Identical to TRM QoS release confirm (QT2.TRM QoS relconf) in ETSI > TS 101 329 part 3 clause 8.1.3. The release of a transport flow is already > covered by the existing Q.CBC procedures in Q.1950. > > Q.CBC QoS performance notification (Qcbc.QoSperfnotif) notifies the Service > Domain of the performance of the Transport Domain in meeting the requested > QoS levels. This may be a periodic event or an urgent alarm. Note: this > primitive is a management primitive and its use is for further study. > > NOTE Identical to TRM QoS performance notification (QT2.TRM QoS > perfnotif) in ETSI TS 101 329 part 3 clause 8.1.3. For further study. > > 5.2 Q.CBC related QoS parameters > > Table 2 lists the parameters used in the Q.CBC related QoS primitives not > yet covered by the Q.CBC protocol. The deleted items refer to the > information elements already covered by the BICC CS2 protocol in Q.1950. > > NOTE The contents of Table 2 is an interpretation of the table in ETSI TS > 101 329 part 3 clause 8.2.5. > > Table 2: Identification of Q.CBC related parameters for end-to-end QoS > service control > > QT2.TRMQreq Transport QoS Parameters Mandatory > > Traffic Descriptor Mandatory > > Transport Addresses Mandatory > > Packet Transport Protocol Optional [Default UDP] > > QT2.TRMQconf Transport QoS Parameters Mandatory > > Transport Addresses Mandatory > > Packet Transport Protocol Optional [Default UDP] > > QoS Mechanism Optional > > QT2.TRMQrej Reason [TBD] Mandatory > > 6 Parameter contents > > Table 3 specifies the information to be covered by the parameters listed in > sections 4.2 and 5.2 based on the QoS parameter groups in ETSI TS 101 329 > part 3 clause 8.2.1. > > Table 3: Identification of parameter contents for end-to-end QoS service > control > > QoS Service Class Describes the end-to-end ETSI TIPHON Best, > High, Medium > > class of a beareror Best Effort > > Transport QoS Specifies the QoS characteristics Maximum > Delay > > Parameters required of the transport flow > > carrying the media flow. Maximum Packet > Delay Variation > > Maximum Packet Loss > > Traffic Descriptor Characterises the resource Peak Bit > > requirements of an application data > > flow (excludes transport flow Maximum Packet Size > > resource requirements). > > Parameters specifying the ETSI TIPHON QoS Class as defined in ETSI TS 101 > 329 Part 2 > > The maximum delay permitted (ms) over either a segment of the transport flow > or the remaining part of the transport flow. > > The maximum packet delay variation permitted (ms) over either a segment of > the transport flow or the remaining part of the transport flow. > > The maximum packet loss permitted (%) over either a segment of the transport > flow or the remaining part of the transport flow. [N.B. This measure assumes > randomly distributed packet loss] > > Maximum bit rate (bit/s) of the media flow. > > Maximum size of the media packets > > 7 Information flows and signalling procedures for end-to-end QoS service > control > > EDITORS' NOTE The information flows and signalling procedures for > end-to-end QoS service control may be considered to follow the same > principles as the already existing procedures for end-to-end codec > negotiation in BICC CS1 and BICC CS2. Similarly mid-call procedures for > end-to-end QoS modification and mid-call QoS modification may be considered > because the perceived QoS is highly related to the codec type employed end- > to-end as part of the connection. The exact scope and properties of these > procedures and protocol message flows needs further discussion. > > Greg Ratta, Vice Chairman, ITU-T SG 11, Signalling requirements and > protocols > > Lucent Technologies Tel: +1 732 332 5174, Fax: +1 732 949 1196, > gratta@lucent.com > > _______________________________________________ > IPTEL mailing list > IPTEL@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/iptel > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Board Chairman, Internet Society http://www.isoc.org From owner-megaco@fore.com Tue Jun 5 19:07:56 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA01293 for ; Tue, 5 Jun 2001 19:07:56 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id TAA05370; Tue, 5 Jun 2001 19:07:33 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id TAA09169 for megaco-list; Tue, 5 Jun 2001 19:00:06 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id TAA09152 for ; Tue, 5 Jun 2001 19:00:04 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id TAA05010 for ; Tue, 5 Jun 2001 19:00:01 -0400 (EDT) Received: from mira-sjc5-1.cisco.com (mira-sjc5-1.cisco.com [171.71.163.15]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f55MwQ505728 for ; Tue, 5 Jun 2001 15:58:26 -0700 (PDT) Received: from BFOSTER-W2K.cisco.com (sjc-vpn-tmp234.cisco.com [10.21.64.234]) by mira-sjc5-1.cisco.com (Mirapoint) with ESMTP id AAT36911; Tue, 5 Jun 2001 15:59:05 -0700 (PDT) Message-Id: <4.3.2.7.2.20010605153320.04e29380@mira-sjc5-1.cisco.com> X-Sender: bfoster@mira-sjc5-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 05 Jun 2001 15:54:10 -0700 To: megaco From: Bill Foster Subject: References for various tones Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk I assume the intent is to provide specific references for tones where possible. For example - draft-boyle-megaco-tonepkgs-04.txt has references in sections 4-6 references get sparse to non-existent in sections 7 to 12. ----------------------------- Bill Foster Phone: (250) 758-9418 Fax: (781) 998-6492 From owner-megaco@fore.com Tue Jun 5 21:20:31 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA02483 for ; Tue, 5 Jun 2001 21:20:31 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id VAA09815; Tue, 5 Jun 2001 21:20:22 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id VAA20440 for megaco-list; Tue, 5 Jun 2001 21:19:16 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id VAA20436 for ; Tue, 5 Jun 2001 21:19:15 -0400 (EDT) From: 02823296@yahoo.com Received: from server-ex.modembad.no (pat.modembad.no [193.212.161.34]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id VAA09697 for ; Tue, 5 Jun 2001 21:19:12 -0400 (EDT) Received: from 193.212.161.34 (192.168.1.1 [192.168.1.1]) by server-ex.modembad.no with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id MKCZYFNG; Wed, 6 Jun 2001 02:58:23 +0200 Received: from international0011@yahoo.com by (8.8.5/8.6.5) with SMTP id GAA06189 for <>; Tue, 05 Jun 2001 20:41:06 -0600 (EST) Date: Tue, 05 Jun 01 20:41:06 EST To: Friend@public.com Subject: Receive $1000 Commission on a $0 down SALE !! E Message-ID: Reply-To: international0011@yahoo.com Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk -------------------------------------------------------------------- NOTE: This one-time message is in response to your online ad. You are NOT on a mailing list and you will NOT receive any more messages. Please send more details about your ad/offer. -------------------------------------------------------------------- Receive $1,000 Commission on a $0 down SALE !! DID YOU MAKE $5,000 LAST MONTH? IF NOT, YOU NEED TO JOIN US TODAY! · Imagine being able to market the hottest consumer savings package in America today! · Imagine earning up to $1,000 each and every time someone joins for INCREDIBLE $0 DOWN! · Imagine being plugged into a proven system that puts your entire business on auto-pilot and have you earning $3,000 every week! IT'S TRUE! You can be in business for $0 DOWN! And you can easily make $3,000 your very first week... and we'll show you how! Your business will literally explode overnight when you join our team and plug into our exclusive marketing system! For more INFO reply to mail2001bb@yahoo.com with in the subject line or JUST CLICK: mailto:mail2001bb@yahoo.com?subject=Send__Info · $0 DOWN ! · 100% FINANCING - 100% CASH MACHINE · EVERYBODY IS A PROSPECT - 98% APPROVED · EARN $1,000 ON EVERY A THROUGH F CREDIT SALE! · EARN $1,000 ON EACH AND EVERY SALE TO INFINITY! We provide you with all the tools and the absolute BEST marketing system available on the web, all resources you will ever need. The only thing you need to do is join our team and plug into our proven system for overnight success today! ~~~~~~~~~~~ For more INFO reply to mail2001bb@yahoo.com with in the subject line or JUST CLICK: mailto:mail2001bb@yahoo.com?subject=Send__Info Testimonies: This program is so easy, 'with your system I have made 13 sales first week'. That's $13000' this is the best program I've done and I've done them all! Richard S. Memphis, TN I did it all with my computer! People sign up like crazy! First I said, ok, I am financially totally down, I need to give this one a try. But after two weeks I am already out of dept! Oh god, I did not expect that! And I am not a sales person and I did it! I am so excited, thank you Richard and Mary! Randy S. Los Angeles, CA I am SPEECHLESS! With your FREE leads, and FREE unsecured Visa MC, I was able to advertise free & pay for faxes that got my phone ringing off the hook! I think I'll have 20 sales this month!!! I haven't even begun to download all the free software to make even more MONEY' Thanks guys! Randy S. Detroit MI I was in my chiropractor's office when the secretary was about to throw out a fax that they had just received. The fax was similar to this email and caught my eye. I did exactly what it told me to do (a fax blast) and in my second day I made $6,000. No hard selling, no hustling my friends, just friendly people looking at a great opportunity and wanting in. Even if it took me a month to make an extra $5,000 I would have been happy, but $6,000 in my second day, wow! I'm excited. Dave W. Newport Beach, CA If you have been looking for something that is not MLM, is turnkey and very easy to do, then join us now, This is the MOST EXPLOSIVE income opportunity we have ever seen. Sign up 3 people & earn $3,000! Sign up 10 people & earn $10,000...how much do you want? This is the easiest sale you will EVER make! GET STARTED WITH INCREDIBLE $0 DOWN + START EARNING $1,000 COMMISSIONS, YOUR FIRST MONTH! All sales wired into your checking account on a daily basis! IMPORTANT: To remove please click: mailto:mail2001bb@yahoo.com?subject=remove ======================================================== This message is in full compliance with U.S. Federal requirements for commercial email under bill S.1618 Title lll, Section 301, Paragraph (a)(2)(C) passed by the 105th U.S. Congress and cannot be considered SPAM since it includes a remove mechanism. From owner-megaco@fore.com Wed Jun 6 02:35:30 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA20420 for ; Wed, 6 Jun 2001 02:35:29 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id BAA17040; Wed, 6 Jun 2001 01:39:33 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id BAA08310 for megaco-list; Wed, 6 Jun 2001 01:37:30 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id BAA08303 for ; Wed, 6 Jun 2001 01:37:28 -0400 (EDT) Received: from newish7.ericsson.com.au ([203.61.155.116]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id BAA16729 for ; Wed, 6 Jun 2001 01:37:24 -0400 (EDT) Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10]) by newish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id PAA25200 for ; Wed, 6 Jun 2001 15:36:03 +1000 (EST) Received: from ericsson.com (mcdh126.epa.ericsson.se [146.11.81.126]) by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id PAA08276 for ; Wed, 6 Jun 2001 15:36:49 +1000 (EST) Message-ID: <3B1D8485.361CF66D@ericsson.com> Date: Wed, 06 Jun 2001 11:16:53 +1000 From: Christian Groves X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: megaco ietf Subject: Megaco Virus Warning Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: 7bit G'Day all, Please be aware that there seems to be an automatic virus generator working with the Megaco. It takes a legimate thread title and the first 20 lines of an email and then attaches an attachment called "hamster". Cheers, Christian From owner-megaco@fore.com Wed Jun 6 10:17:40 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA01643 for ; Wed, 6 Jun 2001 10:17:40 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA11777; Wed, 6 Jun 2001 10:17:31 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA10179 for megaco-list; Wed, 6 Jun 2001 10:13:59 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA10168 for ; Wed, 6 Jun 2001 10:13:58 -0400 (EDT) Received: from gatekeeper.cam.virata.com (gatekeeper.virata.com [194.129.40.2]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA11334 for ; Wed, 6 Jun 2001 10:13:53 -0400 (EDT) Received: from boletus.cam.virata.com (boletus.cam.virata.com [10.7.5.11]) by gatekeeper.cam.virata.com (8.9.3/8.8.5) with ESMTP id PAA17489 for ; Wed, 6 Jun 2001 15:13:56 +0100 Received: from fileserv.ta.virata.com (fileserv.ta.virata.com [10.65.0.254]) by boletus.cam.virata.com (8.9.3/8.9.3/Debian/GNU) with ESMTP id PAA07322 for ; Wed, 6 Jun 2001 15:13:53 +0100 Received: by fileserv.ta.virata.com with Internet Mail Service (5.5.2650.21) id ; Wed, 6 Jun 2001 16:13:46 +0200 Message-ID: From: "Ternovsky, Igor" To: "'megaco@fore.com'" Cc: "Kravetz, Yuri" Subject: Error handling Date: Wed, 6 Jun 2001 16:13:36 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="windows-1252" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Hello list, Please advice what is correct behavior when GW detects an error in transaction. In our implementation (as I suspect in many others) there is a message parsing phase followed by an execution phase. Message parser decodes message transaction by transaction. Assume that transaction consists of a number of actions that in turn consist of number of commands. While parsing the transaction, parser found some error in command number n. Is it legal in this case to reject the whole transaction without executing the first commands (my preference)? Or GW MUST execute the first commands and report error for the n's. Thanks, Igor Ternovsky Virata From owner-megaco@fore.com Wed Jun 6 10:33:01 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA02032 for ; Wed, 6 Jun 2001 10:33:01 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA13574; Wed, 6 Jun 2001 10:32:52 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA15514 for megaco-list; Wed, 6 Jun 2001 10:30:43 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA15503 for ; Wed, 6 Jun 2001 10:30:41 -0400 (EDT) Received: from zcars0m9.ca.nortel.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA13284 for ; Wed, 6 Jun 2001 10:30:37 -0400 (EDT) Received: from zcars04e.nortelnetworks.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f56EUVE02007 for ; Wed, 6 Jun 2001 10:30:31 -0400 (EDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.nortelnetworks.com; Wed, 6 Jun 2001 10:30:05 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 6 Jun 2001 10:29:34 -0400 Message-ID: <28560036253BD41191A10000F8BCBD110250CC52@zcard00g.ca.nortel.com> From: "Tom-PT Taylor" To: "'Ternovsky, Igor'" , "'megaco@fore.com'" Cc: "Kravetz, Yuri" Subject: RE: Error handling Date: Wed, 6 Jun 2001 10:29:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0EE95.17594CC0" X-Orig: Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0EE95.17594CC0 Content-Type: text/plain; charset="windows-1252" Sorry, the specification is quite definite: you have to execute up to the point of failure. > -----Original Message----- > From: Ternovsky, Igor [mailto:ITernovsky@virata.com] > Sent: Wednesday, June 06, 2001 10:14 AM > To: 'megaco@fore.com' > Cc: Kravetz, Yuri > Subject: Error handling > > > > Hello list, > > Please advice what is correct behavior when GW detects an error in > transaction. > In our implementation (as I suspect in many others) there is a message > parsing phase followed by an execution phase. Message parser > decodes message > transaction by transaction. > Assume that transaction consists of a number of actions that > in turn consist > of number of commands. > While parsing the transaction, parser found some error in > command number n. > Is it legal in this case to reject the whole transaction > without executing > the first commands (my preference)? Or GW MUST execute > the first > commands and report error for the n's. > > Thanks, > > Igor Ternovsky > Virata > ------_=_NextPart_001_01C0EE95.17594CC0 Content-Type: text/html; charset="windows-1252" RE: Error handling

Sorry, the specification is quite definite: you have to execute up to the point of failure.

> -----Original Message-----
> From: Ternovsky, Igor [mailto:ITernovsky@virata.com]
> Sent: Wednesday, June 06, 2001 10:14 AM
> To: 'megaco@fore.com'
> Cc: Kravetz, Yuri
> Subject: Error handling
>
>
>
> Hello list,
>
> Please advice what is correct behavior when GW detects an error in
> transaction.
> In our implementation (as I suspect in many others) there is a message
> parsing phase followed by an execution phase. Message parser
> decodes message
> transaction by transaction.
> Assume that transaction consists of a number of actions that
> in turn consist
> of number of commands.
> While parsing the transaction, parser found some error in
> command number n.
> Is it legal in this case to reject the whole transaction
> without executing
> the first <n-1> commands (my preference)? Or GW MUST execute
> the first <n-1>
> commands and report error for the n's.
>
> Thanks,
>
> Igor Ternovsky
> Virata
>

------_=_NextPart_001_01C0EE95.17594CC0-- From owner-megaco@fore.com Wed Jun 6 10:50:43 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA02444 for ; Wed, 6 Jun 2001 10:50:43 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA15217; Wed, 6 Jun 2001 10:50:29 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA20141 for megaco-list; Wed, 6 Jun 2001 10:47:54 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA20136 for ; Wed, 6 Jun 2001 10:47:52 -0400 (EDT) Received: from mail-lod.audiocodes.com ([212.143.19.162]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA14854 for ; Wed, 6 Jun 2001 10:47:48 -0400 (EDT) Received: by MAIL-LOD with Internet Mail Service (5.5.2653.19) id ; Wed, 6 Jun 2001 17:47:52 +0200 Message-ID: <3F2E96E0B800D511821E00306E062AE404BDA7@MAIL-LOD> From: Nurit Shenhar To: "'Megaco (E-mail)" Subject: RE: ABNF Question: digit maps embedded in events Date: Wed, 6 Jun 2001 17:47:51 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Sorry to step in so late, I only now examined this thread. We had a discussion once about digit maps, and the conclusion was that the first option in the digitMapDescriptor (only value) is meaningless, and was left there by mistake. There is no point to program a termination with an unnamed digit map, as we won't be able to activate it in the eventDM... So I think the correct syntax should be: eventDM = DigitMapToken EQUAL (( digitMapName ) / (LBRKT digitMapValue RBRKT)) digitMapDescriptor = DigitMapToken EQUAL digitMapName [LBRKT digitMapValue RBRKT] Nurit -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] Sent: Friday, June 01, 2001 7:51 PM To: 'Troy Cauble'; Megaco Mailing List (E-mail) Subject: RE: ABNF Question: digit maps embedded in events Because it was intended to be symmetric in the beginning, what is written is incorrect. We have caught and fixed several of these. When a proposal actually changes what the original intention/documentation/text vs ABNF(ASN.1) is, then we defer it. Brian > -----Original Message----- > From: Troy Cauble [mailto:troy@lucent.com] > Sent: Friday, June 01, 2001 11:22 AM > To: Megaco Mailing List (E-mail) > Subject: Re: ABNF Question: digit maps embedded in events > > > > Just curious, but why doesn't this get squashed for > being an unnecessary change? Nothing's broken except > the symmetry. > > More useful changes have been delayed to v2. > > Please treat this as a question, not a complaint! > Christian, Tom, Brian, et. al. are doing a great job. > > -troy > > > Christian Groves wrote: > > > > Just in time. I'll add it to the implementors' guide. > > > > Christian > > > > Tom-PT Taylor wrote: > > > > > > Yes, and I suspect I'm the guilty typist. > > > > > > > -----Original Message----- > > > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > > Sent: Wednesday, May 30, 2001 3:44 PM > > > > To: 'Steven Weisz'; Megaco Mailing List (E-mail) > > > > Cc: Taylor, Tom-PT [NORSE:B881:EXCH] > > > > Subject: RE: ABNF Question: digit maps embedded in events > > > > > > > > > > > > I usually defer to Tom on any digitMap questions. > > > > I can't tell you how many hours I (and several others > > > > including Abdullah Rayhan) spent pouring over the > > > > ABNF to ferret out such problems. > > > > > > > > Yes, I agree, it should be > > > > digitMap={... > > > > and not > > > > digitMap{... > > > > > > > > I think this qualifies as a typo and deserves an IG entry. > > > > Tom, do you agree? > > > > > > > > Brian > > > > > > > > > -----Original Message----- > > > > > From: Steven Weisz [mailto:sweisz@mediatrix.com] > > > > > Sent: Wednesday, May 30, 2001 3:08 PM > > > > > To: Megaco Mailing List (E-mail) > > > > > Subject: ABNF Question: digit maps embedded in events > > > > > > > > > > > > > > > Hi List, > > > > > > > > > > I asked this question a few weeks ago and still have not > > > > > found an answer. > > > > > Does anyone have an opinion? > > > > > > > > > > It is a quick question concerning a digit map embedded in a > > > > > requested event. > > > > > Specifically, if you look at the ABNF the embedded digit map > > > > > is defined as > > > > > > > > > > eventDM = DigitMapToken (( EQUAL digitMapName ) / (LBRKT > > > > digitMapValue > > > > > RBRKT)) > > > > > > > > > > and a digit map descriptor is defined as: > > > > > > > > > > digitMapDescriptor = DigitMapToken EQUAL (( LBRKT > > > > > digitMapValue RBRKT ) / > > > > > ( digitMapName [LBRKT > digitMapValue RBRKT] )) > > > > > > > > > > > > > It obvious that they are very similar, as I believe was > > > > > intended but there > > > > > is one thing that is bothering me in eventDM. That is it > > > > > seems to me that > > > > > the EQUAL should be right after DigitMapToken as is > the case in > > > > > digitMapDescriptor. So we would instead have: > > > > > > > > > > eventDM = DigitMapToken EQUAL (( digitMapName ) / (LBRKT > > > > digitMapValue > > > > > RBRKT)) > > > > > > > > > > Does this make sense? > > > > > > > > > > Thanks, > > > > > > > > > > Steve > > > > > > > > > > From owner-megaco@fore.com Wed Jun 6 11:21:15 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA02870 for ; Wed, 6 Jun 2001 11:21:15 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA18513; Wed, 6 Jun 2001 11:21:07 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id LAA28554 for megaco-list; Wed, 6 Jun 2001 11:18:10 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA28550 for ; Wed, 6 Jun 2001 11:18:09 -0400 (EDT) Received: from muninn.ctccom.net (Muninn.CTCCom.net [207.190.194.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA18137 for ; Wed, 6 Jun 2001 11:18:04 -0400 (EDT) Received: from MBRAHMANAPALLY ([64.69.123.121]) by muninn.ctccom.net (Mirapoint) with SMTP id ACW12351; Wed, 6 Jun 2001 11:17:51 -0400 (EDT) From: "Madhu Babu Brahmanapally" To: "'Nurit Shenhar'" , "''Megaco \(E-mail\)'" Subject: RE: ABNF Question: digit maps embedded in events Date: Wed, 6 Jun 2001 11:19:45 -0400 Message-ID: <003c01c0ee9c$1e958c40$c500a8c0@MBRAHMANAPALLY> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <3F2E96E0B800D511821E00306E062AE404BDA7@MAIL-LOD> Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: 7bit HI Nurit/all, Why the digit map value is meaningless?? -Regards Madhubabu -----Original Message----- From: owner-megaco@pit.comms.marconi.com [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Nurit Shenhar Sent: Wednesday, June 06, 2001 11:48 AM To: 'Megaco (E-mail) Subject: RE: ABNF Question: digit maps embedded in events Sorry to step in so late, I only now examined this thread. We had a discussion once about digit maps, and the conclusion was that the first option in the digitMapDescriptor (only value) is meaningless, and was left there by mistake. There is no point to program a termination with an unnamed digit map, as we won't be able to activate it in the eventDM... So I think the correct syntax should be: eventDM = DigitMapToken EQUAL (( digitMapName ) / (LBRKT digitMapValue RBRKT)) digitMapDescriptor = DigitMapToken EQUAL digitMapName [LBRKT digitMapValue RBRKT] Nurit -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] Sent: Friday, June 01, 2001 7:51 PM To: 'Troy Cauble'; Megaco Mailing List (E-mail) Subject: RE: ABNF Question: digit maps embedded in events Because it was intended to be symmetric in the beginning, what is written is incorrect. We have caught and fixed several of these. When a proposal actually changes what the original intention/documentation/text vs ABNF(ASN.1) is, then we defer it. Brian > -----Original Message----- > From: Troy Cauble [mailto:troy@lucent.com] > Sent: Friday, June 01, 2001 11:22 AM > To: Megaco Mailing List (E-mail) > Subject: Re: ABNF Question: digit maps embedded in events > > > > Just curious, but why doesn't this get squashed for > being an unnecessary change? Nothing's broken except > the symmetry. > > More useful changes have been delayed to v2. > > Please treat this as a question, not a complaint! > Christian, Tom, Brian, et. al. are doing a great job. > > -troy > > > Christian Groves wrote: > > > > Just in time. I'll add it to the implementors' guide. > > > > Christian > > > > Tom-PT Taylor wrote: > > > > > > Yes, and I suspect I'm the guilty typist. > > > > > > > -----Original Message----- > > > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > > Sent: Wednesday, May 30, 2001 3:44 PM > > > > To: 'Steven Weisz'; Megaco Mailing List (E-mail) > > > > Cc: Taylor, Tom-PT [NORSE:B881:EXCH] > > > > Subject: RE: ABNF Question: digit maps embedded in events > > > > > > > > > > > > I usually defer to Tom on any digitMap questions. > > > > I can't tell you how many hours I (and several others > > > > including Abdullah Rayhan) spent pouring over the > > > > ABNF to ferret out such problems. > > > > > > > > Yes, I agree, it should be > > > > digitMap={... > > > > and not > > > > digitMap{... > > > > > > > > I think this qualifies as a typo and deserves an IG entry. > > > > Tom, do you agree? > > > > > > > > Brian > > > > > > > > > -----Original Message----- > > > > > From: Steven Weisz [mailto:sweisz@mediatrix.com] > > > > > Sent: Wednesday, May 30, 2001 3:08 PM > > > > > To: Megaco Mailing List (E-mail) > > > > > Subject: ABNF Question: digit maps embedded in events > > > > > > > > > > > > > > > Hi List, > > > > > > > > > > I asked this question a few weeks ago and still have not > > > > > found an answer. > > > > > Does anyone have an opinion? > > > > > > > > > > It is a quick question concerning a digit map embedded in a > > > > > requested event. > > > > > Specifically, if you look at the ABNF the embedded digit map > > > > > is defined as > > > > > > > > > > eventDM = DigitMapToken (( EQUAL digitMapName ) / (LBRKT > > > > digitMapValue > > > > > RBRKT)) > > > > > > > > > > and a digit map descriptor is defined as: > > > > > > > > > > digitMapDescriptor = DigitMapToken EQUAL (( LBRKT > > > > > digitMapValue RBRKT ) / > > > > > ( digitMapName [LBRKT > digitMapValue RBRKT] )) > > > > > > > > > > > > > It obvious that they are very similar, as I believe was > > > > > intended but there > > > > > is one thing that is bothering me in eventDM. That is it > > > > > seems to me that > > > > > the EQUAL should be right after DigitMapToken as is > the case in > > > > > digitMapDescriptor. So we would instead have: > > > > > > > > > > eventDM = DigitMapToken EQUAL (( digitMapName ) / (LBRKT > > > > digitMapValue > > > > > RBRKT)) > > > > > > > > > > Does this make sense? > > > > > > > > > > Thanks, > > > > > > > > > > Steve > > > > > > > > > > From owner-megaco@fore.com Wed Jun 6 12:10:01 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA04246 for ; Wed, 6 Jun 2001 12:10:01 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA22708; Wed, 6 Jun 2001 12:09:55 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id MAA10821 for megaco-list; Wed, 6 Jun 2001 12:07:32 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA10817 for ; Wed, 6 Jun 2001 12:07:31 -0400 (EDT) Received: from texlog2.texas.rr.com (texlog2.texas.rr.com [24.93.35.223]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA22491 for ; Wed, 6 Jun 2001 12:07:28 -0400 (EDT) Received: from plong (cs666831-163.austin.rr.com [66.68.31.163]) by texlog2.texas.rr.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f56G7OdQ021934 for ; Wed, 6 Jun 2001 11:07:24 -0500 (CDT) From: "Paul Long" To: Subject: Megaco modifies SDP Date: Wed, 6 Jun 2001 11:07:29 -0500 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: 7bit Why were the s=, t=, and o= SDP lines made optional even though the SDP spec itself specifies that they are mandatory? This change means that one cannot use a strictly (RFC2327-) compliant SDP codec with Megaco. What would it have hurt for Megaco to use SDP unchanged? Why go to the trouble of effectively amending SDP? Paul Long ipDialog, Inc. From owner-megaco@fore.com Wed Jun 6 12:20:09 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA04434 for ; Wed, 6 Jun 2001 12:20:09 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA23547; Wed, 6 Jun 2001 12:20:03 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id MAA12407 for megaco-list; Wed, 6 Jun 2001 12:17:00 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA12400 for ; Wed, 6 Jun 2001 12:16:59 -0400 (EDT) Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA23258 for ; Wed, 6 Jun 2001 12:16:56 -0400 (EDT) Received: from hoemail1.firewall.lucent.com (localhost [127.0.0.1]) by hoemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f56GGuB05147 for ; Wed, 6 Jun 2001 12:16:56 -0400 (EDT) Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3]) by hoemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f56GGtS05126 for ; Wed, 6 Jun 2001 12:16:56 -0400 (EDT) Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id MAA14741; Wed, 6 Jun 2001 12:16:54 -0400 (EDT) Cc: megaco@fore.com Received: from lucent.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id MAA14728; Wed, 6 Jun 2001 12:16:53 -0400 (EDT) Message-ID: <3B1E56FC.43386DFF@lucent.com> Date: Wed, 06 Jun 2001 12:14:52 -0400 From: Troy Cauble Reply-To: Troy Cauble X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Paul Long Original-CC: megaco@fore.com Subject: Re: Megaco modifies SDP References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: 7bit Paul Long wrote: > > Why were the s=, t=, and o= SDP lines made optional even though the SDP spec > itself specifies that they are mandatory? This change means that one cannot > use a strictly (RFC2327-) compliant SDP codec with Megaco. What would it > have hurt for Megaco to use SDP unchanged? Why go to the trouble of > effectively amending SDP? > > Paul Long > ipDialog, Inc. Note that the "*" and "$" notations are changes too. Not that thats an argument for the changes you pointed out. -troy From owner-megaco@fore.com Wed Jun 6 12:25:32 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA04556 for ; Wed, 6 Jun 2001 12:25:32 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA24105; Wed, 6 Jun 2001 12:25:26 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id MAA13504 for megaco-list; Wed, 6 Jun 2001 12:22:57 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA13497 for ; Wed, 6 Jun 2001 12:22:56 -0400 (EDT) Received: from texlog2.texas.rr.com (texlog2.texas.rr.com [24.93.35.223]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA23798 for ; Wed, 6 Jun 2001 12:22:54 -0400 (EDT) Received: from plong (cs666831-163.austin.rr.com [66.68.31.163]) by texlog2.texas.rr.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f56GMndQ001333 for ; Wed, 6 Jun 2001 11:22:50 -0500 (CDT) From: "Paul Long" To: Subject: RE: Megaco modifies SDP Date: Wed, 6 Jun 2001 11:22:54 -0500 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <3B1E56FC.43386DFF@lucent.com> Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: 7bit Troy, But, as I understand it, those do not change SDP syntax because they merely specify the meaning of specific, reserved values. They therefore leave SDP syntax alone and _extend_ SDP semantics somewhat. The s=/t=/o= changes actually change the syntax. Paul Long ipDialog, Inc. -----Original Message----- From: troy@lucent.com [mailto:troy@lucent.com] Sent: Wednesday, June 06, 2001 11:15 AM To: Paul Long Cc: megaco@fore.com Subject: Re: Megaco modifies SDP Paul Long wrote: > > Why were the s=, t=, and o= SDP lines made optional even though the SDP spec > itself specifies that they are mandatory? This change means that one cannot > use a strictly (RFC2327-) compliant SDP codec with Megaco. What would it > have hurt for Megaco to use SDP unchanged? Why go to the trouble of > effectively amending SDP? > > Paul Long > ipDialog, Inc. Note that the "*" and "$" notations are changes too. Not that thats an argument for the changes you pointed out. -troy From owner-megaco@fore.com Wed Jun 6 14:12:41 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07267 for ; Wed, 6 Jun 2001 14:12:40 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA02613; Wed, 6 Jun 2001 14:12:32 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id OAA07881 for megaco-list; Wed, 6 Jun 2001 14:10:55 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA07872 for ; Wed, 6 Jun 2001 14:10:54 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 6 Jun 2001 14:10:54 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF044654F8@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Nurit Shenhar'" , "'Megaco (E-mail)" Subject: RE: ABNF Question: digit maps embedded in events Date: Wed, 6 Jun 2001 14:10:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk The issue is you should never see a construction like keyword={..} It's always keyword=value{..} or keyword{..} so, you don't want the EQUAL token in EventDM if all you get is a value. Your production should be: eventDM = DigitMapToken ((EQUAL digitMapName ) / (LBRKT digitMapValue RBRKT)) Brian > -----Original Message----- > From: Nurit Shenhar [mailto:nurit.shenhar@audiocodes.com] > Sent: Wednesday, June 06, 2001 11:48 AM > To: 'Megaco (E-mail) > Subject: RE: ABNF Question: digit maps embedded in events > > > Sorry to step in so late, I only now examined this thread. > > We had a discussion once about digit maps, and the conclusion > was that the > first option in the digitMapDescriptor (only value) is > meaningless, and was > left there by mistake. There is no point to program a > termination with an > unnamed digit map, as we won't be able to activate it in the > eventDM... So I > think the correct syntax should be: > > eventDM = DigitMapToken EQUAL (( digitMapName ) / (LBRKT digitMapValue > RBRKT)) > > digitMapDescriptor = DigitMapToken EQUAL digitMapName [LBRKT > digitMapValue > RBRKT] > > Nurit > > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: Friday, June 01, 2001 7:51 PM > To: 'Troy Cauble'; Megaco Mailing List (E-mail) > Subject: RE: ABNF Question: digit maps embedded in events > > > Because it was intended to be symmetric in the beginning, > what is written is incorrect. We have caught and fixed > several of these. When a proposal actually changes what > the original intention/documentation/text vs ABNF(ASN.1) is, > then we defer it. > > Brian > > > -----Original Message----- > > From: Troy Cauble [mailto:troy@lucent.com] > > Sent: Friday, June 01, 2001 11:22 AM > > To: Megaco Mailing List (E-mail) > > Subject: Re: ABNF Question: digit maps embedded in events > > > > > > > > Just curious, but why doesn't this get squashed for > > being an unnecessary change? Nothing's broken except > > the symmetry. > > > > More useful changes have been delayed to v2. > > > > Please treat this as a question, not a complaint! > > Christian, Tom, Brian, et. al. are doing a great job. > > > > -troy > > > > > > Christian Groves wrote: > > > > > > Just in time. I'll add it to the implementors' guide. > > > > > > Christian > > > > > > Tom-PT Taylor wrote: > > > > > > > > Yes, and I suspect I'm the guilty typist. > > > > > > > > > -----Original Message----- > > > > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > > > Sent: Wednesday, May 30, 2001 3:44 PM > > > > > To: 'Steven Weisz'; Megaco Mailing List (E-mail) > > > > > Cc: Taylor, Tom-PT [NORSE:B881:EXCH] > > > > > Subject: RE: ABNF Question: digit maps embedded in events > > > > > > > > > > > > > > > I usually defer to Tom on any digitMap questions. > > > > > I can't tell you how many hours I (and several others > > > > > including Abdullah Rayhan) spent pouring over the > > > > > ABNF to ferret out such problems. > > > > > > > > > > Yes, I agree, it should be > > > > > digitMap={... > > > > > and not > > > > > digitMap{... > > > > > > > > > > I think this qualifies as a typo and deserves an IG entry. > > > > > Tom, do you agree? > > > > > > > > > > Brian > > > > > > > > > > > -----Original Message----- > > > > > > From: Steven Weisz [mailto:sweisz@mediatrix.com] > > > > > > Sent: Wednesday, May 30, 2001 3:08 PM > > > > > > To: Megaco Mailing List (E-mail) > > > > > > Subject: ABNF Question: digit maps embedded in events > > > > > > > > > > > > > > > > > > Hi List, > > > > > > > > > > > > I asked this question a few weeks ago and still have not > > > > > > found an answer. > > > > > > Does anyone have an opinion? > > > > > > > > > > > > It is a quick question concerning a digit map embedded in a > > > > > > requested event. > > > > > > Specifically, if you look at the ABNF the embedded digit map > > > > > > is defined as > > > > > > > > > > > > eventDM = DigitMapToken (( EQUAL digitMapName ) / (LBRKT > > > > > digitMapValue > > > > > > RBRKT)) > > > > > > > > > > > > and a digit map descriptor is defined as: > > > > > > > > > > > > digitMapDescriptor = DigitMapToken EQUAL (( LBRKT > > > > > > digitMapValue RBRKT ) / > > > > > > ( digitMapName [LBRKT > > digitMapValue RBRKT] )) > > > > > > > > > > > > > > > > It obvious that they are very similar, as I believe was > > > > > > intended but there > > > > > > is one thing that is bothering me in eventDM. That is it > > > > > > seems to me that > > > > > > the EQUAL should be right after DigitMapToken as is > > the case in > > > > > > digitMapDescriptor. So we would instead have: > > > > > > > > > > > > eventDM = DigitMapToken EQUAL (( digitMapName ) / (LBRKT > > > > > digitMapValue > > > > > > RBRKT)) > > > > > > > > > > > > Does this make sense? > > > > > > > > > > > > Thanks, > > > > > > > > > > > > Steve > > > > > > > > > > > > > > From owner-megaco@fore.com Wed Jun 6 14:14:26 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07336 for ; Wed, 6 Jun 2001 14:14:26 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA02938; Wed, 6 Jun 2001 14:14:18 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id OAA08189 for megaco-list; Wed, 6 Jun 2001 14:13:15 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA08179 for ; Wed, 6 Jun 2001 14:13:13 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 6 Jun 2001 14:13:13 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF044654F9@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Paul Long'" , megaco@fore.com Subject: RE: Megaco modifies SDP Date: Wed, 6 Jun 2001 14:13:12 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk The requirement is that an implementation always accept a legal SDP. Be strict in what you send, tolerant it what you receive is appropriate here: If you want to send the s=,.... go ahead YOU MUST accept s=, t= and o= They have no meaning in Megaco, so if you want to leave them out, you can. Brian > -----Original Message----- > From: Paul Long [mailto:plong@ipdialog.com] > Sent: Wednesday, June 06, 2001 12:07 PM > To: megaco@fore.com > Subject: Megaco modifies SDP > > > Why were the s=, t=, and o= SDP lines made optional even > though the SDP spec > itself specifies that they are mandatory? This change means > that one cannot > use a strictly (RFC2327-) compliant SDP codec with Megaco. > What would it > have hurt for Megaco to use SDP unchanged? Why go to the trouble of > effectively amending SDP? > > Paul Long > ipDialog, Inc. > From owner-megaco@fore.com Wed Jun 6 14:50:32 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07759 for ; Wed, 6 Jun 2001 14:50:31 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA06176; Wed, 6 Jun 2001 14:50:17 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id OAA17874 for megaco-list; Wed, 6 Jun 2001 14:49:20 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA17870 for ; Wed, 6 Jun 2001 14:49:18 -0400 (EDT) Received: from sm10.texas.rr.com (sm10.texas.rr.com [24.93.35.222]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA05990 for ; Wed, 6 Jun 2001 14:49:15 -0400 (EDT) Received: from plong (cs666831-163.austin.rr.com [66.68.31.163]) by sm10.texas.rr.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f56Imxu3021006 for ; Wed, 6 Jun 2001 13:49:00 -0500 From: "Paul Long" To: Subject: RE: Megaco modifies SDP Date: Wed, 6 Jun 2001 13:49:15 -0500 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <4FBEA8857476D311A03300204840E1CF044654F9@whq-msgusr-02.pit.comms.marconi.com> Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: 7bit Brian, Okay, but "legal SDP" means that the v, o, s, t, and m lines are always present (see section 6 of RFC2327). It's contradictory to say that the s, t, and o lines are optional _and_ that legal SDP must be accepted, because these lines are required by legal SDP. Whatever... Paul Long ipDialog, Inc. -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] Sent: Wednesday, June 06, 2001 1:13 PM To: 'Paul Long'; megaco@fore.com Subject: RE: Megaco modifies SDP The requirement is that an implementation always accept a legal SDP. Be strict in what you send, tolerant it what you receive is appropriate here: If you want to send the s=,.... go ahead YOU MUST accept s=, t= and o= They have no meaning in Megaco, so if you want to leave them out, you can. Brian > -----Original Message----- > From: Paul Long [mailto:plong@ipdialog.com] > Sent: Wednesday, June 06, 2001 12:07 PM > To: megaco@fore.com > Subject: Megaco modifies SDP > > > Why were the s=, t=, and o= SDP lines made optional even > though the SDP spec > itself specifies that they are mandatory? This change means > that one cannot > use a strictly (RFC2327-) compliant SDP codec with Megaco. > What would it > have hurt for Megaco to use SDP unchanged? Why go to the trouble of > effectively amending SDP? > > Paul From owner-megaco@fore.com Wed Jun 6 15:05:17 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA07943 for ; Wed, 6 Jun 2001 15:05:16 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA07597; Wed, 6 Jun 2001 15:05:08 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id PAA21626 for megaco-list; Wed, 6 Jun 2001 15:04:33 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA21622 for ; Wed, 6 Jun 2001 15:04:31 -0400 (EDT) Received: from muninn.ctccom.net (Muninn.CTCCom.net [207.190.194.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA07494 for ; Wed, 6 Jun 2001 15:04:28 -0400 (EDT) Received: from MBRAHMANAPALLY ([64.69.123.121]) by muninn.ctccom.net (Mirapoint) with SMTP id ACW15036; Wed, 6 Jun 2001 15:04:13 -0400 (EDT) From: "Madhu Babu Brahmanapally" To: "'Paul Long'" , Subject: RE: Megaco modifies SDP Date: Wed, 6 Jun 2001 15:06:06 -0400 Message-ID: <006101c0eebb$bd8fb220$c500a8c0@MBRAHMANAPALLY> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: 7bit Hi All, Whatever be the wording, the SDP is modified for Megaco Usage. As pointed out by Troy allowing "$" and "*" itself changes the syntax interpretation against the one defined in the RFC 2327. Along with the wildcards, the statement made regarding v,o,s,t lines in the protocol is enough to say that except for these all other SDP syntax is preserved. Except for whatever has been specifically mentioned other fields are truly interpreted as defined in the RFC 2327. Regards Madhubabu -----Original Message----- From: owner-megaco@pit.comms.marconi.com [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Paul Long Sent: Wednesday, June 06, 2001 2:49 PM To: megaco@fore.com Subject: RE: Megaco modifies SDP Brian, Okay, but "legal SDP" means that the v, o, s, t, and m lines are always present (see section 6 of RFC2327). It's contradictory to say that the s, t, and o lines are optional _and_ that legal SDP must be accepted, because these lines are required by legal SDP. Whatever... Paul Long ipDialog, Inc. -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] Sent: Wednesday, June 06, 2001 1:13 PM To: 'Paul Long'; megaco@fore.com Subject: RE: Megaco modifies SDP The requirement is that an implementation always accept a legal SDP. Be strict in what you send, tolerant it what you receive is appropriate here: If you want to send the s=,.... go ahead YOU MUST accept s=, t= and o= They have no meaning in Megaco, so if you want to leave them out, you can. Brian > -----Original Message----- > From: Paul Long [mailto:plong@ipdialog.com] > Sent: Wednesday, June 06, 2001 12:07 PM > To: megaco@fore.com > Subject: Megaco modifies SDP > > > Why were the s=, t=, and o= SDP lines made optional even > though the SDP spec > itself specifies that they are mandatory? This change means > that one cannot > use a strictly (RFC2327-) compliant SDP codec with Megaco. > What would it > have hurt for Megaco to use SDP unchanged? Why go to the trouble of > effectively amending SDP? > > Paul From owner-megaco@fore.com Wed Jun 6 15:40:01 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA08309 for ; Wed, 6 Jun 2001 15:40:00 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA10648; Wed, 6 Jun 2001 15:39:52 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id PAA01479 for megaco-list; Wed, 6 Jun 2001 15:38:08 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA01457 for ; Wed, 6 Jun 2001 15:37:25 -0400 (EDT) Received: from texlog2.texas.rr.com (texlog2.texas.rr.com [24.93.35.223]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA10301 for ; Wed, 6 Jun 2001 15:37:21 -0400 (EDT) Received: from plong (cs666831-163.austin.rr.com [66.68.31.163]) by texlog2.texas.rr.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f56JbHdQ027939 for ; Wed, 6 Jun 2001 14:37:17 -0500 (CDT) From: "Paul Long" To: "Megaco Mailing List \(E-mail\)" Subject: RE: ABNF Question: digit maps embedded in events Date: Wed, 6 Jun 2001 14:37:22 -0500 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <3B1802B5.D0077BE9@ericsson.com> Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: 7bit Christian, That's not going to work. Your use of "an error" is too vague. You can only put something in the IG if it clarifies an issue or fixes an otherwise broken aspect of the standard which prevents interoperability (not that simply brings the syntax into some kind of aesthetic harmony at the risk of breaking interoperability). Otherwise, as is the case with the proposed digit-map modification, you have created a conflict that opens us up to interoperability problems. Let's say I have shipped product, it's out the door, and it's compliant. According to H.248/RFC3015, another entity could send this embedded digit map to my product, and it would not encounter a parse error. DigitMap { x } However, now you are proposing that we change the standard so that the syntax is now this: DigitMap = { x } My product receives this and flags it as a syntax error--you broke it by changing the standard. IMO, interoperability is sacrosanct and trumps aesthetics any day. But nobody has answered my second question. When can a version of the standard no longer be changed? With H.323, both the standard and its IG must be Decided. Is it the same way with H.248? How about RFC3015? Paul Long ipDialog, Inc. -----Original Message----- From: Christian Groves [mailto:Christian.Groves@ericsson.com] Sent: Friday, June 01, 2001 4:02 PM To: Paul Long Cc: Megaco Mailing List (E-mail) Subject: Re: ABNF Question: digit maps embedded in events G'Day Paul and Troy, If the change is new functionality then it goes to v2. If its to fix an error then it goes to the implementors' guide (IG) If its to align between ABNF and ASN1 it goes in the IG If its to fix inconsistencies between procedures and syntax it goes in the IG This is broadly how I interpret things. There aren't really any solid rules except for the first one. With regards to the EQUALS change I believe it was a syntax irregularity. I assume the intention when the syntax was written it was meant to be the way that it was fixed to. Cheers, Christian Paul Long wrote: > > Yeah, what are the criteria for what gets changed in v1 and what gets put > off to v2? Also, when is v1 officially "done" and can no longer be changed? > Like Troy, I'm not complaining--I really want to know. As you can tell from > my earlier response to Steve's query, I thought it was already too late to > change v1. > > Paul Long > ipDialog, Inc. > > -----Original Message----- > From: owner-megaco@pit.comms.marconi.com > [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Troy Cauble > Sent: Friday, June 01, 2001 10:22 AM > To: Megaco Mailing List (E-mail) > Subject: Re: ABNF Question: digit maps embedded in events > > Just curious, but why doesn't this get squashed for > being an unnecessary change? Nothing's broken except > the symmetry. > > More useful changes have been delayed to v2. > > Please treat this as a question, not a complaint! > Christian, Tom, Brian, et. al. are doing a great job. > > -troy From owner-megaco@fore.com Wed Jun 6 16:43:10 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA08900 for ; Wed, 6 Jun 2001 16:43:05 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA15692; Wed, 6 Jun 2001 16:42:58 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id QAA22905 for megaco-list; Wed, 6 Jun 2001 16:41:30 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA22901 for ; Wed, 6 Jun 2001 16:41:29 -0400 (EDT) Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA15533 for ; Wed, 6 Jun 2001 16:41:26 -0400 (EDT) Received: from ihemail1.firewall.lucent.com (localhost [127.0.0.1]) by ihemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f56KfSf22623 for ; Wed, 6 Jun 2001 16:41:28 -0400 (EDT) Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3]) by ihemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f56KfRu22614 for ; Wed, 6 Jun 2001 16:41:27 -0400 (EDT) Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id QAA01264; Wed, 6 Jun 2001 16:41:25 -0400 (EDT) To: Christian Groves , MEGACO list Received: from lucent.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id QAA01243; Wed, 6 Jun 2001 16:40:57 -0400 (EDT) Message-ID: <3B1E94E1.6289D721@lucent.com> Date: Wed, 06 Jun 2001 16:38:57 -0400 From: Troy Cauble Reply-To: Troy Cauble X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 Original-To: Christian Groves , MEGACO list Subject: ASN.1 PkgdName wildcard comments. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: 7bit Greetings, The following Annex A comment refers to "Property Name" which is too specific (PkgdName is used for lots of things.) The phrase should be replaced. PkgdName ::= OCTET STRING(SIZE(4)) -- represents Package Name (2 octets) plus Property Name (2 octets) -- To wildcard a package use 0xFFFF for first two octets, choose -- is not allowed. To reference native property tag specified in -- Annex C, use 0x0000 as first two octets. -- Wildcarding of Package Name is permitted only if Property Name is -- also wildcarded. Also, it states that you can wildcard a "Property Name", but not how. Note that 7.1.9 also states that the EventID portion (referred to here as "Property Name") of an Event name can be wild carded. I suggest the following rewording. -troy PkgdName ::= OCTET STRING(SIZE(4)) -- represents Package Name (2 octets) plus an Property, Event, -- Signal, or Statistics ID. (2 octets) -- To wildcard a package use 0xFFFF for the first two octets, choose -- is not allowed. To reference native property tag specified in -- Annex C, use 0x0000 as first two octets. -- To wildcard a Property, Event, Signal, or Statistics ID, use -- 0xFFFF for last two octets, choose is not allowed. -- Wildcarding of Package Name is permitted only if the Property, -- Event, Signal, or Statistics ID is also wildcarded. From owner-megaco@fore.com Wed Jun 6 17:09:54 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA09171 for ; Wed, 6 Jun 2001 17:09:53 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA17516; Wed, 6 Jun 2001 17:09:46 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id RAA29993 for megaco-list; Wed, 6 Jun 2001 17:08:40 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA29974 for ; Wed, 6 Jun 2001 17:08:38 -0400 (EDT) Received: from sm10.texas.rr.com (sm10.texas.rr.com [24.93.35.222]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA17402 for ; Wed, 6 Jun 2001 17:08:35 -0400 (EDT) Received: from plong (cs666831-163.austin.rr.com [66.68.31.163]) by sm10.texas.rr.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f56L8Ku3018800 for ; Wed, 6 Jun 2001 16:08:20 -0500 From: "Paul Long" To: Subject: Profiles Date: Wed, 6 Jun 2001 16:08:36 -0500 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: 7bit I have some basic questions regarding profiles. 1. Is IPPhone the only residential-GW profile currently available? 2. Would it ever make sense to _not_ be using a profile? If so, under what circumstances would one want to not use a profile? 3. It appears that an MG would typically support just one profile. Is that correct? For example, there isn't any way to present to the MGC a set of profiles that the MG may support and have the MGC pick one, right? I suppose if the registration failed due to the profile, the MG could attempt subsequent registrations with different profiles. Is this how it is envisioned to work? Or would MGs and MGCs typically be deployed by the same organization, and it is their responsibility to deploy MGs and MGCs with compatible profiles? 4. Any other thoughs on the matter?... Paul Long ipDialog, Inc. From owner-megaco@fore.com Wed Jun 6 17:24:26 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA09351 for ; Wed, 6 Jun 2001 17:24:24 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA18678; Wed, 6 Jun 2001 17:24:18 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id RAA02928 for megaco-list; Wed, 6 Jun 2001 17:23:25 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA02920 for ; Wed, 6 Jun 2001 17:23:23 -0400 (EDT) Received: from pine.cyberpathinc.com ([38.246.253.128]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA18537 for ; Wed, 6 Jun 2001 17:23:20 -0400 (EDT) Received: from YSHA (ysha [172.30.30.41]) by pine.cyberpathinc.com (8.9.3+Sun/8.9.3) with SMTP id RAA24818 for ; Wed, 6 Jun 2001 17:25:22 -0400 (EDT) Received: by YSHA with Microsoft Mail id <01C0EEAD.5E937990@YSHA>; Wed, 6 Jun 2001 17:23:14 -0400 Message-ID: <01C0EEAD.5E937990@YSHA> From: YouLing Sha To: "'megaco@fore.com'" Subject: How to determine which encoding scheme is to be used between MG and MGC? Date: Wed, 6 Jun 2001 17:22:58 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.pit.comms.marconi.com id RAA02921 Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: 8bit If the MG support both binary and text encoding scheme, what is the mechanism to determine which encoding is going to be used by the MG? In other words, how the MG and MGC come to the agreement to chose the ABNF encoding or the ASN.1 encoding, if both are supported by the MG and the MGC? Thanks. Regards, YouLing Sha From owner-megaco@fore.com Wed Jun 6 17:26:45 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA09416 for ; Wed, 6 Jun 2001 17:26:45 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA19023; Wed, 6 Jun 2001 17:26:39 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id RAA03375 for megaco-list; Wed, 6 Jun 2001 17:25:45 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA03352 for ; Wed, 6 Jun 2001 17:25:42 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 6 Jun 2001 17:25:42 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF04465501@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Paul Long'" , megaco@fore.com Subject: RE: Profiles Date: Wed, 6 Jun 2001 17:25:41 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Look at the MSF website for some profile definitions: http://www.msforum.org/techinfo/MSF-MEDIA-001.00-DRAFT_IA.pdf http://www.msforum.org/techinfo/MSF-MEDIA-002.00-DRAFT_IA.pdf I think most MGs will implement a profile. It will work if you don't; you will have to accept the MG, audit it, and then break the association if you can't deal with it. That will be ugly. In real life however, a network will be provisioned so that wouldn't happen, or at least it would be a management problem if it did. An MG advertises only one profile. It could try to find an MGC to serve it with it's "default" profile, and if that failed, try another, but that is not a particularly great network design. I'd implement an MG that way if it could actually support multiple profiles There is no way for an MG to present multiple profiles. The MGC of course, usually would implement multiple profiles. You CAN negotiate versions. Profiles are the way you get interoperability-by-spec. The protocol has too many options and choices. Just saying you support RFC3015 is not sufficient to guarantee interoperability. A well defined profile should be able to do that - an MG meeting a good profile definition should interwork with any MGC meeting that definition full stop - no ifs, ands, or buts. Brian Brian > -----Original Message----- > From: Paul Long [mailto:plong@ipdialog.com] > Sent: Wednesday, June 06, 2001 5:09 PM > To: megaco@fore.com > Subject: Profiles > > > I have some basic questions regarding profiles. > > 1. Is IPPhone the only residential-GW profile currently available? > 2. Would it ever make sense to _not_ be using a profile? If > so, under what > circumstances would one want to not use a profile? > 3. It appears that an MG would typically support just one > profile. Is that > correct? For example, there isn't any way to present to the > MGC a set of > profiles that the MG may support and have the MGC pick one, > right? I suppose > if the registration failed due to the profile, the MG could attempt > subsequent registrations with different profiles. Is this how it is > envisioned to work? Or would MGs and MGCs typically be > deployed by the same > organization, and it is their responsibility to deploy MGs > and MGCs with > compatible profiles? > 4. Any other thoughs on the matter?... > > Paul Long > ipDialog, Inc. > From owner-megaco@fore.com Wed Jun 6 18:11:41 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA09914 for ; Wed, 6 Jun 2001 18:11:41 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA22006; Wed, 6 Jun 2001 18:11:34 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id SAA12893 for megaco-list; Wed, 6 Jun 2001 18:08:56 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA12888 for ; Wed, 6 Jun 2001 18:08:55 -0400 (EDT) From: newpick@main.ukrcom.kherson.ua Received: from maile.village.telecomitalia.it (maile.village.tin.it [195.14.96.138]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA21759 for ; Wed, 6 Jun 2001 18:08:52 -0400 (EDT) Received: from adnet.co.kr ([216.97.194.46]) by maile.village.telecomitalia.it with Microsoft SMTPSVC(5.5.1877.537.53); Wed, 6 Jun 2001 23:57:06 +0200 Message-ID: <0000022f18b7$0000183c$000020dd@adnet.co.kr> To: Subject: EXPLOSIVE STOCK ALERT !!!!!! Date: Wed, 06 Jun 2001 10:48:42 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: 7bit EXPLOSIVE STOCK ALERT !!!!! EXPLOSIVE STOCK ALERT OPHIDIAN PHARMACEUTICALS INC (OTCBB: OPHD) HUGE NEWSLETTER COVERAGE THIS WEEK!!! This Friday OPHD will be profiled by some major newsletters. huge volume and a strong increase in price is expected for several days. The 52 week high for OPHD is $2.37 (approximately 5 times the current price). Needless to say there is huge upside potential for OPHD. We believe the stock could easily reach over $3 in a few weeks. Good luck and watch OPHD fly this week! DISCLAIMER: hotstocks cautions that stocks are high-risk investments and that some or all investment dollars can be lost. We suggest you consult a professional investment advisor before purchasing any stock. All opinions expressed in this newsletter are the opinions of hotstocks. We recommend you use the information found here as an initial starting point for conducting your own research and conduct your own due diligence on the featured company in order to determine your own personal opinion of the company before investing. for proper removal from this newsletter you must email: unsub992@excite.com From owner-megaco@fore.com Wed Jun 6 18:38:57 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA10078 for ; Wed, 6 Jun 2001 18:38:56 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA23332; Wed, 6 Jun 2001 18:38:50 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id SAA18231 for megaco-list; Wed, 6 Jun 2001 18:37:54 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA18214 for ; Wed, 6 Jun 2001 18:37:52 -0400 (EDT) Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA23224 for ; Wed, 6 Jun 2001 18:37:49 -0400 (EDT) Received: from auemail2.firewall.lucent.com (localhost [127.0.0.1]) by auemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f56Mbok26388 for ; Wed, 6 Jun 2001 18:37:50 -0400 (EDT) Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3]) by auemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f56Mboq26381 for ; Wed, 6 Jun 2001 18:37:50 -0400 (EDT) Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id SAA05456; Wed, 6 Jun 2001 18:37:48 -0400 (EDT) Received: from lucent.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id SAA05452; Wed, 6 Jun 2001 18:37:48 -0400 (EDT) Message-ID: <3B1EB043.AD0F64B9@lucent.com> Date: Wed, 06 Jun 2001 18:35:47 -0400 From: Troy Cauble Reply-To: Troy Cauble X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: MEGACO list Subject: Annex M (Adv. Audio Server packages) ?? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: 7bit What's the status of Annex M? Does it have package id numbers yet? -troy From owner-megaco@fore.com Wed Jun 6 18:58:57 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA10276 for ; Wed, 6 Jun 2001 18:58:56 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA24520; Wed, 6 Jun 2001 18:58:48 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id SAA21721 for megaco-list; Wed, 6 Jun 2001 18:58:01 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA21717 for ; Wed, 6 Jun 2001 18:58:00 -0400 (EDT) Received: from zcars0m9.ca.nortel.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA24404 for ; Wed, 6 Jun 2001 18:57:56 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f56MvnE12673 for ; Wed, 6 Jun 2001 18:57:49 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Wed, 6 Jun 2001 18:57:29 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 6 Jun 2001 18:57:38 -0400 Message-ID: <28560036253BD41191A10000F8BCBD110250CC5F@zcard00g.ca.nortel.com> From: "Tom-PT Taylor" To: "'Troy Cauble'" , MEGACO list Subject: RE: Annex M (Adv. Audio Server packages) ?? Date: Wed, 6 Jun 2001 18:57:32 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0EEDC.11DA5130" X-Orig: Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0EEDC.11DA5130 Content-Type: text/plain; charset="ISO-8859-1" Thanks to my dallying, it's still in progress. I will make the current draft available to everyone within the next day. There is an open issue of whether the base package is too big. There could be separate packages for Play, PlayCollect, and PlayRecord, but each would have to have its own success and probably its own failure events. > -----Original Message----- > From: Troy Cauble [mailto:troy@lucent.com] > Sent: Wednesday, June 06, 2001 6:36 PM > To: MEGACO list > Subject: Annex M (Adv. Audio Server packages) ?? > > > > What's the status of Annex M? > > Does it have package id numbers yet? > > -troy > ------_=_NextPart_001_01C0EEDC.11DA5130 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: Annex M (Adv. Audio Server packages) ??

Thanks to my dallying, it's still in progress.  = I will make the current draft available to everyone within the next = day.  There is an open issue of whether the base package is too = big.  There could be separate packages for Play, PlayCollect, and = PlayRecord, but each would have to have its own success and probably = its own failure events.

> -----Original Message-----
> From: Troy Cauble [mailto:troy@lucent.com]
> Sent: Wednesday, June 06, 2001 6:36 PM
> To: MEGACO list
> Subject: Annex M (Adv. Audio Server packages) = ??
>
>
>
> What's the status of Annex M?
>
> Does it have package id numbers yet?
>
> -troy
>

------_=_NextPart_001_01C0EEDC.11DA5130-- From owner-megaco@fore.com Thu Jun 7 01:43:59 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA17619 for ; Thu, 7 Jun 2001 01:43:58 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id BAA06050; Thu, 7 Jun 2001 01:43:49 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id BAA21959 for megaco-list; Thu, 7 Jun 2001 01:39:53 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id BAA21954 for ; Thu, 7 Jun 2001 01:39:51 -0400 (EDT) From: 60paJYyFh@excite.com Received: from server.lowe ([211.111.159.11]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with SMTP id BAA05886 for ; Thu, 7 Jun 2001 01:39:46 -0400 (EDT) Received: from edhfv2ZEM (unverified [209.210.147.58]) by server.lowe (EMWAC SMTPRS 0.83) with SMTP id ; Thu, 07 Jun 2001 14:17:15 +0900 DATE: 06 Jun 01 10:59:42 PM Message-ID: SUBJECT: Your ad here... Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Whatever your product, service or business, email will bring customers to you. Send email for yourself, with a protected website and live tech support. Introduction special 300,000 emails sent for you, only $300.00 Call 702-252-4626 9-5pm. p.s.t. see below for remove. To be removed from this email list, please type "REMOVE" in the subject line.Thank you. abx00@excite.com From owner-megaco@fore.com Thu Jun 7 02:40:55 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA28052 for ; Thu, 7 Jun 2001 02:40:55 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id CAA07659; Thu, 7 Jun 2001 02:40:48 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id CAA25612 for megaco-list; Thu, 7 Jun 2001 02:40:05 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id CAA25608 for ; Thu, 7 Jun 2001 02:40:03 -0400 (EDT) Received: from mail-lod.audiocodes.com ([212.143.19.162]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id CAA07587 for ; Thu, 7 Jun 2001 02:39:59 -0400 (EDT) Received: by MAIL-LOD with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Jun 2001 09:39:58 +0200 Message-ID: <3F2E96E0B800D511821E00306E062AE404BDA9@MAIL-LOD> From: Nurit Shenhar To: "'Megaco (E-mail)" Subject: RE: ABNF Question: digit maps embedded in events Date: Thu, 7 Jun 2001 09:39:51 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk So, do we agree on the following? eventDM = DigitMapToken ((EQUAL digitMapName ) / (LBRKT digitMapValue RBRKT)) digitMapDescriptor = DigitMapToken EQUAL digitMapName [LBRKT digitMapValue RBRKT] Nurit -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] Sent: Wednesday, June 06, 2001 8:11 PM To: 'Nurit Shenhar'; 'Megaco (E-mail) Subject: RE: ABNF Question: digit maps embedded in events The issue is you should never see a construction like keyword={..} It's always keyword=value{..} or keyword{..} so, you don't want the EQUAL token in EventDM if all you get is a value. Your production should be: eventDM = DigitMapToken ((EQUAL digitMapName ) / (LBRKT digitMapValue RBRKT)) Brian > -----Original Message----- > From: Nurit Shenhar [mailto:nurit.shenhar@audiocodes.com] > Sent: Wednesday, June 06, 2001 11:48 AM > To: 'Megaco (E-mail) > Subject: RE: ABNF Question: digit maps embedded in events > > > Sorry to step in so late, I only now examined this thread. > > We had a discussion once about digit maps, and the conclusion > was that the > first option in the digitMapDescriptor (only value) is > meaningless, and was > left there by mistake. There is no point to program a > termination with an > unnamed digit map, as we won't be able to activate it in the > eventDM... So I > think the correct syntax should be: > > eventDM = DigitMapToken EQUAL (( digitMapName ) / (LBRKT digitMapValue > RBRKT)) > > digitMapDescriptor = DigitMapToken EQUAL digitMapName [LBRKT > digitMapValue > RBRKT] > > Nurit > > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: Friday, June 01, 2001 7:51 PM > To: 'Troy Cauble'; Megaco Mailing List (E-mail) > Subject: RE: ABNF Question: digit maps embedded in events > > > Because it was intended to be symmetric in the beginning, > what is written is incorrect. We have caught and fixed > several of these. When a proposal actually changes what > the original intention/documentation/text vs ABNF(ASN.1) is, > then we defer it. > > Brian > > > -----Original Message----- > > From: Troy Cauble [mailto:troy@lucent.com] > > Sent: Friday, June 01, 2001 11:22 AM > > To: Megaco Mailing List (E-mail) > > Subject: Re: ABNF Question: digit maps embedded in events > > > > > > > > Just curious, but why doesn't this get squashed for > > being an unnecessary change? Nothing's broken except > > the symmetry. > > > > More useful changes have been delayed to v2. > > > > Please treat this as a question, not a complaint! > > Christian, Tom, Brian, et. al. are doing a great job. > > > > -troy > > > > > > Christian Groves wrote: > > > > > > Just in time. I'll add it to the implementors' guide. > > > > > > Christian > > > > > > Tom-PT Taylor wrote: > > > > > > > > Yes, and I suspect I'm the guilty typist. > > > > > > > > > -----Original Message----- > > > > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > > > Sent: Wednesday, May 30, 2001 3:44 PM > > > > > To: 'Steven Weisz'; Megaco Mailing List (E-mail) > > > > > Cc: Taylor, Tom-PT [NORSE:B881:EXCH] > > > > > Subject: RE: ABNF Question: digit maps embedded in events > > > > > > > > > > > > > > > I usually defer to Tom on any digitMap questions. > > > > > I can't tell you how many hours I (and several others > > > > > including Abdullah Rayhan) spent pouring over the > > > > > ABNF to ferret out such problems. > > > > > > > > > > Yes, I agree, it should be > > > > > digitMap={... > > > > > and not > > > > > digitMap{... > > > > > > > > > > I think this qualifies as a typo and deserves an IG entry. > > > > > Tom, do you agree? > > > > > > > > > > Brian > > > > > > > > > > > -----Original Message----- > > > > > > From: Steven Weisz [mailto:sweisz@mediatrix.com] > > > > > > Sent: Wednesday, May 30, 2001 3:08 PM > > > > > > To: Megaco Mailing List (E-mail) > > > > > > Subject: ABNF Question: digit maps embedded in events > > > > > > > > > > > > > > > > > > Hi List, > > > > > > > > > > > > I asked this question a few weeks ago and still have not > > > > > > found an answer. > > > > > > Does anyone have an opinion? > > > > > > > > > > > > It is a quick question concerning a digit map embedded in a > > > > > > requested event. > > > > > > Specifically, if you look at the ABNF the embedded digit map > > > > > > is defined as > > > > > > > > > > > > eventDM = DigitMapToken (( EQUAL digitMapName ) / (LBRKT > > > > > digitMapValue > > > > > > RBRKT)) > > > > > > > > > > > > and a digit map descriptor is defined as: > > > > > > > > > > > > digitMapDescriptor = DigitMapToken EQUAL (( LBRKT > > > > > > digitMapValue RBRKT ) / > > > > > > ( digitMapName [LBRKT > > digitMapValue RBRKT] )) > > > > > > > > > > > > > > > > It obvious that they are very similar, as I believe was > > > > > > intended but there > > > > > > is one thing that is bothering me in eventDM. That is it > > > > > > seems to me that > > > > > > the EQUAL should be right after DigitMapToken as is > > the case in > > > > > > digitMapDescriptor. So we would instead have: > > > > > > > > > > > > eventDM = DigitMapToken EQUAL (( digitMapName ) / (LBRKT > > > > > digitMapValue > > > > > > RBRKT)) > > > > > > > > > > > > Does this make sense? > > > > > > > > > > > > Thanks, > > > > > > > > > > > > Steve > > > > > > > > > > > > > > From owner-megaco@fore.com Thu Jun 7 02:52:24 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA28755 for ; Thu, 7 Jun 2001 02:52:24 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id CAA08029; Thu, 7 Jun 2001 02:52:16 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id CAA26205 for megaco-list; Thu, 7 Jun 2001 02:51:16 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id CAA26201 for ; Thu, 7 Jun 2001 02:51:14 -0400 (EDT) Received: from alcatel.es (mail.alcanet.es [194.224.48.1]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with SMTP id CAA07950 for ; Thu, 7 Jun 2001 02:51:09 -0400 (EDT) Received: from sess01.rdp.asi.alcatel.es ([159.23.144.5]) by ns.alcatel.es with ESMTP id <115320>; Thu, 7 Jun 2001 08:52:53 +0200 Received: from sers002.rpi.ses.alcatel.es (sers002 [159.23.193.30]) by sess01.rdp.asi.alcatel.es (8.9.3+Sun/8.8.5) with ESMTP id IAA16519 for ; Thu, 7 Jun 2001 08:51:02 +0200 (MET DST) Received: from alcatel.es (sevsf075 [159.23.195.75]) by sers002.rpi.ses.alcatel.es (8.8.8+Sun/8.8.8) with ESMTP id IAA14941 for ; Thu, 7 Jun 2001 08:51:03 +0200 (MET DST) Message-ID: <3B1F234B.E79AB846@alcatel.es> Date: Thu, 07 Jun 2001 08:46:35 +0200 From: Fernando Vallejo Lazaro Organization: ALCATEL X-Mailer: Mozilla 4.74 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: megaco@fore.com Subject: termination inheritance Content-Type: multipart/alternative; boundary="------------47FA32FC79DFFA72AF07059F" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk --------------47FA32FC79DFFA72AF07059F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, I just have a question. Imagine we have a Root termination with an event Descriptor. If we create a new Termination in the Gateway, does it have to inherit that event descriptor? Thanks Fernando -- Fernando Vallejo Lazaro Phone: +34 91 330 8279 ALCATEL --------------47FA32FC79DFFA72AF07059F Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hello,

I just have a question.

Imagine we have a Root termination with an event Descriptor.
If we create a new Termination in the Gateway, does it have to inherit that event descriptor?

Thanks
Fernando
 
 
  

-- 
Fernando Vallejo Lazaro
Phone:  +34 91 330 8279
       ALCATEL
  --------------47FA32FC79DFFA72AF07059F-- From owner-megaco@fore.com Thu Jun 7 09:35:07 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA07005 for ; Thu, 7 Jun 2001 09:35:06 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA25763; Thu, 7 Jun 2001 09:31:01 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id JAA15935 for megaco-list; Thu, 7 Jun 2001 09:27:44 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA15864 for ; Thu, 7 Jun 2001 09:27:39 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 7 Jun 2001 09:27:34 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF0446550B@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Fernando Vallejo Lazaro'" , megaco@fore.com Subject: RE: termination inheritance Date: Thu, 7 Jun 2001 09:27:33 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0EF55.9BCF0BF0" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0EF55.9BCF0BF0 Content-Type: text/plain; charset="iso-8859-1" No. Let me phrase that in the terms we usually use. If your MG implements a package defined on Root, that has an event descriptor, only the root termination will have that event descriptor. When we instantiate terminations on the gateway (which happens at boot time for physical terminations, and when an Add command is executed for ephemeral terminations), the set of packages implemented on that termination depend on the type of termination. It would be unusual to implement the same package on root and another type of termination. No currently defined packages could be used that way. Brian -----Original Message----- From: Fernando Vallejo Lazaro [mailto:Fernando.Vallejo_Lazaro@alcatel.es] Sent: Thursday, June 07, 2001 2:47 AM To: megaco@fore.com Subject: termination inheritance Hello, I just have a question. Imagine we have a Root termination with an event Descriptor. If we create a new Termination in the Gateway, does it have to inherit that event descriptor? Thanks Fernando -- Fernando Vallejo Lazaro Phone: +34 91 330 8279 ALCATEL ------_=_NextPart_001_01C0EF55.9BCF0BF0 Content-Type: text/html; charset="iso-8859-1"
No.
 
Let me phrase that in the terms we usually use.
If your MG implements a package defined on Root, that has an event descriptor,
only the root termination will have that event descriptor.  When we instantiate
terminations on the gateway (which happens at boot time for physical
terminations, and when an Add command is executed for ephemeral
terminations), the set of packages implemented on that termination depend on
the type of termination.  It would be unusual to implement the same package
on root and another type of termination.  No currently defined packages could
be used that way.
 
Brian
-----Original Message-----
From: Fernando Vallejo Lazaro [mailto:Fernando.Vallejo_Lazaro@alcatel.es]
Sent: Thursday, June 07, 2001 2:47 AM
To: megaco@fore.com
Subject: termination inheritance

Hello,

I just have a question.

Imagine we have a Root termination with an event Descriptor.
If we create a new Termination in the Gateway, does it have to inherit that event descriptor?

Thanks
Fernando
 
 
  

-- 
Fernando Vallejo Lazaro
Phone:  +34 91 330 8279
       ALCATEL
 
------_=_NextPart_001_01C0EF55.9BCF0BF0-- From owner-megaco@fore.com Thu Jun 7 11:51:17 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09150 for ; Thu, 7 Jun 2001 11:51:17 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA08102; Thu, 7 Jun 2001 11:51:03 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id LAA29202 for megaco-list; Thu, 7 Jun 2001 11:47:44 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA29187 for ; Thu, 7 Jun 2001 11:47:42 -0400 (EDT) Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA07746 for ; Thu, 7 Jun 2001 11:47:38 -0400 (EDT) Received: from auemail2.firewall.lucent.com (localhost [127.0.0.1]) by auemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f57FlaJ19768 for ; Thu, 7 Jun 2001 11:47:36 -0400 (EDT) Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3]) by auemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f57Flah19742 for ; Thu, 7 Jun 2001 11:47:36 -0400 (EDT) Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id LAA08766; Thu, 7 Jun 2001 11:47:34 -0400 (EDT) To: Christian Groves , MEGACO list , "Rosen, Brian" Received: from lucent.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id LAA08757; Thu, 7 Jun 2001 11:47:33 -0400 (EDT) Message-ID: <3B1FA19C.370B203A@lucent.com> Date: Thu, 07 Jun 2001 11:45:32 -0400 From: Troy Cauble Reply-To: Troy Cauble X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 Original-To: Christian Groves , MEGACO list , "Rosen, Brian" Subject: IG 6.79 "Cancelling Event Detection" breaks ABNF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: 7bit Greetings, IG 6.79 introduces the square brackets in the ABNF syntax below. eventsDescriptor = EventsToken [ EQUAL RequestID LBRKT requestedEvent *( COMMA requestedEvent ) RBRKT ] and similar changes to "embedFirst" and "eventBufferDescriptor". The token-only representations for empty descriptors are indistingushable from the auditItem tokens in an auditReturnParameter/terminationAudit. (That is, when parsing a terminationAudit, you can't tell if an EventsToken is an empty eventsDescriptor or an auditItem.) auditItem = ( MuxToken / ModemToken / MediaToken / SignalsToken / EventBufferToken / DigitMapToken / StatsToken / EventsToken / ObservedEventsToken / PackagesToken ) auditReturnParameter = (mediaDescriptor / modemDescriptor / muxDescriptor / eventsDescriptor / signalsDescriptor / digitMapDescriptor / observedEventsDescriptor / eventBufferDescriptor / statisticsDescriptor / packagesDescriptor / errorDescriptor / auditItem ) terminationAudit = auditReturnParameter *(COMMA auditReturnParameter) One fix would be to change the empty descriptor syntax to "Token { }" or "Token = { }". eventsDescriptor = (EventsToken EQUAL RequestID LBRKT requestedEvent *( COMMA requestedEvent ) RBRKT) / (EventsToken LBRKT RBRKT) With similar changes for "embedFirst" and "eventBufferDescriptor". -troy From owner-megaco@fore.com Thu Jun 7 13:43:26 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11390 for ; Thu, 7 Jun 2001 13:43:21 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA16759; Thu, 7 Jun 2001 13:43:09 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id NAA24952 for megaco-list; Thu, 7 Jun 2001 13:41:36 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA24942 for ; Thu, 7 Jun 2001 13:41:34 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 7 Jun 2001 13:41:34 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF04465519@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Troy Cauble'" , Christian Groves , MEGACO list Subject: RE: IG 6.79 "Cancelling Event Detection" breaks ABNF Date: Thu, 7 Jun 2001 13:41:32 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk I see the problem. It took me a while to see why auditItem is in auditReturnParameter in the first place. It's so that you can return an empty descriptor, at least that is the only reason I can come up with. Not all the descriptor definitions allow an "empty" descriptor. Consider Mux and Modem for example: muxDescriptor = MuxToken EQUAL MuxType terminationIDList modemDescriptor = ModemToken (( EQUAL modemType) / (LSBRKT modemType *(COMMA modemType) RSBRKT)) [ LBRKT NAME parmValue *(COMMA NAME parmValue) RBRKT ] Notice that an empty modem is easy, but an empty mux is not. Assuming there isn't another reason, your problem is solved -- you can assume either, they mean the same thing, and you don't have to change the syntax. I'm worried that a rule-based parser will complain about the grammar as opposed to actually having a problem parsing. It would have been better to eliminate auditItem in auditReturnParameter and fix all the descriptor productions to have the value optional. That seems like too big of a change for the IG. Brian > -----Original Message----- > From: Troy Cauble [mailto:troy@lucent.com] > Sent: Thursday, June 07, 2001 11:46 AM > To: Christian Groves; MEGACO list; Rosen, Brian > Subject: IG 6.79 "Cancelling Event Detection" breaks ABNF > > > > Greetings, > > IG 6.79 introduces the square brackets in the ABNF syntax below. > > eventsDescriptor = EventsToken [ EQUAL RequestID LBRKT > requestedEvent *( COMMA > requestedEvent ) RBRKT ] > > and similar changes to "embedFirst" and "eventBufferDescriptor". > > > The token-only representations for empty descriptors are > indistingushable > from the auditItem tokens in an auditReturnParameter/terminationAudit. > > (That is, when parsing a terminationAudit, you can't tell if an > EventsToken is an empty eventsDescriptor or an auditItem.) > > auditItem = ( MuxToken / ModemToken / MediaToken / > SignalsToken / EventBufferToken / > DigitMapToken / StatsToken / EventsToken / > ObservedEventsToken / PackagesToken ) > > auditReturnParameter = (mediaDescriptor / modemDescriptor / > muxDescriptor / eventsDescriptor / > signalsDescriptor / digitMapDescriptor / > observedEventsDescriptor / > eventBufferDescriptor / > statisticsDescriptor / packagesDescriptor / > errorDescriptor / auditItem ) > > terminationAudit = auditReturnParameter *(COMMA > auditReturnParameter) > > > One fix would be to change the empty descriptor syntax to "Token { }" > or "Token = { }". > > eventsDescriptor = (EventsToken EQUAL RequestID LBRKT > requestedEvent *( COMMA > requestedEvent ) RBRKT) / > (EventsToken LBRKT RBRKT) > > With similar changes for "embedFirst" and "eventBufferDescriptor". > > -troy > From owner-megaco@fore.com Thu Jun 7 15:37:23 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13214 for ; Thu, 7 Jun 2001 15:37:22 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA25926; Thu, 7 Jun 2001 15:36:25 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id PAA20233 for megaco-list; Thu, 7 Jun 2001 15:34:53 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA20219 for ; Thu, 7 Jun 2001 15:34:51 -0400 (EDT) Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA25698 for ; Thu, 7 Jun 2001 15:34:47 -0400 (EDT) Received: from hoemail1.firewall.lucent.com (localhost [127.0.0.1]) by hoemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f57JYmH23051 for ; Thu, 7 Jun 2001 15:34:48 -0400 (EDT) Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3]) by hoemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f57JYl423015 for ; Thu, 7 Jun 2001 15:34:47 -0400 (EDT) Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id PAA19746; Thu, 7 Jun 2001 15:34:45 -0400 (EDT) Cc: Christian Groves , MEGACO list Received: from lucent.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id PAA19732; Thu, 7 Jun 2001 15:34:43 -0400 (EDT) Message-ID: <3B1FD6DA.66AEEC66@lucent.com> Date: Thu, 07 Jun 2001 15:32:42 -0400 From: Troy Cauble Reply-To: Troy Cauble X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Rosen, Brian" Original-CC: Christian Groves , MEGACO list Subject: Re: IG 6.79 "Cancelling Event Detection" breaks ABNF References: <4FBEA8857476D311A03300204840E1CF04465519@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: 7bit "Rosen, Brian" wrote: > > I see the problem. It took me a while to see why auditItem > is in auditReturnParameter in the first place. It's so that > you can return an empty descriptor, at least that is the only > reason I can come up with. How do we verify that this was the only intended use of that form in auditReturnParameter? The rest of my statements below are based on this assumption. > Not all the descriptor definitions > allow an "empty" descriptor. Consider Mux and Modem for example: > muxDescriptor = MuxToken EQUAL MuxType terminationIDList > modemDescriptor = ModemToken (( EQUAL modemType) / > (LSBRKT modemType *(COMMA modemType) RSBRKT)) > [ LBRKT NAME parmValue > *(COMMA NAME parmValue) RBRKT ] > > Notice that an empty modem is easy, but an empty mux is not. It's the same in either case, just an extra "( ) / LBRKT RBRKT" for my proposal or an extra "[ ]" if you're getting rid of auditItem like you propose below. It would make modemDescriptor a little uglier, but I think that having a higher level parsing conflict is uglier yet. And regarding the form, Token-only vs. Token { }, signalsDescriptor already has an empty form that uses the braces. We should be consistent in what an empty descriptor looks like. > Assuming there isn't another reason, your problem is solved -- > you can assume either, they mean the same thing, and you don't > have to change the syntax. Then there are big implications in the ASN.1 encoding. There there are two *very* different ways of encoding the same thing. And you can't fix this in ASN.1 only without making it hard to see the alignment in the two encodings. > I'm worried that a rule-based parser > will complain about the grammar as opposed to actually having a > problem parsing. A rule based parser will have a reduce/reduce conflict. Your argument that it means the same thing and either choice is OK is valid *IFF* 1) the generater will pick one as a default instead of failing, and 2) the writer associates the same actions with the rules. It's much better to fix the problem though. Two ways to encode the same thing is bad. Conflict messages indicate a poorly defined grammar, whether or not you can explain them away. > It would have been better to eliminate auditItem > in auditReturnParameter and fix all the descriptor productions to > have the value optional. I think that this is the "right" answer, too. Another argument for doing the "right" thing: The auditItem elements have been left out of the command API descriptions, section 7.2.5 and 7.2.6. If the returned descriptors listed there *imply* empty ones too, then an "empty" form should be a part of the ABNF & ASN.1 representations for those descriptors. > That seems like too big of a change for the > IG. I see it differently. The IG is breaking things with 6.79. It is never too much to ask that the IG not break things. We need a *different* or *additional* IG modification to solve the problem that 6.79 was trying to solve. This is significant breakage. Please don't let this slide! But I also understand the desire to do minimal changes. Given that, we could fix how the 3 descriptors with empty forms work with auditItem, not how they all work with auditItem. Here is one approach that works with the current 6.79 (although I'd prefer to see those empty descriptors forms changed to Token { }). Two forms of auditItem. auditReturnItem = ( MuxToken / ModemToken / MediaToken / ; SignalsToken / EventBufferToken / DigitMapToken / StatsToken / ; EventsToken / ObservedEventsToken / PackagesToken ) auditItem = ( auditReturnItem / SignalsToken / EventsToken / EventBufferToken ) auditReturnParameter = (mediaDescriptor / modemDescriptor / muxDescriptor / eventsDescriptor / signalsDescriptor / digitMapDescriptor / observedEventsDescriptor / eventBufferDescriptor / statisticsDescriptor / packagesDescriptor / errorDescriptor / auditEmptyReturnItem ) and lots of comments and similar ASN.1 changes. -troy > > Brian > > > -----Original Message----- > > From: Troy Cauble [mailto:troy@lucent.com] > > Sent: Thursday, June 07, 2001 11:46 AM > > To: Christian Groves; MEGACO list; Rosen, Brian > > Subject: IG 6.79 "Cancelling Event Detection" breaks ABNF > > > > > > > > Greetings, > > > > IG 6.79 introduces the square brackets in the ABNF syntax below. > > > > eventsDescriptor = EventsToken [ EQUAL RequestID LBRKT > > requestedEvent *( COMMA > > requestedEvent ) RBRKT ] > > > > and similar changes to "embedFirst" and "eventBufferDescriptor". > > > > > > The token-only representations for empty descriptors are > > indistingushable > > from the auditItem tokens in an auditReturnParameter/terminationAudit. > > > > (That is, when parsing a terminationAudit, you can't tell if an > > EventsToken is an empty eventsDescriptor or an auditItem.) > > > > auditItem = ( MuxToken / ModemToken / MediaToken / > > SignalsToken / EventBufferToken / > > DigitMapToken / StatsToken / EventsToken / > > ObservedEventsToken / PackagesToken ) > > > > auditReturnParameter = (mediaDescriptor / modemDescriptor / > > muxDescriptor / eventsDescriptor / > > signalsDescriptor / digitMapDescriptor / > > observedEventsDescriptor / > > eventBufferDescriptor / > > statisticsDescriptor / packagesDescriptor / > > errorDescriptor / auditItem ) > > > > terminationAudit = auditReturnParameter *(COMMA > > auditReturnParameter) > > > > > > One fix would be to change the empty descriptor syntax to "Token { }" > > or "Token = { }". > > > > eventsDescriptor = (EventsToken EQUAL RequestID LBRKT > > requestedEvent *( COMMA > > requestedEvent ) RBRKT) / > > (EventsToken LBRKT RBRKT) > > > > With similar changes for "embedFirst" and "eventBufferDescriptor". > > > > -troy > > From owner-megaco@fore.com Thu Jun 7 17:00:37 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA14528 for ; Thu, 7 Jun 2001 17:00:36 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA02404; Thu, 7 Jun 2001 17:00:29 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id QAA09627 for megaco-list; Thu, 7 Jun 2001 16:58:22 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA09620 for ; Thu, 7 Jun 2001 16:58:21 -0400 (EDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA02180 for ; Thu, 7 Jun 2001 16:58:12 -0400 (EDT) Received: from mira-sjc5-1.cisco.com (mira-sjc5-1.cisco.com [171.71.163.15]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f57KwKU10136; Thu, 7 Jun 2001 13:58:21 -0700 (PDT) Received: from BFOSTER-W2K.cisco.com (sjc-vpn-tmp232.cisco.com [10.21.64.232]) by mira-sjc5-1.cisco.com (Mirapoint) with ESMTP id AAT98940; Thu, 7 Jun 2001 13:57:59 -0700 (PDT) Message-Id: <4.3.2.7.2.20010606173727.01a2fc68@mira-sjc5-1.cisco.com> X-Sender: bfoster@mira-sjc5-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 07 Jun 2001 13:53:18 -0700 To: kboyle@nortelnetworks.com, C.Michael.Brown@nortelnetworks.com, sarahc@nortelnetworks.com, sad@nortelnetworks.com, meha@nortelnetworks.com From: Bill Foster Subject: Comments on draft-boyle-megaco-tonepkgs-04.txt Cc: megaco Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Is there a plan to provide further definitions of tones in later updates? Many of the tones in this document are presently not defined or have no references to public documents. Where a tone is not defined but is associated with a feature, a reference to a public document that describes the feature would help (but obviously a real tone definition would be best). With no reference or definition of any kind, these would appear to be proprietary tones. In some cases, with no definition, interoperability problems may occur. So "low tone" and "high tone" in the diagnostics package may refer to the same "low tone" and "high tone" as described in GR-529-CORE or maybe they are something completely different. Tones in section 4 are evidently from E.180 and E.182 - but that should be stated. Tones in sections 5-6 seem to all have definitions. Tones in other sections should have references or better definitions: Section 7: xferdt, srdt and tones in Sections 8-12. ----------------------------- Bill Foster Phone: (250) 758-9418 Fax: (781) 998-6492 From owner-megaco@fore.com Thu Jun 7 17:05:23 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA14573 for ; Thu, 7 Jun 2001 17:05:21 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA02926; Thu, 7 Jun 2001 17:05:14 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id RAA11137 for megaco-list; Thu, 7 Jun 2001 17:04:21 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA11112 for ; Thu, 7 Jun 2001 17:04:19 -0400 (EDT) Received: from ind.alcatel.com (postal.xylan.com [208.8.0.248]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA02770 for ; Thu, 7 Jun 2001 17:04:14 -0400 (EDT) Received: from mailhub.ind.alcatel.com (mailhub [198.206.181.70]) by ind.alcatel.com (8.9.3+Sun/8.9.1 (ind.alcatel.com 3.0 [OUT])) with ESMTP id OAA02246 for ; Thu, 7 Jun 2001 14:04:16 -0700 (PDT) X-Origination-Site: Received: from newman.xylan.com (localhost [127.0.0.1]) by mailhub.ind.alcatel.com (8.9.3+Sun/8.9.3/(mailhub 3.2.4 [HUB])) with ESMTP id OAA12235 for ; Thu, 7 Jun 2001 14:04:00 -0700 (PDT) X-InterScan: Passed Received: from ind.alcatel.com ([10.193.100.186]) by newman.xylan.com (Netscape Messaging Server 4.15) with ESMTP id GEKVUO00.60Z for ; Thu, 7 Jun 2001 14:04:00 -0700 Message-ID: <3B1FEB6C.9DDC8A93@ind.alcatel.com> Date: Thu, 07 Jun 2001 14:00:28 -0700 From: Isabelle Cnudde Organization: Alcatel X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: "megaco megaco" Subject: [Fwd: FW: Feed back from telefonica from the meeting.] Content-Type: multipart/mixed; boundary="------------FEB6B397FD810BB47E3164B4" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk This is a multi-part message in MIME format. --------------FEB6B397FD810BB47E3164B4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Could one of you have a look to the 2 first issues? Thanks, Isabelle -- Isabelle Cnudde ----------------- NGN - media gateway tel: +1 408 957 6234 | A L C A T E L | 720 South Milpitas Blvd fax: +1 408 941 1818 ----------------- Milpitas, CA 95035 mailto:Isabelle.Cnudde@ind.alcatel.com USA --------------FEB6B397FD810BB47E3164B4 Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Received: from lroselet ([10.193.8.6]) by newman.xylan.com (Netscape Messaging Server 4.15) with SMTP id GEKOQM00.PSK; Thu, 7 Jun 2001 11:30:22 -0700 Reply-To: From: "Lieve Roseleth" To: , Subject: FW: Feed back from telefonica from the meeting. Date: Thu, 7 Jun 2001 11:25:43 -0700 Message-ID: <002301c0ef7f$43b081e0$0608c10a@assuredaccess.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Mozilla-Status2: 00000000 X-MIME-Autoconverted: from 8bit to quoted-printable by mailgate.pit.comms.marconi.com id RAA02926 Content-Transfer-Encoding: quoted-printable -----Original Message----- From: Carlos Gonz=E1lez [mailto:cgonreq@yahoo.com] Sent: Thursday, June 07, 2001 10:10 AM To: Lieve.Roseleth@ind.alcatel.com; heber.alfaro@ind.alcatel.com; jfene@usa.alcatel.com; Dennis.Ricketts@usa.alcatel.com Cc: Chuong.Nguyen@usa.alcatel.com; Monique.Kunkel@usa.alcatel.com Subject: Feed back from telefonica from the meeting. Hello , This is the feedback received from telefonica Chile: 1.- In the ServiceChange coming from the GW we don't have the time stamp included. 2.- They are not sure we need TransactionResponseACk for each transaction . In my point of view this is because we use TCP. Could you give some feed back on it? 3.- SoftSwitch is sending tdmc/ec > off . Softswitch issue. 4.- Lucent Gateways register sending ServiceChange with reason 909. Softswitch is accepting this a a good reason. Seems a Lucent issue. If the Softswitch receives a ServiceChange with Restart method, this is enough to put in service the GW. The reason refers to a previous problem ( in this case not existing as we reboot the GW). Kind regards, Carlos Gonzalez Monique Kunkel __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ --------------FEB6B397FD810BB47E3164B4-- From owner-megaco@fore.com Thu Jun 7 17:51:48 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15041 for ; Thu, 7 Jun 2001 17:51:47 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA06058; Thu, 7 Jun 2001 17:51:38 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id RAA18676 for megaco-list; Thu, 7 Jun 2001 17:50:35 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA18672 for ; Thu, 7 Jun 2001 17:50:33 -0400 (EDT) Received: from zcars0m9.ca.nortel.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA05873 for ; Thu, 7 Jun 2001 17:50:29 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f57LoME03408 for ; Thu, 7 Jun 2001 17:50:22 -0400 (EDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.ca.nortel.com; Thu, 7 Jun 2001 17:50:25 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Jun 2001 17:50:34 -0400 Message-ID: <28560036253BD41191A10000F8BCBD1104CB0479@zcard00g.ca.nortel.com> From: "Tom-PT Taylor" To: Troy Cauble , "Rosen, Brian" Cc: Christian Groves , MEGACO list Subject: RE: IG 6.79 "Cancelling Event Detection" breaks ABNF Date: Thu, 7 Jun 2001 17:50:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0EF9B.DD563E40" X-Orig: Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0EF9B.DD563E40 Content-Type: text/plain; charset="ISO-8859-1" I'm the one responsible for all this. I suppose I should dig up the thread. Anyway, the intention was definitiely to provide a way of signalling empty descriptors. I think we chose rather arbitrarily between the desc{} and desc form, opting for the latter. -----Original Message----- From: Troy Cauble [mailto:troy@lucent.com] Sent: Thursday, June 07, 2001 3:33 PM To: Rosen, Brian Cc: Christian Groves; MEGACO list Subject: Re: IG 6.79 "Cancelling Event Detection" breaks ABNF "Rosen, Brian" wrote: > > I see the problem. It took me a while to see why auditItem > is in auditReturnParameter in the first place. It's so that > you can return an empty descriptor, at least that is the only > reason I can come up with. How do we verify that this was the only intended use of that form in auditReturnParameter? The rest of my statements below are based on this assumption. > Not all the descriptor definitions > allow an "empty" descriptor. Consider Mux and Modem for example: > muxDescriptor = MuxToken EQUAL MuxType terminationIDList > modemDescriptor = ModemToken (( EQUAL modemType) / > (LSBRKT modemType *(COMMA modemType) RSBRKT)) > [ LBRKT NAME parmValue > *(COMMA NAME parmValue) RBRKT ] > > Notice that an empty modem is easy, but an empty mux is not. It's the same in either case, just an extra "( ) / LBRKT RBRKT" for my proposal or an extra "[ ]" if you're getting rid of auditItem like you propose below. It would make modemDescriptor a little uglier, but I think that having a higher level parsing conflict is uglier yet. And regarding the form, Token-only vs. Token { }, signalsDescriptor already has an empty form that uses the braces. We should be consistent in what an empty descriptor looks like. > Assuming there isn't another reason, your problem is solved -- > you can assume either, they mean the same thing, and you don't > have to change the syntax. Then there are big implications in the ASN.1 encoding. There there are two *very* different ways of encoding the same thing. And you can't fix this in ASN.1 only without making it hard to see the alignment in the two encodings. > I'm worried that a rule-based parser > will complain about the grammar as opposed to actually having a > problem parsing. A rule based parser will have a reduce/reduce conflict. Your argument that it means the same thing and either choice is OK is valid *IFF* 1) the generater will pick one as a default instead of failing, and 2) the writer associates the same actions with the rules. It's much better to fix the problem though. Two ways to encode the same thing is bad. Conflict messages indicate a poorly defined grammar, whether or not you can explain them away. > It would have been better to eliminate auditItem > in auditReturnParameter and fix all the descriptor productions to > have the value optional. I think that this is the "right" answer, too. Another argument for doing the "right" thing: The auditItem elements have been left out of the command API descriptions, section 7.2.5 and 7.2.6. If the returned descriptors listed there *imply* empty ones too, then an "empty" form should be a part of the ABNF & ASN.1 representations for those descriptors. > That seems like too big of a change for the > IG. I see it differently. The IG is breaking things with 6.79. It is never too much to ask that the IG not break things. We need a *different* or *additional* IG modification to solve the problem that 6.79 was trying to solve. This is significant breakage. Please don't let this slide! But I also understand the desire to do minimal changes. Given that, we could fix how the 3 descriptors with empty forms work with auditItem, not how they all work with auditItem. Here is one approach that works with the current 6.79 (although I'd prefer to see those empty descriptors forms changed to Token { }). Two forms of auditItem. auditReturnItem = ( MuxToken / ModemToken / MediaToken / ; SignalsToken / EventBufferToken / DigitMapToken / StatsToken / ; EventsToken / ObservedEventsToken / PackagesToken ) auditItem = ( auditReturnItem / SignalsToken / EventsToken / EventBufferToken ) auditReturnParameter = (mediaDescriptor / modemDescriptor / muxDescriptor / eventsDescriptor / signalsDescriptor / digitMapDescriptor / observedEventsDescriptor / eventBufferDescriptor / statisticsDescriptor / packagesDescriptor / errorDescriptor / auditEmptyReturnItem ) and lots of comments and similar ASN.1 changes. -troy > > Brian > > > -----Original Message----- > > From: Troy Cauble [mailto:troy@lucent.com] > > Sent: Thursday, June 07, 2001 11:46 AM > > To: Christian Groves; MEGACO list; Rosen, Brian > > Subject: IG 6.79 "Cancelling Event Detection" breaks ABNF > > > > > > > > Greetings, > > > > IG 6.79 introduces the square brackets in the ABNF syntax below. > > > > eventsDescriptor = EventsToken [ EQUAL RequestID LBRKT > > requestedEvent *( COMMA > > requestedEvent ) RBRKT ] > > > > and similar changes to "embedFirst" and "eventBufferDescriptor". > > > > > > The token-only representations for empty descriptors are > > indistingushable > > from the auditItem tokens in an auditReturnParameter/terminationAudit. > > > > (That is, when parsing a terminationAudit, you can't tell if an > > EventsToken is an empty eventsDescriptor or an auditItem.) > > > > auditItem = ( MuxToken / ModemToken / MediaToken / > > SignalsToken / EventBufferToken / > > DigitMapToken / StatsToken / EventsToken / > > ObservedEventsToken / PackagesToken ) > > > > auditReturnParameter = (mediaDescriptor / modemDescriptor / > > muxDescriptor / eventsDescriptor / > > signalsDescriptor / digitMapDescriptor / > > observedEventsDescriptor / > > eventBufferDescriptor / > > statisticsDescriptor / packagesDescriptor / > > errorDescriptor / auditItem ) > > > > terminationAudit = auditReturnParameter *(COMMA > > auditReturnParameter) > > > > > > One fix would be to change the empty descriptor syntax to "Token { }" > > or "Token = { }". > > > > eventsDescriptor = (EventsToken EQUAL RequestID LBRKT > > requestedEvent *( COMMA > > requestedEvent ) RBRKT) / > > (EventsToken LBRKT RBRKT) > > > > With similar changes for "embedFirst" and "eventBufferDescriptor". > > > > -troy > > ------_=_NextPart_001_01C0EF9B.DD563E40 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: IG 6.79 "Cancelling Event Detection" breaks = ABNF

I'm the one responsible for all this.  I suppose = I should dig up the thread.  Anyway, the intention was definitiely = to provide a way of signalling empty descriptors.  I think we = chose rather arbitrarily between the desc{} and desc form, opting for = the latter.

-----Original Message-----
From: Troy Cauble [mailto:troy@lucent.com]
Sent: Thursday, June 07, 2001 3:33 PM
To: Rosen, Brian
Cc: Christian Groves; MEGACO list
Subject: Re: IG 6.79 "Cancelling Event = Detection" breaks ABNF


"Rosen, Brian" wrote:
>
> I see the problem.  It took me a while to = see why auditItem
> is in auditReturnParameter in the first = place.  It's so that
> you can return an empty descriptor, at least = that is the only
> reason I can come up with. 

How do we verify that this was the only intended use = of that
form in auditReturnParameter?

The rest of my statements below are based on this = assumption.


> Not all the descriptor definitions
> allow an "empty" descriptor.  = Consider Mux and Modem for example:
>    = muxDescriptor        =3D MuxToken = EQUAL MuxType  terminationIDList
>    = modemDescriptor      =3D ModemToken (( EQUAL = modemType) /
>          = ;            = ;     (LSBRKT modemType *(COMMA modemType) = RSBRKT))
>          = ;            = ;     [ LBRKT NAME parmValue
>          = ;            = ;    *(COMMA NAME parmValue) RBRKT ]
>
> Notice that an empty modem is easy, but an = empty mux is not.

It's the same in either case, just an extra "( ) = / LBRKT RBRKT" for
my proposal or an extra "[ ]" if you're = getting rid of auditItem 
like you propose below.

It would make modemDescriptor a little uglier, but I = think that
having a higher level parsing conflict is uglier = yet.

And regarding the form, Token-only vs. Token { }, = signalsDescriptor
already has an empty form that uses the = braces.  We should be consistent
in what an empty descriptor looks like.


> Assuming there isn't another reason, your = problem is solved --
> you can assume either, they mean the same = thing, and you don't
> have to change the syntax. 

Then there are big implications in the ASN.1 = encoding.  There
there are two *very* different  ways of = encoding the same thing.
And you can't fix this in ASN.1 only without making = it hard to
see the alignment in the two encodings.


> I'm worried that a rule-based parser
> will complain about the grammar as opposed to = actually having a
> problem parsing. 

A rule based parser will have a reduce/reduce = conflict.
Your argument that it means the same thing and = either
choice is OK is valid *IFF* 1) the generater will = pick one
as a default instead of failing, and 2) the writer = associates
the same actions with the rules.

It's much better to fix the problem though.  Two = ways to
encode the same thing is bad.  Conflict = messages indicate a
poorly defined grammar, whether or not you can = explain them
away.


> It would have been better to eliminate = auditItem
> in auditReturnParameter and fix all the = descriptor productions to
> have the value optional. 

I think that this is the "right" answer, = too.

Another argument for doing the "right" = thing:
The auditItem elements have been left out of the = command
API descriptions, section 7.2.5 and 7.2.6.  If = the returned
descriptors listed there *imply* empty ones too, = then an
"empty" form should be a part of the ABNF = & ASN.1 representations
for those descriptors.


> That seems like too big of a change for = the
> IG.

I see it differently.  The IG is breaking things = with 6.79.
It is never too much to ask that the IG not break = things.
We need a *different* or *additional* IG = modification to
solve the problem that 6.79 was trying to = solve.

This is significant breakage.  Please don't let = this slide!


But I also understand the desire to do minimal = changes.
Given that, we could fix how the 3 descriptors with = empty
forms work with auditItem, not how they all work = with auditItem.

Here is one approach that works with the current 6.79 = (although
I'd prefer to see those empty descriptors forms = changed to Token { }).

Two forms of auditItem.

   = auditReturnItem      =3D ( MuxToken / = ModemToken / MediaToken /
          &nb= sp;           &nb= sp;         =         =         =         ; SignalsToken / = EventBufferToken /
          &nb= sp;           &nb= sp;    DigitMapToken / StatsToken / =           ; EventsToken = /
         = ;            = ;      ObservedEventsToken / PackagesToken = )

   = auditItem          &nb= sp; =3D ( auditReturnItem /
          &nb= sp;           &nb= sp;     SignalsToken / EventsToken / = EventBufferToken )

   auditReturnParameter =3D = (mediaDescriptor / modemDescriptor /
          &nb= sp;           &nb= sp;    muxDescriptor / eventsDescriptor /
          &nb= sp;           &nb= sp;    signalsDescriptor / digitMapDescriptor /
          &nb= sp;          = observedEventsDescriptor / eventBufferDescriptor /
          &nb= sp;           &nb= sp;    statisticsDescriptor / packagesDescriptor = /
          &nb= sp;           &nb= sp;     errorDescriptor / auditEmptyReturnItem = )

and lots of comments and similar ASN.1 = changes.


-troy


>
> Brian
>
> > -----Original Message-----
> > From: Troy Cauble [mailto:troy@lucent.com]
> > Sent: Thursday, June 07, 2001 11:46 = AM
> > To: Christian Groves; MEGACO list; Rosen, = Brian
> > Subject: IG 6.79 "Cancelling Event = Detection" breaks ABNF
> >
> >
> >
> > Greetings,
> >
> > IG 6.79 introduces the square brackets in = the ABNF syntax below.
> >
> >    = eventsDescriptor     =3D EventsToken [ EQUAL = RequestID LBRKT
> = >           &n= bsp;           &n= bsp;  requestedEvent *( COMMA
> > requestedEvent ) RBRKT ]
> >
> > and similar changes to = "embedFirst" and "eventBufferDescriptor".
> >
> >
> > The token-only representations for empty = descriptors are
> > indistingushable
> > from the auditItem tokens in an = auditReturnParameter/terminationAudit.
> >
> > (That is, when parsing a terminationAudit, = you can't tell if an
> > EventsToken is an empty eventsDescriptor = or an auditItem.)
> >
> >    = auditItem          &nb= sp; =3D ( MuxToken / ModemToken / MediaToken /
> = >           &n= bsp;           &n= bsp;    SignalsToken / EventBufferToken /
> = >           &n= bsp;           &n= bsp;    DigitMapToken / StatsToken / EventsToken = /
> = >           &n= bsp;           &n= bsp;    ObservedEventsToken / PackagesToken )
> >
> >    auditReturnParameter =3D = (mediaDescriptor / modemDescriptor /
> = >           &n= bsp;           &n= bsp;    muxDescriptor / eventsDescriptor /
> = >           &n= bsp;           &n= bsp;    signalsDescriptor / digitMapDescriptor /
> = >           &n= bsp;          = observedEventsDescriptor /
> > eventBufferDescriptor /
> = >           &n= bsp;           &n= bsp;    statisticsDescriptor / packagesDescriptor = /
> = >           &n= bsp;           &n= bsp;     errorDescriptor / auditItem )
> >
> >    = terminationAudit     =3D auditReturnParameter = *(COMMA
> = >           &n= bsp;           &n= bsp; auditReturnParameter)
> >
> >
> > One fix would be to change the empty = descriptor syntax to "Token { }"
> > or "Token =3D { }".
> >
> >    = eventsDescriptor     =3D (EventsToken EQUAL = RequestID LBRKT
> = >           &n= bsp;           &n= bsp;  requestedEvent *( COMMA
> > requestedEvent ) RBRKT) /
> = >           &n= bsp;           &n= bsp;  (EventsToken LBRKT RBRKT)
> >
> > With similar changes for = "embedFirst" and "eventBufferDescriptor".
> >
> > -troy
> >

------_=_NextPart_001_01C0EF9B.DD563E40-- From owner-megaco@fore.com Thu Jun 7 17:51:57 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15051 for ; Thu, 7 Jun 2001 17:51:56 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA06098; Thu, 7 Jun 2001 17:51:49 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id RAA18718 for megaco-list; Thu, 7 Jun 2001 17:50:48 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA18712 for ; Thu, 7 Jun 2001 17:50:45 -0400 (EDT) Received: from zcars0m9.ca.nortel.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA05884 for ; Thu, 7 Jun 2001 17:50:36 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f57LoTE03415 for ; Thu, 7 Jun 2001 17:50:29 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Thu, 7 Jun 2001 17:50:24 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Jun 2001 17:50:34 -0400 Message-ID: <28560036253BD41191A10000F8BCBD1104CB047A@zcard00g.ca.nortel.com> From: "Tom-PT Taylor" To: Troy Cauble , MEGACO list , "Rosen, Brian" Subject: RE: IG 6.79 "Cancelling Event Detection" breaks ABNF Date: Thu, 7 Jun 2001 17:50:28 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0EF9B.DDA03F90" X-Orig: Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0EF9B.DDA03F90 Content-Type: text/plain; charset="ISO-8859-1" It's simple: if the terminationAudit is in a reply, these are empty descriptors; if it's in a request, they are auditItems. -----Original Message----- From: Troy Cauble [mailto:troy@lucent.com] Sent: Thursday, June 07, 2001 11:46 AM ... (That is, when parsing a terminationAudit, you can't tell if an EventsToken is an empty eventsDescriptor or an auditItem.) ... ------_=_NextPart_001_01C0EF9B.DDA03F90 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: IG 6.79 "Cancelling Event Detection" breaks = ABNF

It's simple: if the terminationAudit is in a reply, = these are empty descriptors; if it's in a request, they are = auditItems.

-----Original Message-----
From: Troy Cauble [mailto:troy@lucent.com]
Sent: Thursday, June 07, 2001 11:46 AM
...

(That is, when parsing a terminationAudit, you can't = tell if an
EventsToken is an empty eventsDescriptor or an = auditItem.)

...

------_=_NextPart_001_01C0EF9B.DDA03F90-- From owner-megaco@fore.com Thu Jun 7 18:44:27 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA15617 for ; Thu, 7 Jun 2001 18:44:26 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA08862; Thu, 7 Jun 2001 18:44:18 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id SAA26580 for megaco-list; Thu, 7 Jun 2001 18:41:39 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA26576 for ; Thu, 7 Jun 2001 18:41:37 -0400 (EDT) Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA08711 for ; Thu, 7 Jun 2001 18:41:33 -0400 (EDT) Received: from hoemail1.firewall.lucent.com (localhost [127.0.0.1]) by hoemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f57MfVL06040 for ; Thu, 7 Jun 2001 18:41:32 -0400 (EDT) Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3]) by hoemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f57MfVU06021 for ; Thu, 7 Jun 2001 18:41:31 -0400 (EDT) Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id SAA29332; Thu, 7 Jun 2001 18:41:30 -0400 (EDT) Cc: "Rosen, Brian" , Christian Groves , MEGACO list Received: from lucent.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id SAA29313; Thu, 7 Jun 2001 18:41:26 -0400 (EDT) Message-ID: <3B20029D.B387F514@lucent.com> Date: Thu, 07 Jun 2001 18:39:25 -0400 From: Troy Cauble Reply-To: Troy Cauble X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Tom-PT Taylor Original-CC: "Rosen, Brian" , Christian Groves , MEGACO list Subject: Re: IG 6.79 "Cancelling Event Detection" breaks ABNF References: <28560036253BD41191A10000F8BCBD1104CB0479@zcard00g.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: 7bit > Tom-PT Taylor wrote: > > I'm the one responsible for all this. I suppose I should dig up the thread. > Anyway, the intention was definitiely to provide a way of signalling empty > descriptors. I think we chose rather arbitrarily between the desc{} and desc > form, opting for the latter. Well, an empty Signals Descriptors already uses desc{}, shouldn't we go for the symmetry? Didn't we just change the original protocol for symmetry reasons? This would be just changing the IG. -troy From owner-megaco@fore.com Thu Jun 7 18:46:01 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA15642 for ; Thu, 7 Jun 2001 18:45:56 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA09080; Thu, 7 Jun 2001 18:45:38 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id SAA26767 for megaco-list; Thu, 7 Jun 2001 18:43:28 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA26759 for ; Thu, 7 Jun 2001 18:43:26 -0400 (EDT) Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA08766 for ; Thu, 7 Jun 2001 18:43:22 -0400 (EDT) Received: from hoemail1.firewall.lucent.com (localhost [127.0.0.1]) by hoemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f57MhOL08100 for ; Thu, 7 Jun 2001 18:43:24 -0400 (EDT) Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3]) by hoemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f57MhNU08088 for ; Thu, 7 Jun 2001 18:43:23 -0400 (EDT) Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id SAA29388; Thu, 7 Jun 2001 18:43:07 -0400 (EDT) Cc: MEGACO list Received: from lucent.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id SAA29379; Thu, 7 Jun 2001 18:43:05 -0400 (EDT) Message-ID: <3B200300.F1EA13BB@lucent.com> Date: Thu, 07 Jun 2001 18:41:04 -0400 From: Troy Cauble Reply-To: Troy Cauble X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Tom-PT Taylor Original-CC: MEGACO list Subject: Re: IG 6.79 "Cancelling Event Detection" breaks ABNF References: <28560036253BD41191A10000F8BCBD1104CB047A@zcard00g.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: 7bit A terminationAudit is always in a reply. > Tom-PT Taylor wrote: > > It's simple: if the terminationAudit is in a reply, these are empty > descriptors; if it's in a request, they are auditItems. > > -----Original Message----- > From: Troy Cauble [mailto:troy@lucent.com] > Sent: Thursday, June 07, 2001 11:46 AM > ... > > (That is, when parsing a terminationAudit, you can't tell if an > EventsToken is an empty eventsDescriptor or an auditItem.) > > ... From owner-megaco@fore.com Thu Jun 7 19:02:36 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA15886 for ; Thu, 7 Jun 2001 19:02:35 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id TAA09954; Thu, 7 Jun 2001 19:02:20 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id SAA28412 for megaco-list; Thu, 7 Jun 2001 18:58:41 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA28408 for ; Thu, 7 Jun 2001 18:58:40 -0400 (EDT) Received: from ind.alcatel.com (postal.xylan.com [208.8.0.248]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA09741 for ; Thu, 7 Jun 2001 18:58:36 -0400 (EDT) Received: from mailhub.ind.alcatel.com (mailhub [198.206.181.70]) by ind.alcatel.com (8.9.3+Sun/8.9.1 (ind.alcatel.com 3.0 [OUT])) with ESMTP id PAA05831 for ; Thu, 7 Jun 2001 15:58:38 -0700 (PDT) X-Origination-Site: Received: from newman.xylan.com (localhost [127.0.0.1]) by mailhub.ind.alcatel.com (8.9.3+Sun/8.9.3/(mailhub 3.2.4 [HUB])) with ESMTP id PAA26039 for ; Thu, 7 Jun 2001 15:58:23 -0700 (PDT) X-InterScan: Passed Received: from ind.alcatel.com ([10.193.100.186]) by newman.xylan.com (Netscape Messaging Server 4.15) with ESMTP id GEL15A00.TDT for ; Thu, 7 Jun 2001 15:58:22 -0700 Message-ID: <3B20063A.1E211819@ind.alcatel.com> Date: Thu, 07 Jun 2001 15:54:50 -0700 From: Isabelle Cnudde Organization: Alcatel X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: "megaco megaco" Subject: Re: [Fwd: FW: Feed back from telefonica from the meeting.] References: <3B1FEB6C.9DDC8A93@ind.alcatel.com> Content-Type: text/plain; charset=iso-8859-1 Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by mailgate.pit.comms.marconi.com id TAA09954 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA15886 Please ignore this message as well as the one I sent some time ago. I messed up with my e-mail aliases. It won't happened again! Isabelle Isabelle Cnudde wrote: > > Could one of you have a look to the 2 first issues? > Thanks, > Isabelle > -- > Isabelle Cnudde ----------------- NGN - media gateway > tel: +1 408 957 6234 | A L C A T E L | 720 South Milpitas Blvd > fax: +1 408 941 1818 ----------------- Milpitas, CA 95035 > mailto:Isabelle.Cnudde@ind.alcatel.com USA > > ---------------------------------------------------------------------- > > Subject: FW: Feed back from telefonica from the meeting. > Date: Thu, 7 Jun 2001 11:25:43 -0700 > From: "Lieve Roseleth" > To: , > > -----Original Message----- > From: Carlos González [mailto:cgonreq@yahoo.com] > Sent: Thursday, June 07, 2001 10:10 AM > To: Lieve.Roseleth@ind.alcatel.com; heber.alfaro@ind.alcatel.com; > jfene@usa.alcatel.com; Dennis.Ricketts@usa.alcatel.com > Cc: Chuong.Nguyen@usa.alcatel.com; Monique.Kunkel@usa.alcatel.com > Subject: Feed back from telefonica from the meeting. > > [...] From owner-megaco@fore.com Thu Jun 7 21:21:08 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA17034 for ; Thu, 7 Jun 2001 21:21:08 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id VAA14140; Thu, 7 Jun 2001 21:21:01 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id VAA07500 for megaco-list; Thu, 7 Jun 2001 21:19:06 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id VAA07494 for ; Thu, 7 Jun 2001 21:19:05 -0400 (EDT) Received: from zcars0m9.ca.nortel.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id VAA14012 for ; Thu, 7 Jun 2001 21:19:00 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f581IrE09908 for ; Thu, 7 Jun 2001 21:18:53 -0400 (EDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.ca.nortel.com; Thu, 7 Jun 2001 21:18:50 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Jun 2001 21:18:59 -0400 Message-ID: <28560036253BD41191A10000F8BCBD110250CC78@zcard00g.ca.nortel.com> From: "Tom-PT Taylor" To: "'YouLing Sha'" , "'megaco@fore.com'" Subject: RE: How to determine which encoding scheme is to be used between MG and MGC? Date: Thu, 7 Jun 2001 21:18:53 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0EFB8.FB073B70" X-Orig: Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0EFB8.FB073B70 Content-Type: text/plain; charset="ISO-8859-1" The MG chooses because it makes the initial contact. The port number to which it addresses the initial ServiceChange depends on the encoding. (This is assuming the decision hasn't been configured in the first place.) -----Original Message----- From: YouLing Sha [mailto:ysha@cpmail.cyberpathinc.com] Sent: Wednesday, June 06, 2001 5:23 PM To: 'megaco@fore.com' Subject: How to determine which encoding scheme is to be used between MG and MGC? If the MG support both binary and text encoding scheme, what is the mechanism to determine which encoding is going to be used by the MG? In other words, how the MG and MGC come to the agreement to chose the ABNF encoding or the ASN.1 encoding, if both are supported by the MG and the MGC? Thanks. Regards, YouLing Sha ------_=_NextPart_001_01C0EFB8.FB073B70 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: How to determine which encoding scheme is to be used between = MG and MGC?

The MG chooses because it makes the initial = contact.  The port number to which it addresses the initial = ServiceChange depends on the encoding.  (This is assuming the = decision hasn't been configured in the first place.)

-----Original Message-----
From: YouLing Sha [mailto:ysha@cpmail.cyberpat= hinc.com]
Sent: Wednesday, June 06, 2001 5:23 PM
To: 'megaco@fore.com'
Subject: How to determine which encoding scheme is = to be used between MG
and MGC?


If the MG support both binary and text encoding = scheme, what is the mechanism to determine which encoding is going to = be used by the MG?

In other words, how the MG and MGC come to the = agreement to chose the ABNF encoding or the ASN.1 encoding, if both are = supported by the MG and the MGC?

Thanks.

Regards,
YouLing Sha



------_=_NextPart_001_01C0EFB8.FB073B70-- From owner-megaco@fore.com Thu Jun 7 22:51:00 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA19893 for ; Thu, 7 Jun 2001 22:51:00 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id WAA16963; Thu, 7 Jun 2001 22:50:53 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id WAA13168 for megaco-list; Thu, 7 Jun 2001 22:48:12 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id WAA13158 for ; Thu, 7 Jun 2001 22:48:10 -0400 (EDT) Received: from young (d139-kauai-lih0.midpac.net [204.149.167.139] (may be forged)) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id WAA16808 for ; Thu, 7 Jun 2001 22:47:59 -0400 (EDT) Message-ID: <4183200165824040150@young> X-EM-Version: 5, 0, 0, 19 X-EM-Registration: #01B0530810E603002D00 X-Priority: 3 X-MSMail-Priority: Normal From: "Mitchell" To: megaco@fore.com Subject: Your Order (MLM Plan) Date: Thu, 7 Jun 2001 16:40:40 -1000 MIME-Version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.pit.comms.marconi.com id WAA13160 Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: 8bit Dear Friend, here is your Multi-Level Marketing Plan: "Making over half million dollars every 4 to 5 months from your home for an investment of only $25 U.S. Dollars expense one time" THANKS TO THE COMPUTER AGE AND THE INTERNET! =============================================== BE A MILLIONAIRE LIKE OTHERS WITHIN A YEAR !! Before you say "Bull" , please read the following. This is the letter you have been hearing about on the news lately. Due to the popularity of this letter on the internet, a national weekly news program recently devoted an entire show to the investigation of this program described below , to see if it really can make people money. The show also investigated whether or not the program was legal. Their findings proved once and for all that there are "absolutely no laws prohibiting the participation in the program and if people can follow the simple instructions, they are bound to make some mega bucks with only $25 out of pocket cost". DUE TO THE RECENT INCREASE OF POPULARITY & RESPECT THIS PROGRAM HAS ATTAINED, IT IS CURRENTLY WORKING BETTER THAN EVER. This is what one had to say: "Thanks to this profitable opportunity. I was approached many times before but each time I passed on it. I am so glad I finally joined just to see what one could expect in return for the minimal effort and money required. To my astonishment, I received total $ 610,470.00 in 21 weeks, with money still coming in". Pam Hedland, Fort Lee, New Jersey. ------------------------------------------------------------------------- Here is another testimonial: "This program has been around for a long time but I never believed in it. But one day when I received this again in the mail I decided to gamble my $25 on it. I followed thesimple instructions and walaa ..... 3 weeks later the money started to come in. First month I only made $240.00 but the next 2 months after that I made a total of $290,000.00. So far, in the past 8 months by re-entering the program,I have made over $710,000.00 and I am playing it again. The key to success in this program is to follow the simple steps and NOT change anything ." More testimonials later but first, ****** PRINT THIS NOW FOR YOUR FUTURE REFERENCE ******* $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ If you would like to make at least $500,000 every 4 to 5 months easily and comfortably, please read the following...THEN READ IT AGAIN and AGAIN !!! $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ FOLLOW THE SIMPLE INSTRUCTION BELOW AND YOUR FINANCIAL DREAMS WILL COME TRUE, GUARANTEED! INSTRUCTIONS: **** Order all 5 reports shown on the list below. **** For each report, send $5 CASH, THE NAME & NUMBER OF THE REPORT YOU ARE ORDERING and YOUR E-MAIL ADDRESS to the person whose name appears ON THAT LIST next to the report. MAKE SURE YOUR RETURN ADDRESS IS ON YOUR ENVELOPE TOP LEFT CORNER in case of any mail problems. **** When you place your order, make sure you order each of the 5 reports. You will need all 5 reports so that you can save them on your computer and resell them. YOUR TOTAL COST $5 X 5 = $25.00. **** Within a few days you will receive, via e-mail, each of the 5 reports from these 5 different individuals. Save them on your computer so they will be accessible for you to send to the 1,000's of people who will order them from you. Also make a floppy of these reports and keep it on your desk in case something happen to your computer. ****.IMPORTANT - DO NOT alter the names of the people who are listed next to each report, or their sequence on the list, in any way other than what is instructed below in steps 1 through6 or you will loose out on majority of your profits. Once you understand the way this works, you will also see how it does not work if you change it. Remember, this method has been tested, and if you alter, it will NOT work!!! People have tried to put their friends/relatives names on all five thinking they could get all the money. But it does not work this way. Believe us, we all have tried to be greedy and then nothing happened. So Do Not try to change anything other than what is instructed. Because if you do, it will not work for you. Remember, honesty reaps the reward!!! 1.. After you have ordered all 5 reports, take this advertisement and REMOVE the name & address of the person in REPORT # 5. This person has made it through the cycle and is no doubt counting their fortune. 2.... Move the name & address in REPORT # 4 down TO REPORT # 5. 3.... Move the name & address in REPORT # 3 down TO REPORT # 4. 4.... Move the name & address in REPORT # 2 down TO REPORT # 3. 5.... Move the name & address in REPORT # 1 down TO REPORT # 2 6.... Insert YOUR name & address in the REPORT # 1 Position. PLEASE MAKE SURE you copy every name & address ACCURATELY ! ========================================================= Take this entire letter, with the modified list of names, and save it on your computer. DO NOT MAKE ANY OTHER CHANGES. Save this on a disk as well just in case if you loose any data. To assist you with marketing your business on the internet, the 5 reports you purchase will provide you with invaluable marketing information which includes how to send bulk e-mails legally, where to find thousands of free classified ads and much more. There are 2 Primary methods to get this venture going: METHOD # 1 : BY SENDING BULK E-MAIL LEGALLY ============================================ let's say that you decide to start small, just to see how it goes, and we will assume You and those involved send out only 5,000 e-mails each. Let's also assume that the mailing receive only a0.2% response (the response could be much better but lets just say it is only 0.2% . Also many people will send out hundreds of thousands e-mails instead of only 5,000 each). Continuing with this example, you send out only 5,000 e-mails. With a 0.2% response, that is only 10 orders for report # 1. Those 10 people responded by sending out 5,000 e-mail each for a total of 50,000. Out of those 50,000 e-mails only 0.2% responded with orders. That's = 100 people responded and ordered Report # 2. Those 100 people mail out 5,000 e-mails each for a total of 500,000 e-mails. The 0.2% response to that is 1000 orders for Report # 3. Those 1000 people send out 5,000 e-mails each for a total of 5 million e-mails sent out. The 0.2% response to that is 10,000 orders for Report # 4. Those 10,000 people send out 5,000 e-mails each for a total of 50,000,000 (50 million) e-mails. The 0.2% response to that is 100,000 orders for Report # 5. THAT'S 100,000 ORDERS TIMES $5 EACH = $500,000.00 (half million). Your total income in this example is: 1..... $50 + 2..... $500 + 3..... $5,000 + 4..... $50,000 + 5..... $500,000 ......... Grand Total = $555,550.00 NUMBERS DO NOT LIE. GET A PENCIL & PAPER AND FIGURE OUT THE WORST POSSIBLE RESPONSES AND NO MATTER HOW YOU CALCULATE IT, YOU WILL STILL MAKE A LOT OF MONEY ! ------------------------------------------------------------------------------ REMEMBER FRIEND, THIS IS ASSUMING ONLY 10 PEOPLE ORDERING OUT OF 5,000 YOU MAILED TO. Dare to think for a moment what would happen if everyone, or half or even one 4th of those people mailed 100,000 e-mails each or more? There are over 250 million people on the internet worldwide and counting. Believe me, many people will do just that, and more! METHOD # 2 : BY PLACING FREE ADS ON THE INTERNET =================================================== Advertising on the net is very very inexpensive and there are hundreds of FREE places to advertise. Placing a lot of free adson the internet will easily get a larger response. We strongly suggest you start with Method # 1 and add METHOD # 2 as you go along. For every $5 you receive, all you must do is e-mail them the Report they ordered. That's it . Always provide same day service on all orders. This will guarantee that the e-mail they send out, with your name and address on it, will be prompt because they can not advertise until they receive the report. _____________________ AVAILABLE REPORTS_____________________ ORDER EACH REPORT BY ITS NUMBER & NAME ONLY. Notes: Always send $5 cash (U.S. CURRENCY) for each Report. Checks NOT accepted. Make sure the cash is concealed by wrapping it in at least 2 sheets of paper. On one of those sheets of paper, Write the NUMBER & the NAME of the Report you are ordering, YOUR E-MAIL ADDRESS and your name and postal address. PLACE YOUR ORDER FOR THESE REPORTS NOW : ============================================== REPORT #1, "The Insider's Guide to Sending Bulk E-mail on the Internet" ORDER REPORT #1 FROM: G. Mitchell P.O. Box 25884 Honolulu, Hawaii 96825-0884 don't forget to provide a permanent e-mail address in clear writing (better typed) to receive the reports. We had problems in delivery e-mails before!!! ============================================== REPORT #2 "The Insider's Guide to Advertising for Free on the Internet" ORDER REPORT #2 FROM: JD P.O.Box 1114 Des Plaines, IL 60017 USA ============================================== REPORT #3 "The Secrets to Multilevel Marketing on the Internet" ORDER REPORT #3 FROM: J Santi 833 Walter Ave Des Plaines, IL 60016 USA ============================================== REPORT #4 "How to become a Millionaire utilizing the Power of Multilevel Marketing and the Internet" ORDER REPORT #4 FROM: Elaine Rix 138 Dundas Street, West, #243 Toronto, Ontario Canada M5G 1C3 ============================================== REPORT #5 "How to SEND 1,000,000 e-mails for FREE" ORDER REPORT #5 FROM: C. Shaw P.O. Box 468 Schomberg, Ontario Canada L0G IT0 ============================================== There are currently more than 250,000,000 people online worldwide! $$$$$$$$$ YOUR SUCCESS GUIDELINES $$$$$$$$$$$ Follow these guidelines to guarantee your success: If you do not receive at least 10 orders for Report #1 within 2 weeks, continue sending e-mails until you do. After you have received 10 orders, 2 to 3 weeks after that you should receive 100 orders or more for REPORT # 2. If you did not, continue advertising or sending e-mails until you do. Once you have received 100 or more orders for Report # 2, YOU CAN RELAX, because the system is already working for you , and the cash will continue to roll in ! THIS IS IMPORTANT TO REMEMBER : Every time your name is moved down on the list, you are placed in front of a different report. You can KEEP TRACK of your PROGRESS by watching which report people are ordering from you. IF YOU WANT TO GENERATE MORE INCOME SEND ANOTHER BATCH OF E-MAILS AND START THE WHOLE PROCESS AGAIN. There is NO LIMIT to the income you can generate from this business !!! ____________________________________________________ FOLLOWING IS A NOTE FROM THE ORIGINATOR OF THIS PROGRAM: You have just received information that can give you financial freedom for the rest of your life, with NO RISK and JUST A LITTLE BIT OF EFFORT. You can make more money in the next few weeks and months than you have ever imagined. Follow the program EXACTLY AS INSTRUCTED. Do Not change it in any way. It works exceedingly well as it is now. Remember to e-mail a copy of this exciting report after you have put your name and address in Report #1 and moved others to #2...........# 5 as instructed above. One of the people you send this to may send out 100,000 or more e-mails and your name will be on everyone of them. Remember though, the more you send out the more potential customers you will reach. So my friend, I have given you the ideas, information, materials and opportunity to become financially independent. IT IS UP TO YOU NOW ! ************** MORE TESTIMONIALS **************** "My name is Mitchell. My wife , Jody and I live in Chicago. I am an accountant with a major U.S. Corporation and I make pretty good money. When I received this program I grumbled to Jody about receiving ''junk mail''. I made fun of the whole thing, spouting my knowledge of the population and percentages involved. I ''knew'' it wouldn't work. Jody totally ignored my supposed intelligence and few days later she jumped in with both feet. I made merciless fun of her, and was ready to lay the old ''I told you so'' on her when the thing didn'twork. Well, the laugh was on me! Within 3 weeks she had received 50 responses. Within the next 45 days she had received a total of $ 147,200.00 all cash! I was shocked. I have joined Jody in her ''hobby''." Mitchell Wolf, Chicago, Illinois ------------------------------------------------------------ "Not being the gambling type, it took me several weeks to make up my mind to participate in this plan. But conservative that I am, I decided that the initial investment was so little that there was just no way that I wouldn't get enough orders to at least get my money back. I was surprised when I found my medium size post office box crammed with orders. I made $319,210.00 in the first 12 weeks. The nice thing about this deal is that it does not matter where people live. There simply isn't a better investment with a faster return and so big." Dan Sondstrom, Alberta, Canada ----------------------------------------------------------- "I had received this program before. I deleted it, but later I wondered if I should have given it a try. Of course, I had no idea who to contact to get another copy, so I had to wait until I was e-mailed again by someone else.........11 months passed then it luckily came again...... I did not delete this one! I made more than $490,000 on my first try and all the money came within 22 weeks". Susan De Suza, New York, N.Y. ---------------------------------------------------- "It really is a great opportunity to make relatively easy money with little cost to you. I followed the simple instructions carefully and within 10 days the money started to come in. My first month I made $ 20,560.00 and by the end of third month my total cash count was $ 362,840.00. Life is beautiful, Thanx to internet". Fred Dellaca, Westport, New Zealand ------------------------------------------------------------ ORDER YOUR REPORTS TODAY AND GET STARTED ON YOUR ROAD TO FINANCIAL FREEDOM ! ======================================================= If you have any questions of the legality of this program, contact the Office of Associate Director for Marketing Practices, Federal Trade Commission, Bureau of Consumer Protection, Washington, D.C. Under Bill s.1618 TITLE III passed by the 105th US Congress this letter cannot be considered spam as long as the sender includes contact information and a method of removal. This is one time e-mail transmission. No request for removal is necessary. ------------------------------------------------------------ This message is sent in compliance of the new email Bill HR 1910. Under Bill HR 1910 passed by the 106th US Congress on May 24, 1999, this message cannot be considered Spam as long as we include the way to be removed. Per Section HR 1910, Please type "REMOVE" in the subject line and reply to this email. All removal requests are handled personally an immediately once received. From owner-megaco@fore.com Fri Jun 8 02:23:10 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA03558 for ; Fri, 8 Jun 2001 02:23:09 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id CAA23876; Fri, 8 Jun 2001 02:22:57 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id CAA29483 for megaco-list; Fri, 8 Jun 2001 02:21:21 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id CAA29479 for ; Fri, 8 Jun 2001 02:21:19 -0400 (EDT) Received: from newish7.ericsson.com.au ([203.61.155.116]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id CAA23630 for ; Fri, 8 Jun 2001 02:21:12 -0400 (EDT) Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10]) by newish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id QAA13626; Fri, 8 Jun 2001 16:17:35 +1000 (EST) Received: from ericsson.com (mcdh126.epa.ericsson.se [146.11.81.126]) by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id QAA20701; Fri, 8 Jun 2001 16:18:26 +1000 (EST) Message-ID: <3B2028F2.AF537579@ericsson.com> Date: Fri, 08 Jun 2001 11:22:58 +1000 From: Christian Groves X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Troy Cauble CC: MEGACO list , Terry Anderson Subject: New IG Editor: Re: ASN.1 PkgdName wildcard comments. References: <3B1E94E1.6289D721@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: 7bit G'Day Troy, All, At the SG16 meeting I gave up the editorship of the Implementors' Guide. I have other commitments which meant I couldn't spend the necessary time. The new editor is: Terry Anderson Cheers, Christian PS: The change below is OK. Troy Cauble wrote: > > > Greetings, > > The following Annex A comment refers to "Property Name" > which is too specific (PkgdName is used for lots > of things.) The phrase should be replaced. > > PkgdName ::= OCTET STRING(SIZE(4)) > -- represents Package Name (2 octets) plus Property Name (2 octets) > -- To wildcard a package use 0xFFFF for first two octets, choose > -- is not allowed. To reference native property tag specified in > -- Annex C, use 0x0000 as first two octets. > -- Wildcarding of Package Name is permitted only if Property Name is > -- also wildcarded. > > Also, it states that you can wildcard a "Property Name", > but not how. > > Note that 7.1.9 also states that the EventID portion > (referred to here as "Property Name") of an Event name > can be wild carded. > > I suggest the following rewording. > > -troy > > PkgdName ::= OCTET STRING(SIZE(4)) > -- represents Package Name (2 octets) plus an Property, Event, > -- Signal, or Statistics ID. (2 octets) > -- To wildcard a package use 0xFFFF for the first two octets, choose > -- is not allowed. To reference native property tag specified in > -- Annex C, use 0x0000 as first two octets. > -- To wildcard a Property, Event, Signal, or Statistics ID, use > -- 0xFFFF for last two octets, choose is not allowed. > -- Wildcarding of Package Name is permitted only if the Property, > -- Event, Signal, or Statistics ID is also wildcarded. From owner-megaco@fore.com Fri Jun 8 02:23:12 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA03576 for ; Fri, 8 Jun 2001 02:23:12 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id CAA23894; Fri, 8 Jun 2001 02:23:01 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id CAA29314 for megaco-list; Fri, 8 Jun 2001 02:20:02 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id CAA29293 for ; Fri, 8 Jun 2001 02:19:58 -0400 (EDT) Received: from newish7.ericsson.com.au ([203.61.155.116]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id CAA23589 for ; Fri, 8 Jun 2001 02:19:51 -0400 (EDT) Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10]) by newish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id QAA13643; Fri, 8 Jun 2001 16:17:39 +1000 (EST) Received: from ericsson.com (mcdh126.epa.ericsson.se [146.11.81.126]) by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id QAA20720; Fri, 8 Jun 2001 16:18:30 +1000 (EST) Message-ID: <3B204D4E.6246F20F@ericsson.com> Date: Fri, 08 Jun 2001 13:58:06 +1000 From: Christian Groves X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Paul Long CC: "Megaco Mailing List (E-mail)" Subject: Re: ABNF Question: digit maps embedded in events References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: 7bit G'Day Paul, I'm sorry if I haven't given an encyclopedic definition of "an error". I don't believe there's any hard and fast definition. Really its the rough consensus that decides. I appreciate your concern about interoperability. Any change to syntax or procedure creates an interoperability problem, we have about 80 of them. I believe that its worthwhile in H248v1 fixing all these errors/bugs/clarification/etc so that we don't have any problem when we approve H.248v2. When v2 comes out we also have the issue of backwards compatibility and thus any changes are very serious. H.248 works in the same way as H.323. IGs never get "decided". I'm not sure what happens to RFC3015. With the schedule of getting H248v2 approved in Feb 2002 I believe that we have the chance on getting a very robust stable protocol then. Christian Paul Long wrote: > > Christian, > > That's not going to work. Your use of "an error" is too vague. You can only > put something in the IG if it clarifies an issue or fixes an otherwise > broken aspect of the standard which prevents interoperability (not that > simply brings the syntax into some kind of aesthetic harmony at the risk of > breaking interoperability). Otherwise, as is the case with the proposed > digit-map modification, you have created a conflict that opens us up to > interoperability problems. > > Let's say I have shipped product, it's out the door, and it's compliant. > According to H.248/RFC3015, another entity could send this embedded digit > map to my product, and it would not encounter a parse error. > DigitMap { x } > However, now you are proposing that we change the standard so that the > syntax is now this: > DigitMap = { x } > My product receives this and flags it as a syntax error--you broke it by > changing the standard. > > IMO, interoperability is sacrosanct and trumps aesthetics any day. > > But nobody has answered my second question. When can a version of the > standard no longer be changed? With H.323, both the standard and its IG must > be Decided. Is it the same way with H.248? How about RFC3015? > > Paul Long > ipDialog, Inc. > > -----Original Message----- > From: Christian Groves [mailto:Christian.Groves@ericsson.com] > Sent: Friday, June 01, 2001 4:02 PM > To: Paul Long > Cc: Megaco Mailing List (E-mail) > Subject: Re: ABNF Question: digit maps embedded in events > > G'Day Paul and Troy, > > If the change is new functionality then it goes to v2. > If its to fix an error then it goes to the implementors' guide (IG) > If its to align between ABNF and ASN1 it goes in the IG > If its to fix inconsistencies between procedures and syntax it goes in > the IG > > This is broadly how I interpret things. There aren't really any solid > rules > except for the first one. > > With regards to the EQUALS change I believe it was a syntax > irregularity. I assume the intention when the syntax was written it was > meant to be the way that it was fixed to. > > Cheers, Christian > > Paul Long wrote: > > > > Yeah, what are the criteria for what gets changed in v1 and what gets put > > off to v2? Also, when is v1 officially "done" and can no longer be > changed? > > Like Troy, I'm not complaining--I really want to know. As you can tell > from > > my earlier response to Steve's query, I thought it was already too late to > > change v1. > > > > Paul Long > > ipDialog, Inc. > > > > -----Original Message----- > > From: owner-megaco@pit.comms.marconi.com > > [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Troy Cauble > > Sent: Friday, June 01, 2001 10:22 AM > > To: Megaco Mailing List (E-mail) > > Subject: Re: ABNF Question: digit maps embedded in events > > > > Just curious, but why doesn't this get squashed for > > being an unnecessary change? Nothing's broken except > > the symmetry. > > > > More useful changes have been delayed to v2. > > > > Please treat this as a question, not a complaint! > > Christian, Tom, Brian, et. al. are doing a great job. > > > > -troy From owner-megaco@fore.com Fri Jun 8 02:23:34 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA03607 for ; Fri, 8 Jun 2001 02:23:34 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id CAA23965; Fri, 8 Jun 2001 02:23:23 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id CAA29203 for megaco-list; Fri, 8 Jun 2001 02:19:36 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id CAA29199 for ; Fri, 8 Jun 2001 02:19:34 -0400 (EDT) Received: from newish7.ericsson.com.au ([203.61.155.116]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id CAA23580 for ; Fri, 8 Jun 2001 02:19:28 -0400 (EDT) Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10]) by newish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id QAA13628 for ; Fri, 8 Jun 2001 16:17:36 +1000 (EST) Received: from ericsson.com (mcdh126.epa.ericsson.se [146.11.81.126]) by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id QAA20705 for ; Fri, 8 Jun 2001 16:18:28 +1000 (EST) Message-ID: <3B202AC5.63F9F985@ericsson.com> Date: Fri, 08 Jun 2001 11:30:45 +1000 From: Christian Groves X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: megaco@fore.com Subject: Re: Profiles References: <4FBEA8857476D311A03300204840E1CF04465501@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: 7bit G'Day, Profiles are definately something that needs further definition. The current mechanisms and profiles I believe aren't sufficient. Please see my comments below. Cheers, Christian "Rosen, Brian" wrote: > > Look at the MSF website for some profile definitions: > http://www.msforum.org/techinfo/MSF-MEDIA-001.00-DRAFT_IA.pdf > http://www.msforum.org/techinfo/MSF-MEDIA-002.00-DRAFT_IA.pdf > > I think most MGs will implement a profile. It will work if > you don't; you will have to accept the MG, audit it, and then > break the association if you can't deal with it. > That will be ugly. In real life however, a network will be > provisioned so that wouldn't happen, or at least it would be a > management problem if it did. [CHG] As mentioned I don't think this is a problem as in real life this information will be provisioned. > > An MG advertises only one profile. It could try to find an MGC > to serve it with it's "default" profile, and if that failed, try > another, but that is not a particularly great network design. > I'd implement an MG that way if it could actually support multiple > profiles [CHG] I believe that it will be the normal operation that a MG could support multiple profiles. I don't believe that the way proposed by Brian would work as for a particular call/session the MG may in fact need to use elements from two profiles. > > There is no way for an MG to present multiple profiles. > The MGC of course, usually would implement multiple profiles. > You CAN negotiate versions. [CHG] Versions won't help when dealing with profiles. I believe that an update to the profile definition needs to be done for H.248v2. In fact its something I'm planning a contribution on. > > Profiles are the way you get interoperability-by-spec. The > protocol has too many options and choices. Just saying you support > RFC3015 is not sufficient to guarantee interoperability. A well > defined profile should be able to do that - an MG meeting > a good profile definition should interwork with any MGC meeting that > definition full stop - no ifs, ands, or buts. [CHG] I agree but I do not believe currently defined profiles go anywhere close to a full definition. Its the process of this definition not the fact that you send a profile name in a service change that acheives this. ie. you have to agree on a transport even before you can send a service change. > > Brian > > Brian > > > -----Original Message----- > > From: Paul Long [mailto:plong@ipdialog.com] > > Sent: Wednesday, June 06, 2001 5:09 PM > > To: megaco@fore.com > > Subject: Profiles > > > > > > I have some basic questions regarding profiles. > > > > 1. Is IPPhone the only residential-GW profile currently available? > > 2. Would it ever make sense to _not_ be using a profile? If > > so, under what > > circumstances would one want to not use a profile? > > 3. It appears that an MG would typically support just one > > profile. Is that > > correct? For example, there isn't any way to present to the > > MGC a set of > > profiles that the MG may support and have the MGC pick one, > > right? I suppose > > if the registration failed due to the profile, the MG could attempt > > subsequent registrations with different profiles. Is this how it is > > envisioned to work? Or would MGs and MGCs typically be > > deployed by the same > > organization, and it is their responsibility to deploy MGs > > and MGCs with > > compatible profiles? > > 4. Any other thoughs on the matter?... > > > > Paul Long > > ipDialog, Inc. > > From owner-megaco@fore.com Fri Jun 8 05:32:06 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA08076 for ; Fri, 8 Jun 2001 05:32:06 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id FAA29596; Fri, 8 Jun 2001 05:31:55 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id FAA13808 for megaco-list; Fri, 8 Jun 2001 05:27:54 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id FAA13804 for ; Fri, 8 Jun 2001 05:27:52 -0400 (EDT) Received: from alcatel.es (mail.alcanet.es [194.224.48.1]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with SMTP id FAA29402 for ; Fri, 8 Jun 2001 05:27:47 -0400 (EDT) Received: from sess01.rdp.asi.alcatel.es ([159.23.144.5]) by ns.alcatel.es with ESMTP id <115536>; Fri, 8 Jun 2001 11:30:46 +0200 Received: from sers002.rpi.ses.alcatel.es (sers002 [159.23.193.30]) by sess01.rdp.asi.alcatel.es (8.9.3+Sun/8.8.5) with ESMTP id LAA11112 for ; Fri, 8 Jun 2001 11:27:49 +0200 (MET DST) Received: from alcatel.es (sevsg015 [159.23.188.15]) by sers002.rpi.ses.alcatel.es (8.8.8+Sun/8.8.8) with ESMTP id LAA21054 for ; Fri, 8 Jun 2001 11:28:04 +0200 (MET DST) Message-ID: <3B209E50.7372B006@alcatel.es> Date: Fri, 08 Jun 2001 11:43:44 +0200 From: Cristina Sanchez X-Mailer: Mozilla 4.74 [en] (X11; U; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: megaco@fore.com Subject: Digitmap timers : how to cancel them ? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: 7bit Hello, Let's assume the MG has provisioned some default values for the digitmap timers and the MGC wants to eliminate the Start Timer (i.e. infinite wait) This requirement arises when the subscriber can activate a special service by dialing some digits during the conversation phase (e.g. call transference) I see one only one possibility : the MGC sends a digitmap descriptor with no start timer configuration (i.e. no "T:" field). But, can the MG interpret this command as maintaining the existing default value ? Is there an explicit way of setting the digitmap Start Timer to infinite ? Regards, Cristina From owner-megaco@fore.com Fri Jun 8 08:01:51 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA10205 for ; Fri, 8 Jun 2001 08:01:49 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA04971; Fri, 8 Jun 2001 08:01:37 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id IAA28792 for megaco-list; Fri, 8 Jun 2001 08:00:33 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA28780 for ; Fri, 8 Jun 2001 08:00:31 -0400 (EDT) Received: from netmail2.alcatel.com (netmail2.alcatel.com [128.251.168.51]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA04848 for ; Fri, 8 Jun 2001 08:00:26 -0400 (EDT) Received: from auds953.usa.alcatel.com (auds953.usa.alcatel.com [143.209.238.6]) by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id HAA21359; Fri, 8 Jun 2001 07:00:27 -0500 (CDT) Received: from axes-mach01.axes-mach01.usa.alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f58C0ND27423; Fri, 8 Jun 2001 07:00:24 -0500 (CDT) Received: from Chak by axes-mach01.axes-mach01.usa.alcatel.com (8.9.1b+Sun/SMI-SVR4) id RAA13924; Fri, 8 Jun 2001 17:26:36 -0500 (GMT) Message-ID: <006901c0f013$1b0681b0$2f09ca82@Chak> From: "PSK Chakravarthi" To: "Cristina Sanchez" , References: <3B209E50.7372B006@alcatel.es> Subject: Re: Digitmap timers : how to cancel them ? Date: Fri, 8 Jun 2001 17:33:59 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: 7bit Cristina, Instead of digit map you can arm an event to detect any DTMF digit and send embedded event descriptor with digit map. After detecting any DTMF digit, MG sends Notify command with the digit dialed and makes the digit map active. In this scenario MG will not start first digit timer for detecting DTMF digit. regards Chak ----- Original Message ----- From: "Cristina Sanchez" To: Sent: Friday, June 08, 2001 3:13 PM Subject: Digitmap timers : how to cancel them ? > Hello, > > Let's assume the MG has provisioned some default values for the digitmap > timers and the MGC wants to eliminate the Start Timer (i.e. infinite > wait) > > This requirement arises when the subscriber can activate a special > service by dialing some digits during the conversation phase (e.g. call > transference) > > I see one only one possibility : the MGC sends a digitmap descriptor > with no start timer configuration (i.e. no "T:" field). But, can the MG > interpret this command as maintaining the existing default value ? > > Is there an explicit way of setting the digitmap Start Timer to infinite > ? > > Regards, > Cristina > From owner-megaco@fore.com Fri Jun 8 08:42:28 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA11224 for ; Fri, 8 Jun 2001 08:42:27 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA07468; Fri, 8 Jun 2001 08:42:08 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id IAA05709 for megaco-list; Fri, 8 Jun 2001 08:41:20 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA05590 for ; Fri, 8 Jun 2001 08:41:19 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Fri, 8 Jun 2001 08:41:04 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF0446551E@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Troy Cauble'" , Tom-PT Taylor Cc: Christian Groves , "'tla@lucent.com'" , MEGACO list Subject: RE: IG 6.79 "Cancelling Event Detection" breaks ABNF Date: Fri, 8 Jun 2001 08:41:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk I agree with Tom; we did a pass over the ABNF to try to make all of the empty forms not have braces. The choice was completely arbitrary, and as I recall, we decided since it didn't make any real difference, shorter was better. If we missed one, we goofed. Tom, the problem here seems to be real. As Troy says, you will get a reduce conflict in a rules-based parser with this ambiguity. I'm pretty sure you can ignore the problem, but it's poor design practice. You will recall all of the effort Abdallah and Nancy went through to test out these kinds of things as we developed the ABNF. The IG change wasn't verified in the same way, thus we have this problem. We need to decide what to do. Brian > -----Original Message----- > From: Troy Cauble [mailto:troy@lucent.com] > Sent: Thursday, June 07, 2001 6:39 PM > To: Tom-PT Taylor > Cc: Rosen, Brian; Christian Groves; MEGACO list > Subject: Re: IG 6.79 "Cancelling Event Detection" breaks ABNF > > > > Tom-PT Taylor wrote: > > > > I'm the one responsible for all this. I suppose I should > dig up the thread. > > Anyway, the intention was definitiely to provide a way of > signalling empty > > descriptors. I think we chose rather arbitrarily between > the desc{} and desc > > form, opting for the latter. > > Well, an empty Signals Descriptors already uses desc{}, > shouldn't we go for the symmetry? Didn't we just change > the original protocol for symmetry reasons? This would > be just changing the IG. > > -troy > From owner-megaco@fore.com Fri Jun 8 09:38:40 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA12388 for ; Fri, 8 Jun 2001 09:38:40 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA11989; Fri, 8 Jun 2001 09:38:31 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id JAA18021 for megaco-list; Fri, 8 Jun 2001 09:35:48 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA18017 for ; Fri, 8 Jun 2001 09:35:47 -0400 (EDT) From: hardcore999@newmail.ru Received: from big.notre.co.kr ([211.196.244.69]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA11754 for ; Fri, 8 Jun 2001 09:35:40 -0400 (EDT) Received: from www.turbomail.net (slip-32-101-129-108.mn.us.prserv.net [32.101.129.108]) by big.notre.co.kr (8.9.3/8.9.3) with SMTP id WAA08229 for ; Fri, 8 Jun 2001 22:42:48 +0900 To: Date: Fri, 8 Jun 2001 05:02:06 Message-Id: <204.786854.136243@www.turbomail.net> Subject: Hard XXX Action Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: 7bit -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Does Tight Little Pussies - Turn you on?? Welcome To The premiere Porn Site On The Web. Guaranteed !!!!!! -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- http://209.195.63.163/nasty2/6/index.html Try us for 3 days at only $1.95 Hardcore-Sex-Feeds Whats YOU!! Get With your Membership 24hr Live Fucking 7 Days per Week Now Boasting over 100,000 Hell Hardcore XXX-Feeds Cunt Pumping Pictorials ( Now over 800,000 ) All the Latest Updated Porn Voyuer Cams Galore upskirt-pussy cam- dildo cam-toilet cam-dressing room cam- dorm cam-oncampus cam-shower cam-hot Tub cam -tanning cam and more. 11,000+ Fucked up Sex Stories Virgins first Time Barely 18, Vacations, Sex at Work, Gay, Wierd, you name it Hardcore-Sex-Feeds Has it. XXX-Games ( Interactive ) Online Dating ( Find your Wife a Slut to Eat Her Smelly Hole ) http://209.195.63.163/nasty2/6/index.html For your ultimate pleasure: cum join!!!!!!!!!!!!!!!!!!!!!! From owner-megaco@fore.com Fri Jun 8 10:19:46 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13029 for ; Fri, 8 Jun 2001 10:19:45 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA15771; Fri, 8 Jun 2001 10:19:36 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA00110 for megaco-list; Fri, 8 Jun 2001 10:18:14 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA00091 for ; Fri, 8 Jun 2001 10:18:11 -0400 (EDT) Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA15585 for ; Fri, 8 Jun 2001 10:18:00 -0400 (EDT) Received: from ihemail1.firewall.lucent.com (localhost [127.0.0.1]) by ihemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f58EI4406377 for ; Fri, 8 Jun 2001 10:18:04 -0400 (EDT) Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3]) by ihemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f58EI3M06358 for ; Fri, 8 Jun 2001 10:18:03 -0400 (EDT) Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id KAA26012; Fri, 8 Jun 2001 10:18:00 -0400 (EDT) Cc: MEGACO list Received: from lucent.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id KAA26003; Fri, 8 Jun 2001 10:17:59 -0400 (EDT) Message-ID: <3B20DE1F.FD98E18B@lucent.com> Date: Fri, 08 Jun 2001 10:15:59 -0400 From: Troy Cauble Reply-To: Troy Cauble X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Christian Groves Original-CC: MEGACO list Subject: Re: New IG Editor References: <3B1E94E1.6289D721@lucent.com> <3B2028F2.AF537579@ericsson.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: 7bit Christian Groves wrote: > > G'Day Troy, All, > > At the SG16 meeting I gave up the editorship of the Implementors' Guide. > I have other commitments which meant I couldn't spend the necessary > time. > > The new editor is: Terry Anderson > > Cheers, Christian Thanks Christian for all the work. Was IG v7 approved? Has it changed since it was posted to http://standard.pictel.com/ftp/avc-site/0105_Por/DC-xxx_H248_Implementors_Additions_v7.zip ? -troy From owner-megaco@fore.com Fri Jun 8 10:50:33 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13539 for ; Fri, 8 Jun 2001 10:50:32 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA18559; Fri, 8 Jun 2001 10:50:18 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA09664 for megaco-list; Fri, 8 Jun 2001 10:49:06 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA09654 for ; Fri, 8 Jun 2001 10:49:04 -0400 (EDT) Received: from sm10.texas.rr.com (sm10.texas.rr.com [24.93.35.222]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA18387 for ; Fri, 8 Jun 2001 10:48:58 -0400 (EDT) Received: from plong (cs666831-163.austin.rr.com [66.68.31.163]) by sm10.texas.rr.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f58Emfu3017538 for ; Fri, 8 Jun 2001 09:48:41 -0500 From: "Paul Long" To: "'Megaco \(E-mail\)" Subject: RE: ABNF Question: digit maps embedded in events Date: Fri, 8 Jun 2001 09:49:02 -0500 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal In-Reply-To: <3F2E96E0B800D511821E00306E062AE404BDA9@MAIL-LOD> Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: 7bit That's okay for MegacoV2 but not for IGv1 because it would "break" the standard. Specifically, a MegacoV1-compliant entity can currently transmit this digit-map descriptor: DigitMap = { x } However, a MegacoV1 entity that incorporates your proposed change would encounter a decode error for this. If I'm missing something, please enlighten me. How do you propose we handle this scenario with your change? Paul Long ipDialog, Inc. -----Original Message----- From: owner-megaco@pit.comms.marconi.com [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Nurit Shenhar Sent: Thursday, June 07, 2001 2:40 AM To: 'Megaco (E-mail) Subject: RE: ABNF Question: digit maps embedded in events So, do we agree on the following? eventDM = DigitMapToken ((EQUAL digitMapName ) / (LBRKT digitMapValue RBRKT)) digitMapDescriptor = DigitMapToken EQUAL digitMapName [LBRKT digitMapValue RBRKT] Nurit -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] Sent: Wednesday, June 06, 2001 8:11 PM To: 'Nurit Shenhar'; 'Megaco (E-mail) Subject: RE: ABNF Question: digit maps embedded in events The issue is you should never see a construction like keyword={..} It's always keyword=value{..} or keyword{..} so, you don't want the EQUAL token in EventDM if all you get is a value. Your production should be: eventDM = DigitMapToken ((EQUAL digitMapName ) / (LBRKT digitMapValue RBRKT)) Brian > -----Original Message----- > From: Nurit Shenhar [mailto:nurit.shenhar@audiocodes.com] > Sent: Wednesday, June 06, 2001 11:48 AM > To: 'Megaco (E-mail) > Subject: RE: ABNF Question: digit maps embedded in events > > > Sorry to step in so late, I only now examined this thread. > > We had a discussion once about digit maps, and the conclusion > was that the > first option in the digitMapDescriptor (only value) is > meaningless, and was > left there by mistake. There is no point to program a > termination with an > unnamed digit map, as we won't be able to activate it in the > eventDM... So I > think the correct syntax should be: > > eventDM = DigitMapToken EQUAL (( digitMapName ) / (LBRKT digitMapValue > RBRKT)) > > digitMapDescriptor = DigitMapToken EQUAL digitMapName [LBRKT > digitMapValue > RBRKT] > > Nurit > > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: Friday, June 01, 2001 7:51 PM > To: 'Troy Cauble'; Megaco Mailing List (E-mail) > Subject: RE: ABNF Question: digit maps embedded in events > > > Because it was intended to be symmetric in the beginning, > what is written is incorrect. We have caught and fixed > several of these. When a proposal actually changes what > the original intention/documentation/text vs ABNF(ASN.1) is, > then we defer it. > > Brian > > > -----Original Message----- > > From: Troy Cauble [mailto:troy@lucent.com] > > Sent: Friday, June 01, 2001 11:22 AM > > To: Megaco Mailing List (E-mail) > > Subject: Re: ABNF Question: digit maps embedded in events > > > > > > > > Just curious, but why doesn't this get squashed for > > being an unnecessary change? Nothing's broken except > > the symmetry. > > > > More useful changes have been delayed to v2. > > > > Please treat this as a question, not a complaint! > > Christian, Tom, Brian, et. al. are doing a great job. > > > > -troy > > > > > > Christian Groves wrote: > > > > > > Just in time. I'll add it to the implementors' guide. > > > > > > Christian > > > > > > Tom-PT Taylor wrote: > > > > > > > > Yes, and I suspect I'm the guilty typist. > > > > > > > > > -----Original Message----- > > > > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > > > Sent: Wednesday, May 30, 2001 3:44 PM > > > > > To: 'Steven Weisz'; Megaco Mailing List (E-mail) > > > > > Cc: Taylor, Tom-PT [NORSE:B881:EXCH] > > > > > Subject: RE: ABNF Question: digit maps embedded in events > > > > > > > > > > > > > > > I usually defer to Tom on any digitMap questions. > > > > > I can't tell you how many hours I (and several others > > > > > including Abdullah Rayhan) spent pouring over the > > > > > ABNF to ferret out such problems. > > > > > > > > > > Yes, I agree, it should be > > > > > digitMap={... > > > > > and not > > > > > digitMap{... > > > > > > > > > > I think this qualifies as a typo and deserves an IG entry. > > > > > Tom, do you agree? > > > > > > > > > > Brian > > > > > > > > > > > -----Original Message----- > > > > > > From: Steven Weisz [mailto:sweisz@mediatrix.com] > > > > > > Sent: Wednesday, May 30, 2001 3:08 PM > > > > > > To: Megaco Mailing List (E-mail) > > > > > > Subject: ABNF Question: digit maps embedded in events > > > > > > > > > > > > > > > > > > Hi List, > > > > > > > > > > > > I asked this question a few weeks ago and still have not > > > > > > found an answer. > > > > > > Does anyone have an opinion? > > > > > > > > > > > > It is a quick question concerning a digit map embedded in a > > > > > > requested event. > > > > > > Specifically, if you look at the ABNF the embedded digit map > > > > > > is defined as > > > > > > > > > > > > eventDM = DigitMapToken (( EQUAL digitMapName ) / (LBRKT > > > > > digitMapValue > > > > > > RBRKT)) > > > > > > > > > > > > and a digit map descriptor is defined as: > > > > > > > > > > > > digitMapDescriptor = DigitMapToken EQUAL (( LBRKT > > > > > > digitMapValue RBRKT ) / > > > > > > ( digitMapName [LBRKT > > digitMapValue RBRKT] )) > > > > > > > > > > > > > > > > It obvious that they are very similar, as I believe was > > > > > > intended but there > > > > > > is one thing that is bothering me in eventDM. That is it > > > > > > seems to me that > > > > > > the EQUAL should be right after DigitMapToken as is > > the case in > > > > > > digitMapDescriptor. So we would instead have: > > > > > > > > > > > > eventDM = DigitMapToken EQUAL (( digitMapName ) / (LBRKT > > > > > digitMapValue > > > > > > RBRKT)) > > > > > > > > > > > > Does this make sense? > > > > > > > > > > > > Thanks, > > > > > > > > > > > > Steve > > > > > > > > > > > > > > From owner-megaco@fore.com Fri Jun 8 11:23:09 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14309 for ; Fri, 8 Jun 2001 11:23:08 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA21410; Fri, 8 Jun 2001 11:23:00 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id LAA17501 for megaco-list; Fri, 8 Jun 2001 11:21:38 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA17493 for ; Fri, 8 Jun 2001 11:21:36 -0400 (EDT) Received: from auemail1.firewall.lucent.com (auemail1.lucent.com [192.11.223.161]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA21234 for ; Fri, 8 Jun 2001 11:21:30 -0400 (EDT) Received: from auemail1.firewall.lucent.com (localhost [127.0.0.1]) by auemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f58FLXN05501 for ; Fri, 8 Jun 2001 11:21:33 -0400 (EDT) Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3]) by auemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f58FLXY05491 for ; Fri, 8 Jun 2001 11:21:33 -0400 (EDT) Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id LAA29621; Fri, 8 Jun 2001 11:21:30 -0400 (EDT) Cc: Tom-PT Taylor , "'tla@lucent.com'" , MEGACO list Received: from lucent.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id LAA29588; Fri, 8 Jun 2001 11:21:26 -0400 (EDT) Message-ID: <3B20ECFC.A8C1F9BC@lucent.com> Date: Fri, 08 Jun 2001 11:19:24 -0400 From: Troy Cauble Reply-To: Troy Cauble X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Rosen, Brian" Original-CC: Tom-PT Taylor , "'tla@lucent.com'" , MEGACO list Subject: Re: IG 6.79 "Cancelling Event Detection" breaks ABNF References: <4FBEA8857476D311A03300204840E1CF0446551E@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: 7bit A summary of the problems discussed in this thread. 1) In the text encoding, some empty descriptors have the form "Signals {}" while others have "Events". In a Termination Audit: 2) There are two line encodings for an empty Signals descriptor (text and ASN.1). 3) There are two line encodings each for an empty Events descriptor or Event Buffer descriptor (ASN.1 only). 4) In the text encoding, EventsToken and EventBufferToken each have reduce/reduce conflicts because they can represent either an auditItem token or an empty descriptor in the auditReturnParameter. -troy "Rosen, Brian" wrote: > > I agree with Tom; we did a pass over the ABNF to try to make > all of the empty forms not have braces. The choice was > completely arbitrary, and as I recall, we decided since it > didn't make any real difference, shorter was better. > If we missed one, we goofed. > > Tom, the problem here seems to be real. As Troy says, you will get > a reduce conflict in a rules-based parser with this ambiguity. > I'm pretty sure you can ignore the problem, but it's poor design > practice. You will recall all of the effort Abdallah and Nancy > went through to test out these kinds of things as we developed > the ABNF. The IG change wasn't verified in the same way, thus > we have this problem. We need to decide what to do. > > Brian > > > -----Original Message----- > > From: Troy Cauble [mailto:troy@lucent.com] > > Sent: Thursday, June 07, 2001 6:39 PM > > To: Tom-PT Taylor > > Cc: Rosen, Brian; Christian Groves; MEGACO list > > Subject: Re: IG 6.79 "Cancelling Event Detection" breaks ABNF > > > > > > > Tom-PT Taylor wrote: > > > > > > I'm the one responsible for all this. I suppose I should > > dig up the thread. > > > Anyway, the intention was definitiely to provide a way of > > signalling empty > > > descriptors. I think we chose rather arbitrarily between > > the desc{} and desc > > > form, opting for the latter. > > > > Well, an empty Signals Descriptors already uses desc{}, > > shouldn't we go for the symmetry? Didn't we just change > > the original protocol for symmetry reasons? This would > > be just changing the IG. > > > > -troy > > From owner-megaco@fore.com Fri Jun 8 14:50:34 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA18985 for ; Fri, 8 Jun 2001 14:50:33 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA05157; Fri, 8 Jun 2001 14:50:15 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id OAA29076 for megaco-list; Fri, 8 Jun 2001 14:46:49 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA29072 for ; Fri, 8 Jun 2001 14:46:47 -0400 (EDT) Received: from muninn.ctccom.net (Muninn.CTCCom.net [207.190.194.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA04862 for ; Fri, 8 Jun 2001 14:46:43 -0400 (EDT) Received: from MBRAHMANAPALLY ([64.69.123.121]) by muninn.ctccom.net (Mirapoint) with SMTP id ACX14081; Fri, 8 Jun 2001 14:46:13 -0400 (EDT) From: "Madhu Babu Brahmanapally" To: Subject: Stray RTP/RTCP packets. Date: Fri, 8 Jun 2001 14:47:50 -0400 Message-ID: <013401c0f04b$85098160$c500a8c0@MBRAHMANAPALLY> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: 7bit HI All, I was going through some mails in the SIP list and found the following situation. MG is exchanging traffic with a SIP UA, and due to some reason the UA crashes and comes back, without any knowledge about the earlier sessions. But the UA is receiving so called stray RTP/RTCP packets. Does the MG (which is generating these stray RTP/RTCP packets) after receiving any ICMP errors packets need to react on it??? IMO the MGC has to take necessary action when the other MG/UAs fails?? -Regards Madhubabu From owner-megaco@fore.com Fri Jun 8 15:36:54 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA19721 for ; Fri, 8 Jun 2001 15:36:53 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA08517; Fri, 8 Jun 2001 15:36:41 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id PAA08475 for megaco-list; Fri, 8 Jun 2001 15:35:45 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA08468 for ; Fri, 8 Jun 2001 15:35:43 -0400 (EDT) Received: from zcars0m9.ca.nortel.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA08407 for ; Fri, 8 Jun 2001 15:35:39 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f58JZTE05487 for ; Fri, 8 Jun 2001 15:35:29 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Fri, 8 Jun 2001 15:35:15 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Jun 2001 15:35:26 -0400 Message-ID: <28560036253BD41191A10000F8BCBD110250CC83@zcard00g.ca.nortel.com> From: "Tom-PT Taylor" To: "'Madhu Babu Brahmanapally'" , megaco Subject: RE: Stray RTP/RTCP packets. Date: Fri, 8 Jun 2001 15:35:21 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F052.2826A660" X-Orig: Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0F052.2826A660 Content-Type: text/plain; charset="ISO-8859-1" The context of the original discussion was that the MGC restarted and lost track of the media session. One could say on the one hand that it's up to the MGC to do periodic audits to make sure it is in synch with the MG. On the other hand, I wonder if ICMP could trigger some sort of event back up to the MGC. There might be security issues to consider. -----Original Message----- From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com] Sent: Friday, June 08, 2001 2:48 PM To: megaco Subject: Stray RTP/RTCP packets. HI All, I was going through some mails in the SIP list and found the following situation. MG is exchanging traffic with a SIP UA, and due to some reason the UA crashes and comes back, without any knowledge about the earlier sessions. But the UA is receiving so called stray RTP/RTCP packets. Does the MG (which is generating these stray RTP/RTCP packets) after receiving any ICMP errors packets need to react on it??? IMO the MGC has to take necessary action when the other MG/UAs fails?? -Regards Madhubabu ------_=_NextPart_001_01C0F052.2826A660 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: Stray RTP/RTCP packets.

The context of the original discussion was that the = MGC restarted and lost track of the media session.  One could say = on the one hand that it's up to the MGC to do periodic audits to make = sure it is in synch with the MG.  On the other hand, I wonder if = ICMP could trigger some sort of event back up to the MGC.  There = might be security issues to consider.

-----Original Message-----
From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]<= /FONT>
Sent: Friday, June 08, 2001 2:48 PM
To: megaco
Subject: Stray RTP/RTCP packets.


HI All,
I was going through some mails in the SIP list and = found the following
situation.
MG is exchanging traffic with a SIP UA, and due to = some reason the UA
crashes and comes back, without any knowledge about = the earlier sessions.
But the UA is receiving so called stray RTP/RTCP = packets. Does the MG (which
is generating these stray RTP/RTCP packets) after = receiving any ICMP errors
packets need to react on it??? IMO the MGC has to = take necessary action when
the other MG/UAs fails??

-Regards
Madhubabu

------_=_NextPart_001_01C0F052.2826A660-- From owner-megaco@fore.com Fri Jun 8 16:28:53 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA20289 for ; Fri, 8 Jun 2001 16:28:53 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA12179; Fri, 8 Jun 2001 16:28:46 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id QAA19422 for megaco-list; Fri, 8 Jun 2001 16:27:36 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA19409 for ; Fri, 8 Jun 2001 16:27:34 -0400 (EDT) Received: from zcars0m9.ca.nortel.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA12025 for ; Fri, 8 Jun 2001 16:27:29 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f58KRKE10487 for ; Fri, 8 Jun 2001 16:27:20 -0400 (EDT) Received: from ztcfd004.ca.nortel.com by zcars04f.ca.nortel.com; Fri, 8 Jun 2001 16:27:03 -0400 Received: by ztcfd004.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Jun 2001 16:27:03 -0400 Message-ID: <45D2A43C1913D51180F40000F89CB874062E7F@nrtpde0a.us.nortel.com> From: "Michael Brown" To: "'megaco@fore.com'" Subject: RE: Comments on draft-boyle-megaco-tonepkgs-04.txt Date: Fri, 8 Jun 2001 16:26:59 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F059.5E96CA70" X-Orig: Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0F059.5E96CA70 Content-Type: text/plain; charset="iso-8859-1" Sorry for not having responded earlier to your initial post with this question. The short answer is that there is no plan to provide further definitions of the tones particularly those other than in section 4. In the case of Section 4, it should have the exact same reference as provided in the Call Progress tones package in Annex E and that will be added. Regarding the other tones, they are definitely NOT proprietary, but they are tones which have many possible physical definitions based on market/national and/or enterprise implementation variations. The current tones definitions were derived based on analysis of the mapping of existing market variant tonesets to one another from a functional perspective. It is our belief that since these tones are defined for support of Legacy telephony/services, the functional definitions and the inclusion of the Legacy variant naming used for the tones provides sufficient guidance for the use of them. It was considered inappropriate to try to have these packages attempt to provide exhaustive documentation of all of the possible physical tone variations. This has been corroborated by the feedback we have received over the last year on this draft. I don't agree that this is an interoperability problem issue. The reason is that the tones in these packages should be defined using a MIB. We have submitted a draft proposing such a MIB. The definition of the values contained within it is where the potential variations will be resolved. This does allow the possibility that there could be "non-standard" definitions of the tones, but this would be by the choice of the service provider within the context of their deployment based on guidance provided by the vendor providing the MGC. The MG is irrelevant since it will be provisioned with the tone definitions and will play whatever it's told to play and it is up to the MGC to direct the MG actions appropriately. Regards, Michael Brown -----Original Message----- From: Bill Foster [mailto:bfoster@cisco.com] Sent: Thursday, June 07, 2001 4:53 PM To: Boyle, Kevin [NCRTP:3Z30:EXCH]; Brown, Michael [NC1:GW10:EXCH]; Cornel, Sarah [NCRTP:3J08:EXCH]; Doyle, Stacy [NC1:GW23:EXCH]; Kumar, Mehala [MDN05:SR02:EXCH] Cc: megaco Subject: Comments on draft-boyle-megaco-tonepkgs-04.txt Is there a plan to provide further definitions of tones in later updates? Many of the tones in this document are presently not defined or have no references to public documents. Where a tone is not defined but is associated with a feature, a reference to a public document that describes the feature would help (but obviously a real tone definition would be best). With no reference or definition of any kind, these would appear to be proprietary tones. In some cases, with no definition, interoperability problems may occur. So "low tone" and "high tone" in the diagnostics package may refer to the same "low tone" and "high tone" as described in GR-529-CORE or maybe they are something completely different. Tones in section 4 are evidently from E.180 and E.182 - but that should be stated. Tones in sections 5-6 seem to all have definitions. Tones in other sections should have references or better definitions: Section 7: xferdt, srdt and tones in Sections 8-12. ----------------------------- Bill Foster Phone: (250) 758-9418 Fax: (781) 998-6492 ------_=_NextPart_001_01C0F059.5E96CA70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Comments on draft-boyle-megaco-tonepkgs-04.txt

Sorry for not having responded earlier to your = initial post with this question.

The short answer is that there is no plan to provide = further definitions of the tones particularly those other than in = section 4. In the case of Section 4, it should have the exact same = reference as provided in the Call Progress tones package in Annex E and = that will be added.

Regarding the other tones, they are definitely NOT = proprietary, but they are tones which have many possible physical = definitions based on market/national and/or enterprise implementation = variations. The current tones definitions were derived based on = analysis of the mapping of existing market variant tonesets to one = another from a functional perspective. It is our belief that since = these tones are defined for support of Legacy telephony/services, the = functional definitions and the inclusion of the Legacy variant naming = used for the tones provides sufficient guidance for the use of them. It = was considered inappropriate to try to have these packages attempt to = provide exhaustive documentation of all of the possible physical tone = variations. This has been corroborated by the feedback we have received = over the last year on this draft.

I don't agree that this is an interoperability = problem issue. The reason is that the tones in these packages should be = defined using a MIB. We have submitted a draft proposing such a MIB. = The definition of the values contained within it is where the potential = variations will be resolved. This does allow the possibility that there = could be "non-standard" definitions of the tones, but this = would be by the choice of the service provider within the context of = their deployment based on guidance provided by the vendor providing the = MGC. The MG is irrelevant since it will be provisioned with the tone = definitions and will play whatever it's told to play and it is up to = the MGC to direct the MG actions appropriately.

Regards,

Michael Brown

-----Original Message-----
From: Bill Foster [mailto:bfoster@cisco.com]
Sent: Thursday, June 07, 2001 4:53 PM
To: Boyle, Kevin [NCRTP:3Z30:EXCH]; Brown, Michael = [NC1:GW10:EXCH];
Cornel, Sarah [NCRTP:3J08:EXCH]; Doyle, Stacy = [NC1:GW23:EXCH]; Kumar,
Mehala [MDN05:SR02:EXCH]
Cc: megaco
Subject: Comments on = draft-boyle-megaco-tonepkgs-04.txt


Is there a plan to provide further definitions of = tones in later updates?
Many of the tones in this document are presently not = defined or have no
references to public documents. Where a tone is not = defined but is
associated with a feature, a reference to a public = document that describes
the feature would help (but obviously a real tone = definition would be
best). With no reference or definition of any kind, = these would appear to
be proprietary tones. In some cases, with no = definition, interoperability
problems may occur. So  "low tone" = and "high tone" in the diagnostics
package may refer to the same "low tone" = and "high tone" as described in
GR-529-CORE or maybe they are something completely = different.

Tones in section 4 are evidently from E.180 and E.182 = - but that should be
stated.
Tones in sections 5-6 seem to all have = definitions.
Tones in other sections should have references or = better definitions:
Section 7: xferdt, srdt and tones in Sections = 8-12.

-----------------------------
Bill Foster
Phone: (250) 758-9418
Fax:     (781) 998-6492

------_=_NextPart_001_01C0F059.5E96CA70-- From owner-megaco@fore.com Fri Jun 8 21:33:31 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA22824 for ; Fri, 8 Jun 2001 21:33:26 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id VAA23170; Fri, 8 Jun 2001 21:32:57 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id VAA20281 for megaco-list; Fri, 8 Jun 2001 21:26:24 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id VAA20266 for ; Fri, 8 Jun 2001 21:26:15 -0400 (EDT) Received: from mail.newmail.ru (async208-mar-isp-1.nas.one.net.au [61.12.75.209]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id VAA22981 for ; Fri, 8 Jun 2001 21:25:58 -0400 (EDT) Received: (from nobody@localhost) by mail.newmail.ru (8.9.3/8.9.3) id LAA15148; Sat, 9 Jun 2001 11:21:42 +1000 Date: Sat, 9 Jun 2001 11:21:42 +1000 Message-Id: <200106090121.LAA15148@mail.newmail.ru> From: freevac8@turbomail.net Subject: Complimentary Disney Area Vacation xfmjr Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Congratulations! You will be our guest in Orlando, Florida, home of Walt Disney World, for 4 days and 3 nights. All compliments of major Vacation Resort Developers. Click here>>> http://www.fasthostnow.net/freevacations CLAIM YOUR GIFT Your Complimentary Vacation Package Includes: 3 Nights Resort Hotel Accommodations...PLUS 2 Adult Admissions to Disney's Pleasure Island Attraction...PLUS $500.00 Discount Coupon Book...PLUS Round Trip Transportation between your Hotel and Disney World, Epcot, and Animal Kingdom. You Must Qualify - Now. Click here>>> http://www.fasthostnow.net/freevacations CLAIM YOUR GIFT To be removed from future mailings please visit http://www.fasthostnow.net/freevacations/remove.html From owner-megaco@fore.com Fri Jun 8 21:53:46 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA23847 for ; Fri, 8 Jun 2001 21:53:46 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id VAA23745; Fri, 8 Jun 2001 21:53:03 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id VAA21279 for megaco-list; Fri, 8 Jun 2001 21:49:12 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id VAA21275 for ; Fri, 8 Jun 2001 21:49:11 -0400 (EDT) Received: from mail.siemenscom.com (mail.siemenscom.com [206.154.192.2]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id VAA23614 for ; Fri, 8 Jun 2001 21:49:01 -0400 (EDT) Received: from pobox.rolm.com (gate.siemenscom.com [206.154.192.3]) by mail.siemenscom.com (8.9.3/8.9.3) with ESMTP id SAA02339 for ; Fri, 8 Jun 2001 18:39:34 -0700 (PDT) Received: from stca200a.bus.sc.rolm.com by pobox.rolm.com with ESMTP for megaco@fore.com; Fri, 8 Jun 2001 18:49:02 -0700 Received: by stca200a.bus.sc.rolm.com with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Jun 2001 18:58:00 -0700 Message-Id: From: "Nierhaus, Florian" To: "'megaco@fore.com'" Subject: Selecting Codecs with dynamic RTP Payload Type Date: Fri, 8 Jun 2001 18:48:59 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Hi, I want to add a Termination and select GSM EFR as codec. Can someone tell me what is the correct way to do this? The Payload Type for GSM EFR is dynamic. ACodec seems to only support ITU codecs. Thanks, Florian Nierhaus From owner-megaco@fore.com Sat Jun 9 02:00:49 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA00926 for ; Sat, 9 Jun 2001 02:00:48 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id CAA27726; Sat, 9 Jun 2001 02:00:13 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id BAA01355 for megaco-list; Sat, 9 Jun 2001 01:54:20 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id BAA01346; Sat, 9 Jun 2001 01:54:12 -0400 (EDT) From: lush@atantech.com.tw Received: from natproxy.ferntree.com.au (newproxy.gecits-ap.com [203.12.79.21]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id BAA27530; Sat, 9 Jun 2001 01:53:50 -0400 (EDT) Received: by natproxy.ferntree.com.au; id PAA05817; Sat, 9 Jun 2001 15:57:10 +1000 (EST) Message-Id: <200106090557.PAA05817@natproxy.ferntree.com.au> Received: from slip129-37-78-209.ny.us.prserv.net(129.37.78.209) by natproxy.ferntree.com.au via smap (4.1) id xmarc3460; Sat, 9 Jun 01 15:56:22 +1000 Received: from sy@erolson.ca by mike@exeter.ca (8.8.5/8.6.5) with SMTP id GAA00002 for ; Fri, 08 Jun 2001 12:03:16 -0600 (EST) To: exeter.ca@ferntree.com.au Date: Fri, 08 Jun 01 12:03:16 EST Subject: come on in Comments: Authenticated sender is Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Does Tight Little Pussies - Turn you on?? Welcome To The premiere Porn Site On The Web. Guaranteed !!!!!! -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- http://209.195.63.163/nasty2/2/index.html Try us for 3 days at only $2.99 Hardcore-Sex-Feeds Whats YOU!! Get With your Membership 24hr Live Fucking 7 Days per Week Now Boasting over 100,000 Hell Hardcore XXX-Feeds Cunt Pumping Pictorials ( Now over 800,000 ) All the Latest Updated Porn Voyuer Cams Galore upskirt-pussy cam- dildo cam-toilet cam-dressing room cam- dorm cam-oncampus cam-shower cam-hot Tub cam -tanning cam and more. 11,000+ Fucked up Sex Stories Virgins first Time Barely 18, Vacations, Sex at Work, Gay, Wierd, you name it Hardcore-Sex-Feeds Has it. XXX-Games ( Interactive ) Online Dating ( Find your Wife a Slut to Eat Her Smelly Hole ) http://209.195.63.163/nasty2/2/index.html For your ultimate pleasure: cum join!!!!!!!!!!!!!!!!!!!!!! From owner-megaco@fore.com Sun Jun 10 01:01:42 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA24883 for ; Sun, 10 Jun 2001 01:01:42 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id BAA12136; Sun, 10 Jun 2001 01:01:35 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id AAA09729 for megaco-list; Sun, 10 Jun 2001 00:56:22 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id AAA09725 for ; Sun, 10 Jun 2001 00:56:20 -0400 (EDT) Received: from exchange_server.dlfesco.com ([203.87.254.194]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id AAA12033 for ; Sun, 10 Jun 2001 00:56:12 -0400 (EDT) Message-Id: <200106100456.AAA12033@mailgate.pit.comms.marconi.com> Received: from plain (61.153.120.70 [61.153.120.70]) by exchange_server.dlfesco.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3) id MH3KM1R3; Sun, 10 Jun 2001 12:52:04 +0800 From: John To: megalomaniac127@go.com Subject: CONGRATULATIONS !!! YOU WON !! Time:12:57:44 Date: Sun, 10 Jun 2001 12:57:44 Mime-Version: 1.0 Content-Type: text/plain; charset="DEFAULT_CHARSET" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk YOUR FREE MEMBERSHIP!! CHECK IT OUT! The Fastest Way To Earn $2000+ EVERY Month Online !!! Looking for a secure and legitimate online home business? One that WILL bring steady, dependable monthly checks EVERY month and in the shortest amount of time ?? We can share with you a way to earn $1000's per month on the Internet and receive GUARANTEED monthly checks that will continue to grow. No Hype Here ! - We Can PROVE It !! Free To Join - Means Instant Growth ! Can YOU give away FREE memberships? Most Certainly !! All day long in fact, AND earn an explosive income in doing so ! No pre-launch here! Four year old company with proven system - that works !! Making money on the Internet has never been EASIER ! Join Free and get your own free web site where you can watch your downline grow before your eyes !! Check it daily then you decide !! See why thousands of people from all over the world are joining - FREE ! Lock in Your Position Today and we'll also give you promotional software that will increase traffic to ANY web site !! See for Yourself ! Grab your ID Here ! DON"T MISS OUT !! http://65.197.20.145/dhsc_1/d.html --------------------------------------------------------- --------------------- -------- This is a one time mailing and you will not be contacted again and though it is not necessary to request removal, you may do so by sending an email to: mailto:nodice4@excite.com?subject=Please_Remove From owner-megaco@fore.com Sun Jun 10 13:14:59 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12123 for ; Sun, 10 Jun 2001 13:14:59 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA19024; Sun, 10 Jun 2001 13:10:08 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id NAA28383 for megaco-list; Sun, 10 Jun 2001 13:06:53 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA28376 for ; Sun, 10 Jun 2001 13:06:51 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA18910 for ; Sun, 10 Jun 2001 13:06:49 -0400 (EDT) Received: from mira-sjc5-1.cisco.com (mira-sjc5-1.cisco.com [171.71.163.15]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f5AH5EF29291; Sun, 10 Jun 2001 10:05:15 -0700 (PDT) Received: from BFOSTER-W2K.cisco.com (sjc-vpn-325.cisco.com [10.21.65.69]) by mira-sjc5-1.cisco.com (Mirapoint) with ESMTP id AAU44979; Sun, 10 Jun 2001 10:06:47 -0700 (PDT) Message-Id: <4.3.2.7.2.20010610095331.020eb348@mira-sjc5-1.cisco.com> X-Sender: bfoster@mira-sjc5-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 10 Jun 2001 10:02:06 -0700 To: "Michael Brown" From: Bill Foster Subject: RE: Comments on draft-boyle-megaco-tonepkgs-04.txt Cc: "'megaco@fore.com'" In-Reply-To: <45D2A43C1913D51180F40000F89CB874062E7F@nrtpde0a.us.nortel. com> Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Fair enough, but  a clearer definition of what the tone is used for in some cases would help. Some of us may be able to nod our heads knowingly when we see a tone called "faint tone" in a package called "diagnostics package" but many others will be left scratching their heads. Given that you can re-define the tone as anything you want, I can see your point - but it's always possible to carry that idea too far.

At 04:26 PM 6/8/2001 -0400, Michael Brown wrote:

Sorry for not having responded earlier to your initial post with this question.

The short answer is that there is no plan to provide further definitions of the tones particularly those other than in section 4. In the case of Section 4, it should have the exact same reference as provided in the Call Progress tones package in Annex E and that will be added.

Regarding the other tones, they are definitely NOT proprietary, but they are tones which have many possible physical definitions based on market/national and/or enterprise implementation variations. The current tones definitions were derived based on analysis of the mapping of existing market variant tonesets to one another from a functional perspective. It is our belief that since these tones are defined for support of Legacy telephony/services, the functional definitions and the inclusion of the Legacy variant naming used for the tones provides sufficient guidance for the use of them. It was considered inappropriate to try to have these packages attempt to provide exhaustive documentation of all of the possible physical tone variations. This has been corroborated by the feedback we have received over the last year on this draft.

I don't agree that this is an interoperability problem issue. The reason is that the tones in these packages should be defined using a MIB. We have submitted a draft proposing such a MIB. The definition of the values contained within it is where the potential variations will be resolved. This does allow the possibility that there could be "non-standard" definitions of the tones, but this would be by the choice of the service provider within the context of their deployment based on guidance provided by the vendor providing the MGC. The MG is irrelevant since it will be provisioned with the tone definitions and will play whatever it's told to play and it is up to the MGC to direct the MG actions appropriately.

Regards,

Michael Brown

-----Original Message-----
From: Bill Foster [mailto:bfoster@cisco.com]
Sent: Thursday, June 07, 2001 4:53 PM
To: Boyle, Kevin [NCRTP:3Z30:EXCH]; Brown, Michael [NC1:GW10:EXCH];
Cornel, Sarah [NCRTP:3J08:EXCH]; Doyle, Stacy [NC1:GW23:EXCH]; Kumar,
Mehala [MDN05:SR02:EXCH]
Cc: megaco
Subject: Comments on draft-boyle-megaco-tonepkgs-04.txt

Is there a plan to provide further definitions of tones in later updates?
Many of the tones in this document are presently not defined or have no
references to public documents. Where a tone is not defined but is
associated with a feature, a reference to a public document that describes
the feature would help (but obviously a real tone definition would be
best). With no reference or definition of any kind, these would appear to
be proprietary tones. In some cases, with no definition, interoperability
problems may occur. So  "low tone" and "high tone" in the diagnostics
package may refer to the same "low tone" and "high tone" as described in
GR-529-CORE or maybe they are something completely different.

Tones in section 4 are evidently from E.180 and E.182 - but that should be
stated.
Tones in sections 5-6 seem to all have definitions.
Tones in other sections should have references or better definitions:
Section 7: xferdt, srdt and tones in Sections 8-12.

-----------------------------
Bill Foster
Phone: (250) 758-9418
Fax:     (781) 998-6492

-----------------------------
Bill Foster
Phone: (250) 758-9418
Fax:     (781) 998-6492 From owner-megaco@fore.com Sun Jun 10 22:02:25 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA16522 for ; Sun, 10 Jun 2001 22:02:25 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id VAA25920; Sun, 10 Jun 2001 21:57:43 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id VAA15852 for megaco-list; Sun, 10 Jun 2001 21:52:51 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id VAA15848 for ; Sun, 10 Jun 2001 21:52:49 -0400 (EDT) Received: from zcars0m9.ca.nortel.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id VAA25746 for ; Sun, 10 Jun 2001 21:52:43 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f5B1qSE13041 for ; Sun, 10 Jun 2001 21:52:28 -0400 (EDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.ca.nortel.com; Sun, 10 Jun 2001 21:52:29 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Sun, 10 Jun 2001 21:52:30 -0400 Message-ID: <28560036253BD41191A10000F8BCBD110250CC9A@zcard00g.ca.nortel.com> From: "Tom-PT Taylor" To: "'Nierhaus, Florian'" , "'megaco@fore.com'" Cc: "'itu-sg16@mailbag.intel.com'" Subject: RE: Selecting Codecs with dynamic RTP Payload Type Date: Sun, 10 Jun 2001 21:52:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F219.2AE07070" X-Orig: Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0F219.2AE07070 Content-Type: text/plain; charset="ISO-8859-1" I assume you're talking about Megaco/H.248 with binary encoding. This is an interesting issue -- you may have to an object identifier after the fashion of H.245, or we'll have to extend the range of acodec. I'm passing this one on to the SG 16 list for comment. -----Original Message----- From: Nierhaus, Florian [mailto:Florian.Nierhaus@icn.siemens.com] Sent: Friday, June 08, 2001 9:49 PM To: 'megaco@fore.com' Subject: Selecting Codecs with dynamic RTP Payload Type Hi, I want to add a Termination and select GSM EFR as codec. Can someone tell me what is the correct way to do this? The Payload Type for GSM EFR is dynamic. ACodec seems to only support ITU codecs. Thanks, Florian Nierhaus ------_=_NextPart_001_01C0F219.2AE07070 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: Selecting Codecs with dynamic RTP Payload Type

I assume you're talking about Megaco/H.248 with = binary encoding.  This is an interesting issue -- you may have to = an object identifier after the fashion of H.245, or we'll have to = extend the range of acodec.  I'm passing this one on to the SG 16 = list for comment.

-----Original Message-----
From: Nierhaus, Florian [mailto:Florian.Nierhaus= @icn.siemens.com]
Sent: Friday, June 08, 2001 9:49 PM
To: 'megaco@fore.com'
Subject: Selecting Codecs with dynamic RTP Payload = Type


Hi,

I want to add a Termination and select GSM EFR as = codec. Can someone tell me
what is the correct way to do this?

The Payload Type for GSM EFR is dynamic.
ACodec seems to only support ITU codecs.


Thanks,
 Florian Nierhaus

------_=_NextPart_001_01C0F219.2AE07070-- From owner-megaco@fore.com Mon Jun 11 08:25:33 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA08031 for ; Mon, 11 Jun 2001 08:25:33 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA11388; Mon, 11 Jun 2001 08:21:31 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id IAA04025 for megaco-list; Mon, 11 Jun 2001 08:16:53 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA04014 for ; Mon, 11 Jun 2001 08:16:51 -0400 (EDT) Received: from zcars0m9.ca.nortel.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA11088 for ; Mon, 11 Jun 2001 08:16:51 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f5BCGdE00132 for ; Mon, 11 Jun 2001 08:16:39 -0400 (EDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.ca.nortel.com; Mon, 11 Jun 2001 08:16:44 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Jun 2001 08:16:45 -0400 Message-ID: <28560036253BD41191A10000F8BCBD110250CC9E@zcard00g.ca.nortel.com> From: "Tom-PT Taylor" To: "'megaco'" Subject: Study Group 16 Meeting Results Date: Mon, 11 Jun 2001 08:16:40 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) X-Orig: Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk The following extracts come from meeting report of the Study Group 16 meeting just concluded. The complete report may be found at http://standard.pictel.com/ftp/avc-site/0105_Por/WP2_Report_010608.zip I will be updating the Megaco FTP site with copies of the relevant documents. ----- 3.7.2.2 H.248 3.7.2.2.1 D130: Proposed Implementor's Guide for the H.248 Series [Ericsson] Remove proposed section 6.82 as consensus does not seem to exist for this change at this time since sufficient time has not passed to collect comments. The final IG for approval appears in TD15/PLEN. 3.7.2.2.2 TD41/WP2: Communication from the Chairman IETF Megaco Working Group on Descriptors For Megaco/H.248 Annex C Properties [IETF MEGACO] The clarifications proposed in TD41 are beneficial and should be documented. However, it is felt that a specific proposal should be presented to the Megaco mail list to allow time for implementers to comment on the changes. This should be targeted for either V2 or the next implementer's guide. Any proposal to deprecate code points should be accompanied with a package that would allow setting these properties in the MG, unless the property in Annex C is truly unused. No new Annex C codepoints will be added until this issue is resolved. ........ 3.7.3.3 H.248 V2 3.7.3.3.1 D93: Handling of multiple pending transactions in H.248 [Ericsson] There were no objections to this proposal - it was accepted for H.248 V2. The new error code will not appear in Annex L which is up for consent at this meeting - it will appear later (possibly in an implementer's guide). 3.7.3.3.2 D129: Extendable Context Properties for H.248 v2 [Ericsson] There were no objections to this proposal - it was accepted to H.248 V2. There is a possibility that the context property could benefit from the "reserve group" or "reserve value" semantics. 3.7.3.3.3 TD31/WP2: Recommendation H.248(V2) [editor] There are no changes to V2 since the Launceston meeting. The current plan is to present V2 for consent at the next SG16 meeting (around February 2002). Delegates are encouraged to review V2 in detail. 3.7.3.3.4 TD84/WP2: Recommendation H.248 V2 [editor] TD84 is the latest draft of H.248 V2 including the additions approved at this meeting. TD84 was not reviewed since the material added was approved. Delegates are strongly encouraged to review TD84 before the next meeting and to prepare comments. 3.7.3.4 H.248 Annex L 3.7.3.4.1 D128: H.248 Annex L - Error Codes and Service Change Reason Description [Ericsson] There was some discussion about the need for Annex L to cover cases such as where a piece of equipment (for example, an analog line or a BRI station) is not connected or is not powered. The feeling is that this case could be interpreted appropriately by the MGC and the appropriate cause value sent along. Also, specific faults can be covered in error codes defined in packages that describe the special behavior. There were no objections to moving Annex L forward for AAP. The final text appears in TD14/PLEN. 3.7.3.5 H.248 Annex M.1 There were no contributions for Annex M.1. Annex M.1 is currently in an unfinished state. 3.7.3.6 H.248 Annex M.2 3.7.3.6.1 D131: H.248 Annex M.2, Congestion Handling Package [Ericsson] There was comment that the name might be confusing (there may be other packages related to congestion control). The name will be changed to "Media Gateway Resource Congestion Handling" package to attempt to avoid confusion. There were no other objections - Annex M.2 will be moved for approval at this meeting. The final text appears in TD16/PLEN. 3.7.3.7 H.248 Annex M.3 3.7.3.7.1 TD38/WP2: H.248 Packages For Transmission Of Data Over Analog Lines [editor] TD38 indicates that the proposed package M.3 has been withdrawn as it was merged with an IETF proposal. The IETF draft appears in TD38. The IETF proposal has not yet gone for working group last call. 3.7.3.8 H.248 Annex M.4 3.7.3.8.1 D108: Multimedia Support Using the Decomposed H.323/H.3XX Gateway Architecture [Lucent] D108 was presented to provide information and justification for the approach taken in Annex M.4. There were no comments on this material. 3.7.3.8.2 D127: Proposal for the new Annex M.4/H.248 [NTT DoCoMo] Comments from delegates included: · Section 4.4 - what are units for MUXPDU sent? (count?) · Section 4.1.5 - "octet strings" should be "octet string" · Section 5.2 - should this be an event? Seems OK as a property - consider rewording explanation · Section 5.1.2 - check heading numbering - also, need to define "possible values" · Section 5.5 - text needed to define procedures · Section 6 - need to defined possible values, procedures · Binary tags needed for several items (e.g., package Ids) There is no objection to add this material into M.4, provided the editorial comments above are addressed. 3.7.3.8.3 TD39/WP2: Draft Annex M.4 to H.248 [editor] Comments from delegates included: · Need units for "count" · Need binary tags · M.4.4.2.1 - need to add text describing how to select subsets - is length needed in observed events descriptor parameters · M.4.5.2 - need to explain better the circumstances under which and MG makes the decision to open a separate H.245 channel · Mr. Taylor believes we need to resolve the principle of how to determine whether a given property applies to local/remote vs. local control (and possibly termination state). TD72r1/WP2 is the updated M.4 containing changes to address these comments and the incorporation of D127. Editor C. Sayre has requested package identifier values from IANA, but has not yet heard a reply. There were no comments or objections to moving M.4 forward for consent and approval via AAP. The final test appears in TD41/PLEN. 3.7.4 New Supplement to H.248 to Capture Package Work 3.7.4.1 TD76/WP2: H SERIES Supplement 2 : H.248 Packages Guide Release 1 [editor] This supplement was reviewed with no comment on its content. Therefore, this supplement is considered ready to publish. The final text appears in TD26/PLEN. ...... 3.7.5.2 New Packages for H.248 3.7.5.2.1 D109: Basic H.248 Packages for Support of External Signal Sources [Avaya] Comments from delegates: · Does not seem to fit H.248's intent · Need more information on scenarios, architecture D109 was not accepted as the basis for a standard package at this time. A better explanation is needed to justify this proposal. 3.7.5.2.2 D156: Requirements for H.248 Load Control Package - Aggregate Bearer [Israel] Comments from delegates included: · Do these requirements primarily define the operation of the ABAC? These are background for basic requirements of the package. · Can media types be mixed within aggregate bearer? If so, what is a proposal for QoS parameters? Could define aggregate with most stringent QoS parameters, then allow multiple media types within that aggregate bearer. But, it would be simpler to put each media type in its own aggregate bearer. Requirements do not disallow the use of separate aggregate bearer for each media type. Don't understand how to request different QoS parameters for media streams within an aggregate bearer. · A similar proposal was accepted in principal at last Tiphon meeting, but not enough time to close on bandwidth reports. · It would be nice to see the requirements captured in the actual package text. · Should consider review of architectural implications in Q.B, and also in Q.F. The requirements detailed in D156 should appear in the package text to provide a better understanding of the package. 3.7.5.2.3 D157: Improved H.248 Load Control for Aggregate Bearer [Israel] There were no objections to the items proposed in D157. Proponents of the aggregate bearer control are expected to produce the packages for review at future meetings. From owner-megaco@fore.com Mon Jun 11 10:34:58 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11768 for ; Mon, 11 Jun 2001 10:34:53 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA23586; Mon, 11 Jun 2001 10:30:13 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA09665 for megaco-list; Mon, 11 Jun 2001 10:28:38 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA09634 for ; Mon, 11 Jun 2001 10:28:34 -0400 (EDT) Received: from zcars0m9.ca.nortel.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA23415 for ; Mon, 11 Jun 2001 10:28:33 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f5BESLE24755 for ; Mon, 11 Jun 2001 10:28:21 -0400 (EDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.ca.nortel.com; Mon, 11 Jun 2001 10:28:06 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Jun 2001 10:28:07 -0400 Message-ID: <28560036253BD41191A10000F8BCBD110250CCA4@zcard00g.ca.nortel.com> From: "Tom-PT Taylor" To: "'megaco'" Subject: Meeting In August Date: Mon, 11 Jun 2001 10:28:00 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) X-Orig: Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Megaco will meet in August. We should be thinking about open issues to cover in that meeting. I'll go out on a limb and suggest we will also have a new charter to flesh out. We should be forming a consensus on what packages we want to include as WG work items. Tom Taylor From owner-megaco@fore.com Mon Jun 11 13:57:02 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15982 for ; Mon, 11 Jun 2001 13:57:01 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA11156; Mon, 11 Jun 2001 13:52:17 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id NAA02805 for megaco-list; Mon, 11 Jun 2001 13:50:11 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA02786 for ; Mon, 11 Jun 2001 13:50:08 -0400 (EDT) Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA10916 for ; Mon, 11 Jun 2001 13:50:07 -0400 (EDT) Received: from auemail2.firewall.lucent.com (localhost [127.0.0.1]) by auemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5BHo8R17967 for ; Mon, 11 Jun 2001 13:50:08 -0400 (EDT) Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3]) by auemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5BHo8w17953 for ; Mon, 11 Jun 2001 13:50:08 -0400 (EDT) Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id NAA09726; Mon, 11 Jun 2001 13:50:05 -0400 (EDT) Received: from lucent.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id NAA09722; Mon, 11 Jun 2001 13:50:05 -0400 (EDT) Message-ID: <3B250453.538C2359@lucent.com> Date: Mon, 11 Jun 2001 13:48:03 -0400 From: Troy Cauble Reply-To: Troy Cauble X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: MEGACO list Subject: ASN.1: extraInfo OPTIONAL Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: 7bit The sub-object below is used in 3 places in the ASN.1 spec., EventParameter, SigParameter, and PropertyParm. extraInfo CHOICE { relation Relation, range BOOLEAN, sublist BOOLEAN } OPTIONAL, The fact that the whole object is optional is hard to align with the text encoding. What relationship is implied when no extra info is sent? Also, why was this so complicated anyway? extraInfo is a CHOICE of an ENUMERATED or one of two BOOLEANs. Why wasn't it all just an ENUMERATED? -troy From owner-megaco@fore.com Mon Jun 11 16:04:30 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17931 for ; Mon, 11 Jun 2001 16:04:25 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA20549; Mon, 11 Jun 2001 15:59:37 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id PAA03174 for megaco-list; Mon, 11 Jun 2001 15:57:26 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA03159 for ; Mon, 11 Jun 2001 15:57:24 -0400 (EDT) Received: from mail.mediatrix.com (mail.mediatrix.com [205.237.248.11]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA20316 for ; Mon, 11 Jun 2001 15:57:21 -0400 (EDT) Received: from PLEMAY (core1.premierstratatech.com [64.254.4.66]) by mail.mediatrix.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id MK7DM4A3; Mon, 11 Jun 2001 15:52:33 -0400 Reply-To: From: "Paul Lemay" To: Subject: Reply Errors Date: Mon, 11 Jun 2001 15:54:40 -0400 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: 7bit Hello there, Given a Mg that receives a transaction having 1 Action and 3 commands: Transaction (T1) Action (A1) Command (C1) Command (C2) Command (C3) Let say that the parsing went Ok and, an execution error occurs for C2. The Mg reply will show an Error for C2. But what about the Action A1 and Transaction T1? Is the Mg going to reply that the Transaction has no error and the action has no error? Thanks in advance. Paul Lemay ----------------------------------------- Concepteur Logiciel Mediatrix Telecom, Inc. plemay@Mediatrix.com From owner-megaco@fore.com Mon Jun 11 16:29:09 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18402 for ; Mon, 11 Jun 2001 16:29:09 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA22408; Mon, 11 Jun 2001 16:24:31 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id QAA10038 for megaco-list; Mon, 11 Jun 2001 16:23:50 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA10030 for ; Mon, 11 Jun 2001 16:23:49 -0400 (EDT) Received: from zcars0m9.ca.nortel.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA22300 for ; Mon, 11 Jun 2001 16:23:47 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f5BKNaE23437 for ; Mon, 11 Jun 2001 16:23:37 -0400 (EDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.ca.nortel.com; Mon, 11 Jun 2001 16:23:35 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Jun 2001 16:23:37 -0400 Message-ID: <28560036253BD41191A10000F8BCBD110250CCB4@zcard00g.ca.nortel.com> From: "Tom-PT Taylor" To: "'plemay'" , megaco Subject: RE: Reply Errors Date: Mon, 11 Jun 2001 16:23:31 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F2B4.618EFDD0" X-Orig: Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0F2B4.618EFDD0 Content-Type: text/plain; charset="ISO-8859-1" The MG places one error descriptor at the end of the transaction response. That error descriptor applies to C2. Assuming context A1 was created by C1 or continues to exist despite C1, the response would report the contextID for A1 and the result of C1 as well. There is no transactionSuccess response as such, just a transaction result response, and similarly at the action level. -----Original Message----- From: Paul Lemay [mailto:plemay@mediatrix.com] Sent: Monday, June 11, 2001 3:55 PM To: megaco Subject: Reply Errors Hello there, Given a Mg that receives a transaction having 1 Action and 3 commands: Transaction (T1) Action (A1) Command (C1) Command (C2) Command (C3) Let say that the parsing went Ok and, an execution error occurs for C2. The Mg reply will show an Error for C2. But what about the Action A1 and Transaction T1? Is the Mg going to reply that the Transaction has no error and the action has no error? Thanks in advance. Paul Lemay ----------------------------------------- Concepteur Logiciel Mediatrix Telecom, Inc. plemay@Mediatrix.com ------_=_NextPart_001_01C0F2B4.618EFDD0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: Reply Errors

The MG places one error descriptor at the end of the = transaction response.  That error descriptor applies to C2.  = Assuming context A1 was created by C1 or continues to exist despite C1, = the response would report the contextID for A1 and the result of C1 as = well.  There is no transactionSuccess response as such, just a = transaction result response, and similarly at the action = level.

-----Original Message-----
From: Paul Lemay [mailto:plemay@mediatrix.com]
Sent: Monday, June 11, 2001 3:55 PM
To: megaco
Subject: Reply Errors


Hello there,

Given a Mg that receives a transaction having 1 = Action and 3 commands:

Transaction (T1)
   Action (A1)
      Command (C1)
      Command (C2)
      Command (C3)

Let say that the parsing went Ok and, an execution = error occurs for C2. The
Mg reply will show an Error for C2. But what about = the Action A1 and
Transaction T1? Is the Mg going to reply that the = Transaction has no error
and the action has no error?

Thanks in advance.

Paul Lemay
-----------------------------------------
Concepteur Logiciel
Mediatrix Telecom, Inc.
plemay@Mediatrix.com

------_=_NextPart_001_01C0F2B4.618EFDD0-- From owner-megaco@fore.com Tue Jun 12 05:55:03 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11329 for ; Tue, 12 Jun 2001 05:55:03 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id FAA18301; Tue, 12 Jun 2001 05:50:32 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id FAA18757 for megaco-list; Tue, 12 Jun 2001 05:47:02 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id FAA18753 for ; Tue, 12 Jun 2001 05:47:00 -0400 (EDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id FAA18115 for ; Tue, 12 Jun 2001 05:46:59 -0400 (EDT) Received: from mira-sjc5-1.cisco.com (mira-sjc5-1.cisco.com [171.71.163.15]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f5C9l7U22823; Tue, 12 Jun 2001 02:47:07 -0700 (PDT) Received: from BFOSTER-W2K.cisco.com (sjc-vpn-tmp35.cisco.com [10.21.64.35]) by mira-sjc5-1.cisco.com (Mirapoint) with ESMTP id AAU81037; Tue, 12 Jun 2001 02:46:58 -0700 (PDT) Message-Id: <4.3.2.7.2.20010612021227.04032ab8@mira-sjc5-1.cisco.com> X-Sender: bfoster@mira-sjc5-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 12 Jun 2001 02:42:15 -0700 To: "Michael Brown" From: Bill Foster Subject: RE: Comments on draft-boyle-megaco-tonepkgs-04.txt Cc: "'megaco@fore.com'" In-Reply-To: <45D2A43C1913D51180F40000F89CB874062E7F@nrtpde0a.us.nortel. com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk I apologize for not providing feedback earlier. I'm not sure what is meant by "mapping of existing market variant tonesets to one another from a functional perspective means". Many of the tones in sections 7 to 12 as presently undefined are generally useless to the community at large. The fact that any tone can be re-mapped to anything else using a MIB, does not absolve you from providing default tone definitions with some reasonable description of tone usage. References to existing definitions and usage only help. If in order for a service provider to unplug MGC A and replace it with MGC B, they have to completely re-provision all their tone definitions, then there is something wrong. If you carry this idea to the extreme then there is no point in providing package and tone names at all - just have available a collection of package ID's and tone ID's for anyone to use as they will. My case in point was the "low" and "high" tones in the "diagnostic" package. Either this refers to "low" tone and high "tone" in GR-729-CORE - or it refers to some other tones described somewhere else, or these tones are totally undefined. As far as I can tell "low" and "high" tones in GR-729-CORE are not diagnostic tones unless the definition of "diagnostic" is so broad as to be totally meaningless. In that case the package name does nothing to clarify the other tone names like "faint" tone and "loud" tone in that package. Exhaustive documentation may not be required, but some reasonable amount of documentation is. At 04:26 PM 6/8/2001 -0400, Michael Brown wrote: >Sorry for not having responded earlier to your initial post with this >question. > >The short answer is that there is no plan to provide further definitions >of the tones particularly those other than in section 4. In the case of >Section 4, it should have the exact same reference as provided in the Call >Progress tones package in Annex E and that will be added. > >Regarding the other tones, they are definitely NOT proprietary, but they >are tones which have many possible physical definitions based on >market/national and/or enterprise implementation variations. The current >tones definitions were derived based on analysis of the mapping of >existing market variant tonesets to one another from a functional >perspective. It is our belief that since these tones are defined for >support of Legacy telephony/services, the functional definitions and the >inclusion of the Legacy variant naming used for the tones provides >sufficient guidance for the use of them. It was considered inappropriate >to try to have these packages attempt to provide exhaustive documentation >of all of the possible physical tone variations. This has been >corroborated by the feedback we have received over the last year on this draft. > >I don't agree that this is an interoperability problem issue. The reason >is that the tones in these packages should be defined using a MIB. We have >submitted a draft proposing such a MIB. The definition of the values >contained within it is where the potential variations will be resolved. >This does allow the possibility that there could be "non-standard" >definitions of the tones, but this would be by the choice of the service >provider within the context of their deployment based on guidance provided >by the vendor providing the MGC. The MG is irrelevant since it will be >provisioned with the tone definitions and will play whatever it's told to >play and it is up to the MGC to direct the MG actions appropriately. > >Regards, > >Michael Brown > >-----Original Message----- >From: Bill Foster >[mailto:bfoster@cisco.com] >Sent: Thursday, June 07, 2001 4:53 PM >To: Boyle, Kevin [NCRTP:3Z30:EXCH]; Brown, Michael [NC1:GW10:EXCH]; >Cornel, Sarah [NCRTP:3J08:EXCH]; Doyle, Stacy [NC1:GW23:EXCH]; Kumar, >Mehala [MDN05:SR02:EXCH] >Cc: megaco >Subject: Comments on draft-boyle-megaco-tonepkgs-04.txt > >Is there a plan to provide further definitions of tones in later updates? >Many of the tones in this document are presently not defined or have no >references to public documents. Where a tone is not defined but is >associated with a feature, a reference to a public document that describes >the feature would help (but obviously a real tone definition would be >best). With no reference or definition of any kind, these would appear to >be proprietary tones. In some cases, with no definition, interoperability >problems may occur. So "low tone" and "high tone" in the diagnostics >package may refer to the same "low tone" and "high tone" as described in >GR-529-CORE or maybe they are something completely different. > >Tones in section 4 are evidently from E.180 and E.182 - but that should be >stated. >Tones in sections 5-6 seem to all have definitions. >Tones in other sections should have references or better definitions: >Section 7: xferdt, srdt and tones in Sections 8-12. > >----------------------------- >Bill Foster >Phone: (250) 758-9418 >Fax: (781) 998-6492 ----------------------------- Bill Foster Phone: (250) 758-9418 Fax: (781) 998-6492 From owner-megaco@fore.com Tue Jun 12 06:17:00 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11395 for ; Tue, 12 Jun 2001 06:17:00 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id FAA18808; Tue, 12 Jun 2001 05:58:25 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id FAA19555 for megaco-list; Tue, 12 Jun 2001 05:56:08 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id FAA19551 for ; Tue, 12 Jun 2001 05:56:07 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id FAA18611 for ; Tue, 12 Jun 2001 05:56:01 -0400 (EDT) Received: from mira-sjc5-1.cisco.com (mira-sjc5-1.cisco.com [171.71.163.15]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f5C9sPF29456; Tue, 12 Jun 2001 02:54:25 -0700 (PDT) Received: from BFOSTER-W2K.cisco.com (sjc-vpn-tmp35.cisco.com [10.21.64.35]) by mira-sjc5-1.cisco.com (Mirapoint) with ESMTP id AAU81099; Tue, 12 Jun 2001 02:55:53 -0700 (PDT) Message-Id: <4.3.2.7.2.20010612025020.04039558@mira-sjc5-1.cisco.com> X-Sender: bfoster@mira-sjc5-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 12 Jun 2001 02:51:10 -0700 To: "Michael Brown" From: Bill Foster Subject: Fwd: RE: Comments on draft-boyle-megaco-tonepkgs-04.txt Cc: "'megaco@fore.com'" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk That if course is GR-529-CORE. >Date: Tue, 12 Jun 2001 02:42:15 -0700 >To: "Michael Brown" >From: Bill Foster >Subject: RE: Comments on draft-boyle-megaco-tonepkgs-04.txt >Cc: "'megaco@fore.com'" > >I apologize for not providing feedback earlier. I'm not sure what is meant >by "mapping of existing market variant tonesets to one another from a >functional perspective means". Many of the tones in sections 7 to 12 as >presently undefined are generally useless to the community at large. The >fact that any tone can be re-mapped to anything else using a MIB, does not >absolve you from providing default tone definitions with some reasonable >description of tone usage. References to existing definitions and usage >only help. If in order for a service provider to unplug MGC A and replace >it with MGC B, they have to completely re-provision all their tone >definitions, then there is something wrong. If you carry this idea to the >extreme then there is no point in providing package and tone names at all >- just have available a collection of package ID's and tone ID's for >anyone to use as they will. > >My case in point was the "low" and "high" tones in the "diagnostic" >package. Either this refers to "low" tone and high "tone" in GR-729-CORE - >or it refers to some other tones described somewhere else, or these tones >are totally undefined. As far as I can tell "low" and "high" tones in >GR-729-CORE are not diagnostic tones unless the definition of "diagnostic" >is so broad as to be totally meaningless. In that case the package name >does nothing to clarify the other tone names like "faint" tone and "loud" >tone in that package. > >Exhaustive documentation may not be required, but some reasonable amount >of documentation is. > > >At 04:26 PM 6/8/2001 -0400, Michael Brown wrote: > >>Sorry for not having responded earlier to your initial post with this >>question. >> >>The short answer is that there is no plan to provide further definitions >>of the tones particularly those other than in section 4. In the case of >>Section 4, it should have the exact same reference as provided in the >>Call Progress tones package in Annex E and that will be added. >> >>Regarding the other tones, they are definitely NOT proprietary, but they >>are tones which have many possible physical definitions based on >>market/national and/or enterprise implementation variations. The current >>tones definitions were derived based on analysis of the mapping of >>existing market variant tonesets to one another from a functional >>perspective. It is our belief that since these tones are defined for >>support of Legacy telephony/services, the functional definitions and the >>inclusion of the Legacy variant naming used for the tones provides >>sufficient guidance for the use of them. It was considered inappropriate >>to try to have these packages attempt to provide exhaustive documentation >>of all of the possible physical tone variations. This has been >>corroborated by the feedback we have received over the last year on this draft. >> >>I don't agree that this is an interoperability problem issue. The reason >>is that the tones in these packages should be defined using a MIB. We >>have submitted a draft proposing such a MIB. The definition of the values >>contained within it is where the potential variations will be resolved. >>This does allow the possibility that there could be "non-standard" >>definitions of the tones, but this would be by the choice of the service >>provider within the context of their deployment based on guidance >>provided by the vendor providing the MGC. The MG is irrelevant since it >>will be provisioned with the tone definitions and will play whatever it's >>told to play and it is up to the MGC to direct the MG actions appropriately. >> >>Regards, >> >>Michael Brown >> >>-----Original Message----- >>From: Bill Foster >>[mailto:bfoster@cisco.com] >>Sent: Thursday, June 07, 2001 4:53 PM >>To: Boyle, Kevin [NCRTP:3Z30:EXCH]; Brown, Michael [NC1:GW10:EXCH]; >>Cornel, Sarah [NCRTP:3J08:EXCH]; Doyle, Stacy [NC1:GW23:EXCH]; Kumar, >>Mehala [MDN05:SR02:EXCH] >>Cc: megaco >>Subject: Comments on draft-boyle-megaco-tonepkgs-04.txt >> >>Is there a plan to provide further definitions of tones in later updates? >>Many of the tones in this document are presently not defined or have no >>references to public documents. Where a tone is not defined but is >>associated with a feature, a reference to a public document that describes >>the feature would help (but obviously a real tone definition would be >>best). With no reference or definition of any kind, these would appear to >>be proprietary tones. In some cases, with no definition, interoperability >>problems may occur. So "low tone" and "high tone" in the diagnostics >>package may refer to the same "low tone" and "high tone" as described in >>GR-529-CORE or maybe they are something completely different. >> >>Tones in section 4 are evidently from E.180 and E.182 - but that should be >>stated. >>Tones in sections 5-6 seem to all have definitions. >>Tones in other sections should have references or better definitions: >>Section 7: xferdt, srdt and tones in Sections 8-12. >> >>----------------------------- >>Bill Foster >>Phone: (250) 758-9418 >>Fax: (781) 998-6492 ----------------------------- Bill Foster Phone: (250) 758-9418 Fax: (781) 998-6492 From owner-megaco@fore.com Tue Jun 12 06:49:05 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11539 for ; Tue, 12 Jun 2001 06:49:04 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id GAA20459; Tue, 12 Jun 2001 06:44:31 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id GAA23895 for megaco-list; Tue, 12 Jun 2001 06:43:35 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id GAA23891 for ; Tue, 12 Jun 2001 06:43:33 -0400 (EDT) Received: from zcars0m9.ca.nortel.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id GAA20382 for ; Tue, 12 Jun 2001 06:43:32 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f5CAgwE21643 for ; Tue, 12 Jun 2001 06:43:04 -0400 (EDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.ca.nortel.com; Tue, 12 Jun 2001 06:43:08 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 12 Jun 2001 06:43:10 -0400 Message-ID: <28560036253BD41191A10000F8BCBD110250CCBA@zcard00g.ca.nortel.com> From: "Tom-PT Taylor" To: "'Bill Foster'" , "Michael Brown" Cc: "'megaco@fore.com'" Subject: RE: Comments on draft-boyle-megaco-tonepkgs-04.txt Date: Tue, 12 Jun 2001 06:43:03 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F32C.7548F4C0" X-Orig: Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0F32C.7548F4C0 Content-Type: text/plain; charset="ISO-8859-1" I wonder if there was a misunderstanding here. Michael may have been saying they don't want to provide a physical definition of each tone, while Bill is asking for a functional definition. I think the latter is a very reasonable request -- otherwise every MG could support tones 1-100 but the meaning of tone 50 would be locally defined. -----Original Message----- From: Bill Foster [mailto:bfoster@cisco.com] Sent: Tuesday, June 12, 2001 5:42 AM To: Brown, Michael [NC1:GW10:EXCH] Cc: 'megaco@fore.com' Subject: RE: Comments on draft-boyle-megaco-tonepkgs-04.txt I apologize for not providing feedback earlier. I'm not sure what is meant by "mapping of existing market variant tonesets to one another from a functional perspective means". Many of the tones in sections 7 to 12 as presently undefined are generally useless to the community at large. The fact that any tone can be re-mapped to anything else using a MIB, does not absolve you from providing default tone definitions with some reasonable description of tone usage. References to existing definitions and usage only help. If in order for a service provider to unplug MGC A and replace it with MGC B, they have to completely re-provision all their tone definitions, then there is something wrong. If you carry this idea to the extreme then there is no point in providing package and tone names at all - just have available a collection of package ID's and tone ID's for anyone to use as they will. My case in point was the "low" and "high" tones in the "diagnostic" package. Either this refers to "low" tone and high "tone" in GR-729-CORE - or it refers to some other tones described somewhere else, or these tones are totally undefined. As far as I can tell "low" and "high" tones in GR-729-CORE are not diagnostic tones unless the definition of "diagnostic" is so broad as to be totally meaningless. In that case the package name does nothing to clarify the other tone names like "faint" tone and "loud" tone in that package. Exhaustive documentation may not be required, but some reasonable amount of documentation is. At 04:26 PM 6/8/2001 -0400, Michael Brown wrote: >Sorry for not having responded earlier to your initial post with this >question. > >The short answer is that there is no plan to provide further definitions >of the tones particularly those other than in section 4. In the case of >Section 4, it should have the exact same reference as provided in the Call >Progress tones package in Annex E and that will be added. > >Regarding the other tones, they are definitely NOT proprietary, but they >are tones which have many possible physical definitions based on >market/national and/or enterprise implementation variations. The current >tones definitions were derived based on analysis of the mapping of >existing market variant tonesets to one another from a functional >perspective. It is our belief that since these tones are defined for >support of Legacy telephony/services, the functional definitions and the >inclusion of the Legacy variant naming used for the tones provides >sufficient guidance for the use of them. It was considered inappropriate >to try to have these packages attempt to provide exhaustive documentation >of all of the possible physical tone variations. This has been >corroborated by the feedback we have received over the last year on this draft. > >I don't agree that this is an interoperability problem issue. The reason >is that the tones in these packages should be defined using a MIB. We have >submitted a draft proposing such a MIB. The definition of the values >contained within it is where the potential variations will be resolved. >This does allow the possibility that there could be "non-standard" >definitions of the tones, but this would be by the choice of the service >provider within the context of their deployment based on guidance provided >by the vendor providing the MGC. The MG is irrelevant since it will be >provisioned with the tone definitions and will play whatever it's told to >play and it is up to the MGC to direct the MG actions appropriately. > >Regards, > >Michael Brown > >-----Original Message----- >From: Bill Foster >[mailto:bfoster@cisco.c om] >Sent: Thursday, June 07, 2001 4:53 PM >To: Boyle, Kevin [NCRTP:3Z30:EXCH]; Brown, Michael [NC1:GW10:EXCH]; >Cornel, Sarah [NCRTP:3J08:EXCH]; Doyle, Stacy [NC1:GW23:EXCH]; Kumar, >Mehala [MDN05:SR02:EXCH] >Cc: megaco >Subject: Comments on draft-boyle-megaco-tonepkgs-04.txt > >Is there a plan to provide further definitions of tones in later updates? >Many of the tones in this document are presently not defined or have no >references to public documents. Where a tone is not defined but is >associated with a feature, a reference to a public document that describes >the feature would help (but obviously a real tone definition would be >best). With no reference or definition of any kind, these would appear to >be proprietary tones. In some cases, with no definition, interoperability >problems may occur. So "low tone" and "high tone" in the diagnostics >package may refer to the same "low tone" and "high tone" as described in >GR-529-CORE or maybe they are something completely different. > >Tones in section 4 are evidently from E.180 and E.182 - but that should be >stated. >Tones in sections 5-6 seem to all have definitions. >Tones in other sections should have references or better definitions: >Section 7: xferdt, srdt and tones in Sections 8-12. > >----------------------------- >Bill Foster >Phone: (250) 758-9418 >Fax: (781) 998-6492 ----------------------------- Bill Foster Phone: (250) 758-9418 Fax: (781) 998-6492 ------_=_NextPart_001_01C0F32C.7548F4C0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: Comments on draft-boyle-megaco-tonepkgs-04.txt

I wonder if there was a misunderstanding here.  = Michael may have been saying they don't want to provide a physical = definition of each tone, while Bill is asking for a functional = definition.  I think the latter is a very reasonable request -- = otherwise every MG could support tones 1-100 but the meaning of tone 50 = would be locally defined.

-----Original Message-----
From: Bill Foster [mailto:bfoster@cisco.com]
Sent: Tuesday, June 12, 2001 5:42 AM
To: Brown, Michael [NC1:GW10:EXCH]
Cc: 'megaco@fore.com'
Subject: RE: Comments on = draft-boyle-megaco-tonepkgs-04.txt


I apologize for not providing feedback earlier. I'm = not sure what is meant
by "mapping of existing market variant tonesets = to one another from a
functional perspective means". Many of the = tones in sections 7 to 12 as
presently undefined are generally useless to the = community at large. The
fact that any tone can be re-mapped to anything else = using a MIB, does not
absolve you from providing default tone definitions = with some reasonable
description of tone usage. References to existing = definitions and usage
only help. If in order for a service provider to = unplug MGC A and replace
it with MGC B, they have to completely re-provision = all their tone
definitions, then there is something wrong. If you = carry this idea to the
extreme then there is no point in providing package = and tone names at all -
just have available a collection of package ID's and = tone ID's for anyone
to use as they will.

My case in point was the "low" and = "high" tones in the "diagnostic"
package. Either this refers to "low" tone = and high "tone" in GR-729-CORE -
or it refers to some other tones described somewhere = else, or these tones
are totally undefined. As far as I can tell = "low" and "high" tones in
GR-729-CORE are not diagnostic tones unless the = definition of "diagnostic"
is so broad as to be totally meaningless. In that = case the package name
does nothing to clarify the other tone names like = "faint" tone and "loud"
tone in that package.

Exhaustive documentation may not be required, but = some reasonable amount of
documentation is.


At 04:26 PM 6/8/2001 -0400, Michael Brown = wrote:

>Sorry for not having responded earlier to your = initial post with this
>question.
>
>The short answer is that there is no plan to = provide further definitions
>of the tones particularly those other than in = section 4. In the case of
>Section 4, it should have the exact same = reference as provided in the Call
>Progress tones package in Annex E and that will = be added.
>
>Regarding the other tones, they are definitely = NOT proprietary, but they
>are tones which have many possible physical = definitions based on
>market/national and/or enterprise implementation = variations. The current
>tones definitions were derived based on analysis = of the mapping of
>existing market variant tonesets to one another = from a functional
>perspective. It is our belief that since these = tones are defined for
>support of Legacy telephony/services, the = functional definitions and the
>inclusion of the Legacy variant naming used for = the tones provides
>sufficient guidance for the use of them. It was = considered inappropriate
>to try to have these packages attempt to provide = exhaustive documentation
>of all of the possible physical tone variations. = This has been
>corroborated by the feedback we have received = over the last year on this draft.
>
>I don't agree that this is an interoperability = problem issue. The reason
>is that the tones in these packages should be = defined using a MIB. We have
>submitted a draft proposing such a MIB. The = definition of the values
>contained within it is where the potential = variations will be resolved.
>This does allow the possibility that there could = be "non-standard"
>definitions of the tones, but this would be by = the choice of the service
>provider within the context of their deployment = based on guidance provided
>by the vendor providing the MGC. The MG is = irrelevant since it will be
>provisioned with the tone definitions and will = play whatever it's told to
>play and it is up to the MGC to direct the MG = actions appropriately.
>
>Regards,
>
>Michael Brown
>
>-----Original Message-----
>From: Bill Foster
>[<mailto:bfoster@cisco.com>mailto:bfoster@cisco<mailto:bfoster@cisco.com>.com]<= /FONT>
>Sent: Thursday, June 07, 2001 4:53 PM
>To: Boyle, Kevin [NCRTP:3Z30:EXCH]; Brown, = Michael [NC1:GW10:EXCH];
>Cornel, Sarah [NCRTP:3J08:EXCH]; Doyle, Stacy = [NC1:GW23:EXCH]; Kumar,
>Mehala [MDN05:SR02:EXCH]
>Cc: megaco
>Subject: Comments on = draft-boyle-megaco-tonepkgs-04.txt
>
>Is there a plan to provide further definitions = of tones in later updates?
>Many of the tones in this document are presently = not defined or have no
>references to public documents. Where a tone is = not defined but is
>associated with a feature, a reference to a = public document that describes
>the feature would help (but obviously a real = tone definition would be
>best). With no reference or definition of any = kind, these would appear to
>be proprietary tones. In some cases, with no = definition, interoperability
>problems may occur. So  "low = tone" and "high tone" in the diagnostics
>package may refer to the same "low = tone" and "high tone" as described in
>GR-529-CORE or maybe they are something = completely different.
>
>Tones in section 4 are evidently from E.180 and = E.182 - but that should be
>stated.
>Tones in sections 5-6 seem to all have = definitions.
>Tones in other sections should have references = or better definitions:
>Section 7: xferdt, srdt and tones in Sections = 8-12.
>
>-----------------------------
>Bill Foster
>Phone: (250) 758-9418
>Fax:     (781) = 998-6492

-----------------------------
Bill Foster
Phone: (250) 758-9418
Fax:     (781) 998-6492

------_=_NextPart_001_01C0F32C.7548F4C0-- From owner-megaco@fore.com Tue Jun 12 16:21:03 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23938 for ; Tue, 12 Jun 2001 16:21:02 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA03800; Tue, 12 Jun 2001 16:16:09 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id QAA26189 for megaco-list; Tue, 12 Jun 2001 16:10:54 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA26172 for ; Tue, 12 Jun 2001 16:10:52 -0400 (EDT) Received: from rainier.illuminet.com ([63.116.20.100]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA03384 for ; Tue, 12 Jun 2001 16:10:49 -0400 (EDT) Received: from olwinexsmtp01.corp.illuminet.com (olwinexsmtp01.corp.illuminet.com [172.20.1.9]) by rainier.illuminet.com (8.8.8/8.8.8) with ESMTP id NAA07120; Tue, 12 Jun 2001 13:07:44 -0700 (PDT) Received: by olwinexsmtp01.corp.illuminet.com with Internet Mail Service (5.5.2653.19) id ; Tue, 12 Jun 2001 13:07:29 -0700 Message-ID: <1C1EEC765F843E44996971A80682118B62CE28@opwinexcl01.corp.illuminet.com> From: Kevin McCandless To: "'Tom-PT Taylor'" Cc: "'megaco'" Subject: RE: Meeting In August Date: Tue, 12 Jun 2001 13:07:29 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Tom: We are going from a closed working group to a active one again? Do we need a charter before the August meeting? -----Original Message----- From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] Sent: Monday, June 11, 2001 9:28 AM To: 'megaco' Subject: Meeting In August Megaco will meet in August. We should be thinking about open issues to cover in that meeting. I'll go out on a limb and suggest we will also have a new charter to flesh out. We should be forming a consensus on what packages we want to include as WG work items. Tom Taylor From owner-megaco@fore.com Tue Jun 12 17:55:30 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25347 for ; Tue, 12 Jun 2001 17:55:30 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA10092; Tue, 12 Jun 2001 17:50:57 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id RAA16559 for megaco-list; Tue, 12 Jun 2001 17:49:25 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA16540 for ; Tue, 12 Jun 2001 17:49:22 -0400 (EDT) Received: from auemail1.firewall.lucent.com (auemail1.lucent.com [192.11.223.161]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA09952 for ; Tue, 12 Jun 2001 17:49:20 -0400 (EDT) Received: from auemail1.firewall.lucent.com (localhost [127.0.0.1]) by auemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5CLnLh06825 for ; Tue, 12 Jun 2001 17:49:21 -0400 (EDT) Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3]) by auemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5CLnLD06816 for ; Tue, 12 Jun 2001 17:49:21 -0400 (EDT) Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id RAA09438; Tue, 12 Jun 2001 17:49:20 -0400 (EDT) Received: from lucent.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id RAA09434; Tue, 12 Jun 2001 17:49:19 -0400 (EDT) Message-ID: <3B268DE4.5D0AB114@lucent.com> Date: Tue, 12 Jun 2001 17:47:16 -0400 From: Troy Cauble Reply-To: Troy Cauble X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: MEGACO list Subject: empty digit map Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: 7bit Don't we need the ability to clear a digit map? The currently allowable encoding that is closest to being "empty" is "{([])}" as in: DigitMap = Name {([])} Do we need a simpler representation for an empty digit map descriptor? -troy From owner-megaco@fore.com Tue Jun 12 19:35:58 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26865 for ; Tue, 12 Jun 2001 19:35:57 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id TAA14179; Tue, 12 Jun 2001 19:31:24 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id TAA28588 for megaco-list; Tue, 12 Jun 2001 19:29:46 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id TAA28584 for ; Tue, 12 Jun 2001 19:29:45 -0400 (EDT) Received: from hypnos.cps.intel.com (hypnos.cps.intel.com [192.198.165.17]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id TAA14056 for ; Tue, 12 Jun 2001 19:29:42 -0400 (EDT) Received: from SMTP (fmsmsxvs03-1.fm.intel.com [132.233.42.203]) by hypnos.cps.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.40 2001/06/06 21:14:49 root Exp $) with SMTP id XAA15062 for ; Tue, 12 Jun 2001 23:29:43 GMT Received: from fmsmsx19.fm.intel.com ([132.233.48.19]) by 132.233.48.203 (Norton AntiVirus for Internet Email Gateways 1.0) ; Tue, 12 Jun 2001 23:29:43 0000 (GMT) Received: by fmsmsx19.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 12 Jun 2001 16:29:42 -0700 Message-ID: From: "Kaul, Bharat" To: "'megaco@fore.com'" Subject: RE: Polls of MGC Date: Tue, 12 Jun 2001 16:29:40 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Did we ever come to a conclusion on how to Poll ? If yes, can someone summarize what has been concluded ? Thanks - Bharat From owner-megaco@fore.com Tue Jun 12 21:13:26 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27669 for ; Tue, 12 Jun 2001 21:13:26 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id VAA17277; Tue, 12 Jun 2001 21:08:53 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id VAA06787 for megaco-list; Tue, 12 Jun 2001 21:07:48 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id VAA06780 for ; Tue, 12 Jun 2001 21:07:46 -0400 (EDT) From: scliang@lucent.com Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id VAA17169 for ; Tue, 12 Jun 2001 21:07:44 -0400 (EDT) Received: from hoemail2.firewall.lucent.com (localhost [127.0.0.1]) by hoemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5D17kb14444 for ; Tue, 12 Jun 2001 21:07:46 -0400 (EDT) Received: from homail.ho.lucent.com (h135-17-192-10.lucent.com [135.17.192.10]) by hoemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5D17jP14435 for ; Tue, 12 Jun 2001 21:07:45 -0400 (EDT) Received: from md7102notes01.ins.lucent.com (md7102notes01.ins.lucent.com [135.114.92.192]) by homail.ho.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id VAA15228; Tue, 12 Jun 2001 21:07:43 -0400 (EDT) Subject: Re: empty digit map To: Troy Cauble Cc: MEGACO list Date: Tue, 12 Jun 2001 21:00:52 -0400 Message-ID: X-MIMETrack: Serialize by Router on Notes01/SVR/Yurie(Release 5.0.6 |December 14, 2000) at 06/12/2001 09:00:52 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Hi List, Was it the only reason to have *((DIGIT "-" DIGIT) / digitMapLetter) instead of 1*((DIGIT "-" DIGIT) / digitMapLetter), simply for empty digit map value? A digit map range of nothing makes little sense. Thanks, Shihchang Troy Cauble @pit.comms.marconi.com on 06/12/2001 05:47:16 PM Please respond to Troy Cauble Sent by: owner-megaco@pit.comms.marconi.com To: MEGACO list cc: Subject: empty digit map Don't we need the ability to clear a digit map? The currently allowable encoding that is closest to being "empty" is "{([])}" as in: DigitMap = Name {([])} Do we need a simpler representation for an empty digit map descriptor? -troy From owner-megaco@fore.com Tue Jun 12 23:39:27 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01200 for ; Tue, 12 Jun 2001 23:39:27 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id XAA21290; Tue, 12 Jun 2001 23:34:51 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id XAA15717 for megaco-list; Tue, 12 Jun 2001 23:31:58 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id XAA15713 for ; Tue, 12 Jun 2001 23:31:57 -0400 (EDT) From: vbajaj@hss.hns.com Received: from hindon.hss.co.in ([202.54.26.202]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id XAA21194 for ; Tue, 12 Jun 2001 23:31:53 -0400 (EDT) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id f5D3VWY18121; Wed, 13 Jun 2001 09:01:32 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256A6A.0011DA0E ; Wed, 13 Jun 2001 08:44:59 +0530 X-Lotus-FromDomain: HSS To: Bill Foster cc: "Michael Brown" , "'megaco@fore.com'" Message-ID: <65256A6A.0011D8D5.00@sandesh.hss.hns.com> Date: Wed, 13 Jun 2001 08:52:48 +0530 Subject: RE: Comments on draft-boyle-megaco-tonepkgs-04.txt Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Hi, I second Bill's thoughts. The more explicit packages are, lesser would be the interoperability problems. Rgds, Vikas Bajaj Hughes Software Systems Ltd. Bill Foster on 06/12/2001 03:12:15 PM To: "Michael Brown" cc: "'megaco@fore.com'" (bcc: Vikas Bajaj/HSS) Subject: RE: Comments on draft-boyle-megaco-tonepkgs-04.txt I apologize for not providing feedback earlier. I'm not sure what is meant by "mapping of existing market variant tonesets to one another from a functional perspective means". Many of the tones in sections 7 to 12 as presently undefined are generally useless to the community at large. The fact that any tone can be re-mapped to anything else using a MIB, does not absolve you from providing default tone definitions with some reasonable description of tone usage. References to existing definitions and usage only help. If in order for a service provider to unplug MGC A and replace it with MGC B, they have to completely re-provision all their tone definitions, then there is something wrong. If you carry this idea to the extreme then there is no point in providing package and tone names at all - just have available a collection of package ID's and tone ID's for anyone to use as they will. My case in point was the "low" and "high" tones in the "diagnostic" package. Either this refers to "low" tone and high "tone" in GR-729-CORE - or it refers to some other tones described somewhere else, or these tones are totally undefined. As far as I can tell "low" and "high" tones in GR-729-CORE are not diagnostic tones unless the definition of "diagnostic" is so broad as to be totally meaningless. In that case the package name does nothing to clarify the other tone names like "faint" tone and "loud" tone in that package. Exhaustive documentation may not be required, but some reasonable amount of documentation is. At 04:26 PM 6/8/2001 -0400, Michael Brown wrote: >Sorry for not having responded earlier to your initial post with this >question. > >The short answer is that there is no plan to provide further definitions >of the tones particularly those other than in section 4. In the case of >Section 4, it should have the exact same reference as provided in the Call >Progress tones package in Annex E and that will be added. > >Regarding the other tones, they are definitely NOT proprietary, but they >are tones which have many possible physical definitions based on >market/national and/or enterprise implementation variations. The current >tones definitions were derived based on analysis of the mapping of >existing market variant tonesets to one another from a functional >perspective. It is our belief that since these tones are defined for >support of Legacy telephony/services, the functional definitions and the >inclusion of the Legacy variant naming used for the tones provides >sufficient guidance for the use of them. It was considered inappropriate >to try to have these packages attempt to provide exhaustive documentation >of all of the possible physical tone variations. This has been >corroborated by the feedback we have received over the last year on this draft. > >I don't agree that this is an interoperability problem issue. The reason >is that the tones in these packages should be defined using a MIB. We have >submitted a draft proposing such a MIB. The definition of the values >contained within it is where the potential variations will be resolved. >This does allow the possibility that there could be "non-standard" >definitions of the tones, but this would be by the choice of the service >provider within the context of their deployment based on guidance provided >by the vendor providing the MGC. The MG is irrelevant since it will be >provisioned with the tone definitions and will play whatever it's told to >play and it is up to the MGC to direct the MG actions appropriately. > >Regards, > >Michael Brown > >-----Original Message----- >From: Bill Foster >[mailto:bfoster@cisco.com] >Sent: Thursday, June 07, 2001 4:53 PM >To: Boyle, Kevin [NCRTP:3Z30:EXCH]; Brown, Michael [NC1:GW10:EXCH]; >Cornel, Sarah [NCRTP:3J08:EXCH]; Doyle, Stacy [NC1:GW23:EXCH]; Kumar, >Mehala [MDN05:SR02:EXCH] >Cc: megaco >Subject: Comments on draft-boyle-megaco-tonepkgs-04.txt > >Is there a plan to provide further definitions of tones in later updates? >Many of the tones in this document are presently not defined or have no >references to public documents. Where a tone is not defined but is >associated with a feature, a reference to a public document that describes >the feature would help (but obviously a real tone definition would be >best). With no reference or definition of any kind, these would appear to >be proprietary tones. In some cases, with no definition, interoperability >problems may occur. So "low tone" and "high tone" in the diagnostics >package may refer to the same "low tone" and "high tone" as described in >GR-529-CORE or maybe they are something completely different. > >Tones in section 4 are evidently from E.180 and E.182 - but that should be >stated. >Tones in sections 5-6 seem to all have definitions. >Tones in other sections should have references or better definitions: >Section 7: xferdt, srdt and tones in Sections 8-12. > >----------------------------- >Bill Foster >Phone: (250) 758-9418 >Fax: (781) 998-6492 ----------------------------- Bill Foster Phone: (250) 758-9418 Fax: (781) 998-6492 From owner-megaco@fore.com Wed Jun 13 02:11:28 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13100 for ; Wed, 13 Jun 2001 02:11:28 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id CAA25699; Wed, 13 Jun 2001 02:10:23 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id CAA25954 for megaco-list; Wed, 13 Jun 2001 02:08:51 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id CAA25950 for ; Wed, 13 Jun 2001 02:08:50 -0400 (EDT) Received: from mail-lod.audiocodes.com ([212.143.19.162]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id CAA25602 for ; Wed, 13 Jun 2001 02:08:46 -0400 (EDT) Received: by MAIL-LOD with Internet Mail Service (5.5.2653.19) id ; Wed, 13 Jun 2001 09:08:44 +0200 Message-ID: <3F2E96E0B800D511821E00306E062AE404BDC1@MAIL-LOD> From: Nurit Shenhar To: "'Troy Cauble'" , "'Megaco (E-mail)" Subject: RE: empty digit map Date: Wed, 13 Jun 2001 09:08:44 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Troy A digit map is deleted by sending a digitMapDescriptor of the form: DigitMap=Name . This command will delete the digitMap from the termination. Is that what you wanted? Nurit -----Original Message----- From: Troy Cauble [mailto:troy@lucent.com] Sent: Tuesday, June 12, 2001 11:47 PM To: MEGACO list Subject: empty digit map Don't we need the ability to clear a digit map? The currently allowable encoding that is closest to being "empty" is "{([])}" as in: DigitMap = Name {([])} Do we need a simpler representation for an empty digit map descriptor? -troy From owner-megaco@fore.com Wed Jun 13 02:19:35 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13635 for ; Wed, 13 Jun 2001 02:19:34 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id CAA26111; Wed, 13 Jun 2001 02:18:45 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id CAA26561 for megaco-list; Wed, 13 Jun 2001 02:18:16 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id CAA26557 for ; Wed, 13 Jun 2001 02:18:14 -0400 (EDT) From: vibansal@hss.hns.com Received: from hindon.hss.co.in ([202.54.26.202]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id CAA26027 for ; Wed, 13 Jun 2001 02:18:10 -0400 (EDT) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id f5D6JU629402 for ; Wed, 13 Jun 2001 11:49:30 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256A6A.002139C4 ; Wed, 13 Jun 2001 11:32:54 +0530 X-Lotus-FromDomain: HSS To: megaco@fore.com Message-ID: <65256A6A.00213748.00@sandesh.hss.hns.com> Date: Wed, 13 Jun 2001 11:46:22 +0530 Subject: Megaco over ATM Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Hi Can somebody tell which is current reference for transport of protocol over ATM. Regards Vivek Bansal From owner-megaco@fore.com Wed Jun 13 08:31:28 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20619 for ; Wed, 13 Jun 2001 08:31:27 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA08650; Wed, 13 Jun 2001 08:30:14 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id IAA23134 for megaco-list; Wed, 13 Jun 2001 08:27:57 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA23129 for ; Wed, 13 Jun 2001 08:27:55 -0400 (EDT) Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA08405 for ; Wed, 13 Jun 2001 08:27:53 -0400 (EDT) Received: from hoemail2.firewall.lucent.com (localhost [127.0.0.1]) by hoemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5DCRre20024 for ; Wed, 13 Jun 2001 08:27:53 -0400 (EDT) Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3]) by hoemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5DCRrX20020 for ; Wed, 13 Jun 2001 08:27:53 -0400 (EDT) Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id IAA12887; Wed, 13 Jun 2001 08:27:36 -0400 (EDT) Cc: "'Megaco (E-mail)" Received: from lucent.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id IAA12878; Wed, 13 Jun 2001 08:27:34 -0400 (EDT) Message-ID: <3B275BBC.DD90DC33@lucent.com> Date: Wed, 13 Jun 2001 08:25:32 -0400 From: Troy Cauble Reply-To: Troy Cauble X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Nurit Shenhar Original-CC: "'Megaco (E-mail)" Subject: Re: empty digit map References: <3F2E96E0B800D511821E00306E062AE404BDC1@MAIL-LOD> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: 7bit Nurit Shenhar wrote: > > Troy > > A digit map is deleted by sending a digitMapDescriptor of the form: > DigitMap=Name . This command will delete the digitMap from the termination. > Is that what you wanted? I thought that form was for referencing previously defined digitMaps. As in you could pre-load 3 digitMaps with different names and then select among them. -troy From owner-megaco@fore.com Wed Jun 13 09:19:56 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22339 for ; Wed, 13 Jun 2001 09:19:56 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA13839; Wed, 13 Jun 2001 09:18:29 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id JAA02701 for megaco-list; Wed, 13 Jun 2001 09:17:35 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA02696 for ; Wed, 13 Jun 2001 09:17:34 -0400 (EDT) Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA13670 for ; Wed, 13 Jun 2001 09:17:32 -0400 (EDT) Received: from hoemail1.firewall.lucent.com (localhost [127.0.0.1]) by hoemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5DDHWk18439 for ; Wed, 13 Jun 2001 09:17:32 -0400 (EDT) Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3]) by hoemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5DDHWn18427 for ; Wed, 13 Jun 2001 09:17:32 -0400 (EDT) Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id JAA13541; Wed, 13 Jun 2001 09:17:29 -0400 (EDT) Received: from lucent.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id JAA13537; Wed, 13 Jun 2001 09:17:29 -0400 (EDT) Message-ID: <3B27676F.B9D17634@lucent.com> Date: Wed, 13 Jun 2001 09:15:27 -0400 From: Troy Cauble Reply-To: Troy Cauble X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: MEGACO list Subject: g/sc SigID list Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: 7bit Proposal: Change the Type of the g/sc SigId parameter in E.1.2 from "list" to "string". Argument: Sections 12.1.2 and 12.2 define allowable types for Properties and Parameters, including "String" and "Sub-list". Annex E.1.2 (g/sc) defines parameter SigID as being a "list" and references a complex syntax for that "list" which includes nested braces. This specific syntax conflicts with the established syntax for a list. parmValue = (EQUAL alternativeValue/ INEQUAL VALUE) alternativeValue = ( VALUE / LSBRKT VALUE *(COMMA VALUE) RSBRKT ; sublist (i.e. A AND B AND ...) / LBRKT VALUE *(COMMA VALUE) RBRKT ; alternatives (i.e. A OR B OR ...) / LSBRKT VALUE COLON VALUE RSBRKT ) ; range If the type is redefined as "String", double quotes will be required (IG 6.80). Within that quotedString, the syntax could stay as defined. Besides the fact that this syntax is in direct conflict of the ABNF specification, I think it is unreasonable to allow a package to define a complex syntax to be embedded directly in a VALUE without quoting. Parsers should be able to parse the message down to the VALUE level without package knowledge. Comments? -troy From owner-megaco@fore.com Wed Jun 13 10:34:58 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24065 for ; Wed, 13 Jun 2001 10:34:56 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA22740; Wed, 13 Jun 2001 10:33:45 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA21240 for megaco-list; Wed, 13 Jun 2001 10:31:45 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA21225 for ; Wed, 13 Jun 2001 10:31:42 -0400 (EDT) From: prjain@hss.hns.com Received: from hindon.hss.co.in ([202.54.26.202]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA22522 for ; Wed, 13 Jun 2001 10:31:39 -0400 (EDT) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id f5DEWuK18595 for ; Wed, 13 Jun 2001 20:02:56 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256A6A.004E6891 ; Wed, 13 Jun 2001 19:46:25 +0530 X-Lotus-FromDomain: HSS To: megaco@fore.com Message-ID: <65256A6A.004E6796.00@sandesh.hss.hns.com> Date: Wed, 13 Jun 2001 19:50:55 +0530 Subject: Concept of Stream ID Zero Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Hi everybody, tom, brian, In the section 7.1.9 of the protocol, it is written that stream ID 0 indicates that the event to be detected is not related to a particular media stream. This statement is little confusing. Does it imply that stream ID 0 means all media streams in case multiple streams have been created on the specified termination. And if yes, does it also imply that if the specified event is detected on all media streams, then only it shall be reported to the MGC. Another interpretation of the stream ID 0 can be that the specified event is to be detected on any of the streams in case multiple streams exist simultaneously. And in this case event shall be reported to MGC if it is detected over any of the streams on the specified termination. Please clarify my doubt. Thanks, Prashant Jain From owner-megaco@fore.com Wed Jun 13 11:00:03 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24540 for ; Wed, 13 Jun 2001 11:00:02 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA25626; Wed, 13 Jun 2001 10:59:00 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA28877 for megaco-list; Wed, 13 Jun 2001 10:56:58 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA28865 for ; Wed, 13 Jun 2001 10:56:56 -0400 (EDT) Received: from huginn.ctccom.net (Huginn.CTCCom.net [207.190.194.11]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA25360 for ; Wed, 13 Jun 2001 10:56:53 -0400 (EDT) Received: from MBRAHMANAPALLY ([64.69.123.121]) by huginn.ctccom.net (Mirapoint) with SMTP id ACV09928; Wed, 13 Jun 2001 10:56:47 -0400 (EDT) From: "Madhu Babu Brahmanapally" To: , Subject: RE: Concept of Stream ID Zero Date: Wed, 13 Jun 2001 10:58:35 -0400 Message-ID: <000401c0f419$52ec6e00$c500a8c0@MBRAHMANAPALLY> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <65256A6A.004E6796.00@sandesh.hss.hns.com> Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: 7bit Hi Prashant, IMO the first argument is definitely not true..since you can't expect an event to occur simultaneously on all the streams on the given termination. The second possibility can be true as the stream Identifier is of not much significance, the event needs to be reported if recognized on any of the streams. Infact if there is no media stream (I mean no transfer of media)..the same argument for StreamId 0 holds good, as there is no significance for the stream Id. Then The events will be detected on the termination (which maps to a physical line or one or more DS0s). -Regards Madhubabu -----Original Message----- From: owner-megaco@pit.comms.marconi.com [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of prjain@hss.hns.com Sent: Wednesday, June 13, 2001 10:21 AM To: megaco@fore.com Subject: Concept of Stream ID Zero Hi everybody, tom, brian, In the section 7.1.9 of the protocol, it is written that stream ID 0 indicates that the event to be detected is not related to a particular media stream. This statement is little confusing. Does it imply that stream ID 0 means all media streams in case multiple streams have been created on the specified termination. And if yes, does it also imply that if the specified event is detected on all media streams, then only it shall be reported to the MGC. Another interpretation of the stream ID 0 can be that the specified event is to be detected on any of the streams in case multiple streams exist simultaneously. And in this case event shall be reported to MGC if it is detected over any of the streams on the specified termination. Please clarify my doubt. Thanks, Prashant Jain From owner-megaco@fore.com Wed Jun 13 11:09:52 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24730 for ; Wed, 13 Jun 2001 11:09:51 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA26724; Wed, 13 Jun 2001 11:08:41 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id LAA03189 for megaco-list; Wed, 13 Jun 2001 11:07:38 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA03185 for ; Wed, 13 Jun 2001 11:07:37 -0400 (EDT) Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA26542 for ; Wed, 13 Jun 2001 11:07:34 -0400 (EDT) Received: from ihemail1.firewall.lucent.com (localhost [127.0.0.1]) by ihemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5DF7Zt04228 for ; Wed, 13 Jun 2001 11:07:35 -0400 (EDT) Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3]) by ihemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5DF6nb03215 for ; Wed, 13 Jun 2001 11:06:49 -0400 (EDT) Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id LAA15932; Wed, 13 Jun 2001 11:06:47 -0400 (EDT) Received: from lucent.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id LAA15928; Wed, 13 Jun 2001 11:06:46 -0400 (EDT) Message-ID: <3B27810B.AC9FF822@lucent.com> Date: Wed, 13 Jun 2001 11:04:43 -0400 From: Troy Cauble Reply-To: Troy Cauble X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: MEGACO list Subject: Re: g/sc SigID list References: <3B27676F.B9D17634@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: 7bit BTW, here are some uses that I think are consistent with the syntax description in E.1.2. Anyone care to comment? This is vague enough in E.1.2 that it should be clarified with some examples. Note that a sublist uses [] not {} according to the ABNF for alternativeValue. 1.Reporting a signal outside of sequential signal list: SigID="pkg1/sig1" 2.Reporting a signal inside a sequential signal list: SigID="SignalList = 1 {pkg1/sig1}" 3.Reporting a list of signals outside of sequential signal list: SigID=[ "pkg1/sig1" , "pkg2/sig2" ] 4.Reporting a list of signals inside a sequential signal list: SigID=[ "SignalList = 1 {pkg1/sig1}", "SignalList = 2 {pkg2/sig2}" ] 5.Reporting a list of both signals and sequential signal lists: SigID=[ "pkg1/sig1" , "pkg2/sig2", "SignalList = 1 {pkg3/sig3}", "SignalList = 2 {pkg4/sig4}" ] -troy Troy Cauble wrote: > > Proposal: > > Change the Type of the g/sc SigId parameter in E.1.2 > from "list" to "string". > > Argument: > > Sections 12.1.2 and 12.2 define allowable types > for Properties and Parameters, including "String" > and "Sub-list". > > Annex E.1.2 (g/sc) defines parameter SigID as > being a "list" and references a complex syntax for > that "list" which includes nested braces. > > This specific syntax conflicts with the established > syntax for a list. > > parmValue = (EQUAL alternativeValue/ INEQUAL VALUE) > alternativeValue = ( VALUE > / LSBRKT VALUE *(COMMA VALUE) RSBRKT > ; sublist (i.e. A AND B AND ...) > / LBRKT VALUE *(COMMA VALUE) RBRKT > ; alternatives (i.e. A OR B OR ...) > / LSBRKT VALUE COLON VALUE RSBRKT ) > ; range > > If the type is redefined as "String", double quotes > will be required (IG 6.80). Within that quotedString, > the syntax could stay as defined. > > Besides the fact that this syntax is in direct conflict > of the ABNF specification, I think it is unreasonable > to allow a package to define a complex syntax to be > embedded directly in a VALUE without quoting. Parsers > should be able to parse the message down to the VALUE > level without package knowledge. > > Comments? > > -troy From owner-megaco@fore.com Wed Jun 13 11:31:55 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25226 for ; Wed, 13 Jun 2001 11:31:54 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA28912; Wed, 13 Jun 2001 11:31:01 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id LAA09184 for megaco-list; Wed, 13 Jun 2001 11:29:55 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA09155 for ; Wed, 13 Jun 2001 11:29:51 -0400 (EDT) Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA28753 for ; Wed, 13 Jun 2001 11:29:48 -0400 (EDT) Received: from ihemail1.firewall.lucent.com (localhost [127.0.0.1]) by ihemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5DFTmt13668 for ; Wed, 13 Jun 2001 11:29:48 -0400 (EDT) Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3]) by ihemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5DFTl713610 for ; Wed, 13 Jun 2001 11:29:47 -0400 (EDT) Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id LAA16853; Wed, 13 Jun 2001 11:29:45 -0400 (EDT) Received: from lucent.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id LAA16849; Wed, 13 Jun 2001 11:29:45 -0400 (EDT) Message-ID: <3B27866D.5838126E@lucent.com> Date: Wed, 13 Jun 2001 11:27:41 -0400 From: Troy Cauble Reply-To: Troy Cauble X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: MEGACO list Subject: Re: g/sc SigID list References: <3B27676F.B9D17634@lucent.com> <3B27810B.AC9FF822@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: 7bit New proposal: Change the Type of the g/sc SigId parameter in E.1.2 from "list" to "string or list of strings". Clarify syntax with examples below. Objections? -troy Troy Cauble wrote: > > BTW, here are some uses that I think are consistent with > the syntax description in E.1.2. Anyone care to comment? > This is vague enough in E.1.2 that it should be clarified > with some examples. > > Note that a sublist uses [] not {} according to the ABNF > for alternativeValue. > > 1.Reporting a signal outside of sequential signal list: > SigID="pkg1/sig1" > > 2.Reporting a signal inside a sequential signal list: > SigID="SignalList = 1 {pkg1/sig1}" > > 3.Reporting a list of signals outside of sequential signal list: > SigID=[ "pkg1/sig1" , "pkg2/sig2" ] > > 4.Reporting a list of signals inside a sequential signal list: > SigID=[ "SignalList = 1 {pkg1/sig1}", "SignalList = 2 {pkg2/sig2}" ] > > 5.Reporting a list of both signals and sequential signal lists: > SigID=[ "pkg1/sig1" , "pkg2/sig2", "SignalList = 1 {pkg3/sig3}", > "SignalList = 2 {pkg4/sig4}" ] > > -troy > > Troy Cauble wrote: > > > > Proposal: > > > > Change the Type of the g/sc SigId parameter in E.1.2 > > from "list" to "string". > > > > Argument: > > > > Sections 12.1.2 and 12.2 define allowable types > > for Properties and Parameters, including "String" > > and "Sub-list". > > > > Annex E.1.2 (g/sc) defines parameter SigID as > > being a "list" and references a complex syntax for > > that "list" which includes nested braces. > > > > This specific syntax conflicts with the established > > syntax for a list. > > > > parmValue = (EQUAL alternativeValue/ INEQUAL VALUE) > > alternativeValue = ( VALUE > > / LSBRKT VALUE *(COMMA VALUE) RSBRKT > > ; sublist (i.e. A AND B AND ...) > > / LBRKT VALUE *(COMMA VALUE) RBRKT > > ; alternatives (i.e. A OR B OR ...) > > / LSBRKT VALUE COLON VALUE RSBRKT ) > > ; range > > > > If the type is redefined as "String", double quotes > > will be required (IG 6.80). Within that quotedString, > > the syntax could stay as defined. > > > > Besides the fact that this syntax is in direct conflict > > of the ABNF specification, I think it is unreasonable > > to allow a package to define a complex syntax to be > > embedded directly in a VALUE without quoting. Parsers > > should be able to parse the message down to the VALUE > > level without package knowledge. > > > > Comments? > > > > -troy From owner-megaco@fore.com Wed Jun 13 11:41:51 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25455 for ; Wed, 13 Jun 2001 11:41:48 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA29920; Wed, 13 Jun 2001 11:40:52 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id LAA11917 for megaco-list; Wed, 13 Jun 2001 11:38:14 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA11913 for ; Wed, 13 Jun 2001 11:38:13 -0400 (EDT) From: prjain@hss.hns.com Received: from hindon.hss.co.in ([202.54.26.202]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA29614 for ; Wed, 13 Jun 2001 11:38:09 -0400 (EDT) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id f5DFcq019382; Wed, 13 Jun 2001 21:08:53 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256A6A.00547006 ; Wed, 13 Jun 2001 20:52:17 +0530 X-Lotus-FromDomain: HSS To: "Madhu Babu Brahmanapally" , megaco@fore.com Message-ID: <65256A6A.00546F01.00@sandesh.hss.hns.com> Date: Wed, 13 Jun 2001 20:56:36 +0530 Subject: RE: Concept of Stream ID Zero Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Since as per protocol, events and signals are detected on streams, then can we assume that a default stream exists when a termination is put in-service at MG. However if this default stream concept is not valid, then the statement about the stream ID 0, in the protocol needs to be modified. It uses the word "particular stream", and as per our discussion here, it means "ANY stream". It implies that at least one stream should exist and does not imply that event is to be observed on the termination as such. Take the following scenario. If a stream is created by MGC explicitly (through stream descriptor) and after that event descriptor is received without a stream ID, then default value 0 is taken and event shall be detected on any stream (here the stream created through stream descriptor) and not the termination. However, if the event descriptor is received before any stream descriptor with stream ID absent, interpret it as the event being enabled on the termination and not on any stream. If the above interpretation is not correct, the concept of default needs to be there. Thanks, Prashant Jain "Madhu Babu Brahmanapally" on 06/13/2001 08:58:35 PM To: Prashant Jain/HSS@HSS, megaco@fore.com cc: Subject: RE: Concept of Stream ID Zero Hi Prashant, IMO the first argument is definitely not true..since you can't expect an event to occur simultaneously on all the streams on the given termination. The second possibility can be true as the stream Identifier is of not much significance, the event needs to be reported if recognized on any of the streams. Infact if there is no media stream (I mean no transfer of media)..the same argument for StreamId 0 holds good, as there is no significance for the stream Id. Then The events will be detected on the termination (which maps to a physical line or one or more DS0s). -Regards Madhubabu -----Original Message----- From: owner-megaco@pit.comms.marconi.com [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of prjain@hss.hns.com Sent: Wednesday, June 13, 2001 10:21 AM To: megaco@fore.com Subject: Concept of Stream ID Zero Hi everybody, tom, brian, In the section 7.1.9 of the protocol, it is written that stream ID 0 indicates that the event to be detected is not related to a particular media stream. This statement is little confusing. Does it imply that stream ID 0 means all media streams in case multiple streams have been created on the specified termination. And if yes, does it also imply that if the specified event is detected on all media streams, then only it shall be reported to the MGC. Another interpretation of the stream ID 0 can be that the specified event is to be detected on any of the streams in case multiple streams exist simultaneously. And in this case event shall be reported to MGC if it is detected over any of the streams on the specified termination. Please clarify my doubt. Thanks, Prashant Jain From owner-megaco@fore.com Wed Jun 13 13:43:50 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28173 for ; Wed, 13 Jun 2001 13:43:49 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA08992; Wed, 13 Jun 2001 13:42:59 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id NAA08699 for megaco-list; Wed, 13 Jun 2001 13:41:21 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA08695 for ; Wed, 13 Jun 2001 13:41:19 -0400 (EDT) Received: from rumor.cps.intel.com (rumor.cps.intel.com [192.102.198.242]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA08830 for ; Wed, 13 Jun 2001 13:41:17 -0400 (EDT) Received: from SMTP (fmsmsxvs05-1.fm.intel.com [132.233.42.205]) by rumor.cps.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.40 2001/06/06 21:14:49 root Exp $) with SMTP id RAA05546; Wed, 13 Jun 2001 17:41:05 GMT Received: from fmsmsx28.fm.intel.com ([132.233.48.28]) by 132.233.48.205 (Norton AntiVirus for Internet Email Gateways 1.0) ; Wed, 13 Jun 2001 17:41:03 0000 (GMT) Received: by fmsmsx28.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 13 Jun 2001 10:41:02 -0700 Message-ID: From: "Tulpule, Naren" To: "'Troy Cauble'" , MEGACO list Subject: RE: g/sc SigID list Date: Wed, 13 Jun 2001 10:40:55 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Hi Troy, I think the g/sc way to report signal completion creates more problems than it solves. For example, if a new package with a new signal is defined, does it mean the "g"(generic) package is automatically extended to include that sigID as a possible parameter for g/sc? I hope future package creators include a "signal completion" event in the package itself for every signal, if the package has signals. Event parameters will be "Meth" and signal list ID if any. Event name can be signal name (if that's not too confusing) or sc_ or some such. Then we don't need to keep on extending g/sc. These views are mine alone, not those of Intel or Trillium. -- Naren Narendra C. Tulpule 310-442-9222 SMTS, Trillium (an Intel company) 12100 Wilshire Bl #1800 Los Angeles CA 90025 I get enough exercise just pushing my luck. -----Original Message----- From: Troy Cauble [mailto:troy@lucent.com] Sent: Wednesday, June 13, 2001 8:05 AM To: MEGACO list Subject: Re: g/sc SigID list BTW, here are some uses that I think are consistent with the syntax description in E.1.2. Anyone care to comment? This is vague enough in E.1.2 that it should be clarified with some examples. Note that a sublist uses [] not {} according to the ABNF for alternativeValue. 1.Reporting a signal outside of sequential signal list: SigID="pkg1/sig1" 2.Reporting a signal inside a sequential signal list: SigID="SignalList = 1 {pkg1/sig1}" 3.Reporting a list of signals outside of sequential signal list: SigID=[ "pkg1/sig1" , "pkg2/sig2" ] 4.Reporting a list of signals inside a sequential signal list: SigID=[ "SignalList = 1 {pkg1/sig1}", "SignalList = 2 {pkg2/sig2}" ] 5.Reporting a list of both signals and sequential signal lists: SigID=[ "pkg1/sig1" , "pkg2/sig2", "SignalList = 1 {pkg3/sig3}", "SignalList = 2 {pkg4/sig4}" ] -troy Troy Cauble wrote: > > Proposal: > > Change the Type of the g/sc SigId parameter in E.1.2 > from "list" to "string". > > Argument: > > Sections 12.1.2 and 12.2 define allowable types > for Properties and Parameters, including "String" > and "Sub-list". > > Annex E.1.2 (g/sc) defines parameter SigID as > being a "list" and references a complex syntax for > that "list" which includes nested braces. > > This specific syntax conflicts with the established > syntax for a list. > > parmValue = (EQUAL alternativeValue/ INEQUAL VALUE) > alternativeValue = ( VALUE > / LSBRKT VALUE *(COMMA VALUE) RSBRKT > ; sublist (i.e. A AND B AND ...) > / LBRKT VALUE *(COMMA VALUE) RBRKT > ; alternatives (i.e. A OR B OR ...) > / LSBRKT VALUE COLON VALUE RSBRKT ) > ; range > > If the type is redefined as "String", double quotes > will be required (IG 6.80). Within that quotedString, > the syntax could stay as defined. > > Besides the fact that this syntax is in direct conflict > of the ABNF specification, I think it is unreasonable > to allow a package to define a complex syntax to be > embedded directly in a VALUE without quoting. Parsers > should be able to parse the message down to the VALUE > level without package knowledge. > > Comments? > > -troy From owner-megaco@fore.com Wed Jun 13 14:52:12 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29251 for ; Wed, 13 Jun 2001 14:52:11 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA14366; Wed, 13 Jun 2001 14:50:59 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id OAA26363 for megaco-list; Wed, 13 Jun 2001 14:48:41 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA26357 for ; Wed, 13 Jun 2001 14:48:40 -0400 (EDT) Received: from ihemail2.firewall.lucent.com (ihemail2.lucent.com [192.11.222.163]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA14125 for ; Wed, 13 Jun 2001 14:48:36 -0400 (EDT) Received: from ihemail2.firewall.lucent.com (localhost [127.0.0.1]) by ihemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5DImcV17198 for ; Wed, 13 Jun 2001 14:48:38 -0400 (EDT) Received: from teton.mh.lucent.com (h135-3-130-2.lucent.com [135.3.130.2]) by ihemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5DImbh17194 for ; Wed, 13 Jun 2001 14:48:37 -0400 (EDT) Received: from lucent.com (pctla [135.3.130.39]) by teton.mh.lucent.com (8.8.8+Sun/8.8.8) with ESMTP id OAA25304; Wed, 13 Jun 2001 14:48:35 -0400 (EDT) Message-ID: <3B27B68E.32C42D65@lucent.com> Date: Wed, 13 Jun 2001 14:53:02 -0400 From: Terry L Anderson Organization: Lucent Technologies X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Troy Cauble CC: MEGACO list Subject: NotifyCompletion - was Re: g/sc SigID list References: <3B27676F.B9D17634@lucent.com> <3B27810B.AC9FF822@lucent.com> <3B27866D.5838126E@lucent.com> Content-Type: multipart/mixed; boundary="------------F3D27E38BF31CFE8FD70708F" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk This is a multi-part message in MIME format. --------------F3D27E38BF31CFE8FD70708F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit While were on the topic of signal completion events, what is the correct notificationReason and corresponding g/sc Meth value for the completion of a Brief signal? I assume an on/off signal normally completes with SD and NotifyCompletion={IntBySigDescr} since it ends by MGC sending a new or empty signal descriptor and other signals can end this way. I assume a timeout signal normally complete with TO and NotifyCompletion={TimeOut}. But what does a Brief signal normally end with? NC and NotifyCompletion={OtherReason}? Seems odd to use this but none of the others are appropriate. The description of NC "Not completed, other cause" seems odd since it DID complete. Or is there no way to request a completion event for Brief signals? Perhaps I do not understand the proper use of these three types. I am puzzled by Annex K's announcements being listed as "OO, TO (default)". Since these announcements will often be a voice file of finite duration, they would normally play to end of file and quit. This sounds like the description of "brief". On/Off requires a new signal descriptor to turn it off. TimeOut is "until turned off or a specific period of time elapses". That sounds like a provisioned time period rather than simply end of file reached. Or was TimeOut intended to cover this as well. If so what is Brief intended for? Troy Cauble wrote: > New proposal: > > Change the Type of the g/sc SigId parameter in E.1.2 > from "list" to "string or list of strings". > Clarify syntax with examples below. > > Objections? > > -troy > > Troy Cauble wrote: > > > > BTW, here are some uses that I think are consistent with > > the syntax description in E.1.2. Anyone care to comment? > > This is vague enough in E.1.2 that it should be clarified > > with some examples. > > > > Note that a sublist uses [] not {} according to the ABNF > > for alternativeValue. > > > > 1.Reporting a signal outside of sequential signal list: > > SigID="pkg1/sig1" > > > > 2.Reporting a signal inside a sequential signal list: > > SigID="SignalList = 1 {pkg1/sig1}" > > > > 3.Reporting a list of signals outside of sequential signal list: > > SigID=[ "pkg1/sig1" , "pkg2/sig2" ] > > > > 4.Reporting a list of signals inside a sequential signal list: > > SigID=[ "SignalList = 1 {pkg1/sig1}", "SignalList = 2 {pkg2/sig2}" ] > > > > 5.Reporting a list of both signals and sequential signal lists: > > SigID=[ "pkg1/sig1" , "pkg2/sig2", "SignalList = 1 {pkg3/sig3}", > > "SignalList = 2 {pkg4/sig4}" ] > > > > -troy > > > > Troy Cauble wrote: > > > > > > Proposal: > > > > > > Change the Type of the g/sc SigId parameter in E.1.2 > > > from "list" to "string". > > > > > > Argument: > > > > > > Sections 12.1.2 and 12.2 define allowable types > > > for Properties and Parameters, including "String" > > > and "Sub-list". > > > > > > Annex E.1.2 (g/sc) defines parameter SigID as > > > being a "list" and references a complex syntax for > > > that "list" which includes nested braces. > > > > > > This specific syntax conflicts with the established > > > syntax for a list. > > > > > > parmValue = (EQUAL alternativeValue/ INEQUAL VALUE) > > > alternativeValue = ( VALUE > > > / LSBRKT VALUE *(COMMA VALUE) RSBRKT > > > ; sublist (i.e. A AND B AND ...) > > > / LBRKT VALUE *(COMMA VALUE) RBRKT > > > ; alternatives (i.e. A OR B OR ...) > > > / LSBRKT VALUE COLON VALUE RSBRKT ) > > > ; range > > > > > > If the type is redefined as "String", double quotes > > > will be required (IG 6.80). Within that quotedString, > > > the syntax could stay as defined. > > > > > > Besides the fact that this syntax is in direct conflict > > > of the ABNF specification, I think it is unreasonable > > > to allow a package to define a complex syntax to be > > > embedded directly in a VALUE without quoting. Parsers > > > should be able to parse the message down to the VALUE > > > level without package knowledge. > > > > > > Comments? > > > > > > -troy -- ------------------------------------------------------------ Terry L Anderson mailto:tla@lucent.com Tel:908.582.7013 Fax:908.582.6729 Lucent Technologies/INS/Voice Over IP Access Networks Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla --------------F3D27E38BF31CFE8FD70708F Content-Type: text/x-vcard; charset=us-ascii; name="tla.vcf" Content-Description: Card for Terry L Anderson Content-Disposition: attachment; filename="tla.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Anderson;Terry L tel;fax:908.582.6729 tel;work:908.582.7013 x-mozilla-html:TRUE url:http://its.lucent.com/~tla org:Lucent / InterNetworking Systems;VoIP Access Networks version:2.1 email;internet:tla@lucent.com title:DMTS note:http://www.gti.net/tla or http://teton.mh.lucent.com/~tla (Lucent internal) adr;quoted-printable:;;600 Mountain Av=0D=0ARm 2B-121;Murray Hill;NJ;07974;USA x-mozilla-cpt:;21296 fn:Terry L Anderson end:vcard --------------F3D27E38BF31CFE8FD70708F-- From owner-megaco@fore.com Wed Jun 13 15:24:24 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29890 for ; Wed, 13 Jun 2001 15:24:23 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA16923; Wed, 13 Jun 2001 15:23:06 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id PAA03478 for megaco-list; Wed, 13 Jun 2001 15:21:58 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA03472 for ; Wed, 13 Jun 2001 15:21:57 -0400 (EDT) Received: from auemail1.firewall.lucent.com (auemail1.lucent.com [192.11.223.161]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA16802 for ; Wed, 13 Jun 2001 15:21:54 -0400 (EDT) Received: from auemail1.firewall.lucent.com (localhost [127.0.0.1]) by auemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5DJLtn00660 for ; Wed, 13 Jun 2001 15:21:55 -0400 (EDT) Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3]) by auemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5DJLtI00649 for ; Wed, 13 Jun 2001 15:21:55 -0400 (EDT) Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id PAA22964; Wed, 13 Jun 2001 15:21:52 -0400 (EDT) Cc: MEGACO list Received: from lucent.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id PAA22941; Wed, 13 Jun 2001 15:21:49 -0400 (EDT) Message-ID: <3B27BCD3.4B1495B7@lucent.com> Date: Wed, 13 Jun 2001 15:19:47 -0400 From: Troy Cauble Reply-To: Troy Cauble X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Terry L Anderson Original-CC: MEGACO list Subject: Re: NotifyCompletion - was Re: g/sc SigID list References: <3B27676F.B9D17634@lucent.com> <3B27810B.AC9FF822@lucent.com> <3B27866D.5838126E@lucent.com> <3B27B68E.32C42D65@lucent.com> Content-Type: multipart/mixed; boundary="------------831119B224C605AB4B308460" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk This is a multi-part message in MIME format. --------------831119B224C605AB4B308460 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Terry L Anderson wrote: > > While were on the topic of signal completion events, what is the correct > notificationReason and corresponding g/sc Meth value for the completion of > a Brief signal? I assume an on/off signal normally completes with SD and > NotifyCompletion={IntBySigDescr} since it ends by MGC sending a new or > empty signal descriptor and other signals can end this way. I assume a > timeout signal normally complete with TO and NotifyCompletion={TimeOut}. > > But what does a Brief signal normally end with? NC and > NotifyCompletion={OtherReason}? Seems odd to use this but none of the > others are appropriate. The description of NC "Not completed, other > cause" seems odd since it DID complete. Or is there no way to request a > completion event for Brief signals? > > Perhaps I do not understand the proper use of these three types. I am > puzzled by Annex K's announcements being listed as "OO, TO (default)". This was changed with IG section 9.1. > Since these announcements will often be a voice file of finite duration, > they would normally play to end of file and quit. This sounds like the > description of "brief". On/Off requires a new signal descriptor to turn > it off. TimeOut is "until turned off or a specific period of time > elapses". That sounds like a provisioned time period rather than simply > end of file reached. Or was TimeOut intended to cover this as well. If > so what is Brief intended for? There was a discussion of the different signal types in the thread "SignalType ?" from about 1/15/01 to 1/23/01. Christian clarified some things there (IMO), but not everyone agreed. I'm attaching one of his posts below. -troy --------------831119B224C605AB4B308460 Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Received: from grubby.research.bell-labs.com by wink.ho.lucent.com (SMI-8.6/EMS-1.5 sol2) id VAA23848; Sun, 21 Jan 2001 21:41:03 -0500 Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Sun Jan 21 21:39:53 EST 2001 Received: from penguin-ext.wise.edt.ericsson.se ([194.237.142.110]) by dusty; Sun Jan 21 21:39:52 EST 2001 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id f0M2dod23067; Mon, 22 Jan 2001 03:39:50 +0100 (MET) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id DAA28557; Mon, 22 Jan 2001 03:39:50 +0100 (MET) Received: from ericsson.com ([146.11.86.237]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id DAA17897; Mon, 22 Jan 2001 03:39:38 +0100 (MET) Message-ID: <3A6B8568.5682A40D@ericsson.com> Date: Mon, 22 Jan 2001 11:57:12 +1100 From: Christian Groves X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Troy Cauble CC: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Re: SignalType ? References: <5E5172B4DE05D311B3AB0008C75DA9410561BC2E@edeacnt100.eed.ericsson.se> <3A67C06A.6B47E2A0@ericsson.com> <3A687D68.4E97B34E@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit G'Day Troy, Please see my answers below marked CHG. Cheers, Christian Troy Cauble wrote: > > Christian Groves wrote: > > > > Hello Troy, > > > > The different between duration & OO, TO, BR is that duration gives times > > and OO, TO, BR give essentially a number of times that something will > > play. > > > > ie. S1 is a signal that plays a cadence for 100ms > > {Duration 50ms, Signal Type = Br} would play half the signal > > {Duration 150ms, Signal Type = Br} would play one instance of the signal > > and 50ms of silence. > > {Duration 150ms, Signal Type = TO} would play one and a half instances > > of the signal. > > {Signal Type = OO} would keep playing instances of the signal. > > > > The H.248 is different to MGCP. We had alot of disucssion what br, to & > > oo meant during the development of the protocol. > > > > Christian, > > Thanks, this does clarify some things. The different > SignalType values do make a difference in your 150ms > examples. But that's a funny way to specify silence! [CHG] Yes it is a funny way. Its a function of the protocol but I don't expect that you'd use it that way. > > Is it correct then, that the ONLY behavioral difference > between signals that are defined as Brief or Timeout > in their package definitions, is their behavior when > asked to play longer than their default duration with > no explicit SignalType specification? [CHG] Yes. > > { Duration 150ms } ; Note: No SignalType > > Also, is it correct that all three signal types are > suitable for notifyCompletion? [CHG] Yes I believe so. All signals have a finite period of time and the MGC might like to be notified once the signals plays successfully. > > -troy --------------831119B224C605AB4B308460-- From owner-megaco@fore.com Wed Jun 13 15:50:16 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00309 for ; Wed, 13 Jun 2001 15:50:15 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA19158; Wed, 13 Jun 2001 15:49:13 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id PAA09861 for megaco-list; Wed, 13 Jun 2001 15:48:16 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA09857 for ; Wed, 13 Jun 2001 15:48:14 -0400 (EDT) Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA19024 for ; Wed, 13 Jun 2001 15:48:11 -0400 (EDT) Received: from hoemail1.firewall.lucent.com (localhost [127.0.0.1]) by hoemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5DJmC800294 for ; Wed, 13 Jun 2001 15:48:12 -0400 (EDT) Received: from teton.mh.lucent.com (h135-3-130-2.lucent.com [135.3.130.2]) by hoemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5DJmCe00273 for ; Wed, 13 Jun 2001 15:48:12 -0400 (EDT) Received: from lucent.com (pctla [135.3.130.39]) by teton.mh.lucent.com (8.8.8+Sun/8.8.8) with ESMTP id PAA00465; Wed, 13 Jun 2001 15:48:09 -0400 (EDT) Message-ID: <3B27C485.EA0935D9@lucent.com> Date: Wed, 13 Jun 2001 15:52:37 -0400 From: Terry L Anderson Organization: Lucent Technologies X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Troy Cauble CC: MEGACO list Subject: Re: NotifyCompletion - was Re: g/sc SigID list References: <3B27676F.B9D17634@lucent.com> <3B27810B.AC9FF822@lucent.com> <3B27866D.5838126E@lucent.com> <3B27B68E.32C42D65@lucent.com> <3B27BCD3.4B1495B7@lucent.com> Content-Type: multipart/mixed; boundary="------------ED0E7835C6F9C125FDFBDE34" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk This is a multi-part message in MIME format. --------------ED0E7835C6F9C125FDFBDE34 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Troy Cauble wrote: > Terry L Anderson wrote: > > > > While were on the topic of signal completion events, what is the correct > > notificationReason and corresponding g/sc Meth value for the completion of > > a Brief signal? I assume an on/off signal normally completes with SD and > > NotifyCompletion={IntBySigDescr} since it ends by MGC sending a new or > > empty signal descriptor and other signals can end this way. I assume a > > timeout signal normally complete with TO and NotifyCompletion={TimeOut}. > > > > But what does a Brief signal normally end with? NC and > > NotifyCompletion={OtherReason}? Seems odd to use this but none of the > > others are appropriate. The description of NC "Not completed, other > > cause" seems odd since it DID complete. Or is there no way to request a > > completion event for Brief signals? > > > > Perhaps I do not understand the proper use of these three types. I am > > puzzled by Annex K's announcements being listed as "OO, TO (default)". > > This was changed with IG section 9.1. Yes, but only removed OO. As I say below I don't understand how TO applies to a finite-length, non-repeating voice announcement file like "Please enter the number you are calling". > > Since these announcements will often be a voice file of finite duration, > > they would normally play to end of file and quit. This sounds like the > > description of "brief". On/Off requires a new signal descriptor to turn > > it off. TimeOut is "until turned off or a specific period of time > > elapses". That sounds like a provisioned time period rather than simply > > end of file reached. Or was TimeOut intended to cover this as well. If > > so what is Brief intended for? > > There was a discussion of the different signal types in the > thread "SignalType ?" from about 1/15/01 to 1/23/01. > Christian clarified some things there (IMO), but not everyone > agreed. > > I'm attaching one of his posts below. This explains some things but none of the cases apply to announcements or finite-length, non-repeating voice files. Is it assumed that if optional Duration is NOT specified for a TO then the assumed duration is exactly one instance of the file? But then wouldn't Brief without Duration mean the same thing? If so, I guess g/sc would use Meth=TO for both TimeOut and Brief completions? > > > -troy > > ------------------------------------------------------------------------ > > Subject: Re: SignalType ? > Date: Mon, 22 Jan 2001 11:57:12 +1100 > From: Christian Groves > To: Troy Cauble > CC: MEGACO@STANDARDS.NORTELNETWORKS.COM > References: <5E5172B4DE05D311B3AB0008C75DA9410561BC2E@edeacnt100.eed.ericsson.se> <3A67C06A.6B47E2A0@ericsson.com> <3A687D68.4E97B34E@lucent.com> > > G'Day Troy, > > Please see my answers below marked CHG. > > Cheers, Christian > > Troy Cauble wrote: > > > > Christian Groves wrote: > > > > > > Hello Troy, > > > > > > The different between duration & OO, TO, BR is that duration gives times > > > and OO, TO, BR give essentially a number of times that something will > > > play. > > > > > > ie. S1 is a signal that plays a cadence for 100ms > > > {Duration 50ms, Signal Type = Br} would play half the signal > > > {Duration 150ms, Signal Type = Br} would play one instance of the signal > > > and 50ms of silence. > > > {Duration 150ms, Signal Type = TO} would play one and a half instances > > > of the signal. > > > {Signal Type = OO} would keep playing instances of the signal. > > > > > > The H.248 is different to MGCP. We had alot of disucssion what br, to & > > > oo meant during the development of the protocol. > > > > > > > Christian, > > > > Thanks, this does clarify some things. The different > > SignalType values do make a difference in your 150ms > > examples. But that's a funny way to specify silence! > > [CHG] Yes it is a funny way. Its a function of the protocol but I don't > expect that you'd use it that way. > > > > > Is it correct then, that the ONLY behavioral difference > > between signals that are defined as Brief or Timeout > > in their package definitions, is their behavior when > > asked to play longer than their default duration with > > no explicit SignalType specification? > [CHG] Yes. > > > > > { Duration 150ms } ; Note: No SignalType > > > > Also, is it correct that all three signal types are > > suitable for notifyCompletion? > [CHG] Yes I believe so. All signals have a finite period of time and the > MGC might like to be notified once the signals plays successfully. > > > > > -troy -- ------------------------------------------------------------ Terry L Anderson mailto:tla@lucent.com Tel:908.582.7013 Fax:908.582.6729 Lucent Technologies/INS/Voice Over IP Access Networks Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla --------------ED0E7835C6F9C125FDFBDE34 Content-Type: text/x-vcard; charset=us-ascii; name="tla.vcf" Content-Description: Card for Terry L Anderson Content-Disposition: attachment; filename="tla.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Anderson;Terry L tel;fax:908.582.6729 tel;work:908.582.7013 x-mozilla-html:TRUE url:http://its.lucent.com/~tla org:Lucent / InterNetworking Systems;VoIP Access Networks version:2.1 email;internet:tla@lucent.com title:DMTS note:http://www.gti.net/tla or http://teton.mh.lucent.com/~tla (Lucent internal) adr;quoted-printable:;;600 Mountain Av=0D=0ARm 2B-121;Murray Hill;NJ;07974;USA x-mozilla-cpt:;21296 fn:Terry L Anderson end:vcard --------------ED0E7835C6F9C125FDFBDE34-- From owner-megaco@fore.com Wed Jun 13 19:06:32 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03186 for ; Wed, 13 Jun 2001 19:06:31 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id TAA00138; Wed, 13 Jun 2001 19:05:04 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id SAA12004 for megaco-list; Wed, 13 Jun 2001 18:57:53 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA11995 for ; Wed, 13 Jun 2001 18:57:52 -0400 (EDT) From: cheryl2@ns2.ans.co.kr Received: from ns2.ans.co.kr ([210.126.104.74]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA29782 for ; Wed, 13 Jun 2001 18:57:47 -0400 (EDT) Received: from ns2.ans.co.kr (slip129-37-78-141.ny.us.prserv.net [129.37.78.141]) by ns2.ans.co.kr (8.9.3+Sun/8.9.1) with SMTP id HAA01567; Thu, 14 Jun 2001 07:53:38 +0900 (KST) Message-Id: <200106132253.HAA01567@ns2.ans.co.kr> Received: from amanda@hotmail.com by judso@hotmail.com (8.8.5/8.6.5) with SMTP id GAA06069 for ; Tue, 12 Jun 2001 15:49:41 -0600 (EST) To: judso@hotmail.com Date: Tue, 12 Jun 01 15:49:41 EST Subject: hi Reply-To: amanda@hotmail.com Comments: Authenticated sender is Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Hi. I am a 19 year old strawberry blonde. I LOVE to suck cock, and have cum splattered all over my face! Want to watch me fuck and suck live? :) just click here: Its only $1.95. My hot pussy is waiting for you! So what are you waiting for? http://209.195.63.163/nasty2/7/index.html From owner-megaco@fore.com Thu Jun 14 03:59:05 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23314 for ; Thu, 14 Jun 2001 03:59:05 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id DAA13762; Thu, 14 Jun 2001 03:57:50 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id DAA13610 for megaco-list; Thu, 14 Jun 2001 03:46:53 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id DAA13605 for ; Thu, 14 Jun 2001 03:46:52 -0400 (EDT) Received: from ns2.netsland.net ([210.14.228.23]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with SMTP id DAA13402 for ; Thu, 14 Jun 2001 03:46:48 -0400 (EDT) Message-Id: <200106140746.DAA13402@mailgate.pit.comms.marconi.com> Received: (qmail 15678 invoked by uid 0); 14 Jun 2001 01:59:16 -0000 Received: from unknown (HELO plain) (61.153.120.107) by ns2.netsland.net with SMTP; 14 Jun 2001 01:59:16 -0000 From: wayne To: megadestroyer@hotmail.com Subject: Manuf. Production/Contrl Software For $1,495.00. Date: Wed, 13 Jun 2001 21:56:15 Mime-Version: 1.0 Content-Type: text/plain; charset="DEFAULT_CHARSET" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Master, a complete, user friendly Windows based software package, can manage and control your operation from sales quote to shipment. For one week only, Job Master, normally $2,495.00, is on sale for a total price of $1,495.00. In order for you to receive this $1,000.00 savings we must have your order by June 22th. Job Master is designed specifically for small to medium sized manufacturers, and costs many thousands of dollars less than any other even remotely comparable software package. Following is a list of features. If you have any questions, would like to discuss the package further, or if you would like to obtain our Web site address for a total walk through of the program, please call me directly at (661) 286-0041 (please do not E Mail me back. I may not get your message if you simply hit "Reply" and respond to this message via return E Mail). By way of background, we are a software company, which for some years has specialized in the development of custom software, primarily for small to medium sized manufacturers. Job Master is a distillation of over a million and a half dollars of software we have developed to control and manage the production of our manufacturing clients. Job Master contains the following features: 1. QUOTATION MODULE. In this module, quotes are developed, modified, and produced for sending to your client. A history is kept of all quotes for future reference, or modification for other clients. All quotations and revisions are "auto numbered," including versions. The quotes section allows for the entry of parts/processes, and costing of each, including materials, labor, markup, and taxes. Inventory status can be accessed from this section for reference. 2. SALES ORDER. Once a quotation is accepted, the final quotation information can be transformed into a Sales Order for your client's signature on a "point and click" basis. The Sales Order can be modified and re issued if necessary. A history if kept of all Sales Orders for future reference, or modification for other clients. All sales orders and revisions are "auto numbered," including versions. Inventory status can be accessed from this section for reference. 3. CUSTOMER LETTERS can be created from the Quotation and Sales Order sections. 4. SHOP TRAVELER/WORK ORDER. Once a Sales Order is accepted, the sales order information can be transformed into a shop traveler/work order on a "point and click" basis. Each item on the Sales Order becomes a shop traveler/work order, with each step of production of the item then listed on the traveler/work order. Each such traveler/work order is tied back into the Sales Order. The shop traveler/work order allows for the entry of line items, and notes on each line item. The shop traveler/work order contains a "notes" section. The Shop traveler/work order allows for the storing or attachment of drawings to the traveler/work order. The shop traveler/work order also contains a "drop down," from which standard processes can be selected for inclusion on the shop traveler/work order. The shop traveler/work order numbers progress in order of production sequence, and re numbers them if new steps are added. The shop traveler/work order allows for change orders or revisions, and! ! numbers changes in sequence of he original shop traveler/work order number; i.e., 100, 100-1, 100-2, etc. All shop traveler/work orders and related revisions are retained in memory for future reference. The shop traveler/work order is bar coded for tracking of production step by step, and production of ongoing client status reports. Bar coding includes the ability for an employee to "swipe" their own ID bar code for recording in the system as to who upgraded what step. The shop traveler/work order function also allows for manual update of production status. The shop traveler/work order allows for quality control sign off, and the final production of certifications, either from a "canned" list, or hand typed in on a case by case basis. 5. INVENTORY. The application includes an inventory section, which allows operations to check materials inventory in and out. The inventory section allows for the comparison of inventory received against a P.O., and produces an "overage/underage" report of inventory received as compared against the P.O. The inventory section allows for the setting of minimum (re-order now!) and maximum inventory amounts, and produces reports showing what inventory needs to be ordered, as well as inventory that is at or above the maximum set to have in house. The inventory section also tracks "partially shipped" orders, which are tied in to the shipping function. This section shows how much completed product under a particular order has been actually shipped to a client, and how much remains to be shipped. The balance is adjusted as shipments are made. 6. REQUEST FOR PURCHASE. The application allows operators to produce a Request For Purchase for accounting for any inventory items, which need to be ordered. Inventory items have a drop down of approved vendors for each item. 7. REQUEST FOR BID. The application allows operators to produce a Request For Bid for accounting to send to Vendors for any inventory items, which need to be ordered. Inventory items have a drop down of approved vendors for each item to which Requests For Bid can be sent. 8. INVOICE. The application produces an invoice/invoice detail for all completed items ready to be billed/shipped to clients. 9. PRODUCTION OUTPUT STATUS. The application produces a date range selectable report on how much product, and the value of the product, which was completed during a selected date range. The application also produces a report on how many orders, and the value of those orders, which remain to be completed during a selected date range. 10. The application produces SHIPPING DOCUMENTS as per selected shippers, and produces a PACKING SLIP. 11. The application has a "FIND" FUNCTION in selected sections, allowing for searches by customer name, work order number, etc. 12. The application has "AUTO FILL;" i.e., when an operator starts to type in a name, number, etc. all related information auto fills after the first few letters or numbers are typed in. Job Master is currently being sold in the marketplace for $2,495.00 per package. However, if we receive your order by June 22th, your total price will be $1,495.00 Again, if you have any questions at all, or would like to place your order, please call me on my direct line, (661) 286-0041. Thank you! Wayne D. McFarland Application Sales, Inc. ---------------------------------------------------------------------- You have received this newsletter because you signed up for updates on our tracking software. If you want to unsubscribe from this newsletter, please send a reply email with "REMOVE" in the subject line. From owner-megaco@fore.com Thu Jun 14 04:10:17 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23401 for ; Thu, 14 Jun 2001 04:10:16 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id EAA14350; Thu, 14 Jun 2001 04:09:16 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id EAA15058 for megaco-list; Thu, 14 Jun 2001 04:06:55 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id EAA15053 for ; Thu, 14 Jun 2001 04:06:54 -0400 (EDT) Received: from hotmail.com (f153.law14.hotmail.com [64.4.21.153]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id EAA14160 for ; Thu, 14 Jun 2001 04:06:51 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 14 Jun 2001 01:06:48 -0700 Received: from 61.132.62.80 by lw14fd.law14.hotmail.msn.com with HTTP; Thu, 14 Jun 2001 08:06:48 GMT X-Originating-IP: [61.132.62.80] From: "mu lj" To: taylor@nortelnetworks.com Cc: megaco@fore.com Date: Thu, 14 Jun 2001 16:06:48 +0800 Mime-Version: 1.0 Content-Type: text/plain; charset=gb2312; format=flowed Message-ID: X-OriginalArrivalTime: 14 Jun 2001 08:06:48.0418 (UTC) FILETIME=[F5EFA420:01C0F4A8] Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Tom Taylor: There is a conference call, user1 and user2 in MG1,user3 in MG2, the conference resources in MG3. 1. How to describe a conference resource use terminationID? 2. How to choose a RTP resource in a conference resource? 3. What is Call flows about this conference call? _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. From owner-megaco@fore.com Thu Jun 14 05:09:07 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23876 for ; Thu, 14 Jun 2001 05:09:06 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id FAA16160; Thu, 14 Jun 2001 05:08:14 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id FAA19822 for megaco-list; Thu, 14 Jun 2001 05:06:46 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id FAA19818 for ; Thu, 14 Jun 2001 05:06:44 -0400 (EDT) Received: from hotmail.com (f172.law14.hotmail.com [64.4.21.172]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id FAA16058 for ; Thu, 14 Jun 2001 05:06:42 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 14 Jun 2001 02:06:43 -0700 Received: from 61.132.62.80 by lw14fd.law14.hotmail.msn.com with HTTP; Thu, 14 Jun 2001 09:06:42 GMT X-Originating-IP: [61.132.62.80] From: "mu lj" To: taylor@nortelnetworks.com Cc: megaco@fore.com Subject: question about conference Date: Thu, 14 Jun 2001 17:06:42 +0800 Mime-Version: 1.0 Content-Type: text/plain; charset=gb2312; format=flowed Message-ID: X-OriginalArrivalTime: 14 Jun 2001 09:06:43.0131 (UTC) FILETIME=[548D50B0:01C0F4B1] Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Tom Taylor: There is a conference call, user1 and user2 in MG1,user3 in MG2, the conference resources in MG3. 1. How to describe a conference resource use terminationID? 2. How to choose a RTP resource in a conference resource? 3. What is Call flows about this conference call? _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. From owner-megaco@fore.com Thu Jun 14 05:46:07 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24074 for ; Thu, 14 Jun 2001 05:46:06 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id FAA17194; Thu, 14 Jun 2001 05:45:01 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id FAA22450 for megaco-list; Thu, 14 Jun 2001 05:44:06 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id FAA22446 for ; Thu, 14 Jun 2001 05:44:04 -0400 (EDT) Received: from brahma01.netbrahma.com ([164.164.70.67]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id FAA17092 for ; Thu, 14 Jun 2001 05:43:59 -0400 (EDT) Received: from ATANU ([172.16.72.98]) by brahma01.netbrahma.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LQ03J132; Thu, 14 Jun 2001 15:12:56 +0530 Message-ID: <04b401c0f4b7$9619ce40$624810ac@netbrahma.com> Reply-To: "Atanum" From: "Atanum" To: Cc: "Rosen, Brian" , "Madhu Babu Brahmanapally" Subject: resending megaco messge...after timeout.. Date: Thu, 14 Jun 2001 15:21:14 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_04AB_01C0F4E5.A68228D0" 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 Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_04AB_01C0F4E5.A68228D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I have one basic query.... Suppose a Megaco Message structure contains mutiple transactions and = with each transactions having its own transaction-id.. No if a particular transaction of that MegacoMessage structure do not = get a reply..in that case do we send the whole=20 Message structure again( i mean both the Transactions whose reply we = already got + the transaction whose reply is not received) or we extract the transaction whose reply we haven't received and sent it = encapsulating with the message structure header please see it in the below Message structure =3D Message Header1 + Transaction1 + Transaction2 + = Transaction 3 Say Transaction1 and Transaction2 received the reply..and we need to = recend Transaction3.. Do we send it as Message structure =3D MessageHeader1 + Transaction1+Transaction2 + = Transaction3 or Message structure=3D MessageHeader1 + Transaction3 or Message structure=3D MessageHeader2(new header) + Transaction3 If somebody ans this above query.. it will be very helpful.. Thanking in advance.. Atanu Mondal Net Brahma Technologies Internext Networking Software A Microland Group Venture atanum@netbrahma.com www.netbrahma.com Tel : 91.80. 552 1451 Fax : 91.80. 553 7233 ------=_NextPart_000_04AB_01C0F4E5.A68228D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
I have one basic query....
Suppose a Megaco Message structure = contains mutiple=20 transactions and with each transactions having its own=20 transaction-id..
No if a particular transaction of that=20 MegacoMessage structure do not get a reply..in that case do we send the = whole=20
Message structure again( i mean both = the=20 Transactions whose reply we already got + the transaction whose reply is = not=20 received)
 
or
 we extract the transaction whose = reply we=20 haven't received and sent it encapsulating with the message structure=20 header
please see it in the below
 
Message structure =3D Message Header1 + = Transaction1=20 + Transaction2 + Transaction 3
 
Say Transaction1 and Transaction2 = received the=20 reply..and we need to recend Transaction3..
 
Do we send it as
 Message structure =3D = MessageHeader1 +=20 Transaction1+Transaction2 + Transaction3
 
or
 
Message structure=3D MessageHeader1 +=20 Transaction3
 
or
 
Message structure=3D MessageHeader2(new = header) +=20 Transaction3
 
If somebody ans this above query.. it = will be very=20 helpful..
Thanking in advance..
 
 
Atanu Mondal
Net Brahma=20 Technologies
Internext Networking Software
A Microland Group=20 Venture
atanum@netbrahma.com
www.netbrahma.com
Tel : 91.80. = 552=20 1451
Fax : 91.80. 553 7233
------=_NextPart_000_04AB_01C0F4E5.A68228D0-- From owner-megaco@fore.com Thu Jun 14 09:10:55 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27794 for ; Thu, 14 Jun 2001 09:10:55 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA25876; Thu, 14 Jun 2001 09:10:01 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id JAA17776 for megaco-list; Thu, 14 Jun 2001 09:05:53 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA17771 for ; Thu, 14 Jun 2001 09:05:52 -0400 (EDT) Received: from huginn.ctccom.net (Huginn.CTCCom.net [207.190.194.11]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA25479 for ; Thu, 14 Jun 2001 09:05:49 -0400 (EDT) Received: from MBRAHMANAPALLY ([64.69.123.121]) by huginn.ctccom.net (Mirapoint) with SMTP id ACV19374; Thu, 14 Jun 2001 09:05:39 -0400 (EDT) From: "Madhu Babu Brahmanapally" To: "'Atanum'" , Cc: "'Rosen, Brian'" Subject: RE: resending Megaco message...after timeout.. Date: Thu, 14 Jun 2001 09:07:22 -0400 Message-ID: <003201c0f4d2$f40e9600$c500a8c0@MBRAHMANAPALLY> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0033_01C0F4B1.6CFCF600" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <04b401c0f4b7$9619ce40$624810ac@netbrahma.com> Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0033_01C0F4B1.6CFCF600 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Atanu, The transactions in a message are treated independently. There is no order implied, there is no application or protocol acknowledgement of a message. Its only a means of clubbing multiple transactions from one source to a specific destination. If there is no response for a specific transaction, only that particular transaction need to be retransmitted. The Transactions across a given message doesn't share the fate. -Regards Madhubabu -----Original Message----- From: Atanum [mailto:atanum@netbrahma.com] Sent: Thursday, June 14, 2001 5:51 AM To: megaco@fore.com Cc: Rosen, Brian; Madhu Babu Brahmanapally Subject: resending megaco messge...after timeout.. Hi, I have one basic query.... Suppose a Megaco Message structure contains mutiple transactions and with each transactions having its own transaction-id.. No if a particular transaction of that MegacoMessage structure do not get a reply..in that case do we send the whole Message structure again( i mean both the Transactions whose reply we already got + the transaction whose reply is not received) or we extract the transaction whose reply we haven't received and sent it encapsulating with the message structure header please see it in the below Message structure = Message Header1 + Transaction1 + Transaction2 + Transaction 3 Say Transaction1 and Transaction2 received the reply..and we need to recend Transaction3.. Do we send it as Message structure = MessageHeader1 + Transaction1+Transaction2 + Transaction3 or Message structure= MessageHeader1 + Transaction3 or Message structure= MessageHeader2(new header) + Transaction3 If somebody ans this above query.. it will be very helpful.. Thanking in advance.. Atanu Mondal Net Brahma Technologies Internext Networking Software A Microland Group Venture atanum@netbrahma.com www.netbrahma.com Tel : 91.80. 552 1451 Fax : 91.80. 553 7233 ------=_NextPart_000_0033_01C0F4B1.6CFCF600 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi=20 Atanu,
 
The = transactions in a=20 message are treated independently.  There is no  order = implied, there=20 is no application or protocol acknowledgement of  a message. Its only a means of clubbing multiple = transactions=20 from one source to a specific destination. If there is no response for a = specific transaction, only that particular transaction need to be = retransmitted.=20 The Transactions across a given message doesn't share the=20 fate.
 
-Regards
Madhubabu
-----Original Message-----
From: Atanum=20 [mailto:atanum@netbrahma.com]
Sent: Thursday, June 14, 2001 = 5:51=20 AM
To: megaco@fore.com
Cc: Rosen, Brian; Madhu = Babu=20 Brahmanapally
Subject: resending megaco messge...after=20 timeout..

Hi,
I have one basic = query....
Suppose a Megaco Message structure = contains=20 mutiple transactions and with each transactions having its own=20 transaction-id..
No if a particular transaction of = that=20 MegacoMessage structure do not get a reply..in that case do we send = the whole=20
Message structure again( i mean both = the=20 Transactions whose reply we already got + the transaction whose reply = is not=20 received)
 
or
 we extract the transaction = whose reply we=20 haven't received and sent it encapsulating with the message structure=20 header
please see it in the = below
 
Message structure =3D Message Header1 = +=20 Transaction1 + Transaction2 + Transaction 3
 
Say Transaction1 and Transaction2 = received the=20 reply..and we need to recend Transaction3..
 
Do we send it as
 Message structure =3D = MessageHeader1 +=20 Transaction1+Transaction2 + Transaction3
 
or
 
Message structure=3D MessageHeader1 + = Transaction3
 
or
 
Message structure=3D = MessageHeader2(new header) +=20 Transaction3
 
If somebody ans this above query.. it = will be=20 very helpful..
Thanking in advance..
 
 
Atanu Mondal
Net Brahma=20 Technologies
Internext Networking Software
A Microland Group=20 Venture
atanum@netbrahma.com
www.netbrahma.com
Tel : = 91.80. 552=20 1451
Fax : 91.80. 553 7233
------=_NextPart_000_0033_01C0F4B1.6CFCF600-- From owner-megaco@fore.com Thu Jun 14 10:50:38 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01342 for ; Thu, 14 Jun 2001 10:50:37 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA03835; Thu, 14 Jun 2001 10:47:31 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA10972 for megaco-list; Thu, 14 Jun 2001 10:44:09 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA10961 for ; Thu, 14 Jun 2001 10:44:08 -0400 (EDT) Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA03503 for ; Thu, 14 Jun 2001 10:44:00 -0400 (EDT) Received: from ihemail1.firewall.lucent.com (localhost [127.0.0.1]) by ihemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5EEi0020935 for ; Thu, 14 Jun 2001 10:44:01 -0400 (EDT) Received: from teton.mh.lucent.com (h135-3-130-2.lucent.com [135.3.130.2]) by ihemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5EEi0x20918 for ; Thu, 14 Jun 2001 10:44:00 -0400 (EDT) Received: from lucent.com (pctla [135.3.130.39]) by teton.mh.lucent.com (8.8.8+Sun/8.8.8) with ESMTP id KAA06378 for ; Thu, 14 Jun 2001 10:44:00 -0400 (EDT) Message-ID: <3B28CEB4.1B747AB9@lucent.com> Date: Thu, 14 Jun 2001 10:48:21 -0400 From: Terry L Anderson Organization: Lucent Technologies X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Megaco Mailing List Subject: Turning off NotifyCompletion Content-Type: multipart/mixed; boundary="------------52ACB6DB75AD2DA1828D2303" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk This is a multi-part message in MIME format. --------------52ACB6DB75AD2DA1828D2303 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit If I read 7.1.11 paragraph 3 correctly, omitting NotifyCompletion while g/sc is active results in notifies for OtherReason but not the other three, that is, omitting it is equivalent to NotifyCompletion{OtherReason} as though it was a default. I assume that NotifyCompletion{TimeOut} turn off notify for OtherReason. But I see no way to indicate NO notifies, not even for OtherReason. The list cannot be empty, that is, NotifyCompletion{} is not allowed. One can, of course, cancel g/sc but that turns off notifies for all signals. It seems there should be a way to turn off all notifies for a specific signal. Why was OtherReason made a default with no way to turn it off without turning on one other? -- ------------------------------------------------------------ Terry L Anderson mailto:tla@lucent.com Tel:908.582.7013 Fax:908.582.6729 Lucent Technologies/INS/Voice Over IP Access Networks Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla --------------52ACB6DB75AD2DA1828D2303 Content-Type: text/x-vcard; charset=us-ascii; name="tla.vcf" Content-Description: Card for Terry L Anderson Content-Disposition: attachment; filename="tla.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Anderson;Terry L tel;fax:908.582.6729 tel;work:908.582.7013 x-mozilla-html:TRUE url:http://its.lucent.com/~tla org:Lucent / InterNetworking Systems;VoIP Access Networks version:2.1 email;internet:tla@lucent.com title:DMTS note:http://www.gti.net/tla or http://teton.mh.lucent.com/~tla (Lucent internal) adr;quoted-printable:;;600 Mountain Av=0D=0ARm 2B-121;Murray Hill;NJ;07974;USA x-mozilla-cpt:;21296 fn:Terry L Anderson end:vcard --------------52ACB6DB75AD2DA1828D2303-- From owner-megaco@fore.com Thu Jun 14 21:19:09 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12535 for ; Thu, 14 Jun 2001 21:19:09 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id VAA17425; Thu, 14 Jun 2001 21:18:00 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id VAA27265 for megaco-list; Thu, 14 Jun 2001 21:12:23 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id VAA27258 for ; Thu, 14 Jun 2001 21:12:21 -0400 (EDT) Received: from smtp.huawei.com ([202.96.135.132]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id VAA17092 for ; Thu, 14 Jun 2001 21:12:16 -0400 (EDT) Received: from q173262 ([10.105.28.1]) by smtp.huawei.com (Netscape Messaging Server 4.15) with SMTP id GEY5RD01.R0A for ; Fri, 15 Jun 2001 09:06:49 +0800 Message-ID: <001b01c0f538$1b999e80$011c690a@huawei.com> From: "Qiu Xiuping" To: Subject: Where's the latest Implementor's Guide? Date: Fri, 15 Jun 2001 09:11:29 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mailman.pit.comms.marconi.com id VAA27259 Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: 8bit Hello, Dear All. Where's the latest implementor's guide? And after RFC 3015, any data structure changing or protocol changing? Thank you, Qiu Xiuping From owner-megaco@fore.com Fri Jun 15 03:21:46 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01534 for ; Fri, 15 Jun 2001 03:21:46 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id DAA27923; Fri, 15 Jun 2001 03:19:31 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id DAA17013 for megaco-list; Fri, 15 Jun 2001 03:17:10 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id DAA16997; Fri, 15 Jun 2001 03:17:08 -0400 (EDT) Received: from jumpjive.com (ads.jumpjive.com [63.66.132.248]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id DAA27780; Fri, 15 Jun 2001 03:17:05 -0400 (EDT) Received: from localhost (mail@localhost) by jumpjive.com (8.11.0/8.11.0) with SMTP id f5F79rE12738; Fri, 15 Jun 2001 03:09:53 -0400 X-Authentication-Warning: jjdb.jumpjive.com: mail owned process doing -bs Received: by jjdb.jumpjive.com (bulk_mailer v1.13); Thu, 14 Jun 2001 20:03:22 -0400 Received: (from majordomo@localhost) by jumpjive.com (8.11.0/8.11.0) id f5F03MW17699 for jumpjive-members-outgoing; Thu, 14 Jun 2001 20:03:22 -0400 X-Authentication-Warning: jjdb.jumpjive.com: majordomo set sender to owner-jumpjive-members@jumpjive.com using -f Received: (from root@localhost) by jumpjive.com (8.11.0/8.11.0) id f5F03Mf17695 for jumpjive-members; Thu, 14 Jun 2001 20:03:22 -0400 Date: Thu, 14 Jun 2001 20:03:22 -0400 Message-Id: <200106150003.f5F03Mf17695@jumpjive.com> Subject: You've been selected! From: offers@jumpjive.com Reply-To: offers@jumpjive.com To: undisclosed-recipients:; Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Now You Can Talk About Whatever You Want Whenever, With Voice Stream. Get an exclusive, limited-time Wireless Cell Phone Package including a free Internet-Ready VoiceStream Phone With PingPong Text Messaging. Just click below: http://wireless.freeze.com/transactvs Please note: not all US markets are served by VoiceStream, if you are in a non-VoiceStream area you will receive another great offer, from another well known company. Along with your free VoiceStream digital cell phone you get: Free Nationwide Long Distance 1000 Free Weekend Minutes Exclusive PingPong Text Messaging Service Free Car Charger and Free Belt Clip Free Hands-Free Kit Lowest VoiceStream Rates Available Nation Wide! This is by far the quickest, easiest and least expensive way to get a cell phone from an industry-leading company who you know and trust. Just click below: http://wireless.freeze.com/transactvs Sincerely, Rob Weber, President, Freeze Wireless To unsubscribe, send an e-mail to unsubscribe@jumpjive.com. From owner-megaco@fore.com Fri Jun 15 07:34:42 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03439 for ; Fri, 15 Jun 2001 07:34:41 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id HAA06982; Fri, 15 Jun 2001 07:33:46 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id HAA11612 for megaco-list; Fri, 15 Jun 2001 07:32:00 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id HAA11602; Fri, 15 Jun 2001 07:31:58 -0400 (EDT) Received: from jumpjive.com (ads.jumpjive.com [63.66.132.248]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id HAA06838; Fri, 15 Jun 2001 07:31:55 -0400 (EDT) Received: from localhost (mail@localhost) by jumpjive.com (8.11.0/8.11.0) with SMTP id f5FBOXr21291; Fri, 15 Jun 2001 07:24:33 -0400 X-Authentication-Warning: jjdb.jumpjive.com: mail owned process doing -bs Received: by jjdb.jumpjive.com (bulk_mailer v1.13); Fri, 15 Jun 2001 02:57:56 -0400 Received: (from majordomo@localhost) by jumpjive.com (8.11.0/8.11.0) id f5EN0Ps13333 for jumpjive-members-outgoing; Thu, 14 Jun 2001 19:00:25 -0400 X-Authentication-Warning: jjdb.jumpjive.com: majordomo set sender to owner-jumpjive-members@jumpjive.com using -f Received: (from root@localhost) by jumpjive.com (8.11.0/8.11.0) id f5EN0PN13329 for jumpjive-members; Thu, 14 Jun 2001 19:00:25 -0400 Date: Thu, 14 Jun 2001 19:00:25 -0400 Message-Id: <200106142300.f5EN0PN13329@jumpjive.com> Subject: You've been selected! From: offers@jumpjive.com Reply-To: offers@jumpjive.com To: undisclosed-recipients:; Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Now You Can Talk About Whatever You Want Whenever, With Voice Stream. Get an exclusive, limited-time Wireless Cell Phone Package including a free Internet-Ready VoiceStream Phone With PingPong Text Messaging. Just click below: http://wireless.freeze.com/transactvs Please note: not all US markets are served by VoiceStream, if you are in a non-VoiceStream area you will receive another great offer, from another well known company. Along with your free VoiceStream digital cell phone you get: Free Nationwide Long Distance 1000 Free Weekend Minutes Exclusive PingPong Text Messaging Service Free Car Charger and Free Belt Clip Free Hands-Free Kit Lowest VoiceStream Rates Available Nation Wide! This is by far the quickest, easiest and least expensive way to get a cell phone from an industry-leading company who you know and trust. Just click below: http://wireless.freeze.com/transactvs Sincerely, Rob Weber, President, Freeze Wireless To unsubscribe, send an e-mail to unsubscribe@jumpjive.com. From owner-megaco@fore.com Fri Jun 15 10:10:56 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09344 for ; Fri, 15 Jun 2001 10:10:55 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA17393; Fri, 15 Jun 2001 10:05:15 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA12822 for megaco-list; Fri, 15 Jun 2001 10:03:20 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA12777; Fri, 15 Jun 2001 10:03:10 -0400 (EDT) Received: from jumpjive.com (ads.jumpjive.com [63.66.132.248]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA17135; Fri, 15 Jun 2001 10:03:06 -0400 (EDT) Received: from localhost (mail@localhost) by jumpjive.com (8.11.0/8.11.0) with SMTP id f5FDtlr20755; Fri, 15 Jun 2001 09:55:48 -0400 X-Authentication-Warning: jjdb.jumpjive.com: mail owned process doing -bs Received: by jjdb.jumpjive.com (bulk_mailer v1.13); Fri, 15 Jun 2001 04:57:56 -0400 Received: (from majordomo@localhost) by jumpjive.com (8.11.0/8.11.0) id f5F03MW17699 for jumpjive-members-outgoing; Thu, 14 Jun 2001 20:03:22 -0400 X-Authentication-Warning: jjdb.jumpjive.com: majordomo set sender to owner-jumpjive-members@jumpjive.com using -f Received: (from root@localhost) by jumpjive.com (8.11.0/8.11.0) id f5F03Mf17695 for jumpjive-members; Thu, 14 Jun 2001 20:03:22 -0400 Date: Thu, 14 Jun 2001 20:03:22 -0400 Message-Id: <200106150003.f5F03Mf17695@jumpjive.com> Subject: You've been selected! From: offers@jumpjive.com Reply-To: offers@jumpjive.com To: undisclosed-recipients:; Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Now You Can Talk About Whatever You Want Whenever, With Voice Stream. Get an exclusive, limited-time Wireless Cell Phone Package including a free Internet-Ready VoiceStream Phone With PingPong Text Messaging. Just click below: http://wireless.freeze.com/transactvs Please note: not all US markets are served by VoiceStream, if you are in a non-VoiceStream area you will receive another great offer, from another well known company. Along with your free VoiceStream digital cell phone you get: Free Nationwide Long Distance 1000 Free Weekend Minutes Exclusive PingPong Text Messaging Service Free Car Charger and Free Belt Clip Free Hands-Free Kit Lowest VoiceStream Rates Available Nation Wide! This is by far the quickest, easiest and least expensive way to get a cell phone from an industry-leading company who you know and trust. Just click below: http://wireless.freeze.com/transactvs Sincerely, Rob Weber, President, Freeze Wireless To unsubscribe, send an e-mail to unsubscribe@jumpjive.com. From owner-megaco@fore.com Fri Jun 15 10:50:04 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10935 for ; Fri, 15 Jun 2001 10:50:03 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA20099; Fri, 15 Jun 2001 10:35:15 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA21262 for megaco-list; Fri, 15 Jun 2001 10:34:08 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA21244 for ; Fri, 15 Jun 2001 10:34:05 -0400 (EDT) Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA19912 for ; Fri, 15 Jun 2001 10:34:01 -0400 (EDT) Received: from ihemail1.firewall.lucent.com (localhost [127.0.0.1]) by ihemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5FEY2611889 for ; Fri, 15 Jun 2001 10:34:02 -0400 (EDT) Received: from teton.mh.lucent.com (h135-3-130-2.lucent.com [135.3.130.2]) by ihemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5FEY2w11882; Fri, 15 Jun 2001 10:34:02 -0400 (EDT) Received: from lucent.com (pctla [135.3.130.39]) by teton.mh.lucent.com (8.8.8+Sun/8.8.8) with ESMTP id KAA11163; Fri, 15 Jun 2001 10:34:01 -0400 (EDT) Message-ID: <3B2A1DD5.9B8C7EB5@lucent.com> Date: Fri, 15 Jun 2001 10:38:14 -0400 From: Terry L Anderson Organization: Lucent Technologies X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Qiu Xiuping CC: megaco@fore.com Subject: Re: Where's the latest Implementor's Guide? References: <001b01c0f538$1b999e80$011c690a@huawei.com> Content-Type: multipart/mixed; boundary="------------ACD3C835A9A97552B50D8C57" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk This is a multi-part message in MIME format. --------------ACD3C835A9A97552B50D8C57 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The latest H.248 Implementors Guide was approved at ITU SG16 at Porto Seguro, Brazil last week. It can be access on the SG16 draft documents site at: ftp://standard.pictel.com/avc-site/0105_Por/PL-015_H248_imp_guide.zip The same directory has other output documents from the meeting including the consent version of H.248 Annex L, M.2 & supplement 2 (Packages Guide) Qiu Xiuping wrote: > Hello, Dear All. > > Where's the latest implementor's guide? > And after RFC 3015, any data structure changing or protocol changing? > > Thank you, > > Qiu Xiuping -- ------------------------------------------------------------ Terry L Anderson mailto:tla@lucent.com Tel:908.582.7013 Fax:908.582.6729 Lucent Technologies/INS/Voice Over IP Access Networks Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla --------------ACD3C835A9A97552B50D8C57 Content-Type: text/x-vcard; charset=us-ascii; name="tla.vcf" Content-Description: Card for Terry L Anderson Content-Disposition: attachment; filename="tla.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Anderson;Terry L tel;fax:908.582.6729 tel;work:908.582.7013 x-mozilla-html:TRUE url:http://its.lucent.com/~tla org:Lucent / InterNetworking Systems;VoIP Access Networks version:2.1 email;internet:tla@lucent.com title:DMTS note:http://www.gti.net/tla or http://teton.mh.lucent.com/~tla (Lucent internal) adr;quoted-printable:;;600 Mountain Av=0D=0ARm 2B-121;Murray Hill;NJ;07974;USA x-mozilla-cpt:;21296 fn:Terry L Anderson end:vcard --------------ACD3C835A9A97552B50D8C57-- From owner-megaco@fore.com Fri Jun 15 16:41:46 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29056 for ; Fri, 15 Jun 2001 16:41:46 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA14158; Fri, 15 Jun 2001 16:36:35 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id QAA14528 for megaco-list; Fri, 15 Jun 2001 16:33:50 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA14521 for ; Fri, 15 Jun 2001 16:33:49 -0400 (EDT) Received: from lmmx1.fl.icn.siemens.com (lmmx1.fl.icn.siemens.com [192.132.51.129]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA13956 for ; Fri, 15 Jun 2001 16:33:44 -0400 (EDT) Received: from lmyr210a.lm.ssc.siemens.com (lmyr210a.lm.ssc.siemens.com [165.218.224.44]) by lmmx1.fl.icn.siemens.com (8.9.3/8.9.3) with ESMTP id QAA24592 for ; Fri, 15 Jun 2001 16:30:19 -0400 (EDT) Received: by lmyr210a.lm.ssc.siemens.com with Internet Mail Service (5.5.2653.19) id ; Fri, 15 Jun 2001 16:33:46 -0400 Message-ID: <637FAED82678D311AFAE0008C791D24901674698@lmyr227a.lm.ssc.siemens.com> From: "Sayer, Trevor" To: "'megaco@fore.com'" Subject: Megaco response/notify routing Date: Fri, 15 Jun 2001 16:33:30 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Gentlemen I believe the answer is 'No', but is the behavior of Megaco the same as MGCP with respect to routing of responses and notifies in particular:- Should an MG route responses back to the command source IP address/port, even if this is different from the IP/Port negotiated by the ServiceChange, when the MG first established communication with the MGC. Or should the MG reject commands from sources different from the ServiceChange negotiation. Megaco does not have a notifyEntity parameter, but should a MG send notifies to the source IP address/port of the last command received for a given endpoint or should notifies always be sent to the IP/Port negotiated with the ServiceChange. In summary, does a Megaco MGC have to appear to the MG as a single IP/Port from which all commands are received and all responses/notifies are sent or can endpoints be controlled from MGC IP address/ports which are different from the IP/Port negotiated by the ServiceChange. Differences between the two protocols in this area has a large impact on the MGC design with respect to performance scalability and fault tolerance. Any comments/opinions would be greatly appreciate. Trevor Sayer Siemens Carrier Networks Lake Mary, FL Tel 407-942-4176 From owner-megaco@fore.com Fri Jun 15 17:19:53 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29828 for ; Fri, 15 Jun 2001 17:19:52 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA16641; Fri, 15 Jun 2001 17:18:59 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id RAA24651 for megaco-list; Fri, 15 Jun 2001 17:18:02 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA24646 for ; Fri, 15 Jun 2001 17:18:01 -0400 (EDT) Received: from huginn.ctccom.net (Huginn.CTCCom.net [207.190.194.11]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA16555 for ; Fri, 15 Jun 2001 17:17:56 -0400 (EDT) Received: from MBRAHMANAPALLY ([64.69.123.121]) by huginn.ctccom.net (Mirapoint) with SMTP id ACX04364; Fri, 15 Jun 2001 17:17:27 -0400 (EDT) From: "Madhu Babu Brahmanapally" To: "'Sayer, Trevor'" , Subject: RE: Megaco response/notify routing Date: Fri, 15 Jun 2001 17:19:02 -0400 Message-ID: <011d01c0f5e0$cd6d84c0$c500a8c0@MBRAHMANAPALLY> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <637FAED82678D311AFAE0008C791D24901674698@lmyr227a.lm.ssc.siemens.com> Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: 7bit HI Sayer, The MG/MGC during the initial registration on ROOT can exchange the port numbers to be used for further communication. Of course there is no concept of "NotifiedEntity" in Megaco. If no port number is exchanged during the initial registration the default one has to used. -Regards Madhubabu Brahmanapally -----Original Message----- From: owner-megaco@pit.comms.marconi.com [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Sayer, Trevor Sent: Friday, June 15, 2001 4:34 PM To: 'megaco@fore.com' Subject: Megaco response/notify routing Gentlemen I believe the answer is 'No', but is the behavior of Megaco the same as MGCP with respect to routing of responses and notifies in particular:- Should an MG route responses back to the command source IP address/port, even if this is different from the IP/Port negotiated by the ServiceChange, when the MG first established communication with the MGC. Or should the MG reject commands from sources different from the ServiceChange negotiation. Megaco does not have a notifyEntity parameter, but should a MG send notifies to the source IP address/port of the last command received for a given endpoint or should notifies always be sent to the IP/Port negotiated with the ServiceChange. In summary, does a Megaco MGC have to appear to the MG as a single IP/Port from which all commands are received and all responses/notifies are sent or can endpoints be controlled from MGC IP address/ports which are different from the IP/Port negotiated by the ServiceChange. Differences between the two protocols in this area has a large impact on the MGC design with respect to performance scalability and fault tolerance. Any comments/opinions would be greatly appreciate. Trevor Sayer Siemens Carrier Networks Lake Mary, FL Tel 407-942-4176 From owner-megaco@fore.com Sun Jun 17 03:46:45 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03229 for ; Sun, 17 Jun 2001 03:46:44 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id DAA12824; Sun, 17 Jun 2001 03:37:47 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id DAA04842 for megaco-list; Sun, 17 Jun 2001 03:21:38 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id DAA04838 for ; Sun, 17 Jun 2001 03:21:36 -0400 (EDT) Received: from accord-ntsrv3.accord.co.il ([212.199.61.2]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id DAA12643 for ; Sun, 17 Jun 2001 03:21:33 -0400 (EDT) Received: by ACCORD-NTSRV3 with Internet Mail Service (5.5.2650.21) id ; Sun, 17 Jun 2001 08:30:54 +0200 Message-ID: <912F8F9A0F16D511A64C00805F6526BD83B26F@ACCORD-NTSRV3> From: "Even ,Roni" To: megaco@fore.com Subject: re: question about conference Date: Sun, 17 Jun 2001 08:30:54 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="windows-1255" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk mu lj In general a conference is implied by having all streams in a context mixed. In you question since I assume you have two physical MGs There are two options to model the conference 1. A cascaded conference which means you have mixed streams from MG1 to MG2. In that case there is a context in MG1 with user1 and user2 and according to H.248 mixing is implied (How is implementation dependent) and the output stream goes to MG2 as a new RTP stream to a context with user3. These are bi-directional connections. The context with version 2 of H.248 can have properties based on package that will define the mixing. 2. MG1 is just passing user1 and user2 streams. You may create two contexts one for each user in MG1 and have a context with three termination in MG2. The MGs handle only media streams. Call signalling and control are in the MGC. If one MGC is handling both MGs then it is a simple conference with the streams according to the above options. If you have two MGC each controlling an MG then it is a cascaded conference according to H.323. Please note that the ITU is working on MCU decomposition and a profile and packages for supporting multimedia conferences will be defined. Roni ********************************************** Roni Even VP Product Planning Polycom Israel Tel: +972-3-9251200 Fax: +972-3-9211571 Email: roni.even@polycom.co.il From owner-megaco@fore.com Sun Jun 17 03:48:07 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03304 for ; Sun, 17 Jun 2001 03:48:06 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id DAA13035; Sun, 17 Jun 2001 03:41:24 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id DAA05261 for megaco-list; Sun, 17 Jun 2001 03:38:10 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id DAA05254; Sun, 17 Jun 2001 03:38:06 -0400 (EDT) From: stacylovely@pll.kiev.ua Received: from pll.kiev.ua ([193.193.200.82]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id DAA12797; Sun, 17 Jun 2001 03:37:36 -0400 (EDT) Received: from 193.193.200.82 ([209.210.146.215]) by pll.kiev.ua (8.9.3/8.8.7) with SMTP id LAA21632; Sun, 17 Jun 2001 11:07:19 +0300 Message-Id: <200106170807.LAA21632@pll.kiev.ua> Received: from amanda@hotmail.com by judso@hotmail.com (8.8.5/8.6.5) with SMTP id GAA02596 for ; Sat, 16 Jun 2001 00:21:54 -0600 (EST) To: judso@hotmail.com Date: Sat, 16 Jun 01 00:21:54 EST Subject: Hey dude, this is my new email address Reply-To: amanda@hotmail.com Comments: Authenticated sender is Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Hi. I am a 19 year old strawberry blonde. I LOVE to suck cock, and have cum splattered all over my face! Want to watch me fuck and suck live? :) Just $1.95 just click here: My hot pussy is waiting for you! So what are you waiting for? http://216.242.173.247 From owner-megaco@fore.com Sun Jun 17 20:55:45 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13097 for ; Sun, 17 Jun 2001 20:55:43 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA24102; Sun, 17 Jun 2001 20:53:23 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id UAA05886 for megaco-list; Sun, 17 Jun 2001 20:46:16 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA05882 for ; Sun, 17 Jun 2001 20:46:15 -0400 (EDT) Received: from hotmail.com (f55.law14.hotmail.com [64.4.21.55]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA23922 for ; Sun, 17 Jun 2001 20:46:11 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 17 Jun 2001 17:46:03 -0700 Received: from 61.132.62.80 by lw14fd.law14.hotmail.msn.com with HTTP; Mon, 18 Jun 2001 00:46:03 GMT X-Originating-IP: [61.132.62.80] From: "mu lj" To: megaco@fore.com Date: Mon, 18 Jun 2001 08:46:03 +0800 Mime-Version: 1.0 Content-Type: text/plain; charset=gb2312; format=flowed Message-ID: X-OriginalArrivalTime: 18 Jun 2001 00:46:03.0436 (UTC) FILETIME=[0D269EC0:01C0F790] Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk hi all: I cann't get h.248(V2),who can give me a document. Thanks. Regards, mu lj _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. From owner-megaco@fore.com Mon Jun 18 02:06:09 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27268 for ; Mon, 18 Jun 2001 02:06:09 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id CAA28452; Mon, 18 Jun 2001 02:01:33 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id BAA17100 for megaco-list; Mon, 18 Jun 2001 01:59:15 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id BAA17096 for ; Mon, 18 Jun 2001 01:59:14 -0400 (EDT) Received: from telesoft.indts.com ([164.164.71.52]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id BAA28320 for ; Mon, 18 Jun 2001 01:59:04 -0400 (EDT) Received: from indts_fs.indts.com (indts_fs [201.64.64.29]) by telesoft.indts.com (8.8.7/8.8.7) with ESMTP id LAA15179 for ; Mon, 18 Jun 2001 11:50:35 +0530 Received: by INDTS_FS with Internet Mail Service (5.5.2650.21) id ; Mon, 18 Jun 2001 11:36:57 +0530 Message-ID: From: Lalit Kumar To: megaco@fore.com Subject: difference between servicechangeaddress and servicechangeMgcId Date: Mon, 18 Jun 2001 11:36:56 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk hi, I was going through RFC3015 section 7.2.8. It says that "The ServiceChangeAddress provides an address to be used within the context of the association currently being negotiated, while the serviceChangeMgcId provides an alternative address where the MG should seek to establish another association." Can somebody explain the role of association?? Since both cannot be used simultaneously when should MGC use serviceChangeAddress and when should it use serviceChangeMgcId?? Thanks in advance, With Regards, lalit From owner-megaco@fore.com Mon Jun 18 02:15:01 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27899 for ; Mon, 18 Jun 2001 02:15:00 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id CAA28875; Mon, 18 Jun 2001 02:10:21 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id CAA17714 for megaco-list; Mon, 18 Jun 2001 02:09:21 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id CAA17710 for ; Mon, 18 Jun 2001 02:09:19 -0400 (EDT) Received: from newish7.ericsson.com.au ([203.61.155.116]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id CAA28708 for ; Mon, 18 Jun 2001 02:09:12 -0400 (EDT) Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10]) by newish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id QAA20845; Mon, 18 Jun 2001 16:07:20 +1000 (EST) Received: from ericsson.com (mcdh126.epa.ericsson.se [146.11.81.126]) by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id QAA05537; Mon, 18 Jun 2001 16:08:13 +1000 (EST) Message-ID: <3B2D8837.8FA183DE@ericsson.com> Date: Mon, 18 Jun 2001 14:48:55 +1000 From: Christian Groves X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Troy Cauble CC: MEGACO list Subject: Re: New IG Editor References: <3B1E94E1.6289D721@lucent.com> <3B2028F2.AF537579@ericsson.com> <3B20DE1F.FD98E18B@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: 7bit G'Day Troy, There were 2 changes: adding something with regards to EQUAL in digitmap and removing 6.82 on servicechange for the next revision of the implementors' guide/h248v2. Christian Troy Cauble wrote: > > Christian Groves wrote: > > > > G'Day Troy, All, > > > > At the SG16 meeting I gave up the editorship of the Implementors' Guide. > > I have other commitments which meant I couldn't spend the necessary > > time. > > > > The new editor is: Terry Anderson > > > > Cheers, Christian > > Thanks Christian for all the work. > > Was IG v7 approved? > > Has it changed since it was posted to > http://standard.pictel.com/ftp/avc-site/0105_Por/DC-xxx_H248_Implementors_Additions_v7.zip > ? > > -troy From owner-megaco@fore.com Mon Jun 18 02:15:39 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27956 for ; Mon, 18 Jun 2001 02:15:38 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id CAA28989; Mon, 18 Jun 2001 02:10:59 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id CAA17733 for megaco-list; Mon, 18 Jun 2001 02:09:40 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id CAA17728 for ; Mon, 18 Jun 2001 02:09:39 -0400 (EDT) Received: from newish7.ericsson.com.au ([203.61.155.116]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id CAA28714 for ; Mon, 18 Jun 2001 02:09:33 -0400 (EDT) Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10]) by newish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id QAA20840; Mon, 18 Jun 2001 16:07:19 +1000 (EST) Received: from ericsson.com (mcdh126.epa.ericsson.se [146.11.81.126]) by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id QAA05531; Mon, 18 Jun 2001 16:08:12 +1000 (EST) Message-ID: <3B2D8781.D7832021@ericsson.com> Date: Mon, 18 Jun 2001 14:45:53 +1000 From: Christian Groves X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Troy Cauble CC: MEGACO list Subject: Re: g/sc SigID list References: <3B27676F.B9D17634@lucent.com> <3B27810B.AC9FF822@lucent.com> <3B27866D.5838126E@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: 7bit G'Day Troy, I guess the question I have is who would encode multiple signalIDs in one signal completion response? I can see the following cases are realistic: (a) Individual Signal outside of a list (b) Individual Signal in list (c) Whole list The whole list case is handled by the SignalListID parameter. I'm inclined to have g/sc(SigID) only have the signalID. This is a string. If you need multiple indication of signal completion you'd have multiple notifications. Christian Troy Cauble wrote: > > New proposal: > > Change the Type of the g/sc SigId parameter in E.1.2 > from "list" to "string or list of strings". > Clarify syntax with examples below. > > Objections? > > -troy > > Troy Cauble wrote: > > > > BTW, here are some uses that I think are consistent with > > the syntax description in E.1.2. Anyone care to comment? > > This is vague enough in E.1.2 that it should be clarified > > with some examples. > > > > Note that a sublist uses [] not {} according to the ABNF > > for alternativeValue. > > > > 1.Reporting a signal outside of sequential signal list: > > SigID="pkg1/sig1" > > > > 2.Reporting a signal inside a sequential signal list: > > SigID="SignalList = 1 {pkg1/sig1}" > > > > 3.Reporting a list of signals outside of sequential signal list: > > SigID=[ "pkg1/sig1" , "pkg2/sig2" ] > > > > 4.Reporting a list of signals inside a sequential signal list: > > SigID=[ "SignalList = 1 {pkg1/sig1}", "SignalList = 2 {pkg2/sig2}" ] > > > > 5.Reporting a list of both signals and sequential signal lists: > > SigID=[ "pkg1/sig1" , "pkg2/sig2", "SignalList = 1 {pkg3/sig3}", > > "SignalList = 2 {pkg4/sig4}" ] > > > > -troy > > > > Troy Cauble wrote: > > > > > > Proposal: > > > > > > Change the Type of the g/sc SigId parameter in E.1.2 > > > from "list" to "string". > > > > > > Argument: > > > > > > Sections 12.1.2 and 12.2 define allowable types > > > for Properties and Parameters, including "String" > > > and "Sub-list". > > > > > > Annex E.1.2 (g/sc) defines parameter SigID as > > > being a "list" and references a complex syntax for > > > that "list" which includes nested braces. > > > > > > This specific syntax conflicts with the established > > > syntax for a list. > > > > > > parmValue = (EQUAL alternativeValue/ INEQUAL VALUE) > > > alternativeValue = ( VALUE > > > / LSBRKT VALUE *(COMMA VALUE) RSBRKT > > > ; sublist (i.e. A AND B AND ...) > > > / LBRKT VALUE *(COMMA VALUE) RBRKT > > > ; alternatives (i.e. A OR B OR ...) > > > / LSBRKT VALUE COLON VALUE RSBRKT ) > > > ; range > > > > > > If the type is redefined as "String", double quotes > > > will be required (IG 6.80). Within that quotedString, > > > the syntax could stay as defined. > > > > > > Besides the fact that this syntax is in direct conflict > > > of the ABNF specification, I think it is unreasonable > > > to allow a package to define a complex syntax to be > > > embedded directly in a VALUE without quoting. Parsers > > > should be able to parse the message down to the VALUE > > > level without package knowledge. > > > > > > Comments? > > > > > > -troy From owner-megaco@fore.com Mon Jun 18 02:16:28 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28022 for ; Mon, 18 Jun 2001 02:16:28 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id CAA28894; Mon, 18 Jun 2001 02:10:29 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id CAA17720 for megaco-list; Mon, 18 Jun 2001 02:09:23 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id CAA17716 for ; Mon, 18 Jun 2001 02:09:22 -0400 (EDT) Received: from newish7.ericsson.com.au ([203.61.155.116]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id CAA28709 for ; Mon, 18 Jun 2001 02:09:14 -0400 (EDT) Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10]) by newish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id QAA20855; Mon, 18 Jun 2001 16:07:21 +1000 (EST) Received: from ericsson.com (mcdh126.epa.ericsson.se [146.11.81.126]) by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id QAA05545; Mon, 18 Jun 2001 16:08:14 +1000 (EST) Message-ID: <3B2D8C1B.AAC18D44@ericsson.com> Date: Mon, 18 Jun 2001 15:05:31 +1000 From: Christian Groves X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Troy Cauble CC: MEGACO list Subject: Re: ASN.1: extraInfo OPTIONAL References: <3B250453.538C2359@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: 7bit G'Day Troy, Its optional because you don't need to send extraInfo in a majority of cases. A one to one relationship is implied if not sent. ie. property = value (does this really need to be stated????). In hindsight the enum may have been nicer the optional was the way we went at the time. Cheers, Christian Troy Cauble wrote: > > The sub-object below is used in 3 places in the ASN.1 spec., > EventParameter, SigParameter, and PropertyParm. > > extraInfo CHOICE > { > relation Relation, > range BOOLEAN, > sublist BOOLEAN > } OPTIONAL, > > The fact that the whole object is optional is hard to align > with the text encoding. What relationship is implied when > no extra info is sent? > > Also, why was this so complicated anyway? extraInfo is > a CHOICE of an ENUMERATED or one of two BOOLEANs. Why > wasn't it all just an ENUMERATED? > > -troy From owner-megaco@fore.com Mon Jun 18 02:46:27 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29973 for ; Mon, 18 Jun 2001 02:46:27 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id CAA29727; Mon, 18 Jun 2001 02:45:18 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id CAA19431 for megaco-list; Mon, 18 Jun 2001 02:44:28 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id CAA19418 for ; Mon, 18 Jun 2001 02:44:26 -0400 (EDT) From: df4@ns2.ans.co.kr Received: from ns2.ans.co.kr ([210.126.104.74]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id CAA29638 for ; Mon, 18 Jun 2001 02:44:23 -0400 (EDT) Received: from ns2.ans.co.kr (cust-146-183.as02.hnsn.eli.net [209.210.146.183]) by ns2.ans.co.kr (8.9.3+Sun/8.9.1) with SMTP id PAA11772; Mon, 18 Jun 2001 15:40:14 +0900 (KST) Message-Id: <200106180640.PAA11772@ns2.ans.co.kr> To: judso@kti.co.kr Date: Sat, 16 Jun 01 23:38:06 EST Subject: hi Reply-To: amanda@kti.co.kr Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Do you have back, muscle or joint problems? If so we would like to offer you the opportunity to discuss them with a health care professional at no charge. What do you have to lose besides your pain and discomfort? http://www.westhousehosting.net/backache To be removed please go to: http://www.westhousehosting.net/backache/remove.html HITTING REPLY WILL NOT GET YOU REMOVED NOR GET YOU MORE INFORMATION. THIS IS AN OUTGOING EMAIL ONLY. REPLIES ARE NOT READ. NOTE: THIS IS FOR RESIDENTS OF THE U.S. ONLY From owner-megaco@fore.com Mon Jun 18 06:34:28 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02795 for ; Mon, 18 Jun 2001 06:34:27 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id GAA05718; Mon, 18 Jun 2001 06:24:21 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id GAA09217 for megaco-list; Mon, 18 Jun 2001 06:20:39 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id GAA09212 for ; Mon, 18 Jun 2001 06:20:37 -0400 (EDT) Received: from cvis29.marconicomms.com (cvis29.marconicomms.com [195.99.244.61] (may be forged)) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id GAA05559 for ; Mon, 18 Jun 2001 06:20:35 -0400 (EDT) Received: from cvis01.gpt.co.uk (unverified) by cvis29.marconicomms.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Mon, 18 Jun 2001 11:20:24 +0100 Received: from marconicomms.com by cvis01.gpt.co.uk with SMTP (8.8.8+Sun/cvms-32) id LAA22584; Mon, 18 Jun 2001 11:20:24 +0100 (BST) Received: by marconicomms.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 80256A6F.00386047 ; Mon, 18 Jun 2001 11:15:45 +0100 X-Lotus-FromDomain: MCMAIN@MCEXT From: "Sean Leahy" To: "Madhu Babu Brahmanapally" cc: megaco@fore.com Message-ID: <80256A6F.00385B76.00@marconicomms.com> Date: Mon, 18 Jun 2001 11:15:45 +0100 Subject: RE: Megaco response/notify routing Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Hello, Can someone clarify that if the MGC during the initial registration on ROOT, wishes to change the port numbers to be used for further communication should it respond to the MG Service Change message using a new Service Change Address or a Service Change MgcId parameter or does it matter ? Sean Leahy Marconi From owner-megaco@fore.com Mon Jun 18 09:08:19 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06314 for ; Mon, 18 Jun 2001 09:08:18 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA14142; Mon, 18 Jun 2001 09:06:13 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id JAA04219 for megaco-list; Mon, 18 Jun 2001 09:04:24 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA04211 for ; Mon, 18 Jun 2001 09:04:23 -0400 (EDT) Received: from huginn.ctccom.net (Huginn.CTCCom.net [207.190.194.11]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA13932 for ; Mon, 18 Jun 2001 09:04:20 -0400 (EDT) Received: from MBRAHMANAPALLY ([64.69.123.121]) by huginn.ctccom.net (Mirapoint) with SMTP id ACY00037; Mon, 18 Jun 2001 09:04:04 -0400 (EDT) From: "Madhu Babu Brahmanapally" To: "'Sean Leahy'" Cc: Subject: RE: Megaco response/notify routing Date: Mon, 18 Jun 2001 09:05:26 -0400 Message-ID: <013901c0f7f7$58102610$c500a8c0@MBRAHMANAPALLY> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <80256A6F.00385B76.00@marconicomms.com> Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: 7bit HI Sean, The excerpt below might by useful. "The optional ServiceChangeAddress parameter specifies the address (e.g., IP port number for IP networks) to be used for subsequent communications. It can be specified in the input parameter descriptor or the returned result descriptor. ServiceChangeAddress and ServiceChangeMgcId parameters must not both be present in the ServiceChangeDescriptor or the ServiceChangeResultDescriptor. The ServiceChangeAddress provides an address to be used within the context of the association currently being negotiated, while the ServiceChangeMgcId provides an alternate address where the MG should seek to establish another association." Regards Madhubabu Brahmanapally -----Original Message----- From: Sean Leahy [mailto:Sean.Leahy@marconi.com] Sent: Monday, June 18, 2001 6:16 AM To: Madhu Babu Brahmanapally Cc: megaco@fore.com Subject: RE: Megaco response/notify routing Hello, Can someone clarify that if the MGC during the initial registration on ROOT, wishes to change the port numbers to be used for further communication should it respond to the MG Service Change message using a new Service Change Address or a Service Change MgcId parameter or does it matter ? Sean Leahy Marconi From owner-megaco@fore.com Mon Jun 18 09:50:00 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07708 for ; Mon, 18 Jun 2001 09:49:59 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA18399; Mon, 18 Jun 2001 09:48:07 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id JAA16180 for megaco-list; Mon, 18 Jun 2001 09:47:02 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA16172 for ; Mon, 18 Jun 2001 09:47:00 -0400 (EDT) Received: from huginn.ctccom.net (Huginn.CTCCom.net [207.190.194.11]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA18246 for ; Mon, 18 Jun 2001 09:46:58 -0400 (EDT) Received: from MBRAHMANAPALLY ([64.69.123.121]) by huginn.ctccom.net (Mirapoint) with SMTP id ACY00686; Mon, 18 Jun 2001 09:45:51 -0400 (EDT) From: "Madhu Babu Brahmanapally" To: "'Lalit Kumar'" , Subject: RE: difference between servicechangeaddress and servicechangeMgcId Date: Mon, 18 Jun 2001 09:47:35 -0400 Message-ID: <000f01c0f7fd$3bd44ed0$c500a8c0@MBRAHMANAPALLY> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: 7bit Hi Lalit, The serviceChangeMgcId is sent from the MGC when it doesn't accept the registration request from the MG. And hence the serviceChangeMgcId is set to another MGC. In case the MGC accepts the registration request from the MG, the serviceChangeAddress is used to specify address to which further commands/responses need to be sent. Hope this answers your query. -Regards Madhubabu -----Original Message----- From: owner-megaco@pit.comms.marconi.com [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Lalit Kumar Sent: Monday, June 18, 2001 2:07 AM To: megaco@fore.com Subject: difference between servicechangeaddress and servicechangeMgcId hi, I was going through RFC3015 section 7.2.8. It says that "The ServiceChangeAddress provides an address to be used within the context of the association currently being negotiated, while the serviceChangeMgcId provides an alternative address where the MG should seek to establish another association." Can somebody explain the role of association?? Since both cannot be used simultaneously when should MGC use serviceChangeAddress and when should it use serviceChangeMgcId?? Thanks in advance, With Regards, lalit From owner-megaco@fore.com Mon Jun 18 10:18:25 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08567 for ; Mon, 18 Jun 2001 10:18:25 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA21225; Mon, 18 Jun 2001 10:12:20 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA24178 for megaco-list; Mon, 18 Jun 2001 10:10:39 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA24173 for ; Mon, 18 Jun 2001 10:10:37 -0400 (EDT) Received: from auemail1.firewall.lucent.com (auemail1.lucent.com [192.11.223.161]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA20952 for ; Mon, 18 Jun 2001 10:10:34 -0400 (EDT) Received: from auemail1.firewall.lucent.com (localhost [127.0.0.1]) by auemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5IEAZp06885 for ; Mon, 18 Jun 2001 10:10:35 -0400 (EDT) Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3]) by auemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5IEAYX06872 for ; Mon, 18 Jun 2001 10:10:34 -0400 (EDT) Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id KAA01554; Mon, 18 Jun 2001 10:10:16 -0400 (EDT) Cc: MEGACO list Received: from lucent.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id KAA01541; Mon, 18 Jun 2001 10:10:15 -0400 (EDT) Message-ID: <3B2E0B4D.8467D579@lucent.com> Date: Mon, 18 Jun 2001 10:08:13 -0400 From: Troy Cauble Reply-To: Troy Cauble X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Christian Groves Original-CC: MEGACO list Subject: Re: g/sc SigID list References: <3B27676F.B9D17634@lucent.com> <3B27810B.AC9FF822@lucent.com> <3B27866D.5838126E@lucent.com> <3B2D8781.D7832021@ericsson.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: 7bit Christian, Changing it to a single string sounds reasonable but is more of a change. I'd be happy with it, but will others? My proposal is just a clarification: "List of what?" -troy Christian Groves wrote: > > G'Day Troy, > > I guess the question I have is who would encode multiple signalIDs in > one signal completion response? I can see the following cases are > realistic: > (a) Individual Signal outside of a list > (b) Individual Signal in list > (c) Whole list > The whole list case is handled by the SignalListID parameter. I'm > inclined to have g/sc(SigID) only have the signalID. This is a string. > If you need multiple indication of signal completion you'd have multiple > notifications. > > Christian > > Troy Cauble wrote: > > > > New proposal: > > > > Change the Type of the g/sc SigId parameter in E.1.2 > > from "list" to "string or list of strings". > > Clarify syntax with examples below. > > > > Objections? > > > > -troy > > > > Troy Cauble wrote: > > > > > > BTW, here are some uses that I think are consistent with > > > the syntax description in E.1.2. Anyone care to comment? > > > This is vague enough in E.1.2 that it should be clarified > > > with some examples. > > > > > > Note that a sublist uses [] not {} according to the ABNF > > > for alternativeValue. > > > > > > 1.Reporting a signal outside of sequential signal list: > > > SigID="pkg1/sig1" > > > > > > 2.Reporting a signal inside a sequential signal list: > > > SigID="SignalList = 1 {pkg1/sig1}" > > > > > > 3.Reporting a list of signals outside of sequential signal list: > > > SigID=[ "pkg1/sig1" , "pkg2/sig2" ] > > > > > > 4.Reporting a list of signals inside a sequential signal list: > > > SigID=[ "SignalList = 1 {pkg1/sig1}", "SignalList = 2 {pkg2/sig2}" ] > > > > > > 5.Reporting a list of both signals and sequential signal lists: > > > SigID=[ "pkg1/sig1" , "pkg2/sig2", "SignalList = 1 {pkg3/sig3}", > > > "SignalList = 2 {pkg4/sig4}" ] > > > > > > -troy > > > > > > Troy Cauble wrote: > > > > > > > > Proposal: > > > > > > > > Change the Type of the g/sc SigId parameter in E.1.2 > > > > from "list" to "string". > > > > > > > > Argument: > > > > > > > > Sections 12.1.2 and 12.2 define allowable types > > > > for Properties and Parameters, including "String" > > > > and "Sub-list". > > > > > > > > Annex E.1.2 (g/sc) defines parameter SigID as > > > > being a "list" and references a complex syntax for > > > > that "list" which includes nested braces. > > > > > > > > This specific syntax conflicts with the established > > > > syntax for a list. > > > > > > > > parmValue = (EQUAL alternativeValue/ INEQUAL VALUE) > > > > alternativeValue = ( VALUE > > > > / LSBRKT VALUE *(COMMA VALUE) RSBRKT > > > > ; sublist (i.e. A AND B AND ...) > > > > / LBRKT VALUE *(COMMA VALUE) RBRKT > > > > ; alternatives (i.e. A OR B OR ...) > > > > / LSBRKT VALUE COLON VALUE RSBRKT ) > > > > ; range > > > > > > > > If the type is redefined as "String", double quotes > > > > will be required (IG 6.80). Within that quotedString, > > > > the syntax could stay as defined. > > > > > > > > Besides the fact that this syntax is in direct conflict > > > > of the ABNF specification, I think it is unreasonable > > > > to allow a package to define a complex syntax to be > > > > embedded directly in a VALUE without quoting. Parsers > > > > should be able to parse the message down to the VALUE > > > > level without package knowledge. > > > > > > > > Comments? > > > > > > > > -troy From owner-megaco@fore.com Mon Jun 18 10:33:29 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08866 for ; Mon, 18 Jun 2001 10:33:27 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA20069; Mon, 18 Jun 2001 10:03:57 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA20544 for megaco-list; Mon, 18 Jun 2001 10:02:32 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA20515 for ; Mon, 18 Jun 2001 10:01:52 -0400 (EDT) Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA19803 for ; Mon, 18 Jun 2001 10:01:49 -0400 (EDT) Received: from auemail2.firewall.lucent.com (localhost [127.0.0.1]) by auemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5IE1n601685 for ; Mon, 18 Jun 2001 10:01:49 -0400 (EDT) Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3]) by auemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5IE1nf01676 for ; Mon, 18 Jun 2001 10:01:49 -0400 (EDT) Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id KAA01455; Mon, 18 Jun 2001 10:01:46 -0400 (EDT) Cc: MEGACO list Received: from lucent.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id KAA01446; Mon, 18 Jun 2001 10:01:44 -0400 (EDT) Message-ID: <3B2E094D.1C80350D@lucent.com> Date: Mon, 18 Jun 2001 09:59:41 -0400 From: Troy Cauble Reply-To: Troy Cauble X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Christian Groves Original-CC: MEGACO list Subject: Re: ASN.1: extraInfo OPTIONAL References: <3B250453.538C2359@lucent.com> <3B2D8C1B.AAC18D44@ericsson.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: 7bit Christian Groves wrote: > > G'Day Troy, > > Its optional because you don't need to send extraInfo in a majority of > cases. A one to one relationship is implied if not sent. ie. property = > value (does this really need to be stated????). Yes it does. There's an explicit way to encode equalTo, why would we assume there's two ways. I'll settle for knowing it's equalTo, but for v2 we really should avoid having 2 ways to encode the same thing. -troy > In hindsight the enum may have been nicer the optional was the way we > went at the time. > > Cheers, Christian > > Troy Cauble wrote: > > > > The sub-object below is used in 3 places in the ASN.1 spec., > > EventParameter, SigParameter, and PropertyParm. > > > > extraInfo CHOICE > > { > > relation Relation, > > range BOOLEAN, > > sublist BOOLEAN > > } OPTIONAL, > > > > The fact that the whole object is optional is hard to align > > with the text encoding. What relationship is implied when > > no extra info is sent? > > > > Also, why was this so complicated anyway? extraInfo is > > a CHOICE of an ENUMERATED or one of two BOOLEANs. Why > > wasn't it all just an ENUMERATED? > > > > -troy From owner-megaco@fore.com Mon Jun 18 11:17:13 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10047 for ; Mon, 18 Jun 2001 11:17:12 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA27527; Mon, 18 Jun 2001 11:13:55 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id LAA14708 for megaco-list; Mon, 18 Jun 2001 11:12:09 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA14694 for ; Mon, 18 Jun 2001 11:12:07 -0400 (EDT) Received: from mail.mediatrix.com (mail.mediatrix.com [205.237.248.11]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA27279 for ; Mon, 18 Jun 2001 11:12:03 -0400 (EDT) Received: by mail.mediatrix.com with Internet Mail Service (5.5.2650.21) id ; Mon, 18 Jun 2001 11:06:27 -0400 Message-ID: From: Steven Weisz To: "Megaco Mailing List (E-mail)" Subject: Parsing Question Date: Mon, 18 Jun 2001 11:06:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Hi List, I am currently looking at what needs to be done when a command is marked as "optional" but during parsing of the command an error occurs. As I see it these are the possible scenarios (assuming at least the command token has been parsed): (a) A transactionId cannot be reliably determined (b) An error occurs in one of the command descriptors (c) there is no closing '}' for the command Now in case (a) we should fill the "action" reply with error 442 - Syntax error in command, does this mean that the command cannot be skipped even though it is optional? However, if it still can be skipped, shouldn't we set the "command" reply's error descriptor to something, since we may still have other command to process. Case (b) seems to be straight forward, that it we set the "command" reply's error descriptor appropriately. Case (c) leads me to believe that we would have to stop parsing, since the question would be what is the next token we could look for? Would we expect a ',' or a CtxToken or what? Is my reasoning making sense, do we try to skip optional commands when a parsing error is encountered? Thanks, Steven From owner-megaco@fore.com Tue Jun 19 10:30:31 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA22604 for ; Tue, 19 Jun 2001 10:30:31 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA02115; Tue, 19 Jun 2001 10:20:29 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA23893 for megaco-list; Tue, 19 Jun 2001 10:13:51 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA23887 for ; Tue, 19 Jun 2001 10:13:50 -0400 (EDT) Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA01417 for ; Tue, 19 Jun 2001 10:13:46 -0400 (EDT) Received: from ihemail1.firewall.lucent.com (localhost [127.0.0.1]) by ihemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5JEDlD03932 for ; Tue, 19 Jun 2001 10:13:47 -0400 (EDT) Received: from teton.mh.lucent.com (h135-3-130-2.lucent.com [135.3.130.2]) by ihemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5JEDke03915 for ; Tue, 19 Jun 2001 10:13:47 -0400 (EDT) Received: from lucent.com (pctla [135.3.130.39]) by teton.mh.lucent.com (8.8.8+Sun/8.8.8) with ESMTP id KAA23132 for ; Tue, 19 Jun 2001 10:13:41 -0400 (EDT) Message-ID: <3B2F5F2D.9DF0298E@lucent.com> Date: Tue, 19 Jun 2001 10:18:21 -0400 From: Terry L Anderson Organization: Lucent Technologies X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Megaco Mailing List Subject: TimeStamp Optional in Notify ObservedEventsDescriptor Content-Type: multipart/mixed; boundary="------------656A46D8D4B97E510B06340D" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk This is a multi-part message in MIME format. --------------656A46D8D4B97E510B06340D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I believe that TimeStamp is intended to be optional in ObservedEvents Descriptor. Both ABNF and ASN.1 have the element optional, but no where is this suggested in the text. Section 7.1.17 and 7.2.7 both mention time as one of the contents of ObservedEvents with no suggestion that it is optional. If the intention was to make it optional, seems like the text should mention that. Section 7.2.7 includes: Each event in the list is accompanied by parameters associated with the event and an indication of the time that the event was detected. which doesn't sound very optional and the statement in 7.1.17 includes it in a list where all other items are required. If we agree it should be optional I suggest clarifying this through the Implementors Guide. Sentence in 7.2.7 would read: Each event in the list is accompanied by parameters associated with the event and optionally an indication of the time that the event was detected. 7.1.17 to read: ObservedEvents contains the RequestIdentifier of the EventsDescriptor that triggered the notification, the event(s) detected, optionally the detection time(s) and any parameters of the event. To be more complete I'm also suggested adding meantion of the parameters here. Any objection? -- ------------------------------------------------------------ Terry L Anderson mailto:tla@lucent.com Tel:908.582.7013 Fax:908.582.6729 Lucent Technologies/INS/Voice Over IP Access Networks Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla --------------656A46D8D4B97E510B06340D Content-Type: text/x-vcard; charset=us-ascii; name="tla.vcf" Content-Description: Card for Terry L Anderson Content-Disposition: attachment; filename="tla.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Anderson;Terry L tel;fax:908.582.6729 tel;work:908.582.7013 x-mozilla-html:TRUE url:http://its.lucent.com/~tla org:Lucent / InterNetworking Systems;VoIP Access Networks version:2.1 email;internet:tla@lucent.com title:DMTS note:http://www.gti.net/tla or http://teton.mh.lucent.com/~tla (Lucent internal) adr;quoted-printable:;;600 Mountain Av=0D=0ARm 2B-121;Murray Hill;NJ;07974;USA x-mozilla-cpt:;21296 fn:Terry L Anderson end:vcard --------------656A46D8D4B97E510B06340D-- From owner-megaco@fore.com Tue Jun 19 11:38:55 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA24454 for ; Tue, 19 Jun 2001 11:38:55 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA08025; Tue, 19 Jun 2001 11:28:37 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id LAA14654 for megaco-list; Tue, 19 Jun 2001 11:26:58 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA14642 for ; Tue, 19 Jun 2001 11:26:56 -0400 (EDT) Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA07794 for ; Tue, 19 Jun 2001 11:26:52 -0400 (EDT) Received: from hoemail1.firewall.lucent.com (localhost [127.0.0.1]) by hoemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5JFQrB19720 for ; Tue, 19 Jun 2001 11:26:53 -0400 (EDT) Received: from teton.mh.lucent.com (h135-3-130-2.lucent.com [135.3.130.2]) by hoemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5JFQqP19706 for ; Tue, 19 Jun 2001 11:26:52 -0400 (EDT) Received: from lucent.com (pctla [135.3.130.39]) by teton.mh.lucent.com (8.8.8+Sun/8.8.8) with ESMTP id LAA28106 for ; Tue, 19 Jun 2001 11:26:50 -0400 (EDT) Message-ID: <3B2F7053.6880C6BC@lucent.com> Date: Tue, 19 Jun 2001 11:31:31 -0400 From: Terry L Anderson Organization: Lucent Technologies X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Megaco Mailing List Subject: Continuity Test Package reference Content-Type: multipart/mixed; boundary="------------7A84A6F4F2625BC125C5F2D5" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk This is a multi-part message in MIME format. --------------7A84A6F4F2625BC125C5F2D5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit E.10 Basic Continuity Package has no reference to a source for detail of the ct tone, the "appropriate response tone" in rsp for 2-wire circuits and other details of the test procedures. I believe the correct reference is Q.724 Section 7 & 8. I propose adding: Tones and test procedure details are given in Q.724 sections 7 and 8. to the description in sec E.10 and the formal reference to Sec 2.1 Normative references through the Implementors Guide. Can we make only sections 7 & 8 normative? Any objections? -- ------------------------------------------------------------ Terry L Anderson mailto:tla@lucent.com Tel:908.582.7013 Fax:908.582.6729 Lucent Technologies/INS/Voice Over IP Access Networks Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla --------------7A84A6F4F2625BC125C5F2D5 Content-Type: text/x-vcard; charset=us-ascii; name="tla.vcf" Content-Description: Card for Terry L Anderson Content-Disposition: attachment; filename="tla.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Anderson;Terry L tel;fax:908.582.6729 tel;work:908.582.7013 x-mozilla-html:TRUE url:http://its.lucent.com/~tla org:Lucent / InterNetworking Systems;VoIP Access Networks version:2.1 email;internet:tla@lucent.com title:DMTS note:http://www.gti.net/tla or http://teton.mh.lucent.com/~tla (Lucent internal) adr;quoted-printable:;;600 Mountain Av=0D=0ARm 2B-121;Murray Hill;NJ;07974;USA x-mozilla-cpt:;21296 fn:Terry L Anderson end:vcard --------------7A84A6F4F2625BC125C5F2D5-- From owner-megaco@fore.com Tue Jun 19 12:11:53 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25281 for ; Tue, 19 Jun 2001 12:11:53 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA08920; Tue, 19 Jun 2001 11:37:24 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id LAA17429 for megaco-list; Tue, 19 Jun 2001 11:36:11 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA17399 for ; Tue, 19 Jun 2001 11:36:08 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 19 Jun 2001 11:36:07 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF04465589@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Steven Weisz'" , "Megaco Mailing List (E-mail)" Subject: RE: Parsing Question Date: Tue, 19 Jun 2001 11:36:04 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk I was kind of hoping Tom would field this, but my opinion is that: (a) If the transactionId is incorrect, you toss the entire transaction; it doesn't matter what the commands are (b) I agree that you return an error on the optional command and continue processing IFF you can reliably determine the end of the command. This is problematic, and you should be conservative. (c) if you can't reliably determine the end of a command, then you have to stop processing commands in the transaction. This kind of problem should not cause your implementation much grief. It is a FATAL error to send an ill-formed message; nothing the recipient can do is likely to make matters better; there is a bug in the sender, and it has to be fixed. Therefore, if you decide that following anything that is a real syntax error you can't figure out where the next command is -- stop parsing the transaction, or even the message, and return an error. Brian > -----Original Message----- > From: Steven Weisz [mailto:sweisz@mediatrix.com] > Sent: Monday, June 18, 2001 11:06 AM > To: Megaco Mailing List (E-mail) > Subject: Parsing Question > > > Hi List, > > I am currently looking at what needs to be done when a > command is marked as > "optional" but during parsing of the command an error occurs. > > As I see it these are the possible scenarios (assuming at > least the command > token has been parsed): > > (a) A transactionId cannot be reliably determined > > (b) An error occurs in one of the command descriptors > > (c) there is no closing '}' for the command > > Now in case (a) we should fill the "action" reply with error > 442 - Syntax > error in command, does this mean that the command cannot be > skipped even > though it is optional? However, if it still can be skipped, > shouldn't we set > the "command" reply's error descriptor to something, since we > may still have > other command to process. > > Case (b) seems to be straight forward, that it we set the > "command" reply's > error descriptor appropriately. > > Case (c) leads me to believe that we would have to stop > parsing, since the > question would be what is the next token we could look for? > Would we expect > a ',' or a CtxToken or what? > > Is my reasoning making sense, do we try to skip optional > commands when a > parsing error is encountered? > > Thanks, > > Steven > > From owner-megaco@fore.com Tue Jun 19 17:59:53 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA06141 for ; Tue, 19 Jun 2001 17:59:51 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA06331; Tue, 19 Jun 2001 17:53:43 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id RAA17393 for megaco-list; Tue, 19 Jun 2001 17:51:59 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA17387 for ; Tue, 19 Jun 2001 17:51:58 -0400 (EDT) Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA06191 for ; Tue, 19 Jun 2001 17:51:53 -0400 (EDT) Received: from ihemail1.firewall.lucent.com (localhost [127.0.0.1]) by ihemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5JLptU19329 for ; Tue, 19 Jun 2001 17:51:55 -0400 (EDT) Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3]) by ihemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5JLpsK19322 for ; Tue, 19 Jun 2001 17:51:54 -0400 (EDT) Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id RAA29737; Tue, 19 Jun 2001 17:51:53 -0400 (EDT) Cc: MEGACO list Received: from lucent.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id RAA29728; Tue, 19 Jun 2001 17:51:52 -0400 (EDT) Message-ID: <3B2FC8FC.DBE78D72@lucent.com> Date: Tue, 19 Jun 2001 17:49:48 -0400 From: Troy Cauble Reply-To: Troy Cauble X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Christian Groves Original-CC: MEGACO list Subject: Re: New IG Editor References: <3B1E94E1.6289D721@lucent.com> <3B2028F2.AF537579@ericsson.com> <3B20DE1F.FD98E18B@lucent.com> <3B2D8837.8FA183DE@ericsson.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: 7bit If it was approved, shouldn't a version of the document that reflects this exist? ...so we can all read what was approved. -troy Christian Groves wrote: > > G'Day Troy, > > There were 2 changes: adding something with regards to EQUAL in digitmap > and removing 6.82 on servicechange for the next revision of the > implementors' guide/h248v2. > > Christian > > Troy Cauble wrote: > > > > Christian Groves wrote: > > > > > > G'Day Troy, All, > > > > > > At the SG16 meeting I gave up the editorship of the Implementors' Guide. > > > I have other commitments which meant I couldn't spend the necessary > > > time. > > > > > > The new editor is: Terry Anderson > > > > > > Cheers, Christian > > > > Thanks Christian for all the work. > > > > Was IG v7 approved? > > > > Has it changed since it was posted to > > http://standard.pictel.com/ftp/avc-site/0105_Por/DC-xxx_H248_Implementors_Additions_v7.zip > > ? > > > > -troy From owner-megaco@fore.com Tue Jun 19 18:10:40 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA06399 for ; Tue, 19 Jun 2001 18:10:40 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA07200; Tue, 19 Jun 2001 18:06:00 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id SAA19594 for megaco-list; Tue, 19 Jun 2001 18:04:48 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA19588 for ; Tue, 19 Jun 2001 18:04:47 -0400 (EDT) Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA07008 for ; Tue, 19 Jun 2001 18:04:43 -0400 (EDT) Received: from ihemail1.firewall.lucent.com (localhost [127.0.0.1]) by ihemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5JM4iU26184 for ; Tue, 19 Jun 2001 18:04:44 -0400 (EDT) Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3]) by ihemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5JM4iK26176 for ; Tue, 19 Jun 2001 18:04:44 -0400 (EDT) Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id SAA00204; Tue, 19 Jun 2001 18:04:43 -0400 (EDT) To: Christian Groves , MEGACO list Received: from lucent.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id SAA00195; Tue, 19 Jun 2001 18:04:42 -0400 (EDT) Message-ID: <3B2FCBFE.E8C22191@lucent.com> Date: Tue, 19 Jun 2001 18:02:38 -0400 From: Troy Cauble Reply-To: Troy Cauble X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 Original-To: Christian Groves , MEGACO list Subject: Re: New IG Editor References: <3B1E94E1.6289D721@lucent.com> <3B2028F2.AF537579@ericsson.com> <3B20DE1F.FD98E18B@lucent.com> <3B2D8837.8FA183DE@ericsson.com> <3B2FC8FC.DBE78D72@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: 7bit Whoops! I cleaned out my mailbox and saw that the reference has already been posted. This is the version approved at ITU SG16 ftp://standard.pictel.com/avc-site/0105_Por/PL-015_H248_imp_guide.zip -troy Troy Cauble wrote: > > If it was approved, shouldn't a version of > the document that reflects this exist? > > ...so we can all read what was approved. > > -troy > > Christian Groves wrote: > > > > G'Day Troy, > > > > There were 2 changes: adding something with regards to EQUAL in digitmap > > and removing 6.82 on servicechange for the next revision of the > > implementors' guide/h248v2. > > > > > > Was IG v7 approved? > > > > > > Has it changed since it was posted to > > > http://standard.pictel.com/ftp/avc-site/0105_Por/DC-xxx_H248_Implementors_Additions_v7.zip > > > ? > > > > > > -troy From owner-megaco@fore.com Wed Jun 20 01:31:37 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA16317 for ; Wed, 20 Jun 2001 01:31:37 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id BAA20318; Wed, 20 Jun 2001 01:26:56 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id BAA23811 for megaco-list; Wed, 20 Jun 2001 01:25:10 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id BAA23807 for ; Wed, 20 Jun 2001 01:25:08 -0400 (EDT) From: akalra@hss.hns.com Received: from hindon.hss.co.in ([202.54.26.202]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id BAA20226 for ; Wed, 20 Jun 2001 01:25:02 -0400 (EDT) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id f5K5QFG28848 for ; Wed, 20 Jun 2001 10:56:19 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256A71.001E2588 ; Wed, 20 Jun 2001 10:58:33 +0530 X-Lotus-FromDomain: HSS To: megaco@fore.com Message-ID: <65256A71.001DF77B.00@sandesh.hss.hns.com> Date: Wed, 20 Jun 2001 10:57:23 +0530 Subject: Query on case insensitivity Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Hi all, ABNF syntax notation is CASE INSENSITIVE, apart from the SDP and whatever comes within quotes should not be validated. My queries: 1. In case of short and long tokens can we mix both of them like MEGACO/1 [123.123.123.123]:55555 P = 50005 { Context = - { N = A5555 } Is it allowed? 2. Can we have tokens like "TranACTIONresponSEAck" , I mean mix of lower and upper case in one token ? 3. Can we have short tokens in lower case or mix case like "rc" or "rC" for ReceiveOnly ? regards/ Amit From owner-megaco@fore.com Wed Jun 20 03:03:03 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA29278 for ; Wed, 20 Jun 2001 03:03:03 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id CAA23275; Wed, 20 Jun 2001 02:54:15 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id CAA00107 for megaco-list; Wed, 20 Jun 2001 02:51:41 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id CAA00101 for ; Wed, 20 Jun 2001 02:51:39 -0400 (EDT) Received: from telesoft.indts.com ([164.164.71.52]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id CAA23167 for ; Wed, 20 Jun 2001 02:51:20 -0400 (EDT) Received: from indts_fs.indts.com (indts_fs [201.64.64.29]) by telesoft.indts.com (8.8.7/8.8.7) with ESMTP id MAA09846; Wed, 20 Jun 2001 12:40:56 +0530 Received: by INDTS_FS with Internet Mail Service (5.5.2650.21) id ; Wed, 20 Jun 2001 12:27:12 +0530 Message-ID: From: Lalit Kumar To: "'Madhu Babu Brahmanapally'" , megaco@fore.com Subject: RE: difference between servicechangeaddress and servicechangeMgcI d Date: Wed, 20 Jun 2001 12:27:11 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk hi, Thanks for the response, but some doubts still persist. In RFC3015 section 7.2.8, the document writes "The MG may specify an address in the ServiceChangeAddress parameter of the serviceChange Request, and the MGC may also do so in the ServiceChange reply. In either case, the recipient must use the supplied address as the destination for all subsequent transaction requests within the association......" In section 11.5 the document says, "In partial failure, or manual maintenance reasons, an MGC may wish to direct its controlled MGs to use a different MGC. To do so, it sends a ServiceChange method to the MG with a "Handoff" method, and its designated replacement in the ServiceMgcId............" According to my interpretation, besides sending serviceChangeMgcId at the time of registration, MGC might wish to send the ServiceChange Request with ServiceChangeMgcId for the mated pair, making transactions transparent to the MG. All the transaction replies, acks, request or pending shall be handled by the new MGC after making the new association. The MGC might also send a serviceChangeAddress when it wants to handle all the transaction replies/acks/pendings for transaction request initiated by it. All the new Transactions shall be handled by the newMG. This setup works in the current associated and MG need not establish a new association. Please correct me if my interpretation is wrong. With Regards, lalit -----Original Message----- From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com] Sent: Monday, June 18, 2001 7:18 PM To: 'Lalit Kumar'; megaco@fore.com Subject: RE: difference between servicechangeaddress and servicechangeMgcId Hi Lalit, The serviceChangeMgcId is sent from the MGC when it doesn't accept the registration request from the MG. And hence the serviceChangeMgcId is set to another MGC. In case the MGC accepts the registration request from the MG, the serviceChangeAddress is used to specify address to which further commands/responses need to be sent. Hope this answers your query. -Regards Madhubabu -----Original Message----- From: owner-megaco@pit.comms.marconi.com [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Lalit Kumar Sent: Monday, June 18, 2001 2:07 AM To: megaco@fore.com Subject: difference between servicechangeaddress and servicechangeMgcId hi, I was going through RFC3015 section 7.2.8. It says that "The ServiceChangeAddress provides an address to be used within the context of the association currently being negotiated, while the serviceChangeMgcId provides an alternative address where the MG should seek to establish another association." Can somebody explain the role of association?? Since both cannot be used simultaneously when should MGC use serviceChangeAddress and when should it use serviceChangeMgcId?? Thanks in advance, With Regards, lalit From owner-megaco@fore.com Wed Jun 20 03:14:53 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA29959 for ; Wed, 20 Jun 2001 03:14:52 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id DAA23636; Wed, 20 Jun 2001 03:04:46 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id DAA00693 for megaco-list; Wed, 20 Jun 2001 03:02:46 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id DAA00688 for ; Wed, 20 Jun 2001 03:02:44 -0400 (EDT) Received: from netmail2.alcatel.com (netmail2.alcatel.com [128.251.168.51]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id DAA23518 for ; Wed, 20 Jun 2001 03:02:41 -0400 (EDT) Received: from auds953.usa.alcatel.com (auds953.usa.alcatel.com [143.209.238.6]) by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id CAA11141 for ; Wed, 20 Jun 2001 02:02:41 -0500 (CDT) Received: from axes-mach01.axes-mach01.usa.alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f5K72cD22818 for ; Wed, 20 Jun 2001 02:02:39 -0500 (CDT) Received: from Chak by axes-mach01.axes-mach01.usa.alcatel.com (8.9.1b+Sun/SMI-SVR4) id MAA06396; Wed, 20 Jun 2001 12:28:40 -0500 (GMT) Message-ID: <007801c0f957$bb3975f0$2f09ca82@Chak> From: "PSK Chakravarthi" To: References: <65256A71.001DF77B.00@sandesh.hss.hns.com> Subject: Ephemeral Termination Date: Wed, 20 Jun 2001 12:37:54 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: 7bit I have got the following doubt. If the originating and terminating termination IDs are on the same gateway and gateway supports two TDM terminations in a context, is it required to craete a ephenmeral termination for this call? Message flow between MGC and MG: 1. MGC send ADD command to originating MG a) Choose a context ID b) Add a TDM termination c) Choose a Ephemeral termination d) Reserve Local Descriptor e) set MODE to Receive only. 2. MGC now finds that call is terminating on the same MG. Also MGC knows that MG is capable of adding two TDMs to the same context. At this point what should be the command to the MG? Is it required to SUBTRACT the ephemeral termination and send ADD for adding new TDM to the same context? or Simply sending ADD for new TDM to the same context is sufficient? thanks & regards Chak From owner-megaco@fore.com Wed Jun 20 07:11:35 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA02243 for ; Wed, 20 Jun 2001 07:11:35 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id GAA00955; Wed, 20 Jun 2001 06:56:51 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id GAA14001 for megaco-list; Wed, 20 Jun 2001 06:51:41 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id GAA13997 for ; Wed, 20 Jun 2001 06:51:40 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id GAA00680 for ; Wed, 20 Jun 2001 06:51:36 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01949; Wed, 20 Jun 2001 06:51:01 -0400 (EDT) Message-Id: <200106201051.GAA01949@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: megaco@fore.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-megaco-r2package-02.txt Date: Wed, 20 Jun 2001 06:51:01 -0400 Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Media Gateway Control Working Group of the IETF. Title : Megaco/H.248 R2 Package Author(s) : K. Laha, V. Nair Filename : draft-ietf-megaco-r2package-02.txt Pages : 35 Date : 19-Jun-01 This document is work in progress and defines the R2 package in association with the Megaco/H.248 Protocol that can be used to control a Media Gateway (MG) from an external controller, called a Media Gateway controller (MGC). It is intended to satisfy the requirements in section 12 of the Megaco/H.248 requirement document [2]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-megaco-r2package-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-megaco-r2package-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-megaco-r2package-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010619113244.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-megaco-r2package-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-megaco-r2package-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010619113244.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-megaco@fore.com Wed Jun 20 08:35:13 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA04627 for ; Wed, 20 Jun 2001 08:35:12 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA04983; Wed, 20 Jun 2001 08:30:30 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id IAA26232 for megaco-list; Wed, 20 Jun 2001 08:28:39 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA26226 for ; Wed, 20 Jun 2001 08:28:38 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 20 Jun 2001 08:28:35 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF0446559B@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'akalra@hss.hns.com'" , megaco@fore.com Subject: RE: Query on case insensitivity Date: Wed, 20 Jun 2001 08:28:32 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk The answer to all of your queries is yes Brian > -----Original Message----- > From: akalra@hss.hns.com [mailto:akalra@hss.hns.com] > Sent: Wednesday, June 20, 2001 1:27 AM > To: megaco@fore.com > Subject: Query on case insensitivity > > > > > Hi all, > ABNF syntax notation is CASE INSENSITIVE, apart from the > SDP and whatever > comes within quotes should not be validated. > My queries: > 1. In case of short and long tokens can we mix both of them like > > MEGACO/1 [123.123.123.123]:55555 > P = 50005 { > Context = - { N = A5555 } > Is it allowed? > > 2. Can we have tokens like "TranACTIONresponSEAck" , I > mean mix of lower and > upper case in one token ? > > 3. Can we have short tokens in lower case or mix case like > "rc" or "rC" for > ReceiveOnly ? > > regards/ > Amit > > From owner-megaco@fore.com Wed Jun 20 08:52:24 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA05279 for ; Wed, 20 Jun 2001 08:52:23 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA05922; Wed, 20 Jun 2001 08:42:15 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id IAA28196 for megaco-list; Wed, 20 Jun 2001 08:38:33 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA28190 for ; Wed, 20 Jun 2001 08:38:32 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 20 Jun 2001 08:38:30 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF0446559C@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Lalit Kumar'" , "'Madhu Babu Brahmanapally'" , megaco@fore.com Subject: RE: difference between servicechangeaddress and servicechangeMgcI d Date: Wed, 20 Jun 2001 08:38:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk A ServiceChange with Handoff causes the MG to create a new association. There is no way to use this mechanism to make the handoff transparent. If you did send both, the MG would use the ServiceChangeAddress for any subsequent commands to the old MGC, but there shouldn't be any. I'll point out that immediately after the MGC sends the Handoff, it needs to be able to continue to recieve commands from the MG because there is an indeterminate time difference between when the MGC sends the Handoff, and the MG actually performs it. Brian > -----Original Message----- > From: Lalit Kumar [mailto:lalit@indts.com] > Sent: Wednesday, June 20, 2001 2:57 AM > To: 'Madhu Babu Brahmanapally'; megaco@fore.com > Subject: RE: difference between servicechangeaddress and > servicechangeMgcI d > > > hi, > Thanks for the response, but some doubts still persist. > > In RFC3015 section 7.2.8, the document writes "The MG may > specify an > address in the ServiceChangeAddress parameter of the > serviceChange Request, > and the MGC may also do so in the ServiceChange reply. In > either case, the > recipient must use the supplied address as the destination for all > subsequent transaction requests within the association......" > > In section 11.5 the document says, "In partial failure, or manual > maintenance reasons, an MGC may wish to direct its controlled > MGs to use a > different MGC. To do so, it sends a ServiceChange method to > the MG with a > "Handoff" method, and its designated replacement in the > ServiceMgcId............" > > According to my interpretation, besides sending > serviceChangeMgcId at the > time of registration, MGC might wish to send the > ServiceChange Request with > ServiceChangeMgcId for the mated pair, making transactions > transparent to > the MG. All the transaction replies, acks, request or pending shall be > handled by the new MGC after making the new association. > > The MGC might also send a serviceChangeAddress when it > wants to handle > all the transaction replies/acks/pendings for transaction > request initiated > by it. All the new Transactions shall be handled by the > newMG. This setup > works in the current associated and MG need not establish a > new association. > > Please correct me if my interpretation is wrong. > > With Regards, > lalit > > > > -----Original Message----- > From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com] > Sent: Monday, June 18, 2001 7:18 PM > To: 'Lalit Kumar'; megaco@fore.com > Subject: RE: difference between servicechangeaddress and > servicechangeMgcId > > > Hi Lalit, > The serviceChangeMgcId is sent from the MGC when it doesn't accept the > registration request from the MG. And hence the > serviceChangeMgcId is set to > another MGC. In case the MGC accepts the registration request > from the MG, > the serviceChangeAddress is used to specify address to which further > commands/responses need to be sent. Hope this answers your query. > -Regards > Madhubabu > > -----Original Message----- > From: owner-megaco@pit.comms.marconi.com > [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Lalit Kumar > Sent: Monday, June 18, 2001 2:07 AM > To: megaco@fore.com > Subject: difference between servicechangeaddress and > servicechangeMgcId > > > hi, > I was going through RFC3015 section 7.2.8. It says that > "The ServiceChangeAddress provides an address to be used > within the > context of the association currently being negotiated, while the > serviceChangeMgcId provides an alternative address where the > MG should seek > to establish another association." > > Can somebody explain the role of association?? > Since both cannot be used simultaneously when should MGC use > serviceChangeAddress and when should it use serviceChangeMgcId?? > > Thanks in advance, > > With Regards, > lalit > From owner-megaco@fore.com Wed Jun 20 08:55:08 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA05397 for ; Wed, 20 Jun 2001 08:55:08 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA06282; Wed, 20 Jun 2001 08:45:31 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id IAA29273 for megaco-list; Wed, 20 Jun 2001 08:43:08 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA29241 for ; Wed, 20 Jun 2001 08:43:04 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 20 Jun 2001 08:43:02 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF0446559D@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'PSK Chakravarthi'" , megaco@fore.com Subject: RE: Ephemeral Termination Date: Wed, 20 Jun 2001 08:43:01 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk No, you don't need the ephemeral for a "hairpin" connection. I don't understand why you would create the ephemeral before you know the terminating MG. You might create the context with the originating termination, but when you determine the terminating MG is the same you Add the other termination, and if you determine that it is in another MG then you Add the ephemeral. A basic call with a hairpin is two physicals in the context. Brian > -----Original Message----- > From: PSK Chakravarthi [mailto:chak@axes-mach01.usa.alcatel.com] > Sent: Wednesday, June 20, 2001 3:08 AM > To: megaco@fore.com > Subject: Ephemeral Termination > > > I have got the following doubt. > If the originating and terminating termination IDs are on the > same gateway and > gateway supports two TDM terminations in a context, is it > required to craete a > ephenmeral termination for this call? > > Message flow between MGC and MG: > > 1. MGC send ADD command to originating MG > a) Choose a context ID > b) Add a TDM termination > c) Choose a Ephemeral termination > d) Reserve Local Descriptor > e) set MODE to Receive only. > > 2. MGC now finds that call is terminating on the same MG. > Also MGC knows that > MG is capable of adding two TDMs to the same context. At > this point what should > be the command to the MG? > Is it required to SUBTRACT the ephemeral termination and send > ADD for adding new > TDM to the same context? or > Simply sending ADD for new TDM to the same context is sufficient? > > thanks & regards > Chak > > > From owner-megaco@fore.com Wed Jun 20 09:27:40 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA06475 for ; Wed, 20 Jun 2001 09:27:40 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA09669; Wed, 20 Jun 2001 09:21:33 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id JAA08698 for megaco-list; Wed, 20 Jun 2001 09:20:46 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA08682 for ; Wed, 20 Jun 2001 09:20:44 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 20 Jun 2001 09:20:41 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF044655A0@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Sarju Garg'" , "'megaco'" Subject: RE: Property Characteristics Date: Wed, 20 Jun 2001 09:20:37 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F98B.CB9BA740" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0F98B.CB9BA740 Content-Type: text/plain; charset="iso-8859-1" Global and read/write are independent; you can have any combination. Packages should define the values. If they don't, there is no default, and it's implementation dependent - a bad idea. I do believe the current convention is that if you don't say Global, then it's "local". Brian -----Original Message----- From: Sarju Garg [mailto:sarju@bhartitelesoft.com] Sent: Wednesday, June 20, 2001 9:20 AM To: 'megaco' Subject: Property Characteristics Hi all, I have a question pertaining to property characteristics. What I understand is that the characteristics of property is one of the following: read and local read/write and local read/write and global read and global Is write and local and write and global characteristics is also possible as Sec 12.1.2 says Characteristics: Read/Write or both and (optionally global)? What is the default characteristics of the property as none of the package define the characteristics? TIA Sarju ------_=_NextPart_001_01C0F98B.CB9BA740 Content-Type: text/html; charset="iso-8859-1"
Global and read/write are independent; you can have any combination.
 
Packages should define the values.  If they don't, there is no default, and
it's implementation dependent - a bad idea.  I do believe the current
convention is that if you don't say Global, then it's "local".
 
Brian
-----Original Message-----
From: Sarju Garg [mailto:sarju@bhartitelesoft.com]
Sent: Wednesday, June 20, 2001 9:20 AM
To: 'megaco'
Subject: Property Characteristics

Hi all,
 
I have a question pertaining to property characteristics. What I understand is that the characteristics of property is one of the following:
read and local
read/write and local
read/write and global
read and global
 
Is write and local and write and global characteristics is also possible as Sec 12.1.2 says Characteristics: Read/Write or both and (optionally global)?
 
What is the default characteristics of the property as none of the package define the characteristics?
 
TIA
Sarju 
------_=_NextPart_001_01C0F98B.CB9BA740-- From owner-megaco@fore.com Wed Jun 20 09:34:31 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA06855 for ; Wed, 20 Jun 2001 09:34:30 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA09085; Wed, 20 Jun 2001 09:16:29 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id JAA06954 for megaco-list; Wed, 20 Jun 2001 09:15:26 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA06948 for ; Wed, 20 Jun 2001 09:15:25 -0400 (EDT) Received: from mail.bhartitelesoft.com ([202.56.229.147]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA08898 for ; Wed, 20 Jun 2001 09:15:17 -0400 (EDT) Received: from sarju (taquila [202.56.229.146]) by mail.bhartitelesoft.com (8.11.0/8.11.0) with SMTP id f5KDCkF22446 for ; Wed, 20 Jun 2001 18:42:47 +0530 Message-ID: <007d01c0f98b$a56676e0$240310ac@bhartitelesoft.com> Reply-To: "Sarju Garg" From: "Sarju Garg" To: "'megaco'" Subject: Property Characteristics Date: Wed, 20 Jun 2001 18:49:31 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_007A_01C0F9B9.BDAEF640" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_007A_01C0F9B9.BDAEF640 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, I have a question pertaining to property characteristics. What I = understand is that the characteristics of property is one of the = following: read and local read/write and local read/write and global read and global Is write and local and write and global characteristics is also possible = as Sec 12.1.2 says Characteristics: Read/Write or both and (optionally = global)? What is the default characteristics of the property as none of the = package define the characteristics? TIA Sarju=20 ------=_NextPart_000_007A_01C0F9B9.BDAEF640 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi all,
 
I have a question pertaining to = property=20 characteristics. What I understand is that the characteristics of = property is=20 one of the following:
read and local
read/write and local
read/write and global
read and global
 
Is write and local and write and global = characteristics is also possible as Sec 12.1.2 says Characteristics: = Read/Write=20 or both and (optionally global)?
 
What is = the default characteristics of=20 the property as none of the package define the = characteristics?
 
TIA
Sarju 
------=_NextPart_000_007A_01C0F9B9.BDAEF640-- From owner-megaco@fore.com Wed Jun 20 10:07:01 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08096 for ; Wed, 20 Jun 2001 10:07:00 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA12722; Wed, 20 Jun 2001 09:52:55 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id JAA18326 for megaco-list; Wed, 20 Jun 2001 09:51:11 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA18318 for ; Wed, 20 Jun 2001 09:51:10 -0400 (EDT) Received: from mail.bhartitelesoft.com ([202.56.229.147]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA12486 for ; Wed, 20 Jun 2001 09:51:02 -0400 (EDT) Received: from sarju (taquila [202.56.229.146]) by mail.bhartitelesoft.com (8.11.0/8.11.0) with SMTP id f5KDmSF28016; Wed, 20 Jun 2001 19:18:29 +0530 Message-ID: <008d01c0f990$a13e5ec0$240310ac@bhartitelesoft.com> Reply-To: "Sarju Garg" From: "Sarju Garg" To: "Rosen, Brian" , "'megaco'" References: <4FBEA8857476D311A03300204840E1CF044655A0@whq-msgusr-02.pit.comms.marconi.com> Subject: Re: Property Characteristics Date: Wed, 20 Jun 2001 19:25:07 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0088_01C0F9BE.B6F84400" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0088_01C0F9BE.B6F84400 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable But it is pretty confusing in the document. In Section 12.1.2 it says. = Indicates whether a property is read-only or read-write and if it is = global. Also Sec 6.2.4 says that the property mat be read-only or = read/write. No mention of write in these cases. Can we specify an unambiguous line in the document?. I feel there should = be no convention in the standards. Everything should be specified = explicitly whereever possible.=20 Sarju ----- Original Message -----=20 From: Rosen, Brian=20 To: 'Sarju Garg' ; 'megaco'=20 Sent: Wednesday, June 20, 2001 6:50 PM Subject: RE: Property Characteristics Global and read/write are independent; you can have any combination. =20 Packages should define the values. If they don't, there is no = default, and it's implementation dependent - a bad idea. I do believe the current convention is that if you don't say Global, then it's "local". =20 Brian -----Original Message----- From: Sarju Garg [mailto:sarju@bhartitelesoft.com] Sent: Wednesday, June 20, 2001 9:20 AM To: 'megaco' Subject: Property Characteristics Hi all, I have a question pertaining to property characteristics. What I = understand is that the characteristics of property is one of the = following: read and local read/write and local read/write and global read and global Is write and local and write and global characteristics is also = possible as Sec 12.1.2 says Characteristics: Read/Write or both and = (optionally global)? =20 What is the default characteristics of the property as none of the = package define the characteristics? TIA Sarju=20 ------=_NextPart_000_0088_01C0F9BE.B6F84400 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
But it is pretty confusing in the = document. In=20 Section 12.1.2 it says. Indicates whether a property is read-only or = read-write=20 and if it is global. Also Sec 6.2.4 says that the property mat be = read-only or=20 read/write. No mention of write in these cases.
Can we specify an unambiguous line in = the=20 document?. I feel there should be no convention in the standards. = Everything=20 should be specified explicitly whereever possible.
 
Sarju
 
----- Original Message -----
From:=20 Rosen,=20 Brian
To: 'Sarju=20 Garg' ; 'megaco'
Sent: Wednesday, June 20, 2001 = 6:50=20 PM
Subject: RE: Property=20 Characteristics

Global and=20 read/write are independent; you can have any = combination.
 
Packages=20 should define the values.  If they don't, there is no default,=20 and
it's=20 implementation dependent - a bad idea.  I do believe the=20 current
convention=20 is that if you don't say Global, then it's = "local".
 
Brian
-----Original Message-----
From: Sarju Garg [mailto:sarju@bhartitelesoft.com<= /A>]
Sent:=20 Wednesday, June 20, 2001 9:20 AM
To: = 'megaco'
Subject:=20 Property Characteristics

Hi all,
 
I have a question pertaining to = property=20 characteristics. What I understand is that the characteristics of = property=20 is one of the following:
read and local
read/write and local
read/write and global
read and global
 
Is write and local and write and = global=20 characteristics is also possible as Sec 12.1.2 says Characteristics: = Read/Write or both and (optionally global)?
 
What is = the default characteristics=20 of the property as none of the package define the=20 characteristics?
 
TIA
Sarju 
= ------=_NextPart_000_0088_01C0F9BE.B6F84400-- From owner-megaco@fore.com Wed Jun 20 10:47:17 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09665 for ; Wed, 20 Jun 2001 10:47:17 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA16386; Wed, 20 Jun 2001 10:28:59 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA28684 for megaco-list; Wed, 20 Jun 2001 10:25:47 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA28669 for ; Wed, 20 Jun 2001 10:25:45 -0400 (EDT) Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA16035 for ; Wed, 20 Jun 2001 10:25:36 -0400 (EDT) Received: from hoemail1.firewall.lucent.com (localhost [127.0.0.1]) by hoemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5KEPbx18331 for ; Wed, 20 Jun 2001 10:25:37 -0400 (EDT) Received: from teton.mh.lucent.com (h135-3-130-2.lucent.com [135.3.130.2]) by hoemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5KEPa718326 for ; Wed, 20 Jun 2001 10:25:36 -0400 (EDT) Received: from lucent.com (pctla [135.3.130.39]) by teton.mh.lucent.com (8.8.8+Sun/8.8.8) with ESMTP id KAA19333 for ; Wed, 20 Jun 2001 10:25:36 -0400 (EDT) Message-ID: <3B30B36F.C3F79AA2@lucent.com> Date: Wed, 20 Jun 2001 10:30:07 -0400 From: Terry L Anderson Organization: Lucent Technologies X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Megaco Mailing List Subject: NotifyCompletion and g/sc Meth Content-Type: multipart/mixed; boundary="------------0C9335A623C4A93AB4A9044F" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk This is a multi-part message in MIME format. --------------0C9335A623C4A93AB4A9044F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit NotifyCompletion reasons and g/sc{Meth=XX} codes are abviously paired. TimeOut -- TO Duration expired IntByEvent -- EV Interrupted by event IntBySigDescr -- SD Halted by new Signals Descriptor OtherReason -- NC Not completed, other cause What is not so clear is which of these is appropriate for the case of a signal that "plays to completion" for reasons other than time, e.g., a voice announcement file. The use of OtherReason/NC does not seem appropriate, since this is usually used for errors and it controdicts the "not completed" text. Such signals could be of type "brief" or time "timeout". I believe that TimeOut/TO is the most appropriate, in spite of time not being the real cause and in private discussions, others suggest that this was the original intent. The choice of words for the reason is unfortunate - NormalCompletion might have been clearer. The "Duration expired" is more applicable than the "TimeOut". I suggest we add language to make it clear that this is the correct reason. 7.1.11 3rd paragraph change the sentence to: The possible cases are that the signal timed out (or otherwise ended on its own), that it was interrupted ... E.1.2 change the text after "TO" in Meth to "TO" (0x0001) Signal Timed out or otherwise ended on its own. I will add this to the Implementors Guide unless there is an objection. -- ------------------------------------------------------------ Terry L Anderson mailto:tla@lucent.com Tel:908.582.7013 Fax:908.582.6729 Lucent Technologies/INS/Voice Over IP Access Networks Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla --------------0C9335A623C4A93AB4A9044F Content-Type: text/x-vcard; charset=us-ascii; name="tla.vcf" Content-Description: Card for Terry L Anderson Content-Disposition: attachment; filename="tla.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Anderson;Terry L tel;fax:908.582.6729 tel;work:908.582.7013 x-mozilla-html:TRUE url:http://its.lucent.com/~tla org:Lucent / InterNetworking Systems;VoIP Access Networks version:2.1 email;internet:tla@lucent.com title:DMTS note:http://www.gti.net/tla or http://teton.mh.lucent.com/~tla (Lucent internal) adr;quoted-printable:;;600 Mountain Av=0D=0ARm 2B-121;Murray Hill;NJ;07974;USA x-mozilla-cpt:;21296 fn:Terry L Anderson end:vcard --------------0C9335A623C4A93AB4A9044F-- From owner-megaco@fore.com Wed Jun 20 11:04:16 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10088 for ; Wed, 20 Jun 2001 11:04:15 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA18332; Wed, 20 Jun 2001 10:50:32 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA02395 for megaco-list; Wed, 20 Jun 2001 10:48:20 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA01483 for ; Wed, 20 Jun 2001 10:32:56 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 20 Jun 2001 10:31:17 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF044655A1@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Sarju Garg'" , "'megaco'" Subject: RE: Property Characteristics Date: Wed, 20 Jun 2001 10:31:17 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F995.AAA187D0" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0F995.AAA187D0 Content-Type: text/plain; charset="iso-8859-1" Here is the entire text: Characteristics: Read / Write or both, and (optionally), global: Indicates whether a property is read-only, or read-write, and if it is global. If Global is omitted, the property is not global. If a property is declared as global, the value of the property is shared by all terminations realizing the package. The only part I see that is potentially confusing is whether you can have a write-only property. Such things used to happen in hardware design, but it's been a LONG time since I allowed any engineer to create one. I can try rewriting it: Characteristics: A property may have one or two characteristics specified: read/write and global. The read/write characteristic is specified as "read-only" or "read-write". Every property MUST specify read/write. The characteristics specification MAY also include the "Global" keyword. If Global is specified, the value of the property is shared by all terminations realizing the package. If Global is not specified, each termination realizing the package has an independent value of the property. If you really think that makes it more clear, we can ask that the rewritten text appear in the IG. Brian -----Original Message----- From: Sarju Garg [mailto:sarju@bhartitelesoft.com] Sent: Wednesday, June 20, 2001 9:55 AM To: Rosen, Brian; 'megaco' Subject: Re: Property Characteristics But it is pretty confusing in the document. In Section 12.1.2 it says. Indicates whether a property is read-only or read-write and if it is global. Also Sec 6.2.4 says that the property mat be read-only or read/write. No mention of write in these cases. Can we specify an unambiguous line in the document?. I feel there should be no convention in the standards. Everything should be specified explicitly whereever possible. Sarju ----- Original Message ----- From: Rosen, Brian To: 'Sarju Garg' ; 'megaco' Sent: Wednesday, June 20, 2001 6:50 PM Subject: RE: Property Characteristics Global and read/write are independent; you can have any combination. Packages should define the values. If they don't, there is no default, and it's implementation dependent - a bad idea. I do believe the current convention is that if you don't say Global, then it's "local". Brian -----Original Message----- From: Sarju Garg [ mailto:sarju@bhartitelesoft.com ] Sent: Wednesday, June 20, 2001 9:20 AM To: 'megaco' Subject: Property Characteristics Hi all, I have a question pertaining to property characteristics. What I understand is that the characteristics of property is one of the following: read and local read/write and local read/write and global read and global Is write and local and write and global characteristics is also possible as Sec 12.1.2 says Characteristics: Read/Write or both and (optionally global)? What is the default characteristics of the property as none of the package define the characteristics? TIA Sarju ------_=_NextPart_001_01C0F995.AAA187D0 Content-Type: text/html; charset="iso-8859-1"
Here is the entire text:
 
     Characteristics: Read / Write or both, and (optionally), global:
     Indicates whether a property is read-only, or read-write, and if
     it is global.  If Global is omitted, the property is not global. 
     If a property is declared as global, the value of the property is
     shared by all terminations realizing the package.
The only part I see that is potentially confusing is whether you can have
a write-only property.  Such things used to happen in hardware design,
but it's been a LONG time since I allowed any engineer to create one.
 
I can try rewriting it:
Characteristics: A property may have one or two characteristics specified:
read/write and global.  The read/write characteristic is specified as
"read-only" or "read-write".  Every property MUST specify read/write.
The characteristics specification MAY also include the "Global"
keyword.  If Global is specified, the value of the property is shared
by all terminations realizing the package.  If Global is not specified,
each termination realizing the package has an independent value of
the property. 
 
If you really think that makes it more clear, we can ask that the
rewritten text appear in the IG.
 
Brian
 
-----Original Message-----
From: Sarju Garg [mailto:sarju@bhartitelesoft.com]
Sent: Wednesday, June 20, 2001 9:55 AM
To: Rosen, Brian; 'megaco'
Subject: Re: Property Characteristics

But it is pretty confusing in the document. In Section 12.1.2 it says. Indicates whether a property is read-only or read-write and if it is global. Also Sec 6.2.4 says that the property mat be read-only or read/write. No mention of write in these cases.
Can we specify an unambiguous line in the document?. I feel there should be no convention in the standards. Everything should be specified explicitly whereever possible.
 
Sarju
 
----- Original Message -----
Sent: Wednesday, June 20, 2001 6:50 PM
Subject: RE: Property Characteristics

Global and read/write are independent; you can have any combination.
 
Packages should define the values.  If they don't, there is no default, and
it's implementation dependent - a bad idea.  I do believe the current
convention is that if you don't say Global, then it's "local".
 
Brian
-----Original Message-----
From: Sarju Garg [mailto:sarju@bhartitelesoft.com]
Sent: Wednesday, June 20, 2001 9:20 AM
To: 'megaco'
Subject: Property Characteristics

Hi all,
 
I have a question pertaining to property characteristics. What I understand is that the characteristics of property is one of the following:
read and local
read/write and local
read/write and global
read and global
 
Is write and local and write and global characteristics is also possible as Sec 12.1.2 says Characteristics: Read/Write or both and (optionally global)?
 
What is the default characteristics of the property as none of the package define the characteristics?
 
TIA
Sarju 
------_=_NextPart_001_01C0F995.AAA187D0-- From owner-megaco@fore.com Wed Jun 20 11:05:33 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10132 for ; Wed, 20 Jun 2001 11:05:33 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA19213; Wed, 20 Jun 2001 10:55:30 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA09852 for megaco-list; Wed, 20 Jun 2001 10:52:40 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA09818 for ; Wed, 20 Jun 2001 10:51:22 -0400 (EDT) Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA18444 for ; Wed, 20 Jun 2001 10:51:15 -0400 (EDT) Received: from hoemail1.firewall.lucent.com (localhost [127.0.0.1]) by hoemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5KEpFx20253 for ; Wed, 20 Jun 2001 10:51:16 -0400 (EDT) Received: from teton.mh.lucent.com (h135-3-130-2.lucent.com [135.3.130.2]) by hoemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5KEpF720246; Wed, 20 Jun 2001 10:51:15 -0400 (EDT) Received: from lucent.com (pctla [135.3.130.39]) by teton.mh.lucent.com (8.8.8+Sun/8.8.8) with ESMTP id KAA22550; Wed, 20 Jun 2001 10:51:15 -0400 (EDT) Message-ID: <3B30B971.5DA36350@lucent.com> Date: Wed, 20 Jun 2001 10:55:45 -0400 From: Terry L Anderson Organization: Lucent Technologies X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Lalit Kumar CC: "'Madhu Babu Brahmanapally'" , megaco@fore.com Subject: Re: difference between servicechangeaddress and servicechangeMgcId References: Content-Type: multipart/mixed; boundary="------------6E5A4AEBE56D61A93DF62535" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk This is a multi-part message in MIME format. --------------6E5A4AEBE56D61A93DF62535 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lalit Kumar wrote: > hi, > Thanks for the response, but some doubts still persist. > > In RFC3015 section 7.2.8, the document writes "The MG may specify an > address in the ServiceChangeAddress parameter of the serviceChange Request, > and the MGC may also do so in the ServiceChange reply. In either case, the > recipient must use the supplied address as the destination for all > subsequent transaction requests within the association......" but you end your quote too soon. see below. > In section 11.5 the document says, "In partial failure, or manual > maintenance reasons, an MGC may wish to direct its controlled MGs to use a > different MGC. To do so, it sends a ServiceChange method to the MG with a > "Handoff" method, and its designated replacement in the > ServiceMgcId............" > > According to my interpretation, besides sending serviceChangeMgcId at the > time of registration, MGC might wish to send the ServiceChange Request with > ServiceChangeMgcId for the mated pair, making transactions transparent to > the MG. All the transaction replies, acks, request or pending shall be > handled by the new MGC after making the new association. But 7.2.8 says, "In either case, the recipient must use the supplied address as the destination for all subsequent transaction requests within the association. At the same time, as indicated in section 9, transaction repies and pending indications must be sent to the address from which the corresponding requests originated." and in second paragraph of section 9 "As describged in section 7.2.8, either the MG or the MGC may supply an address in the ServiceChangeAddress parameter to which subsequent request must be addressed, but responses (including the response to the initial ServiceChange request) must always be sent back to the address which was the source of the corresponding request." and in D.1.5 fourth paragraph (applying to UDP only) "...a valid ServiceChange message announcing a failover, it will start transmitting outstanding commands to that new MGC. Responses to commands are still transmitted to the source address of the command." I think that this is pretty clear that the intent was NOT to make any exceptions to the principle stated in D.1 (for UDP) "Responses must be sent to the address and port from which the corresponding commands were sent." > The MGC might also send a serviceChangeAddress when it wants to handle > all the transaction replies/acks/pendings for transaction request initiated > by it. All the new Transactions shall be handled by the newMG. This setup > works in the current associated and MG need not establish a new association. > > Please correct me if my interpretation is wrong. You might prefer a different policy, but I think that the policy in H.248 is clear - responses always go to source address of request, never to any advertised address. > > > With Regards, > lalit > > -----Original Message----- > From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com] > Sent: Monday, June 18, 2001 7:18 PM > To: 'Lalit Kumar'; megaco@fore.com > Subject: RE: difference between servicechangeaddress and > servicechangeMgcId > > Hi Lalit, > The serviceChangeMgcId is sent from the MGC when it doesn't accept the > registration request from the MG. And hence the serviceChangeMgcId is set to > another MGC. In case the MGC accepts the registration request from the MG, > the serviceChangeAddress is used to specify address to which further > commands/responses need to be sent. Hope this answers your query. > -Regards > Madhubabu > > -----Original Message----- > From: owner-megaco@pit.comms.marconi.com > [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Lalit Kumar > Sent: Monday, June 18, 2001 2:07 AM > To: megaco@fore.com > Subject: difference between servicechangeaddress and servicechangeMgcId > > hi, > I was going through RFC3015 section 7.2.8. It says that > "The ServiceChangeAddress provides an address to be used within the > context of the association currently being negotiated, while the > serviceChangeMgcId provides an alternative address where the MG should seek > to establish another association." > > Can somebody explain the role of association?? > Since both cannot be used simultaneously when should MGC use > serviceChangeAddress and when should it use serviceChangeMgcId?? > > Thanks in advance, > > With Regards, > lalit -- ------------------------------------------------------------ Terry L Anderson mailto:tla@lucent.com Tel:908.582.7013 Fax:908.582.6729 Lucent Technologies/INS/Voice Over IP Access Networks Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla --------------6E5A4AEBE56D61A93DF62535 Content-Type: text/x-vcard; charset=us-ascii; name="tla.vcf" Content-Description: Card for Terry L Anderson Content-Disposition: attachment; filename="tla.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Anderson;Terry L tel;fax:908.582.6729 tel;work:908.582.7013 x-mozilla-html:TRUE url:http://its.lucent.com/~tla org:Lucent / InterNetworking Systems;VoIP Access Networks version:2.1 email;internet:tla@lucent.com title:DMTS note:http://www.gti.net/tla or http://teton.mh.lucent.com/~tla (Lucent internal) adr;quoted-printable:;;600 Mountain Av=0D=0ARm 2B-121;Murray Hill;NJ;07974;USA x-mozilla-cpt:;21296 fn:Terry L Anderson end:vcard --------------6E5A4AEBE56D61A93DF62535-- From owner-megaco@fore.com Wed Jun 20 11:17:12 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10539 for ; Wed, 20 Jun 2001 11:17:12 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA20215; Wed, 20 Jun 2001 11:02:14 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id LAA14125 for megaco-list; Wed, 20 Jun 2001 11:01:35 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA14112 for ; Wed, 20 Jun 2001 11:01:33 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 20 Jun 2001 11:01:30 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF044655A6@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Terry L Anderson'" , Lalit Kumar Cc: "'Madhu Babu Brahmanapally'" , megaco@fore.com Subject: RE: difference between servicechangeaddress and servicechangeMgcI d Date: Wed, 20 Jun 2001 11:01:28 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Of course this is very true, but only applies to REPLIES. A particular thing to note is that a Notify issued AFTER a Handoff is processed is sent to the new MGC. Brian > -----Original Message----- > From: Terry L Anderson [mailto:tla@lucent.com] > Sent: Wednesday, June 20, 2001 10:56 AM > To: Lalit Kumar > Cc: 'Madhu Babu Brahmanapally'; megaco@fore.com > Subject: Re: difference between servicechangeaddress and > servicechangeMgcId > > > > > Lalit Kumar wrote: > > > hi, > > Thanks for the response, but some doubts still persist. > > > > In RFC3015 section 7.2.8, the document writes "The MG > may specify an > > address in the ServiceChangeAddress parameter of the > serviceChange Request, > > and the MGC may also do so in the ServiceChange reply. In > either case, the > > recipient must use the supplied address as the destination for all > > subsequent transaction requests within the association......" > > but you end your quote too soon. see below. > > > In section 11.5 the document says, "In partial failure, or manual > > maintenance reasons, an MGC may wish to direct its > controlled MGs to use a > > different MGC. To do so, it sends a ServiceChange method to > the MG with a > > "Handoff" method, and its designated replacement in the > > ServiceMgcId............" > > > > According to my interpretation, besides sending > serviceChangeMgcId at the > > time of registration, MGC might wish to send the > ServiceChange Request with > > ServiceChangeMgcId for the mated pair, making transactions > transparent to > > the MG. All the transaction replies, acks, request or > pending shall be > > handled by the new MGC after making the new association. > > But 7.2.8 says, > "In either case, the recipient must use the supplied > address as the > destination for all subsequent transaction requests within > the association. At > the same time, as indicated in section 9, transaction repies > and pending > indications must be sent to the address from which the > corresponding requests > originated." > > and in second paragraph of section 9 > "As describged in section 7.2.8, either the MG or the MGC > may supply an > address in the ServiceChangeAddress parameter to which > subsequent request must > be addressed, but responses (including the response to the > initial ServiceChange > request) must always be sent back to the address which was > the source of the > corresponding request." > > and in D.1.5 fourth paragraph (applying to UDP only) > "...a valid ServiceChange message announcing a failover, > it will start > transmitting outstanding commands to that new MGC. Responses > to commands are > still transmitted to the source address of the command." > > I think that this is pretty clear that the intent was NOT to > make any exceptions > to the principle stated in D.1 (for UDP) > "Responses must be sent to the address and port from > which the corresponding > commands were sent." > > > The MGC might also send a serviceChangeAddress when it > wants to handle > > all the transaction replies/acks/pendings for transaction > request initiated > > by it. All the new Transactions shall be handled by the > newMG. This setup > > works in the current associated and MG need not establish a > new association. > > > > Please correct me if my interpretation is wrong. > > You might prefer a different policy, but I think that the > policy in H.248 is > clear - responses always go to source address of request, never to any > advertised address. > > > > > > > With Regards, > > lalit > > > > -----Original Message----- > > From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com] > > Sent: Monday, June 18, 2001 7:18 PM > > To: 'Lalit Kumar'; megaco@fore.com > > Subject: RE: difference between servicechangeaddress and > > servicechangeMgcId > > > > Hi Lalit, > > The serviceChangeMgcId is sent from the MGC when it doesn't > accept the > > registration request from the MG. And hence the > serviceChangeMgcId is set to > > another MGC. In case the MGC accepts the registration > request from the MG, > > the serviceChangeAddress is used to specify address to which further > > commands/responses need to be sent. Hope this answers your query. > > -Regards > > Madhubabu > > > > -----Original Message----- > > From: owner-megaco@pit.comms.marconi.com > > [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Lalit Kumar > > Sent: Monday, June 18, 2001 2:07 AM > > To: megaco@fore.com > > Subject: difference between servicechangeaddress and > servicechangeMgcId > > > > hi, > > I was going through RFC3015 section 7.2.8. It says that > > "The ServiceChangeAddress provides an address to be > used within the > > context of the association currently being negotiated, while the > > serviceChangeMgcId provides an alternative address where > the MG should seek > > to establish another association." > > > > Can somebody explain the role of association?? > > Since both cannot be used simultaneously when should MGC use > > serviceChangeAddress and when should it use serviceChangeMgcId?? > > > > Thanks in advance, > > > > With Regards, > > lalit > > -- > ------------------------------------------------------------ > Terry L Anderson mailto:tla@lucent.com > Tel:908.582.7013 Fax:908.582.6729 > Lucent Technologies/INS/Voice Over IP Access Networks > Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 > http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla > > From owner-megaco@fore.com Wed Jun 20 11:33:26 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11171 for ; Wed, 20 Jun 2001 11:33:25 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA22730; Wed, 20 Jun 2001 11:27:11 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id LAA20949 for megaco-list; Wed, 20 Jun 2001 11:26:07 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA20938 for ; Wed, 20 Jun 2001 11:26:05 -0400 (EDT) Received: from huginn.ctccom.net (Huginn.CTCCom.net [207.190.194.11]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA22533 for ; Wed, 20 Jun 2001 11:26:01 -0400 (EDT) Received: from MBRAHMANAPALLY ([64.69.123.121]) by huginn.ctccom.net (Mirapoint) with SMTP id ACZ41647; Wed, 20 Jun 2001 11:25:59 -0400 (EDT) From: "Madhu Babu Brahmanapally" To: "'Terry L Anderson'" , "'PSK Chakravarthi'" Cc: Subject: RE: Ephemeral Termination Date: Wed, 20 Jun 2001 11:27:31 -0400 Message-ID: <010501c0f99d$861b1f40$c500a8c0@MBRAHMANAPALLY> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <3B30BAA8.A90ED13A@lucent.com> Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: 7bit Hi All, The creation of ephemeral termination can be done either after digit analysis or before it. Each has its own advantages and disadvantages. 1) If Ephemeral termination is created before digit analysis, situation may occur where the destination user/termination is connected to the same MG and there is no need to create an ephemeral termination (as PSK mentioned). But this has the advantage that the call wont be dropped due to lack of resource, as ephemeral resources are pre-reserved at the MG. (in case Add fails later to add ephemeral termination). 2) If Ephemeral termination is created after digit analysis, it takes care of all situation where destination user may/may not connected to the same MG. But when Ephemeral termination is added later, there is no pre-reservation of the ephemeral resources at the origination MG. In case of 1) if the call doesn't mature, reserving the resources doesn't gain anything. Consideration that the destination user on the same MG is less probable, Method 2 IMO will be a better choice. Regards Madhubabu -----Original Message----- From: owner-megaco@pit.comms.marconi.com [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Terry L Anderson Sent: Wednesday, June 20, 2001 11:01 AM To: PSK Chakravarthi Cc: megaco@fore.com Subject: Re: Ephemeral Termination PSK Chakravarthi wrote: > I have got the following doubt. > If the originating and terminating termination IDs are on the same gateway and > gateway supports two TDM terminations in a context, is it required to craete a > ephenmeral termination for this call? > > Message flow between MGC and MG: > > 1. MGC send ADD command to originating MG > a) Choose a context ID > b) Add a TDM termination > c) Choose a Ephemeral termination > d) Reserve Local Descriptor > e) set MODE to Receive only. > > 2. MGC now finds that call is terminating on the same MG. Also MGC knows that > MG is capable of adding two TDMs to the same context. At this point what should > be the command to the MG? > Is it required to SUBTRACT the ephemeral termination and send ADD for adding new > TDM to the same context? or > Simply sending ADD for new TDM to the same context is sufficient? It would be better if MGC "finds" that the call is terminated on the same MG before sending the ADD, in step 1c, but if since step c (which you call "Choose a Ephemeral termination) is an Add with wildcard, MGC must certainly Subtract it if it chooses later not to use it. The Subtract deletes the ephemeral termination and releases its resources. > thanks & regards > Chak -- ------------------------------------------------------------ Terry L Anderson mailto:tla@lucent.com Tel:908.582.7013 Fax:908.582.6729 Lucent Technologies/INS/Voice Over IP Access Networks Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla From owner-megaco@fore.com Wed Jun 20 11:34:18 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11217 for ; Wed, 20 Jun 2001 11:34:17 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA22025; Wed, 20 Jun 2001 11:21:13 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id LAA19420 for megaco-list; Wed, 20 Jun 2001 11:20:09 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA19416 for ; Wed, 20 Jun 2001 11:20:08 -0400 (EDT) From: svkumar@hss.hns.com Received: from hindon.hss.co.in ([202.54.26.202]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA21881 for ; Wed, 20 Jun 2001 11:20:02 -0400 (EDT) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id f5KFLG518704 for ; Wed, 20 Jun 2001 20:51:16 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256A71.00548EBA ; Wed, 20 Jun 2001 20:53:35 +0530 X-Lotus-FromDomain: HSS To: megaco@fore.com Message-ID: <65256A71.00548D38.00@sandesh.hss.hns.com> Date: Wed, 20 Jun 2001 20:53:40 +0530 Subject: RE: Query on case insensitivity Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Hi I am a bit concerned about the first point. Maybe its a bit too late, or simply irrelevant, but still I would like to put forth this point. Allowing a message to contain a mixture of short and long tokens will needlessly complicate the parser. For tokens like the one for Error, which has a short token 'Er' and a long one 'Error' the parser would have to look ahead to the 3rd character to conclude whether it is the shorter version of Error token, or it is halfway thru the long 'Error' token or whether it is simply an syntax error. If we put a small restriction, that the messages should contain only one kind of tokens, it would atleast do away with one of the possibilities. Parsing is a CPU intensive process and such small restrictions would be a major help. It will make life simpler for the parser, and perhaps make the messages more elegant. Regards Shiv "Rosen, Brian" on 06/20/2001 05:58:32 PM To: Amit Kalra/HSS@HSS, megaco@fore.com cc: (bcc: Shiv Kumar/HSS) Subject: RE: Query on case insensitivity The answer to all of your queries is yes Brian > -----Original Message----- > From: akalra@hss.hns.com [mailto:akalra@hss.hns.com] > Sent: Wednesday, June 20, 2001 1:27 AM > To: megaco@fore.com > Subject: Query on case insensitivity > > > > > Hi all, > ABNF syntax notation is CASE INSENSITIVE, apart from the > SDP and whatever > comes within quotes should not be validated. > My queries: > 1. In case of short and long tokens can we mix both of them like > > MEGACO/1 [123.123.123.123]:55555 > P = 50005 { > Context = - { N = A5555 } > Is it allowed? > > 2. Can we have tokens like "TranACTIONresponSEAck" , I > mean mix of lower and > upper case in one token ? > > 3. Can we have short tokens in lower case or mix case like > "rc" or "rC" for > ReceiveOnly ? > > regards/ > Amit > > From owner-megaco@fore.com Wed Jun 20 11:37:41 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11374 for ; Wed, 20 Jun 2001 11:37:40 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA19674; Wed, 20 Jun 2001 10:58:00 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA12399 for megaco-list; Wed, 20 Jun 2001 10:56:41 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA12378 for ; Wed, 20 Jun 2001 10:56:38 -0400 (EDT) Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA19398 for ; Wed, 20 Jun 2001 10:56:33 -0400 (EDT) Received: from hoemail1.firewall.lucent.com (localhost [127.0.0.1]) by hoemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5KEuVx27001 for ; Wed, 20 Jun 2001 10:56:31 -0400 (EDT) Received: from teton.mh.lucent.com (h135-3-130-2.lucent.com [135.3.130.2]) by hoemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5KEuT726965; Wed, 20 Jun 2001 10:56:29 -0400 (EDT) Received: from lucent.com (pctla [135.3.130.39]) by teton.mh.lucent.com (8.8.8+Sun/8.8.8) with ESMTP id KAA23126; Wed, 20 Jun 2001 10:56:26 -0400 (EDT) Message-ID: <3B30BAA8.A90ED13A@lucent.com> Date: Wed, 20 Jun 2001 11:00:56 -0400 From: Terry L Anderson Organization: Lucent Technologies X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: PSK Chakravarthi CC: megaco@fore.com Subject: Re: Ephemeral Termination References: <65256A71.001DF77B.00@sandesh.hss.hns.com> <007801c0f957$bb3975f0$2f09ca82@Chak> Content-Type: multipart/mixed; boundary="------------3B4C4877A34FA714096A19A0" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk This is a multi-part message in MIME format. --------------3B4C4877A34FA714096A19A0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit PSK Chakravarthi wrote: > I have got the following doubt. > If the originating and terminating termination IDs are on the same gateway and > gateway supports two TDM terminations in a context, is it required to craete a > ephenmeral termination for this call? > > Message flow between MGC and MG: > > 1. MGC send ADD command to originating MG > a) Choose a context ID > b) Add a TDM termination > c) Choose a Ephemeral termination > d) Reserve Local Descriptor > e) set MODE to Receive only. > > 2. MGC now finds that call is terminating on the same MG. Also MGC knows that > MG is capable of adding two TDMs to the same context. At this point what should > be the command to the MG? > Is it required to SUBTRACT the ephemeral termination and send ADD for adding new > TDM to the same context? or > Simply sending ADD for new TDM to the same context is sufficient? It would be better if MGC "finds" that the call is terminated on the same MG before sending the ADD, in step 1c, but if since step c (which you call "Choose a Ephemeral termination) is an Add with wildcard, MGC must certainly Subtract it if it chooses later not to use it. The Subtract deletes the ephemeral termination and releases its resources. > thanks & regards > Chak -- ------------------------------------------------------------ Terry L Anderson mailto:tla@lucent.com Tel:908.582.7013 Fax:908.582.6729 Lucent Technologies/INS/Voice Over IP Access Networks Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla --------------3B4C4877A34FA714096A19A0 Content-Type: text/x-vcard; charset=us-ascii; name="tla.vcf" Content-Description: Card for Terry L Anderson Content-Disposition: attachment; filename="tla.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Anderson;Terry L tel;fax:908.582.6729 tel;work:908.582.7013 x-mozilla-html:TRUE url:http://its.lucent.com/~tla org:Lucent / InterNetworking Systems;VoIP Access Networks version:2.1 email;internet:tla@lucent.com title:DMTS note:http://www.gti.net/tla or http://teton.mh.lucent.com/~tla (Lucent internal) adr;quoted-printable:;;600 Mountain Av=0D=0ARm 2B-121;Murray Hill;NJ;07974;USA x-mozilla-cpt:;21296 fn:Terry L Anderson end:vcard --------------3B4C4877A34FA714096A19A0-- From owner-megaco@fore.com Wed Jun 20 11:41:45 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11523 for ; Wed, 20 Jun 2001 11:41:44 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA23487; Wed, 20 Jun 2001 11:32:15 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id LAA22573 for megaco-list; Wed, 20 Jun 2001 11:31:24 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA22563 for ; Wed, 20 Jun 2001 11:31:23 -0400 (EDT) Received: from huginn.ctccom.net (Huginn.CTCCom.net [207.190.194.11]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA23331 for ; Wed, 20 Jun 2001 11:31:18 -0400 (EDT) Received: from MBRAHMANAPALLY ([64.69.123.121]) by huginn.ctccom.net (Mirapoint) with SMTP id ACZ41731; Wed, 20 Jun 2001 11:31:00 -0400 (EDT) From: "Madhu Babu Brahmanapally" To: , Subject: RE: Query on case insensitivity Date: Wed, 20 Jun 2001 11:32:34 -0400 Message-ID: <010601c0f99e$3b103200$c500a8c0@MBRAHMANAPALLY> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <65256A71.00548D38.00@sandesh.hss.hns.com> Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: 7bit Hi Shiv,all, I agree with shiv's argument. First of all, I am not clear why there are two set of tokens. The long tokens doesn't convey any extra information (except for debugging purposes). In terms of efficiency obviously the short tokens will be the better choice. And having a mix of both unnecessarily complicates the parser. Regards Madhubabu -----Original Message----- From: owner-megaco@pit.comms.marconi.com [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of svkumar@hss.hns.com Sent: Wednesday, June 20, 2001 11:24 AM To: megaco@fore.com Subject: RE: Query on case insensitivity Hi I am a bit concerned about the first point. Maybe its a bit too late, or simply irrelevant, but still I would like to put forth this point. Allowing a message to contain a mixture of short and long tokens will needlessly complicate the parser. For tokens like the one for Error, which has a short token 'Er' and a long one 'Error' the parser would have to look ahead to the 3rd character to conclude whether it is the shorter version of Error token, or it is halfway thru the long 'Error' token or whether it is simply an syntax error. If we put a small restriction, that the messages should contain only one kind of tokens, it would atleast do away with one of the possibilities. Parsing is a CPU intensive process and such small restrictions would be a major help. It will make life simpler for the parser, and perhaps make the messages more elegant. Regards Shiv "Rosen, Brian" on 06/20/2001 05:58:32 PM To: Amit Kalra/HSS@HSS, megaco@fore.com cc: (bcc: Shiv Kumar/HSS) Subject: RE: Query on case insensitivity The answer to all of your queries is yes Brian > -----Original Message----- > From: akalra@hss.hns.com [mailto:akalra@hss.hns.com] > Sent: Wednesday, June 20, 2001 1:27 AM > To: megaco@fore.com > Subject: Query on case insensitivity > > > > > Hi all, > ABNF syntax notation is CASE INSENSITIVE, apart from the > SDP and whatever > comes within quotes should not be validated. > My queries: > 1. In case of short and long tokens can we mix both of them like > > MEGACO/1 [123.123.123.123]:55555 > P = 50005 { > Context = - { N = A5555 } > Is it allowed? > > 2. Can we have tokens like "TranACTIONresponSEAck" , I > mean mix of lower and > upper case in one token ? > > 3. Can we have short tokens in lower case or mix case like > "rc" or "rC" for > ReceiveOnly ? > > regards/ > Amit > > From owner-megaco@fore.com Wed Jun 20 11:45:06 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11608 for ; Wed, 20 Jun 2001 11:45:04 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA24025; Wed, 20 Jun 2001 11:35:15 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id LAA23188 for megaco-list; Wed, 20 Jun 2001 11:33:41 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA23173 for ; Wed, 20 Jun 2001 11:33:38 -0400 (EDT) Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA23715 for ; Wed, 20 Jun 2001 11:33:33 -0400 (EDT) Received: from ihemail1.firewall.lucent.com (localhost [127.0.0.1]) by ihemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5KFXYA16918 for ; Wed, 20 Jun 2001 11:33:34 -0400 (EDT) Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3]) by ihemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5KFXXw16910 for ; Wed, 20 Jun 2001 11:33:33 -0400 (EDT) Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id LAA02927; Wed, 20 Jun 2001 11:33:32 -0400 (EDT) Cc: megaco@fore.com Received: from lucent.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id LAA02918; Wed, 20 Jun 2001 11:33:30 -0400 (EDT) Message-ID: <3B30C1CE.1D892B45@lucent.com> Date: Wed, 20 Jun 2001 11:31:26 -0400 From: Troy Cauble Reply-To: Troy Cauble X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: svkumar@hss.hns.com Original-CC: megaco@fore.com Subject: Re: Query on case insensitivity References: <65256A71.00548D38.00@sandesh.hss.hns.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: 7bit svkumar@hss.hns.com wrote: > > Hi > > I am a bit concerned about the first point. > Maybe its a bit too late, or simply irrelevant, but still I would like to put > forth this point. > > Allowing a message to contain a mixture of short and long tokens will > needlessly complicate the parser. > For tokens like the one for Error, which has a short token 'Er' and a long > one 'Error' > the parser would have to look ahead to the 3rd character to conclude whether it > is the shorter version of > Error token, or it is halfway thru the long 'Error' token or whether it is > simply an syntax error. If we put a small > restriction, that the messages should contain only one kind of tokens, it would > atleast do away with one of the possibilities. > Parsing is a CPU intensive process and such small restrictions would be a > major help. > It will make life simpler for the parser, and perhaps make the messages > more elegant. > So instead it would have to look at a state variable to tell whether you should look at the next character?! That doesn't remove any possibilities. Or do you want to write two complete lexers?! NO NO NO. Your restriction would make it harder not easier. In (f)lex: Error|ER { return ErrorToken; } Simple yes? -troy From owner-megaco@fore.com Wed Jun 20 11:50:08 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11755 for ; Wed, 20 Jun 2001 11:50:05 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA25027; Wed, 20 Jun 2001 11:43:38 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id LAA25616 for megaco-list; Wed, 20 Jun 2001 11:42:35 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA25611 for ; Wed, 20 Jun 2001 11:42:34 -0400 (EDT) Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA24802 for ; Wed, 20 Jun 2001 11:42:29 -0400 (EDT) Received: from hoemail2.firewall.lucent.com (localhost [127.0.0.1]) by hoemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5KFgUp07159 for ; Wed, 20 Jun 2001 11:42:30 -0400 (EDT) Received: from ihgp.ih.lucent.com (h135-1-53-23.lucent.com [135.1.53.23]) by hoemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5KFgUT07148 for ; Wed, 20 Jun 2001 11:42:30 -0400 (EDT) Received: by ihgp.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id KAA29386; Wed, 20 Jun 2001 10:42:28 -0500 (CDT) Received: from IL0015VARNEY2.lucent.com by ihgp.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id KAA29377; Wed, 20 Jun 2001 10:42:27 -0500 (CDT) Message-Id: <4.3.2.7.2.20010620102034.04648e80@ihmail.ih.lucent.com> X-Sender: varney@ihmail.ih.lucent.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 20 Jun 2001 10:42:24 -0500 To: megaco@fore.com From: Al Varney Subject: RE: Query on case insensitivity In-Reply-To: <4FBEA8857476D311A03300204840E1CF0446559B@whq-msgusr-02.pit .comms.marconi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk At 08:28 6/20/2001 -0400, Rosen, Brian wrote: >The answer to all of your queries is yes I assume your answer applies to non-tokens as well? For example, I can specify a 'digitMapName' of "ParisFrance" and later refer to it by 'parisFRANCE'? An Event notification can refer to an event name in lower case, even though I originally asked for the Event report usng the Event name in upper case? Package names/event names are case insensitive (dt, DT, dT and Dt all refer to dial tone)? Responses can use different/mixed cases in any (non-SDP) string from that used in a Command? Or is it JUST the 'fixed' tokens of the MEGACO ABNF itself that are case insensitive? > > -----Original Message----- > > From: akalra@hss.hns.com [mailto:akalra@hss.hns.com] > > Sent: Wednesday, June 20, 2001 1:27 AM > > To: megaco@fore.com > > Subject: Query on case insensitivity > > > > Hi all, > > ABNF syntax notation is CASE INSENSITIVE, apart from the > > SDP and whatever > > comes within quotes should not be validated. > > 2. Can we have tokens like "TranACTIONresponSEAck" , I > > mean mix of lower and > > upper case in one token ? Al Varney - Lucent Technologies +1 630 224-7493 varney@lucent.com From owner-megaco@fore.com Wed Jun 20 11:55:20 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11901 for ; Wed, 20 Jun 2001 11:55:17 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA25055; Wed, 20 Jun 2001 11:43:45 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id LAA25561 for megaco-list; Wed, 20 Jun 2001 11:42:22 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA25548 for ; Wed, 20 Jun 2001 11:42:20 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 20 Jun 2001 11:42:18 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF044655AC@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Madhu Babu Brahmanapally'" , svkumar@hss.hns.com, megaco@fore.com Subject: RE: Query on case insensitivity Date: Wed, 20 Jun 2001 11:42:17 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Debugging is considered a very good reason for long tokens. Generally speaking there is NO good reason for short tokens, but we were working towards no binary (which failed of course), and we wanted to not have the length-of-message argument. There are very few MGs on links where bandwidth is so constrained, the difference between long and short tokens matters. Now, if we were using Megaco on a mobile link, where we had kilobits of bandwidth, maybe. BTW, in the end, text is proving to be shorter, and faster, than binary (I think that is with short tokens but I'm not sure). But we knew that, right :) Brian > -----Original Message----- > From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com] > Sent: Wednesday, June 20, 2001 11:33 AM > To: svkumar@hss.hns.com; megaco@fore.com > Subject: RE: Query on case insensitivity > > > Hi Shiv,all, > I agree with shiv's argument. First of all, I am not clear > why there are two > set of tokens. The long tokens doesn't convey any extra > information (except > for debugging purposes). In terms of efficiency obviously the > short tokens > will be the better choice. And having a mix of both unnecessarily > complicates the parser. > > Regards > Madhubabu > > -----Original Message----- > From: owner-megaco@pit.comms.marconi.com > [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of > svkumar@hss.hns.com > Sent: Wednesday, June 20, 2001 11:24 AM > To: megaco@fore.com > Subject: RE: Query on case insensitivity > > > > > > > Hi > > I am a bit concerned about the first point. > Maybe its a bit too late, or simply irrelevant, but still I > would like to > put > forth this point. > > Allowing a message to contain a mixture of short and long tokens will > needlessly complicate the parser. > For tokens like the one for Error, which has a short > token 'Er' and a > long > one 'Error' > the parser would have to look ahead to the 3rd character to > conclude whether > it > is the shorter version of > Error token, or it is halfway thru the long 'Error' token or > whether it is > simply an syntax error. If we put a small > restriction, that the messages should contain only one kind > of tokens, it > would > atleast do away with one of the possibilities. > Parsing is a CPU intensive process and such small > restrictions would be > a > major help. > It will make life simpler for the parser, and perhaps > make the messages > more elegant. > > Regards > Shiv > > > > > > "Rosen, Brian" on 06/20/2001 05:58:32 PM > > To: Amit Kalra/HSS@HSS, megaco@fore.com > cc: (bcc: Shiv Kumar/HSS) > > Subject: RE: Query on case insensitivity > > > > > The answer to all of your queries is yes > > Brian > > > -----Original Message----- > > From: akalra@hss.hns.com [mailto:akalra@hss.hns.com] > > Sent: Wednesday, June 20, 2001 1:27 AM > > To: megaco@fore.com > > Subject: Query on case insensitivity > > > > > > > > > > Hi all, > > ABNF syntax notation is CASE INSENSITIVE, apart from the > > SDP and whatever > > comes within quotes should not be validated. > > My queries: > > 1. In case of short and long tokens can we mix both of them like > > > > MEGACO/1 [123.123.123.123]:55555 > > P = 50005 { > > Context = - { N = A5555 } > > Is it allowed? > > > > 2. Can we have tokens like "TranACTIONresponSEAck" , I > > mean mix of lower and > > upper case in one token ? > > > > 3. Can we have short tokens in lower case or mix case like > > "rc" or "rC" for > > ReceiveOnly ? > > > > regards/ > > Amit > > > > > > > > From owner-megaco@fore.com Wed Jun 20 11:58:15 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11937 for ; Wed, 20 Jun 2001 11:58:14 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA25577; Wed, 20 Jun 2001 11:47:48 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id LAA26683 for megaco-list; Wed, 20 Jun 2001 11:46:45 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA26675 for ; Wed, 20 Jun 2001 11:46:43 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 20 Jun 2001 11:46:41 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF044655AE@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: megaco@fore.com Subject: RE: Query on case insensitivity Date: Wed, 20 Jun 2001 11:46:39 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Yep, applies to DigitMapNames. I was trying to come up with something that was a counter example. Closest I can come is the display in the IPPhone packages. I think the string for the value of the display would have cases sensitivity, althought there are no comparisons against such a property value. Brian > -----Original Message----- > From: Al Varney [mailto:varney@lucent.com] > Sent: Wednesday, June 20, 2001 11:42 AM > To: megaco@fore.com > Subject: RE: Query on case insensitivity > > > At 08:28 6/20/2001 -0400, Rosen, Brian wrote: > >The answer to all of your queries is yes > > I assume your answer applies to non-tokens as well? > > For example, I can specify a 'digitMapName' of > "ParisFrance" and later > refer to it by 'parisFRANCE'? An Event notification can > refer to an event > name in lower case, even though I originally asked for the > Event report > usng the Event name in upper case? Package names/event names > are case > insensitive (dt, DT, dT and Dt all refer to dial tone)? > Responses can use > different/mixed cases in any (non-SDP) string from that used > in a Command? > > Or is it JUST the 'fixed' tokens of the MEGACO ABNF > itself that are > case insensitive? > > > > -----Original Message----- > > > From: akalra@hss.hns.com [mailto:akalra@hss.hns.com] > > > Sent: Wednesday, June 20, 2001 1:27 AM > > > To: megaco@fore.com > > > Subject: Query on case insensitivity > > > > > > Hi all, > > > ABNF syntax notation is CASE INSENSITIVE, apart from the > > > SDP and whatever > > > comes within quotes should not be validated. > > > > 2. Can we have tokens like "TranACTIONresponSEAck" , I > > > mean mix of lower and > > > upper case in one token ? > > > > > Al Varney - Lucent Technologies +1 630 224-7493 varney@lucent.com > From owner-megaco@fore.com Wed Jun 20 12:00:06 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11993 for ; Wed, 20 Jun 2001 12:00:05 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA23687; Wed, 20 Jun 2001 11:33:18 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id LAA22755 for megaco-list; Wed, 20 Jun 2001 11:32:11 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA22743 for ; Wed, 20 Jun 2001 11:32:10 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 20 Jun 2001 11:32:08 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF044655AA@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'svkumar@hss.hns.com'" , megaco@fore.com Subject: RE: Query on case insensitivity Date: Wed, 20 Jun 2001 11:32:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk I really think this is not a real concern, and would make a number of tokens lose any semblance of readability. Usually, you parse identifiers (including keywords) by looking for the separation punctuation, and then comparing against a dictionary (and you would, of course, convert the identifier to a single case before you did that). While there are parsers that do literal state machine transitions on every character, even they wouldn't be substantially improved by such a restriction on token choices. The short tokens are for link efficiency and not for parser efficiency. I don't think parser efficiency would be measurably affected either way. YMMV Brian > -----Original Message----- > From: svkumar@hss.hns.com [mailto:svkumar@hss.hns.com] > Sent: Wednesday, June 20, 2001 11:24 AM > To: megaco@fore.com > Subject: RE: Query on case insensitivity > > > > > > > Hi > > I am a bit concerned about the first point. > Maybe its a bit too late, or simply irrelevant, but still I > would like to put > forth this point. > > Allowing a message to contain a mixture of short and long tokens will > needlessly complicate the parser. > For tokens like the one for Error, which has a short > token 'Er' and a long > one 'Error' > the parser would have to look ahead to the 3rd character to > conclude whether it > is the shorter version of > Error token, or it is halfway thru the long 'Error' token or > whether it is > simply an syntax error. If we put a small > restriction, that the messages should contain only one kind > of tokens, it would > atleast do away with one of the possibilities. > Parsing is a CPU intensive process and such small > restrictions would be a > major help. > It will make life simpler for the parser, and perhaps > make the messages > more elegant. > > Regards > Shiv > > > > > > "Rosen, Brian" on 06/20/2001 05:58:32 PM > > To: Amit Kalra/HSS@HSS, megaco@fore.com > cc: (bcc: Shiv Kumar/HSS) > > Subject: RE: Query on case insensitivity > > > > > The answer to all of your queries is yes > > Brian > > > -----Original Message----- > > From: akalra@hss.hns.com [mailto:akalra@hss.hns.com] > > Sent: Wednesday, June 20, 2001 1:27 AM > > To: megaco@fore.com > > Subject: Query on case insensitivity > > > > > > > > > > Hi all, > > ABNF syntax notation is CASE INSENSITIVE, apart from the > > SDP and whatever > > comes within quotes should not be validated. > > My queries: > > 1. In case of short and long tokens can we mix both of them like > > > > MEGACO/1 [123.123.123.123]:55555 > > P = 50005 { > > Context = - { N = A5555 } > > Is it allowed? > > > > 2. Can we have tokens like "TranACTIONresponSEAck" , I > > mean mix of lower and > > upper case in one token ? > > > > 3. Can we have short tokens in lower case or mix case like > > "rc" or "rC" for > > ReceiveOnly ? > > > > regards/ > > Amit > > > > > > > > From owner-megaco@fore.com Wed Jun 20 12:03:49 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12110 for ; Wed, 20 Jun 2001 12:03:49 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA24448; Wed, 20 Jun 2001 11:38:16 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id LAA24134 for megaco-list; Wed, 20 Jun 2001 11:37:14 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA24125 for ; Wed, 20 Jun 2001 11:37:13 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 20 Jun 2001 11:37:11 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF044655AB@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Madhu Babu Brahmanapally'" , "'Terry L Anderson'" , "'PSK Chakravarthi'" Cc: megaco@fore.com Subject: RE: Ephemeral Termination Date: Wed, 20 Jun 2001 11:37:09 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk I'm not at all sure what "resources" you can reserve before you know the destination: For an IP network, you can reserve a UDP port I suppose, but until you negotiate the SDP, you can't reserve bandwidth. You can't make any QoS reservation for the same reason. It's worse on an ATM network. I think there is nothing to be gained by #1 Brian > -----Original Message----- > From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com] > Sent: Wednesday, June 20, 2001 11:28 AM > To: 'Terry L Anderson'; 'PSK Chakravarthi' > Cc: megaco@fore.com > Subject: RE: Ephemeral Termination > > > Hi All, > The creation of ephemeral termination can be done either after digit > analysis or before it. Each has its own advantages and disadvantages. > > 1) If Ephemeral termination is created before digit analysis, > situation may > occur where the destination user/termination is connected to > the same MG and > there is no need to create an ephemeral termination (as PSK > mentioned). But > this has the advantage that the call wont be dropped due to lack of > resource, as ephemeral resources are pre-reserved at the MG. > (in case Add > fails later to add ephemeral termination). > > 2) If Ephemeral termination is created after digit analysis, > it takes care > of all situation where destination user may/may not connected > to the same > MG. But when Ephemeral termination is added later, there is no > pre-reservation of the ephemeral resources at the origination MG. > > In case of 1) if the call doesn't mature, reserving the > resources doesn't > gain anything. Consideration that the destination user on the > same MG is > less probable, Method 2 IMO will be a better choice. > > Regards > Madhubabu > > -----Original Message----- > From: owner-megaco@pit.comms.marconi.com > [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Terry > L Anderson > Sent: Wednesday, June 20, 2001 11:01 AM > To: PSK Chakravarthi > Cc: megaco@fore.com > Subject: Re: Ephemeral Termination > > > > > PSK Chakravarthi wrote: > > > I have got the following doubt. > > If the originating and terminating termination IDs are on > the same gateway > and > > gateway supports two TDM terminations in a context, is it > required to > craete a > > ephenmeral termination for this call? > > > > Message flow between MGC and MG: > > > > 1. MGC send ADD command to originating MG > > a) Choose a context ID > > b) Add a TDM termination > > c) Choose a Ephemeral termination > > d) Reserve Local Descriptor > > e) set MODE to Receive only. > > > > 2. MGC now finds that call is terminating on the same MG. > Also MGC knows > that > > MG is capable of adding two TDMs to the same context. At > this point what > should > > be the command to the MG? > > Is it required to SUBTRACT the ephemeral termination and > send ADD for > adding new > > TDM to the same context? or > > Simply sending ADD for new TDM to the same context is sufficient? > > It would be better if MGC "finds" that the call is terminated > on the same MG > before > sending the ADD, in step 1c, but if since step c (which you > call "Choose a > Ephemeral > termination) is an Add with wildcard, MGC must certainly > Subtract it if it > chooses > later not to use it. The Subtract deletes the ephemeral > termination and > releases > its resources. > > > thanks & regards > > Chak > > -- > ------------------------------------------------------------ > Terry L Anderson mailto:tla@lucent.com > Tel:908.582.7013 Fax:908.582.6729 > Lucent Technologies/INS/Voice Over IP Access Networks > Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 > http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla > > From owner-megaco@fore.com Wed Jun 20 12:36:05 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13138 for ; Wed, 20 Jun 2001 12:36:03 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA28542; Wed, 20 Jun 2001 12:21:28 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id MAA04620 for megaco-list; Wed, 20 Jun 2001 12:20:51 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA04616 for ; Wed, 20 Jun 2001 12:20:50 -0400 (EDT) Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA28425 for ; Wed, 20 Jun 2001 12:20:41 -0400 (EDT) Received: from hoemail2.firewall.lucent.com (localhost [127.0.0.1]) by hoemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5KGKgS21080 for ; Wed, 20 Jun 2001 12:20:42 -0400 (EDT) Received: from ihgp.ih.lucent.com (h135-1-53-23.lucent.com [135.1.53.23]) by hoemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5KGKg321072 for ; Wed, 20 Jun 2001 12:20:42 -0400 (EDT) Received: by ihgp.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id LAA09810; Wed, 20 Jun 2001 11:20:41 -0500 (CDT) To: megaco@fore.com Cc: svkumar@hss.hns.com Received: from IL0015VARNEY2.lucent.com by ihgp.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id LAA09805; Wed, 20 Jun 2001 11:20:40 -0500 (CDT) Message-Id: <4.3.2.7.2.20010620111838.0463d7c0@ihmail.ih.lucent.com> X-Sender: varney@ihmail.ih.lucent.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 20 Jun 2001 11:20:38 -0500 Original-To: From: Al Varney Subject: RE: Query on case insensitivity Original-Cc: In-Reply-To: <010601c0f99e$3b103200$c500a8c0@MBRAHMANAPALLY> References: <65256A71.00548D38.00@sandesh.hss.hns.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk At 11:32 6/20/2001 -0400, Madhu Babu Brahmanapally wrote: >I agree with shiv's argument. First of all, I am not clear why there are two >set of tokens. The long tokens doesn't convey any extra information (except >for debugging purposes). In terms of efficiency obviously the short tokens >will be the better choice. And having a mix of both unnecessarily >complicates the parser. If parsing efficiency is a concern, then removing the case insensitivity would be a much bigger gain than reducing the size of the dictionary (having only ER or ERROR, for example). Al Varney - Lucent Technologies +1 630 224-7493 varney@lucent.com From owner-megaco@fore.com Wed Jun 20 12:42:59 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13422 for ; Wed, 20 Jun 2001 12:42:58 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA28155; Wed, 20 Jun 2001 12:18:06 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id MAA03788 for megaco-list; Wed, 20 Jun 2001 12:17:01 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA03774 for ; Wed, 20 Jun 2001 12:16:59 -0400 (EDT) Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA27986 for ; Wed, 20 Jun 2001 12:16:55 -0400 (EDT) Received: from hoemail2.firewall.lucent.com (localhost [127.0.0.1]) by hoemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5KGGuS17458 for ; Wed, 20 Jun 2001 12:16:56 -0400 (EDT) Received: from ihgp.ih.lucent.com (h135-1-53-23.lucent.com [135.1.53.23]) by hoemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5KGGt317451 for ; Wed, 20 Jun 2001 12:16:55 -0400 (EDT) Received: by ihgp.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id LAA08752; Wed, 20 Jun 2001 11:16:55 -0500 (CDT) Received: from IL0015VARNEY2.lucent.com by ihgp.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id LAA08730; Wed, 20 Jun 2001 11:16:53 -0500 (CDT) Message-Id: <4.3.2.7.2.20010620110426.046ceb40@ihmail.ih.lucent.com> X-Sender: varney@ihmail.ih.lucent.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 20 Jun 2001 11:16:50 -0500 To: megaco@fore.com From: Al Varney Subject: RE: Ephemeral Termination In-Reply-To: <4FBEA8857476D311A03300204840E1CF044655AB@whq-msgusr-02.pit .comms.marconi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Brian, At 11:37 6/20/2001 -0400, Rosen, Brian wrote: >I'm not at all sure what "resources" you can reserve before you >know the destination: > >For an IP network, you can reserve a UDP port I suppose, but until >you negotiate the SDP, you can't reserve bandwidth. You can't >make any QoS reservation for the same reason. > >It's worse on an ATM network. > >I think there is nothing to be gained by #1 On the other hand, if NO resources are used, why bother removing the Ephemeral from the Context? The original question was "Is it REQUIRED to remove the Ephemeral prior to ADDing the second TDM termination?" I think the answer is "no" (in disagreement with my colleague Terry). If you are willing to waste the time/overhead of pre-allocating an Ephemeral, there doesn't seem to be much harm in letting it "hang around" for the duration of a call. You may not get all the possible capacity out of the MG if you use it that way, but MEGACO certainly doesn't REQUIRE you to Subtract it -- before or after ADDing the second TDM. Who knows, maybe you're keeping it around to support possible wire-tap applications? Al Varney >Brian > > > -----Original Message----- > > From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com] > > Sent: Wednesday, June 20, 2001 11:28 AM > > To: 'Terry L Anderson'; 'PSK Chakravarthi' > > Cc: megaco@fore.com > > Subject: RE: Ephemeral Termination > > > > > > Hi All, > > The creation of ephemeral termination can be done either after digit > > analysis or before it. Each has its own advantages and disadvantages. > > > > 1) If Ephemeral termination is created before digit analysis, > > situation may > > occur where the destination user/termination is connected to > > the same MG and > > there is no need to create an ephemeral termination (as PSK > > mentioned). But > > this has the advantage that the call wont be dropped due to lack of > > resource, as ephemeral resources are pre-reserved at the MG. > > (in case Add > > fails later to add ephemeral termination). > > > > 2) If Ephemeral termination is created after digit analysis, > > it takes care > > of all situation where destination user may/may not connected > > to the same > > MG. But when Ephemeral termination is added later, there is no > > pre-reservation of the ephemeral resources at the origination MG. > > > > In case of 1) if the call doesn't mature, reserving the > > resources doesn't > > gain anything. Consideration that the destination user on the > > same MG is > > less probable, Method 2 IMO will be a better choice. > > > > Regards > > Madhubabu > > > > -----Original Message----- > > From: owner-megaco@pit.comms.marconi.com > > [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Terry > > L Anderson > > Sent: Wednesday, June 20, 2001 11:01 AM > > To: PSK Chakravarthi > > Cc: megaco@fore.com > > Subject: Re: Ephemeral Termination > > > > > > > > > > PSK Chakravarthi wrote: > > > > > I have got the following doubt. > > > If the originating and terminating termination IDs are on > > the same gateway > > and > > > gateway supports two TDM terminations in a context, is it > > required to > > craete a > > > ephenmeral termination for this call? > > > > > > Message flow between MGC and MG: > > > > > > 1. MGC send ADD command to originating MG > > > a) Choose a context ID > > > b) Add a TDM termination > > > c) Choose a Ephemeral termination > > > d) Reserve Local Descriptor > > > e) set MODE to Receive only. > > > > > > 2. MGC now finds that call is terminating on the same MG. > > Also MGC knows > > that > > > MG is capable of adding two TDMs to the same context. At > > this point what > > should > > > be the command to the MG? > > > Is it required to SUBTRACT the ephemeral termination and > > send ADD for > > adding new > > > TDM to the same context? or > > > Simply sending ADD for new TDM to the same context is sufficient? > > > > It would be better if MGC "finds" that the call is terminated > > on the same MG > > before > > sending the ADD, in step 1c, but if since step c (which you > > call "Choose a > > Ephemeral > > termination) is an Add with wildcard, MGC must certainly > > Subtract it if it > > chooses > > later not to use it. The Subtract deletes the ephemeral > > termination and > > releases > > its resources. > > > > > thanks & regards > > > Chak > > > > -- > > ------------------------------------------------------------ > > Terry L Anderson mailto:tla@lucent.com > > Tel:908.582.7013 Fax:908.582.6729 > > Lucent Technologies/INS/Voice Over IP Access Networks > > Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 > > http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla > > > > From owner-megaco@fore.com Wed Jun 20 13:44:33 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15666 for ; Wed, 20 Jun 2001 13:44:32 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA03778; Wed, 20 Jun 2001 13:29:48 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id NAA21113 for megaco-list; Wed, 20 Jun 2001 13:28:26 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA21109 for ; Wed, 20 Jun 2001 13:28:25 -0400 (EDT) From: svkumar@hss.hns.com Received: from hindon.hss.co.in ([202.54.26.202]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA03619 for ; Wed, 20 Jun 2001 13:28:19 -0400 (EDT) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id f5KHTc919648 for ; Wed, 20 Jun 2001 22:59:39 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256A71.00604D00 ; Wed, 20 Jun 2001 23:01:51 +0530 X-Lotus-FromDomain: HSS To: megaco@fore.com Message-ID: <65256A71.00604AEE.00@sandesh.hss.hns.com> Date: Wed, 20 Jun 2001 23:01:55 +0530 Subject: RE: Query on case insensitivity Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Hi All I have no qualms about whether we use short tokens or long ones. Its just that the message should be consistent about the kind of token used. The first token MEGACO/! should indicate what the following tokens are going to be like. The parser engine with a bit of extra effort can be tuned for maximum efficiency [ and no Troy, the state variable can be used in a better manner than what you suggested :-) ] Adding more restrictions like say, only Short Tokens in upper case, would probably make the parsing very fast. Almost as good as its binary equivalent. But then again, for debugging purposes, Long Text Tokens are very convenient. Regards Shiv From owner-megaco@fore.com Wed Jun 20 14:24:06 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA17079 for ; Wed, 20 Jun 2001 14:24:05 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA05267; Wed, 20 Jun 2001 13:47:01 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id NAA25506 for megaco-list; Wed, 20 Jun 2001 13:45:35 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA25495 for ; Wed, 20 Jun 2001 13:45:33 -0400 (EDT) Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA05028 for ; Wed, 20 Jun 2001 13:45:28 -0400 (EDT) Received: from hoemail1.firewall.lucent.com (localhost [127.0.0.1]) by hoemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5KHjOP02529 for ; Wed, 20 Jun 2001 13:45:24 -0400 (EDT) Received: from teton.mh.lucent.com (h135-3-130-2.lucent.com [135.3.130.2]) by hoemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5KHjOp02521 for ; Wed, 20 Jun 2001 13:45:24 -0400 (EDT) Received: from lucent.com (pctla [135.3.130.39]) by teton.mh.lucent.com (8.8.8+Sun/8.8.8) with ESMTP id NAA08127; Wed, 20 Jun 2001 13:45:24 -0400 (EDT) Message-ID: <3B30E240.53185E19@lucent.com> Date: Wed, 20 Jun 2001 13:49:53 -0400 From: Terry L Anderson Organization: Lucent Technologies X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Al Varney CC: megaco@fore.com Subject: Re: Ephemeral Termination References: <4.3.2.7.2.20010620110426.046ceb40@ihmail.ih.lucent.com> Content-Type: multipart/mixed; boundary="------------834913CC8AB5B0E3DEB3B1BE" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk This is a multi-part message in MIME format. --------------834913CC8AB5B0E3DEB3B1BE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Al - You are, of course, correct that you are not required to Subtract it at the beginning of the call. My point was that you must subtract it sometime - Adding another TDM termination does not magically remove it. You can of course wait until the end of the call and subtract it at the same time as the two TDM terminations, if that is desirable for some reason, but it would seem simpler (but not required) to Subtract it in the same transaction as the second TDM Add. Al Varney wrote: > Brian, > > At 11:37 6/20/2001 -0400, Rosen, Brian wrote: > >I'm not at all sure what "resources" you can reserve before you > >know the destination: > > > >For an IP network, you can reserve a UDP port I suppose, but until > >you negotiate the SDP, you can't reserve bandwidth. You can't > >make any QoS reservation for the same reason. > > > >It's worse on an ATM network. > > > >I think there is nothing to be gained by #1 > > On the other hand, if NO resources are used, why bother removing the > Ephemeral from the Context? > > The original question was "Is it REQUIRED to remove the Ephemeral prior > to ADDing the second TDM termination?" > > I think the answer is "no" (in disagreement with my colleague > Terry). If you are willing to waste the time/overhead of pre-allocating an > Ephemeral, there doesn't seem to be much harm in letting it "hang around" > for the duration of a call. You may not get all the possible capacity out > of the MG if you use it that way, but MEGACO certainly doesn't REQUIRE you > to Subtract it -- before or after ADDing the second TDM. > > Who knows, maybe you're keeping it around to support possible wire-tap > applications? > > Al Varney > > >Brian > > > > > -----Original Message----- > > > From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com] > > > Sent: Wednesday, June 20, 2001 11:28 AM > > > To: 'Terry L Anderson'; 'PSK Chakravarthi' > > > Cc: megaco@fore.com > > > Subject: RE: Ephemeral Termination > > > > > > > > > Hi All, > > > The creation of ephemeral termination can be done either after digit > > > analysis or before it. Each has its own advantages and disadvantages. > > > > > > 1) If Ephemeral termination is created before digit analysis, > > > situation may > > > occur where the destination user/termination is connected to > > > the same MG and > > > there is no need to create an ephemeral termination (as PSK > > > mentioned). But > > > this has the advantage that the call wont be dropped due to lack of > > > resource, as ephemeral resources are pre-reserved at the MG. > > > (in case Add > > > fails later to add ephemeral termination). > > > > > > 2) If Ephemeral termination is created after digit analysis, > > > it takes care > > > of all situation where destination user may/may not connected > > > to the same > > > MG. But when Ephemeral termination is added later, there is no > > > pre-reservation of the ephemeral resources at the origination MG. > > > > > > In case of 1) if the call doesn't mature, reserving the > > > resources doesn't > > > gain anything. Consideration that the destination user on the > > > same MG is > > > less probable, Method 2 IMO will be a better choice. > > > > > > Regards > > > Madhubabu > > > > > > -----Original Message----- > > > From: owner-megaco@pit.comms.marconi.com > > > [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Terry > > > L Anderson > > > Sent: Wednesday, June 20, 2001 11:01 AM > > > To: PSK Chakravarthi > > > Cc: megaco@fore.com > > > Subject: Re: Ephemeral Termination > > > > > > > > > > > > > > > PSK Chakravarthi wrote: > > > > > > > I have got the following doubt. > > > > If the originating and terminating termination IDs are on > > > the same gateway > > > and > > > > gateway supports two TDM terminations in a context, is it > > > required to > > > craete a > > > > ephenmeral termination for this call? > > > > > > > > Message flow between MGC and MG: > > > > > > > > 1. MGC send ADD command to originating MG > > > > a) Choose a context ID > > > > b) Add a TDM termination > > > > c) Choose a Ephemeral termination > > > > d) Reserve Local Descriptor > > > > e) set MODE to Receive only. > > > > > > > > 2. MGC now finds that call is terminating on the same MG. > > > Also MGC knows > > > that > > > > MG is capable of adding two TDMs to the same context. At > > > this point what > > > should > > > > be the command to the MG? > > > > Is it required to SUBTRACT the ephemeral termination and > > > send ADD for > > > adding new > > > > TDM to the same context? or > > > > Simply sending ADD for new TDM to the same context is sufficient? > > > > > > It would be better if MGC "finds" that the call is terminated > > > on the same MG > > > before > > > sending the ADD, in step 1c, but if since step c (which you > > > call "Choose a > > > Ephemeral > > > termination) is an Add with wildcard, MGC must certainly > > > Subtract it if it > > > chooses > > > later not to use it. The Subtract deletes the ephemeral > > > termination and > > > releases > > > its resources. > > > > > > > thanks & regards > > > > Chak > > > > > > -- > > > ------------------------------------------------------------ > > > Terry L Anderson mailto:tla@lucent.com > > > Tel:908.582.7013 Fax:908.582.6729 > > > Lucent Technologies/INS/Voice Over IP Access Networks > > > Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 > > > http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla > > > > > > -- ------------------------------------------------------------ Terry L Anderson mailto:tla@lucent.com Tel:908.582.7013 Fax:908.582.6729 Lucent Technologies/INS/Voice Over IP Access Networks Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla --------------834913CC8AB5B0E3DEB3B1BE Content-Type: text/x-vcard; charset=us-ascii; name="tla.vcf" Content-Description: Card for Terry L Anderson Content-Disposition: attachment; filename="tla.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Anderson;Terry L tel;fax:908.582.6729 tel;work:908.582.7013 x-mozilla-html:TRUE url:http://its.lucent.com/~tla org:Lucent / InterNetworking Systems;VoIP Access Networks version:2.1 email;internet:tla@lucent.com title:DMTS note:http://www.gti.net/tla or http://teton.mh.lucent.com/~tla (Lucent internal) adr;quoted-printable:;;600 Mountain Av=0D=0ARm 2B-121;Murray Hill;NJ;07974;USA x-mozilla-cpt:;21296 fn:Terry L Anderson end:vcard --------------834913CC8AB5B0E3DEB3B1BE-- From owner-megaco@fore.com Wed Jun 20 14:39:19 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA17591 for ; Wed, 20 Jun 2001 14:39:18 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA08607; Wed, 20 Jun 2001 14:24:30 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id OAA06038 for megaco-list; Wed, 20 Jun 2001 14:23:38 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA06011 for ; Wed, 20 Jun 2001 14:23:33 -0400 (EDT) Received: from telesoft.indts.com ([164.164.71.52]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA08455 for ; Wed, 20 Jun 2001 14:23:24 -0400 (EDT) Received: from indts_fs.indts.com (indts_fs [201.64.64.29]) by telesoft.indts.com (8.8.7/8.8.7) with ESMTP id AAA00267 for ; Thu, 21 Jun 2001 00:15:17 +0530 Received: by INDTS_FS with Internet Mail Service (5.5.2650.21) id ; Thu, 21 Jun 2001 00:01:32 +0530 Message-ID: From: Nitin Kumar To: "'megaco@fore.com'" Subject: Few clarification in RFC3015 Date: Thu, 21 Jun 2001 00:01:31 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Hi Folks, Just looking for following clarification. 1. In a TransactionRequest, are ActionRequests processed in order or only Commands in an ActionRequest are executed sequencially ? RFC says "Commands within a Transaction are executed sequentially." 2. Few lines from the RFC on page number 135, section D.1.4.. "Upon receipt of a final response following receipt of provisional responses, an immediate confirmation shall be sent, and normal repetition timers shall be used thereafter." Now what does "normal repetition timers shall be used thereafter" mean in above extract? i hope to receive some insights. regards, -nitin Ind Telesoft Pvt. Ltd. 104, Koramangla Industrial Estate, 5th Block, Bangalore 560 095 Tel : 5508930, 5521937, 5529758-62 ext-259 Fax : 5521164 mailto:nitin@indts.com http:\\www.telesoftinc.com From owner-megaco@fore.com Wed Jun 20 15:09:26 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA18780 for ; Wed, 20 Jun 2001 15:09:25 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA09757; Wed, 20 Jun 2001 14:36:11 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id OAA09881 for megaco-list; Wed, 20 Jun 2001 14:34:49 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA09873 for ; Wed, 20 Jun 2001 14:34:47 -0400 (EDT) Received: from web5305.mail.yahoo.com (web5305.mail.yahoo.com [216.115.106.114]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with SMTP id OAA09574 for ; Wed, 20 Jun 2001 14:34:42 -0400 (EDT) Message-ID: <20010620183442.29890.qmail@web5305.mail.yahoo.com> Received: from [208.185.176.26] by web5305.mail.yahoo.com; Wed, 20 Jun 2001 11:34:42 PDT Date: Wed, 20 Jun 2001 11:34:42 -0700 (PDT) From: Thalanayar Muthukumar Subject: ALGs for Megaco To: megaco@fore.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Hi, Are there PC based applications using Megaco? If so, please send information. Also, I understand that Megaco requires an ALG when working with NAT. Is there any ALG for Megaco available in Linux? - Kuamr __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ From owner-megaco@fore.com Wed Jun 20 15:20:56 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA19153 for ; Wed, 20 Jun 2001 15:20:55 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA10404; Wed, 20 Jun 2001 14:43:32 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id OAA11658 for megaco-list; Wed, 20 Jun 2001 14:41:11 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA11643 for ; Wed, 20 Jun 2001 14:41:09 -0400 (EDT) Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA10185 for ; Wed, 20 Jun 2001 14:40:59 -0400 (EDT) Received: from hoemail2.firewall.lucent.com (localhost [127.0.0.1]) by hoemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5KIf0S20648 for ; Wed, 20 Jun 2001 14:41:00 -0400 (EDT) Received: from teton.mh.lucent.com (h135-3-130-2.lucent.com [135.3.130.2]) by hoemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5KIf0320644; Wed, 20 Jun 2001 14:41:00 -0400 (EDT) Received: from lucent.com ([135.3.128.238]) by teton.mh.lucent.com (8.8.8+Sun/8.8.8) with ESMTP id OAA11319; Wed, 20 Jun 2001 14:41:00 -0400 (EDT) Message-ID: <3B30EDE4.2F4D55A9@lucent.com> Date: Wed, 20 Jun 2001 14:39:33 -0400 From: Terry L Anderson Organization: Lucent Technologies X-Mailer: Mozilla 4.75 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: "Rosen, Brian" CC: megaco@fore.com Subject: Re: Query on case insensitivity References: <4FBEA8857476D311A03300204840E1CF044655AC@whq-msgusr-02.pit.comms.marconi.com> Content-Type: multipart/mixed; boundary="------------9EF906F59397226286047777" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk This is a multi-part message in MIME format. --------------9EF906F59397226286047777 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Isn't there an issue with UDP since, as I understand it, the full message must be less than MTU (often 1400 bytes or so). Seems that with long form text this may more often be exceeded. A lot of my Adds or Modifies with SDP come close. "Rosen, Brian" wrote: > Debugging is considered a very good reason for long tokens. > Generally speaking there is NO good reason for short tokens, > but we were working towards no binary (which failed of course), > and we wanted to not have the length-of-message argument. > There are very few MGs on links where bandwidth is so constrained, > the difference between long and short tokens matters. > Now, if we were using Megaco on a mobile link, where we had kilobits > of bandwidth, maybe. > > BTW, in the end, text is proving to be shorter, and faster, than > binary (I think that is with short tokens but I'm not sure). > But we knew that, right :) > > Brian > > > -----Original Message----- > > From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com] > > Sent: Wednesday, June 20, 2001 11:33 AM > > To: svkumar@hss.hns.com; megaco@fore.com > > Subject: RE: Query on case insensitivity > > > > > > Hi Shiv,all, > > I agree with shiv's argument. First of all, I am not clear > > why there are two > > set of tokens. The long tokens doesn't convey any extra > > information (except > > for debugging purposes). In terms of efficiency obviously the > > short tokens > > will be the better choice. And having a mix of both unnecessarily > > complicates the parser. > > > > Regards > > Madhubabu > > > > -----Original Message----- > > From: owner-megaco@pit.comms.marconi.com > > [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of > > svkumar@hss.hns.com > > Sent: Wednesday, June 20, 2001 11:24 AM > > To: megaco@fore.com > > Subject: RE: Query on case insensitivity > > > > > > > > > > > > > > Hi > > > > I am a bit concerned about the first point. > > Maybe its a bit too late, or simply irrelevant, but still I > > would like to > > put > > forth this point. > > > > Allowing a message to contain a mixture of short and long tokens will > > needlessly complicate the parser. > > For tokens like the one for Error, which has a short > > token 'Er' and a > > long > > one 'Error' > > the parser would have to look ahead to the 3rd character to > > conclude whether > > it > > is the shorter version of > > Error token, or it is halfway thru the long 'Error' token or > > whether it is > > simply an syntax error. If we put a small > > restriction, that the messages should contain only one kind > > of tokens, it > > would > > atleast do away with one of the possibilities. > > Parsing is a CPU intensive process and such small > > restrictions would be > > a > > major help. > > It will make life simpler for the parser, and perhaps > > make the messages > > more elegant. > > > > Regards > > Shiv > > > > > > > > > > > > "Rosen, Brian" on 06/20/2001 05:58:32 PM > > > > To: Amit Kalra/HSS@HSS, megaco@fore.com > > cc: (bcc: Shiv Kumar/HSS) > > > > Subject: RE: Query on case insensitivity > > > > > > > > > > The answer to all of your queries is yes > > > > Brian > > > > > -----Original Message----- > > > From: akalra@hss.hns.com [mailto:akalra@hss.hns.com] > > > Sent: Wednesday, June 20, 2001 1:27 AM > > > To: megaco@fore.com > > > Subject: Query on case insensitivity > > > > > > > > > > > > > > > Hi all, > > > ABNF syntax notation is CASE INSENSITIVE, apart from the > > > SDP and whatever > > > comes within quotes should not be validated. > > > My queries: > > > 1. In case of short and long tokens can we mix both of them like > > > > > > MEGACO/1 [123.123.123.123]:55555 > > > P = 50005 { > > > Context = - { N = A5555 } > > > Is it allowed? > > > > > > 2. Can we have tokens like "TranACTIONresponSEAck" , I > > > mean mix of lower and > > > upper case in one token ? > > > > > > 3. Can we have short tokens in lower case or mix case like > > > "rc" or "rC" for > > > ReceiveOnly ? > > > > > > regards/ > > > Amit > > > > > > > > > > > > > > -- ------------------------------------------------------------ Terry L Anderson mailto:tla@lucent.com Tel:908.582.7013 Fax:908.582.6729 Lucent Technologies/INS/Voice Over IP Access Networks Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla --------------9EF906F59397226286047777 Content-Type: text/x-vcard; charset=us-ascii; name="tla.vcf" Content-Description: Card for Terry L Anderson Content-Disposition: attachment; filename="tla.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Anderson;Terry L tel;fax:908.582.6729 tel;work:908.582.7013 x-mozilla-html:TRUE url:http://its.lucent.com/~tla org:Lucent / InterNetworking Systems;VoIP Access Networks version:2.1 email;internet:tla@lucent.com title:DMTS note:http://www.gti.net/tla or http://teton.mh.lucent.com/~tla (Lucent internal) adr;quoted-printable:;;Rm 2B-121=0D=0A600 Mountain Ave;Murray Hill;NJ;07974;USA x-mozilla-cpt:;7264 fn:Terry L Anderson end:vcard --------------9EF906F59397226286047777-- From owner-megaco@fore.com Wed Jun 20 15:51:18 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA20219 for ; Wed, 20 Jun 2001 15:51:18 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA14070; Wed, 20 Jun 2001 15:28:22 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id PAA24170 for megaco-list; Wed, 20 Jun 2001 15:27:32 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA24142 for ; Wed, 20 Jun 2001 15:27:29 -0400 (EDT) Received: from huginn.ctccom.net (Huginn.CTCCom.net [207.190.194.11]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA13888 for ; Wed, 20 Jun 2001 15:27:23 -0400 (EDT) Received: from MBRAHMANAPALLY ([64.69.123.121]) by huginn.ctccom.net (Mirapoint) with SMTP id ACZ45204; Wed, 20 Jun 2001 15:26:39 -0400 (EDT) From: "Madhu Babu Brahmanapally" To: "'Thalanayar Muthukumar'" , Subject: RE: ALGs for Megaco Date: Wed, 20 Jun 2001 15:28:12 -0400 Message-ID: <012301c0f9bf$25c9dd30$c500a8c0@MBRAHMANAPALLY> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <20010620183442.29890.qmail@web5305.mail.yahoo.com> Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: 7bit HI Kumar/All, There is no ALG for Megaco. Earlier there was some discussion on NAT for MEGACO. The conclusion then was that the outcome of midcom is something that can be used for Megaco also. (Even I'm not sure what this means ;-p) Regards Madhubabu -----Original Message----- From: owner-megaco@pit.comms.marconi.com [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Thalanayar Muthukumar Sent: Wednesday, June 20, 2001 2:35 PM To: megaco@fore.com Subject: ALGs for Megaco Hi, Are there PC based applications using Megaco? If so, please send information. Also, I understand that Megaco requires an ALG when working with NAT. Is there any ALG for Megaco available in Linux? - Kuamr __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ From owner-megaco@fore.com Wed Jun 20 17:06:44 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA22794 for ; Wed, 20 Jun 2001 17:06:42 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA19786; Wed, 20 Jun 2001 16:55:26 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id QAA15189 for megaco-list; Wed, 20 Jun 2001 16:54:12 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA15184 for ; Wed, 20 Jun 2001 16:54:10 -0400 (EDT) Received: from nwcst336.netaddress.usa.net (nwcst336.netaddress.usa.net [204.68.23.81]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with SMTP id QAA19635 for ; Wed, 20 Jun 2001 16:54:05 -0400 (EDT) Received: (qmail 11630 invoked by uid 60001); 20 Jun 2001 20:54:07 -0000 Message-ID: <20010620205407.11629.qmail@nwcst336.netaddress.usa.net> Received: from 204.68.23.81 by nwcst336 for [63.111.211.20] via web-mailer(34FM.0700.17C.01) on Wed Jun 20 20:54:07 GMT 2001 Date: 20 Jun 2001 14:54:07 MDT From: suryapratap vamsi To: megaco@fore.com Subject: UDP/TCP Default ports. X-Mailer: USANET web-mailer (34FM.0700.17C.01) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.pit.comms.marconi.com id QAA15185 Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: 8bit Hello All, section 9.Transport says "If TCP or UDP is used as the protocol transport and the port to which the initial ServiceChange request is to be sent is not otherwise known, that request should be sent to the default port number for the protocol. This port number is 2944 for text-encoded operation or 2945 for binary-encoded operation, for either UDP or TCP." Since the protocol says MGC should support both UDP and TCP, how does MGC binds for the same port for both TCP as well UDP transport ?. This is a pure provisional/configuration issue or Is there a otherway to deal with this problem ? Please clarify this . Surya ____________________________________________________________________ Get free email and a permanent address at http://www.netaddress.com/?N=1 From owner-megaco@fore.com Wed Jun 20 17:27:02 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23486 for ; Wed, 20 Jun 2001 17:27:02 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA21426; Wed, 20 Jun 2001 17:17:14 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id RAA19861 for megaco-list; Wed, 20 Jun 2001 17:16:32 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA19853 for ; Wed, 20 Jun 2001 17:16:31 -0400 (EDT) Received: from texlog2.texas.rr.com (texlog2.texas.rr.com [24.93.35.223]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA21303 for ; Wed, 20 Jun 2001 17:16:26 -0400 (EDT) Received: from plong (cs666831-163.austin.rr.com [66.68.31.163]) by texlog2.texas.rr.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f5KLGLdQ012939 for ; Wed, 20 Jun 2001 16:16:22 -0500 (CDT) From: "Paul Long" To: Subject: RE: UDP/TCP Default ports. Date: Wed, 20 Jun 2001 16:16:28 -0500 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <20010620205407.11629.qmail@nwcst336.netaddress.usa.net> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: 7bit The TCP port space is distinct from the UDP port space. Paul Long ipDialog, Inc. -----Original Message----- From: owner-megaco@pit.comms.marconi.com [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of suryapratap vamsi Sent: Wednesday, June 20, 2001 3:54 PM To: megaco@fore.com Subject: UDP/TCP Default ports. Hello All, section 9.Transport says "If TCP or UDP is used as the protocol transport and the port to which the initial ServiceChange request is to be sent is not otherwise known, that request should be sent to the default port number for the protocol. This port number is 2944 for text-encoded operation or 2945 for binary-encoded operation, for either UDP or TCP." Since the protocol says MGC should support both UDP and TCP, how does MGC binds for the same port for both TCP as well UDP transport ?. This is a pure provisional/configuration issue or Is there a otherway to deal with this problem ? Please clarify this . Surya ____________________________________________________________________ Get free email and a permanent address at http://www.netaddress.com/?N=1 From owner-megaco@fore.com Wed Jun 20 17:29:44 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23529 for ; Wed, 20 Jun 2001 17:29:43 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA21641; Wed, 20 Jun 2001 17:18:45 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id RAA20143 for megaco-list; Wed, 20 Jun 2001 17:17:48 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA20137 for ; Wed, 20 Jun 2001 17:17:47 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 20 Jun 2001 17:17:45 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF044655B2@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Terry L Anderson'" Cc: megaco@fore.com Subject: RE: Query on case insensitivity Date: Wed, 20 Jun 2001 17:17:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Yep, could be an issue. Brian > -----Original Message----- > From: Terry L Anderson [mailto:tla@lucent.com] > Sent: Wednesday, June 20, 2001 2:40 PM > To: Rosen, Brian > Cc: megaco@fore.com > Subject: Re: Query on case insensitivity > > > Isn't there an issue with UDP since, as I understand it, the > full message > must be less than MTU (often 1400 bytes or so). Seems that > with long form > text this may more often be exceeded. A lot of my Adds or > Modifies with SDP > come close. > > "Rosen, Brian" wrote: > > > Debugging is considered a very good reason for long tokens. > > Generally speaking there is NO good reason for short tokens, > > but we were working towards no binary (which failed of course), > > and we wanted to not have the length-of-message argument. > > There are very few MGs on links where bandwidth is so constrained, > > the difference between long and short tokens matters. > > Now, if we were using Megaco on a mobile link, where we had kilobits > > of bandwidth, maybe. > > > > BTW, in the end, text is proving to be shorter, and faster, than > > binary (I think that is with short tokens but I'm not sure). > > But we knew that, right :) > > > > Brian > > > > > -----Original Message----- > > > From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com] > > > Sent: Wednesday, June 20, 2001 11:33 AM > > > To: svkumar@hss.hns.com; megaco@fore.com > > > Subject: RE: Query on case insensitivity > > > > > > > > > Hi Shiv,all, > > > I agree with shiv's argument. First of all, I am not clear > > > why there are two > > > set of tokens. The long tokens doesn't convey any extra > > > information (except > > > for debugging purposes). In terms of efficiency obviously the > > > short tokens > > > will be the better choice. And having a mix of both unnecessarily > > > complicates the parser. > > > > > > Regards > > > Madhubabu > > > > > > -----Original Message----- > > > From: owner-megaco@pit.comms.marconi.com > > > [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of > > > svkumar@hss.hns.com > > > Sent: Wednesday, June 20, 2001 11:24 AM > > > To: megaco@fore.com > > > Subject: RE: Query on case insensitivity > > > > > > > > > > > > > > > > > > > > > Hi > > > > > > I am a bit concerned about the first point. > > > Maybe its a bit too late, or simply irrelevant, but still I > > > would like to > > > put > > > forth this point. > > > > > > Allowing a message to contain a mixture of short and > long tokens will > > > needlessly complicate the parser. > > > For tokens like the one for Error, which has a short > > > token 'Er' and a > > > long > > > one 'Error' > > > the parser would have to look ahead to the 3rd character to > > > conclude whether > > > it > > > is the shorter version of > > > Error token, or it is halfway thru the long 'Error' token or > > > whether it is > > > simply an syntax error. If we put a small > > > restriction, that the messages should contain only one kind > > > of tokens, it > > > would > > > atleast do away with one of the possibilities. > > > Parsing is a CPU intensive process and such small > > > restrictions would be > > > a > > > major help. > > > It will make life simpler for the parser, and perhaps > > > make the messages > > > more elegant. > > > > > > Regards > > > Shiv > > > > > > > > > > > > > > > > > > "Rosen, Brian" on 06/20/2001 05:58:32 PM > > > > > > To: Amit Kalra/HSS@HSS, megaco@fore.com > > > cc: (bcc: Shiv Kumar/HSS) > > > > > > Subject: RE: Query on case insensitivity > > > > > > > > > > > > > > > The answer to all of your queries is yes > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: akalra@hss.hns.com [mailto:akalra@hss.hns.com] > > > > Sent: Wednesday, June 20, 2001 1:27 AM > > > > To: megaco@fore.com > > > > Subject: Query on case insensitivity > > > > > > > > > > > > > > > > > > > > Hi all, > > > > ABNF syntax notation is CASE INSENSITIVE, apart from the > > > > SDP and whatever > > > > comes within quotes should not be validated. > > > > My queries: > > > > 1. In case of short and long tokens can we mix both of > them like > > > > > > > > MEGACO/1 [123.123.123.123]:55555 > > > > P = 50005 { > > > > Context = - { N = A5555 } > > > > Is it allowed? > > > > > > > > 2. Can we have tokens like "TranACTIONresponSEAck" , I > > > > mean mix of lower and > > > > upper case in one token ? > > > > > > > > 3. Can we have short tokens in lower case or mix case like > > > > "rc" or "rC" for > > > > ReceiveOnly ? > > > > > > > > regards/ > > > > Amit > > > > > > > > > > > > > > > > > > > > > > -- > ------------------------------------------------------------ > Terry L Anderson mailto:tla@lucent.com > Tel:908.582.7013 Fax:908.582.6729 > Lucent Technologies/INS/Voice Over IP Access Networks > Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 > http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla > > From owner-megaco@fore.com Wed Jun 20 17:34:43 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23739 for ; Wed, 20 Jun 2001 17:34:42 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA22155; Wed, 20 Jun 2001 17:23:19 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id RAA21145 for megaco-list; Wed, 20 Jun 2001 17:22:34 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA21139 for ; Wed, 20 Jun 2001 17:22:32 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 20 Jun 2001 17:22:30 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF044655B3@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Nitin Kumar'" , "'megaco@fore.com'" Subject: RE: Few clarification in RFC3015 Date: Wed, 20 Jun 2001 17:22:30 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Hmmm, maybe we should edit that text to say: "Actions in a transaction and commands within an action are executed sequentially in the order they appear in the transaction." Terry? "Normal Repitition timers" are the timer values defined in D.1.3 Brian > -----Original Message----- > From: Nitin Kumar [mailto:nitin@indts.com] > Sent: Wednesday, June 20, 2001 2:32 PM > To: 'megaco@fore.com' > Subject: Few clarification in RFC3015 > > > Hi Folks, > > Just looking for following clarification. > > 1. In a TransactionRequest, are ActionRequests processed in > order or only > Commands in an ActionRequest are executed sequencially ? RFC > says "Commands > within a Transaction are executed sequentially." > > 2. Few lines from the RFC on page number 135, section D.1.4.. > "Upon receipt of a final response following receipt of > provisional responses, an immediate confirmation shall be sent, and > normal repetition timers shall be used thereafter." > > Now what does "normal repetition timers shall be used > thereafter" mean in > above extract? > > i hope to receive some insights. > > regards, > > -nitin > > Ind Telesoft Pvt. Ltd. > 104, Koramangla Industrial Estate, > 5th Block, Bangalore 560 095 > Tel : 5508930, 5521937, 5529758-62 ext-259 > Fax : 5521164 > mailto:nitin@indts.com > http:\\www.telesoftinc.com > From owner-megaco@fore.com Wed Jun 20 17:55:54 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA24340 for ; Wed, 20 Jun 2001 17:55:53 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA23683; Wed, 20 Jun 2001 17:45:10 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id RAA24968 for megaco-list; Wed, 20 Jun 2001 17:44:09 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA24960 for ; Wed, 20 Jun 2001 17:44:06 -0400 (EDT) Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA23565 for ; Wed, 20 Jun 2001 17:44:00 -0400 (EDT) Received: from ihemail1.firewall.lucent.com (localhost [127.0.0.1]) by ihemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5KLi2K01350 for ; Wed, 20 Jun 2001 17:44:02 -0400 (EDT) Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3]) by ihemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5KLi1R01341 for ; Wed, 20 Jun 2001 17:44:02 -0400 (EDT) Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id RAA20900; Wed, 20 Jun 2001 17:43:35 -0400 (EDT) Cc: "'Nitin Kumar'" , "'megaco@fore.com'" Received: from lucent.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id RAA20886; Wed, 20 Jun 2001 17:43:33 -0400 (EDT) Message-ID: <3B311888.F7B4F99B@lucent.com> Date: Wed, 20 Jun 2001 17:41:28 -0400 From: Troy Cauble Reply-To: Troy Cauble X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Rosen, Brian" Original-CC: "'Nitin Kumar'" , "'megaco@fore.com'" Subject: Re: Few clarification in RFC3015 References: <4FBEA8857476D311A03300204840E1CF044655B3@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: 7bit I suggest a shortened version, the trailing clause was confusing. "Actions in a transaction and commands within an action are executed sequentially in the order they appear." -troy "Rosen, Brian" wrote: > > Hmmm, maybe we should edit that text to say: > "Actions in a transaction and commands within an action are > executed sequentially in the order they appear in the transaction." > > Terry? > > "Normal Repitition timers" are the timer values defined in D.1.3 > > Brian > > > -----Original Message----- > > From: Nitin Kumar [mailto:nitin@indts.com] > > Sent: Wednesday, June 20, 2001 2:32 PM > > To: 'megaco@fore.com' > > Subject: Few clarification in RFC3015 > > > > > > Hi Folks, > > > > Just looking for following clarification. > > > > 1. In a TransactionRequest, are ActionRequests processed in > > order or only > > Commands in an ActionRequest are executed sequencially ? RFC > > says "Commands > > within a Transaction are executed sequentially." > > > > 2. Few lines from the RFC on page number 135, section D.1.4.. > > "Upon receipt of a final response following receipt of > > provisional responses, an immediate confirmation shall be sent, and > > normal repetition timers shall be used thereafter." > > > > Now what does "normal repetition timers shall be used > > thereafter" mean in > > above extract? > > > > i hope to receive some insights. > > > > regards, > > > > -nitin > > > > Ind Telesoft Pvt. Ltd. > > 104, Koramangla Industrial Estate, > > 5th Block, Bangalore 560 095 > > Tel : 5508930, 5521937, 5529758-62 ext-259 > > Fax : 5521164 > > mailto:nitin@indts.com > > http:\\www.telesoftinc.com > > From owner-megaco@fore.com Wed Jun 20 18:08:43 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA24607 for ; Wed, 20 Jun 2001 18:08:42 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA24421; Wed, 20 Jun 2001 17:55:56 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id RAA27133 for megaco-list; Wed, 20 Jun 2001 17:54:24 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA27120 for ; Wed, 20 Jun 2001 17:54:23 -0400 (EDT) Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA24286 for ; Wed, 20 Jun 2001 17:54:17 -0400 (EDT) Received: from ihemail1.firewall.lucent.com (localhost [127.0.0.1]) by ihemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5KLsJK08189 for ; Wed, 20 Jun 2001 17:54:19 -0400 (EDT) Received: from teton.mh.lucent.com (h135-3-130-2.lucent.com [135.3.130.2]) by ihemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5KLsJR08176; Wed, 20 Jun 2001 17:54:19 -0400 (EDT) Received: from lucent.com ([135.3.128.238]) by teton.mh.lucent.com (8.8.8+Sun/8.8.8) with ESMTP id RAA26742; Wed, 20 Jun 2001 17:54:18 -0400 (EDT) Message-ID: <3B311B33.D6CFA912@lucent.com> Date: Wed, 20 Jun 2001 17:52:51 -0400 From: Terry L Anderson Organization: Lucent Technologies X-Mailer: Mozilla 4.75 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: "Rosen, Brian" CC: "'Nitin Kumar'" , "'megaco@fore.com'" Subject: Re: Few clarification in RFC3015 References: <4FBEA8857476D311A03300204840E1CF044655B3@whq-msgusr-02.pit.comms.marconi.com> Content-Type: multipart/mixed; boundary="------------B6508594C01B07E81FBD32AF" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk This is a multi-part message in MIME format. --------------B6508594C01B07E81FBD32AF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Rosen, Brian" wrote: > Hmmm, maybe we should edit that text to say: > "Actions in a transaction and commands within an action are > executed sequentially in the order they appear in the transaction." > > Terry? That is certainly the intent and the way I would read the current text ("commands in order" - the fact that they are grouped into actions doesn't alter their order). But your text is certainly more explicit. I have no trouble with it. I'll put it in. > > > "Normal Repitition timers" are the timer values defined in D.1.3 > > Brian > > > -----Original Message----- > > From: Nitin Kumar [mailto:nitin@indts.com] > > Sent: Wednesday, June 20, 2001 2:32 PM > > To: 'megaco@fore.com' > > Subject: Few clarification in RFC3015 > > > > > > Hi Folks, > > > > Just looking for following clarification. > > > > 1. In a TransactionRequest, are ActionRequests processed in > > order or only > > Commands in an ActionRequest are executed sequencially ? RFC > > says "Commands > > within a Transaction are executed sequentially." > > > > 2. Few lines from the RFC on page number 135, section D.1.4.. > > "Upon receipt of a final response following receipt of > > provisional responses, an immediate confirmation shall be sent, and > > normal repetition timers shall be used thereafter." > > > > Now what does "normal repetition timers shall be used > > thereafter" mean in > > above extract? > > > > i hope to receive some insights. > > > > regards, > > > > -nitin > > > > Ind Telesoft Pvt. Ltd. > > 104, Koramangla Industrial Estate, > > 5th Block, Bangalore 560 095 > > Tel : 5508930, 5521937, 5529758-62 ext-259 > > Fax : 5521164 > > mailto:nitin@indts.com > > http:\\www.telesoftinc.com > > -- ------------------------------------------------------------ Terry L Anderson mailto:tla@lucent.com Tel:908.582.7013 Fax:908.582.6729 Lucent Technologies/INS/Voice Over IP Access Networks Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla --------------B6508594C01B07E81FBD32AF Content-Type: text/x-vcard; charset=us-ascii; name="tla.vcf" Content-Description: Card for Terry L Anderson Content-Disposition: attachment; filename="tla.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Anderson;Terry L tel;fax:908.582.6729 tel;work:908.582.7013 x-mozilla-html:TRUE url:http://its.lucent.com/~tla org:Lucent / InterNetworking Systems;VoIP Access Networks version:2.1 email;internet:tla@lucent.com title:DMTS note:http://www.gti.net/tla or http://teton.mh.lucent.com/~tla (Lucent internal) adr;quoted-printable:;;Rm 2B-121=0D=0A600 Mountain Ave;Murray Hill;NJ;07974;USA x-mozilla-cpt:;7264 fn:Terry L Anderson end:vcard --------------B6508594C01B07E81FBD32AF-- From owner-megaco@fore.com Wed Jun 20 18:25:24 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25030 for ; Wed, 20 Jun 2001 18:25:23 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA25734; Wed, 20 Jun 2001 18:15:10 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id SAA00468 for megaco-list; Wed, 20 Jun 2001 18:14:17 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA00461 for ; Wed, 20 Jun 2001 18:14:16 -0400 (EDT) Received: from nwcst333.netaddress.usa.net (nwcst333.netaddress.usa.net [204.68.23.78]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with SMTP id SAA25637 for ; Wed, 20 Jun 2001 18:14:10 -0400 (EDT) Received: (qmail 22702 invoked by uid 60001); 20 Jun 2001 22:14:12 -0000 Message-ID: <20010620221412.22701.qmail@nwcst333.netaddress.usa.net> Received: from 204.68.23.78 by nwcst333 for [63.111.211.20] via web-mailer(34FM.0700.17C.01) on Wed Jun 20 22:14:12 GMT 2001 Date: 20 Jun 2001 16:14:12 MDT From: suryapratap vamsi To: plong@ipdialog.com, megaco@fore.com Subject: RE: UDP/TCP Default ports. X-Mailer: USANET web-mailer (34FM.0700.17C.01) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.pit.comms.marconi.com id SAA00462 Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: 8bit Hello Paul, I framed the question incorrectly. Let me rephrase it again. The MGC should support both TCP and UDP, and MG can either support TCP or UDP or both. Assuming MGC is created two udp listen sockets( 2944 for text, 2945 for binary), and MG is trying to establish communication with TCP, it's connection will get refused. So, there should be someway of specifing in the RFC that, the GW should try to send the initial SvcChangeRequest with UDP transport or otherwise or on TCP transport. Thanks Surya -----Original Message----- From: Paul Long [mailto:plong@ipdialog.com] Sent: Wednesday, June 20, 2001 5:16 PM To: megaco@fore.com Subject: RE: UDP/TCP Default ports. The TCP port space is distinct from the UDP port space. Paul Long ipDialog, Inc. -----Original Message----- From: owner-megaco@pit.comms.marconi.com [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of suryapratap vamsi Sent: Wednesday, June 20, 2001 3:54 PM To: megaco@fore.com Subject: UDP/TCP Default ports. Hello All, section 9.Transport says "If TCP or UDP is used as the protocol transport and the port to which the initial ServiceChange request is to be sent is not otherwise known, that request should be sent to the default port number for the protocol. This port number is 2944 for text-encoded operation or 2945 for binary-encoded operation, for either UDP or TCP." Since the protocol says MGC should support both UDP and TCP, how does MGC binds for the same port for both TCP as well UDP transport ?. This is a pure provisional/configuration issue or Is there a otherway to deal with this problem ? Please clarify this . Surya ____________________________________________________________________ Get free email and a permanent address at http://www.netaddress.com/?N=1 From owner-megaco@fore.com Wed Jun 20 19:25:05 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA26272 for ; Wed, 20 Jun 2001 19:25:04 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id TAA28195; Wed, 20 Jun 2001 19:14:55 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id TAA06954 for megaco-list; Wed, 20 Jun 2001 19:13:29 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id TAA06950 for ; Wed, 20 Jun 2001 19:13:28 -0400 (EDT) Received: from sapphire.int.ipverse.com ([65.195.29.42]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id TAA28068 for ; Wed, 20 Jun 2001 19:13:23 -0400 (EDT) Received: from default.ipverse.com (MATT [10.1.1.160]) by sapphire.int.ipverse.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id L4T527BM; Wed, 20 Jun 2001 16:13:24 -0700 Message-Id: <5.1.0.14.2.20010620161158.02158970@mail.ipverse.com> X-Sender: matt@mail.ipverse.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 20 Jun 2001 16:13:19 -0700 To: "Madhu Babu Brahmanapally" , "'Thalanayar Muthukumar'" , From: Matt Holdrege Subject: RE: ALGs for Megaco In-Reply-To: <012301c0f9bf$25c9dd30$c500a8c0@MBRAHMANAPALLY> References: <20010620183442.29890.qmail@web5305.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk From my memory, there is no ALG needed for MEGACO. However would be an ALG required for SDP and/or the MEGACO Native Descriptors aka H.245. At 12:28 PM 6/20/2001, Madhu Babu Brahmanapally wrote: >HI Kumar/All, >There is no ALG for Megaco. Earlier there was some discussion on NAT for >MEGACO. The conclusion then was that the outcome of midcom is something that >can be used for Megaco also. (Even I'm not sure what this means ;-p) > >Regards >Madhubabu > >-----Original Message----- >From: owner-megaco@pit.comms.marconi.com >[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Thalanayar >Muthukumar >Sent: Wednesday, June 20, 2001 2:35 PM >To: megaco@fore.com >Subject: ALGs for Megaco > > >Hi, > >Are there PC based applications using Megaco? If so, >please send information. > >Also, I understand that Megaco requires an ALG when >working with NAT. > >Is there any ALG for Megaco available in Linux? > >- Kuamr > > >__________________________________________________ >Do You Yahoo!? >Get personalized email addresses from Yahoo! Mail >http://personal.mail.yahoo.com/ From owner-megaco@fore.com Wed Jun 20 22:44:16 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA01316 for ; Wed, 20 Jun 2001 22:44:15 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id WAA04169; Wed, 20 Jun 2001 22:35:26 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id WAA20855 for megaco-list; Wed, 20 Jun 2001 22:33:30 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id WAA20851 for ; Wed, 20 Jun 2001 22:33:28 -0400 (EDT) Received: from ganymede.or.intel.com (jffdns01.or.intel.com [134.134.248.3]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id WAA04020 for ; Wed, 20 Jun 2001 22:33:23 -0400 (EDT) Received: from SMTP (orsmsxvs02-1.jf.intel.com [192.168.65.201]) by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.40 2001/06/06 21:14:49 root Exp $) with SMTP id CAA12065 for ; Thu, 21 Jun 2001 02:33:09 GMT Received: from orsmsx28.jf.intel.com ([192.168.70.28]) by 192.168.70.201 (Norton AntiVirus for Internet Email Gateways 1.0) ; Thu, 21 Jun 2001 02:33:09 0000 (GMT) Received: by orsmsx28.jf.intel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Jun 2001 19:33:08 -0700 Message-ID: From: "Kaul, Bharat" To: "'megaco@fore.com'" Subject: ISDN Terminated at MG and Packages Required Date: Wed, 20 Jun 2001 15:53:31 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Can someone clarify following for me :) > If ISDN is terminated to MG, which package is necessary for ISDN bearer > capability and call connection? Is basic package sufficient or do we need > additional packages ? > > - Bharat > > From owner-megaco@fore.com Wed Jun 20 23:24:33 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA02685 for ; Wed, 20 Jun 2001 23:24:33 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id XAA05793; Wed, 20 Jun 2001 23:14:23 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id XAA24030 for megaco-list; Wed, 20 Jun 2001 23:13:12 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id XAA24026 for ; Wed, 20 Jun 2001 23:13:11 -0400 (EDT) From: Stealth@btamail.net.cn Received: from www.fashionnet.seoul.kr ([211.192.22.50]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id XAA05687 for ; Wed, 20 Jun 2001 23:12:59 -0400 (EDT) Received: from lovecanival.co.kr by www.fashionnet.seoul.kr (8.9.3/1.1.27.5/28May01-1104PM) id MAA0000501757; Thu, 21 Jun 2001 12:12:22 +0900 (KST) Message-Id: <200106210312.MAA0000501757@www.fashionnet.seoul.kr> To: Subject: 10 Million Fresh Email Addresses, Stealth Mass Mailer & More.. 8612 Date: Wed, 20 Jun 2001 20:14:40 -0700 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal Reply-To: Stealth@btamail.net.cn Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: quoted-printable
Email = Advertising WORKS!


Email Advertise your product or website to millions for only $99.

For $99.00 you will receive the Stealth Bulk E-Mailing Software, List Manager, Over 10 Million "FRESH" E-Mail Addresses, Targeted Email Address Harvesting Software, and as a FREE BONUS, special Mail Servers to send your mail through!

Its only $99 for everything,
and you can DOWNLOAD IT ALL, today!

FOR MORE INFO:
Click H= ERE OR Si= mply Reply with "99" in the SUBJECT Field

To be PERMANENTLY REMOVED from our mail list:
Click HERE&= nbsp;OR Simply Rep= ly with "REMOVE" in the SUBJECT Field

--- From owner-megaco@fore.com Thu Jun 21 01:48:48 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA07407 for ; Thu, 21 Jun 2001 01:48:47 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id BAA09519; Thu, 21 Jun 2001 01:39:51 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id BAA03273 for megaco-list; Thu, 21 Jun 2001 01:38:12 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id BAA03269 for ; Thu, 21 Jun 2001 01:38:11 -0400 (EDT) Received: from netmail2.alcatel.com (netmail2.alcatel.com [128.251.168.51]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id BAA09398 for ; Thu, 21 Jun 2001 01:38:04 -0400 (EDT) Received: from auds953.usa.alcatel.com (auds953.usa.alcatel.com [143.209.238.6]) by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id AAA23195; Thu, 21 Jun 2001 00:38:04 -0500 (CDT) Received: from axes-mach01.axes-mach01.usa.alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f5L5bwD14215; Thu, 21 Jun 2001 00:37:59 -0500 (CDT) Received: from Chak by axes-mach01.axes-mach01.usa.alcatel.com (8.9.1b+Sun/SMI-SVR4) id LAA23531; Thu, 21 Jun 2001 11:04:00 -0500 (GMT) Message-ID: <005201c0fa15$0cfedb60$2f09ca82@Chak> From: "PSK Chakravarthi" To: "Rosen, Brian" , "'Madhu Babu Brahmanapally'" , "'Terry L Anderson'" Cc: References: <4FBEA8857476D311A03300204840E1CF044655AB@whq-msgusr-02.pit.comms.marconi.com> Subject: Re: Ephemeral Termination Date: Thu, 21 Jun 2001 11:13:06 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: 7bit The reason for creating Ephemeral and reserving SDP before knowing the termination is to reduce the call setup time. thanks & regards Chak ----- Original Message ----- From: "Rosen, Brian" To: "'Madhu Babu Brahmanapally'" ; "'Terry L Anderson'" ; "'PSK Chakravarthi'" Cc: Sent: Wednesday, June 20, 2001 9:07 PM Subject: RE: Ephemeral Termination > I'm not at all sure what "resources" you can reserve before you > know the destination: > > For an IP network, you can reserve a UDP port I suppose, but until > you negotiate the SDP, you can't reserve bandwidth. You can't > make any QoS reservation for the same reason. > > It's worse on an ATM network. > > I think there is nothing to be gained by #1 > > Brian > > > -----Original Message----- > > From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com] > > Sent: Wednesday, June 20, 2001 11:28 AM > > To: 'Terry L Anderson'; 'PSK Chakravarthi' > > Cc: megaco@fore.com > > Subject: RE: Ephemeral Termination > > > > > > Hi All, > > The creation of ephemeral termination can be done either after digit > > analysis or before it. Each has its own advantages and disadvantages. > > > > 1) If Ephemeral termination is created before digit analysis, > > situation may > > occur where the destination user/termination is connected to > > the same MG and > > there is no need to create an ephemeral termination (as PSK > > mentioned). But > > this has the advantage that the call wont be dropped due to lack of > > resource, as ephemeral resources are pre-reserved at the MG. > > (in case Add > > fails later to add ephemeral termination). > > > > 2) If Ephemeral termination is created after digit analysis, > > it takes care > > of all situation where destination user may/may not connected > > to the same > > MG. But when Ephemeral termination is added later, there is no > > pre-reservation of the ephemeral resources at the origination MG. > > > > In case of 1) if the call doesn't mature, reserving the > > resources doesn't > > gain anything. Consideration that the destination user on the > > same MG is > > less probable, Method 2 IMO will be a better choice. > > > > Regards > > Madhubabu > > > > -----Original Message----- > > From: owner-megaco@pit.comms.marconi.com > > [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Terry > > L Anderson > > Sent: Wednesday, June 20, 2001 11:01 AM > > To: PSK Chakravarthi > > Cc: megaco@fore.com > > Subject: Re: Ephemeral Termination > > > > > > > > > > PSK Chakravarthi wrote: > > > > > I have got the following doubt. > > > If the originating and terminating termination IDs are on > > the same gateway > > and > > > gateway supports two TDM terminations in a context, is it > > required to > > craete a > > > ephenmeral termination for this call? > > > > > > Message flow between MGC and MG: > > > > > > 1. MGC send ADD command to originating MG > > > a) Choose a context ID > > > b) Add a TDM termination > > > c) Choose a Ephemeral termination > > > d) Reserve Local Descriptor > > > e) set MODE to Receive only. > > > > > > 2. MGC now finds that call is terminating on the same MG. > > Also MGC knows > > that > > > MG is capable of adding two TDMs to the same context. At > > this point what > > should > > > be the command to the MG? > > > Is it required to SUBTRACT the ephemeral termination and > > send ADD for > > adding new > > > TDM to the same context? or > > > Simply sending ADD for new TDM to the same context is sufficient? > > > > It would be better if MGC "finds" that the call is terminated > > on the same MG > > before > > sending the ADD, in step 1c, but if since step c (which you > > call "Choose a > > Ephemeral > > termination) is an Add with wildcard, MGC must certainly > > Subtract it if it > > chooses > > later not to use it. The Subtract deletes the ephemeral > > termination and > > releases > > its resources. > > > > > thanks & regards > > > Chak > > > > -- > > ------------------------------------------------------------ > > Terry L Anderson mailto:tla@lucent.com > > Tel:908.582.7013 Fax:908.582.6729 > > Lucent Technologies/INS/Voice Over IP Access Networks > > Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 > > http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla > > > > > From owner-megaco@fore.com Thu Jun 21 01:55:30 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA07856 for ; Thu, 21 Jun 2001 01:55:30 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id BAA09833; Thu, 21 Jun 2001 01:46:40 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id BAA03709 for megaco-list; Thu, 21 Jun 2001 01:45:59 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id BAA03705 for ; Thu, 21 Jun 2001 01:45:58 -0400 (EDT) Received: from telesoft.indts.com ([164.164.71.52]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id BAA09749 for ; Thu, 21 Jun 2001 01:45:44 -0400 (EDT) Received: from indts_fs.indts.com (indts_fs [201.64.64.29]) by telesoft.indts.com (8.8.7/8.8.7) with ESMTP id LAA20478; Thu, 21 Jun 2001 11:34:39 +0530 Received: by INDTS_FS with Internet Mail Service (5.5.2650.21) id ; Thu, 21 Jun 2001 11:20:52 +0530 Message-ID: From: Nitin Kumar To: "'Terry L Anderson'" , "Rosen, Brian" Cc: "'megaco@fore.com'" Subject: RE: Few clarification in RFC3015 Date: Thu, 21 Jun 2001 11:20:51 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk ok... thats what even i thought.. now if actions in a transaction are processed in sequence then consider following scenario TransactionRequest { Action1 { command1 command2 } Action2 { command1 command2 command3 } Action3 { command1 command2 } } Suppose all commands are manatory. Lets assume command2 in Action2 generates some error or is not processed successfully then does it mean that command3 of Action2 as well as any further action i.e. Action3 will not be executed? If yes, then my doubt is: when every Action is concerned with different Context.. then why failure of one command in one Action should bother other Action with in the same transaction? We should be able to process every Action sequentially and independently. regards, -nitin -----Original Message----- From: Terry L Anderson [mailto:tla@lucent.com] Sent: Thursday, June 21, 2001 3:23 AM To: Rosen, Brian Cc: 'Nitin Kumar'; 'megaco@fore.com' Subject: Re: Few clarification in RFC3015 "Rosen, Brian" wrote: > Hmmm, maybe we should edit that text to say: > "Actions in a transaction and commands within an action are > executed sequentially in the order they appear in the transaction." > > Terry? That is certainly the intent and the way I would read the current text ("commands in order" - the fact that they are grouped into actions doesn't alter their order). But your text is certainly more explicit. I have no trouble with it. I'll put it in. > > > "Normal Repitition timers" are the timer values defined in D.1.3 > > Brian > > > -----Original Message----- > > From: Nitin Kumar [mailto:nitin@indts.com] > > Sent: Wednesday, June 20, 2001 2:32 PM > > To: 'megaco@fore.com' > > Subject: Few clarification in RFC3015 > > > > > > Hi Folks, > > > > Just looking for following clarification. > > > > 1. In a TransactionRequest, are ActionRequests processed in > > order or only > > Commands in an ActionRequest are executed sequencially ? RFC > > says "Commands > > within a Transaction are executed sequentially." > > > > 2. Few lines from the RFC on page number 135, section D.1.4.. > > "Upon receipt of a final response following receipt of > > provisional responses, an immediate confirmation shall be sent, and > > normal repetition timers shall be used thereafter." > > > > Now what does "normal repetition timers shall be used > > thereafter" mean in > > above extract? > > > > i hope to receive some insights. > > > > regards, > > > > -nitin > > > > Ind Telesoft Pvt. Ltd. > > 104, Koramangla Industrial Estate, > > 5th Block, Bangalore 560 095 > > Tel : 5508930, 5521937, 5529758-62 ext-259 > > Fax : 5521164 > > mailto:nitin@indts.com > > http:\\www.telesoftinc.com > > -- ------------------------------------------------------------ Terry L Anderson mailto:tla@lucent.com Tel:908.582.7013 Fax:908.582.6729 Lucent Technologies/INS/Voice Over IP Access Networks Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla From owner-megaco@fore.com Thu Jun 21 03:35:12 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA21093 for ; Thu, 21 Jun 2001 03:35:12 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id DAA12483; Thu, 21 Jun 2001 03:26:21 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id DAA09428 for megaco-list; Thu, 21 Jun 2001 03:24:23 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id DAA09424 for ; Thu, 21 Jun 2001 03:24:22 -0400 (EDT) Received: from hotmail.com (f217.law14.hotmail.com [64.4.21.217]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id DAA12277 for ; Thu, 21 Jun 2001 03:24:18 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 21 Jun 2001 00:24:18 -0700 Received: from 61.132.62.80 by lw14fd.law14.hotmail.msn.com with HTTP; Thu, 21 Jun 2001 07:24:18 GMT X-Originating-IP: [61.132.62.80] From: "mu lj" To: megaco@fore.com Subject: me how to get h.248 version 2? Date: Thu, 21 Jun 2001 15:24:18 +0800 Mime-Version: 1.0 Content-Type: text/plain; charset=gb2312; format=flowed Message-ID: X-OriginalArrivalTime: 21 Jun 2001 07:24:18.0361 (UTC) FILETIME=[2EE01290:01C0FA23] Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk hi all: Who can tell me how to get h.248 version 2? Regards, mu lj _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. From owner-megaco@fore.com Thu Jun 21 03:39:45 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA21094 for ; Thu, 21 Jun 2001 03:35:12 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id DAA12486; Thu, 21 Jun 2001 03:26:22 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id DAA09439 for megaco-list; Thu, 21 Jun 2001 03:24:36 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id DAA09435 for ; Thu, 21 Jun 2001 03:24:34 -0400 (EDT) Received: from hotmail.com (f14.law14.hotmail.com [64.4.21.14]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id DAA12287 for ; Thu, 21 Jun 2001 03:24:30 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 21 Jun 2001 00:24:31 -0700 Received: from 61.132.62.80 by lw14fd.law14.hotmail.msn.com with HTTP; Thu, 21 Jun 2001 07:24:30 GMT X-Originating-IP: [61.132.62.80] From: "mu lj" To: megaco@fore.com Subject: how to get h.248 version 2? Date: Thu, 21 Jun 2001 15:24:30 +0800 Mime-Version: 1.0 Content-Type: text/plain; charset=gb2312; format=flowed Message-ID: X-OriginalArrivalTime: 21 Jun 2001 07:24:31.0155 (UTC) FILETIME=[36804830:01C0FA23] Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk hi all: Who can tell me how to get h.248 version 2? Regards, mu lj _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. From owner-megaco@fore.com Thu Jun 21 05:27:59 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA22287 for ; Thu, 21 Jun 2001 05:27:59 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id FAA16191; Thu, 21 Jun 2001 05:18:35 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id FAA18553 for megaco-list; Thu, 21 Jun 2001 05:16:31 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id FAA18547 for ; Thu, 21 Jun 2001 05:16:29 -0400 (EDT) Received: from mail.bhartitelesoft.com ([202.56.229.147]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id FAA16057 for ; Thu, 21 Jun 2001 05:16:18 -0400 (EDT) Received: from sarju (taquila [202.56.229.146]) by mail.bhartitelesoft.com (8.11.0/8.11.0) with SMTP id f5L9DiF22027 for ; Thu, 21 Jun 2001 14:43:47 +0530 Message-ID: <002e01c0fa33$739514c0$240310ac@bhartitelesoft.com> Reply-To: "Sarju Garg" From: "Sarju Garg" To: "'megaco'" Subject: How to Determine the Termination Type Date: Thu, 21 Jun 2001 14:22:46 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002B_01C0FA5D.A4CA5580" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_002B_01C0FA5D.A4CA5580 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, Suppose MG application supports RTP, PSTN termination. The termination = are allocated by the MG application for a call? So the ADD command = specify $ for the termination name so that MG can allocate a termination = and return it to MGC application. How does the MG application come to = know that receiving an ADD command is for which type of termination - = for RTP termination or PSTN termination? I believe Local/Remote = descriptors are required for RTP terminations. So can Local/Remote = descriptor be used for this purpose?=20 TIA Sarju ------=_NextPart_000_002B_01C0FA5D.A4CA5580 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

 
Hi all,
 
Suppose MG application supports RTP, = PSTN=20 termination. The termination are allocated by the MG application for a = call? So=20 the ADD command specify $ for the termination name so that MG can = allocate a=20 termination  and return it to MGC application. How does the MG = application=20 come to know that receiving an ADD command is for which type of = termination -=20 for RTP termination or PSTN termination? I believe Local/Remote = descriptors are=20 required for RTP terminations. So can Local/Remote descriptor be used = for this=20 purpose?
 
TIA
Sarju
 
------=_NextPart_000_002B_01C0FA5D.A4CA5580-- From owner-megaco@fore.com Thu Jun 21 07:33:17 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA23724 for ; Thu, 21 Jun 2001 07:33:16 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id HAA20292; Thu, 21 Jun 2001 07:24:20 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id HAA01038 for megaco-list; Thu, 21 Jun 2001 07:22:00 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id HAA01034 for ; Thu, 21 Jun 2001 07:21:59 -0400 (EDT) Received: from mail.bhartitelesoft.com ([202.56.229.147]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id HAA20150 for ; Thu, 21 Jun 2001 07:21:50 -0400 (EDT) Received: from sarju (taquila [202.56.229.146]) by mail.bhartitelesoft.com (8.11.0/8.11.0) with SMTP id f5LBJ9F13144; Thu, 21 Jun 2001 16:49:10 +0530 Message-ID: <003601c0fa44$f4e8ee00$240310ac@bhartitelesoft.com> Reply-To: "Sarju Garg" From: "Sarju Garg" To: "Rosen, Brian" , "'megaco'" References: <4FBEA8857476D311A03300204840E1CF044655A1@whq-msgusr-02.pit.comms.marconi.com> Subject: Re: Property Characteristics Date: Thu, 21 Jun 2001 16:55:58 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0033_01C0FA73.0BD89420" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0033_01C0FA73.0BD89420 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yes. I think this make things more clear. What does others says about = it?=20 I have other queries related to package characteristics in the following = section: 1. Sec 12.1.2 Defined in: Can a property be defined in more than one = descriptor? 2. Sec 12.1.5 Statistics: How can I define a unit? is it of type double = or int or what? Would it be better to define it as=20 Statisitics Name: only descriptive Statistics ID: Is an identifier Type: One of: U_Integer : 4 byte unsigned integer U_Double: 8 byte unsigned integer. Possible Values: This definition is what followed in defining packages for RTP package. = Sec E.12.4. Should be change Type double to unsigned double as it just = count the number of package which cannot be negative? 3. Can a package be extended from two packages?=20 TIA=20 Sarju ----- Original Message -----=20 From: Rosen, Brian=20 To: 'Sarju Garg' ; 'megaco'=20 Sent: Wednesday, June 20, 2001 8:01 PM Subject: RE: Property Characteristics Here is the entire text: =20 Characteristics: Read / Write or both, and (optionally), global:=20 Indicates whether a property is read-only, or read-write, and if=20 it is global. If Global is omitted, the property is not global. = If a property is declared as global, the value of the property is = shared by all terminations realizing the package.=20 The only part I see that is potentially confusing is whether you can = have a write-only property. Such things used to happen in hardware design, but it's been a LONG time since I allowed any engineer to create one. =20 I can try rewriting it: Characteristics: A property may have one or two characteristics = specified: read/write and global. The read/write characteristic is specified as=20 "read-only" or "read-write". Every property MUST specify read/write. The characteristics specification MAY also include the "Global" keyword. If Global is specified, the value of the property is shared by all terminations realizing the package. If Global is not = specified, each termination realizing the package has an independent value of the property. =20 =20 If you really think that makes it more clear, we can ask that the rewritten text appear in the IG. =20 Brian =20 -----Original Message----- From: Sarju Garg [mailto:sarju@bhartitelesoft.com] Sent: Wednesday, June 20, 2001 9:55 AM To: Rosen, Brian; 'megaco' Subject: Re: Property Characteristics But it is pretty confusing in the document. In Section 12.1.2 it = says. Indicates whether a property is read-only or read-write and if it = is global. Also Sec 6.2.4 says that the property mat be read-only or = read/write. No mention of write in these cases. Can we specify an unambiguous line in the document?. I feel there = should be no convention in the standards. Everything should be specified = explicitly whereever possible.=20 Sarju ----- Original Message -----=20 From: Rosen, Brian=20 To: 'Sarju Garg' ; 'megaco'=20 Sent: Wednesday, June 20, 2001 6:50 PM Subject: RE: Property Characteristics Global and read/write are independent; you can have any = combination. =20 Packages should define the values. If they don't, there is no = default, and it's implementation dependent - a bad idea. I do believe the = current convention is that if you don't say Global, then it's "local". =20 Brian -----Original Message----- From: Sarju Garg [mailto:sarju@bhartitelesoft.com] Sent: Wednesday, June 20, 2001 9:20 AM To: 'megaco' Subject: Property Characteristics Hi all, I have a question pertaining to property characteristics. What I = understand is that the characteristics of property is one of the = following: read and local read/write and local read/write and global read and global Is write and local and write and global characteristics is also = possible as Sec 12.1.2 says Characteristics: Read/Write or both and = (optionally global)? =20 What is the default characteristics of the property as none of = the package define the characteristics? TIA Sarju=20 ------=_NextPart_000_0033_01C0FA73.0BD89420 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Yes. I think this make things more = clear. What does=20 others says about it?
 
I have other queries related to package = characteristics in the following section:
1. Sec 12.1.2 Defined in:  Can a = property be=20 defined in more than one descriptor?
 
2. Sec 12.1.5 Statistics: How can I = define a unit?=20 is it of type double or int or what? Would it be better to define it as=20
Statisitics Name: only = descriptive
Statistics ID: Is an = identifier
Type: One=20 of:
    U_Integer : 4 byte = unsigned=20 integer
    U_Double: 8 byte = unsigned=20 integer.
Possible Values:
 
This definition is what followed in = defining=20 packages for RTP package. Sec E.12.4. Should be change Type double to = unsigned=20 double as it just count the number of package which cannot be=20 negative?
 
3. Can a package be extended from two = packages?=20
 
TIA
Sarju
----- Original Message -----
From:=20 Rosen,=20 Brian
To: 'Sarju=20 Garg' ; 'megaco'
Sent: Wednesday, June 20, 2001 = 8:01=20 PM
Subject: RE: Property=20 Characteristics

Here is the=20 entire text:
 
     Characteristics: Read / Write or = both, and=20 (optionally), global:
     Indicates whether a = property is read-only, or read-write, and if =
     it=20 is global.  If Global is omitted, the property is not = global. =20
     If a property is declared as global, the = value of=20 the property is
     shared by all = terminations=20 realizing the package.
The only=20 part I see that is potentially confusing is whether you can=20 have
a=20 write-only property.  Such things used to happen in hardware=20 design,
but it's=20 been a LONG time since I allowed any engineer to create=20 one.
 
I can try=20 rewriting it:
Characteristics: A property may have one or two = characteristics=20 specified:
read/write=20 and global.  The read/write characteristic is specified = as=20
"read-only"=20 or=20 "read-write".  Every property MUST specify=20 read/write.
The=20 characteristics specification MAY also include the=20 "Global"
keyword.  If Global is specified, the value of the = property is=20 shared
by all=20 terminations realizing the package.  If Global is not=20 specified,
each=20 termination realizing the package has an independent value=20 of
the=20 property. 
 
If you=20 really think that makes it more clear, we can ask that = the
rewritten=20 text appear in the IG.
 
Brian
 
-----Original Message-----
From: Sarju Garg=20 [mailto:sarju@bhartitelesoft.com]
Sent: Wednesday, June = 20, 2001=20 9:55 AM
To: Rosen, Brian; 'megaco'
Subject: Re: = Property=20 Characteristics

But it is pretty confusing in the = document. In=20 Section 12.1.2 it says. Indicates whether a property is read-only or = read-write and if it is global. Also Sec 6.2.4 says that the = property mat be=20 read-only or read/write. No mention of write in these = cases.
Can we specify an unambiguous line = in the=20 document?. I feel there should be no convention in the standards. = Everything=20 should be specified explicitly whereever possible.
 
Sarju
 
----- Original Message ----- =
From:=20 Rosen, Brian
To: 'Sarju Garg' ; 'megaco'
Sent: Wednesday, June 20, = 2001 6:50=20 PM
Subject: RE: Property=20 Characteristics

Global=20 and read/write are independent; you can have any=20 combination.
 
Packages should define the values.  If they = don't, there=20 is no default, and
it's=20 implementation dependent - a bad idea.  I do believe the=20 current
convention is that if you don't say Global, then it's = "local".
 
Brian
-----Original Message-----
From: Sarju Garg = [mailto:sarju@bhartitelesoft.com<= /A>]
Sent:=20 Wednesday, June 20, 2001 9:20 AM
To:=20 'megaco'
Subject: Property=20 Characteristics

Hi all,
 
I have a question pertaining to = property=20 characteristics. What I understand is that the characteristics = of=20 property is one of the following:
read and local
read/write and = local
read/write and = global
read and global
 
Is write and local and write = and global=20 characteristics is also possible as Sec 12.1.2 says = Characteristics:=20 Read/Write or both and (optionally global)?
 
What is=20 the default characteristics of the property as none of = the=20 package define the characteristics?
 
TIA
Sarju 
<= /BLOCKQUOTE> ------=_NextPart_000_0033_01C0FA73.0BD89420-- From owner-megaco@fore.com Thu Jun 21 09:02:47 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA26729 for ; Thu, 21 Jun 2001 09:02:47 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA24929; Thu, 21 Jun 2001 08:52:19 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id IAA16529 for megaco-list; Thu, 21 Jun 2001 08:50:37 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA16509 for ; Thu, 21 Jun 2001 08:50:34 -0400 (EDT) Received: from mail.bhartitelesoft.com ([202.56.229.147]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA24726 for ; Thu, 21 Jun 2001 08:50:25 -0400 (EDT) Received: from sarju (taquila [202.56.229.146]) by mail.bhartitelesoft.com (8.11.0/8.11.0) with SMTP id f5LClcF27655 for ; Thu, 21 Jun 2001 18:17:39 +0530 Message-ID: <004901c0fa51$4e3ba2c0$240310ac@bhartitelesoft.com> Reply-To: "Sarju Garg" From: "Sarju Garg" To: "'megaco'" Subject: Allowed char set for Identifier Date: Thu, 21 Jun 2001 18:24:22 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0046_01C0FA7F.6509B720" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0046_01C0FA7F.6509B720 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, I have a confusion in the allowed char set for Identifiers. In Sec 12.4, = it says the following:=20 Identifiers in text encoding shall be strings of up to 64 characters, = containing no spaces, starting with an alphanumeric character and = consisting of alphanumeric characters and / or digits, and possibly = including the special character underscore ("_"). Shouldn't be alphanumeric be alphabet here?=20 Or if the above statement is true, then there should be no digits = mentioned here. The text should be like: Identifiers in text encoding shall be strings of up to 64 characters, = containing no spaces, starting with an alphanumeric character and = consisting of alphanumeric characters, and possibly including the = special character underscore ("_"). TIA Sarju ------=_NextPart_000_0046_01C0FA7F.6509B720 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi all,
 
I have a confusion in the allowed char = set for=20 Identifiers. In Sec 12.4, it says the following:
Identifiers=20 in text encoding shall be strings of up to 64 characters, containing no = spaces,=20 starting with an alphanumeric character and consisting of alphanumeric=20 characters and / or digits, and possibly including the special character = underscore ("_").
 
Shouldn't be alphanumeric be alphabet here?
 
Or if the above statement is true, then there should be no digits = mentioned=20 here. The text should be like:
Identifiers=20 in text encoding shall be strings of up to 64 characters, containing no = spaces,=20 starting with an alphanumeric character and consisting of alphanumeric=20 characters, and possibly including the special character underscore=20 ("_").
 
TIA
Sarju
------=_NextPart_000_0046_01C0FA7F.6509B720-- From owner-megaco@fore.com Thu Jun 21 09:50:07 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA28877 for ; Thu, 21 Jun 2001 09:50:06 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA29512; Thu, 21 Jun 2001 09:41:00 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id JAA00393 for megaco-list; Thu, 21 Jun 2001 09:39:40 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA00387 for ; Thu, 21 Jun 2001 09:39:39 -0400 (EDT) Received: from huginn.ctccom.net (Huginn.CTCCom.net [207.190.194.11]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA29264 for ; Thu, 21 Jun 2001 09:39:33 -0400 (EDT) Received: from MBRAHMANAPALLY ([64.69.123.121]) by huginn.ctccom.net (Mirapoint) with SMTP id ACZ49972; Thu, 21 Jun 2001 09:39:12 -0400 (EDT) From: "Madhu Babu Brahmanapally" To: "'suryapratap vamsi'" , , Subject: RE: UDP/TCP Default ports. Date: Thu, 21 Jun 2001 09:40:42 -0400 Message-ID: <016301c0fa57$c4b0e540$c500a8c0@MBRAHMANAPALLY> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <20010620221412.22701.qmail@nwcst333.netaddress.usa.net> Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: 7bit Hi Surya/All, IMO the MG should be provisioned to send requests to specifics MGCs. Similarly MGCs also will accept requests from specifics MGs. If a given MGC is going to control a MG then both should have some provisioned information about the existence of the other including the transport protocol they use. IMHO this is not a big problem and protocol shouldn't insist usage of any specific transport protocol for initial ServiceChange. Regards Madhubabu -----Original Message----- From: owner-megaco@pit.comms.marconi.com [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of suryapratap vamsi Sent: Wednesday, June 20, 2001 6:14 PM To: plong@ipdialog.com; megaco@fore.com Subject: RE: UDP/TCP Default ports. Hello Paul, I framed the question incorrectly. Let me rephrase it again. The MGC should support both TCP and UDP, and MG can either support TCP or UDP or both. Assuming MGC is created two udp listen sockets( 2944 for text, 2945 for binary), and MG is trying to establish communication with TCP, it's connection will get refused. So, there should be someway of specifing in the RFC that, the GW should try to send the initial SvcChangeRequest with UDP transport or otherwise or on TCP transport. Thanks Surya -----Original Message----- From: Paul Long [mailto:plong@ipdialog.com] Sent: Wednesday, June 20, 2001 5:16 PM To: megaco@fore.com Subject: RE: UDP/TCP Default ports. The TCP port space is distinct from the UDP port space. Paul Long ipDialog, Inc. -----Original Message----- From: owner-megaco@pit.comms.marconi.com [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of suryapratap vamsi Sent: Wednesday, June 20, 2001 3:54 PM To: megaco@fore.com Subject: UDP/TCP Default ports. Hello All, section 9.Transport says "If TCP or UDP is used as the protocol transport and the port to which the initial ServiceChange request is to be sent is not otherwise known, that request should be sent to the default port number for the protocol. This port number is 2944 for text-encoded operation or 2945 for binary-encoded operation, for either UDP or TCP." Since the protocol says MGC should support both UDP and TCP, how does MGC binds for the same port for both TCP as well UDP transport ?. This is a pure provisional/configuration issue or Is there a otherway to deal with this problem ? Please clarify this . Surya ____________________________________________________________________ Get free email and a permanent address at http://www.netaddress.com/?N=1 From owner-megaco@fore.com Thu Jun 21 10:03:56 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29289 for ; Thu, 21 Jun 2001 10:03:56 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA00960; Thu, 21 Jun 2001 09:53:42 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id JAA04049 for megaco-list; Thu, 21 Jun 2001 09:52:00 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA04040 for ; Thu, 21 Jun 2001 09:51:58 -0400 (EDT) Received: from huginn.ctccom.net (Huginn.CTCCom.net [207.190.194.11]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA00635 for ; Thu, 21 Jun 2001 09:51:54 -0400 (EDT) Received: from MBRAHMANAPALLY ([64.69.123.121]) by huginn.ctccom.net (Mirapoint) with SMTP id ACZ50235; Thu, 21 Jun 2001 09:51:51 -0400 (EDT) From: "Madhu Babu Brahmanapally" To: "'Kaul, Bharat'" , Subject: RE: ISDN Terminated at MG and Packages Required Date: Thu, 21 Jun 2001 09:53:21 -0400 Message-ID: <016e01c0fa59$892c9e90$c500a8c0@MBRAHMANAPALLY> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: 7bit Hi Bharat, Sorry I didn't get your query. What do you expect? Is the IUA defined by SIGTRAN not enough ?? Regards Madhubabu -----Original Message----- From: owner-megaco@pit.comms.marconi.com [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Kaul, Bharat Sent: Wednesday, June 20, 2001 6:54 PM To: 'megaco@fore.com' Subject: ISDN Terminated at MG and Packages Required Can someone clarify following for me :) > If ISDN is terminated to MG, which package is necessary for ISDN bearer > capability and call connection? Is basic package sufficient or do we need > additional packages ? > > - Bharat > > From owner-megaco@fore.com Thu Jun 21 10:03:57 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29296 for ; Thu, 21 Jun 2001 10:03:56 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA00903; Thu, 21 Jun 2001 09:53:25 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id JAA03777 for megaco-list; Thu, 21 Jun 2001 09:51:36 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA03739 for ; Thu, 21 Jun 2001 09:51:16 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 21 Jun 2001 09:51:11 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF044655B7@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'PSK Chakravarthi'" , "'Madhu Babu Brahmanapally'" , "'Terry L Anderson'" Cc: megaco@fore.com Subject: RE: Ephemeral Termination Date: Thu, 21 Jun 2001 09:51:11 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk There is no way this will reduce call setup time. Since you do not have the destination information, you will have to MODIFY the ephemeral when you do. The processing time for the Modify won't be substantially more than doing an Add at that point, and there is no difference to the actual operation of the gateway. Brian > -----Original Message----- > From: PSK Chakravarthi [mailto:chak@axes-mach01.usa.alcatel.com] > Sent: Thursday, June 21, 2001 1:43 AM > To: Rosen, Brian; 'Madhu Babu Brahmanapally'; 'Terry L Anderson' > Cc: megaco@fore.com > Subject: Re: Ephemeral Termination > > > The reason for creating Ephemeral and reserving SDP before knowing the > termination is > to reduce the call setup time. > > thanks & regards > Chak > ----- Original Message ----- > From: "Rosen, Brian" > To: "'Madhu Babu Brahmanapally'" ; > "'Terry L Anderson'" > ; "'PSK Chakravarthi'" > > Cc: > Sent: Wednesday, June 20, 2001 9:07 PM > Subject: RE: Ephemeral Termination > > > > I'm not at all sure what "resources" you can reserve before you > > know the destination: > > > > For an IP network, you can reserve a UDP port I suppose, but until > > you negotiate the SDP, you can't reserve bandwidth. You can't > > make any QoS reservation for the same reason. > > > > It's worse on an ATM network. > > > > I think there is nothing to be gained by #1 > > > > Brian > > > > > -----Original Message----- > > > From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com] > > > Sent: Wednesday, June 20, 2001 11:28 AM > > > To: 'Terry L Anderson'; 'PSK Chakravarthi' > > > Cc: megaco@fore.com > > > Subject: RE: Ephemeral Termination > > > > > > > > > Hi All, > > > The creation of ephemeral termination can be done either > after digit > > > analysis or before it. Each has its own advantages and > disadvantages. > > > > > > 1) If Ephemeral termination is created before digit analysis, > > > situation may > > > occur where the destination user/termination is connected to > > > the same MG and > > > there is no need to create an ephemeral termination (as PSK > > > mentioned). But > > > this has the advantage that the call wont be dropped due > to lack of > > > resource, as ephemeral resources are pre-reserved at the MG. > > > (in case Add > > > fails later to add ephemeral termination). > > > > > > 2) If Ephemeral termination is created after digit analysis, > > > it takes care > > > of all situation where destination user may/may not connected > > > to the same > > > MG. But when Ephemeral termination is added later, there is no > > > pre-reservation of the ephemeral resources at the origination MG. > > > > > > In case of 1) if the call doesn't mature, reserving the > > > resources doesn't > > > gain anything. Consideration that the destination user on the > > > same MG is > > > less probable, Method 2 IMO will be a better choice. > > > > > > Regards > > > Madhubabu > > > > > > -----Original Message----- > > > From: owner-megaco@pit.comms.marconi.com > > > [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Terry > > > L Anderson > > > Sent: Wednesday, June 20, 2001 11:01 AM > > > To: PSK Chakravarthi > > > Cc: megaco@fore.com > > > Subject: Re: Ephemeral Termination > > > > > > > > > > > > > > > PSK Chakravarthi wrote: > > > > > > > I have got the following doubt. > > > > If the originating and terminating termination IDs are on > > > the same gateway > > > and > > > > gateway supports two TDM terminations in a context, is it > > > required to > > > craete a > > > > ephenmeral termination for this call? > > > > > > > > Message flow between MGC and MG: > > > > > > > > 1. MGC send ADD command to originating MG > > > > a) Choose a context ID > > > > b) Add a TDM termination > > > > c) Choose a Ephemeral termination > > > > d) Reserve Local Descriptor > > > > e) set MODE to Receive only. > > > > > > > > 2. MGC now finds that call is terminating on the same MG. > > > Also MGC knows > > > that > > > > MG is capable of adding two TDMs to the same context. At > > > this point what > > > should > > > > be the command to the MG? > > > > Is it required to SUBTRACT the ephemeral termination and > > > send ADD for > > > adding new > > > > TDM to the same context? or > > > > Simply sending ADD for new TDM to the same context is > sufficient? > > > > > > It would be better if MGC "finds" that the call is terminated > > > on the same MG > > > before > > > sending the ADD, in step 1c, but if since step c (which you > > > call "Choose a > > > Ephemeral > > > termination) is an Add with wildcard, MGC must certainly > > > Subtract it if it > > > chooses > > > later not to use it. The Subtract deletes the ephemeral > > > termination and > > > releases > > > its resources. > > > > > > > thanks & regards > > > > Chak > > > > > > -- > > > ------------------------------------------------------------ > > > Terry L Anderson mailto:tla@lucent.com > > > Tel:908.582.7013 Fax:908.582.6729 > > > Lucent Technologies/INS/Voice Over IP Access Networks > > > Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 > > > http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla > > > > > From owner-megaco@fore.com Thu Jun 21 10:05:53 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29408 for ; Thu, 21 Jun 2001 10:05:52 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA01315; Thu, 21 Jun 2001 09:55:29 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id JAA04686 for megaco-list; Thu, 21 Jun 2001 09:53:40 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA04679 for ; Thu, 21 Jun 2001 09:53:38 -0400 (EDT) Received: from huginn.ctccom.net (Huginn.CTCCom.net [207.190.194.11]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA00927 for ; Thu, 21 Jun 2001 09:53:32 -0400 (EDT) Received: from MBRAHMANAPALLY ([64.69.123.121]) by huginn.ctccom.net (Mirapoint) with SMTP id ACZ50244; Thu, 21 Jun 2001 09:52:21 -0400 (EDT) From: "Madhu Babu Brahmanapally" To: "'Nitin Kumar'" , "'Terry L Anderson'" , "'Rosen, Brian'" Cc: Subject: RE: Few clarification in RFC3015 Date: Thu, 21 Jun 2001 09:53:51 -0400 Message-ID: <016f01c0fa59$9ad641a0$c500a8c0@MBRAHMANAPALLY> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: 7bit Hi Nitin, In the example you considered Action1 Action2 and Action3 are clubbed in a single command as there is some dependency between the three contexts. If there is none then they don't qualify to be clubbed in a single transaction. They may be part of single message with different transaction Ids. But once clubbed (due to whatever reasons) the execution of the actions and commands within should be in order. -Regards Madhubabu -----Original Message----- From: owner-megaco@pit.comms.marconi.com [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Nitin Kumar Sent: Thursday, June 21, 2001 1:51 AM To: 'Terry L Anderson'; Rosen, Brian Cc: 'megaco@fore.com' Subject: RE: Few clarification in RFC3015 ok... thats what even i thought.. now if actions in a transaction are processed in sequence then consider following scenario TransactionRequest { Action1 { command1 command2 } Action2 { command1 command2 command3 } Action3 { command1 command2 } } Suppose all commands are manatory. Lets assume command2 in Action2 generates some error or is not processed successfully then does it mean that command3 of Action2 as well as any further action i.e. Action3 will not be executed? If yes, then my doubt is: when every Action is concerned with different Context.. then why failure of one command in one Action should bother other Action with in the same transaction? We should be able to process every Action sequentially and independently. regards, -nitin -----Original Message----- From: Terry L Anderson [mailto:tla@lucent.com] Sent: Thursday, June 21, 2001 3:23 AM To: Rosen, Brian Cc: 'Nitin Kumar'; 'megaco@fore.com' Subject: Re: Few clarification in RFC3015 "Rosen, Brian" wrote: > Hmmm, maybe we should edit that text to say: > "Actions in a transaction and commands within an action are > executed sequentially in the order they appear in the transaction." > > Terry? That is certainly the intent and the way I would read the current text ("commands in order" - the fact that they are grouped into actions doesn't alter their order). But your text is certainly more explicit. I have no trouble with it. I'll put it in. > > > "Normal Repitition timers" are the timer values defined in D.1.3 > > Brian > > > -----Original Message----- > > From: Nitin Kumar [mailto:nitin@indts.com] > > Sent: Wednesday, June 20, 2001 2:32 PM > > To: 'megaco@fore.com' > > Subject: Few clarification in RFC3015 > > > > > > Hi Folks, > > > > Just looking for following clarification. > > > > 1. In a TransactionRequest, are ActionRequests processed in > > order or only > > Commands in an ActionRequest are executed sequencially ? RFC > > says "Commands > > within a Transaction are executed sequentially." > > > > 2. Few lines from the RFC on page number 135, section D.1.4.. > > "Upon receipt of a final response following receipt of > > provisional responses, an immediate confirmation shall be sent, and > > normal repetition timers shall be used thereafter." > > > > Now what does "normal repetition timers shall be used > > thereafter" mean in > > above extract? > > > > i hope to receive some insights. > > > > regards, > > > > -nitin > > > > Ind Telesoft Pvt. Ltd. > > 104, Koramangla Industrial Estate, > > 5th Block, Bangalore 560 095 > > Tel : 5508930, 5521937, 5529758-62 ext-259 > > Fax : 5521164 > > mailto:nitin@indts.com > > http:\\www.telesoftinc.com > > -- ------------------------------------------------------------ Terry L Anderson mailto:tla@lucent.com Tel:908.582.7013 Fax:908.582.6729 Lucent Technologies/INS/Voice Over IP Access Networks Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla From owner-megaco@fore.com Thu Jun 21 10:07:26 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29476 for ; Thu, 21 Jun 2001 10:07:25 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA01846; Thu, 21 Jun 2001 09:58:23 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id JAA05168 for megaco-list; Thu, 21 Jun 2001 09:55:51 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA05154 for ; Thu, 21 Jun 2001 09:55:47 -0400 (EDT) Received: from huginn.ctccom.net (Huginn.CTCCom.net [207.190.194.11]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA01346 for ; Thu, 21 Jun 2001 09:55:39 -0400 (EDT) Received: from MBRAHMANAPALLY ([64.69.123.121]) by huginn.ctccom.net (Mirapoint) with SMTP id ACZ50282; Thu, 21 Jun 2001 09:54:37 -0400 (EDT) From: "Madhu Babu Brahmanapally" To: "'Sarju Garg'" , "'megaco'" Subject: RE: How to Determine the Termination Type Date: Thu, 21 Jun 2001 09:56:07 -0400 Message-ID: <017001c0fa59$ebf7e8e0$c500a8c0@MBRAHMANAPALLY> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0171_01C0FA38.64E648E0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <002e01c0fa33$739514c0$240310ac@bhartitelesoft.com> Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0171_01C0FA38.64E648E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit HI Sarju, You are right. The logic of type of termination is derived from the descriptors. A long chain of mails were exchanged on this topic. The archive of the mails may help you. -Regards Madhubabu -----Original Message----- From: owner-megaco@pit.comms.marconi.com [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Sarju Garg Sent: Thursday, June 21, 2001 4:53 AM To: 'megaco' Subject: How to Determine the Termination Type Hi all, Suppose MG application supports RTP, PSTN termination. The termination are allocated by the MG application for a call? So the ADD command specify $ for the termination name so that MG can allocate a termination and return it to MGC application. How does the MG application come to know that receiving an ADD command is for which type of termination - for RTP termination or PSTN termination? I believe Local/Remote descriptors are required for RTP terminations. So can Local/Remote descriptor be used for this purpose? TIA Sarju ------=_NextPart_000_0171_01C0FA38.64E648E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
HI=20 Sarju,
You=20 are right. The logic of type of termination is derived from the = descriptors. A=20 long chain of mails were exchanged on this topic. The archive of the = mails may=20 help you.
 
-Regards
Madhubabu
-----Original Message-----
From:=20 owner-megaco@pit.comms.marconi.com=20 [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Sarju=20 Garg
Sent: Thursday, June 21, 2001 4:53 AM
To:=20 'megaco'
Subject: How to Determine the Termination=20 Type

 
Hi all,
 
Suppose MG application supports RTP, = PSTN=20 termination. The termination are allocated by the MG application for a = call?=20 So the ADD command specify $ for the termination name so that MG can = allocate=20 a termination  and return it to MGC application. How does the MG=20 application come to know that receiving an ADD command is for which = type of=20 termination - for RTP termination or PSTN termination? I believe = Local/Remote=20 descriptors are required for RTP terminations. So can Local/Remote = descriptor=20 be used for this purpose?
 
TIA
Sarju
 
------=_NextPart_000_0171_01C0FA38.64E648E0-- From owner-megaco@fore.com Thu Jun 21 10:07:27 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29491 for ; Thu, 21 Jun 2001 10:07:27 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA01512; Thu, 21 Jun 2001 09:56:33 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id JAA04923 for megaco-list; Thu, 21 Jun 2001 09:54:49 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA04904 for ; Thu, 21 Jun 2001 09:54:48 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 21 Jun 2001 09:54:44 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF044655B8@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Nitin Kumar'" , "'Terry L Anderson'" Cc: "'megaco@fore.com'" Subject: RE: Few clarification in RFC3015 Date: Thu, 21 Jun 2001 09:54:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk The Transaction is the unit of control here, not the action. If you want to execute the other actions if there is an error, put them in separate transactions. Just because there are different contexts does not necessarily mean you want the actions to proceed. If you do, use the optional command. Anyway, we probably wouldn't change the protocol in this way at this point - it would be non-backwards compatible. Brian > -----Original Message----- > From: Nitin Kumar [mailto:nitin@indts.com] > Sent: Thursday, June 21, 2001 1:51 AM > To: 'Terry L Anderson'; Rosen, Brian > Cc: 'megaco@fore.com' > Subject: RE: Few clarification in RFC3015 > > > ok... > thats what even i thought.. > now if actions in a transaction are processed in sequence > then consider > following scenario > > TransactionRequest > { > Action1 > { > command1 > command2 > } > Action2 > { > command1 > command2 > command3 > } > Action3 > { > command1 > command2 > } > } > > Suppose all commands are manatory. Lets assume command2 in > Action2 generates > some error or is not processed successfully then > does it mean that command3 of Action2 as well as any further > action i.e. > Action3 will not be executed? > > If yes, then my doubt is: when every Action is concerned with > different > Context.. then why failure of one command in one Action > should bother other > Action with in the same transaction? > > We should be able to process every Action sequentially and > independently. > > regards, > > -nitin > > > > -----Original Message----- > From: Terry L Anderson [mailto:tla@lucent.com] > Sent: Thursday, June 21, 2001 3:23 AM > To: Rosen, Brian > Cc: 'Nitin Kumar'; 'megaco@fore.com' > Subject: Re: Few clarification in RFC3015 > > > > > "Rosen, Brian" wrote: > > > Hmmm, maybe we should edit that text to say: > > "Actions in a transaction and commands within an action are > > executed sequentially in the order they appear in the transaction." > > > > Terry? > > That is certainly the intent and the way I would read the current text > ("commands in order" - the fact that they are grouped into > actions doesn't > alter their order). But your text is certainly more > explicit. I have no > trouble with it. I'll put it in. > > > > > > > "Normal Repitition timers" are the timer values defined in D.1.3 > > > > Brian > > > > > -----Original Message----- > > > From: Nitin Kumar [mailto:nitin@indts.com] > > > Sent: Wednesday, June 20, 2001 2:32 PM > > > To: 'megaco@fore.com' > > > Subject: Few clarification in RFC3015 > > > > > > > > > Hi Folks, > > > > > > Just looking for following clarification. > > > > > > 1. In a TransactionRequest, are ActionRequests processed in > > > order or only > > > Commands in an ActionRequest are executed sequencially ? RFC > > > says "Commands > > > within a Transaction are executed sequentially." > > > > > > 2. Few lines from the RFC on page number 135, section D.1.4.. > > > "Upon receipt of a final response following receipt of > > > provisional responses, an immediate confirmation shall > be sent, and > > > normal repetition timers shall be used thereafter." > > > > > > Now what does "normal repetition timers shall be used > > > thereafter" mean in > > > above extract? > > > > > > i hope to receive some insights. > > > > > > regards, > > > > > > -nitin > > > > > > Ind Telesoft Pvt. Ltd. > > > 104, Koramangla Industrial Estate, > > > 5th Block, Bangalore 560 095 > > > Tel : 5508930, 5521937, 5529758-62 ext-259 > > > Fax : 5521164 > > > mailto:nitin@indts.com > > > http:\\www.telesoftinc.com > > > > > -- > ------------------------------------------------------------ > Terry L Anderson mailto:tla@lucent.com > Tel:908.582.7013 Fax:908.582.6729 > Lucent Technologies/INS/Voice Over IP Access Networks > Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 > http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla > From owner-megaco@fore.com Thu Jun 21 10:17:16 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29789 for ; Thu, 21 Jun 2001 10:17:15 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA02737; Thu, 21 Jun 2001 10:06:57 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA08144 for megaco-list; Thu, 21 Jun 2001 10:06:05 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA08137 for ; Thu, 21 Jun 2001 10:06:03 -0400 (EDT) Received: from netmail.alcatel.com (netmail.alcatel.com [128.251.168.50]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA02601 for ; Thu, 21 Jun 2001 10:05:58 -0400 (EDT) Received: from auds951.usa.alcatel.com (auds951.usa.alcatel.com [143.209.238.80]) by netmail.alcatel.com (8.9.1/8.9.1) with ESMTP id JAA27089; Thu, 21 Jun 2001 09:05:08 -0500 (CDT) Received: from axes-mach01.axes-mach01.usa.alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f5LE51p26159; Thu, 21 Jun 2001 09:05:02 -0500 (CDT) Received: from Chak by axes-mach01.axes-mach01.usa.alcatel.com (8.9.1b+Sun/SMI-SVR4) id TAA02802; Thu, 21 Jun 2001 19:31:04 -0500 (GMT) Message-ID: <015701c0fa5b$e0fb08d0$2f09ca82@Chak> From: "PSK Chakravarthi" To: "Rosen, Brian" , "'Madhu Babu Brahmanapally'" , "'Terry L Anderson'" Cc: References: <4FBEA8857476D311A03300204840E1CF044655B7@whq-msgusr-02.pit.comms.marconi.com> Subject: Re: Ephemeral Termination Date: Thu, 21 Jun 2001 19:40:07 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: 7bit The reason for creating Ephemeral and reserving SDP before knowing the termination is to reduce the call setup time. Following is the MGC processing. 1. Soon after receiving IAM send ADD command to the originating MG for a)Creating Ephemeral b)Reserving SDP for Local c)Simultaneously start digit analysis After finding termination (By this time ADD response would have been received, if not MGC need to wait for ADD response) If terminating trunk belongs to the same MG a) send ADD command to add the second termination to the same context. This ADD command will have empty Local descriptor to release resources previously allocated. Note that ephemeral is not SUBTRACTED. Also MODIFY to originating MG is not required as MG is going to make only hairpin connection. If the terminating MG is not same as originating MG Send ADD command to terminating MG a) Creating Ephemeral b) Reserving SDP for Local c) Setting SDP remote as Local returned by the originating MG. After receiving the ADD response from terminating MG Send MODIFY to originating MG for setting remote Descriptor. If you send ADD command to the originating MG only after knowing the terminator, MGC had completed processing of the call but now it need to wait for sending three commands (ADD to originating MG, ADD to terminating MG and MODIFY to originating MG) and their responses. Take the case of trunking gateway, where the number of calls originating on a MG and terminating on the same MG are much less than calls originated and terminated on two different MGs. thanks & regards Chak ----- Original Message ----- From: "Rosen, Brian" To: "'PSK Chakravarthi'" ; "'Madhu Babu Brahmanapally'" ; "'Terry L Anderson'" Cc: Sent: Thursday, June 21, 2001 7:21 PM Subject: RE: Ephemeral Termination > There is no way this will reduce call setup time. > Since you do not have the destination information, you > will have to MODIFY the ephemeral when you do. The processing > time for the Modify won't be substantially more than doing > an Add at that point, and there is no difference to the actual > operation of the gateway. > > Brian > > > -----Original Message----- > > From: PSK Chakravarthi [mailto:chak@axes-mach01.usa.alcatel.com] > > Sent: Thursday, June 21, 2001 1:43 AM > > To: Rosen, Brian; 'Madhu Babu Brahmanapally'; 'Terry L Anderson' > > Cc: megaco@fore.com > > Subject: Re: Ephemeral Termination > > > > > > The reason for creating Ephemeral and reserving SDP before knowing the > > termination is > > to reduce the call setup time. > > > > thanks & regards > > Chak > > ----- Original Message ----- > > From: "Rosen, Brian" > > To: "'Madhu Babu Brahmanapally'" ; > > "'Terry L Anderson'" > > ; "'PSK Chakravarthi'" > > > > Cc: > > Sent: Wednesday, June 20, 2001 9:07 PM > > Subject: RE: Ephemeral Termination > > > > > > > I'm not at all sure what "resources" you can reserve before you > > > know the destination: > > > > > > For an IP network, you can reserve a UDP port I suppose, but until > > > you negotiate the SDP, you can't reserve bandwidth. You can't > > > make any QoS reservation for the same reason. > > > > > > It's worse on an ATM network. > > > > > > I think there is nothing to be gained by #1 > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com] > > > > Sent: Wednesday, June 20, 2001 11:28 AM > > > > To: 'Terry L Anderson'; 'PSK Chakravarthi' > > > > Cc: megaco@fore.com > > > > Subject: RE: Ephemeral Termination > > > > > > > > > > > > Hi All, > > > > The creation of ephemeral termination can be done either > > after digit > > > > analysis or before it. Each has its own advantages and > > disadvantages. > > > > > > > > 1) If Ephemeral termination is created before digit analysis, > > > > situation may > > > > occur where the destination user/termination is connected to > > > > the same MG and > > > > there is no need to create an ephemeral termination (as PSK > > > > mentioned). But > > > > this has the advantage that the call wont be dropped due > > to lack of > > > > resource, as ephemeral resources are pre-reserved at the MG. > > > > (in case Add > > > > fails later to add ephemeral termination). > > > > > > > > 2) If Ephemeral termination is created after digit analysis, > > > > it takes care > > > > of all situation where destination user may/may not connected > > > > to the same > > > > MG. But when Ephemeral termination is added later, there is no > > > > pre-reservation of the ephemeral resources at the origination MG. > > > > > > > > In case of 1) if the call doesn't mature, reserving the > > > > resources doesn't > > > > gain anything. Consideration that the destination user on the > > > > same MG is > > > > less probable, Method 2 IMO will be a better choice. > > > > > > > > Regards > > > > Madhubabu > > > > > > > > -----Original Message----- > > > > From: owner-megaco@pit.comms.marconi.com > > > > [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Terry > > > > L Anderson > > > > Sent: Wednesday, June 20, 2001 11:01 AM > > > > To: PSK Chakravarthi > > > > Cc: megaco@fore.com > > > > Subject: Re: Ephemeral Termination > > > > > > > > > > > > > > > > > > > > PSK Chakravarthi wrote: > > > > > > > > > I have got the following doubt. > > > > > If the originating and terminating termination IDs are on > > > > the same gateway > > > > and > > > > > gateway supports two TDM terminations in a context, is it > > > > required to > > > > craete a > > > > > ephenmeral termination for this call? > > > > > > > > > > Message flow between MGC and MG: > > > > > > > > > > 1. MGC send ADD command to originating MG > > > > > a) Choose a context ID > > > > > b) Add a TDM termination > > > > > c) Choose a Ephemeral termination > > > > > d) Reserve Local Descriptor > > > > > e) set MODE to Receive only. > > > > > > > > > > 2. MGC now finds that call is terminating on the same MG. > > > > Also MGC knows > > > > that > > > > > MG is capable of adding two TDMs to the same context. At > > > > this point what > > > > should > > > > > be the command to the MG? > > > > > Is it required to SUBTRACT the ephemeral termination and > > > > send ADD for > > > > adding new > > > > > TDM to the same context? or > > > > > Simply sending ADD for new TDM to the same context is > > sufficient? > > > > > > > > It would be better if MGC "finds" that the call is terminated > > > > on the same MG > > > > before > > > > sending the ADD, in step 1c, but if since step c (which you > > > > call "Choose a > > > > Ephemeral > > > > termination) is an Add with wildcard, MGC must certainly > > > > Subtract it if it > > > > chooses > > > > later not to use it. The Subtract deletes the ephemeral > > > > termination and > > > > releases > > > > its resources. > > > > > > > > > thanks & regards > > > > > Chak > > > > > > > > -- > > > > ------------------------------------------------------------ > > > > Terry L Anderson mailto:tla@lucent.com > > > > Tel:908.582.7013 Fax:908.582.6729 > > > > Lucent Technologies/INS/Voice Over IP Access Networks > > > > Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 > > > > http://its.lucent.com/~tla (Lucent internal) > http://www.gti.net/tla > > > > > > > > > From owner-megaco@fore.com Thu Jun 21 10:39:37 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA00644 for ; Thu, 21 Jun 2001 10:39:36 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA04689; Thu, 21 Jun 2001 10:26:15 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA13949 for megaco-list; Thu, 21 Jun 2001 10:24:51 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA13938 for ; Thu, 21 Jun 2001 10:24:49 -0400 (EDT) Received: from netmail.alcatel.com (netmail.alcatel.com [128.251.168.50]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA04513 for ; Thu, 21 Jun 2001 10:24:44 -0400 (EDT) Received: from auds951.usa.alcatel.com (auds951.usa.alcatel.com [143.209.238.80]) by netmail.alcatel.com (8.9.1/8.9.1) with ESMTP id JAA01821 for ; Thu, 21 Jun 2001 09:24:45 -0500 (CDT) Received: from ssd.usa.alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f5LEOjp00663 for ; Thu, 21 Jun 2001 09:24:45 -0500 (CDT) Received: from sun3144.ssd.usa.alcatel.com (sun3144.ssd.usa.alcatel.com [143.209.151.53]) by ssd.usa.alcatel.com (8.11.1/8.11.1) with ESMTP id f5LEOG100528 for ; Thu, 21 Jun 2001 09:24:16 -0500 (CDT) Received: from usa.alcatel.com (localhost [127.0.0.1]) by sun3144.ssd.usa.alcatel.com (8.11.1/8.11.1) with ESMTP id f5LEOGW24510 for ; Thu, 21 Jun 2001 09:24:16 -0500 (CDT) Message-ID: <3B320390.22B96C2A@usa.alcatel.com> Date: Thu, 21 Jun 2001 09:24:16 -0500 From: Chuong Nguyen X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: megaco@fore.com Subject: Re: Ephemeral Termination References: <4FBEA8857476D311A03300204840E1CF044655B7@whq-msgusr-02.pit.comms.marconi.com> <015701c0fa5b$e0fb08d0$2f09ca82@Chak> Content-Type: multipart/alternative; boundary="------------E6E2AAB0FC04069E05E1885B" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk --------------E6E2AAB0FC04069E05E1885B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I am a bit lost as to where this discussion is leading to. Is a Megaco Standard change requested here or just a discussion on a particular prefer implementation? Chuong PSK Chakravarthi wrote: > The reason for creating Ephemeral and reserving SDP before knowing the > termination is to reduce the call setup time. > > Following is the MGC processing. > > 1. Soon after receiving IAM send ADD command to the originating MG for > a)Creating Ephemeral > b)Reserving SDP for Local > c)Simultaneously start digit analysis > After finding termination > (By this time ADD response would have been received, if not MGC need to wait for > ADD response) > If terminating trunk belongs to the same MG > a) send ADD command to add the second termination to the same context. > This ADD command will have empty Local descriptor to release resources > previously allocated. > Note that ephemeral is not SUBTRACTED. Also MODIFY to originating MG is > not required as MG is going to make only hairpin connection. > If the terminating MG is not same as originating MG > Send ADD command to terminating MG > a) Creating Ephemeral > b) Reserving SDP for Local > c) Setting SDP remote as Local returned by the originating MG. > After receiving the ADD response from terminating MG > Send MODIFY to originating MG for setting remote Descriptor. > > If you send ADD command to the originating MG only after knowing the terminator, > MGC had completed processing of the call but now it need to wait for sending > three commands > (ADD to originating MG, ADD to terminating MG and MODIFY to originating MG) and > their responses. > > Take the case of trunking gateway, where the number of calls originating on a MG > and terminating on the same MG are much less than calls originated and > terminated on two different MGs. > > thanks & regards > Chak > > ----- Original Message ----- > From: "Rosen, Brian" > To: "'PSK Chakravarthi'" ; "'Madhu Babu > Brahmanapally'" ; "'Terry L Anderson'" > Cc: > Sent: Thursday, June 21, 2001 7:21 PM > Subject: RE: Ephemeral Termination > > > There is no way this will reduce call setup time. > > Since you do not have the destination information, you > > will have to MODIFY the ephemeral when you do. The processing > > time for the Modify won't be substantially more than doing > > an Add at that point, and there is no difference to the actual > > operation of the gateway. > > > > Brian > > > > > -----Original Message----- > > > From: PSK Chakravarthi [mailto:chak@axes-mach01.usa.alcatel.com] > > > Sent: Thursday, June 21, 2001 1:43 AM > > > To: Rosen, Brian; 'Madhu Babu Brahmanapally'; 'Terry L Anderson' > > > Cc: megaco@fore.com > > > Subject: Re: Ephemeral Termination > > > > > > > > > The reason for creating Ephemeral and reserving SDP before knowing the > > > termination is > > > to reduce the call setup time. > > > > > > thanks & regards > > > Chak > > > ----- Original Message ----- > > > From: "Rosen, Brian" > > > To: "'Madhu Babu Brahmanapally'" ; > > > "'Terry L Anderson'" > > > ; "'PSK Chakravarthi'" > > > > > > Cc: > > > Sent: Wednesday, June 20, 2001 9:07 PM > > > Subject: RE: Ephemeral Termination > > > > > > > > > > I'm not at all sure what "resources" you can reserve before you > > > > know the destination: > > > > > > > > For an IP network, you can reserve a UDP port I suppose, but until > > > > you negotiate the SDP, you can't reserve bandwidth. You can't > > > > make any QoS reservation for the same reason. > > > > > > > > It's worse on an ATM network. > > > > > > > > I think there is nothing to be gained by #1 > > > > > > > > Brian > > > > > > > > > -----Original Message----- > > > > > From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com] > > > > > Sent: Wednesday, June 20, 2001 11:28 AM > > > > > To: 'Terry L Anderson'; 'PSK Chakravarthi' > > > > > Cc: megaco@fore.com > > > > > Subject: RE: Ephemeral Termination > > > > > > > > > > > > > > > Hi All, > > > > > The creation of ephemeral termination can be done either > > > after digit > > > > > analysis or before it. Each has its own advantages and > > > disadvantages. > > > > > > > > > > 1) If Ephemeral termination is created before digit analysis, > > > > > situation may > > > > > occur where the destination user/termination is connected to > > > > > the same MG and > > > > > there is no need to create an ephemeral termination (as PSK > > > > > mentioned). But > > > > > this has the advantage that the call wont be dropped due > > > to lack of > > > > > resource, as ephemeral resources are pre-reserved at the MG. > > > > > (in case Add > > > > > fails later to add ephemeral termination). > > > > > > > > > > 2) If Ephemeral termination is created after digit analysis, > > > > > it takes care > > > > > of all situation where destination user may/may not connected > > > > > to the same > > > > > MG. But when Ephemeral termination is added later, there is no > > > > > pre-reservation of the ephemeral resources at the origination MG. > > > > > > > > > > In case of 1) if the call doesn't mature, reserving the > > > > > resources doesn't > > > > > gain anything. Consideration that the destination user on the > > > > > same MG is > > > > > less probable, Method 2 IMO will be a better choice. > > > > > > > > > > Regards > > > > > Madhubabu > > > > > > > > > > -----Original Message----- > > > > > From: owner-megaco@pit.comms.marconi.com > > > > > [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Terry > > > > > L Anderson > > > > > Sent: Wednesday, June 20, 2001 11:01 AM > > > > > To: PSK Chakravarthi > > > > > Cc: megaco@fore.com > > > > > Subject: Re: Ephemeral Termination > > > > > > > > > > > > > > > > > > > > > > > > > PSK Chakravarthi wrote: > > > > > > > > > > > I have got the following doubt. > > > > > > If the originating and terminating termination IDs are on > > > > > the same gateway > > > > > and > > > > > > gateway supports two TDM terminations in a context, is it > > > > > required to > > > > > craete a > > > > > > ephenmeral termination for this call? > > > > > > > > > > > > Message flow between MGC and MG: > > > > > > > > > > > > 1. MGC send ADD command to originating MG > > > > > > a) Choose a context ID > > > > > > b) Add a TDM termination > > > > > > c) Choose a Ephemeral termination > > > > > > d) Reserve Local Descriptor > > > > > > e) set MODE to Receive only. > > > > > > > > > > > > 2. MGC now finds that call is terminating on the same MG. > > > > > Also MGC knows > > > > > that > > > > > > MG is capable of adding two TDMs to the same context. At > > > > > this point what > > > > > should > > > > > > be the command to the MG? > > > > > > Is it required to SUBTRACT the ephemeral termination and > > > > > send ADD for > > > > > adding new > > > > > > TDM to the same context? or > > > > > > Simply sending ADD for new TDM to the same context is > > > sufficient? > > > > > > > > > > It would be better if MGC "finds" that the call is terminated > > > > > on the same MG > > > > > before > > > > > sending the ADD, in step 1c, but if since step c (which you > > > > > call "Choose a > > > > > Ephemeral > > > > > termination) is an Add with wildcard, MGC must certainly > > > > > Subtract it if it > > > > > chooses > > > > > later not to use it. The Subtract deletes the ephemeral > > > > > termination and > > > > > releases > > > > > its resources. > > > > > > > > > > > thanks & regards > > > > > > Chak > > > > > > > > > > -- > > > > > ------------------------------------------------------------ > > > > > Terry L Anderson mailto:tla@lucent.com > > > > > Tel:908.582.7013 Fax:908.582.6729 > > > > > Lucent Technologies/INS/Voice Over IP Access Networks > > > > > Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 > > > > > http://its.lucent.com/~tla (Lucent internal) > > http://www.gti.net/tla > > > > > > > > > > > > > -- Alcatel USA, Inc Internet: Chuong.Nguyen@usa.alcatel.com 1000 Coit Road Plano, Texas 75075 Phone: (972) 519-4613 **** The opinions expressed are not those of Alcatel USA, Inc **** --------------E6E2AAB0FC04069E05E1885B Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  
I am a bit lost as to where this discussion is leading to.
Is a Megaco Standard change requested here or just a discussion on
a particular prefer implementation?

Chuong
 

PSK Chakravarthi wrote:

The reason for creating Ephemeral and reserving SDP before knowing the
termination is to reduce the call setup time.

Following is the MGC processing.

1. Soon after receiving IAM send ADD command to the originating MG for
    a)Creating Ephemeral
    b)Reserving SDP for Local
    c)Simultaneously start digit analysis
After finding termination
(By this time ADD response would have been received, if not MGC need to wait for
ADD response)
If terminating trunk belongs to the same MG
   a) send ADD command to add the second termination to the same context.
       This ADD command will have empty Local descriptor to release resources
previously allocated.
       Note that ephemeral is not SUBTRACTED.  Also MODIFY to originating MG is
not required as    MG is going to make only hairpin connection.
If the terminating MG is not same as originating MG
Send ADD command to terminating MG
   a) Creating Ephemeral
   b) Reserving SDP for Local
   c) Setting SDP remote as Local returned by the originating MG.
After receiving the ADD response from terminating MG
Send MODIFY to originating MG for setting remote Descriptor.

If you send ADD command to the originating MG only after knowing the terminator,
MGC had completed processing of the call but now it need to wait for sending
three commands
(ADD to originating MG, ADD to terminating MG and MODIFY to originating MG) and
their responses.

Take the case of trunking gateway, where the number of calls originating on a MG
and terminating on the same MG are much less than calls originated and
terminated on two different MGs.

thanks & regards
Chak

----- Original Message -----
From: "Rosen, Brian" <Brian.Rosen@marconi.com>
To: "'PSK Chakravarthi'" <chak@axes-mach01.usa.alcatel.com>; "'Madhu Babu
Brahmanapally'" <madhubabu@kenetec.com>; "'Terry L Anderson'" <tla@lucent.com>
Cc: <megaco@fore.com>
Sent: Thursday, June 21, 2001 7:21 PM
Subject: RE: Ephemeral Termination

> There is no way this will reduce call setup time.
> Since you do not have the destination information, you
> will have to MODIFY the ephemeral when you do.  The processing
> time for the Modify won't be substantially more than doing
> an Add at that point, and there is no difference to the actual
> operation of the gateway.
>
> Brian
>
> > -----Original Message-----
> > From: PSK Chakravarthi [mailto:chak@axes-mach01.usa.alcatel.com]
> > Sent: Thursday, June 21, 2001 1:43 AM
> > To: Rosen, Brian; 'Madhu Babu Brahmanapally'; 'Terry L Anderson'
> > Cc: megaco@fore.com
> > Subject: Re: Ephemeral Termination
> >
> >
> > The reason for creating Ephemeral and reserving SDP before knowing the
> > termination is
> > to reduce the call setup time.
> >
> > thanks & regards
> > Chak
> > ----- Original Message -----
> > From: "Rosen, Brian" <Brian.Rosen@marconi.com>
> > To: "'Madhu Babu Brahmanapally'" <madhubabu@kenetec.com>;
> > "'Terry L Anderson'"
> > <tla@lucent.com>; "'PSK Chakravarthi'"
> > <chak@axes-mach01.usa.alcatel.com>
> > Cc: <megaco@fore.com>
> > Sent: Wednesday, June 20, 2001 9:07 PM
> > Subject: RE: Ephemeral Termination
> >
> >
> > > I'm not at all sure what "resources" you can reserve before you
> > > know the destination:
> > >
> > > For an IP network, you can reserve a UDP port I suppose, but until
> > > you negotiate the SDP, you can't reserve bandwidth.  You can't
> > > make any QoS reservation for the same reason.
> > >
> > > It's worse on an ATM network.
> > >
> > > I think there is nothing to be gained by #1
> > >
> > > Brian
> > >
> > > > -----Original Message-----
> > > > From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
> > > > Sent: Wednesday, June 20, 2001 11:28 AM
> > > > To: 'Terry L Anderson'; 'PSK Chakravarthi'
> > > > Cc: megaco@fore.com
> > > > Subject: RE: Ephemeral Termination
> > > >
> > > >
> > > > Hi All,
> > > > The creation of ephemeral termination can be done either
> > after digit
> > > > analysis or before it. Each has its own advantages and
> > disadvantages.
> > > >
> > > > 1) If Ephemeral termination is created before digit analysis,
> > > > situation may
> > > > occur where the destination user/termination is connected to
> > > > the same MG and
> > > > there is no need to create an ephemeral termination (as PSK
> > > > mentioned). But
> > > > this has the advantage that the call wont be dropped due
> > to lack of
> > > > resource, as ephemeral resources are pre-reserved at the MG.
> > > > (in case Add
> > > > fails later to add ephemeral termination).
> > > >
> > > > 2) If Ephemeral termination is created after digit analysis,
> > > > it takes care
> > > > of all situation where destination user may/may not connected
> > > > to the same
> > > > MG. But when Ephemeral termination is added later, there is no
> > > > pre-reservation of the ephemeral resources at the origination MG.
> > > >
> > > > In case of 1) if the call doesn't mature, reserving the
> > > > resources doesn't
> > > > gain anything. Consideration that the destination user on the
> > > > same MG is
> > > > less probable, Method 2 IMO will be a better choice.
> > > >
> > > > Regards
> > > > Madhubabu
> > > >
> > > > -----Original Message-----
> > > > From: owner-megaco@pit.comms.marconi.com
> > > > [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Terry
> > > > L Anderson
> > > > Sent: Wednesday, June 20, 2001 11:01 AM
> > > > To: PSK Chakravarthi
> > > > Cc: megaco@fore.com
> > > > Subject: Re: Ephemeral Termination
> > > >
> > > >
> > > >
> > > >
> > > > PSK Chakravarthi wrote:
> > > >
> > > > > I have got the following doubt.
> > > > > If the originating and terminating termination IDs are on
> > > > the same gateway
> > > > and
> > > > > gateway supports two TDM terminations in a context, is it
> > > > required to
> > > > craete a
> > > > > ephenmeral termination for this call?
> > > > >
> > > > > Message flow between MGC and MG:
> > > > >
> > > > > 1. MGC send ADD command to originating MG
> > > > >     a) Choose a context ID
> > > > >     b) Add a TDM termination
> > > > >     c) Choose a Ephemeral termination
> > > > >     d) Reserve Local Descriptor
> > > > >     e) set MODE to Receive only.
> > > > >
> > > > > 2. MGC now finds that call is terminating on the same MG.
> > > > Also MGC knows
> > > > that
> > > > > MG is capable of adding two TDMs to the same context.  At
> > > > this point what
> > > > should
> > > > > be the command to the MG?
> > > > > Is it required to SUBTRACT the ephemeral termination and
> > > > send ADD for
> > > > adding new
> > > > > TDM to the same context? or
> > > > > Simply sending ADD for new TDM to the same context is
> > sufficient?
> > > >
> > > > It would be better if MGC "finds" that the call is terminated
> > > > on the same MG
> > > > before
> > > > sending the ADD, in step 1c, but if since step c (which you
> > > > call "Choose a
> > > > Ephemeral
> > > > termination) is an Add with wildcard, MGC must certainly
> > > > Subtract it if it
> > > > chooses
> > > > later not to use it.  The Subtract deletes the ephemeral
> > > > termination and
> > > > releases
> > > > its resources.
> > > >
> > > > > thanks & regards
> > > > > Chak
> > > >
> > > > --
> > > > ------------------------------------------------------------
> > > > Terry L Anderson             mailto:tla@lucent.com
> > > > Tel:908.582.7013   Fax:908.582.6729
> > > > Lucent Technologies/INS/Voice Over IP Access Networks
> > > > Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974
> > > > http://its.lucent.com/~tla (Lucent internal)
> http://www.gti.net/tla
> > >
> > >
> >
>

-- 
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****
  --------------E6E2AAB0FC04069E05E1885B-- From owner-megaco@fore.com Thu Jun 21 10:42:26 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA00797 for ; Thu, 21 Jun 2001 10:42:25 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA05128; Thu, 21 Jun 2001 10:30:32 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA14811 for megaco-list; Thu, 21 Jun 2001 10:28:39 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA14793 for ; Thu, 21 Jun 2001 10:28:37 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 21 Jun 2001 10:28:33 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF044655B9@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Sarju Garg'" , "'megaco'" Subject: RE: Property Characteristics Date: Thu, 21 Jun 2001 10:28:32 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0FA5E.72B72950" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0FA5E.72B72950 Content-Type: text/plain; charset="iso-8859-1" 1. Sec 12.1.2 Defined in: Can a property be defined in more than one descriptor? No 2. Sec 12.1.5 Statistics: How can I define a unit? is it of type double or int or what? Would it be better to define it as Statisitics Name: only descriptive Statistics ID: Is an identifier Type: One of: U_Integer : 4 byte unsigned integer U_Double: 8 byte unsigned integer. Possible Values: There is presently no way to define an unsigned integer. A V2 item. This definition is what followed in defining packages for RTP package. Sec E.12.4. Should be change Type double to unsigned double as it just count the number of package which cannot be negative? 3. Can a package be extended from two packages? No Brian ------_=_NextPart_001_01C0FA5E.72B72950 Content-Type: text/html; charset="iso-8859-1"
1. Sec 12.1.2 Defined in:  Can a property be defined in more than one descriptor? 
No 
 
2. Sec 12.1.5 Statistics: How can I define a unit? is it of type double or int or what? Would it be better to define it as
Statisitics Name: only descriptive
Statistics ID: Is an identifier
Type: One of:
    U_Integer : 4 byte unsigned integer
    U_Double: 8 byte unsigned integer.
Possible Values: 
There is presently no way to define an unsigned integer.  A V2 item. 
 
This definition is what followed in defining packages for RTP package. Sec E.12.4. Should be change Type double to unsigned double as it just count the number of package which cannot be negative?
 
3. Can a package be extended from two packages?  
No 
 
Brian 
------_=_NextPart_001_01C0FA5E.72B72950-- From owner-megaco@fore.com Thu Jun 21 10:43:45 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA00853 for ; Thu, 21 Jun 2001 10:43:44 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA05548; Thu, 21 Jun 2001 10:33:00 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA15725 for megaco-list; Thu, 21 Jun 2001 10:32:14 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA15711 for ; Thu, 21 Jun 2001 10:32:12 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 21 Jun 2001 10:32:10 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF044655BA@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Sarju Garg'" , "'megaco'" Subject: RE: Allowed char set for Identifier Date: Thu, 21 Jun 2001 10:32:08 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0FA5E.F3B418B0" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0FA5E.F3B418B0 Content-Type: text/plain; charset="iso-8859-1" A typo, it should use "alphabetic" for the first instance. I think the second can stand (alphanumeric = characters and/or digits). Terry, this is clearly an IG item. Brian -----Original Message----- From: Sarju Garg [mailto:sarju@bhartitelesoft.com] Sent: Thursday, June 21, 2001 8:54 AM To: 'megaco' Subject: Allowed char set for Identifier Hi all, I have a confusion in the allowed char set for Identifiers. In Sec 12.4, it says the following: Identifiers in text encoding shall be strings of up to 64 characters, containing no spaces, starting with an alphanumeric character and consisting of alphanumeric characters and / or digits, and possibly including the special character underscore ("_"). Shouldn't be alphanumeric be alphabet here? Or if the above statement is true, then there should be no digits mentioned here. The text should be like: Identifiers in text encoding shall be strings of up to 64 characters, containing no spaces, starting with an alphanumeric character and consisting of alphanumeric characters, and possibly including the special character underscore ("_"). TIA Sarju ------_=_NextPart_001_01C0FA5E.F3B418B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
A typo, it=20 should use "alphabetic" for the first instance.  I think the = second=20 can
stand=20 (alphanumeric =3D characters and/or digits).
 
Terry, this=20 is clearly an IG item.
 
Brian
-----Original Message-----
From: Sarju Garg=20 [mailto:sarju@bhartitelesoft.com]
Sent: Thursday, June 21, = 2001 8:54=20 AM
To: 'megaco'
Subject: Allowed char set for=20 Identifier

Hi all,
 
I have a confusion in the allowed = char set for=20 Identifiers. In Sec 12.4, it says the following:
Identifiers=20 in text encoding shall be strings of up to 64 characters, containing = no=20 spaces, starting with an alphanumeric character and consisting of = alphanumeric=20 characters and / or digits, and possibly including the special = character=20 underscore ("_").
 
Shouldn't be alphanumeric be alphabet here?
 
Or if the above statement is true, then there should be no = digits=20 mentioned here. The text should be like:
Identifiers=20 in text encoding shall be strings of up to 64 characters, containing = no=20 spaces, starting with an alphanumeric character and consisting of = alphanumeric=20 characters, and possibly including the special character underscore=20 ("_").
 
TIA
Sarju
------_=_NextPart_001_01C0FA5E.F3B418B0-- From owner-megaco@fore.com Thu Jun 21 10:45:44 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA00928 for ; Thu, 21 Jun 2001 10:45:43 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA06023; Thu, 21 Jun 2001 10:35:43 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA16489 for megaco-list; Thu, 21 Jun 2001 10:34:30 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA16479 for ; Thu, 21 Jun 2001 10:34:29 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 21 Jun 2001 10:34:26 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF044655BB@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Sarju Garg'" , "'megaco'" Subject: RE: How to Determine the Termination Type Date: Thu, 21 Jun 2001 10:34:24 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0FA5F.44861950" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0FA5F.44861950 Content-Type: text/plain; charset="iso-8859-1" In most cases, you won't use $ with a physical termination because it usually matters which physical port you want. However, the rule is that you must specify (using local/remote) enough parameters to allow the MG to choose the type of termination correctly. Brian -----Original Message----- From: Sarju Garg [mailto:sarju@bhartitelesoft.com] Sent: Thursday, June 21, 2001 4:53 AM To: 'megaco' Subject: How to Determine the Termination Type Hi all, Suppose MG application supports RTP, PSTN termination. The termination are allocated by the MG application for a call? So the ADD command specify $ for the termination name so that MG can allocate a termination and return it to MGC application. How does the MG application come to know that receiving an ADD command is for which type of termination - for RTP termination or PSTN termination? I believe Local/Remote descriptors are required for RTP terminations. So can Local/Remote descriptor be used for this purpose? TIA Sarju ------_=_NextPart_001_01C0FA5F.44861950 Content-Type: text/html; charset="iso-8859-1"
In most cases, you won't use $ with a physical termination because it usually matters
which physical port you want. 
 
However, the rule is that you must specify (using local/remote) enough parameters
to allow the MG to choose the type of termination correctly.
 
Brian
-----Original Message-----
From: Sarju Garg [mailto:sarju@bhartitelesoft.com]
Sent: Thursday, June 21, 2001 4:53 AM
To: 'megaco'
Subject: How to Determine the Termination Type

 
Hi all,
 
Suppose MG application supports RTP, PSTN termination. The termination are allocated by the MG application for a call? So the ADD command specify $ for the termination name so that MG can allocate a termination  and return it to MGC application. How does the MG application come to know that receiving an ADD command is for which type of termination - for RTP termination or PSTN termination? I believe Local/Remote descriptors are required for RTP terminations. So can Local/Remote descriptor be used for this purpose?
 
TIA
Sarju
 
------_=_NextPart_001_01C0FA5F.44861950-- From owner-megaco@fore.com Thu Jun 21 11:09:28 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA01720 for ; Thu, 21 Jun 2001 11:09:27 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA08043; Thu, 21 Jun 2001 10:55:54 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA22271 for megaco-list; Thu, 21 Jun 2001 10:54:34 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA22258 for ; Thu, 21 Jun 2001 10:54:32 -0400 (EDT) Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA07888 for ; Thu, 21 Jun 2001 10:54:27 -0400 (EDT) Received: from ihemail1.firewall.lucent.com (localhost [127.0.0.1]) by ihemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5LEsS212189 for ; Thu, 21 Jun 2001 10:54:28 -0400 (EDT) Received: from teton.mh.lucent.com (h135-3-130-2.lucent.com [135.3.130.2]) by ihemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5LEsR312160; Thu, 21 Jun 2001 10:54:27 -0400 (EDT) Received: from lucent.com (pctla [135.3.130.39]) by teton.mh.lucent.com (8.8.8+Sun/8.8.8) with ESMTP id KAA25183; Thu, 21 Jun 2001 10:54:26 -0400 (EDT) Message-ID: <3B320BE4.A3DEB946@lucent.com> Date: Thu, 21 Jun 2001 10:59:48 -0400 From: Terry L Anderson Organization: Lucent Technologies X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Nitin Kumar CC: "Rosen, Brian" , "'megaco@fore.com'" Subject: Re: Few clarification in RFC3015 References: Content-Type: multipart/mixed; boundary="------------3CE84D39B9D8622BB8E8ECE0" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk This is a multi-part message in MIME format. --------------3CE84D39B9D8622BB8E8ECE0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Nitin Kumar wrote: > ok... > thats what even i thought.. > now if actions in a transaction are processed in sequence then consider > following scenario > > TransactionRequest > { > Action1 > { > command1 > command2 > } > Action2 > { > command1 > command2 > command3 > } > Action3 > { > command1 > command2 > } > } > > Suppose all commands are manatory. Lets assume command2 in Action2 generates > some error or is not processed successfully then > does it mean that command3 of Action2 as well as any further action i.e. > Action3 will not be executed? > > If yes, then my doubt is: when every Action is concerned with different > Context.. then why failure of one command in one Action should bother other > Action with in the same transaction? If you want Action3 to be executed regardless of the success of Action1&2 put them into separate Transactions (they can still be in the same message). Transactions are precisely to tie actions and commands to success of previous. I cannot think of a reason you would want to ensure action3 was executed sequentally after action2 but did not care if action2 succeeded. > We should be able to process every Action sequentially and independently. > > regards, > > -nitin > > -----Original Message----- > From: Terry L Anderson [mailto:tla@lucent.com] > Sent: Thursday, June 21, 2001 3:23 AM > To: Rosen, Brian > Cc: 'Nitin Kumar'; 'megaco@fore.com' > Subject: Re: Few clarification in RFC3015 > > "Rosen, Brian" wrote: > > > Hmmm, maybe we should edit that text to say: > > "Actions in a transaction and commands within an action are > > executed sequentially in the order they appear in the transaction." > > > > Terry? > > That is certainly the intent and the way I would read the current text > ("commands in order" - the fact that they are grouped into actions doesn't > alter their order). But your text is certainly more explicit. I have no > trouble with it. I'll put it in. > > > > > > > "Normal Repitition timers" are the timer values defined in D.1.3 > > > > Brian > > > > > -----Original Message----- > > > From: Nitin Kumar [mailto:nitin@indts.com] > > > Sent: Wednesday, June 20, 2001 2:32 PM > > > To: 'megaco@fore.com' > > > Subject: Few clarification in RFC3015 > > > > > > > > > Hi Folks, > > > > > > Just looking for following clarification. > > > > > > 1. In a TransactionRequest, are ActionRequests processed in > > > order or only > > > Commands in an ActionRequest are executed sequencially ? RFC > > > says "Commands > > > within a Transaction are executed sequentially." > > > > > > 2. Few lines from the RFC on page number 135, section D.1.4.. > > > "Upon receipt of a final response following receipt of > > > provisional responses, an immediate confirmation shall be sent, and > > > normal repetition timers shall be used thereafter." > > > > > > Now what does "normal repetition timers shall be used > > > thereafter" mean in > > > above extract? > > > > > > i hope to receive some insights. > > > > > > regards, > > > > > > -nitin > > > > > > Ind Telesoft Pvt. Ltd. > > > 104, Koramangla Industrial Estate, > > > 5th Block, Bangalore 560 095 > > > Tel : 5508930, 5521937, 5529758-62 ext-259 > > > Fax : 5521164 > > > mailto:nitin@indts.com > > > http:\\www.telesoftinc.com > > > > > -- > ------------------------------------------------------------ > Terry L Anderson mailto:tla@lucent.com > Tel:908.582.7013 Fax:908.582.6729 > Lucent Technologies/INS/Voice Over IP Access Networks > Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 > http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla -- ------------------------------------------------------------ Terry L Anderson mailto:tla@lucent.com Tel:908.582.7013 Fax:908.582.6729 Lucent Technologies/INS/Voice Over IP Access Networks Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla --------------3CE84D39B9D8622BB8E8ECE0 Content-Type: text/x-vcard; charset=us-ascii; name="tla.vcf" Content-Description: Card for Terry L Anderson Content-Disposition: attachment; filename="tla.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Anderson;Terry L tel;fax:908.582.6729 tel;work:908.582.7013 x-mozilla-html:TRUE url:http://its.lucent.com/~tla org:Lucent / InterNetworking Systems;VoIP Access Networks version:2.1 email;internet:tla@lucent.com title:DMTS note:http://www.gti.net/tla or http://teton.mh.lucent.com/~tla (Lucent internal) adr;quoted-printable:;;600 Mountain Av=0D=0ARm 2B-121;Murray Hill;NJ;07974;USA x-mozilla-cpt:;21296 fn:Terry L Anderson end:vcard --------------3CE84D39B9D8622BB8E8ECE0-- From owner-megaco@fore.com Thu Jun 21 11:09:29 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA01721 for ; Thu, 21 Jun 2001 11:09:28 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA08257; Thu, 21 Jun 2001 10:57:11 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA22732 for megaco-list; Thu, 21 Jun 2001 10:56:28 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA22713 for ; Thu, 21 Jun 2001 10:56:26 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 21 Jun 2001 10:56:24 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF044655BC@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'PSK Chakravarthi'" , "'Madhu Babu Brahmanapally'" , "'Terry L Anderson'" Cc: megaco@fore.com Subject: RE: Ephemeral Termination Date: Thu, 21 Jun 2001 10:56:23 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk I'm having trouble following your logic. This seems to be a trunk GW/ISUP issue, so we don't have to deal with off hook/DTMF issues, right? In the case of hairpin, you need two commands: 1) An add to put the originating termination in the context 2) An add to put the terminating termination in the context. They cannot be in the same transaction if you have not completed digit analysis before you do 1. In the case of a normal connection between two MGs you need 4 total commands: 1) The Add of the physical in the originating MG 2) The Add of the ephemeral in the originating MG 3) The Add of the physical in the terminating MG 4) The Add of the ephemeral in the terminating MG You can do 1 before you do digit analysis. You have to do 3 and 4 after digit analysis, but they can be in the same transaction. If you do 2 before you do digit analysis, you would not have the correct remote SDP, and therefore you would need to send a Modify after digit analysis. If you do it after you do digit analysis, then you only have the 4 commands. Before digit analysis, the MGC sends 1. After digit analysis the MGC sends two transactions in two messages; one to the originating MG (message 2 containing correct local and remote SDP) and one to the terminating MG (with messages 3 and 4 including all the SDP). In most cases, I suspect it would actually be more efficient to send message 1 after digit analysis, because then the originating MG has one less transaction to process, but the same number of commands. The call setup difference between the originating MG doing one add before digit analysis and another after vs doing both after won't matter enough to be measurable I think, but the difference in processing of half the number of messages will be substantial. I see no way to have the Add of the ephemeral before digit analysis improve call setup time. It seems to only create extra work for the originating MG. Brian > -----Original Message----- > From: PSK Chakravarthi [mailto:chak@axes-mach01.usa.alcatel.com] > Sent: Thursday, June 21, 2001 10:10 AM > To: Rosen, Brian; 'Madhu Babu Brahmanapally'; 'Terry L Anderson' > Cc: megaco@fore.com > Subject: Re: Ephemeral Termination > > > The reason for creating Ephemeral and reserving SDP before knowing the > termination is to reduce the call setup time. > > Following is the MGC processing. > > 1. Soon after receiving IAM send ADD command to the originating MG for > a)Creating Ephemeral > b)Reserving SDP for Local > c)Simultaneously start digit analysis > After finding termination > (By this time ADD response would have been received, if not > MGC need to wait for > ADD response) > If terminating trunk belongs to the same MG > a) send ADD command to add the second termination to the > same context. > This ADD command will have empty Local descriptor to > release resources > previously allocated. > Note that ephemeral is not SUBTRACTED. Also MODIFY to > originating MG is > not required as MG is going to make only hairpin connection. > If the terminating MG is not same as originating MG > Send ADD command to terminating MG > a) Creating Ephemeral > b) Reserving SDP for Local > c) Setting SDP remote as Local returned by the originating MG. > After receiving the ADD response from terminating MG > Send MODIFY to originating MG for setting remote Descriptor. > > If you send ADD command to the originating MG only after > knowing the terminator, > MGC had completed processing of the call but now it need to > wait for sending > three commands > (ADD to originating MG, ADD to terminating MG and MODIFY to > originating MG) and > their responses. > > Take the case of trunking gateway, where the number of calls > originating on a MG > and terminating on the same MG are much less than calls originated and > terminated on two different MGs. > > thanks & regards > Chak > > ----- Original Message ----- > From: "Rosen, Brian" > To: "'PSK Chakravarthi'" ; > "'Madhu Babu > Brahmanapally'" ; "'Terry L Anderson'" > > Cc: > Sent: Thursday, June 21, 2001 7:21 PM > Subject: RE: Ephemeral Termination > > > > There is no way this will reduce call setup time. > > Since you do not have the destination information, you > > will have to MODIFY the ephemeral when you do. The processing > > time for the Modify won't be substantially more than doing > > an Add at that point, and there is no difference to the actual > > operation of the gateway. > > > > Brian > > > > > -----Original Message----- > > > From: PSK Chakravarthi [mailto:chak@axes-mach01.usa.alcatel.com] > > > Sent: Thursday, June 21, 2001 1:43 AM > > > To: Rosen, Brian; 'Madhu Babu Brahmanapally'; 'Terry L Anderson' > > > Cc: megaco@fore.com > > > Subject: Re: Ephemeral Termination > > > > > > > > > The reason for creating Ephemeral and reserving SDP > before knowing the > > > termination is > > > to reduce the call setup time. > > > > > > thanks & regards > > > Chak > > > ----- Original Message ----- > > > From: "Rosen, Brian" > > > To: "'Madhu Babu Brahmanapally'" ; > > > "'Terry L Anderson'" > > > ; "'PSK Chakravarthi'" > > > > > > Cc: > > > Sent: Wednesday, June 20, 2001 9:07 PM > > > Subject: RE: Ephemeral Termination > > > > > > > > > > I'm not at all sure what "resources" you can reserve before you > > > > know the destination: > > > > > > > > For an IP network, you can reserve a UDP port I > suppose, but until > > > > you negotiate the SDP, you can't reserve bandwidth. You can't > > > > make any QoS reservation for the same reason. > > > > > > > > It's worse on an ATM network. > > > > > > > > I think there is nothing to be gained by #1 > > > > > > > > Brian > > > > > > > > > -----Original Message----- > > > > > From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com] > > > > > Sent: Wednesday, June 20, 2001 11:28 AM > > > > > To: 'Terry L Anderson'; 'PSK Chakravarthi' > > > > > Cc: megaco@fore.com > > > > > Subject: RE: Ephemeral Termination > > > > > > > > > > > > > > > Hi All, > > > > > The creation of ephemeral termination can be done either > > > after digit > > > > > analysis or before it. Each has its own advantages and > > > disadvantages. > > > > > > > > > > 1) If Ephemeral termination is created before digit analysis, > > > > > situation may > > > > > occur where the destination user/termination is connected to > > > > > the same MG and > > > > > there is no need to create an ephemeral termination (as PSK > > > > > mentioned). But > > > > > this has the advantage that the call wont be dropped due > > > to lack of > > > > > resource, as ephemeral resources are pre-reserved at the MG. > > > > > (in case Add > > > > > fails later to add ephemeral termination). > > > > > > > > > > 2) If Ephemeral termination is created after digit analysis, > > > > > it takes care > > > > > of all situation where destination user may/may not connected > > > > > to the same > > > > > MG. But when Ephemeral termination is added later, there is no > > > > > pre-reservation of the ephemeral resources at the > origination MG. > > > > > > > > > > In case of 1) if the call doesn't mature, reserving the > > > > > resources doesn't > > > > > gain anything. Consideration that the destination user on the > > > > > same MG is > > > > > less probable, Method 2 IMO will be a better choice. > > > > > > > > > > Regards > > > > > Madhubabu > > > > > > > > > > -----Original Message----- > > > > > From: owner-megaco@pit.comms.marconi.com > > > > > [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Terry > > > > > L Anderson > > > > > Sent: Wednesday, June 20, 2001 11:01 AM > > > > > To: PSK Chakravarthi > > > > > Cc: megaco@fore.com > > > > > Subject: Re: Ephemeral Termination > > > > > > > > > > > > > > > > > > > > > > > > > PSK Chakravarthi wrote: > > > > > > > > > > > I have got the following doubt. > > > > > > If the originating and terminating termination IDs are on > > > > > the same gateway > > > > > and > > > > > > gateway supports two TDM terminations in a context, is it > > > > > required to > > > > > craete a > > > > > > ephenmeral termination for this call? > > > > > > > > > > > > Message flow between MGC and MG: > > > > > > > > > > > > 1. MGC send ADD command to originating MG > > > > > > a) Choose a context ID > > > > > > b) Add a TDM termination > > > > > > c) Choose a Ephemeral termination > > > > > > d) Reserve Local Descriptor > > > > > > e) set MODE to Receive only. > > > > > > > > > > > > 2. MGC now finds that call is terminating on the same MG. > > > > > Also MGC knows > > > > > that > > > > > > MG is capable of adding two TDMs to the same context. At > > > > > this point what > > > > > should > > > > > > be the command to the MG? > > > > > > Is it required to SUBTRACT the ephemeral termination and > > > > > send ADD for > > > > > adding new > > > > > > TDM to the same context? or > > > > > > Simply sending ADD for new TDM to the same context is > > > sufficient? > > > > > > > > > > It would be better if MGC "finds" that the call is terminated > > > > > on the same MG > > > > > before > > > > > sending the ADD, in step 1c, but if since step c (which you > > > > > call "Choose a > > > > > Ephemeral > > > > > termination) is an Add with wildcard, MGC must certainly > > > > > Subtract it if it > > > > > chooses > > > > > later not to use it. The Subtract deletes the ephemeral > > > > > termination and > > > > > releases > > > > > its resources. > > > > > > > > > > > thanks & regards > > > > > > Chak > > > > > > > > > > -- > > > > > ------------------------------------------------------------ > > > > > Terry L Anderson mailto:tla@lucent.com > > > > > Tel:908.582.7013 Fax:908.582.6729 > > > > > Lucent Technologies/INS/Voice Over IP Access Networks > > > > > Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 > > > > > http://its.lucent.com/~tla (Lucent internal) > > http://www.gti.net/tla > > > > > > > > > > > > > > From owner-megaco@fore.com Thu Jun 21 11:10:47 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA01804 for ; Thu, 21 Jun 2001 11:10:46 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA08641; Thu, 21 Jun 2001 10:59:40 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA23361 for megaco-list; Thu, 21 Jun 2001 10:58:56 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA23344 for ; Thu, 21 Jun 2001 10:58:55 -0400 (EDT) Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA08490 for ; Thu, 21 Jun 2001 10:58:49 -0400 (EDT) Received: from ihemail1.firewall.lucent.com (localhost [127.0.0.1]) by ihemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5LEwp217914 for ; Thu, 21 Jun 2001 10:58:51 -0400 (EDT) Received: from teton.mh.lucent.com (h135-3-130-2.lucent.com [135.3.130.2]) by ihemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5LEwo317898; Thu, 21 Jun 2001 10:58:50 -0400 (EDT) Received: from lucent.com ([135.3.128.238]) by teton.mh.lucent.com (8.8.8+Sun/8.8.8) with ESMTP id KAA25672; Thu, 21 Jun 2001 10:58:48 -0400 (EDT) Message-ID: <3B320B53.D90194E@lucent.com> Date: Thu, 21 Jun 2001 10:57:23 -0400 From: Terry L Anderson Organization: Lucent Technologies X-Mailer: Mozilla 4.75 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: mu lj CC: megaco@fore.com Subject: Re: how to get h.248 version 2? References: Content-Type: multipart/mixed; boundary="------------D8BD5A2C3B9F4FFFD0391B5F" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk This is a multi-part message in MIME format. --------------D8BD5A2C3B9F4FFFD0391B5F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit H.248 v2 is not approved but the latest draft (presented at Porto Seguro meeting) is available at: ftp://standard.pictel.com/avc-site/0105_Por/TD-xxx_H248_v2.zip mu lj wrote: > hi all: > Who can tell me how to get h.248 version 2? > Regards, > > mu lj > > _________________________________________________________________________ > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. -- ------------------------------------------------------------ Terry L Anderson mailto:tla@lucent.com Tel:908.582.7013 Fax:908.582.6729 Lucent Technologies/INS/Voice Over IP Access Networks Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla --------------D8BD5A2C3B9F4FFFD0391B5F Content-Type: text/x-vcard; charset=us-ascii; name="tla.vcf" Content-Description: Card for Terry L Anderson Content-Disposition: attachment; filename="tla.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Anderson;Terry L tel;fax:908.582.6729 tel;work:908.582.7013 x-mozilla-html:TRUE url:http://its.lucent.com/~tla org:Lucent / InterNetworking Systems;VoIP Access Networks version:2.1 email;internet:tla@lucent.com title:DMTS note:http://www.gti.net/tla or http://teton.mh.lucent.com/~tla (Lucent internal) adr;quoted-printable:;;Rm 2B-121=0D=0A600 Mountain Ave;Murray Hill;NJ;07974;USA x-mozilla-cpt:;7264 fn:Terry L Anderson end:vcard --------------D8BD5A2C3B9F4FFFD0391B5F-- From owner-megaco@fore.com Thu Jun 21 11:11:36 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA01837 for ; Thu, 21 Jun 2001 11:11:33 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA08926; Thu, 21 Jun 2001 11:01:38 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id LAA23939 for megaco-list; Thu, 21 Jun 2001 11:00:56 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA23921 for ; Thu, 21 Jun 2001 11:00:54 -0400 (EDT) Received: from huginn.ctccom.net (Huginn.CTCCom.net [207.190.194.11]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA08806 for ; Thu, 21 Jun 2001 11:00:44 -0400 (EDT) Received: from MBRAHMANAPALLY ([64.69.123.121]) by huginn.ctccom.net (Mirapoint) with SMTP id ACZ51360; Thu, 21 Jun 2001 10:59:04 -0400 (EDT) From: "Madhu Babu Brahmanapally" To: "'Rosen, Brian'" , "'Sarju Garg'" , "'megaco'" Subject: RE: How to Determine the Termination Type Date: Thu, 21 Jun 2001 11:00:33 -0400 Message-ID: <019801c0fa62$ec77d830$c500a8c0@MBRAHMANAPALLY> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0199_01C0FA41.65663830" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <4FBEA8857476D311A03300204840E1CF044655BB@whq-msgusr-02.pit.comms.marconi.com> Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0199_01C0FA41.65663830 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Brian,All, In case of choosing any physical trunk IMO $ can be useful for choosing physical termination too. MGs shouldn't assume that $ in ADD only comes for creation of Ephemeral Termination, and logic should be based on the descriptors rather than the wildcard termination Identifier. Of course as Brian, suggested enough parameters needs to be specified by the MGC. -Regards Madhubabu -----Original Message----- From: owner-megaco@pit.comms.marconi.com [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Rosen, Brian Sent: Thursday, June 21, 2001 10:34 AM To: 'Sarju Garg'; 'megaco' Subject: RE: How to Determine the Termination Type In most cases, you won't use $ with a physical termination because it usually matters which physical port you want. However, the rule is that you must specify (using local/remote) enough parameters to allow the MG to choose the type of termination correctly. Brian -----Original Message----- From: Sarju Garg [mailto:sarju@bhartitelesoft.com] Sent: Thursday, June 21, 2001 4:53 AM To: 'megaco' Subject: How to Determine the Termination Type Hi all, Suppose MG application supports RTP, PSTN termination. The termination are allocated by the MG application for a call? So the ADD command specify $ for the termination name so that MG can allocate a termination and return it to MGC application. How does the MG application come to know that receiving an ADD command is for which type of termination - for RTP termination or PSTN termination? I believe Local/Remote descriptors are required for RTP terminations. So can Local/Remote descriptor be used for this purpose? TIA Sarju ------=_NextPart_000_0199_01C0FA41.65663830 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi=20 Brian,All,
 
In=20 case of choosing any physical trunk IMO $ can be useful for = choosing=20 physical termination too.  MGs shouldn't assume that $ in ADD only = comes=20 for creation of Ephemeral Termination, and logic should be based on the=20 descriptors rather than the wildcard termination Identifier. Of course = as Brian,=20 suggested enough parameters needs to be specified by the=20 MGC.
 
-Regards
Madhubabu
-----Original Message-----
From:=20 owner-megaco@pit.comms.marconi.com=20 [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Rosen,=20 Brian
Sent: Thursday, June 21, 2001 10:34 AM
To: = 'Sarju=20 Garg'; 'megaco'
Subject: RE: How to Determine the = Termination=20 Type

In most=20 cases, you won't use $ with a physical termination because it usually=20 matters
which=20 physical port you want. 
 
However,=20 the rule is that you must specify (using local/remote) enough=20 parameters
to allow=20 the MG to choose the type of termination = correctly.
 
Brian
-----Original Message-----
From: Sarju Garg=20 [mailto:sarju@bhartitelesoft.com]
Sent: Thursday, June 21, = 2001=20 4:53 AM
To: 'megaco'
Subject: How to Determine = the=20 Termination Type

 
Hi all,
 
Suppose MG application supports = RTP, PSTN=20 termination. The termination are allocated by the MG application for = a call?=20 So the ADD command specify $ for the termination name so that MG can = allocate a termination  and return it to MGC application. How = does the=20 MG application come to know that receiving an ADD command is for = which type=20 of termination - for RTP termination or PSTN termination? I believe=20 Local/Remote descriptors are required for RTP terminations. So can=20 Local/Remote descriptor be used for this purpose?
 
TIA
Sarju
=
 
------=_NextPart_000_0199_01C0FA41.65663830-- From owner-megaco@fore.com Thu Jun 21 11:37:50 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA02936 for ; Thu, 21 Jun 2001 11:37:49 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA11039; Thu, 21 Jun 2001 11:20:52 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id LAA29153 for megaco-list; Thu, 21 Jun 2001 11:19:45 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA29132 for ; Thu, 21 Jun 2001 11:19:42 -0400 (EDT) Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA10889 for ; Thu, 21 Jun 2001 11:19:36 -0400 (EDT) Received: from hoemail2.firewall.lucent.com (localhost [127.0.0.1]) by hoemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5LFJcn05151 for ; Thu, 21 Jun 2001 11:19:38 -0400 (EDT) Received: from teton.mh.lucent.com (h135-3-130-2.lucent.com [135.3.130.2]) by hoemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5LFJc905144; Thu, 21 Jun 2001 11:19:38 -0400 (EDT) Received: from lucent.com (pctla [135.3.130.39]) by teton.mh.lucent.com (8.8.8+Sun/8.8.8) with ESMTP id LAA26942; Thu, 21 Jun 2001 11:19:35 -0400 (EDT) Message-ID: <3B3211CA.8180F217@lucent.com> Date: Thu, 21 Jun 2001 11:24:59 -0400 From: Terry L Anderson Organization: Lucent Technologies X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Rosen, Brian" CC: "'Sarju Garg'" , "'megaco'" Subject: Re: Allowed char set for Identifier References: <4FBEA8857476D311A03300204840E1CF044655BA@whq-msgusr-02.pit.comms.marconi.com> Content-Type: multipart/mixed; boundary="------------63B21641B82AC65D1B1E8AE3" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk This is a multi-part message in MIME format. --------------63B21641B82AC65D1B1E8AE3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I agree. I believe the intent was do disallow the first character being numeric. The second instance could be "...consisting of alphanumeric characters, and possibly..." or "...consisting of alphabetic characters and/or digits, and possibly..." or or left alone as Brian suggests. I will make the first change and leave the second as is unless folks write preferring one of the above. "Rosen, Brian" wrote: > A typo, it should use "alphabetic" for the first instance. I think > the second canstand (alphanumeric = characters and/or digits).Terry, > this is clearly an IG item.Brian > > -----Original Message----- > From: Sarju Garg [mailto:sarju@bhartitelesoft.com] > Sent: Thursday, June 21, 2001 8:54 AM > To: 'megaco' > Subject: Allowed char set for Identifier > > Hi all, I have a confusion in the allowed char set for > Identifiers. In Sec 12.4, it says the following:Identifiers > in text encoding shall be strings of up to 64 characters, > containing no spaces, starting with an alphanumeric > character and consisting of alphanumeric characters and / or > digits, and possibly including the special character > underscore ("_").Shouldn't be alphanumeric be alphabet > here? Or if the above statement is true, then there should > be no digits mentioned here. The text should be > like:Identifiers in text encoding shall be strings of up to > 64 characters, containing no spaces, starting with an > alphanumeric character and consisting of alphanumeric > characters, and possibly including the special character > underscore ("_").TIASarju > -- ------------------------------------------------------------ Terry L Anderson mailto:tla@lucent.com Tel:908.582.7013 Fax:908.582.6729 Lucent Technologies/INS/Voice Over IP Access Networks Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla --------------63B21641B82AC65D1B1E8AE3 Content-Type: text/x-vcard; charset=us-ascii; name="tla.vcf" Content-Description: Card for Terry L Anderson Content-Disposition: attachment; filename="tla.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Anderson;Terry L tel;fax:908.582.6729 tel;work:908.582.7013 x-mozilla-html:TRUE url:http://its.lucent.com/~tla org:Lucent / InterNetworking Systems;VoIP Access Networks version:2.1 email;internet:tla@lucent.com title:DMTS note:http://www.gti.net/tla or http://teton.mh.lucent.com/~tla (Lucent internal) adr;quoted-printable:;;600 Mountain Av=0D=0ARm 2B-121;Murray Hill;NJ;07974;USA x-mozilla-cpt:;21296 fn:Terry L Anderson end:vcard --------------63B21641B82AC65D1B1E8AE3-- From owner-megaco@fore.com Thu Jun 21 11:54:47 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA03632 for ; Thu, 21 Jun 2001 11:54:47 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA13030; Thu, 21 Jun 2001 11:42:34 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id LAA05497 for megaco-list; Thu, 21 Jun 2001 11:41:11 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA05432 for ; Thu, 21 Jun 2001 11:41:06 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 21 Jun 2001 11:41:01 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF044655BD@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Madhu Babu Brahmanapally'" , "Rosen, Brian" , "'Sarju Garg'" , "'megaco'" Subject: RE: How to Determine the Termination Type Date: Thu, 21 Jun 2001 11:41:00 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0FA68.923455A0" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0FA68.923455A0 Content-Type: text/plain; charset="iso-8859-1" I keep forgetting that sometimes people take what I say too literally. Here is an example - on outgoing calls, the particular trunk to be seized can be determined by the MG instead of the MGC. In this case, use of "$" on the physical termination is quite reasonable. MGs must be able to handle $ on any termination. However, I disagree with your statement about using wildcarded termination IDs. If you supply a wildcarded termination ID, the MG must use that information. If your MG is built so that terminations with similar capabilities have similar terminationIds (as almost all will be), and you get a wildcarded terminationId, then you CAN use that to determine the "type" of termination. If SDP is given, it MUST match (i.e. be compatible with the wildcarded terminationId). If the SDP and the terminationId don't "match", that is an error. Brian -----Original Message----- From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com] Sent: Thursday, June 21, 2001 11:01 AM To: 'Rosen, Brian'; 'Sarju Garg'; 'megaco' Subject: RE: How to Determine the Termination Type Hi Brian,All, In case of choosing any physical trunk IMO $ can be useful for choosing physical termination too. MGs shouldn't assume that $ in ADD only comes for creation of Ephemeral Termination, and logic should be based on the descriptors rather than the wildcard termination Identifier. Of course as Brian, suggested enough parameters needs to be specified by the MGC. -Regards Madhubabu -----Original Message----- From: owner-megaco@pit.comms.marconi.com [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Rosen, Brian Sent: Thursday, June 21, 2001 10:34 AM To: 'Sarju Garg'; 'megaco' Subject: RE: How to Determine the Termination Type In most cases, you won't use $ with a physical termination because it usually matters which physical port you want. However, the rule is that you must specify (using local/remote) enough parameters to allow the MG to choose the type of termination correctly. Brian -----Original Message----- From: Sarju Garg [mailto:sarju@bhartitelesoft.com] Sent: Thursday, June 21, 2001 4:53 AM To: 'megaco' Subject: How to Determine the Termination Type Hi all, Suppose MG application supports RTP, PSTN termination. The termination are allocated by the MG application for a call? So the ADD command specify $ for the termination name so that MG can allocate a termination and return it to MGC application. How does the MG application come to know that receiving an ADD command is for which type of termination - for RTP termination or PSTN termination? I believe Local/Remote descriptors are required for RTP terminations. So can Local/Remote descriptor be used for this purpose? TIA Sarju ------_=_NextPart_001_01C0FA68.923455A0 Content-Type: text/html; charset="iso-8859-1"
I keep forgetting that sometimes people take what I say too literally.
 
Here is an example - on outgoing calls, the particular trunk to be seized can
be determined by the MG instead of the MGC.  In this case, use of
"$" on the physical termination is quite reasonable.  MGs must be able to
handle $ on any termination.
 
However, I disagree with your statement about using wildcarded termination
IDs.  If you supply a wildcarded termination ID, the MG must use that information.
If your MG is built so that terminations with similar capabilities have similar
terminationIds (as almost all will be), and you get a wildcarded terminationId,
then you CAN use that to determine the "type" of termination.  If SDP is
given, it MUST match (i.e. be compatible with the wildcarded terminationId).
If the SDP and the terminationId don't "match", that is an error.
 
Brian
-----Original Message-----
From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
Sent: Thursday, June 21, 2001 11:01 AM
To: 'Rosen, Brian'; 'Sarju Garg'; 'megaco'
Subject: RE: How to Determine the Termination Type

Hi Brian,All,
 
In case of choosing any physical trunk IMO $ can be useful for choosing physical termination too.  MGs shouldn't assume that $ in ADD only comes for creation of Ephemeral Termination, and logic should be based on the descriptors rather than the wildcard termination Identifier. Of course as Brian, suggested enough parameters needs to be specified by the MGC.
 
-Regards
Madhubabu
-----Original Message-----
From: owner-megaco@pit.comms.marconi.com [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Rosen, Brian
Sent: Thursday, June 21, 2001 10:34 AM
To: 'Sarju Garg'; 'megaco'
Subject: RE: How to Determine the Termination Type

In most cases, you won't use $ with a physical termination because it usually matters
which physical port you want. 
 
However, the rule is that you must specify (using local/remote) enough parameters
to allow the MG to choose the type of termination correctly.
 
Brian
-----Original Message-----
From: Sarju Garg [mailto:sarju@bhartitelesoft.com]
Sent: Thursday, June 21, 2001 4:53 AM
To: 'megaco'
Subject: How to Determine the Termination Type

 
Hi all,
 
Suppose MG application supports RTP, PSTN termination. The termination are allocated by the MG application for a call? So the ADD command specify $ for the termination name so that MG can allocate a termination  and return it to MGC application. How does the MG application come to know that receiving an ADD command is for which type of termination - for RTP termination or PSTN termination? I believe Local/Remote descriptors are required for RTP terminations. So can Local/Remote descriptor be used for this purpose?
 
TIA
Sarju
 
------_=_NextPart_001_01C0FA68.923455A0-- From owner-megaco@fore.com Thu Jun 21 14:10:31 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA11464 for ; Thu, 21 Jun 2001 14:10:30 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA22992; Thu, 21 Jun 2001 13:56:20 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id NAA07157 for megaco-list; Thu, 21 Jun 2001 13:53:48 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA07143 for ; Thu, 21 Jun 2001 13:53:44 -0400 (EDT) Received: from ihemail2.firewall.lucent.com (ihemail2.lucent.com [192.11.222.163]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA22716 for ; Thu, 21 Jun 2001 13:53:39 -0400 (EDT) Received: from ihemail2.firewall.lucent.com (localhost [127.0.0.1]) by ihemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5LHrdH12750 for ; Thu, 21 Jun 2001 13:53:39 -0400 (EDT) Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3]) by ihemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5LHrdM12724 for ; Thu, 21 Jun 2001 13:53:39 -0400 (EDT) Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id NAA07327; Thu, 21 Jun 2001 13:53:37 -0400 (EDT) Cc: "'Sarju Garg'" , "'megaco'" Received: from lucent.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id NAA07305; Thu, 21 Jun 2001 13:53:32 -0400 (EDT) Message-ID: <3B323420.72F385@lucent.com> Date: Thu, 21 Jun 2001 13:51:28 -0400 From: Troy Cauble Reply-To: Troy Cauble X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Rosen, Brian" Original-CC: "'Sarju Garg'" , "'megaco'" Subject: Re: Property Characteristics References: <4FBEA8857476D311A03300204840E1CF044655B9@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: 7bit Sarju: > 2. Sec 12.1.5 Statistics: How can I define a unit? is it of type double or int or what? Would it be better to define it as > Statisitics Name: only descriptive > Statistics ID: Is an identifier > Type: One of: > U_Integer : 4 byte unsigned integer > U_Double: 8 byte unsigned integer. > Possible Values: Brian: > There is presently no way to define an unsigned integer. A V2 item. Brian, I know unsigned integer is not listed in 12.2 or 12.1.2, but several Annex C properties specify unsigned integer. Sarju, I think Statistics can be any of the types listed in 12.2. The use of the word "Units" in 12.1.5 is just reminding you that you have to specify the units *too*. I don't think there's any reason to restrict statistics to unsigned integral values. Perhaps not even to integral values. -troy From owner-megaco@fore.com Thu Jun 21 14:17:45 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA12065 for ; Thu, 21 Jun 2001 14:17:44 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA24100; Thu, 21 Jun 2001 14:06:37 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id OAA10298 for megaco-list; Thu, 21 Jun 2001 14:05:49 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA10294 for ; Thu, 21 Jun 2001 14:05:47 -0400 (EDT) Received: from ihemail2.firewall.lucent.com (ihemail2.lucent.com [192.11.222.163]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA23970 for ; Thu, 21 Jun 2001 14:05:41 -0400 (EDT) Received: from ihemail2.firewall.lucent.com (localhost [127.0.0.1]) by ihemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5LI5hH24169 for ; Thu, 21 Jun 2001 14:05:43 -0400 (EDT) Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3]) by ihemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5LI5hM24159 for ; Thu, 21 Jun 2001 14:05:43 -0400 (EDT) Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id OAA08470; Thu, 21 Jun 2001 14:05:41 -0400 (EDT) Cc: "'Sarju Garg'" , "'megaco'" Received: from lucent.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id OAA08456; Thu, 21 Jun 2001 14:05:40 -0400 (EDT) Message-ID: <3B3236F8.C139AAF5@lucent.com> Date: Thu, 21 Jun 2001 14:03:36 -0400 From: Troy Cauble Reply-To: Troy Cauble X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Rosen, Brian" Original-CC: "'Sarju Garg'" , "'megaco'" Subject: Re: How to Determine the Termination Type References: <4FBEA8857476D311A03300204840E1CF044655BB@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: 7bit > > In most cases, you won't use $ with a physical termination because it usually matters > which physical port you want. > > However, the rule is that you must specify (using local/remote) enough parameters > to allow the MG to choose the type of termination correctly. > > Brian I know it's too late to change, but I must rant again: If the MGC KNOWS the type it wants, why can't it just TELL the MG. Making the MG deduce the type is stupid. Why send the MG any details? Make it deduce everything. "Read my mind." -troy P.S. I'm thinking of a number... From owner-megaco@fore.com Thu Jun 21 14:18:55 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA12124 for ; Thu, 21 Jun 2001 14:18:54 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA23433; Thu, 21 Jun 2001 14:00:11 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id NAA08536 for megaco-list; Thu, 21 Jun 2001 13:59:20 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA08528 for ; Thu, 21 Jun 2001 13:59:19 -0400 (EDT) Received: from ihemail2.firewall.lucent.com (ihemail2.lucent.com [192.11.222.163]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA23291 for ; Thu, 21 Jun 2001 13:59:13 -0400 (EDT) Received: from ihemail2.firewall.lucent.com (localhost [127.0.0.1]) by ihemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5LHxEH17983 for ; Thu, 21 Jun 2001 13:59:14 -0400 (EDT) Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3]) by ihemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5LHxDM17979 for ; Thu, 21 Jun 2001 13:59:13 -0400 (EDT) Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id NAA07866; Thu, 21 Jun 2001 13:58:45 -0400 (EDT) Cc: "Rosen, Brian" , "'Sarju Garg'" , "'megaco'" Received: from lucent.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id NAA07817; Thu, 21 Jun 2001 13:58:26 -0400 (EDT) Message-ID: <3B323546.B47BAB70@lucent.com> Date: Thu, 21 Jun 2001 13:56:22 -0400 From: Troy Cauble Reply-To: Troy Cauble X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Terry L Anderson Original-CC: "Rosen, Brian" , "'Sarju Garg'" , "'megaco'" Subject: Re: Allowed char set for Identifier References: <4FBEA8857476D311A03300204840E1CF044655BA@whq-msgusr-02.pit.comms.marconi.com> <3B3211CA.8180F217@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: 7bit If you restrict the first character, you will have to do it in Annex B also. -troy Terry L Anderson wrote: > > I agree. I believe the intent was do disallow the first character being > numeric. The second instance could be > "...consisting of alphanumeric characters, and possibly..." > or > "...consisting of alphabetic characters and/or digits, and possibly..." > or > or left alone as Brian suggests. I will make the first change and leave > the second as is unless folks write preferring one of the above. > > "Rosen, Brian" wrote: > > > A typo, it should use "alphabetic" for the first instance. I think > > the second canstand (alphanumeric = characters and/or digits).Terry, > > this is clearly an IG item.Brian > > > > -----Original Message----- > > From: Sarju Garg [mailto:sarju@bhartitelesoft.com] > > Sent: Thursday, June 21, 2001 8:54 AM > > To: 'megaco' > > Subject: Allowed char set for Identifier > > > > Hi all, I have a confusion in the allowed char set for > > Identifiers. In Sec 12.4, it says the following:Identifiers > > in text encoding shall be strings of up to 64 characters, > > containing no spaces, starting with an alphanumeric > > character and consisting of alphanumeric characters and / or > > digits, and possibly including the special character > > underscore ("_").Shouldn't be alphanumeric be alphabet > > here? Or if the above statement is true, then there should > > be no digits mentioned here. The text should be > > like:Identifiers in text encoding shall be strings of up to > > 64 characters, containing no spaces, starting with an > > alphanumeric character and consisting of alphanumeric > > characters, and possibly including the special character > > underscore ("_").TIASarju > > > -- > ------------------------------------------------------------ > Terry L Anderson mailto:tla@lucent.com > Tel:908.582.7013 Fax:908.582.6729 > Lucent Technologies/INS/Voice Over IP Access Networks > Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 > http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla From owner-megaco@fore.com Thu Jun 21 14:26:27 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA12640 for ; Thu, 21 Jun 2001 14:26:27 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA25001; Thu, 21 Jun 2001 14:16:51 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id OAA13253 for megaco-list; Thu, 21 Jun 2001 14:15:56 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA13236 for ; Thu, 21 Jun 2001 14:15:54 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 21 Jun 2001 14:15:52 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF044655CB@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Troy Cauble'" Cc: "'Sarju Garg'" , "'megaco'" Subject: RE: How to Determine the Termination Type Date: Thu, 21 Jun 2001 14:15:50 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Because we would have to define an entirely new syntax for termination type, with some kind of name space, and some rules for how to disambiguate types. I thought about it, but it turns out that any sane implementation has to verify all the things it now uses to deduce the type, and you don't actually save any code. Anyway, as you know, it's too late. Brian P.S. ?33? (I'm from Pittsburgh, it's real near Latrobe - which is pronounced "lay-trowb" -- home of Rolling Rock beer) > -----Original Message----- > From: Troy Cauble [mailto:troy@lucent.com] > Sent: Thursday, June 21, 2001 2:04 PM > To: Rosen, Brian > Cc: 'Sarju Garg'; 'megaco' > Subject: Re: How to Determine the Termination Type > > > > > > In most cases, you won't use $ with a physical termination > because it usually matters > > which physical port you want. > > > > However, the rule is that you must specify (using > local/remote) enough parameters > > to allow the MG to choose the type of termination correctly. > > > > Brian > > > I know it's too late to change, but I must rant again: > > If the MGC KNOWS the type it wants, why can't it just > TELL the MG. Making the MG deduce the type is stupid. > > Why send the MG any details? Make it deduce everything. > "Read my mind." > > -troy > > P.S. I'm thinking of a number... > From owner-megaco@fore.com Thu Jun 21 14:30:11 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA12891 for ; Thu, 21 Jun 2001 14:30:10 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA25343; Thu, 21 Jun 2001 14:18:48 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id OAA13633 for megaco-list; Thu, 21 Jun 2001 14:18:00 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA13626 for ; Thu, 21 Jun 2001 14:17:59 -0400 (EDT) Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA25167 for ; Thu, 21 Jun 2001 14:17:52 -0400 (EDT) Received: from auemail2.firewall.lucent.com (localhost [127.0.0.1]) by auemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5LIHrj29639 for ; Thu, 21 Jun 2001 14:17:53 -0400 (EDT) Received: from teton.mh.lucent.com (h135-3-130-2.lucent.com [135.3.130.2]) by auemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5LIHqR29619; Thu, 21 Jun 2001 14:17:52 -0400 (EDT) Received: from lucent.com ([135.3.128.238]) by teton.mh.lucent.com (8.8.8+Sun/8.8.8) with ESMTP id OAA13020; Thu, 21 Jun 2001 14:17:49 -0400 (EDT) Message-ID: <3B3239F6.BE41B63C@lucent.com> Date: Thu, 21 Jun 2001 14:16:23 -0400 From: Terry L Anderson Organization: Lucent Technologies X-Mailer: Mozilla 4.75 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Troy Cauble CC: "Rosen, Brian" , "'Sarju Garg'" , "'megaco'" Subject: Re: Allowed char set for Identifier References: <4FBEA8857476D311A03300204840E1CF044655BA@whq-msgusr-02.pit.comms.marconi.com> <3B3211CA.8180F217@lucent.com> <3B323546.B47BAB70@lucent.com> Content-Type: multipart/mixed; boundary="------------7F3E2DA09D1B69FD0CDF506F" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk This is a multi-part message in MIME format. --------------7F3E2DA09D1B69FD0CDF506F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Troy Cauble wrote: > If you restrict the first character, > you will have to do it in Annex B also. I believe it is. The statement were discussing is in 12.4 and so is referring to identifiers in packages. In Annex B this would be things like PackageName and ItemID (used in pkgdName), eventParameterName, etc. All these are NAME which is ALPHA *63(ALPHA / DIGIT / "_") so I believe this is consistent with restricting the first character to "alphabetic character". Have you noticed a place in Annex B that does not restrict? > > > -troy > > Terry L Anderson wrote: > > > > I agree. I believe the intent was do disallow the first character being > > numeric. The second instance could be > > "...consisting of alphanumeric characters, and possibly..." > > or > > "...consisting of alphabetic characters and/or digits, and possibly..." > > or > > or left alone as Brian suggests. I will make the first change and leave > > the second as is unless folks write preferring one of the above. > > > > "Rosen, Brian" wrote: > > > > > A typo, it should use "alphabetic" for the first instance. I think > > > the second canstand (alphanumeric = characters and/or digits).Terry, > > > this is clearly an IG item.Brian > > > > > > -----Original Message----- > > > From: Sarju Garg [mailto:sarju@bhartitelesoft.com] > > > Sent: Thursday, June 21, 2001 8:54 AM > > > To: 'megaco' > > > Subject: Allowed char set for Identifier > > > > > > Hi all, I have a confusion in the allowed char set for > > > Identifiers. In Sec 12.4, it says the following:Identifiers > > > in text encoding shall be strings of up to 64 characters, > > > containing no spaces, starting with an alphanumeric > > > character and consisting of alphanumeric characters and / or > > > digits, and possibly including the special character > > > underscore ("_").Shouldn't be alphanumeric be alphabet > > > here? Or if the above statement is true, then there should > > > be no digits mentioned here. The text should be > > > like:Identifiers in text encoding shall be strings of up to > > > 64 characters, containing no spaces, starting with an > > > alphanumeric character and consisting of alphanumeric > > > characters, and possibly including the special character > > > underscore ("_").TIASarju > > > > > -- > > ------------------------------------------------------------ > > Terry L Anderson mailto:tla@lucent.com > > Tel:908.582.7013 Fax:908.582.6729 > > Lucent Technologies/INS/Voice Over IP Access Networks > > Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 > > http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla -- ------------------------------------------------------------ Terry L Anderson mailto:tla@lucent.com Tel:908.582.7013 Fax:908.582.6729 Lucent Technologies/INS/Voice Over IP Access Networks Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla --------------7F3E2DA09D1B69FD0CDF506F Content-Type: text/x-vcard; charset=us-ascii; name="tla.vcf" Content-Description: Card for Terry L Anderson Content-Disposition: attachment; filename="tla.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Anderson;Terry L tel;fax:908.582.6729 tel;work:908.582.7013 x-mozilla-html:TRUE url:http://its.lucent.com/~tla org:Lucent / InterNetworking Systems;VoIP Access Networks version:2.1 email;internet:tla@lucent.com title:DMTS note:http://www.gti.net/tla or http://teton.mh.lucent.com/~tla (Lucent internal) adr;quoted-printable:;;Rm 2B-121=0D=0A600 Mountain Ave;Murray Hill;NJ;07974;USA x-mozilla-cpt:;7264 fn:Terry L Anderson end:vcard --------------7F3E2DA09D1B69FD0CDF506F-- From owner-megaco@fore.com Thu Jun 21 15:11:47 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14585 for ; Thu, 21 Jun 2001 15:11:47 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA29191; Thu, 21 Jun 2001 15:01:18 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id OAA24777 for megaco-list; Thu, 21 Jun 2001 14:59:31 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA24754 for ; Thu, 21 Jun 2001 14:59:28 -0400 (EDT) Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA28891 for ; Thu, 21 Jun 2001 14:59:21 -0400 (EDT) Received: from auemail2.firewall.lucent.com (localhost [127.0.0.1]) by auemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5LIxMj09589 for ; Thu, 21 Jun 2001 14:59:22 -0400 (EDT) Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3]) by auemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5LIxMR09560 for ; Thu, 21 Jun 2001 14:59:22 -0400 (EDT) Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id OAA13272; Thu, 21 Jun 2001 14:59:04 -0400 (EDT) Cc: "'megaco'" Received: from lucent.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id OAA13253; Thu, 21 Jun 2001 14:59:02 -0400 (EDT) Message-ID: <3B32437A.7BB720DB@lucent.com> Date: Thu, 21 Jun 2001 14:56:58 -0400 From: Troy Cauble Reply-To: Troy Cauble X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Terry L Anderson Original-CC: "'megaco'" Subject: Re: Allowed char set for Identifier References: <4FBEA8857476D311A03300204840E1CF044655BA@whq-msgusr-02.pit.comms.marconi.com> <3B3211CA.8180F217@lucent.com> <3B323546.B47BAB70@lucent.com> <3B3239F6.BE41B63C@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: 7bit Terry L Anderson wrote: > > Troy Cauble wrote: > > > If you restrict the first character, > > you will have to do it in Annex B also. > > I believe it is. You are correct. My mistake. From owner-megaco@fore.com Thu Jun 21 15:37:07 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA15495 for ; Thu, 21 Jun 2001 15:37:05 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA01458; Thu, 21 Jun 2001 15:27:21 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id PAA02175 for megaco-list; Thu, 21 Jun 2001 15:26:48 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA02169 for ; Thu, 21 Jun 2001 15:26:46 -0400 (EDT) Received: from vcnet.com (mail.vcnet.com [209.239.239.15]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with SMTP id PAA01373 for ; Thu, 21 Jun 2001 15:26:41 -0400 (EDT) Received: (qmail 69002 invoked from network); 21 Jun 2001 19:26:41 -0000 Received: from mail-fw1.peakss.com (HELO shane) (12.45.97.98) by mail.vcnet.com with SMTP; 21 Jun 2001 19:26:41 -0000 Message-Id: <4.2.0.58.20010621121719.01466eb0@64.60.54.225> X-Sender: shawkins@64.60.54.225 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 21 Jun 2001 12:20:37 -0700 To: megaco@fore.com From: "Shane V. Hawkins" Subject: Looking for information Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk I have been asked to support R2 DLB function and can find no references within ITU, ETSI, etc. Thinking it is another name for some R2/MFC derivative..... Has anyone ever heard of R2 DLB? Thank you in advance for any information provided. shane- From owner-megaco@fore.com Thu Jun 21 20:40:35 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA22042 for ; Thu, 21 Jun 2001 20:40:34 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA19065; Thu, 21 Jun 2001 20:31:40 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id UAA23991 for megaco-list; Thu, 21 Jun 2001 20:30:01 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA23987 for ; Thu, 21 Jun 2001 20:30:00 -0400 (EDT) From: TimeForAChange@real.com Received: from yourwebsite.com (24.100.115.107.on.wave.home.com [24.100.115.107]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with SMTP id UAA18911 for ; Thu, 21 Jun 2001 20:29:51 -0400 (EDT) Message-Id: <200106220029.UAA18911@mailgate.pit.comms.marconi.com> Reply-To: kchmystery@yahoo.com To: megaco@fore.com Subject: Don't take my word for it Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 21 Jun 2001 20:27:50 -0400 Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Earn up to $500K in 120 Days Sending Email!! > ________________________________________________________________________________ Note Transmissions to you by the sender of 'this' email will be stopped promptly by sending an e-mail with "unsubscribe" in the subject line. Simply hit reply and send and we will remove you from our database. Please Note-This is a one time mailing.Thank you. ________________________________________________________________________________ > >Excuse us for bothering you but we would like to share our >good luck with everybody. > >My wife received this e-mail and forwarded it to me to review. >We've both read completely through it and have been in contact >with some of the individuals listed below. > >We think it's an excellent opportunity that is well worth the small >investment of time and money, and believe that you will, too! > > >===== PRINT THIS NOW FOR YOUR FUTURE REFERENCE ====== >If you would like to make at least $500,000 every 4 to 5 months easily and >comfortably, please read the following... > >THEN READ IT AGAIN and AGAIN!!! > > >FOLLOW THE SIMPLE INSTRUCTIONS BELOW AND YOUR FINANCIAL >DREAMS WILL COME TRUE, GUARANTEED! > >INSTRUCTIONS: >Order all 5 reports shown on the list below > >For each report, send $5 CASH, THE NAME & NUMBER OF THE REPORT >YOU ARE ORDERING and YOUR E-MAIL ADDRESS to the person whose >name appears ON THAT LIST next to the report. MAKE SURE YOUR RETURN >ADDRESS IS ON YOUR ENVELOPE TOP LEFT CORNER in case of any mail >problems. > >When you place your order, make sure you order each of the 5 reports. > > >You will need all 5 reports so that you can save them on your computer >and resell them. YOUR TOTAL COST $5 X 5=$25.00. > >Within a few days you will receive, vie e-mail, each of the 5 re ports from >these 5 different individuals. Save them on your computer so they will be >accessible for you to send to the 1,000's of people who will order them >from you. Also make a floppy of these reports and keep it on your desk in >case something happens to your computer. > > >IMPORTANT - DO NOT alter the names of the people who are listed next >to each report, or their sequence on the list, in any way other than what is >instructed below in step '' 1 through 6 '' or you will loose out on a >majority of your profits. Once you understand the way this works, >you will also see how it does not work if you change it. Remember, >this method has been tested, and if altered, it will NOT work !!! >People have tried to put their friends/relatives names on all five thinking >they could get all the money. But it does not work this way. Believe us, >and Do Not try to change anything other than what is instructed. If you do, >it will not work for you. >Remember, honesty reaps the reward!!! > > > > > >1.... After you have ordered all 5 reports, take this advertisement and >REMOVE the name & address of the person in REPORT # 5. This person >has made it through the cycle and is no doubt counting their fortune > > >2....Move the name & address in REPORT # 4 down toREPORT # 5. > > >3....Move the name & address in REPORT # 3 down TO REPORT # 4. > > >4....Move the name & address in REPORT # 2 downTO REPORT # 3. > > >5.... Move the name & address in REPORT # 1 down TO REPORT # 2 > > >6.... Insert YOUR name & address in the REPORT # 1 Position. PLEASE MAKE >SURE you copy every name & address ACCURATELY! >****Take this entire letter, with the modified list of names, and save it on >your computer. DO NOT MAKE ANY OTHER CHANGES. > > >Save this on a disk as well, just in case you loose any data. To assist you >with marketing your business on the internet, the 5 reports you purchase >will provide you with invaluable marketing information which includes how >to send bulk e-mails legally, where to find thousands of free classified ads >and much more. > > >There are 2 Primary methods to get this venture going: > > >METHOD # 1:BY SENDING BULK E-MAIL LEGALLY > >Let's say that you decide to start small, just to see how it goes, and we >Will assume you and those involved send out only 5,000 e-mails each. Let's >also assume that the mailing receive only a 0.2% response (the response >could be much better but lets just say it is only 0.2%. Also many people >will send out hundreds of thousands e-mails instead of only 5,000 each). >Continuing with this example, you send out only 5,000 e-mails. With a 0.2% >response, that is only 10 orders for report # 1. Those 10 people responded >by sending out 5,000 e-mail each for a total of 50,000. Out of those 50,000 >e-mails only 0.2% responded with orders. That's=100 people responded and >ordered Report # 2. > > >Those 100 people mail out 5,000 e-mails each for a total of 500,000 >e-mails. The 0.2% response to that is 1000 orders for Report # 3. > > >Those 1000 people send out 5,000 e-mails each for a total of 5 million >e-mails sent out. The 0.2% response to that is 10,000 orders for Report # >4. > > >Those 10,000 people send out 5,000 e-mails each for a total of 50,000,000 >(50 million) e-mails. > > > >The 0.2% response to that is 100,000 orders for Report # 5 > > THAT'S 100,000 ORDERS TIMES $5 EACH=$500,000.00 (half million). >Your total income in this example is: 1..... $50 + 2..... $500 + 3..... >$5,000 + 4 .... $50,000 + 5..... $500,000 ........ Grand Total=$555,550.00 > > >NUMBERS DO NOT LIE. GET A PENCIL & PAPER AND FIGURE OUT >THE WORST POSSIBLE RESPONSES AND NO MATTER HOW YOU >CALCULATE IT, YOU WILL STILL MAKE A LOT OF MONEY ! > > > >REMEMBER FRIEND, THIS IS ASSUMING ONLY 10 PEOPLE >ORDERING OUT OF 5,000 YOU MAILED TO. > >Dare to think for a moment what would happen if everyone or half or even >one 4th of those people mailed 100,000 e-mails each or more? There are >over 150 million people on the Internet worldwide and counting. Believe me, >many people will do just that, and more! > > > >METHOD # 2 : BY PLACING FREE ADS ON THE INTERNET >Advertising on the net is very very inexpensive and there are hundreds >of FREE places to advertise. Placing a lot of free ads on the Internet will >easily get a larger response. We strongly suggest you start with Method # 1 >and add METHOD # 2 as you go along. For every $5 you receive, all you >must do is e-mail them the Report they ordered. That's it. Always provide >same day service on all orders. > >This will guarantee that the e-mail they send out, with your name and >address on it, will be prompt because they can not advertise until they >receive the report. > > >========= AVAILABLE REPORTS ============= >ORDER EACH REPORT BY ITS NUMBER & NAME ONLY. Notes: > >============================================== >Always send $5 cash (U.S. CURRENCY only) for each Report. > >Checks NOT accepted. >Make sure the cash is concealed by wrapping it in at least 2 sheets >of paper. > > On one of those sheets of paper, Write > > a.The NUMBER & the NAME of the Report > > you are ordering, > > b. YOUR E-MAIL ADDRESS and > > c. your name and postal address. > > (In case of mail difficulties.) > > >PLACE YOUR ORDER FOR THESE REPORTS NOW : > >REPORT # 1: "The Insider's Guide to Advertising for Free on the Net" >Order Report #1 from: >Kerry G. >PO Box 210132 >San Francisco, CA 94121 >USA >_________________________________________________________ >REPORT # 2: "The Insider's Guide to Sending Bulk e-mail on the Net" >Order Report # 2 from: >P.Harry >P.O. Box 470015 >Brooklyn, NY 11247 > USA >__________________________________________________________ >REPORT # 3: "Secret to Multi-Level Marketing on the Net" >Order Report # 3 from: >Mary Morgan >12 Condotti Drive >Woodbridge, Ontario, L4H 2C8 >Canada >__________________________________________________________ >REPORT # 4: "How to Become a Millionaire Utilizing MLM & the Net" >Order Report # 4 from: >D. Harris >6717 Main Street >Stouffville, ON L4A 6B3 >Canada >__________________________________________________________ >REPORT #5: "How to Send Out One Million e-mails for Free" >Order Report # 5 from: >Christa H >6021 Yonge Street, Ste. 1021 >Toronto, ON M2M 3W2 >Canada > >_________________________________________________________ >You can KEEP TRACK of your PROGRESS by watching which report >people are ordering from you. IF YOU WANT TO GENERATE MORE >INCOME SEND ANOTHER BATCH OF E-MAILS AND START >THE WHOLE PROCESS AGAIN. >_________________________________________________________ >$$$$$$$$$YOUR SUCCESS GUIDELINES $$$$$$$$$$$ > > >Follow these guidelines to guarantee your success: > > >=== If you do not receive at least 10 orders for Report #1 within 2 >weeks, continue sending e-mails until you do. > > >=== After you have received 10 orders, 2 to 3 weeks after that you >should receive 100 orders or more for REPORT # 2. If you did not, >continue advertising or sending e-mails until you do. > > >=== Once you have received 100 or more orders for Report # 2, YOU >CAN RELAX, because the system is already working for you, and the >cash will continue to roll in ! THIS IS IMPORTANT TO REMEMBER: >Every time your name is moved down on the list, you are placed in front >of a Different report. > > >There is NO LIMIT to the income you can generate from this business !!! > > >=============================================== > > >FOLLOWING IS A NOTE FROM THE ORIGINATOR OF THIS >PROGRAM: > >You have just received information that can give you >financial freedom for the rest of your life, with NO RISK and JUST >A LITTLE BIT OF EFFORT. You can make more money in the next >few weeks and months than you have ever imagined. Follow the program >EXACTLY AS INSTRUCTED. Do Not change it in any way. It works >exceedingly well as it is now. > > >Remember to e-mail a copy of this exciting report after you have put >your name and address in Report #1 and moved others to #2 ..........# 5 >as instructed above. One of the people you send this to may send out >100,000 or more e-mails and your name will be on every one of them. >Remember though, the more you send out the more potential customers >you will reach. > > >So my friend, I have given you the ideas, information, materials and >opportunity to become financially independent. IT IS UP TO YOU NOW ! > > >============ TESTIMONIALS ================ > >This is what one had to say: ''Thanks to this profitable opportunity. I >was approached many times before but each time I passed on it. I am >so glad I finally joined just to see what one could expect in return for the >minimal effort and money required. > >To my astonishment, I received total $610,470.00 in 21 weeks, >with money still coming in." >Pam Hedland, Fort Lee, New Jersey > > >Here is another testimonial: > >"This program has been around for a long time but I never believed >in it. But one day when I received this again in the mail I decided to >gamble my $25 on it. I followed the simple instructions and walaa >..... 3 weeks later the money started to come in. > >First month I only made $240.00 but the next 2 months after that I made >a total of $290,000.00. So far, in the past 8 months by re-entering the >program, I have made over $710,000.00 and I am playing it again. The >key to success in this program is to follow the simple steps and NOT change >anything.'' > > >"My name is Mitchell. My wife, Jody and I live in Chicago. I am an >accountant with a major U.S. Corporation and I make pretty good money. >When I received this program I grumbled to Jody about receiving ''junk >mail''. I made fun of the whole thing, spouting my knowledge of the >population and percentages involved. I ''knew'' it wouldn't work. >Jody totally ignored my supposed intelligence and a few days later >she jumped in with both feet. > >I made merciless fun of her, and was ready to lay the old ''I told you so'' on >her when the thing didn't work. Well, the laugh was on me! Within 3 weeks >she had received 50 responses. Within the next 45 days she had received >total $ 147,200.00 ........... all cash! I was shocked. I have joined Jody >in her ''hobby''. > >Mitchell Wolf M.D., Chicago, Illinois > >================================================ > > >''Not being the gambling type, it took me several weeks to make up my >mind to participate in this plan. But conservative that I am, I decided that >the initial investment was so little that there was just no way that I >wouldn't get enough orders to at least get my money back''. '' I was >surprised when I found my medium size post office box crammed with >orders. I made $319,210.00 in the first 12 weeks. The nice thing about >this deal is that it does not matter where people live. There simply isn't a >better investment with a faster return and so big." >Dan Sondstrom, Alberta, Canada > > >================================================ >''I had received this program before. I deleted it, but later I wondered >if I should have given it a try. Of course, I had no idea who to contact to >get another copy, so I had to wait until I was e-mailed agai n by someone >else.........11 months passed then it luckily came again...... I did not >delete this one! I made more than $490,000 on my first try and all the >money came within 22 weeks." >Susan De Suza, New York, N.Y. > > >================================================= > > >''It really is a great opportunity to make relatively easy money with >little cost to you. I followed the simple instructions carefully and >within 10 days the money started to come in. My first month I made >$20,560.00 and by the end of third month my total cash count was >$362,840.00. Life is beautiful, Thanks to internet.". >Fred Dellaca, Westport, New Zealand > > >================================================= >ORDER YOUR REPORTS TODAY AND GET STARTED ON >'YOUR' ROAD TO FINANCIAL FREEDOM ! >================================================= > > >About 50,000 new people get online every month! >_______________________________________________________ > > > > >FOR YOUR INFORMATION.... >If you need help with starting a business, registering a business name, >learning how income tax is handled, etc., contact your local office of the >Small Business Administration (a Federal agency) 1-(800)827-5722 for free >help and answers to questions. Also, the Internal Revenue Service offers >free help via telephone and free seminars about business tax requirements. > >Under Bill S1618 Title III passed by the 105th US Congress this letter >cannot be considered spam as long as the sender includes contact >information >and a method of removal. This is a one-time e-mail transmission. No request >for removal is necessary. > >If you have any questions of the legality of this program, contact the >Office of Associate Director for Marketing Practices, Federal Trade >Commission, Bureau of Consumer Protection, Washington, D.C. > > Transmissions to you by the sender of 'this' email will be stopped promptly by sending an e-mail with "unsubscribe" in the subject line. Simply hit reply and send and we will remove you from our database. Please Note-This is a one time mailing.Thank you. From owner-megaco@fore.com Thu Jun 21 22:02:04 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA24727 for ; Thu, 21 Jun 2001 22:02:04 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id VAA21251; Thu, 21 Jun 2001 21:53:17 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id VAA29420 for megaco-list; Thu, 21 Jun 2001 21:51:47 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id VAA29416 for ; Thu, 21 Jun 2001 21:51:46 -0400 (EDT) Received: from smtp.huawei.com ([202.96.135.132]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id VAA21151 for ; Thu, 21 Jun 2001 21:51:37 -0400 (EDT) Received: from q17326 ([10.11.1.164]) by smtp.huawei.com (Netscape Messaging Server 4.15) with SMTP id GFB68Q02.P0K for ; Fri, 22 Jun 2001 09:46:02 +0800 Message-ID: <000501c0fabd$c3efa7c0$a4010b0a@huawei.com.cn> From: "Qiu Xiuping" To: Subject: E.6.2 Events : digit map parameter definition Date: Fri, 22 Jun 2001 09:50:50 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mailman.pit.comms.marconi.com id VAA29417 Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: 8bit Hi, Dear all. In RFC 3015. ====================================================================== E.6.2 Events ------------------------- EventID: ce, 0x0001 Generated when a digit map completes as described in section 7.1.14. EventsDescriptor parameters: digit map processing is activated only if a digit map parameter is present, specifying a digit map by name or by value. Other parameters such as a KeepActive flag or embedded Events or Signals Descriptors may be present. ======================================================================= It's said that "if a digit map parameter is present", but the digit map parameter is not defined here. I think there should a definition like: name, ID, Type , Possible values, Description and so on. Where's it? Thank you, Qiu Xiuping _______________________________________________ Huawei Technologies Co., Ltd. Room 5707,Keji Building, Kefa Road Science-Based Industrial Park Nanshan District, Shenzhen 518057, P.R.China Tel : +86-755-6544 509 _______________________________________________ From owner-megaco@fore.com Thu Jun 21 23:07:27 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA26596 for ; Thu, 21 Jun 2001 23:07:27 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id WAA23224; Thu, 21 Jun 2001 22:57:43 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id WAA03610 for megaco-list; Thu, 21 Jun 2001 22:56:24 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id WAA03606 for ; Thu, 21 Jun 2001 22:56:22 -0400 (EDT) Received: from wiproecmx2.wipro.com (wiproecmx2.wipro.com [164.164.31.6]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id WAA23134 for ; Thu, 21 Jun 2001 22:56:12 -0400 (EDT) Received: from m2vwall2.wipro.com ([164.164.27.52]) by wiproecmx2.wipro.com (8.11.3/8.11.3) with SMTP id f5M8aTn23908 for ; Fri, 22 Jun 2001 08:36:29 GMT Received: from wslexch.wipsys.soft.net ([192.219.223.59]) by kmglmail.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GFB9HD00.4D1; Fri, 22 Jun 2001 08:26:01 +0530 Received: from wipro.com (bheeshma.wipsys.soft.net [164.164.24.251]) by wslexch.wipsys.soft.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id NK5XMSAS; Fri, 22 Jun 2001 08:38:20 +0530 Message-ID: <3B32B147.448C59AC@wipro.com> Date: Fri, 22 Jun 2001 08:15:28 +0530 From: Narayanan Nadadhur Organization: Wipro Technologies X-Mailer: Mozilla 4.75 [en] (X11; U; HP-UX B.10.20 9000/820) X-Accept-Language: en MIME-Version: 1.0 To: "Shane V. Hawkins" CC: megaco@fore.com Subject: Re: Looking for information References: <4.2.0.58.20010621121719.01466eb0@64.60.54.225> Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="------------F6B5F3CA748CA34316600E84" --------------F6B5F3CA748CA34316600E84 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, R2 DLB is the term mainly used in National markets. In the market where it is used the DLB function means support of all the Basic Line Signals specified by ITU. Metering pulses and Forced Release signal are not supported as part of DLB function. Hope it answers your queries. Regards Narayanan "Shane V. Hawkins" wrote: > I have been asked to support R2 DLB function and can find no references > within ITU, ETSI, etc. > > Thinking it is another name for some R2/MFC derivative..... > > Has anyone ever heard of R2 DLB? > > Thank you in advance for any information provided. > > shane- -- ----------------------------------------------------------------------- There is no pleasure in having nothing to do; the fun is in having lots to do and not doing it. --------------F6B5F3CA748CA34316600E84 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi,
    R2 DLB is the term mainly used in National markets. In the market where it is used the
DLB function means support of all the Basic Line Signals specified by ITU.
Metering pulses and Forced Release signal are not supported as part of DLB function.

Hope it answers your queries.

Regards
Narayanan
 

"Shane V. Hawkins" wrote:

I have been asked to support R2 DLB function and can find no references
within ITU, ETSI, etc.

Thinking it is another name for some R2/MFC derivative.....

Has anyone ever heard of R2 DLB?

Thank you in advance for any information provided.

shane-

-- 
-----------------------------------------------------------------------
            There is no pleasure in having nothing to do;
            the fun is in having lots to do and not doing it.
  --------------F6B5F3CA748CA34316600E84-- --------------InterScan_NT_MIME_Boundary-- From owner-megaco@fore.com Fri Jun 22 01:00:10 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA28269 for ; Fri, 22 Jun 2001 01:00:09 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id AAA25969; Fri, 22 Jun 2001 00:51:05 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id AAA09435 for megaco-list; Fri, 22 Jun 2001 00:49:14 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id AAA09427 for ; Fri, 22 Jun 2001 00:49:12 -0400 (EDT) Received: from newish7.ericsson.com.au ([203.61.155.116]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id AAA25725 for ; Fri, 22 Jun 2001 00:48:59 -0400 (EDT) Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10]) by newish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id OAA27940; Fri, 22 Jun 2001 14:47:31 +1000 (EST) Received: from ericsson.com (mcdh126.epa.ericsson.se [146.11.81.126]) by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id OAA06628; Fri, 22 Jun 2001 14:48:25 +1000 (EST) Message-ID: <3B32A398.C2BF2C96@ericsson.com> Date: Fri, 22 Jun 2001 11:47:04 +1000 From: Christian Groves X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Terry L Anderson CC: "Rosen, Brian" , "'Nitin Kumar'" , "'megaco@fore.com'" Subject: Re: Few clarification in RFC3015 References: <4FBEA8857476D311A03300204840E1CF044655B3@whq-msgusr-02.pit.comms.marconi.com> <3B311B33.D6CFA912@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: 7bit G'Day, Why should we make this change if the it currently says so in the text? This seems to me that we're adding things just for changes sake. Not all questions to this list have result in a change in the IG. Cheers, Christian Terry L Anderson wrote: > > "Rosen, Brian" wrote: > > > Hmmm, maybe we should edit that text to say: > > "Actions in a transaction and commands within an action are > > executed sequentially in the order they appear in the transaction." > > > > Terry? > > That is certainly the intent and the way I would read the current text > ("commands in order" - the fact that they are grouped into actions doesn't > alter their order). But your text is certainly more explicit. I have no > trouble with it. I'll put it in. > > > > > > > "Normal Repitition timers" are the timer values defined in D.1.3 > > > > Brian > > > > > -----Original Message----- > > > From: Nitin Kumar [mailto:nitin@indts.com] > > > Sent: Wednesday, June 20, 2001 2:32 PM > > > To: 'megaco@fore.com' > > > Subject: Few clarification in RFC3015 > > > > > > > > > Hi Folks, > > > > > > Just looking for following clarification. > > > > > > 1. In a TransactionRequest, are ActionRequests processed in > > > order or only > > > Commands in an ActionRequest are executed sequencially ? RFC > > > says "Commands > > > within a Transaction are executed sequentially." > > > > > > 2. Few lines from the RFC on page number 135, section D.1.4.. > > > "Upon receipt of a final response following receipt of > > > provisional responses, an immediate confirmation shall be sent, and > > > normal repetition timers shall be used thereafter." > > > > > > Now what does "normal repetition timers shall be used > > > thereafter" mean in > > > above extract? > > > > > > i hope to receive some insights. > > > > > > regards, > > > > > > -nitin > > > > > > Ind Telesoft Pvt. Ltd. > > > 104, Koramangla Industrial Estate, > > > 5th Block, Bangalore 560 095 > > > Tel : 5508930, 5521937, 5529758-62 ext-259 > > > Fax : 5521164 > > > mailto:nitin@indts.com > > > http:\\www.telesoftinc.com > > > > > -- > ------------------------------------------------------------ > Terry L Anderson mailto:tla@lucent.com > Tel:908.582.7013 Fax:908.582.6729 > Lucent Technologies/INS/Voice Over IP Access Networks > Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 > http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla From owner-megaco@fore.com Fri Jun 22 01:00:28 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA28280 for ; Fri, 22 Jun 2001 01:00:28 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id AAA26002; Fri, 22 Jun 2001 00:51:17 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id AAA09434 for megaco-list; Fri, 22 Jun 2001 00:49:14 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id AAA09425 for ; Fri, 22 Jun 2001 00:49:12 -0400 (EDT) Received: from newish7.ericsson.com.au ([203.61.155.116]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id AAA25724 for ; Fri, 22 Jun 2001 00:48:59 -0400 (EDT) Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10]) by newish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id OAA27946; Fri, 22 Jun 2001 14:47:31 +1000 (EST) Received: from ericsson.com (mcdh126.epa.ericsson.se [146.11.81.126]) by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id OAA06632; Fri, 22 Jun 2001 14:48:25 +1000 (EST) Message-ID: <3B32A42B.2D53A854@ericsson.com> Date: Fri, 22 Jun 2001 11:49:31 +1000 From: Christian Groves X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Terry L Anderson CC: Megaco Mailing List Subject: Re: NotifyCompletion and g/sc Meth References: <3B30B36F.C3F79AA2@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: 7bit G'Day Terry, I would have still been happy with "Duration expired" but your update does cover "ended on its own more explicitely". Cheers, Christian Terry L Anderson wrote: > > NotifyCompletion reasons and g/sc{Meth=XX} codes are abviously paired. > TimeOut -- TO Duration expired > IntByEvent -- EV Interrupted by event > IntBySigDescr -- SD Halted by new Signals Descriptor > OtherReason -- NC Not completed, other cause > > What is not so clear is which of these is appropriate for the case of a > signal that "plays to completion" for reasons other than time, e.g., a > voice announcement file. The use of OtherReason/NC does not seem > appropriate, since this is usually used for errors and it controdicts > the "not completed" text. Such signals could be of type "brief" or time > "timeout". I believe that TimeOut/TO is the most appropriate, in spite > of time not being the real cause and in private discussions, others > suggest that this was the original intent. > > The choice of words for the reason is unfortunate - NormalCompletion > might have been clearer. The "Duration expired" is more applicable than > the "TimeOut". I suggest we add language to make it clear that this is > the correct reason. > > 7.1.11 3rd paragraph > change the sentence to: > The possible cases are that the signal timed out (or otherwise ended on > its own), that it was interrupted ... > > E.1.2 change the text after "TO" in Meth to > "TO" (0x0001) Signal Timed out or otherwise ended on its own. > > I will add this to the Implementors Guide unless there is an objection. > > -- > ------------------------------------------------------------ > Terry L Anderson mailto:tla@lucent.com > Tel:908.582.7013 Fax:908.582.6729 > Lucent Technologies/INS/Voice Over IP Access Networks > Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 > http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla From owner-megaco@fore.com Fri Jun 22 01:00:46 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA28292 for ; Fri, 22 Jun 2001 01:00:46 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id AAA26104; Fri, 22 Jun 2001 00:51:51 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id AAA09467 for megaco-list; Fri, 22 Jun 2001 00:50:05 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id AAA09463 for ; Fri, 22 Jun 2001 00:50:04 -0400 (EDT) Received: from newish7.ericsson.com.au ([203.61.155.116]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id AAA25737 for ; Fri, 22 Jun 2001 00:49:52 -0400 (EDT) Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10]) by newish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id OAA27964; Fri, 22 Jun 2001 14:47:36 +1000 (EST) Received: from ericsson.com (mcdh126.epa.ericsson.se [146.11.81.126]) by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id OAA06646; Fri, 22 Jun 2001 14:48:29 +1000 (EST) Message-ID: <3B32AB31.CDEBF7CE@ericsson.com> Date: Fri, 22 Jun 2001 12:19:29 +1000 From: Christian Groves X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Terry L Anderson CC: Megaco Mailing List Subject: Re: Continuity Test Package reference References: <3B2F7053.6880C6BC@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: 7bit G'Day Terry, You could try adding it as a note. Its informative then and no ITU impementations could also use this package. If you add an normative note then you tie this to the ITU, not that I think that's a bad thing. Christian Terry L Anderson wrote: > > E.10 Basic Continuity Package has no reference to a source for detail of > the ct tone, the "appropriate response tone" in rsp for 2-wire circuits > and other details of the test procedures. I believe the correct > reference is Q.724 Section 7 & 8. I propose adding: > > Tones and test procedure details are given in Q.724 sections 7 and > 8. > > to the description in sec E.10 and the formal reference to Sec 2.1 > Normative references through the Implementors Guide. Can we make only > sections 7 & 8 normative? > > Any objections? > > -- > ------------------------------------------------------------ > Terry L Anderson mailto:tla@lucent.com > Tel:908.582.7013 Fax:908.582.6729 > Lucent Technologies/INS/Voice Over IP Access Networks > Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 > http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla From owner-megaco@fore.com Fri Jun 22 01:02:19 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA28338 for ; Fri, 22 Jun 2001 01:02:18 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id AAA26129; Fri, 22 Jun 2001 00:51:59 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id AAA09474 for megaco-list; Fri, 22 Jun 2001 00:50:08 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id AAA09470 for ; Fri, 22 Jun 2001 00:50:07 -0400 (EDT) Received: from newish7.ericsson.com.au ([203.61.155.116]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id AAA25738 for ; Fri, 22 Jun 2001 00:49:54 -0400 (EDT) Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10]) by newish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id OAA27969; Fri, 22 Jun 2001 14:47:38 +1000 (EST) Received: from ericsson.com (mcdh126.epa.ericsson.se [146.11.81.126]) by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id OAA06656; Fri, 22 Jun 2001 14:48:32 +1000 (EST) Message-ID: <3B32ABCC.D0BA826D@ericsson.com> Date: Fri, 22 Jun 2001 12:22:04 +1000 From: Christian Groves X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Terry L Anderson CC: Megaco Mailing List Subject: Re: TimeStamp Optional in Notify ObservedEventsDescriptor References: <3B2F5F2D.9DF0298E@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: 7bit G'Day Terry, No problem with the change as it aligns the procedures with the syntax. Christian Terry L Anderson wrote: > > I believe that TimeStamp is intended to be optional in ObservedEvents > Descriptor. Both ABNF and ASN.1 have the element > optional, but no where is this suggested in the text. Section 7.1.17 > and 7.2.7 both mention time as one of the contents of ObservedEvents > with no suggestion that it is optional. If the intention was to make it > optional, seems like the text should mention that. > > Section 7.2.7 includes: > > Each event in the list is accompanied by parameters associated with > the event and an indication of the time that the event > was detected. > > which doesn't sound very optional and the statement in 7.1.17 includes > it in a list where all other items are required. If we agree it should > be optional I suggest clarifying this through the Implementors Guide. > > Sentence in 7.2.7 would read: > > Each event in the list is accompanied by parameters associated > with the event and optionally an indication of the time that > the event was detected. > > 7.1.17 to read: > > ObservedEvents contains the RequestIdentifier of the > EventsDescriptor that triggered the notification, the event(s) > detected, optionally the detection time(s) and any parameters > of the event. > > To be more complete I'm also suggested adding meantion of the parameters > here. > > Any objection? > -- > ------------------------------------------------------------ > Terry L Anderson mailto:tla@lucent.com > Tel:908.582.7013 Fax:908.582.6729 > Lucent Technologies/INS/Voice Over IP Access Networks > Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 > http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla From owner-megaco@fore.com Fri Jun 22 01:02:47 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA28353 for ; Fri, 22 Jun 2001 01:02:46 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id AAA26186; Fri, 22 Jun 2001 00:52:18 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id AAA09484 for megaco-list; Fri, 22 Jun 2001 00:50:11 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id AAA09479 for ; Fri, 22 Jun 2001 00:50:10 -0400 (EDT) Received: from newish7.ericsson.com.au ([203.61.155.116]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id AAA25739 for ; Fri, 22 Jun 2001 00:49:56 -0400 (EDT) Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10]) by newish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id OAA27956; Fri, 22 Jun 2001 14:47:35 +1000 (EST) Received: from ericsson.com (mcdh126.epa.ericsson.se [146.11.81.126]) by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id OAA06636; Fri, 22 Jun 2001 14:48:26 +1000 (EST) Message-ID: <3B32A581.A846A30@ericsson.com> Date: Fri, 22 Jun 2001 11:55:13 +1000 From: Christian Groves X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Rosen, Brian" CC: "'Sarju Garg'" , "'megaco'" Subject: Re: Property Characteristics References: <4FBEA8857476D311A03300204840E1CF044655A1@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: 7bit G'Day, I think the text should stay as stands in H.248. Christian From owner-megaco@fore.com Fri Jun 22 04:18:27 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA14517 for ; Fri, 22 Jun 2001 04:18:27 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id EAA02084; Fri, 22 Jun 2001 04:09:37 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id EAA22469 for megaco-list; Fri, 22 Jun 2001 04:06:48 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id EAA22464 for ; Fri, 22 Jun 2001 04:06:47 -0400 (EDT) Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id EAA01895 for ; Fri, 22 Jun 2001 04:06:42 -0400 (EDT) Received: from hoemail2.firewall.lucent.com (localhost [127.0.0.1]) by hoemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5M86hg08236 for ; Fri, 22 Jun 2001 04:06:43 -0400 (EDT) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5M86hG08220 for ; Fri, 22 Jun 2001 04:06:43 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2650.21) id ; Fri, 22 Jun 2001 10:06:42 +0200 Message-ID: From: "Bemmel, Jeroen van (Jeroen)" To: "'megaco@fore.com'" Date: Fri, 22 Jun 2001 10:06:40 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk unsubscribe From owner-megaco@fore.com Fri Jun 22 04:21:30 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA14540 for ; Fri, 22 Jun 2001 04:21:29 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id EAA02392; Fri, 22 Jun 2001 04:12:39 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id EAA22983 for megaco-list; Fri, 22 Jun 2001 04:11:46 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id EAA22970 for ; Fri, 22 Jun 2001 04:11:44 -0400 (EDT) Received: from cvis21.Marconicomms.com (cvis21.marconicomms.com [195.99.244.53] (may be forged)) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id EAA02260 for ; Fri, 22 Jun 2001 04:11:34 -0400 (EDT) Received: from cvis01.gpt.co.uk (unverified) by cvis21.Marconicomms.com (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Fri, 22 Jun 2001 09:11:12 +0100 Received: from marconicomms.com by cvis01.gpt.co.uk with SMTP (8.8.8+Sun/cvms-32) id JAA02573; Fri, 22 Jun 2001 09:11:23 +0100 (BST) Received: by marconicomms.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 80256A73.002CDBFF ; Fri, 22 Jun 2001 09:09:58 +0100 X-Lotus-FromDomain: MCMAIN@MCEXT From: "Sean Leahy" To: "Brian Rosen" cc: megaco@fore.com Message-ID: <80256A73.002CBCDF.00@marconicomms.com> Date: Fri, 22 Jun 2001 09:09:00 +0100 Subject: RE: Ephemeral Termination Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Brian, Just a question. There may be cases where Megaco is being used solely for bearer control and the call control/digit analysis is conducted at a layer above the Megaco protocol. In these circumstances, it is also possible that ephemerals are added and modified by command from the MGC when the bearer connection is actually between two physical terminations on the same Media Gateway. Is it altogether impossible for a Media Gateway to optimise such a hair-pin connection whilst maintaining the same model to the MGC ? Sean Leahy Marconi CN=Brian Rosen/OU=MAIN/O=MC1@MSEXCH on 21/06/2001 15:56:23 To: "'PSK Chakravarthi'" , "'Madhu Babu Brahmanapally'" , "'Terry L Anderson'" cc: megaco@fore.com(bcc: Sean Leahy/MAIN/MC1) Subject: RE: Ephemeral Termination I'm having trouble following your logic. This seems to be a trunk GW/ISUP issue, so we don't have to deal with off hook/DTMF issues, right? In the case of hairpin, you need two commands: 1) An add to put the originating termination in the context 2) An add to put the terminating termination in the context. They cannot be in the same transaction if you have not completed digit analysis before you do 1. In the case of a normal connection between two MGs you need 4 total commands: 1) The Add of the physical in the originating MG 2) The Add of the ephemeral in the originating MG 3) The Add of the physical in the terminating MG 4) The Add of the ephemeral in the terminating MG You can do 1 before you do digit analysis. You have to do 3 and 4 after digit analysis, but they can be in the same transaction. If you do 2 before you do digit analysis, you would not have the correct remote SDP, and therefore you would need to send a Modify after digit analysis. If you do it after you do digit analysis, then you only have the 4 commands. Before digit analysis, the MGC sends 1. After digit analysis the MGC sends two transactions in two messages; one to the originating MG (message 2 containing correct local and remote SDP) and one to the terminating MG (with messages 3 and 4 including all the SDP). In most cases, I suspect it would actually be more efficient to send message 1 after digit analysis, because then the originating MG has one less transaction to process, but the same number of commands. The call setup difference between the originating MG doing one add before digit analysis and another after vs doing both after won't matter enough to be measurable I think, but the difference in processing of half the number of messages will be substantial. I see no way to have the Add of the ephemeral before digit analysis improve call setup time. It seems to only create extra work for the originating MG. Brian > -----Original Message----- > From: PSK Chakravarthi [mailto:chak@axes-mach01.usa.alcatel.com] > Sent: Thursday, June 21, 2001 10:10 AM > To: Rosen, Brian; 'Madhu Babu Brahmanapally'; 'Terry L Anderson' > Cc: megaco@fore.com > Subject: Re: Ephemeral Termination > > > The reason for creating Ephemeral and reserving SDP before knowing the > termination is to reduce the call setup time. > > Following is the MGC processing. > > 1. Soon after receiving IAM send ADD command to the originating MG for > a)Creating Ephemeral > b)Reserving SDP for Local > c)Simultaneously start digit analysis > After finding termination > (By this time ADD response would have been received, if not > MGC need to wait for > ADD response) > If terminating trunk belongs to the same MG > a) send ADD command to add the second termination to the > same context. > This ADD command will have empty Local descriptor to > release resources > previously allocated. > Note that ephemeral is not SUBTRACTED. Also MODIFY to > originating MG is > not required as MG is going to make only hairpin connection. > If the terminating MG is not same as originating MG > Send ADD command to terminating MG > a) Creating Ephemeral > b) Reserving SDP for Local > c) Setting SDP remote as Local returned by the originating MG. > After receiving the ADD response from terminating MG > Send MODIFY to originating MG for setting remote Descriptor. > > If you send ADD command to the originating MG only after > knowing the terminator, > MGC had completed processing of the call but now it need to > wait for sending > three commands > (ADD to originating MG, ADD to terminating MG and MODIFY to > originating MG) and > their responses. > > Take the case of trunking gateway, where the number of calls > originating on a MG > and terminating on the same MG are much less than calls originated and > terminated on two different MGs. > > thanks & regards > Chak > > ----- Original Message ----- > From: "Rosen, Brian" > To: "'PSK Chakravarthi'" ; > "'Madhu Babu > Brahmanapally'" ; "'Terry L Anderson'" > > Cc: > Sent: Thursday, June 21, 2001 7:21 PM > Subject: RE: Ephemeral Termination > > > > There is no way this will reduce call setup time. > > Since you do not have the destination information, you > > will have to MODIFY the ephemeral when you do. The processing > > time for the Modify won't be substantially more than doing > > an Add at that point, and there is no difference to the actual > > operation of the gateway. > > > > Brian > > > > > -----Original Message----- > > > From: PSK Chakravarthi [mailto:chak@axes-mach01.usa.alcatel.com] > > > Sent: Thursday, June 21, 2001 1:43 AM > > > To: Rosen, Brian; 'Madhu Babu Brahmanapally'; 'Terry L Anderson' > > > Cc: megaco@fore.com > > > Subject: Re: Ephemeral Termination > > > > > > > > > The reason for creating Ephemeral and reserving SDP > before knowing the > > > termination is > > > to reduce the call setup time. > > > > > > thanks & regards > > > Chak > > > ----- Original Message ----- > > > From: "Rosen, Brian" > > > To: "'Madhu Babu Brahmanapally'" ; > > > "'Terry L Anderson'" > > > ; "'PSK Chakravarthi'" > > > > > > Cc: > > > Sent: Wednesday, June 20, 2001 9:07 PM > > > Subject: RE: Ephemeral Termination > > > > > > > > > > I'm not at all sure what "resources" you can reserve before you > > > > know the destination: > > > > > > > > For an IP network, you can reserve a UDP port I > suppose, but until > > > > you negotiate the SDP, you can't reserve bandwidth. You can't > > > > make any QoS reservation for the same reason. > > > > > > > > It's worse on an ATM network. > > > > > > > > I think there is nothing to be gained by #1 > > > > > > > > Brian > > > > > > > > > -----Original Message----- > > > > > From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com] > > > > > Sent: Wednesday, June 20, 2001 11:28 AM > > > > > To: 'Terry L Anderson'; 'PSK Chakravarthi' > > > > > Cc: megaco@fore.com > > > > > Subject: RE: Ephemeral Termination > > > > > > > > > > > > > > > Hi All, > > > > > The creation of ephemeral termination can be done either > > > after digit > > > > > analysis or before it. Each has its own advantages and > > > disadvantages. > > > > > > > > > > 1) If Ephemeral termination is created before digit analysis, > > > > > situation may > > > > > occur where the destination user/termination is connected to > > > > > the same MG and > > > > > there is no need to create an ephemeral termination (as PSK > > > > > mentioned). But > > > > > this has the advantage that the call wont be dropped due > > > to lack of > > > > > resource, as ephemeral resources are pre-reserved at the MG. > > > > > (in case Add > > > > > fails later to add ephemeral termination). > > > > > > > > > > 2) If Ephemeral termination is created after digit analysis, > > > > > it takes care > > > > > of all situation where destination user may/may not connected > > > > > to the same > > > > > MG. But when Ephemeral termination is added later, there is no > > > > > pre-reservation of the ephemeral resources at the > origination MG. > > > > > > > > > > In case of 1) if the call doesn't mature, reserving the > > > > > resources doesn't > > > > > gain anything. Consideration that the destination user on the > > > > > same MG is > > > > > less probable, Method 2 IMO will be a better choice. > > > > > > > > > > Regards > > > > > Madhubabu > > > > > > > > > > -----Original Message----- > > > > > From: owner-megaco@pit.comms.marconi.com > > > > > [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Terry > > > > > L Anderson > > > > > Sent: Wednesday, June 20, 2001 11:01 AM > > > > > To: PSK Chakravarthi > > > > > Cc: megaco@fore.com > > > > > Subject: Re: Ephemeral Termination > > > > > > > > > > > > > > > > > > > > > > > > > PSK Chakravarthi wrote: > > > > > > > > > > > I have got the following doubt. > > > > > > If the originating and terminating termination IDs are on > > > > > the same gateway > > > > > and > > > > > > gateway supports two TDM terminations in a context, is it > > > > > required to > > > > > craete a > > > > > > ephenmeral termination for this call? > > > > > > > > > > > > Message flow between MGC and MG: > > > > > > > > > > > > 1. MGC send ADD command to originating MG > > > > > > a) Choose a context ID > > > > > > b) Add a TDM termination > > > > > > c) Choose a Ephemeral termination > > > > > > d) Reserve Local Descriptor > > > > > > e) set MODE to Receive only. > > > > > > > > > > > > 2. MGC now finds that call is terminating on the same MG. > > > > > Also MGC knows > > > > > that > > > > > > MG is capable of adding two TDMs to the same context. At > > > > > this point what > > > > > should > > > > > > be the command to the MG? > > > > > > Is it required to SUBTRACT the ephemeral termination and > > > > > send ADD for > > > > > adding new > > > > > > TDM to the same context? or > > > > > > Simply sending ADD for new TDM to the same context is > > > sufficient? > > > > > > > > > > It would be better if MGC "finds" that the call is terminated > > > > > on the same MG > > > > > before > > > > > sending the ADD, in step 1c, but if since step c (which you > > > > > call "Choose a > > > > > Ephemeral > > > > > termination) is an Add with wildcard, MGC must certainly > > > > > Subtract it if it > > > > > chooses > > > > > later not to use it. The Subtract deletes the ephemeral > > > > > termination and > > > > > releases > > > > > its resources. > > > > > > > > > > > thanks & regards > > > > > > Chak > > > > > > > > > > -- > > > > > ------------------------------------------------------------ > > > > > Terry L Anderson mailto:tla@lucent.com > > > > > Tel:908.582.7013 Fax:908.582.6729 > > > > > Lucent Technologies/INS/Voice Over IP Access Networks > > > > > Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 > > > > > http://its.lucent.com/~tla (Lucent internal) > > http://www.gti.net/tla > > > > > > > > > > > > > > From owner-megaco@fore.com Fri Jun 22 05:22:14 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA15001 for ; Fri, 22 Jun 2001 05:22:13 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id FAA04533; Fri, 22 Jun 2001 05:11:59 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id FAA28063 for megaco-list; Fri, 22 Jun 2001 05:09:12 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id FAA28059 for ; Fri, 22 Jun 2001 05:09:10 -0400 (EDT) From: rcxvhmn3un@yahoo.com Received: from scserver.lnpt.co.th (lnpt.co.th [203.148.252.90] (may be forged)) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id FAA04324 for ; Fri, 22 Jun 2001 05:09:01 -0400 (EDT) Received: from n51299r72 (ip213.lawest.quik.com [216.176.1.213]) by scserver.lnpt.co.th with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3) id NBCN3YBV; Mon, 18 Jun 2001 01:43:50 +0700 DATE: 17 Jun 02 10:08:50 AM Message-ID: Content-Type: text/html SUBJECT: Wave of the Future Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk We will put your product or service instantly into the hands of millions of prospects! =============================================================== "Many business people are finding out that they can now advertise in ways that they never could have afforded in the past. The cost of sending mass e-mail is extremely low, and the response rate is high and quick." - USA TODAY =============================================================== Since 1996, Bulk Email Network has provided bulk email marketing to thousands of well-satisfied customers. We offer the most competitive prices in the industry, made possible by our high percentage of repeat business. We have the most advanced direct email technology employed by only a knowledgeable few in the world. We have over 160 million active email addresses, increasing our list at the rate of half a million to one million a month. You will have instant guaranteed results, something no other form of marketing can claim. Our turn around time is a remarkable 24 hours. Our email addresses are sorted by country, state, city and target. Your marketing campaign will speed with pinpoint accuracy to your desired audience! Call us for a free consultation at 323 876 6148 [U.S.A.]. We guarantee the lowest prices or your service is free! Best of ALL, Bulk Email Network can be used as a 100% TAX WRITE OFF for your Business! 1) Let's say you... Sell a $24.95 PRODUCT or SERVICE. 2) Let's say you... Mass Email to 1,000,000 PEOPLE DAILY. 3) Let's say you... Receive JUST 1 ORDER for EVERY 2,500 EMAILS. CALCULATION OF YOUR EARNINGS BASED ON THE ABOVE STATISTICS: [Day 1]: $9,980 [Week 1]: $69,860 [Month 1]: $279,440 Now you know why you receive so many email advertisements... Best Regards, Sam Al Bulk Email Network C.E.O Under Bill s.1618 TITLE III passed by the 105th U.S. Congress this letter is not considered "spam" as long as we include: 1) contact information and, 2) the way to be removed from future mailings (see below). To Remove Yourself From This List: Please email to jk72jk72@yahoo.com with the email address that you would like removed and the word REMOVE in the subject heading. From owner-megaco@fore.com Fri Jun 22 08:42:28 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA19070 for ; Fri, 22 Jun 2001 08:42:27 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA11930; Fri, 22 Jun 2001 08:33:25 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id IAA20260 for megaco-list; Fri, 22 Jun 2001 08:31:37 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA20254 for ; Fri, 22 Jun 2001 08:31:36 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Fri, 22 Jun 2001 08:31:33 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF044655D7@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Christian Groves'" , Terry L Anderson Cc: "'Nitin Kumar'" , "'megaco@fore.com'" Subject: RE: Few clarification in RFC3015 Date: Fri, 22 Jun 2001 08:31:31 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Well I thought the text was clear enough as it was, but someone got confused. While we will forever be in this state. In this case, there are three entities - transactions, actions and commands. The text talks about the order of transaction execution, and it talks about the order of command execution but is silent on the order of action execution. I thought, given that, an edit was warranted. I agree that just because someone is confused doesn't mean we have to add something to the I-G. Brian > -----Original Message----- > From: Christian Groves [mailto:Christian.Groves@ericsson.com] > Sent: Thursday, June 21, 2001 9:47 PM > To: Terry L Anderson > Cc: Rosen, Brian; 'Nitin Kumar'; 'megaco@fore.com' > Subject: Re: Few clarification in RFC3015 > > > G'Day, > > Why should we make this change if the it currently says so in > the text? > This seems to me that we're adding things just for changes > sake. Not all > questions to this list have result in a change in the IG. > > Cheers, Christian > > Terry L Anderson wrote: > > > > "Rosen, Brian" wrote: > > > > > Hmmm, maybe we should edit that text to say: > > > "Actions in a transaction and commands within an action are > > > executed sequentially in the order they appear in the > transaction." > > > > > > Terry? > > > > That is certainly the intent and the way I would read the > current text > > ("commands in order" - the fact that they are grouped into > actions doesn't > > alter their order). But your text is certainly more > explicit. I have no > > trouble with it. I'll put it in. > > > > > > > > > > > "Normal Repitition timers" are the timer values defined in D.1.3 > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: Nitin Kumar [mailto:nitin@indts.com] > > > > Sent: Wednesday, June 20, 2001 2:32 PM > > > > To: 'megaco@fore.com' > > > > Subject: Few clarification in RFC3015 > > > > > > > > > > > > Hi Folks, > > > > > > > > Just looking for following clarification. > > > > > > > > 1. In a TransactionRequest, are ActionRequests processed in > > > > order or only > > > > Commands in an ActionRequest are executed sequencially ? RFC > > > > says "Commands > > > > within a Transaction are executed sequentially." > > > > > > > > 2. Few lines from the RFC on page number 135, section D.1.4.. > > > > "Upon receipt of a final response following receipt of > > > > provisional responses, an immediate confirmation > shall be sent, and > > > > normal repetition timers shall be used thereafter." > > > > > > > > Now what does "normal repetition timers shall be used > > > > thereafter" mean in > > > > above extract? > > > > > > > > i hope to receive some insights. > > > > > > > > regards, > > > > > > > > -nitin > > > > > > > > Ind Telesoft Pvt. Ltd. > > > > 104, Koramangla Industrial Estate, > > > > 5th Block, Bangalore 560 095 > > > > Tel : 5508930, 5521937, 5529758-62 ext-259 > > > > Fax : 5521164 > > > > mailto:nitin@indts.com > > > > http:\\www.telesoftinc.com > > > > > > > > -- > > ------------------------------------------------------------ > > Terry L Anderson mailto:tla@lucent.com > > Tel:908.582.7013 Fax:908.582.6729 > > Lucent Technologies/INS/Voice Over IP Access Networks > > Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 > > http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla > > From owner-megaco@fore.com Fri Jun 22 09:34:00 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA20949 for ; Fri, 22 Jun 2001 09:33:59 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA15711; Fri, 22 Jun 2001 09:19:46 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id JAA29599 for megaco-list; Fri, 22 Jun 2001 09:18:41 -0400 (EDT) Received: from notes.marconicommsna.com ([208.43.60.106]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA29584 for ; Fri, 22 Jun 2001 09:18:39 -0400 (EDT) From: Brian.Rosen@marconi.com To: Sean.Leahy@marconi.com Cc: megaco@fore.com X-Priority: 3 (Normal) Importance: Normal Date: Fri, 22 Jun 2001 08:39:04 -0400 Subject: RE: Ephemeral Termination Message-ID: X-MIMETrack: Serialize by Router on MHDGWY02/S/EXT/MC1(Release 5.0.6a |January 17, 2001) at 06/22/2001 09:16:39 AM MIME-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=85256A730048932D8f9e8a93df938690918c85256A730048932D" Content-Disposition: inline Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk --0__=85256A730048932D8f9e8a93df938690918c85256A730048932D Content-type: text/plain; charset=us-ascii I'm having trouble following your question. The example we are discussing, trunk gateways, has digit analysis and call control done completely in the MGC; the MG has no role at all in these matters. The fact that digit analysis takes some time in the MGC is, I believe, the reasons being advanced for starting with the originating MG and doing everything you can in advance of determining the terminating MG. If the design of the MGC is such that it gets all the information at once (both ends), it can send out the optimal 2 transaction/4 command sequence. The issue is that you gain nothing by anticipating that you might need an ephemeral. Whether it turns out that you do (originating MG not equal terminating MG) or you don't (hairpin), putting the ephemeral in the context before you know doesn't help anything. It may or may not "work" in all MGs, but I don't see any reason to do it. Maybe I'm missing something. Brian -----Original Message----- From: Leahy, Sean Sent: Friday, June 22, 2001 4:09 AM To: Rosen, Brian Cc: megaco@fore.com Subject: RE: Ephemeral Termination Brian, Just a question. There may be cases where Megaco is being used solely for bearer control and the call control/digit analysis is conducted at a layer above the Megaco protocol. In these circumstances, it is also possible that ephemerals are added and modified by command from the MGC when the bearer connection is actually between two physical terminations on the same Media Gateway. Is it altogether impossible for a Media Gateway to optimise such a hair-pin connection whilst maintaining the same model to the MGC ? Sean Leahy Marconi (Embedded image moved to file: pic24464.pcx) CN=Brian Rosen/OU=MAIN/O=MC1@MSEXCH on 21/06/2001 15:56:23 |--------------------------------------------------------------------------------------------------------------------------| | | | | | | |--------------------------------------------------------------------------------------------------------------------------| |----------+-------------------------------------------------------------| | | | | | | | | | |----------+-------------------------------------------------------------| | | | | To: | "'PSK Chakravarthi'" , | | | "'Madhu Babu Brahmanapally'" , | | | "'Terry L Anderson'" | | | | |----------+-------------------------------------------------------------| | | | | cc: | megaco@fore.com(bcc: Sean Leahy/MAIN/MC1) | | | | |----------+-------------------------------------------------------------| | | | | | | | | | |----------+-------------------------------------------------------------| | | | | Subject: | RE: Ephemeral Termination | | | | |----------+-------------------------------------------------------------| (Embedded image moved to file: pic05705.pcx) I'm having trouble following your logic. This seems to be a trunk GW/ISUP issue, so we don't have to deal with off hook/DTMF issues, right? In the case of hairpin, you need two commands: 1) An add to put the originating termination in the context 2) An add to put the terminating termination in the context. They cannot be in the same transaction if you have not completed digit analysis before you do 1. In the case of a normal connection between two MGs you need 4 total commands: 1) The Add of the physical in the originating MG 2) The Add of the ephemeral in the originating MG 3) The Add of the physical in the terminating MG 4) The Add of the ephemeral in the terminating MG You can do 1 before you do digit analysis. You have to do 3 and 4 after digit analysis, but they can be in the same transaction. If you do 2 before you do digit analysis, you would not have the correct remote SDP, and therefore you would need to send a Modify after digit analysis. If you do it after you do digit analysis, then you only have the 4 commands. Before digit analysis, the MGC sends 1. After digit analysis the MGC sends two transactions in two messages; one to the originating MG (message 2 containing correct local and remote SDP) and one to the terminating MG (with messages 3 and 4 including all the SDP). In most cases, I suspect it would actually be more efficient to send message 1 after digit analysis, because then the originating MG has one less transaction to process, but the same number of commands. The call setup difference between the originating MG doing one add before digit analysis and another after vs doing both after won't matter enough to be measurable I think, but the difference in processing of half the number of messages will be substantial. I see no way to have the Add of the ephemeral before digit analysis improve call setup time. It seems to only create extra work for the originating MG. Brian > -----Original Message----- > From: PSK Chakravarthi [mailto:chak@axes-mach01.usa.alcatel.com] > Sent: Thursday, June 21, 2001 10:10 AM > To: Rosen, Brian; 'Madhu Babu Brahmanapally'; 'Terry L Anderson' > Cc: megaco@fore.com > Subject: Re: Ephemeral Termination > > > The reason for creating Ephemeral and reserving SDP before knowing the > termination is to reduce the call setup time. > > Following is the MGC processing. > > 1. Soon after receiving IAM send ADD command to the originating MG for > a)Creating Ephemeral > b)Reserving SDP for Local > c)Simultaneously start digit analysis > After finding termination > (By this time ADD response would have been received, if not > MGC need to wait for > ADD response) > If terminating trunk belongs to the same MG > a) send ADD command to add the second termination to the > same context. > This ADD command will have empty Local descriptor to > release resources > previously allocated. > Note that ephemeral is not SUBTRACTED. Also MODIFY to > originating MG is > not required as MG is going to make only hairpin connection. > If the terminating MG is not same as originating MG > Send ADD command to terminating MG > a) Creating Ephemeral > b) Reserving SDP for Local > c) Setting SDP remote as Local returned by the originating MG. > After receiving the ADD response from terminating MG > Send MODIFY to originating MG for setting remote Descriptor. > > If you send ADD command to the originating MG only after > knowing the terminator, > MGC had completed processing of the call but now it need to > wait for sending > three commands > (ADD to originating MG, ADD to terminating MG and MODIFY to > originating MG) and > their responses. > > Take the case of trunking gateway, where the number of calls > originating on a MG > and terminating on the same MG are much less than calls originated and > terminated on two different MGs. > > thanks & regards > Chak > > ----- Original Message ----- > From: "Rosen, Brian" > To: "'PSK Chakravarthi'" ; > "'Madhu Babu > Brahmanapally'" ; "'Terry L Anderson'" > > Cc: > Sent: Thursday, June 21, 2001 7:21 PM > Subject: RE: Ephemeral Termination > > > > There is no way this will reduce call setup time. > > Since you do not have the destination information, you > > will have to MODIFY the ephemeral when you do. The processing > > time for the Modify won't be substantially more than doing > > an Add at that point, and there is no difference to the actual > > operation of the gateway. > > > > Brian > > > > > -----Original Message----- > > > From: PSK Chakravarthi [mailto:chak@axes-mach01.usa.alcatel.com] > > > Sent: Thursday, June 21, 2001 1:43 AM > > > To: Rosen, Brian; 'Madhu Babu Brahmanapally'; 'Terry L Anderson' > > > Cc: megaco@fore.com > > > Subject: Re: Ephemeral Termination > > > > > > > > > The reason for creating Ephemeral and reserving SDP > before knowing the > > > termination is > > > to reduce the call setup time. > > > > > > thanks & regards > > > Chak > > > ----- Original Message ----- > > > From: "Rosen, Brian" > > > To: "'Madhu Babu Brahmanapally'" ; > > > "'Terry L Anderson'" > > > ; "'PSK Chakravarthi'" > > > > > > Cc: > > > Sent: Wednesday, June 20, 2001 9:07 PM > > > Subject: RE: Ephemeral Termination > > > > > > > > > > I'm not at all sure what "resources" you can reserve before you > > > > know the destination: > > > > > > > > For an IP network, you can reserve a UDP port I > suppose, but until > > > > you negotiate the SDP, you can't reserve bandwidth. You can't > > > > make any QoS reservation for the same reason. > > > > > > > > It's worse on an ATM network. > > > > > > > > I think there is nothing to be gained by #1 > > > > > > > > Brian > > > > > > > > > -----Original Message----- > > > > > From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com] > > > > > Sent: Wednesday, June 20, 2001 11:28 AM > > > > > To: 'Terry L Anderson'; 'PSK Chakravarthi' > > > > > Cc: megaco@fore.com > > > > > Subject: RE: Ephemeral Termination > > > > > > > > > > > > > > > Hi All, > > > > > The creation of ephemeral termination can be done either > > > after digit > > > > > analysis or before it. Each has its own advantages and > > > disadvantages. > > > > > > > > > > 1) If Ephemeral termination is created before digit analysis, > > > > > situation may > > > > > occur where the destination user/termination is connected to > > > > > the same MG and > > > > > there is no need to create an ephemeral termination (as PSK > > > > > mentioned). But > > > > > this has the advantage that the call wont be dropped due > > > to lack of > > > > > resource, as ephemeral resources are pre-reserved at the MG. > > > > > (in case Add > > > > > fails later to add ephemeral termination). > > > > > > > > > > 2) If Ephemeral termination is created after digit analysis, > > > > > it takes care > > > > > of all situation where destination user may/may not connected > > > > > to the same > > > > > MG. But when Ephemeral termination is added later, there is no > > > > > pre-reservation of the ephemeral resources at the > origination MG. > > > > > > > > > > In case of 1) if the call doesn't mature, reserving the > > > > > resources doesn't > > > > > gain anything. Consideration that the destination user on the > > > > > same MG is > > > > > less probable, Method 2 IMO will be a better choice. > > > > > > > > > > Regards > > > > > Madhubabu > > > > > > > > > > -----Original Message----- > > > > > From: owner-megaco@pit.comms.marconi.com > > > > > [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Terry > > > > > L Anderson > > > > > Sent: Wednesday, June 20, 2001 11:01 AM > > > > > To: PSK Chakravarthi > > > > > Cc: megaco@fore.com > > > > > Subject: Re: Ephemeral Termination > > > > > > > > > > > > > > > > > > > > > > > > > PSK Chakravarthi wrote: > > > > > > > > > > > I have got the following doubt. > > > > > > If the originating and terminating termination IDs are on > > > > > the same gateway > > > > > and > > > > > > gateway supports two TDM terminations in a context, is it > > > > > required to > > > > > craete a > > > > > > ephenmeral termination for this call? > > > > > > > > > > > > Message flow between MGC and MG: > > > > > > > > > > > > 1. MGC send ADD command to originating MG > > > > > > a) Choose a context ID > > > > > > b) Add a TDM termination > > > > > > c) Choose a Ephemeral termination > > > > > > d) Reserve Local Descriptor > > > > > > e) set MODE to Receive only. > > > > > > > > > > > > 2. MGC now finds that call is terminating on the same MG. > > > > > Also MGC knows > > > > > that > > > > > > MG is capable of adding two TDMs to the same context. At > > > > > this point what > > > > > should > > > > > > be the command to the MG? > > > > > > Is it required to SUBTRACT the ephemeral termination and > > > > > send ADD for > > > > > adding new > > > > > > TDM to the same context? or > > > > > > Simply sending ADD for new TDM to the same context is > > > sufficient? > > > > > > > > > > It would be better if MGC "finds" that the call is terminated > > > > > on the same MG > > > > > before > > > > > sending the ADD, in step 1c, but if since step c (which you > > > > > call "Choose a > > > > > Ephemeral > > > > > termination) is an Add with wildcard, MGC must certainly > > > > > Subtract it if it > > > > > chooses > > > > > later not to use it. The Subtract deletes the ephemeral > > > > > termination and > > > > > releases > > > > > its resources. > > > > > > > > > > > thanks & regards > > > > > > Chak > > > > > > > > > > -- > > > > > ------------------------------------------------------------ > > > > > Terry L Anderson mailto:tla@lucent.com > > > > > Tel:908.582.7013 Fax:908.582.6729 > > > > > Lucent Technologies/INS/Voice Over IP Access Networks > > > > > Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 > > > > > http://its.lucent.com/~tla (Lucent internal) > > http://www.gti.net/tla > > > > > > > > > > > > > > --0__=85256A730048932D8f9e8a93df938690918c85256A730048932D Content-type: application/octet-stream; name="pic24464.pcx" Content-Disposition: attachment; filename="pic24464.pcx" Content-Transfer-Encoding: base64 CgUBCAAAAABGADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAABRwABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAADk/9L/yf/F/8L/wf/T/9MA0f/J/8T/wv/B/9P/AMH/B8H/B8H/B8H/B8H/ B8H/B8H/B8H/B8H/wgDR/8j/xP/C/8H/0/8AB8H/B8H/B8H/B8H/B8H/B8H/B8H/B8H/BwAHAND/ yP/E/8L/wf/T/wDB/wfB/wfB/wfB/wfB/wfB/wfB/wfB/wfB/wDCBwDQ/8j/xP/C/9P/AAfB/wfB /wfB/wfB/wfB/wfB/wfB/wfB/wcAwwcAz//I/8T/wv/T/wDB/wfB/wfB/wfB/wfB/wfB/wfB/wfB /wfB/wDEBwDP/8f/xP/C/9P/AAfB/wfB/wfB/wfB/wfB/wfB/wfB/wfB/wfHAM7/x//E/8L/0/8A wf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Azv/H/8T/wv/T/wAHwf8Hwf8Hwf8H wf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8HAM7/x//E/8L/0/8Awf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8H wf8Hwf8Hwf8Hwf8Hwf8Azv/H/8T/wv/T/wAHwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8H wf8HAM7/x//E/8L/0/8Awf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Azv/H/8T/ wv/T/wAHwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8HAM7/x//E/8L/0/8Awf8Hwf8H wf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Azv/H/8T/wv/T/wAHwf8Hwf8Hwf8Hwf8Hwf8H wf8Hwf8Hwf8Hwf8Hwf8Hwf8HAM7/x//E/8L/0/8Awf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8H wf8Hwf8Hwf8Azv/H/8T/wv/T/wAHwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8HAM7/ x//E/8L/0/8Awf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Azv/H/8T/wv/T/wAH wf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8HAM7/x//E/8L/0/8Awf8Hwf8Hwf8Hwf8H wf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Azv/H/8T/wv/T/wAHwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8H wf8Hwf8Hwf8Hwf8HAM7/x//E/8L/0/8Awf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8H wf8Azv/H/8T/wv/T/wAHwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8HAM7/x//E/8L/ 0/8Awf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Azv/H/8T/wv/T/wAHwf8Hwf8H wf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8HAM7/x//E/8L/0/8Awf8Hwf8Hwf8Hwf8Hwf8Hwf8H wf8Hwf8Hwf8Hwf8Hwf8Hwf8Azv/H/8T/wv/T/wAHwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8H wf8Hwf8HAM7/x//E/8L/0/8Awf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Azv/H /8T/wv/T/wAHwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8HAM7/x//E/8L/0//ZAM7/ x//E/8L/5P/S/8n/xf/C/8H/5P/S/8n/xf/C/8H/5P/S/8n/xf/C/8H/5P/S/8n/xf/C/8H/5P/S /8n/xf/C/8H/5P/S/8n/xf/C/8H/5P/S/8n/xf/C/8H/x/8AxP8Awv8Azv8A1f/E/wDI/8T/wv/G /wDB/wDD/wDC/wDO/wDV/8T/AMj/xP/C/8b/AMH/AML/xgDC/8MAw//DAML/AMH/wgDC/wDB/8QA w//DAML/xADB/8MAx//E/8L/xv8Awf8Aw/8Awv8Awv8Aw/8Awf8Aw/8Awf/CAML/AMH/wgDB/wDC /wDB/wDD/wDB/wDD/wDB/wDI/8T/wv/F/wDD/wDC/wDC/wDD/8QAwf8Axf8Aw/8Awf8Awv8Awv8A wf/FAMH/AMP/AMH/AMj/xP/C/8X/xQDC/wDC/wDC/wDD/wDB/wDF/wDD/wDB/wDC/wDC/wDB/wDF /wDD/wDB/wDI/8T/wv/E/wDF/wDB/wDC/wDC/wDC/8IAwf8Aw/8Awf8Aw/8Awf8Awv8Awv8Awf8A w/8Awf8Aw/8Awf8AyP/E/8L/xP8Axf8Awf/CAMH/wgDC/8IAwf8Awv/DAML/AMP/AMH/AML/AML/ AML/wwDC/wDD/wDB/8IAx//E/8L/5P/S/8n/xf/C/8H/5P/S/8n/xf/C/8H/5P/S/8n/xf/C/8H/ DAAAAIAAAACAAICAAAAAgIAAgACAgMDAwMDcwKbK8EAgAGAgAIAgAKAgAMAgAOAgAABAACBAAEBA AGBAAIBAAKBAAMBAAOBAAABgACBgAEBgAGBgAIBgAKBgAMBgAOBgAACAACCAAECAAGCAAICAAKCA AMCAAOCAAACgACCgAECgAGCgAICgAKCgAMCgAOCgAADAACDAAEDAAGDAAIDAAKDAAMDAAODAAADg ACDgAEDgAGDgAIDgAKDgAMDgAODgAAAAQCAAQEAAQGAAQIAAQKAAQMAAQOAAQAAgQCAgQEAgQGAg QIAgQKAgQMAgQOAgQABAQCBAQEBAQGBAQIBAQKBAQMBAQOBAQABgQCBgQEBgQGBgQIBgQKBgQMBg QOBgQACAQCCAQECAQGCAQICAQKCAQMCAQOCAQACgQCCgQECgQGCgQICgQKCgQMCgQOCgQADAQCDA QEDAQGDAQIDAQKDAQMDAQODAQADgQCDgQEDgQGDgQIDgQKDgQMDgQODgQAAAgCAAgEAAgGAAgIAA gKAAgMAAgOAAgAAggCAggEAggGAggIAggKAggMAggOAggABAgCBAgEBAgGBAgIBAgKBAgMBAgOBA gABggCBggEBggGBggIBggKBggMBggOBggACAgCCAgECAgGCAgICAgKCAgMCAgOCAgACggCCggECg gGCggICggKCggMCggOCggADAgCDAgEDAgGDAgIDAgKDAgMDAgODAgADggCDggEDggGDggIDggKDg gMDggODggAAAwCAAwEAAwGAAwIAAwKAAwMAAwOAAwAAgwCAgwEAgwGAgwIAgwKAgwMAgwOAgwABA wCBAwEBAwGBAwIBAwKBAwMBAwOBAwABgwCBgwEBgwGBgwIBgwKBgwMBgwOBgwACAwCCAwECAwGCA wICAwKCAwMCAwOCAwACgwCCgwECgwGCgwICgwKCgwMCgwOCgwADAwCDAwEDAwGDAwIDAwKDAwP/7 8KCgpICAgP8AAAD/AP//AAAA//8A/wD//////w== --0__=85256A730048932D8f9e8a93df938690918c85256A730048932D Content-type: application/octet-stream; name="pic05705.pcx" Content-Disposition: attachment; filename="pic05705.pcx" Content-Transfer-Encoding: base64 CgUBCAAAAABGADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAABRwABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAADk/9L/yf/F/8L/wf/T/9MA0f/J/8T/wv/B/9P/AMH/B8H/B8H/B8H/B8H/ B8H/B8H/B8H/B8H/wgDR/8j/xP/C/8H/0/8AB8H/B8H/B8H/B8H/B8H/B8H/B8H/B8H/BwAHAND/ yP/E/8L/wf/T/wDB/wfB/wfB/wfB/wfB/wfB/wfB/wfB/wfB/wDCBwDQ/8j/xP/C/9P/AAfB/wfB /wfB/wfB/wfB/wfB/wfB/wfB/wcAwwcAz//I/8T/wv/T/wDB/wfB/wfB/wfB/wfB/wfB/wfB/wfB /wfB/wDEBwDP/8f/xP/C/9P/AAfB/wfB/wfB/wfB/wfB/wfB/wfB/wfB/wfHAM7/x//E/8L/0/8A wf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Azv/H/8T/wv/T/wAHwf8Hwf8Hwf8H wf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8HAM7/x//E/8L/0/8Awf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8H wf8Hwf8Hwf8Hwf8Hwf8Azv/H/8T/wv/T/wAHwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8H wf8HAM7/x//E/8L/0/8Awf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Azv/H/8T/ wv/T/wAHwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8HAM7/x//E/8L/0/8Awf8Hwf8H wf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Azv/H/8T/wv/T/wAHwf8Hwf8Hwf8Hwf8Hwf8H wf8Hwf8Hwf8Hwf8Hwf8Hwf8HAM7/x//E/8L/0/8Awf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8H wf8Hwf8Hwf8Azv/H/8T/wv/T/wAHwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8HAM7/ x//E/8L/0/8Awf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Azv/H/8T/wv/T/wAH wf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8HAM7/x//E/8L/0/8Awf8Hwf8Hwf8Hwf8H wf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Azv/H/8T/wv/T/wAHwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8H wf8Hwf8Hwf8Hwf8HAM7/x//E/8L/0/8Awf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8H wf8Azv/H/8T/wv/T/wAHwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8HAM7/x//E/8L/ 0/8Awf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Azv/H/8T/wv/T/wAHwf8Hwf8H wf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8HAM7/x//E/8L/0/8Awf8Hwf8Hwf8Hwf8Hwf8Hwf8H wf8Hwf8Hwf8Hwf8Hwf8Hwf8Azv/H/8T/wv/T/wAHwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8H wf8Hwf8HAM7/x//E/8L/0/8Awf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Azv/H /8T/wv/T/wAHwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8Hwf8HAM7/x//E/8L/0//ZAM7/ x//E/8L/5P/S/8n/xf/C/8H/5P/S/8n/xf/C/8H/5P/S/8n/xf/C/8H/5P/S/8n/xf/C/8H/5P/S /8n/xf/C/8H/5P/S/8n/xf/C/8H/5P/S/8n/xf/C/8H/x/8AxP8Awv8Azv8A1f/E/wDI/8T/wv/G /wDB/wDD/wDC/wDO/wDV/8T/AMj/xP/C/8b/AMH/AML/xgDC/8MAw//DAML/AMH/wgDC/wDB/8QA w//DAML/xADB/8MAx//E/8L/xv8Awf8Aw/8Awv8Awv8Aw/8Awf8Aw/8Awf/CAML/AMH/wgDB/wDC /wDB/wDD/wDB/wDD/wDB/wDI/8T/wv/F/wDD/wDC/wDC/wDD/8QAwf8Axf8Aw/8Awf8Awv8Awv8A wf/FAMH/AMP/AMH/AMj/xP/C/8X/xQDC/wDC/wDC/wDD/wDB/wDF/wDD/wDB/wDC/wDC/wDB/wDF /wDD/wDB/wDI/8T/wv/E/wDF/wDB/wDC/wDC/wDC/8IAwf8Aw/8Awf8Aw/8Awf8Awv8Awv8Awf8A w/8Awf8Aw/8Awf8AyP/E/8L/xP8Axf8Awf/CAMH/wgDC/8IAwf8Awv/DAML/AMP/AMH/AML/AML/ AML/wwDC/wDD/wDB/8IAx//E/8L/5P/S/8n/xf/C/8H/5P/S/8n/xf/C/8H/5P/S/8n/xf/C/8H/ DAAAAIAAAACAAICAAAAAgIAAgACAgMDAwMDcwKbK8EAgAGAgAIAgAKAgAMAgAOAgAABAACBAAEBA AGBAAIBAAKBAAMBAAOBAAABgACBgAEBgAGBgAIBgAKBgAMBgAOBgAACAACCAAECAAGCAAICAAKCA AMCAAOCAAACgACCgAECgAGCgAICgAKCgAMCgAOCgAADAACDAAEDAAGDAAIDAAKDAAMDAAODAAADg ACDgAEDgAGDgAIDgAKDgAMDgAODgAAAAQCAAQEAAQGAAQIAAQKAAQMAAQOAAQAAgQCAgQEAgQGAg QIAgQKAgQMAgQOAgQABAQCBAQEBAQGBAQIBAQKBAQMBAQOBAQABgQCBgQEBgQGBgQIBgQKBgQMBg QOBgQACAQCCAQECAQGCAQICAQKCAQMCAQOCAQACgQCCgQECgQGCgQICgQKCgQMCgQOCgQADAQCDA QEDAQGDAQIDAQKDAQMDAQODAQADgQCDgQEDgQGDgQIDgQKDgQMDgQODgQAAAgCAAgEAAgGAAgIAA gKAAgMAAgOAAgAAggCAggEAggGAggIAggKAggMAggOAggABAgCBAgEBAgGBAgIBAgKBAgMBAgOBA gABggCBggEBggGBggIBggKBggMBggOBggACAgCCAgECAgGCAgICAgKCAgMCAgOCAgACggCCggECg gGCggICggKCggMCggOCggADAgCDAgEDAgGDAgIDAgKDAgMDAgODAgADggCDggEDggGDggIDggKDg gMDggODggAAAwCAAwEAAwGAAwIAAwKAAwMAAwOAAwAAgwCAgwEAgwGAgwIAgwKAgwMAgwOAgwABA wCBAwEBAwGBAwIBAwKBAwMBAwOBAwABgwCBgwEBgwGBgwIBgwKBgwMBgwOBgwACAwCCAwECAwGCA wICAwKCAwMCAwOCAwACgwCCgwECgwGCgwICgwKCgwMCgwOCgwADAwCDAwEDAwGDAwIDAwKDAwP/7 8KCgpICAgP8AAAD/AP//AAAA//8A/wD//////w== --0__=85256A730048932D8f9e8a93df938690918c85256A730048932D-- From owner-megaco@fore.com Fri Jun 22 09:51:31 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA21562 for ; Fri, 22 Jun 2001 09:51:31 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA17336; Fri, 22 Jun 2001 09:38:06 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id JAA03429 for megaco-list; Fri, 22 Jun 2001 09:36:22 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA03425 for ; Fri, 22 Jun 2001 09:36:20 -0400 (EDT) Received: from auemail1.firewall.lucent.com (auemail1.lucent.com [192.11.223.161]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA17117 for ; Fri, 22 Jun 2001 09:36:14 -0400 (EDT) Received: from auemail1.firewall.lucent.com (localhost [127.0.0.1]) by auemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5MDaF716232 for ; Fri, 22 Jun 2001 09:36:15 -0400 (EDT) Received: from teton.mh.lucent.com (h135-3-130-2.lucent.com [135.3.130.2]) by auemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5MDaFc16219; Fri, 22 Jun 2001 09:36:15 -0400 (EDT) Received: from lucent.com (pctla [135.3.130.39]) by teton.mh.lucent.com (8.8.8+Sun/8.8.8) with ESMTP id JAA15625; Fri, 22 Jun 2001 09:36:13 -0400 (EDT) Message-ID: <3B334B06.B8D21D75@lucent.com> Date: Fri, 22 Jun 2001 09:41:28 -0400 From: Terry L Anderson Organization: Lucent Technologies X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Christian Groves CC: Megaco Mailing List Subject: Re: NotifyCompletion and g/sc Meth References: <3B30B36F.C3F79AA2@lucent.com> <3B32A42B.2D53A854@ericsson.com> Content-Type: multipart/mixed; boundary="------------F0413F08E63B05937500984D" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk This is a multi-part message in MIME format. --------------F0413F08E63B05937500984D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I figured if we were editing the item anyway, it would be least confusing if we keep the same language used elsewhere (emphasizing the pairing with NotifyCompletion reason) rather than introducing yet another term for the same thing. So I copied the language from 7.1.11. BTW I agree with you about not making gratuitous edits where there is no serious problem with the old language and I would not have suggested changing "Duration expired" to "Timed out" unless I had been changing the description for other reasons. On your previous point, I agree with Brian, that ambiguity or language leading to common confusion is worth changing. Whether that case was confusing enough is perhaps debateable. Christian Groves wrote: > G'Day Terry, > > I would have still been happy with "Duration expired" but your update > does cover "ended on its own more explicitely". > > Cheers, Christian > > Terry L Anderson wrote: > > > > NotifyCompletion reasons and g/sc{Meth=XX} codes are abviously paired. > > TimeOut -- TO Duration expired > > IntByEvent -- EV Interrupted by event > > IntBySigDescr -- SD Halted by new Signals Descriptor > > OtherReason -- NC Not completed, other cause > > > > What is not so clear is which of these is appropriate for the case of a > > signal that "plays to completion" for reasons other than time, e.g., a > > voice announcement file. The use of OtherReason/NC does not seem > > appropriate, since this is usually used for errors and it controdicts > > the "not completed" text. Such signals could be of type "brief" or time > > "timeout". I believe that TimeOut/TO is the most appropriate, in spite > > of time not being the real cause and in private discussions, others > > suggest that this was the original intent. > > > > The choice of words for the reason is unfortunate - NormalCompletion > > might have been clearer. The "Duration expired" is more applicable than > > the "TimeOut". I suggest we add language to make it clear that this is > > the correct reason. > > > > 7.1.11 3rd paragraph > > change the sentence to: > > The possible cases are that the signal timed out (or otherwise ended on > > its own), that it was interrupted ... > > > > E.1.2 change the text after "TO" in Meth to > > "TO" (0x0001) Signal Timed out or otherwise ended on its own. > > > > I will add this to the Implementors Guide unless there is an objection. > > > > -- > > ------------------------------------------------------------ > > Terry L Anderson mailto:tla@lucent.com > > Tel:908.582.7013 Fax:908.582.6729 > > Lucent Technologies/INS/Voice Over IP Access Networks > > Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 > > http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla -- ------------------------------------------------------------ Terry L Anderson mailto:tla@lucent.com Tel:908.582.7013 Fax:908.582.6729 Lucent Technologies/INS/Voice Over IP Access Networks Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla --------------F0413F08E63B05937500984D Content-Type: text/x-vcard; charset=us-ascii; name="tla.vcf" Content-Description: Card for Terry L Anderson Content-Disposition: attachment; filename="tla.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Anderson;Terry L tel;fax:908.582.6729 tel;work:908.582.7013 x-mozilla-html:TRUE url:http://its.lucent.com/~tla org:Lucent / InterNetworking Systems;VoIP Access Networks version:2.1 email;internet:tla@lucent.com title:DMTS note:http://www.gti.net/tla or http://teton.mh.lucent.com/~tla (Lucent internal) adr;quoted-printable:;;600 Mountain Av=0D=0ARm 2B-121;Murray Hill;NJ;07974;USA x-mozilla-cpt:;21296 fn:Terry L Anderson end:vcard --------------F0413F08E63B05937500984D-- From owner-megaco@fore.com Fri Jun 22 10:01:07 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA21976 for ; Fri, 22 Jun 2001 10:01:05 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA17979; Fri, 22 Jun 2001 09:43:28 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id JAA04811 for megaco-list; Fri, 22 Jun 2001 09:42:19 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA04798 for ; Fri, 22 Jun 2001 09:42:17 -0400 (EDT) Received: from auemail1.firewall.lucent.com (auemail1.lucent.com [192.11.223.161]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA17773 for ; Fri, 22 Jun 2001 09:42:11 -0400 (EDT) Received: from auemail1.firewall.lucent.com (localhost [127.0.0.1]) by auemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5MDgC723162 for ; Fri, 22 Jun 2001 09:42:13 -0400 (EDT) Received: from teton.mh.lucent.com (h135-3-130-2.lucent.com [135.3.130.2]) by auemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5MDgAc23100; Fri, 22 Jun 2001 09:42:10 -0400 (EDT) Received: from lucent.com (pctla [135.3.130.39]) by teton.mh.lucent.com (8.8.8+Sun/8.8.8) with ESMTP id JAA16451; Fri, 22 Jun 2001 09:42:09 -0400 (EDT) Message-ID: <3B334C6C.735BE9B3@lucent.com> Date: Fri, 22 Jun 2001 09:47:24 -0400 From: Terry L Anderson Organization: Lucent Technologies X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Qiu Xiuping CC: megaco@fore.com Subject: Re: E.6.2 Events : digit map parameter definition References: <000501c0fabd$c3efa7c0$a4010b0a@huawei.com.cn> Content-Type: multipart/mixed; boundary="------------0624C5EE3958742D64D23117" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk This is a multi-part message in MIME format. --------------0624C5EE3958742D64D23117 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit DigitMaps are defined in 7.1.14. No reason to repeat everything here any more than repeating embedded Events. Qiu Xiuping wrote: > Hi, Dear all. > > In RFC 3015. > ====================================================================== > E.6.2 Events > ------------------------- > EventID: ce, 0x0001 > > Generated when a digit map completes as described in section 7.1.14. > > EventsDescriptor parameters: digit map processing is activated only > if a digit map parameter is present, specifying a digit map by name > or by value. Other parameters such as a KeepActive flag or embedded > Events or Signals Descriptors may be present. > ======================================================================= > It's said that "if a digit map parameter is present", but the digit map > parameter is not defined here. I think there should a definition like: > name, ID, Type , Possible values, Description and so on. > > Where's it? > > Thank you, > > Qiu Xiuping > _______________________________________________ > Huawei Technologies Co., Ltd. > Room 5707,Keji Building, Kefa Road > Science-Based Industrial Park > Nanshan District, Shenzhen 518057, P.R.China > Tel : +86-755-6544 509 > _______________________________________________ -- ------------------------------------------------------------ Terry L Anderson mailto:tla@lucent.com Tel:908.582.7013 Fax:908.582.6729 Lucent Technologies/INS/Voice Over IP Access Networks Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla --------------0624C5EE3958742D64D23117 Content-Type: text/x-vcard; charset=us-ascii; name="tla.vcf" Content-Description: Card for Terry L Anderson Content-Disposition: attachment; filename="tla.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Anderson;Terry L tel;fax:908.582.6729 tel;work:908.582.7013 x-mozilla-html:TRUE url:http://its.lucent.com/~tla org:Lucent / InterNetworking Systems;VoIP Access Networks version:2.1 email;internet:tla@lucent.com title:DMTS note:http://www.gti.net/tla or http://teton.mh.lucent.com/~tla (Lucent internal) adr;quoted-printable:;;600 Mountain Av=0D=0ARm 2B-121;Murray Hill;NJ;07974;USA x-mozilla-cpt:;21296 fn:Terry L Anderson end:vcard --------------0624C5EE3958742D64D23117-- From owner-megaco@fore.com Fri Jun 22 12:13:41 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA28677 for ; Fri, 22 Jun 2001 12:13:40 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA28328; Fri, 22 Jun 2001 11:39:44 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id LAA10819 for megaco-list; Fri, 22 Jun 2001 11:32:38 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA10807 for ; Fri, 22 Jun 2001 11:32:35 -0400 (EDT) Received: from cvis21.Marconicomms.com (cvis21.marconicomms.com [195.99.244.53] (may be forged)) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA27654 for ; Fri, 22 Jun 2001 11:32:29 -0400 (EDT) Received: from cvis01.gpt.co.uk (unverified) by cvis21.Marconicomms.com (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Fri, 22 Jun 2001 16:30:11 +0100 Received: from marconicomms.com by cvis01.gpt.co.uk with SMTP (8.8.8+Sun/cvms-32) id QAA08622; Fri, 22 Jun 2001 16:25:23 +0100 (BST) Received: by marconicomms.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 80256A73.0054AB76 ; Fri, 22 Jun 2001 16:24:49 +0100 X-Lotus-FromDomain: MCMAIN@MCEXT From: "Sean Leahy" To: "Brian Rosen" cc: megaco@fore.com Message-ID: <80256A73.00549CF7.00@marconicomms.com> Date: Fri, 22 Jun 2001 16:24:34 +0100 Subject: RE: Ephemeral Termination Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=QD8vBJ9B5zKiK4ix0MPgrANQM4EM0xit1JYzfYwO4xDoZKp7NjwIn6O2" Content-Disposition: inline Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk --0__=QD8vBJ9B5zKiK4ix0MPgrANQM4EM0xit1JYzfYwO4xDoZKp7NjwIn6O2 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Brian, Briefly, the scenario that I was postulating was that the Call Control at the MGC (or above the MGC - depending on how you define an 'MGC' realisation) is separate from the bearer control at the MGC. Thus the MGC bearer signalling is independent enough from the call control/digit analysis that it does not allow the H.248 functionality to be told directly that the two physical terminations are on the same MG when it is first invoked (for the connection to termination A) from the call control function. The MGC might work this out when it is invoked for the connection to termination B, but there may be a problem if there are two separate instances of the same MGC handling each side of the connection. Thus the question remains - Is there any possibility for a Media Gateway to optimise such a hair-pin connection whilst maintaining the same model to the MGC ? Obviously, the alternative is to change both the call control and bearer control layers to be able to harmonise better to deal with hairpin connections. But it would be interesting to know if you think optimisation at the MG is a possibility that might mean this could be avoided, if it were so desired. Regards, Sean Leahy From: Brian Rosen/MAIN/MC1@MSEXCH on 22/06/2001 13:39 To: Sean Leahy/MAIN/MC1@MCMAIN cc: megaco@fore.com Subject: RE: Ephemeral Termination I'm having trouble following your question. The example we are discussing, trunk gateways, has digit analysis and call control done completely in the MGC; the MG has no role at all in these matters. The fact that digit analysis takes some time in the MGC is, I believe, the reasons being advanced for starting with the originating MG and doing everything you can in advance of determining the terminating MG. If the design of the MGC is such that it gets all the information at once (both ends), it can send out the optimal 2 transaction/4 command sequence. The issue is that you gain nothing by anticipating that you might need an ephemeral. Whether it turns out that you do (originating MG not equal terminating MG) or you don't (hairpin), putting the ephemeral in the context before you know doesn't help anything. It may or may not "work" in all MGs, but I don't see any reason to do it. Maybe I'm missing something. Brian -----Original Message----- From: Leahy, Sean Sent: Friday, June 22, 2001 4:09 AM To: Rosen, Brian Cc: megaco@fore.com Subject: RE: Ephemeral Termination Brian, Just a question. There may be cases where Megaco is being used solely for bearer control and the call control/digit analysis is conducted at a layer above the Megaco protocol. In these circumstances, it is also possible that ephemerals are added and modified by command from the MGC when the bearer connection is actually between two physical terminations on the same Media Gateway. Is it altogether impossible for a Media Gateway to optimise such a hair-pin connection whilst maintaining the same model to the MGC ? Sean Leahy Marconi (Embedded image moved to file: pic28418.pcx) CN=Brian Rosen/OU=MAIN/O=MC1@MSEXCH on 21/06/2001 15:56:23 |------------------------------------------------------------------------------| | | | | | | |------------------------------------------------------------------------------| |----------+-------------------------------------------------------------| | | | | | | | | | |----------+-------------------------------------------------------------| | | | | To: | "'PSK Chakravarthi'" , | | | "'Madhu Babu Brahmanapally'" , | | | "'Terry L Anderson'" | | | | |----------+-------------------------------------------------------------| | | | | cc: | megaco@fore.com(bcc: Sean Leahy/MAIN/MC1) | | | | |----------+-------------------------------------------------------------| | | | | | | | | | |----------+-------------------------------------------------------------| | | | | Subject: | RE: Ephemeral Termination | | | | |----------+-------------------------------------------------------------| (Embedded image moved to file: pic06763.pcx) I'm having trouble following your logic. This seems to be a trunk GW/ISUP issue, so we don't have to deal with off hook/DTMF issues, right? In the case of hairpin, you need two commands: 1) An add to put the originating termination in the context 2) An add to put the terminating termination in the context. They cannot be in the same transaction if you have not completed digit analysis before you do 1. In the case of a normal connection between two MGs you need 4 total commands: 1) The Add of the physical in the originating MG 2) The Add of the ephemeral in the originating MG 3) The Add of the physical in the terminating MG 4) The Add of the ephemeral in the terminating MG You can do 1 before you do digit analysis. You have to do 3 and 4 after digit analysis, but they can be in the same transaction. If you do 2 before you do digit analysis, you would not have the correct remote SDP, and therefore you would need to send a Modify after digit analysis. If you do it after you do digit analysis, then you only have the 4 commands. Before digit analysis, the MGC sends 1. After digit analysis the MGC sends two transactions in two messages; one to the originating MG (message 2 containing correct local and remote SDP) and one to the terminating MG (with messages 3 and 4 including all the SDP). In most cases, I suspect it would actually be more efficient to send message 1 after digit analysis, because then the originating MG has one less transaction to process, but the same number of commands. The call setup difference between the originating MG doing one add before digit analysis and another after vs doing both after won't matter enough to be measurable I think, but the difference in processing of half the number of messages will be substantial. I see no way to have the Add of the ephemeral before digit analysis improve call setup time. It seems to only create extra work for the originating MG. Brian > -----Original Message----- > From: PSK Chakravarthi [mailto:chak@axes-mach01.usa.alcatel.com] > Sent: Thursday, June 21, 2001 10:10 AM > To: Rosen, Brian; 'Madhu Babu Brahmanapally'; 'Terry L Anderson' > Cc: megaco@fore.com > Subject: Re: Ephemeral Termination > > > The reason for creating Ephemeral and reserving SDP before knowing the > termination is to reduce the call setup time. > > Following is the MGC processing. > > 1. Soon after receiving IAM send ADD command to the originating MG for > a)Creating Ephemeral > b)Reserving SDP for Local > c)Simultaneously start digit analysis > After finding termination > (By this time ADD response would have been received, if not > MGC need to wait for > ADD response) > If terminating trunk belongs to the same MG > a) send ADD command to add the second termination to the > same context. > This ADD command will have empty Local descriptor to > release resources > previously allocated. > Note that ephemeral is not SUBTRACTED. Also MODIFY to > originating MG is > not required as MG is going to make only hairpin connection. > If the terminating MG is not same as originating MG > Send ADD command to terminating MG > a) Creating Ephemeral > b) Reserving SDP for Local > c) Setting SDP remote as Local returned by the originating MG. > After receiving the ADD response from terminating MG > Send MODIFY to originating MG for setting remote Descriptor. > > If you send ADD command to the originating MG only after > knowing the terminator, > MGC had completed processing of the call but now it need to > wait for sending > three commands > (ADD to originating MG, ADD to terminating MG and MODIFY to > originating MG) and > their responses. > > Take the case of trunking gateway, where the number of calls > originating on a MG > and terminating on the same MG are much less than calls originated and > terminated on two different MGs. > > thanks & regards > Chak > > ----- Original Message ----- > From: "Rosen, Brian" > To: "'PSK Chakravarthi'" ; > "'Madhu Babu > Brahmanapally'" ; "'Terry L Anderson'" > > Cc: > Sent: Thursday, June 21, 2001 7:21 PM > Subject: RE: Ephemeral Termination > > > > There is no way this will reduce call setup time. > > Since you do not have the destination information, you > > will have to MODIFY the ephemeral when you do. The processing > > time for the Modify won't be substantially more than doing > > an Add at that point, and there is no difference to the actual > > operation of the gateway. > > > > Brian > > > > > -----Original Message----- > > > From: PSK Chakravarthi [mailto:chak@axes-mach01.usa.alcatel.com] > > > Sent: Thursday, June 21, 2001 1:43 AM > > > To: Rosen, Brian; 'Madhu Babu Brahmanapally'; 'Terry L Anderson' > > > Cc: megaco@fore.com > > > Subject: Re: Ephemeral Termination > > > > > > > > > The reason for creating Ephemeral and reserving SDP > before knowing the > > > termination is > > > to reduce the call setup time. > > > > > > thanks & regards > > > Chak > > > ----- Original Message ----- > > > From: "Rosen, Brian" > > > To: "'Madhu Babu Brahmanapally'" ; > > > "'Terry L Anderson'" > > > ; "'PSK Chakravarthi'" > > > > > > Cc: > > > Sent: Wednesday, June 20, 2001 9:07 PM > > > Subject: RE: Ephemeral Termination > > > > > > > > > > I'm not at all sure what "resources" you can reserve before you > > > > know the destination: > > > > > > > > For an IP network, you can reserve a UDP port I > suppose, but until > > > > you negotiate the SDP, you can't reserve bandwidth. You can't > > > > make any QoS reservation for the same reason. > > > > > > > > It's worse on an ATM network. > > > > > > > > I think there is nothing to be gained by #1 > > > > > > > > Brian > > > > > > > > > -----Original Message----- > > > > > From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com] > > > > > Sent: Wednesday, June 20, 2001 11:28 AM > > > > > To: 'Terry L Anderson'; 'PSK Chakravarthi' > > > > > Cc: megaco@fore.com > > > > > Subject: RE: Ephemeral Termination > > > > > > > > > > > > > > > Hi All, > > > > > The creation of ephemeral termination can be done either > > > after digit > > > > > analysis or before it. Each has its own advantages and > > > disadvantages. > > > > > > > > > > 1) If Ephemeral termination is created before digit analysis, > > > > > situation may > > > > > occur where the destination user/termination is connected to > > > > > the same MG and > > > > > there is no need to create an ephemeral termination (as PSK > > > > > mentioned). But > > > > > this has the advantage that the call wont be dropped due > > > to lack of > > > > > resource, as ephemeral resources are pre-reserved at the MG. > > > > > (in case Add > > > > > fails later to add ephemeral termination). > > > > > > > > > > 2) If Ephemeral termination is created after digit analysis, > > > > > it takes care > > > > > of all situation where destination user may/may not connected > > > > > to the same > > > > > MG. But when Ephemeral termination is added later, there is no > > > > > pre-reservation of the ephemeral resources at the > origination MG. > > > > > > > > > > In case of 1) if the call doesn't mature, reserving the > > > > > resources doesn't > > > > > gain anything. Consideration that the destination user on the > > > > > same MG is > > > > > less probable, Method 2 IMO will be a better choice. > > > > > > > > > > Regards > > > > > Madhubabu > > > > > > > > > > -----Original Message----- > > > > > From: owner-megaco@pit.comms.marconi.com > > > > > [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Terry > > > > > L Anderson > > > > > Sent: Wednesday, June 20, 2001 11:01 AM > > > > > To: PSK Chakravarthi > > > > > Cc: megaco@fore.com > > > > > Subject: Re: Ephemeral Termination > > > > > > > > > > > > > > > > > > > > > > > > > PSK Chakravarthi wrote: > > > > > > > > > > > I have got the following doubt. > > > > > > If the originating and terminating termination IDs are on > > > > > the same gateway > > > > > and > > > > > > gateway supports two TDM terminations in a context, is it > > > > > required to > > > > > craete a > > > > > > ephenmeral termination for this call? > > > > > > > > > > > > Message flow between MGC and MG: > > > > > > > > > > > > 1. MGC send ADD command to originating MG > > > > > > a) Choose a context ID > > > > > > b) Add a TDM termination > > > > > > c) Choose a Ephemeral termination > > > > > > d) Reserve Local Descriptor > > > > > > e) set MODE to Receive only. > > > > > > > > > > > > 2. MGC now finds that call is terminating on the same MG. > > > > > Also MGC knows > > > > > that > > > > > > MG is capable of adding two TDMs to the same context. At > > > > > this point what > > > > > should > > > > > > be the command to the MG? > > > > > > Is it required to SUBTRACT the ephemeral termination and > > > > > send ADD for > > > > > adding new > > > > > > TDM to the same context? or > > > > > > Simply sending ADD for new TDM to the same context is > > > sufficient? > > > > > > > > > > It would be better if MGC "finds" that the call is terminated > > > > > on the same MG > > > > > before > > > > > sending the ADD, in step 1c, but if since step c (which you > > > > > call "Choose a > > > > > Ephemeral > > > > > termination) is an Add with wildcard, MGC must certainly > > > > > Subtract it if it > > > > > chooses > > > > > later not to use it. The Subtract deletes the ephemeral > > > > > termination and > > > > > releases > > > > > its resources. > > > > > > > > > > > thanks & regards > > > > > > Chak > > > > > > > > > > -- > > > > > ------------------------------------------------------------ > > > > > Terry L Anderson mailto:tla@lucent.com > > > > > Tel:908.582.7013 Fax:908.582.6729 > > > > > Lucent Technologies/INS/Voice Over IP Access Networks > > > > > Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 > > > > > http://its.lucent.com/~tla (Lucent internal) > > http://www.gti.net/tla > > > > > > > > > > > > > > --0__=QD8vBJ9B5zKiK4ix0MPgrANQM4EM0xit1JYzfYwO4xDoZKp7NjwIn6O2 Content-type: application/octet-stream; name="pic28418.pcx" Content-Disposition: attachment; filename="pic28418.pcx" Content-Transfer-Encoding: base64 CgUBCAAAAABwADcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAABcQABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAADt/9IA2v/N/8b/w//C/+3/AND/wgDZ/83/xv/D/8L/7f8A0P8ApADZ/8z/ xv/D/8L/7f8A0P8Awf+kANj/zP/G/8P/wv/t/wDQ/wDC/6QA2P/M/8b/w//B/+3/AND/AMP/pMIA 1//L/8b/w//B/+3/AND/yADW/8v/xv/D/8H/7f8A1/8ApNb/y//F/8P/wf/t/wDX/wCk1v/L/8X/ w//B/+3/ANf/AKTW/8v/xf/D/8H/7f8A1/8ApNb/y//F/8P/wf/t/wDX/wCk1v/L/8X/w//B/+3/ ANf/AKTW/8v/xf/D/8H/7f8A1/8ApNb/y//F/8P/wf/t/wDX/wCk1v/L/8X/w//B/+3/ANf/AKTW /8v/xf/D/8H/7f8A1/8ApNb/y//F/8P/wf/t/wDX/wCk1v/L/8X/w//B/+3/ANf/AKTW/8v/xf/D /8H/7f8A1/8ApNb/y//F/8P/wf/t/wDX/wCk1v/L/8X/w//B/+3/ANf/AKTW/8v/xf/D/8H/7f8A 1/8ApNb/y//F/8P/wf/t/wDX/wCk1v/L/8X/w//B/+3/ANf/AKTW/8v/xf/D/8H/7f8A1/8ApNb/ y//F/8P/wf/t/9kApNb/y//F/8P/wf/u/9mk1v/L/8X/w//B//n/3f/O/8f/xP/C//n/3f/O/8f/ xP/C//n/3f/O/8f/xP/C//n/3f/O/8f/xP/C//n/3f/O/8f/xP/C//n/3f/O/8f/xP/C//n/3f/O /8f/xP/C/9v/wwDK/wDC/8QAw/8AyP/EAMP/AMX/ANX/yv/F/8P/wf/a/wDD/wDC/wDG/wDB/wDE /wDC/wDH/wDE/wDC/wDT/wDO/8f/w//C/9r/AMb/AMb/AMH/AMT/AML/AMf/AMT/AML/ANP/AM7/ x//D/8L/2v8Axv/CAML/xADB/wDE/wDC/wDC/8MAwv8AxP8Awv/EAML/AML/wwDD/8MAwv/CAM3/ x//D/8L/2//DAMP/AML/AMP/AMH/AMT/AML/AMH/AMP/AMH/AMT/AML/AMP/AMH/AMH/AMP/AMH/ AMP/AMH/AM7/x//D/8L/3v8Awv8Awv8Aw/8Awf8AxP8Awv8Awf/FAMH/AMT/AML/AMP/AMH/AMH/ xQDB/wDF/wDO/8f/w//C/97/AML/AML/AMP/AMH/AMT/AML/AMH/AMX/AMT/AML/AMP/AMH/AMH/ AMX/AMX/AM7/x//D/8L/2v8Aw/8Awv8Awv8Aw/8Awf8AxP8Awv8Awf8Aw/8Awf8AxP8Awv8Aw/8A wf8Awf8Aw/8Awf8Aw/8Awf8Azv/H/8P/wv/b/8MAxP8Awv/EAML/xADD/wDC/8MAw//EAMP/xADC /wDC/8MAw//DAMP/AM3/x//D/8L/+f/P/wDV/8r/xf/D/8H/+f/P/wDV/8r/xf/D/8H/+f/d/87/ x//E/8L/+f/d/87/x//E/8L/+f/d/87/x//E/8L/+f/d/87/x//E/8L/+f/d/87/x//E/8L/+f/d /87/x//E/8L/+f/d/87/x//E/8L/+f/d/87/x//E/8L/+f/d/87/x//E/8L/+f/d/87/x//E/8L/ DAAAAIAAAACAAICAAAAAgIAAgACAgMDAwMDcwKbK8EAgAGAgAIAgAKAgAMAgAOAgAABAACBAAEBA AGBAAIBAAKBAAMBAAOBAAABgACBgAEBgAGBgAIBgAKBgAMBgAOBgAACAACCAAECAAGCAAICAAKCA AMCAAOCAAACgACCgAECgAGCgAICgAKCgAMCgAOCgAADAACDAAEDAAGDAAIDAAKDAAMDAAODAAADg ACDgAEDgAGDgAIDgAKDgAMDgAODgAAAAQCAAQEAAQGAAQIAAQKAAQMAAQOAAQAAgQCAgQEAgQGAg QIAgQKAgQMAgQOAgQABAQCBAQEBAQGBAQIBAQKBAQMBAQOBAQABgQCBgQEBgQGBgQIBgQKBgQMBg QOBgQACAQCCAQECAQGCAQICAQKCAQMCAQOCAQACgQCCgQECgQGCgQICgQKCgQMCgQOCgQADAQCDA QEDAQGDAQIDAQKDAQMDAQODAQADgQCDgQEDgQGDgQIDgQKDgQMDgQODgQAAAgCAAgEAAgGAAgIAA gKAAgMAAgOAAgAAggCAggEAggGAggIAggKAggMAggOAggABAgCBAgEBAgGBAgIBAgKBAgMBAgOBA gABggCBggEBggGBggIBggKBggMBggOBggACAgCCAgECAgGCAgICAgKCAgMCAgOCAgACggCCggECg gGCggICggKCggMCggOCggADAgCDAgEDAgGDAgIDAgKDAgMDAgODAgADggCDggEDggGDggIDggKDg gMDggODggAAAwCAAwEAAwGAAwIAAwKAAwMAAwOAAwAAgwCAgwEAgwGAgwIAgwKAgwMAgwOAgwABA wCBAwEBAwGBAwIBAwKBAwMBAwOBAwABgwCBgwEBgwGBgwIBgwKBgwMBgwOBgwACAwCCAwECAwGCA wICAwKCAwMCAwOCAwACgwCCgwECgwGCgwICgwKCgwMCgwOCgwADAwCDAwEDAwGDAwIDAwKDAwP/7 8KCgpICAgP8AAAD/AP//AAAA//8A/wD//////w== --0__=QD8vBJ9B5zKiK4ix0MPgrANQM4EM0xit1JYzfYwO4xDoZKp7NjwIn6O2 Content-type: application/octet-stream; name="pic06763.pcx" Content-Disposition: attachment; filename="pic06763.pcx" Content-Transfer-Encoding: base64 CgUBCAAAAABwADcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAABcQABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAADt/9IA2v/N/8b/w//C/+3/AND/wgDZ/83/xv/D/8L/7f8A0P8ApADZ/8z/ xv/D/8L/7f8A0P8Awf+kANj/zP/G/8P/wv/t/wDQ/wDC/6QA2P/M/8b/w//B/+3/AND/AMP/pMIA 1//L/8b/w//B/+3/AND/yADW/8v/xv/D/8H/7f8A1/8ApNb/y//F/8P/wf/t/wDX/wCk1v/L/8X/ w//B/+3/ANf/AKTW/8v/xf/D/8H/7f8A1/8ApNb/y//F/8P/wf/t/wDX/wCk1v/L/8X/w//B/+3/ ANf/AKTW/8v/xf/D/8H/7f8A1/8ApNb/y//F/8P/wf/t/wDX/wCk1v/L/8X/w//B/+3/ANf/AKTW /8v/xf/D/8H/7f8A1/8ApNb/y//F/8P/wf/t/wDX/wCk1v/L/8X/w//B/+3/ANf/AKTW/8v/xf/D /8H/7f8A1/8ApNb/y//F/8P/wf/t/wDX/wCk1v/L/8X/w//B/+3/ANf/AKTW/8v/xf/D/8H/7f8A 1/8ApNb/y//F/8P/wf/t/wDX/wCk1v/L/8X/w//B/+3/ANf/AKTW/8v/xf/D/8H/7f8A1/8ApNb/ y//F/8P/wf/t/9kApNb/y//F/8P/wf/u/9mk1v/L/8X/w//B//n/3f/O/8f/xP/C//n/3f/O/8f/ xP/C//n/3f/O/8f/xP/C//n/3f/O/8f/xP/C//n/3f/O/8f/xP/C//n/3f/O/8f/xP/C//n/3f/O /8f/xP/C/9v/wwDK/wDC/8QAw/8AyP/EAMP/AMX/ANX/yv/F/8P/wf/a/wDD/wDC/wDG/wDB/wDE /wDC/wDH/wDE/wDC/wDT/wDO/8f/w//C/9r/AMb/AMb/AMH/AMT/AML/AMf/AMT/AML/ANP/AM7/ x//D/8L/2v8Axv/CAML/xADB/wDE/wDC/wDC/8MAwv8AxP8Awv/EAML/AML/wwDD/8MAwv/CAM3/ x//D/8L/2//DAMP/AML/AMP/AMH/AMT/AML/AMH/AMP/AMH/AMT/AML/AMP/AMH/AMH/AMP/AMH/ AMP/AMH/AM7/x//D/8L/3v8Awv8Awv8Aw/8Awf8AxP8Awv8Awf/FAMH/AMT/AML/AMP/AMH/AMH/ xQDB/wDF/wDO/8f/w//C/97/AML/AML/AMP/AMH/AMT/AML/AMH/AMX/AMT/AML/AMP/AMH/AMH/ AMX/AMX/AM7/x//D/8L/2v8Aw/8Awv8Awv8Aw/8Awf8AxP8Awv8Awf8Aw/8Awf8AxP8Awv8Aw/8A wf8Awf8Aw/8Awf8Aw/8Awf8Azv/H/8P/wv/b/8MAxP8Awv/EAML/xADD/wDC/8MAw//EAMP/xADC /wDC/8MAw//DAMP/AM3/x//D/8L/+f/P/wDV/8r/xf/D/8H/+f/P/wDV/8r/xf/D/8H/+f/d/87/ x//E/8L/+f/d/87/x//E/8L/+f/d/87/x//E/8L/+f/d/87/x//E/8L/+f/d/87/x//E/8L/+f/d /87/x//E/8L/+f/d/87/x//E/8L/+f/d/87/x//E/8L/+f/d/87/x//E/8L/+f/d/87/x//E/8L/ DAAAAIAAAACAAICAAAAAgIAAgACAgMDAwMDcwKbK8EAgAGAgAIAgAKAgAMAgAOAgAABAACBAAEBA AGBAAIBAAKBAAMBAAOBAAABgACBgAEBgAGBgAIBgAKBgAMBgAOBgAACAACCAAECAAGCAAICAAKCA AMCAAOCAAACgACCgAECgAGCgAICgAKCgAMCgAOCgAADAACDAAEDAAGDAAIDAAKDAAMDAAODAAADg ACDgAEDgAGDgAIDgAKDgAMDgAODgAAAAQCAAQEAAQGAAQIAAQKAAQMAAQOAAQAAgQCAgQEAgQGAg QIAgQKAgQMAgQOAgQABAQCBAQEBAQGBAQIBAQKBAQMBAQOBAQABgQCBgQEBgQGBgQIBgQKBgQMBg QOBgQACAQCCAQECAQGCAQICAQKCAQMCAQOCAQACgQCCgQECgQGCgQICgQKCgQMCgQOCgQADAQCDA QEDAQGDAQIDAQKDAQMDAQODAQADgQCDgQEDgQGDgQIDgQKDgQMDgQODgQAAAgCAAgEAAgGAAgIAA gKAAgMAAgOAAgAAggCAggEAggGAggIAggKAggMAggOAggABAgCBAgEBAgGBAgIBAgKBAgMBAgOBA gABggCBggEBggGBggIBggKBggMBggOBggACAgCCAgECAgGCAgICAgKCAgMCAgOCAgACggCCggECg gGCggICggKCggMCggOCggADAgCDAgEDAgGDAgIDAgKDAgMDAgODAgADggCDggEDggGDggIDggKDg gMDggODggAAAwCAAwEAAwGAAwIAAwKAAwMAAwOAAwAAgwCAgwEAgwGAgwIAgwKAgwMAgwOAgwABA wCBAwEBAwGBAwIBAwKBAwMBAwOBAwABgwCBgwEBgwGBgwIBgwKBgwMBgwOBgwACAwCCAwECAwGCA wICAwKCAwMCAwOCAwACgwCCgwECgwGCgwICgwKCgwMCgwOCgwADAwCDAwEDAwGDAwIDAwKDAwP/7 8KCgpICAgP8AAAD/AP//AAAA//8A/wD//////w== --0__=QD8vBJ9B5zKiK4ix0MPgrANQM4EM0xit1JYzfYwO4xDoZKp7NjwIn6O2-- From owner-megaco@fore.com Fri Jun 22 12:21:12 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA29041 for ; Fri, 22 Jun 2001 12:21:11 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA00356; Fri, 22 Jun 2001 12:03:06 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id LAA17658 for megaco-list; Fri, 22 Jun 2001 11:59:56 -0400 (EDT) Received: from notes.marconicommsna.com ([208.43.60.106]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA17653 for ; Fri, 22 Jun 2001 11:59:55 -0400 (EDT) From: Brian.Rosen@marconi.com To: Sean.Leahy@marconi.com Cc: megaco@fore.com X-Priority: 3 (Normal) Importance: Normal Date: Fri, 22 Jun 2001 11:59:45 -0400 Subject: RE: Ephemeral Termination Message-ID: X-MIMETrack: Serialize by Router on MHDGWY02/S/EXT/MC1(Release 5.0.6a |January 17, 2001) at 06/22/2001 11:57:55 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Okay, so the problem you postulate is that there are TWO instances of an MGC handling the two sides of the connection and thus you don't know that the same MG is being used. I'll leave the issue of how the two MGCs share the resources of the MG to another discussion; let's suppose for the moment that two virtual MGs are assigned one each to the two MGC instances -- is that close?? Now, in theory, anyway, no-one figure out that it's the same MG. In that case, your MG better be able to send packets to itself. Then, backing up a little, it's the MG that figures it out, in which case it has two contexts, each with two terminations, and it knows that in fact the two ephemerals are "connected" via the net. It can, in theory anyway, fake the network connection and "do the right thing". In this case, as far as the MGCs know, it IS going across the network; the MG is just optimizing the network path! Now we step back to your position, which is that, somehow, the two MGC instances discover this, and you want to know how they should handle that. Is that right? Well, I must be dense or something, because I would say that the MGCs never Add the ephemeral until they know what the other end is, and then they add it with all the right characteristics. If the originating MGC instance communicates with the terminating MGC instance and discovers that both ends are in the same MG, in my postulated Virtual MG scenario they CAN'T actually do the really right thing, which is to create one context with both physical terminations, because there is no way for either of the two MGCs to access the other physical termination, and one MGC can't use the other MGC's ContextId. So, you HAVE to let the MG do it, if at all. So, if the real bottom line question you are asking is if I have a circumstance where the physical MG is presented with a circumstance where it has two, 2 termination contexts, where the ephemerals are cross connected, can it optimize that to make a hairpin without telling the MGCs what is happening, I'd say yes, but it has to do all of the right thing. This would include, for example, supplying some appropriate statistics for the ephemerals! If you are asking if I ever see a circumstance where it makes sense to have a 3 termination context with two physicals and an ephemeral, where the ephemeral isn't actually "active" (doesn't have a remote), then I would say, no I don't see how that ever makes sense. Would it work? That is, should an MG actually allow it? I don't know; it's really an error (incomplete characterization of the ephemeral), but that is allowed at least transiently. I could see some timeout, but that would not be a "standards based" thing. So, I expect in most cases it actually would work. YMMV. Brian -----Original Message----- From: Leahy, Sean Sent: Friday, June 22, 2001 11:25 AM To: Rosen, Brian Cc: megaco@fore.com Subject: RE: Ephemeral Termination Brian, Briefly, the scenario that I was postulating was that the Call Control at the MGC (or above the MGC - depending on how you define an 'MGC' realisation) is separate from the bearer control at the MGC. Thus the MGC bearer signalling is independent enough from the call control/digit analysis that it does not allow the H.248 functionality to be told directly that the two physical terminations are on the same MG when it is first invoked (for the connection to termination A) from the call control function. The MGC might work this out when it is invoked for the connection to termination B, but there may be a problem if there are two separate instances of the same MGC handling each side of the connection. Thus the question remains - Is there any possibility for a Media Gateway to optimise such a hair-pin connection whilst maintaining the same model to the MGC ? Obviously, the alternative is to change both the call control and bearer control layers to be able to harmonise better to deal with hairpin connections. But it would be interesting to know if you think optimisation at the MG is a possibility that might mean this could be avoided, if it were so desired. Regards, Sean Leahy From: Brian Rosen/MAIN/MC1@MSEXCH on 22/06/2001 13:39 To: Sean Leahy/MAIN/MC1@MCMAIN cc: megaco@fore.com Subject: RE: Ephemeral Termination I'm having trouble following your question. The example we are discussing, trunk gateways, has digit analysis and call control done completely in the MGC; the MG has no role at all in these matters. The fact that digit analysis takes some time in the MGC is, I believe, the reasons being advanced for starting with the originating MG and doing everything you can in advance of determining the terminating MG. If the design of the MGC is such that it gets all the information at once (both ends), it can send out the optimal 2 transaction/4 command sequence. The issue is that you gain nothing by anticipating that you might need an ephemeral. Whether it turns out that you do (originating MG not equal terminating MG) or you don't (hairpin), putting the ephemeral in the context before you know doesn't help anything. It may or may not "work" in all MGs, but I don't see any reason to do it. Maybe I'm missing something. Brian -----Original Message----- From: Leahy, Sean Sent: Friday, June 22, 2001 4:09 AM To: Rosen, Brian Cc: megaco@fore.com Subject: RE: Ephemeral Termination Brian, Just a question. There may be cases where Megaco is being used solely for bearer control and the call control/digit analysis is conducted at a layer above the Megaco protocol. In these circumstances, it is also possible that ephemerals are added and modified by command from the MGC when the bearer connection is actually between two physical terminations on the same Media Gateway. Is it altogether impossible for a Media Gateway to optimise such a hair-pin connection whilst maintaining the same model to the MGC ? Sean Leahy Marconi << OLE Object: Picture (Device Independent Bitmap) >> CN=Brian Rosen/OU=MAIN/O=MC1@MSEXCH on 21/06/2001 15:56:23 |----------------------------------------------------------------------------------------------------------------------------------------------------| | | | | | | |----------------------------------------------------------------------------------------------------------------------------------------------------| |------------+-------------------------------------------------------------------------| | | | | | | | | | |------------+-------------------------------------------------------------------------| | | | | To: | "'PSK Chakravarthi'" , "'Madhu Babu | | | Brahmanapally'" , "'Terry L Anderson'" | | | | | | | |------------+-------------------------------------------------------------------------| | | | | cc: | megaco@fore.com(bcc: Sean Leahy/MAIN/MC1) | | | | |------------+-------------------------------------------------------------------------| | | | | | | | | | |------------+-------------------------------------------------------------------------| | | | | Subject: | RE: Ephemeral Termination | | | | |------------+-------------------------------------------------------------------------| << OLE Object: Picture (Device Independent Bitmap) >> I'm having trouble following your logic. This seems to be a trunk GW/ISUP issue, so we don't have to deal with off hook/DTMF issues, right? In the case of hairpin, you need two commands: 1) An add to put the originating termination in the context 2) An add to put the terminating termination in the context. They cannot be in the same transaction if you have not completed digit analysis before you do 1. In the case of a normal connection between two MGs you need 4 total commands: 1) The Add of the physical in the originating MG 2) The Add of the ephemeral in the originating MG 3) The Add of the physical in the terminating MG 4) The Add of the ephemeral in the terminating MG You can do 1 before you do digit analysis. You have to do 3 and 4 after digit analysis, but they can be in the same transaction. If you do 2 before you do digit analysis, you would not have the correct remote SDP, and therefore you would need to send a Modify after digit analysis. If you do it after you do digit analysis, then you only have the 4 commands. Before digit analysis, the MGC sends 1. After digit analysis the MGC sends two transactions in two messages; one to the originating MG (message 2 containing correct local and remote SDP) and one to the terminating MG (with messages 3 and 4 including all the SDP). In most cases, I suspect it would actually be more efficient to send message 1 after digit analysis, because then the originating MG has one less transaction to process, but the same number of commands. The call setup difference between the originating MG doing one add before digit analysis and another after vs doing both after won't matter enough to be measurable I think, but the difference in processing of half the number of messages will be substantial. I see no way to have the Add of the ephemeral before digit analysis improve call setup time. It seems to only create extra work for the originating MG. Brian > -----Original Message----- > From: PSK Chakravarthi [mailto:chak@axes-mach01.usa.alcatel.com] > Sent: Thursday, June 21, 2001 10:10 AM > To: Rosen, Brian; 'Madhu Babu Brahmanapally'; 'Terry L Anderson' > Cc: megaco@fore.com > Subject: Re: Ephemeral Termination > > > The reason for creating Ephemeral and reserving SDP before knowing the > termination is to reduce the call setup time. > > Following is the MGC processing. > > 1. Soon after receiving IAM send ADD command to the originating MG for > a)Creating Ephemeral > b)Reserving SDP for Local > c)Simultaneously start digit analysis > After finding termination > (By this time ADD response would have been received, if not > MGC need to wait for > ADD response) > If terminating trunk belongs to the same MG > a) send ADD command to add the second termination to the > same context. > This ADD command will have empty Local descriptor to > release resources > previously allocated. > Note that ephemeral is not SUBTRACTED. Also MODIFY to > originating MG is > not required as MG is going to make only hairpin connection. > If the terminating MG is not same as originating MG > Send ADD command to terminating MG > a) Creating Ephemeral > b) Reserving SDP for Local > c) Setting SDP remote as Local returned by the originating MG. > After receiving the ADD response from terminating MG > Send MODIFY to originating MG for setting remote Descriptor. > > If you send ADD command to the originating MG only after > knowing the terminator, > MGC had completed processing of the call but now it need to > wait for sending > three commands > (ADD to originating MG, ADD to terminating MG and MODIFY to > originating MG) and > their responses. > > Take the case of trunking gateway, where the number of calls > originating on a MG > and terminating on the same MG are much less than calls originated and > terminated on two different MGs. > > thanks & regards > Chak > > ----- Original Message ----- > From: "Rosen, Brian" > To: "'PSK Chakravarthi'" ; > "'Madhu Babu > Brahmanapally'" ; "'Terry L Anderson'" > > Cc: > Sent: Thursday, June 21, 2001 7:21 PM > Subject: RE: Ephemeral Termination > > > > There is no way this will reduce call setup time. > > Since you do not have the destination information, you > > will have to MODIFY the ephemeral when you do. The processing > > time for the Modify won't be substantially more than doing > > an Add at that point, and there is no difference to the actual > > operation of the gateway. > > > > Brian > > > > > -----Original Message----- > > > From: PSK Chakravarthi [mailto:chak@axes-mach01.usa.alcatel.com] > > > Sent: Thursday, June 21, 2001 1:43 AM > > > To: Rosen, Brian; 'Madhu Babu Brahmanapally'; 'Terry L Anderson' > > > Cc: megaco@fore.com > > > Subject: Re: Ephemeral Termination > > > > > > > > > The reason for creating Ephemeral and reserving SDP > before knowing the > > > termination is > > > to reduce the call setup time. > > > > > > thanks & regards > > > Chak > > > ----- Original Message ----- > > > From: "Rosen, Brian" > > > To: "'Madhu Babu Brahmanapally'" ; > > > "'Terry L Anderson'" > > > ; "'PSK Chakravarthi'" > > > > > > Cc: > > > Sent: Wednesday, June 20, 2001 9:07 PM > > > Subject: RE: Ephemeral Termination > > > > > > > > > > I'm not at all sure what "resources" you can reserve before you > > > > know the destination: > > > > > > > > For an IP network, you can reserve a UDP port I > suppose, but until > > > > you negotiate the SDP, you can't reserve bandwidth. You can't > > > > make any QoS reservation for the same reason. > > > > > > > > It's worse on an ATM network. > > > > > > > > I think there is nothing to be gained by #1 > > > > > > > > Brian > > > > > > > > > -----Original Message----- > > > > > From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com] > > > > > Sent: Wednesday, June 20, 2001 11:28 AM > > > > > To: 'Terry L Anderson'; 'PSK Chakravarthi' > > > > > Cc: megaco@fore.com > > > > > Subject: RE: Ephemeral Termination > > > > > > > > > > > > > > > Hi All, > > > > > The creation of ephemeral termination can be done either > > > after digit > > > > > analysis or before it. Each has its own advantages and > > > disadvantages. > > > > > > > > > > 1) If Ephemeral termination is created before digit analysis, > > > > > situation may > > > > > occur where the destination user/termination is connected to > > > > > the same MG and > > > > > there is no need to create an ephemeral termination (as PSK > > > > > mentioned). But > > > > > this has the advantage that the call wont be dropped due > > > to lack of > > > > > resource, as ephemeral resources are pre-reserved at the MG. > > > > > (in case Add > > > > > fails later to add ephemeral termination). > > > > > > > > > > 2) If Ephemeral termination is created after digit analysis, > > > > > it takes care > > > > > of all situation where destination user may/may not connected > > > > > to the same > > > > > MG. But when Ephemeral termination is added later, there is no > > > > > pre-reservation of the ephemeral resources at the > origination MG. > > > > > > > > > > In case of 1) if the call doesn't mature, reserving the > > > > > resources doesn't > > > > > gain anything. Consideration that the destination user on the > > > > > same MG is > > > > > less probable, Method 2 IMO will be a better choice. > > > > > > > > > > Regards > > > > > Madhubabu > > > > > > > > > > -----Original Message----- > > > > > From: owner-megaco@pit.comms.marconi.com > > > > > [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Terry > > > > > L Anderson > > > > > Sent: Wednesday, June 20, 2001 11:01 AM > > > > > To: PSK Chakravarthi > > > > > Cc: megaco@fore.com > > > > > Subject: Re: Ephemeral Termination > > > > > > > > > > > > > > > > > > > > > > > > > PSK Chakravarthi wrote: > > > > > > > > > > > I have got the following doubt. > > > > > > If the originating and terminating termination IDs are on > > > > > the same gateway > > > > > and > > > > > > gateway supports two TDM terminations in a context, is it > > > > > required to > > > > > craete a > > > > > > ephenmeral termination for this call? > > > > > > > > > > > > Message flow between MGC and MG: > > > > > > > > > > > > 1. MGC send ADD command to originating MG > > > > > > a) Choose a context ID > > > > > > b) Add a TDM termination > > > > > > c) Choose a Ephemeral termination > > > > > > d) Reserve Local Descriptor > > > > > > e) set MODE to Receive only. > > > > > > > > > > > > 2. MGC now finds that call is terminating on the same MG. > > > > > Also MGC knows > > > > > that > > > > > > MG is capable of adding two TDMs to the same context. At > > > > > this point what > > > > > should > > > > > > be the command to the MG? > > > > > > Is it required to SUBTRACT the ephemeral termination and > > > > > send ADD for > > > > > adding new > > > > > > TDM to the same context? or > > > > > > Simply sending ADD for new TDM to the same context is > > > sufficient? > > > > > > > > > > It would be better if MGC "finds" that the call is terminated > > > > > on the same MG > > > > > before > > > > > sending the ADD, in step 1c, but if since step c (which you > > > > > call "Choose a > > > > > Ephemeral > > > > > termination) is an Add with wildcard, MGC must certainly > > > > > Subtract it if it > > > > > chooses > > > > > later not to use it. The Subtract deletes the ephemeral > > > > > termination and > > > > > releases > > > > > its resources. > > > > > > > > > > > thanks & regards > > > > > > Chak > > > > > > > > > > -- > > > > > ------------------------------------------------------------ > > > > > Terry L Anderson mailto:tla@lucent.com > > > > > Tel:908.582.7013 Fax:908.582.6729 > > > > > Lucent Technologies/INS/Voice Over IP Access Networks > > > > > Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 > > > > > http://its.lucent.com/~tla (Lucent internal) > > http://www.gti.net/tla > > > > > > > > > > > > > > From owner-megaco@fore.com Fri Jun 22 13:00:19 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA00279 for ; Fri, 22 Jun 2001 13:00:18 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA03439; Fri, 22 Jun 2001 12:48:36 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id MAA27634 for megaco-list; Fri, 22 Jun 2001 12:44:53 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA27626 for ; Fri, 22 Jun 2001 12:44:52 -0400 (EDT) From: Dave.Sclarsky@radisys.com Received: from radisys.com (mail-gw.radisys.com [206.102.10.35]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA03149 for ; Fri, 22 Jun 2001 12:44:45 -0400 (EDT) Received: (22945 bytes) by radisys.com via sendmail with P:stdio/R:inet_hosts/T:smtp (sender: ) id for megaco@fore.com; Fri, 22 Jun 2001 09:44:46 -0700 (PDT) (Smail-3.2.0.105 1999-Mar-3 #2 built 1999-Apr-18) Received: from notes.radisys.com(206.103.52.220) via SMTP by mail-gw.radisys.com, id smtpdAAAK3aOyY; Fri Jun 22 09:44:31 2001 To: Brian.Rosen@marconi.com Cc: megaco@fore.com, owner-megaco@pit.comms.marconi.com, Sean.Leahy@marconi.com Subject: RE: Ephemeral Termination MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Fri, 22 Jun 2001 12:42:05 -0400 X-MIMETrack: Serialize by Router on HQ_ACS_1/Radisys_Corporation/US(Release 5.0.6a |January 17, 2001) at 06/22/2001 09:44:15 AM, Serialize complete at 06/22/2001 09:44:15 AM Content-Type: text/plain; charset="us-ascii" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Does an MG that 'discovers' that it has 2 ephemerals that are "connected" via the net and bypasses the network connection pose a problem related to CALEA/wiretapping? In other words, if the MGC instructs the MG to use the network, shouldn't the MG comply? DaveS. Brian.Rosen@marconi.com Sent by: owner-megaco@pit.comms.marconi.com 06/22/2001 11:59 AM To: Sean.Leahy@marconi.com cc: megaco@fore.com Subject: RE: Ephemeral Termination Okay, so the problem you postulate is that there are TWO instances of an MGC handling the two sides of the connection and thus you don't know that the same MG is being used. I'll leave the issue of how the two MGCs share the resources of the MG to another discussion; let's suppose for the moment that two virtual MGs are assigned one each to the two MGC instances -- is that close?? Now, in theory, anyway, no-one figure out that it's the same MG. In that case, your MG better be able to send packets to itself. Then, backing up a little, it's the MG that figures it out, in which case it has two contexts, each with two terminations, and it knows that in fact the two ephemerals are "connected" via the net. It can, in theory anyway, fake the network connection and "do the right thing". In this case, as far as the MGCs know, it IS going across the network; the MG is just optimizing the network path! Now we step back to your position, which is that, somehow, the two MGC instances discover this, and you want to know how they should handle that. Is that right? Well, I must be dense or something, because I would say that the MGCs never Add the ephemeral until they know what the other end is, and then they add it with all the right characteristics. If the originating MGC instance communicates with the terminating MGC instance and discovers that both ends are in the same MG, in my postulated Virtual MG scenario they CAN'T actually do the really right thing, which is to create one context with both physical terminations, because there is no way for either of the two MGCs to access the other physical termination, and one MGC can't use the other MGC's ContextId. So, you HAVE to let the MG do it, if at all. So, if the real bottom line question you are asking is if I have a circumstance where the physical MG is presented with a circumstance where it has two, 2 termination contexts, where the ephemerals are cross connected, can it optimize that to make a hairpin without telling the MGCs what is happening, I'd say yes, but it has to do all of the right thing. This would include, for example, supplying some appropriate statistics for the ephemerals! If you are asking if I ever see a circumstance where it makes sense to have a 3 termination context with two physicals and an ephemeral, where the ephemeral isn't actually "active" (doesn't have a remote), then I would say, no I don't see how that ever makes sense. Would it work? That is, should an MG actually allow it? I don't know; it's really an error (incomplete characterization of the ephemeral), but that is allowed at least transiently. I could see some timeout, but that would not be a "standards based" thing. So, I expect in most cases it actually would work. YMMV. Brian -----Original Message----- From: Leahy, Sean Sent: Friday, June 22, 2001 11:25 AM To: Rosen, Brian Cc: megaco@fore.com Subject: RE: Ephemeral Termination Brian, Briefly, the scenario that I was postulating was that the Call Control at the MGC (or above the MGC - depending on how you define an 'MGC' realisation) is separate from the bearer control at the MGC. Thus the MGC bearer signalling is independent enough from the call control/digit analysis that it does not allow the H.248 functionality to be told directly that the two physical terminations are on the same MG when it is first invoked (for the connection to termination A) from the call control function. The MGC might work this out when it is invoked for the connection to termination B, but there may be a problem if there are two separate instances of the same MGC handling each side of the connection. Thus the question remains - Is there any possibility for a Media Gateway to optimise such a hair-pin connection whilst maintaining the same model to the MGC ? Obviously, the alternative is to change both the call control and bearer control layers to be able to harmonise better to deal with hairpin connections. But it would be interesting to know if you think optimisation at the MG is a possibility that might mean this could be avoided, if it were so desired. Regards, Sean Leahy From: Brian Rosen/MAIN/MC1@MSEXCH on 22/06/2001 13:39 To: Sean Leahy/MAIN/MC1@MCMAIN cc: megaco@fore.com Subject: RE: Ephemeral Termination I'm having trouble following your question. The example we are discussing, trunk gateways, has digit analysis and call control done completely in the MGC; the MG has no role at all in these matters. The fact that digit analysis takes some time in the MGC is, I believe, the reasons being advanced for starting with the originating MG and doing everything you can in advance of determining the terminating MG. If the design of the MGC is such that it gets all the information at once (both ends), it can send out the optimal 2 transaction/4 command sequence. The issue is that you gain nothing by anticipating that you might need an ephemeral. Whether it turns out that you do (originating MG not equal terminating MG) or you don't (hairpin), putting the ephemeral in the context before you know doesn't help anything. It may or may not "work" in all MGs, but I don't see any reason to do it. Maybe I'm missing something. Brian -----Original Message----- From: Leahy, Sean Sent: Friday, June 22, 2001 4:09 AM To: Rosen, Brian Cc: megaco@fore.com Subject: RE: Ephemeral Termination Brian, Just a question. There may be cases where Megaco is being used solely for bearer control and the call control/digit analysis is conducted at a layer above the Megaco protocol. In these circumstances, it is also possible that ephemerals are added and modified by command from the MGC when the bearer connection is actually between two physical terminations on the same Media Gateway. Is it altogether impossible for a Media Gateway to optimise such a hair-pin connection whilst maintaining the same model to the MGC ? Sean Leahy Marconi << OLE Object: Picture (Device Independent Bitmap) >> CN=Brian Rosen/OU=MAIN/O=MC1@MSEXCH on 21/06/2001 15:56:23 |----------------------------------------------------------------------------------------------------------------------------------------------------| | | | | | | |----------------------------------------------------------------------------------------------------------------------------------------------------| |------------+-------------------------------------------------------------------------| | | | | | | | | | |------------+-------------------------------------------------------------------------| | | | | To: | "'PSK Chakravarthi'" , "'Madhu Babu | | | Brahmanapally'" , "'Terry L Anderson'" | | | | | | | |------------+-------------------------------------------------------------------------| | | | | cc: | megaco@fore.com(bcc: Sean Leahy/MAIN/MC1) | | | | |------------+-------------------------------------------------------------------------| | | | | | | | | | |------------+-------------------------------------------------------------------------| | | | | Subject: | RE: Ephemeral Termination | | | | |------------+-------------------------------------------------------------------------| << OLE Object: Picture (Device Independent Bitmap) >> I'm having trouble following your logic. This seems to be a trunk GW/ISUP issue, so we don't have to deal with off hook/DTMF issues, right? In the case of hairpin, you need two commands: 1) An add to put the originating termination in the context 2) An add to put the terminating termination in the context. They cannot be in the same transaction if you have not completed digit analysis before you do 1. In the case of a normal connection between two MGs you need 4 total commands: 1) The Add of the physical in the originating MG 2) The Add of the ephemeral in the originating MG 3) The Add of the physical in the terminating MG 4) The Add of the ephemeral in the terminating MG You can do 1 before you do digit analysis. You have to do 3 and 4 after digit analysis, but they can be in the same transaction. If you do 2 before you do digit analysis, you would not have the correct remote SDP, and therefore you would need to send a Modify after digit analysis. If you do it after you do digit analysis, then you only have the 4 commands. Before digit analysis, the MGC sends 1. After digit analysis the MGC sends two transactions in two messages; one to the originating MG (message 2 containing correct local and remote SDP) and one to the terminating MG (with messages 3 and 4 including all the SDP). In most cases, I suspect it would actually be more efficient to send message 1 after digit analysis, because then the originating MG has one less transaction to process, but the same number of commands. The call setup difference between the originating MG doing one add before digit analysis and another after vs doing both after won't matter enough to be measurable I think, but the difference in processing of half the number of messages will be substantial. I see no way to have the Add of the ephemeral before digit analysis improve call setup time. It seems to only create extra work for the originating MG. Brian > -----Original Message----- > From: PSK Chakravarthi [mailto:chak@axes-mach01.usa.alcatel.com] > Sent: Thursday, June 21, 2001 10:10 AM > To: Rosen, Brian; 'Madhu Babu Brahmanapally'; 'Terry L Anderson' > Cc: megaco@fore.com > Subject: Re: Ephemeral Termination > > > The reason for creating Ephemeral and reserving SDP before knowing the > termination is to reduce the call setup time. > > Following is the MGC processing. > > 1. Soon after receiving IAM send ADD command to the originating MG for > a)Creating Ephemeral > b)Reserving SDP for Local > c)Simultaneously start digit analysis > After finding termination > (By this time ADD response would have been received, if not > MGC need to wait for > ADD response) > If terminating trunk belongs to the same MG > a) send ADD command to add the second termination to the > same context. > This ADD command will have empty Local descriptor to > release resources > previously allocated. > Note that ephemeral is not SUBTRACTED. Also MODIFY to > originating MG is > not required as MG is going to make only hairpin connection. > If the terminating MG is not same as originating MG > Send ADD command to terminating MG > a) Creating Ephemeral > b) Reserving SDP for Local > c) Setting SDP remote as Local returned by the originating MG. > After receiving the ADD response from terminating MG > Send MODIFY to originating MG for setting remote Descriptor. > > If you send ADD command to the originating MG only after > knowing the terminator, > MGC had completed processing of the call but now it need to > wait for sending > three commands > (ADD to originating MG, ADD to terminating MG and MODIFY to > originating MG) and > their responses. > > Take the case of trunking gateway, where the number of calls > originating on a MG > and terminating on the same MG are much less than calls originated and > terminated on two different MGs. > > thanks & regards > Chak > > ----- Original Message ----- > From: "Rosen, Brian" > To: "'PSK Chakravarthi'" ; > "'Madhu Babu > Brahmanapally'" ; "'Terry L Anderson'" > > Cc: > Sent: Thursday, June 21, 2001 7:21 PM > Subject: RE: Ephemeral Termination > > > > There is no way this will reduce call setup time. > > Since you do not have the destination information, you > > will have to MODIFY the ephemeral when you do. The processing > > time for the Modify won't be substantially more than doing > > an Add at that point, and there is no difference to the actual > > operation of the gateway. > > > > Brian > > > > > -----Original Message----- > > > From: PSK Chakravarthi [mailto:chak@axes-mach01.usa.alcatel.com] > > > Sent: Thursday, June 21, 2001 1:43 AM > > > To: Rosen, Brian; 'Madhu Babu Brahmanapally'; 'Terry L Anderson' > > > Cc: megaco@fore.com > > > Subject: Re: Ephemeral Termination > > > > > > > > > The reason for creating Ephemeral and reserving SDP > before knowing the > > > termination is > > > to reduce the call setup time. > > > > > > thanks & regards > > > Chak > > > ----- Original Message ----- > > > From: "Rosen, Brian" > > > To: "'Madhu Babu Brahmanapally'" ; > > > "'Terry L Anderson'" > > > ; "'PSK Chakravarthi'" > > > > > > Cc: > > > Sent: Wednesday, June 20, 2001 9:07 PM > > > Subject: RE: Ephemeral Termination > > > > > > > > > > I'm not at all sure what "resources" you can reserve before you > > > > know the destination: > > > > > > > > For an IP network, you can reserve a UDP port I > suppose, but until > > > > you negotiate the SDP, you can't reserve bandwidth. You can't > > > > make any QoS reservation for the same reason. > > > > > > > > It's worse on an ATM network. > > > > > > > > I think there is nothing to be gained by #1 > > > > > > > > Brian > > > > > > > > > -----Original Message----- > > > > > From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com] > > > > > Sent: Wednesday, June 20, 2001 11:28 AM > > > > > To: 'Terry L Anderson'; 'PSK Chakravarthi' > > > > > Cc: megaco@fore.com > > > > > Subject: RE: Ephemeral Termination > > > > > > > > > > > > > > > Hi All, > > > > > The creation of ephemeral termination can be done either > > > after digit > > > > > analysis or before it. Each has its own advantages and > > > disadvantages. > > > > > > > > > > 1) If Ephemeral termination is created before digit analysis, > > > > > situation may > > > > > occur where the destination user/termination is connected to > > > > > the same MG and > > > > > there is no need to create an ephemeral termination (as PSK > > > > > mentioned). But > > > > > this has the advantage that the call wont be dropped due > > > to lack of > > > > > resource, as ephemeral resources are pre-reserved at the MG. > > > > > (in case Add > > > > > fails later to add ephemeral termination). > > > > > > > > > > 2) If Ephemeral termination is created after digit analysis, > > > > > it takes care > > > > > of all situation where destination user may/may not connected > > > > > to the same > > > > > MG. But when Ephemeral termination is added later, there is no > > > > > pre-reservation of the ephemeral resources at the > origination MG. > > > > > > > > > > In case of 1) if the call doesn't mature, reserving the > > > > > resources doesn't > > > > > gain anything. Consideration that the destination user on the > > > > > same MG is > > > > > less probable, Method 2 IMO will be a better choice. > > > > > > > > > > Regards > > > > > Madhubabu > > > > > > > > > > -----Original Message----- > > > > > From: owner-megaco@pit.comms.marconi.com > > > > > [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Terry > > > > > L Anderson > > > > > Sent: Wednesday, June 20, 2001 11:01 AM > > > > > To: PSK Chakravarthi > > > > > Cc: megaco@fore.com > > > > > Subject: Re: Ephemeral Termination > > > > > > > > > > > > > > > > > > > > > > > > > PSK Chakravarthi wrote: > > > > > > > > > > > I have got the following doubt. > > > > > > If the originating and terminating termination IDs are on > > > > > the same gateway > > > > > and > > > > > > gateway supports two TDM terminations in a context, is it > > > > > required to > > > > > craete a > > > > > > ephenmeral termination for this call? > > > > > > > > > > > > Message flow between MGC and MG: > > > > > > > > > > > > 1. MGC send ADD command to originating MG > > > > > > a) Choose a context ID > > > > > > b) Add a TDM termination > > > > > > c) Choose a Ephemeral termination > > > > > > d) Reserve Local Descriptor > > > > > > e) set MODE to Receive only. > > > > > > > > > > > > 2. MGC now finds that call is terminating on the same MG. > > > > > Also MGC knows > > > > > that > > > > > > MG is capable of adding two TDMs to the same context. At > > > > > this point what > > > > > should > > > > > > be the command to the MG? > > > > > > Is it required to SUBTRACT the ephemeral termination and > > > > > send ADD for > > > > > adding new > > > > > > TDM to the same context? or > > > > > > Simply sending ADD for new TDM to the same context is > > > sufficient? > > > > > > > > > > It would be better if MGC "finds" that the call is terminated > > > > > on the same MG > > > > > before > > > > > sending the ADD, in step 1c, but if since step c (which you > > > > > call "Choose a > > > > > Ephemeral > > > > > termination) is an Add with wildcard, MGC must certainly > > > > > Subtract it if it > > > > > chooses > > > > > later not to use it. The Subtract deletes the ephemeral > > > > > termination and > > > > > releases > > > > > its resources. > > > > > > > > > > > thanks & regards > > > > > > Chak > > > > > > > > > > -- > > > > > ------------------------------------------------------------ > > > > > Terry L Anderson mailto:tla@lucent.com > > > > > Tel:908.582.7013 Fax:908.582.6729 > > > > > Lucent Technologies/INS/Voice Over IP Access Networks > > > > > Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 > > > > > http://its.lucent.com/~tla (Lucent internal) > > http://www.gti.net/tla > > > > > > > > > > > > > > From owner-megaco@fore.com Fri Jun 22 13:10:23 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA00629 for ; Fri, 22 Jun 2001 13:10:21 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA04364; Fri, 22 Jun 2001 13:01:16 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id MAA00944 for megaco-list; Fri, 22 Jun 2001 12:58:38 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA00924; Fri, 22 Jun 2001 12:58:28 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Fri, 22 Jun 2001 12:58:25 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF044655E2@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Dave.Sclarsky@radisys.com'" Cc: megaco@fore.com, owner-megaco@pit.comms.marconi.com, "Leahy, Sean" Subject: RE: Ephemeral Termination Date: Fri, 22 Jun 2001 12:58:22 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Could be. That is a system design issue. I suspect that in that case you need to force packets to flow upstream. In some operating systems, a packet sent to yourself doesn't get on the net. Might need to force the flow to always go through the access router. There are a couple of ways to do that. Brian > -----Original Message----- > From: Dave.Sclarsky@radisys.com [mailto:Dave.Sclarsky@radisys.com] > Sent: Friday, June 22, 2001 12:42 PM > To: Brian.Rosen@marconi.com > Cc: megaco@fore.com; owner-megaco@pit.comms.marconi.com; > Sean.Leahy@marconi.com > Subject: RE: Ephemeral Termination > > > Does an MG that 'discovers' that it has 2 ephemerals that are > "connected" > via the net and bypasses the network connection pose a > problem related to > CALEA/wiretapping? In other words, if the MGC instructs the > MG to use the > network, shouldn't the MG comply? > > DaveS. > > > > > > Brian.Rosen@marconi.com > Sent by: owner-megaco@pit.comms.marconi.com > 06/22/2001 11:59 AM > > > To: Sean.Leahy@marconi.com > cc: megaco@fore.com > Subject: RE: Ephemeral Termination > > > Okay, so the problem you postulate is that there are TWO > instances of an > MGC > handling the two sides of the connection and thus you don't > know that the > same MG > is being used. > > I'll leave the issue of how the two MGCs share the resources > of the MG to > another discussion; > let's suppose for the moment that two virtual MGs are > assigned one each to > the two > MGC instances -- is that close?? > > Now, in theory, anyway, no-one figure out that it's the same > MG. In that > case, > your MG better be able to send packets to itself. Then, backing up a > little, it's the MG > that figures it out, in which case it has two contexts, each with two > terminations, and it > knows that in fact the two ephemerals are "connected" via the > net. It > can, > in theory anyway, > fake the network connection and "do the right thing". In > this case, as > far > as the MGCs > know, it IS going across the network; the MG is just optimizing the > network > path! > > Now we step back to your position, which is that, somehow, the two MGC > instances > discover this, and you want to know how they should handle > that. Is that > right? > > Well, I must be dense or something, because I would say that the MGCs > never > Add the ephemeral until they know what the other end is, and > then they add > it with > all the right characteristics. If the originating MGC instance > communicates with the > terminating MGC instance and discovers that both ends are in > the same MG, > in my > postulated Virtual MG scenario they CAN'T actually do the really right > thing, which is > to create one context with both physical terminations, > because there is no > way for > either of the two MGCs to access the other physical > termination, and one > MGC can't > use the other MGC's ContextId. So, you HAVE to let the MG do > it, if at > all. > > So, if the real bottom line question you are asking is if I have a > circumstance where > the physical MG is presented with a circumstance where it has two, 2 > termination > contexts, where the ephemerals are cross connected, can it > optimize that > to > make a > hairpin without telling the MGCs what is happening, I'd say > yes, but it > has > to do > all of the right thing. This would include, for example, > supplying some > appropriate > statistics for the ephemerals! > > If you are asking if I ever see a circumstance where it makes > sense to > have > a > 3 termination context with two physicals and an ephemeral, where the > ephemeral > isn't actually "active" (doesn't have a remote), then I would > say, no I > don't see how that > ever makes sense. Would it work? That is, should an MG > actually allow > it? > I don't know; > it's really an error (incomplete characterization of the > ephemeral), but > that is allowed > at least transiently. I could see some timeout, but that > would not be a > "standards based" > thing. So, I expect in most cases it actually would work. YMMV. > > Brian > > -----Original Message----- > From: Leahy, Sean > Sent: Friday, June 22, 2001 11:25 AM > To: Rosen, Brian > Cc: megaco@fore.com > Subject: RE: Ephemeral Termination > > Brian, > Briefly, the scenario that I was postulating was > that the Call > Control at the MGC (or above the > MGC - depending on how you define an 'MGC' realisation) > is separate > from the bearer control at the MGC. Thus > the MGC bearer signalling is independent enough from the call > control/digit analysis that it does not > allow the H.248 functionality to be told directly that the two > physical terminations are on the same MG > when it is first invoked (for the connection to > termination A) from > the call control function. > The MGC might work this out when it is invoked for the > connection > to termination B, but there may > be a problem if there are two separate instances of the same MGC > handling each side of the connection. > Thus the question remains - Is there any > possibility for a Media > Gateway to optimise such a hair-pin > connection whilst maintaining the same model to the MGC ? > Obviously, the alternative is to change both the > call control > and > bearer control layers to be able to harmonise > better to deal with hairpin connections. But it would be > interesting > to know if you think optimisation at the MG is a possibility > that might mean this could be avoided, if it were so desired. > > Regards, > Sean Leahy > > > > From: Brian Rosen/MAIN/MC1@MSEXCH on 22/06/2001 13:39 > > To: Sean Leahy/MAIN/MC1@MCMAIN > cc: megaco@fore.com > > Subject: RE: Ephemeral Termination > > I'm having trouble following your question. > > The example we are discussing, trunk gateways, has digit > analysis and > call control done > completely in the MGC; the MG has no role at all in > these matters. > The fact that digit > analysis takes some time in the MGC is, I believe, the > reasons being > advanced for > starting with the originating MG and doing everything you can in > advance of determining > the terminating MG. If the design of the MGC is such > that it gets > all > the information at > once (both ends), it can send out the optimal 2 > transaction/4 command > sequence. > > The issue is that you gain nothing by anticipating that > you might > need > an ephemeral. > Whether it turns out that you do (originating MG not equal > terminating > MG) or you don't > (hairpin), putting the ephemeral in the context before you know > doesn't help anything. > > It may or may not "work" in all MGs, but I don't see any > reason to do > it. > > Maybe I'm missing something. > > Brian > > -----Original Message----- > From: Leahy, Sean > Sent: Friday, June 22, 2001 4:09 AM > To: Rosen, Brian > Cc: megaco@fore.com > Subject: RE: Ephemeral Termination > > Brian, > Just a question. > > There may be cases where Megaco is being used > solely for > bearer control and the call control/digit analysis > is conducted > at a layer above the Megaco protocol. In these > circumstances, it > is also possible that ephemerals are added and modified by > command from the MGC when the bearer connection is actually > between two physical terminations on the same Media > Gateway. Is > it altogether impossible for a Media Gateway to > optimise such a > hair-pin connection whilst maintaining the same > model to the MGC > ? > > Sean Leahy > Marconi > > > > > > > << OLE Object: Picture (Device Independent Bitmap) >> > CN=Brian Rosen/OU=MAIN/O=MC1@MSEXCH on 21/06/2001 15:56:23 > > |------------------------------------------------------------- > -------------------------------------------------------------- > -------------------------| > | | > | | > | | > |------------------------------------------------------------- > -------------------------------------------------------------- > -------------------------| > > > > > > |------------+------------------------------------------------ > -------------------------| > | | | > | | | > | | | > > |------------+------------------------------------------------ > -------------------------| > | | | > | To: | "'PSK Chakravarthi'" > , > "'Madhu Babu | > | | Brahmanapally'" , "'Terry L > Anderson'" | > | | | > | | | > > |------------+------------------------------------------------ > -------------------------| > | | | > | cc: | megaco@fore.com(bcc: Sean Leahy/MAIN/MC1) | > | | | > > |------------+------------------------------------------------ > -------------------------| > | | | > | | | > | | | > > |------------+------------------------------------------------ > -------------------------| > | | | > | Subject: | RE: Ephemeral Termination | > | | | > > |------------+------------------------------------------------ > -------------------------| > > > > > > > > << OLE Object: Picture (Device Independent Bitmap) >> > I'm having trouble following your logic. > > This seems to be a trunk GW/ISUP issue, so we don't have to > deal with off hook/DTMF issues, right? > > In the case of hairpin, you need two commands: > 1) An add to put the originating termination in the context > 2) An add to put the terminating termination in the context. > They cannot be in the same transaction if you have > not completed > digit analysis before you do 1. > > In the case of a normal connection between two MGs you need > 4 total commands: > 1) The Add of the physical in the originating MG > 2) The Add of the ephemeral in the originating MG > 3) The Add of the physical in the terminating MG > 4) The Add of the ephemeral in the terminating MG > > You can do 1 before you do digit analysis. You have to > do 3 and 4 after digit analysis, but they can be in the > same transaction. If you do 2 before you do digit analysis, > you would not have the correct remote SDP, and therefore you > would > need to send a Modify after digit analysis. If you do it > after you do digit analysis, then you only have the 4 > commands. Before digit analysis, the MGC sends 1. > After digit analysis the MGC sends two transactions > in two messages; one to the originating MG (message > 2 containing > correct local and remote SDP) and one to the terminating MG > (with messages 3 and 4 including all the SDP). > > In most cases, I suspect it would actually be more > efficient to > send message 1 after digit analysis, because then the > originating > MG has one less transaction to process, but the > same number of > commands. The call setup difference between the > originating MG > doing one add before digit analysis and another > after vs doing > both after won't matter enough to be measurable I > think, but the > difference in processing of half the number of > messages will be > substantial. > > I see no way to have the Add of the ephemeral before > digit analysis improve call setup time. It seems > to only create > extra work for the originating MG. > > Brian > > > -----Original Message----- > > From: PSK Chakravarthi > [mailto:chak@axes-mach01.usa.alcatel.com] > > Sent: Thursday, June 21, 2001 10:10 AM > > To: Rosen, Brian; 'Madhu Babu Brahmanapally'; 'Terry L > Anderson' > > Cc: megaco@fore.com > > Subject: Re: Ephemeral Termination > > > > > > The reason for creating Ephemeral and reserving SDP before > knowing the > > termination is to reduce the call setup time. > > > > Following is the MGC processing. > > > > 1. Soon after receiving IAM send ADD command to the > originating > MG for > > a)Creating Ephemeral > > b)Reserving SDP for Local > > c)Simultaneously start digit analysis > > After finding termination > > (By this time ADD response would have been > received, if not > > MGC need to wait for > > ADD response) > > If terminating trunk belongs to the same MG > > a) send ADD command to add the second > termination to the > > same context. > > This ADD command will have empty Local > descriptor to > > release resources > > previously allocated. > > Note that ephemeral is not SUBTRACTED. > Also MODIFY to > > originating MG is > > not required as MG is going to make only hairpin > connection. > > If the terminating MG is not same as originating MG > > Send ADD command to terminating MG > > a) Creating Ephemeral > > b) Reserving SDP for Local > > c) Setting SDP remote as Local returned by the > originating > MG. > > After receiving the ADD response from terminating MG > > Send MODIFY to originating MG for setting remote > Descriptor. > > > > If you send ADD command to the originating MG only after > > knowing the terminator, > > MGC had completed processing of the call but now > it need to > > wait for sending > > three commands > > (ADD to originating MG, ADD to terminating MG and > MODIFY to > > originating MG) and > > their responses. > > > > Take the case of trunking gateway, where the > number of calls > > originating on a MG > > and terminating on the same MG are much less than calls > originated and > > terminated on two different MGs. > > > > thanks & regards > > Chak > > > > ----- Original Message ----- > > From: "Rosen, Brian" > > To: "'PSK Chakravarthi'" > ; > > "'Madhu Babu > > Brahmanapally'" ; "'Terry > L Anderson'" > > > > Cc: > > Sent: Thursday, June 21, 2001 7:21 PM > > Subject: RE: Ephemeral Termination > > > > > > > There is no way this will reduce call setup time. > > > Since you do not have the destination information, you > > > will have to MODIFY the ephemeral when you do. The > processing > > > time for the Modify won't be substantially more > than doing > > > an Add at that point, and there is no difference to the > actual > > > operation of the gateway. > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: PSK Chakravarthi > [mailto:chak@axes-mach01.usa.alcatel.com] > > > > Sent: Thursday, June 21, 2001 1:43 AM > > > > To: Rosen, Brian; 'Madhu Babu Brahmanapally'; 'Terry L > Anderson' > > > > Cc: megaco@fore.com > > > > Subject: Re: Ephemeral Termination > > > > > > > > > > > > The reason for creating Ephemeral and reserving SDP > > before knowing the > > > > termination is > > > > to reduce the call setup time. > > > > > > > > thanks & regards > > > > Chak > > > > ----- Original Message ----- > > > > From: "Rosen, Brian" > > > > To: "'Madhu Babu Brahmanapally'" > ; > > > > "'Terry L Anderson'" > > > > ; "'PSK Chakravarthi'" > > > > > > > > Cc: > > > > Sent: Wednesday, June 20, 2001 9:07 PM > > > > Subject: RE: Ephemeral Termination > > > > > > > > > > > > > I'm not at all sure what "resources" you can reserve > before you > > > > > know the destination: > > > > > > > > > > For an IP network, you can reserve a UDP port I > > suppose, but until > > > > > you negotiate the SDP, you can't reserve > bandwidth. You > can't > > > > > make any QoS reservation for the same reason. > > > > > > > > > > It's worse on an ATM network. > > > > > > > > > > I think there is nothing to be gained by #1 > > > > > > > > > > Brian > > > > > > > > > > > -----Original Message----- > > > > > > From: Madhu Babu Brahmanapally > [mailto:madhubabu@kenetec.com] > > > > > > Sent: Wednesday, June 20, 2001 11:28 AM > > > > > > To: 'Terry L Anderson'; 'PSK Chakravarthi' > > > > > > Cc: megaco@fore.com > > > > > > Subject: RE: Ephemeral Termination > > > > > > > > > > > > > > > > > > Hi All, > > > > > > The creation of ephemeral termination can be done > either > > > > after digit > > > > > > analysis or before it. Each has its own > advantages and > > > > disadvantages. > > > > > > > > > > > > 1) If Ephemeral termination is created > before digit > analysis, > > > > > > situation may > > > > > > occur where the destination user/termination is > connected to > > > > > > the same MG and > > > > > > there is no need to create an ephemeral > termination > (as > PSK > > > > > > mentioned). But > > > > > > this has the advantage that the call wont > be dropped > due > > > > to lack of > > > > > > resource, as ephemeral resources are > pre-reserved at > the MG. > > > > > > (in case Add > > > > > > fails later to add ephemeral termination). > > > > > > > > > > > > 2) If Ephemeral termination is created after digit > analysis, > > > > > > it takes care > > > > > > of all situation where destination user > may/may not > connected > > > > > > to the same > > > > > > MG. But when Ephemeral termination is added later, > there is no > > > > > > pre-reservation of the ephemeral resources at the > > origination MG. > > > > > > > > > > > > In case of 1) if the call doesn't mature, > reserving > the > > > > > > resources doesn't > > > > > > gain anything. Consideration that the > destination user > on the > > > > > > same MG is > > > > > > less probable, Method 2 IMO will be a > better choice. > > > > > > > > > > > > Regards > > > > > > Madhubabu > > > > > > > > > > > > -----Original Message----- > > > > > > From: owner-megaco@pit.comms.marconi.com > > > > > > > [mailto:owner-megaco@pit.comms.marconi.com]On Behalf > Of > Terry > > > > > > L Anderson > > > > > > Sent: Wednesday, June 20, 2001 11:01 AM > > > > > > To: PSK Chakravarthi > > > > > > Cc: megaco@fore.com > > > > > > Subject: Re: Ephemeral Termination > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > PSK Chakravarthi wrote: > > > > > > > > > > > > > I have got the following doubt. > > > > > > > If the originating and terminating > termination IDs > are on > > > > > > the same gateway > > > > > > and > > > > > > > gateway supports two TDM terminations > in a context, > is it > > > > > > required to > > > > > > craete a > > > > > > > ephenmeral termination for this call? > > > > > > > > > > > > > > Message flow between MGC and MG: > > > > > > > > > > > > > > 1. MGC send ADD command to originating MG > > > > > > > a) Choose a context ID > > > > > > > b) Add a TDM termination > > > > > > > c) Choose a Ephemeral termination > > > > > > > d) Reserve Local Descriptor > > > > > > > e) set MODE to Receive only. > > > > > > > > > > > > > > 2. MGC now finds that call is > terminating on the > same > MG. > > > > > > Also MGC knows > > > > > > that > > > > > > > MG is capable of adding two TDMs to the same > context. > At > > > > > > this point what > > > > > > should > > > > > > > be the command to the MG? > > > > > > > Is it required to SUBTRACT the > ephemeral termination > and > > > > > > send ADD for > > > > > > adding new > > > > > > > TDM to the same context? or > > > > > > > Simply sending ADD for new TDM to the > same context > is > > > > sufficient? > > > > > > > > > > > > It would be better if MGC "finds" that the call is > terminated > > > > > > on the same MG > > > > > > before > > > > > > sending the ADD, in step 1c, but if since step c > (which > you > > > > > > call "Choose a > > > > > > Ephemeral > > > > > > termination) is an Add with wildcard, MGC must > certainly > > > > > > Subtract it if it > > > > > > chooses > > > > > > later not to use it. The Subtract deletes the > ephemeral > > > > > > termination and > > > > > > releases > > > > > > its resources. > > > > > > > > > > > > > thanks & regards > > > > > > > Chak > > > > > > > > > > > > -- > > > > > > > ------------------------------------------------------------ > > > > > > Terry L Anderson > mailto:tla@lucent.com > > > > > > Tel:908.582.7013 Fax:908.582.6729 > > > > > > Lucent Technologies/INS/Voice Over IP > Access Networks > > > > > > Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 > > > > > > http://its.lucent.com/~tla (Lucent internal) > > > http://www.gti.net/tla > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From owner-megaco@fore.com Fri Jun 22 14:53:01 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA04675 for ; Fri, 22 Jun 2001 14:53:01 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA11832; Fri, 22 Jun 2001 14:44:06 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id OAA24982 for megaco-list; Fri, 22 Jun 2001 14:40:59 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA24975 for ; Fri, 22 Jun 2001 14:40:57 -0400 (EDT) From: Dave.Sclarsky@radisys.com Received: from radisys.com (mail-gw.radisys.com [206.102.10.35]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA11518 for ; Fri, 22 Jun 2001 14:40:50 -0400 (EDT) Received: (25452 bytes) by radisys.com via sendmail with P:stdio/R:inet_hosts/T:smtp (sender: ) id for megaco@fore.com; Fri, 22 Jun 2001 11:40:51 -0700 (PDT) (Smail-3.2.0.105 1999-Mar-3 #2 built 1999-Apr-18) Received: from notes.radisys.com(206.103.52.220) via SMTP by mail-gw.radisys.com, id smtpdAAAkQaqrw; Fri Jun 22 11:40:33 2001 To: "Rosen, Brian" , megaco@fore.com Subject: RE: Ephemeral Termination MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Fri, 22 Jun 2001 14:38:08 -0400 X-MIMETrack: Serialize by Router on HQ_ACS_1/Radisys_Corporation/US(Release 5.0.6a |January 17, 2001) at 06/22/2001 11:40:17 AM, Serialize complete at 06/22/2001 11:40:17 AM Content-Type: text/plain; charset="us-ascii" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Oops, I was only thinking of ATM, where the MG was asked to make a hairpin SVC. I don't think anything other than intelligence in the MG would prevent cells from going out on the wire in that case! DaveS. "Rosen, Brian" Sent by: owner-megaco@pit.comms.marconi.com 06/22/2001 12:58 PM To: "'Dave.Sclarsky@radisys.com'" cc: megaco@fore.com, owner-megaco@pit.comms.marconi.com, "Leahy, Sean" Subject: RE: Ephemeral Termination Could be. That is a system design issue. I suspect that in that case you need to force packets to flow upstream. In some operating systems, a packet sent to yourself doesn't get on the net. Might need to force the flow to always go through the access router. There are a couple of ways to do that. Brian > -----Original Message----- > From: Dave.Sclarsky@radisys.com [mailto:Dave.Sclarsky@radisys.com] > Sent: Friday, June 22, 2001 12:42 PM > To: Brian.Rosen@marconi.com > Cc: megaco@fore.com; owner-megaco@pit.comms.marconi.com; > Sean.Leahy@marconi.com > Subject: RE: Ephemeral Termination > > > Does an MG that 'discovers' that it has 2 ephemerals that are > "connected" > via the net and bypasses the network connection pose a > problem related to > CALEA/wiretapping? In other words, if the MGC instructs the > MG to use the > network, shouldn't the MG comply? > > DaveS. > > > > > > Brian.Rosen@marconi.com > Sent by: owner-megaco@pit.comms.marconi.com > 06/22/2001 11:59 AM > > > To: Sean.Leahy@marconi.com > cc: megaco@fore.com > Subject: RE: Ephemeral Termination > > > Okay, so the problem you postulate is that there are TWO > instances of an > MGC > handling the two sides of the connection and thus you don't > know that the > same MG > is being used. > > I'll leave the issue of how the two MGCs share the resources > of the MG to > another discussion; > let's suppose for the moment that two virtual MGs are > assigned one each to > the two > MGC instances -- is that close?? > > Now, in theory, anyway, no-one figure out that it's the same > MG. In that > case, > your MG better be able to send packets to itself. Then, backing up a > little, it's the MG > that figures it out, in which case it has two contexts, each with two > terminations, and it > knows that in fact the two ephemerals are "connected" via the > net. It > can, > in theory anyway, > fake the network connection and "do the right thing". In > this case, as > far > as the MGCs > know, it IS going across the network; the MG is just optimizing the > network > path! > > Now we step back to your position, which is that, somehow, the two MGC > instances > discover this, and you want to know how they should handle > that. Is that > right? > > Well, I must be dense or something, because I would say that the MGCs > never > Add the ephemeral until they know what the other end is, and > then they add > it with > all the right characteristics. If the originating MGC instance > communicates with the > terminating MGC instance and discovers that both ends are in > the same MG, > in my > postulated Virtual MG scenario they CAN'T actually do the really right > thing, which is > to create one context with both physical terminations, > because there is no > way for > either of the two MGCs to access the other physical > termination, and one > MGC can't > use the other MGC's ContextId. So, you HAVE to let the MG do > it, if at > all. > > So, if the real bottom line question you are asking is if I have a > circumstance where > the physical MG is presented with a circumstance where it has two, 2 > termination > contexts, where the ephemerals are cross connected, can it > optimize that > to > make a > hairpin without telling the MGCs what is happening, I'd say > yes, but it > has > to do > all of the right thing. This would include, for example, > supplying some > appropriate > statistics for the ephemerals! > > If you are asking if I ever see a circumstance where it makes > sense to > have > a > 3 termination context with two physicals and an ephemeral, where the > ephemeral > isn't actually "active" (doesn't have a remote), then I would > say, no I > don't see how that > ever makes sense. Would it work? That is, should an MG > actually allow > it? > I don't know; > it's really an error (incomplete characterization of the > ephemeral), but > that is allowed > at least transiently. I could see some timeout, but that > would not be a > "standards based" > thing. So, I expect in most cases it actually would work. YMMV. > > Brian > > -----Original Message----- > From: Leahy, Sean > Sent: Friday, June 22, 2001 11:25 AM > To: Rosen, Brian > Cc: megaco@fore.com > Subject: RE: Ephemeral Termination > > Brian, > Briefly, the scenario that I was postulating was > that the Call > Control at the MGC (or above the > MGC - depending on how you define an 'MGC' realisation) > is separate > from the bearer control at the MGC. Thus > the MGC bearer signalling is independent enough from the call > control/digit analysis that it does not > allow the H.248 functionality to be told directly that the two > physical terminations are on the same MG > when it is first invoked (for the connection to > termination A) from > the call control function. > The MGC might work this out when it is invoked for the > connection > to termination B, but there may > be a problem if there are two separate instances of the same MGC > handling each side of the connection. > Thus the question remains - Is there any > possibility for a Media > Gateway to optimise such a hair-pin > connection whilst maintaining the same model to the MGC ? > Obviously, the alternative is to change both the > call control > and > bearer control layers to be able to harmonise > better to deal with hairpin connections. But it would be > interesting > to know if you think optimisation at the MG is a possibility > that might mean this could be avoided, if it were so desired. > > Regards, > Sean Leahy > > > > From: Brian Rosen/MAIN/MC1@MSEXCH on 22/06/2001 13:39 > > To: Sean Leahy/MAIN/MC1@MCMAIN > cc: megaco@fore.com > > Subject: RE: Ephemeral Termination > > I'm having trouble following your question. > > The example we are discussing, trunk gateways, has digit > analysis and > call control done > completely in the MGC; the MG has no role at all in > these matters. > The fact that digit > analysis takes some time in the MGC is, I believe, the > reasons being > advanced for > starting with the originating MG and doing everything you can in > advance of determining > the terminating MG. If the design of the MGC is such > that it gets > all > the information at > once (both ends), it can send out the optimal 2 > transaction/4 command > sequence. > > The issue is that you gain nothing by anticipating that > you might > need > an ephemeral. > Whether it turns out that you do (originating MG not equal > terminating > MG) or you don't > (hairpin), putting the ephemeral in the context before you know > doesn't help anything. > > It may or may not "work" in all MGs, but I don't see any > reason to do > it. > > Maybe I'm missing something. > > Brian > > -----Original Message----- > From: Leahy, Sean > Sent: Friday, June 22, 2001 4:09 AM > To: Rosen, Brian > Cc: megaco@fore.com > Subject: RE: Ephemeral Termination > > Brian, > Just a question. > > There may be cases where Megaco is being used > solely for > bearer control and the call control/digit analysis > is conducted > at a layer above the Megaco protocol. In these > circumstances, it > is also possible that ephemerals are added and modified by > command from the MGC when the bearer connection is actually > between two physical terminations on the same Media > Gateway. Is > it altogether impossible for a Media Gateway to > optimise such a > hair-pin connection whilst maintaining the same > model to the MGC > ? > > Sean Leahy > Marconi > > > > > > > << OLE Object: Picture (Device Independent Bitmap) >> > CN=Brian Rosen/OU=MAIN/O=MC1@MSEXCH on 21/06/2001 15:56:23 > > |------------------------------------------------------------- > -------------------------------------------------------------- > -------------------------| > | | > | | > | | > |------------------------------------------------------------- > -------------------------------------------------------------- > -------------------------| > > > > > > |------------+------------------------------------------------ > -------------------------| > | | | > | | | > | | | > > |------------+------------------------------------------------ > -------------------------| > | | | > | To: | "'PSK Chakravarthi'" > , > "'Madhu Babu | > | | Brahmanapally'" , "'Terry L > Anderson'" | > | | | > | | | > > |------------+------------------------------------------------ > -------------------------| > | | | > | cc: | megaco@fore.com(bcc: Sean Leahy/MAIN/MC1) | > | | | > > |------------+------------------------------------------------ > -------------------------| > | | | > | | | > | | | > > |------------+------------------------------------------------ > -------------------------| > | | | > | Subject: | RE: Ephemeral Termination | > | | | > > |------------+------------------------------------------------ > -------------------------| > > > > > > > > << OLE Object: Picture (Device Independent Bitmap) >> > I'm having trouble following your logic. > > This seems to be a trunk GW/ISUP issue, so we don't have to > deal with off hook/DTMF issues, right? > > In the case of hairpin, you need two commands: > 1) An add to put the originating termination in the context > 2) An add to put the terminating termination in the context. > They cannot be in the same transaction if you have > not completed > digit analysis before you do 1. > > In the case of a normal connection between two MGs you need > 4 total commands: > 1) The Add of the physical in the originating MG > 2) The Add of the ephemeral in the originating MG > 3) The Add of the physical in the terminating MG > 4) The Add of the ephemeral in the terminating MG > > You can do 1 before you do digit analysis. You have to > do 3 and 4 after digit analysis, but they can be in the > same transaction. If you do 2 before you do digit analysis, > you would not have the correct remote SDP, and therefore you > would > need to send a Modify after digit analysis. If you do it > after you do digit analysis, then you only have the 4 > commands. Before digit analysis, the MGC sends 1. > After digit analysis the MGC sends two transactions > in two messages; one to the originating MG (message > 2 containing > correct local and remote SDP) and one to the terminating MG > (with messages 3 and 4 including all the SDP). > > In most cases, I suspect it would actually be more > efficient to > send message 1 after digit analysis, because then the > originating > MG has one less transaction to process, but the > same number of > commands. The call setup difference between the > originating MG > doing one add before digit analysis and another > after vs doing > both after won't matter enough to be measurable I > think, but the > difference in processing of half the number of > messages will be > substantial. > > I see no way to have the Add of the ephemeral before > digit analysis improve call setup time. It seems > to only create > extra work for the originating MG. > > Brian > > > -----Original Message----- > > From: PSK Chakravarthi > [mailto:chak@axes-mach01.usa.alcatel.com] > > Sent: Thursday, June 21, 2001 10:10 AM > > To: Rosen, Brian; 'Madhu Babu Brahmanapally'; 'Terry L > Anderson' > > Cc: megaco@fore.com > > Subject: Re: Ephemeral Termination > > > > > > The reason for creating Ephemeral and reserving SDP before > knowing the > > termination is to reduce the call setup time. > > > > Following is the MGC processing. > > > > 1. Soon after receiving IAM send ADD command to the > originating > MG for > > a)Creating Ephemeral > > b)Reserving SDP for Local > > c)Simultaneously start digit analysis > > After finding termination > > (By this time ADD response would have been > received, if not > > MGC need to wait for > > ADD response) > > If terminating trunk belongs to the same MG > > a) send ADD command to add the second > termination to the > > same context. > > This ADD command will have empty Local > descriptor to > > release resources > > previously allocated. > > Note that ephemeral is not SUBTRACTED. > Also MODIFY to > > originating MG is > > not required as MG is going to make only hairpin > connection. > > If the terminating MG is not same as originating MG > > Send ADD command to terminating MG > > a) Creating Ephemeral > > b) Reserving SDP for Local > > c) Setting SDP remote as Local returned by the > originating > MG. > > After receiving the ADD response from terminating MG > > Send MODIFY to originating MG for setting remote > Descriptor. > > > > If you send ADD command to the originating MG only after > > knowing the terminator, > > MGC had completed processing of the call but now > it need to > > wait for sending > > three commands > > (ADD to originating MG, ADD to terminating MG and > MODIFY to > > originating MG) and > > their responses. > > > > Take the case of trunking gateway, where the > number of calls > > originating on a MG > > and terminating on the same MG are much less than calls > originated and > > terminated on two different MGs. > > > > thanks & regards > > Chak > > > > ----- Original Message ----- > > From: "Rosen, Brian" > > To: "'PSK Chakravarthi'" > ; > > "'Madhu Babu > > Brahmanapally'" ; "'Terry > L Anderson'" > > > > Cc: > > Sent: Thursday, June 21, 2001 7:21 PM > > Subject: RE: Ephemeral Termination > > > > > > > There is no way this will reduce call setup time. > > > Since you do not have the destination information, you > > > will have to MODIFY the ephemeral when you do. The > processing > > > time for the Modify won't be substantially more > than doing > > > an Add at that point, and there is no difference to the > actual > > > operation of the gateway. > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: PSK Chakravarthi > [mailto:chak@axes-mach01.usa.alcatel.com] > > > > Sent: Thursday, June 21, 2001 1:43 AM > > > > To: Rosen, Brian; 'Madhu Babu Brahmanapally'; 'Terry L > Anderson' > > > > Cc: megaco@fore.com > > > > Subject: Re: Ephemeral Termination > > > > > > > > > > > > The reason for creating Ephemeral and reserving SDP > > before knowing the > > > > termination is > > > > to reduce the call setup time. > > > > > > > > thanks & regards > > > > Chak > > > > ----- Original Message ----- > > > > From: "Rosen, Brian" > > > > To: "'Madhu Babu Brahmanapally'" > ; > > > > "'Terry L Anderson'" > > > > ; "'PSK Chakravarthi'" > > > > > > > > Cc: > > > > Sent: Wednesday, June 20, 2001 9:07 PM > > > > Subject: RE: Ephemeral Termination > > > > > > > > > > > > > I'm not at all sure what "resources" you can reserve > before you > > > > > know the destination: > > > > > > > > > > For an IP network, you can reserve a UDP port I > > suppose, but until > > > > > you negotiate the SDP, you can't reserve > bandwidth. You > can't > > > > > make any QoS reservation for the same reason. > > > > > > > > > > It's worse on an ATM network. > > > > > > > > > > I think there is nothing to be gained by #1 > > > > > > > > > > Brian > > > > > > > > > > > -----Original Message----- > > > > > > From: Madhu Babu Brahmanapally > [mailto:madhubabu@kenetec.com] > > > > > > Sent: Wednesday, June 20, 2001 11:28 AM > > > > > > To: 'Terry L Anderson'; 'PSK Chakravarthi' > > > > > > Cc: megaco@fore.com > > > > > > Subject: RE: Ephemeral Termination > > > > > > > > > > > > > > > > > > Hi All, > > > > > > The creation of ephemeral termination can be done > either > > > > after digit > > > > > > analysis or before it. Each has its own > advantages and > > > > disadvantages. > > > > > > > > > > > > 1) If Ephemeral termination is created > before digit > analysis, > > > > > > situation may > > > > > > occur where the destination user/termination is > connected to > > > > > > the same MG and > > > > > > there is no need to create an ephemeral > termination > (as > PSK > > > > > > mentioned). But > > > > > > this has the advantage that the call wont > be dropped > due > > > > to lack of > > > > > > resource, as ephemeral resources are > pre-reserved at > the MG. > > > > > > (in case Add > > > > > > fails later to add ephemeral termination). > > > > > > > > > > > > 2) If Ephemeral termination is created after digit > analysis, > > > > > > it takes care > > > > > > of all situation where destination user > may/may not > connected > > > > > > to the same > > > > > > MG. But when Ephemeral termination is added later, > there is no > > > > > > pre-reservation of the ephemeral resources at the > > origination MG. > > > > > > > > > > > > In case of 1) if the call doesn't mature, > reserving > the > > > > > > resources doesn't > > > > > > gain anything. Consideration that the > destination user > on the > > > > > > same MG is > > > > > > less probable, Method 2 IMO will be a > better choice. > > > > > > > > > > > > Regards > > > > > > Madhubabu > > > > > > > > > > > > -----Original Message----- > > > > > > From: owner-megaco@pit.comms.marconi.com > > > > > > > [mailto:owner-megaco@pit.comms.marconi.com]On Behalf > Of > Terry > > > > > > L Anderson > > > > > > Sent: Wednesday, June 20, 2001 11:01 AM > > > > > > To: PSK Chakravarthi > > > > > > Cc: megaco@fore.com > > > > > > Subject: Re: Ephemeral Termination > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > PSK Chakravarthi wrote: > > > > > > > > > > > > > I have got the following doubt. > > > > > > > If the originating and terminating > termination IDs > are on > > > > > > the same gateway > > > > > > and > > > > > > > gateway supports two TDM terminations > in a context, > is it > > > > > > required to > > > > > > craete a > > > > > > > ephenmeral termination for this call? > > > > > > > > > > > > > > Message flow between MGC and MG: > > > > > > > > > > > > > > 1. MGC send ADD command to originating MG > > > > > > > a) Choose a context ID > > > > > > > b) Add a TDM termination > > > > > > > c) Choose a Ephemeral termination > > > > > > > d) Reserve Local Descriptor > > > > > > > e) set MODE to Receive only. > > > > > > > > > > > > > > 2. MGC now finds that call is > terminating on the > same > MG. > > > > > > Also MGC knows > > > > > > that > > > > > > > MG is capable of adding two TDMs to the same > context. > At > > > > > > this point what > > > > > > should > > > > > > > be the command to the MG? > > > > > > > Is it required to SUBTRACT the > ephemeral termination > and > > > > > > send ADD for > > > > > > adding new > > > > > > > TDM to the same context? or > > > > > > > Simply sending ADD for new TDM to the > same context > is > > > > sufficient? > > > > > > > > > > > > It would be better if MGC "finds" that the call is > terminated > > > > > > on the same MG > > > > > > before > > > > > > sending the ADD, in step 1c, but if since step c > (which > you > > > > > > call "Choose a > > > > > > Ephemeral > > > > > > termination) is an Add with wildcard, MGC must > certainly > > > > > > Subtract it if it > > > > > > chooses > > > > > > later not to use it. The Subtract deletes the > ephemeral > > > > > > termination and > > > > > > releases > > > > > > its resources. > > > > > > > > > > > > > thanks & regards > > > > > > > Chak > > > > > > > > > > > > -- > > > > > > > ------------------------------------------------------------ > > > > > > Terry L Anderson > mailto:tla@lucent.com > > > > > > Tel:908.582.7013 Fax:908.582.6729 > > > > > > Lucent Technologies/INS/Voice Over IP > Access Networks > > > > > > Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 > > > > > > http://its.lucent.com/~tla (Lucent internal) > > > http://www.gti.net/tla > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From owner-megaco@fore.com Fri Jun 22 20:17:42 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA16610 for ; Fri, 22 Jun 2001 20:17:38 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA28581; Fri, 22 Jun 2001 20:07:54 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id UAA16208 for megaco-list; Fri, 22 Jun 2001 20:04:39 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA16204 for ; Fri, 22 Jun 2001 20:04:38 -0400 (EDT) Received: from zcars0m9.ca.nortel.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA28415 for ; Fri, 22 Jun 2001 20:04:21 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f5N046024672 for ; Fri, 22 Jun 2001 20:04:10 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Fri, 22 Jun 2001 20:04:16 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 22 Jun 2001 20:04:19 -0400 Message-ID: <28560036253BD41191A10000F8BCBD1104E916AD@zcard00g.ca.nortel.com> From: "Tom-PT Taylor" To: Kevin McCandless Cc: "'megaco'" Subject: RE: Meeting In August Date: Fri, 22 Jun 2001 20:04:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0FB78.0B412580" X-Orig: Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0FB78.0B412580 Content-Type: text/plain; charset="iso-8859-1" A charter has been under discussion with our ADs, based partly on what I published several months back. It should be final by August. -----Original Message----- From: Kevin McCandless [mailto:KMcCandless@illuminet.com] Sent: Tuesday, June 12, 2001 4:07 PM To: Taylor, Tom-PT [NORSE:B881:EXCH] Cc: 'megaco' Subject: RE: Meeting In August Tom: We are going from a closed working group to a active one again? Do we need a charter before the August meeting? -----Original Message----- From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] Sent: Monday, June 11, 2001 9:28 AM To: 'megaco' Subject: Meeting In August Megaco will meet in August. We should be thinking about open issues to cover in that meeting. I'll go out on a limb and suggest we will also have a new charter to flesh out. We should be forming a consensus on what packages we want to include as WG work items. Tom Taylor ------_=_NextPart_001_01C0FB78.0B412580 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Meeting In August

A charter has been under discussion with our ADs, = based partly on what I published several months back.  It should = be final by August.

-----Original Message-----
From: Kevin McCandless [mailto:KMcCandless@illuminet.c= om]
Sent: Tuesday, June 12, 2001 4:07 PM
To: Taylor, Tom-PT [NORSE:B881:EXCH]
Cc: 'megaco'
Subject: RE: Meeting In August


Tom:

We are going from a closed working group to a active = one again?  Do we need
a charter before the August meeting?

-----Original Message-----
From: Tom-PT Taylor [mailto:taylor@nortelnetworks.c= om]
Sent: Monday, June 11, 2001 9:28 AM
To: 'megaco'
Subject: Meeting In August


Megaco will meet in August.  We should be = thinking about open issues to
cover in that meeting.  I'll go out on a limb = and suggest we will also have
a new charter to flesh out.  We should be = forming a consensus on what
packages we want to include as WG work items.

Tom Taylor

------_=_NextPart_001_01C0FB78.0B412580-- From owner-megaco@fore.com Fri Jun 22 20:59:09 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA17238 for ; Fri, 22 Jun 2001 20:59:08 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA29615; Fri, 22 Jun 2001 20:49:25 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id UAA18451 for megaco-list; Fri, 22 Jun 2001 20:46:20 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA18446 for ; Fri, 22 Jun 2001 20:46:18 -0400 (EDT) Received: from zcars0m9.ca.nortel.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA29514 for ; Fri, 22 Jun 2001 20:46:11 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f5N0ju025335 for ; Fri, 22 Jun 2001 20:45:56 -0400 (EDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.ca.nortel.com; Fri, 22 Jun 2001 20:45:58 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 22 Jun 2001 20:46:01 -0400 Message-ID: <28560036253BD41191A10000F8BCBD110250CCBD@zcard00g.ca.nortel.com> From: "Tom-PT Taylor" To: "'megaco'" Subject: My Absence Date: Fri, 22 Jun 2001 20:46:00 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) X-Orig: Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk In case you're wondering, I'm on a camping holiday with sporadic E-mail access. Back July 10. Tom Taylor From owner-megaco@fore.com Sat Jun 23 02:36:30 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA05662 for ; Sat, 23 Jun 2001 02:36:30 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id CAA04314; Sat, 23 Jun 2001 02:26:39 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id CAA29400 for megaco-list; Sat, 23 Jun 2001 02:22:50 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id CAA29395 for ; Sat, 23 Jun 2001 02:22:44 -0400 (EDT) Received: from telesoft.indts.com ([164.164.71.52]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id CAA04189 for ; Sat, 23 Jun 2001 02:22:36 -0400 (EDT) Received: from indts_fs.indts.com (indts_fs [201.64.64.29]) by telesoft.indts.com (8.8.7/8.8.7) with ESMTP id MAA12998; Sat, 23 Jun 2001 12:10:26 +0530 Received: by INDTS_FS with Internet Mail Service (5.5.2650.21) id ; Sat, 23 Jun 2001 11:56:33 +0530 Message-ID: From: Nitin Kumar To: "'Rosen, Brian'" , "'Christian Groves'" , Terry L Anderson Cc: "'megaco@fore.com'" Subject: RE: Few clarification in RFC3015 Date: Sat, 23 Jun 2001 11:56:32 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk So, whats the final decision?? The language won't be changed in the Specification... -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] Sent: Friday, June 22, 2001 6:02 PM To: 'Christian Groves'; Terry L Anderson Cc: 'Nitin Kumar'; 'megaco@fore.com' Subject: RE: Few clarification in RFC3015 Well I thought the text was clear enough as it was, but someone got confused. While we will forever be in this state. In this case, there are three entities - transactions, actions and commands. The text talks about the order of transaction execution, and it talks about the order of command execution but is silent on the order of action execution. I thought, given that, an edit was warranted. I agree that just because someone is confused doesn't mean we have to add something to the I-G. Brian > -----Original Message----- > From: Christian Groves [mailto:Christian.Groves@ericsson.com] > Sent: Thursday, June 21, 2001 9:47 PM > To: Terry L Anderson > Cc: Rosen, Brian; 'Nitin Kumar'; 'megaco@fore.com' > Subject: Re: Few clarification in RFC3015 > > > G'Day, > > Why should we make this change if the it currently says so in > the text? > This seems to me that we're adding things just for changes > sake. Not all > questions to this list have result in a change in the IG. > > Cheers, Christian > > Terry L Anderson wrote: > > > > "Rosen, Brian" wrote: > > > > > Hmmm, maybe we should edit that text to say: > > > "Actions in a transaction and commands within an action are > > > executed sequentially in the order they appear in the > transaction." > > > > > > Terry? > > > > That is certainly the intent and the way I would read the > current text > > ("commands in order" - the fact that they are grouped into > actions doesn't > > alter their order). But your text is certainly more > explicit. I have no > > trouble with it. I'll put it in. > > > > > > > > > > > "Normal Repitition timers" are the timer values defined in D.1.3 > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: Nitin Kumar [mailto:nitin@indts.com] > > > > Sent: Wednesday, June 20, 2001 2:32 PM > > > > To: 'megaco@fore.com' > > > > Subject: Few clarification in RFC3015 > > > > > > > > > > > > Hi Folks, > > > > > > > > Just looking for following clarification. > > > > > > > > 1. In a TransactionRequest, are ActionRequests processed in > > > > order or only > > > > Commands in an ActionRequest are executed sequencially ? RFC > > > > says "Commands > > > > within a Transaction are executed sequentially." > > > > > > > > 2. Few lines from the RFC on page number 135, section D.1.4.. > > > > "Upon receipt of a final response following receipt of > > > > provisional responses, an immediate confirmation > shall be sent, and > > > > normal repetition timers shall be used thereafter." > > > > > > > > Now what does "normal repetition timers shall be used > > > > thereafter" mean in > > > > above extract? > > > > > > > > i hope to receive some insights. > > > > > > > > regards, > > > > > > > > -nitin > > > > > > > > Ind Telesoft Pvt. Ltd. > > > > 104, Koramangla Industrial Estate, > > > > 5th Block, Bangalore 560 095 > > > > Tel : 5508930, 5521937, 5529758-62 ext-259 > > > > Fax : 5521164 > > > > mailto:nitin@indts.com > > > > http:\\www.telesoftinc.com > > > > > > > > -- > > ------------------------------------------------------------ > > Terry L Anderson mailto:tla@lucent.com > > Tel:908.582.7013 Fax:908.582.6729 > > Lucent Technologies/INS/Voice Over IP Access Networks > > Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 > > http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla > > From owner-megaco@fore.com Sat Jun 23 15:35:03 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16028 for ; Sat, 23 Jun 2001 15:35:03 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA13096; Sat, 23 Jun 2001 15:24:23 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id PAA22242 for megaco-list; Sat, 23 Jun 2001 15:17:33 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA22238 for ; Sat, 23 Jun 2001 15:17:31 -0400 (EDT) Received: from telesoft.indts.com ([164.164.71.52]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA12933 for ; Sat, 23 Jun 2001 15:17:23 -0400 (EDT) Received: from indts_fs.indts.com (indts_fs [201.64.64.29]) by telesoft.indts.com (8.8.7/8.8.7) with ESMTP id BAA01201 for ; Sun, 24 Jun 2001 01:09:28 +0530 Received: by INDTS_FS with Internet Mail Service (5.5.2650.21) id ; Sun, 24 Jun 2001 00:55:33 +0530 Message-ID: From: Nitin Kumar To: "'megaco@fore.com'" Subject: mId and IPaddress of the source Date: Sun, 24 Jun 2001 00:55:33 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Hi, Spec says that response to a request must always go to source of the request. Now, we can get source identification from UDP or TCP layer as well as from mId. now, which one should be used? Is it possible to have different value in mId than actual source IPaddress? Secondly, can MGC send Auditvalue to all MGs, which are controlled by it, on coming up? or everytime when MG comes up it sends ServiceChange. regards, -nitin Ind Telesoft Pvt. Ltd. 104, Koramangla Industrial Estate, 5th Block, Bangalore 560 095 Tel : 5508930, 5521937, 5529758-62 ext-259 Fax : 5521164 mailto:nitin@indts.com http:\\www.telesoftinc.com From owner-megaco@fore.com Sun Jun 24 02:11:37 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA05527 for ; Sun, 24 Jun 2001 02:11:37 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id CAA19579; Sun, 24 Jun 2001 02:01:19 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id BAA08771 for megaco-list; Sun, 24 Jun 2001 01:56:09 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id BAA08767; Sun, 24 Jun 2001 01:56:07 -0400 (EDT) Received: from mail.szutstar.com ([202.105.137.238]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id BAA19450; Sun, 24 Jun 2001 01:56:03 -0400 (EDT) Received: from minliu ([202.105.137.230]) by mail.szutstar.com (8.11.1/8.11.1) with SMTP id f5O5rpK10186; Sun, 24 Jun 2001 13:53:51 +0800 From: "Jackson.liu" To: Cc: Subject: no subscribe megaco Date: Sun, 24 Jun 2001 13:58:23 +0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mailman.pit.comms.marconi.com id BAB08768 Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: 8bit From owner-megaco@fore.com Sun Jun 24 06:40:31 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA09269 for ; Sun, 24 Jun 2001 06:40:31 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id GAA22555; Sun, 24 Jun 2001 06:30:14 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id GAA15534 for megaco-list; Sun, 24 Jun 2001 06:28:20 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id GAA15527 for ; Sun, 24 Jun 2001 06:28:18 -0400 (EDT) From: ljdklsag454@yahoo.com Received: from sapphire.ex-teq.co.za ([196.34.144.91]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id GAA22485 for ; Sun, 24 Jun 2001 06:28:15 -0400 (EDT) Received: from [196.34.144.100] (helo=64.65.76.116) by sapphire.ex-teq.co.za with smtp (Exim 3.02 #1) id 15DlnO-0002kW-00; Sat, 23 Jun 2001 13:41:47 +0200 To: jackyfan2002@yahoo.com Subject: RECEIVE $2,000 in one WEEK !! GUARANTEED!! --------------maily7 Date: Sat, 23 Jun 01 01:44:53 Hawaiian Standard Time Reply-To: Yllaxis@yahoo.com X-Mailer: [12.87.149.207] 196.34.144.100] (helo=66.97.0.6) X-Priority: 3 X-MSMailPriority: Normal Importance: Normal Message-Id: Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk R E C E I V E $1,000 COMMISSION every $0 down SALE !! DID YOU MAKE $8,000 LAST MONTH? IF NOT, YOU NEED TO JOIN US TODAY! $0 DOWN ! 100% FINANCING - 100% CASH MACHINE EVERYBODY IS A PROSPECT - 99% APPROVED EARN $1,000 ON EVERY A THROUGH F CREDIT SALE! EARN $1,000 ON EACH AND EVERY SALE TO INFINITY! REQUEST MORE INFO NOW! send an e-mail to: mailybox@yahoo.com with SEND INFO in the subject line or JUST CLICK on "Reply" NOW!! Available for USA residents only. ~~~~~~~~~~~ MARKET the hottest consumer savings package in America today and earn $1,000 each and every time someone joins for $0 DOWN! NO hard selling, NO cold calls - 100% AUTOPILOT Imagine being plugged into a proven system that puts your entire business on auto-pilot and have you earning MINIMUM $2,000 every week! GUARANTEED!! IT'S TRUE! You can be in business for $0 DOWN! And you can easily make $2,000 your very FIRST week .. . and we'll show you how! Your business will literally explode overnight when you join our team and plug into the BEST marketing system available on the web! Most OUTSTANDING: Receive FULL SUPPORT 24 hrs!! ~~~~~~~~~~~ REQUEST MORE INFO NOW! send an e-mail to: mailybox@yahoo.com with SEND INFO in the subject line or JUST CLICK on "Reply" NOW!! Available for USA residents only. To remove please click: remove12341@excite.com From owner-megaco@fore.com Sun Jun 24 13:05:18 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13336 for ; Sun, 24 Jun 2001 13:05:18 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA26279; Sun, 24 Jun 2001 12:56:15 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id MAA25512 for megaco-list; Sun, 24 Jun 2001 12:54:25 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA25508 for ; Sun, 24 Jun 2001 12:54:24 -0400 (EDT) From: 17219212@yahoo.com Received: from caserver.corporateair.net (caserver.corporateair.net [208.49.62.146]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA26191 for ; Sun, 24 Jun 2001 12:54:21 -0400 (EDT) Date: Mon, 25 Jun 01 09:23:39 EST To: megaco@fore.com Subject: $1000 commission per $89 down!! G21 Message-ID: Reply-To: wedgie@hotmail.com Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Dear megaco@fore.com, -------------------------------------------------------------------- NOTE: This one-time message is in response to your online ad. You are NOT on a mailing list and you will NOT receive any more messages. Please send more details about your ad/offer. -------------------------------------------------------------------- Receive $1,000 Commission on a $89 Sale!! DID YOU MAKE $5,000 LAST MONTH? IF NOT, YOU NEED TO JOIN US TODAY! Imagine being able to market the hottest consumer savings package in America today! Imagine earning up to $1,000 each and every time someone joins for $89 DOWN! Imagine being plugged into a proven system that puts your entire business on auto-pilot and have you earning $3,000 every week! IT'S TRUE! You can be in business for $89 DOWN! And you can easily make $3,000 your very first week... and we'll show you how! Your business will literally explode overnight when you join our team and plug into our exclusive marketing system! For more INFO reply to t1212777@yahoo.com with in the subject line or JUST CLICK: mailto:t1212777@yahoo.com?subject=Send__INFO 100% FINANCING - 100% CASH MACHINE EVERYBODY IS A PROSPECT - 98% APPROVED EARN $1,000 ON EVERY A THROUGH F CREDIT SALE! EARN $1,000 ON EACH AND EVERY SALE TO INFINITY! We provide you with all the tools and marketing resources you will every need. The only thing you need to do is join our team and plug into our proven system for success today! ~~~~~~~~~~~ For more INFO reply to t1212777@yahoo.com with in the subject line or JUST CLICK: mailto:t1212777@yahoo.com?subject=Send__INFO Testimonies: This program is so easy, 'with your system I have made 13 sales first week'. That's $13000' this is the best program I've done and I've done them all! Richard SO. Memphis, TN I did it all with my computer! People sign up like crazy! First I said, ok, I am financially totally down, I need to give this one a try. But after two weeks I am already out of dept! Oh god, I did not expect that! And I am not a sales person and I did it! I am so excited, thank you Richard and Mary! Randy SO. Los Angeles, CA I am SPEECHLESS! With your FREE leads, and FREE unsecured Visa MC, I was able to advertise free & pay for faxes that got my phone ringing off the hook! I think I'll have 20 sales this month!!! I haven't even begun to download all the free software to make even more MONEY' Thanks guys Randy SO. Detroit MI I was in my chiropractor's office when the secretary was about to throw out a fax that they had just received. The fax was similar to this email and caught my eye. I did exactly what it told me to do (a fax blast) and in my second day I made $6,000. No hard selling, no hustling my friends, just friendly people looking at a great opportunity and wanting in. Even if it took me a month to make an extra $5,000 I would have been happy, but $6,000 in my second day, wow! I'm excited. Dave W. Newport Beach, CA If you have been looking for something that is not MLM, is turnkey and very easy to do, then join us now, This is the MOST EXPLOSIVE income opportunity we have ever seen. Sign up 3 people & earn $3,000! Sign up 10 people & earn $10,000...how much do you want? This is the easiest sale you will EVER make! GET STARTED WITH $89 DOWN + START EARNING $1,000 CHECKS YOUR FIRST MONTH! IMPORTANT: To remove please click: mailto:t1212777@yahoo.com?subject=remove ========================================================= This message is in full compliance with UP.SO. Federal requirements for commercial email under bill SO.1618 Title loll, Section 301, Paragraph (a)(2)(CO) passed by the 105th UP.SO. Congress and cannot be considered SPAM since it includes a remove mechanism. From owner-megaco@fore.com Mon Jun 25 07:56:33 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA11661 for ; Mon, 25 Jun 2001 07:56:33 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id HAA12144; Mon, 25 Jun 2001 07:44:50 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id EAA29787 for megaco-list; Mon, 25 Jun 2001 04:23:53 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id EAA29745 for ; Mon, 25 Jun 2001 04:22:31 -0400 (EDT) Received: from cvis21.Marconicomms.com (cvis21.marconicomms.com [195.99.244.53] (may be forged)) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id EAA06840 for ; Mon, 25 Jun 2001 04:22:29 -0400 (EDT) Received: from cvis01.gpt.co.uk (unverified) by cvis21.Marconicomms.com (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Mon, 25 Jun 2001 09:21:03 +0100 Received: from marconicomms.com by cvis01.gpt.co.uk with SMTP (8.8.8+Sun/cvms-32) id JAA00160; Mon, 25 Jun 2001 09:21:04 +0100 (BST) Received: by marconicomms.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 80256A76.002DA798 ; Mon, 25 Jun 2001 09:18:40 +0100 X-Lotus-FromDomain: MCMAIN@MCEXT From: "Sean Leahy" To: "Brian Rosen" cc: megaco@fore.com Message-ID: <80256A76.002DA13C.00@marconicomms.com> Date: Mon, 25 Jun 2001 09:18:27 +0100 Subject: RE: Ephemeral Termination Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Brian, Thanks for the reply. Yes indeed, and as you suggest 'the real bottom line question' was "if the physical MG has two, 2 termination contexts, where the ephemerals are cross connected, can it optimize that to make a hairpin without telling the MGCs what is happening". I understand that your answer is 'Yes...at least in principle". I had not considered that if such a solution was adopted the 2 MGC instances would then "somehow discover" this. The whole idea as far as I was concerned was that this optimisation would be invisible to the MGC. Incidentally, I believe that in addition to the reasons that you give about the MGC Instances not being able to share the same ContextId or physical terminations, the MGC Instances probably cannot resolve the optimisation at their own level because each instance does not have the full view of the connection but only a partial one-sided view of it (although for recovery purposes they might hold more information about the full connection then they think they do - if you see what I mean). Thanks again, Sean Brian Rosen wrote: Okay, so the problem you postulate is that there are TWO instances of an MGC handling the two sides of the connection and thus you don't know that the same MG is being used. I'll leave the issue of how the two MGCs share the resources of the MG to another discussion; let's suppose for the moment that two virtual MGs are assigned one each to the two MGC instances -- is that close?? Now, in theory, anyway, no-one figure out that it's the same MG. In that case, your MG better be able to send packets to itself. Then, backing up a little, it's the MG that figures it out, in which case it has two contexts, each with two terminations, and it knows that in fact the two ephemerals are "connected" via the net. It can, in theory anyway, fake the network connection and "do the right thing". In this case, as far as the MGCs know, it IS going across the network; the MG is just optimizing the network path! Now we step back to your position, which is that, somehow, the two MGC instances discover this, and you want to know how they should handle that. Is that right? Well, I must be dense or something, because I would say that the MGCs never Add the ephemeral until they know what the other end is, and then they add it with all the right characteristics. If the originating MGC instance communicates with the terminating MGC instance and discovers that both ends are in the same MG, in my postulated Virtual MG scenario they CAN'T actually do the really right thing, which is to create one context with both physical terminations, because there is no way for either of the two MGCs to access the other physical termination, and one MGC can't use the other MGC's ContextId. So, you HAVE to let the MG do it, if at all. So, if the real bottom line question you are asking is if I have a circumstance where the physical MG is presented with a circumstance where it has two, 2 termination contexts, where the ephemerals are cross connected, can it optimize that to make a hairpin without telling the MGCs what is happening, I'd say yes, but it has to do all of the right thing. This would include, for example, supplying some appropriate statistics for the ephemerals! If you are asking if I ever see a circumstance where it makes sense to have a 3 termination context with two physicals and an ephemeral, where the ephemeral isn't actually "active" (doesn't have a remote), then I would say, no I don't see how that ever makes sense. Would it work? That is, should an MG actually allow it? I don't know; it's really an error (incomplete characterization of the ephemeral), but that is allowed at least transiently. I could see some timeout, but that would not be a "standards based" thing. So, I expect in most cases it actually would work. YMMV. Brian From owner-megaco@fore.com Mon Jun 25 10:03:05 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA15912 for ; Mon, 25 Jun 2001 10:03:04 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA24784; Mon, 25 Jun 2001 09:53:52 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id JAA20718 for megaco-list; Mon, 25 Jun 2001 09:51:28 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA20701 for ; Mon, 25 Jun 2001 09:51:26 -0400 (EDT) From: rcxvhmn3un@yahoo.com Received: from scserver.lnpt.co.th (lnpt.co.th [203.148.252.90] (may be forged)) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA24485 for ; Mon, 25 Jun 2001 09:51:14 -0400 (EDT) Received: from n51299r72 (ip213.lawest.quik.com [216.176.1.213]) by scserver.lnpt.co.th with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3) id NBCN3YBV; Mon, 18 Jun 2001 01:43:50 +0700 DATE: 17 Jun 02 10:08:50 AM Message-ID: Content-Type: text/html SUBJECT: Wave of the Future Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk We will put your product or service instantly into the hands of millions of prospects! =============================================================== "Many business people are finding out that they can now advertise in ways that they never could have afforded in the past. The cost of sending mass e-mail is extremely low, and the response rate is high and quick." - USA TODAY =============================================================== Since 1996, Bulk Email Network has provided bulk email marketing to thousands of well-satisfied customers. We offer the most competitive prices in the industry, made possible by our high percentage of repeat business. We have the most advanced direct email technology employed by only a knowledgeable few in the world. We have over 160 million active email addresses, increasing our list at the rate of half a million to one million a month. You will have instant guaranteed results, something no other form of marketing can claim. Our turn around time is a remarkable 24 hours. Our email addresses are sorted by country, state, city and target. Your marketing campaign will speed with pinpoint accuracy to your desired audience! Call us for a free consultation at 323 876 6148 [U.S.A.]. We guarantee the lowest prices or your service is free! Best of ALL, Bulk Email Network can be used as a 100% TAX WRITE OFF for your Business! 1) Let's say you... Sell a $24.95 PRODUCT or SERVICE. 2) Let's say you... Mass Email to 1,000,000 PEOPLE DAILY. 3) Let's say you... Receive JUST 1 ORDER for EVERY 2,500 EMAILS. CALCULATION OF YOUR EARNINGS BASED ON THE ABOVE STATISTICS: [Day 1]: $9,980 [Week 1]: $69,860 [Month 1]: $279,440 Now you know why you receive so many email advertisements... Best Regards, Sam Al Bulk Email Network C.E.O Under Bill s.1618 TITLE III passed by the 105th U.S. Congress this letter is not considered "spam" as long as we include: 1) contact information and, 2) the way to be removed from future mailings (see below). To Remove Yourself From This List: Please email to jk72jk72@yahoo.com with the email address that you would like removed and the word REMOVE in the subject heading. From owner-megaco@fore.com Mon Jun 25 20:04:25 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA00280 for ; Mon, 25 Jun 2001 20:04:24 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id TAA17520; Mon, 25 Jun 2001 19:55:05 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id TAA15521 for megaco-list; Mon, 25 Jun 2001 19:51:47 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id TAA15516 for ; Mon, 25 Jun 2001 19:51:45 -0400 (EDT) Received: from texlog2.texas.rr.com (texlog2.texas.rr.com [24.93.35.223]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id TAA17382 for ; Mon, 25 Jun 2001 19:51:43 -0400 (EDT) Received: from plong1 (cs666831-164.austin.rr.com [66.68.31.164]) by texlog2.texas.rr.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f5PNpcdQ009181 for ; Mon, 25 Jun 2001 18:51:38 -0500 (CDT) From: "Paul Long" To: Subject: RE: mId and IPaddress of the source Date: Mon, 25 Jun 2001 18:48:33 -0500 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: 7bit Nitin, We just talked about this very thing recently. mId may indeed contain an IP address that is different than the address from which the message was sent. It is essentially just a unique lexical identifier for the sending entity and should _never_ be used as an actual IP address. Paul Long ipDialog, Inc. -----Original Message----- From: owner-megaco@pit.comms.marconi.com [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Nitin Kumar Sent: Saturday, June 23, 2001 2:26 PM To: 'megaco@fore.com' Subject: mId and IPaddress of the source Hi, Spec says that response to a request must always go to source of the request. Now, we can get source identification from UDP or TCP layer as well as from mId. now, which one should be used? Is it possible to have different value in mId than actual source IPaddress? Secondly, can MGC send Auditvalue to all MGs, which are controlled by it, on coming up? or everytime when MG comes up it sends ServiceChange. regards, -nitin Ind Telesoft Pvt. Ltd. 104, Koramangla Industrial Estate, 5th Block, Bangalore 560 095 Tel : 5508930, 5521937, 5529758-62 ext-259 Fax : 5521164 mailto:nitin@indts.com http:\\www.telesoftinc.com From owner-megaco@fore.com Tue Jun 26 05:36:36 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA25903 for ; Tue, 26 Jun 2001 05:36:34 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id FAA04288; Tue, 26 Jun 2001 05:22:12 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id FAA22290 for megaco-list; Tue, 26 Jun 2001 05:16:03 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id FAA21646 for ; Tue, 26 Jun 2001 05:06:15 -0400 (EDT) Received: from kr-outmail1.lycos.co.kr ([211.51.63.160]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id FAA03739 for ; Tue, 26 Jun 2001 05:06:10 -0400 (EDT) Message-Id: <200106260906.FAA03739@mailgate.pit.comms.marconi.com> From: "¹ÚÁøÀç" To: medlib3@medical.yeungnam.ac.kr, medpharm@medical.yeungnam.ac.kr, medpostgr@yumc.yonsei.ac.kr, mee_world@yahoo.co.kr, mee123kr@yahoo.co.kr, meeki@samsung.co.kr, meekid@hitel.net, meekings@idi-middleware.com, meeks@changwon-c.ac.kr, meektk@hanmail.net, Hmeeongu@hyowon.cc.pusan.ac.kr, meerroo@hanmail.net, meesook@eve.hannam.ac.kr, meetdragon@hanmail.net, meetingand@netsgo.com, meetingwithsook@hanmail.net, meetjh@tradenews.net, mef@xs4all.nl, meflores@panam.edu, meg@menupan.com, megaco@fore.com, megamax@hanmaHil.net, megapass@onegame.co.kr, megapass2@yahoo.co.kr, megapr@hotmail.com, megary@hanmail.net, megi@ketis.or.kr, mehlbegg@cnsvax.uwec.edu, mehnbal@hanmail.net, meifox1004@daigong.com, meissner@cygnus.com, meiswink@itsnova.its.uni-karlsruhe.de, mekotl@plaHnetx.bloomu.edu, mel@dcs.qmw.ac.uk, mel_liz@acay.com.au, melani76@yahoo.com, melbourneemr@coombs.anu.edu.au, melobby@dds.nl, mem@mv.mv.com, member@bric.postech.ac.kr, member@chosun.com, member@edutown.co.kr, member@ieea.co.kr, member@labplus.co.kr, memberH@linuxer.co.kr, member@oktop10.com, member@starcome.com, members@kaist.ac.kr, membership@fnjoy.com, membership@sbs.co.kr, memexlee@azalea.yonsei.ac.kr, memming@cain.kaist.ac.kr, memory@howow.com, memory-lina@hanmail.net, memphis@cookand.net, memphis@silesHia.top.pl, memsysop@netian.com, memsysop3@netian.com, mengel@fsui02.fnal.gov, mentoroh@chollian.net, meolakim@yna.co.kr, meolakim@yonhapnews.co.kr, mephistopeles@hotmail.com, merchant@linkprice.com, mercury@dailysports.co.kr, merdok@lacademy.co.kr, meria7H9@hanmail.net, merideth1109@hotmail.com, meridian@meridsch.demon.co.uk, merlyn@stonehenge.com, mermaid-3@hanmail.net, merners@netsgo.com, merteree@hanmail.net, mertonb@aol.com, meru77@empal.com, merzky@physik.hu-berlin.de, mesang@world-net.co.nz, meslta@dHreamwiz.com, mesmac@chollian.net, mesoc@zip.com.au, messages.yannik@softhome.net, messenger@interkorean.com, messner@hanimail.com, meszaros@sztaki.hu, meta@ix.netcom.com, metadb@dpc.or.kr, metae@lycos.co.kr, metal@korea.com, metal@uno-systems.com, metaliaHn@hanimail.com, metallica-x-y@hanmail.net, metcalfe@ecis.com, meteokong@hanmail.net, meteor@sprintmail.com, meteor21@netsgo.com, metro1@netsgo.com, mettw@newt.phys.unsw.edu.au, meyoon@dreamx.net, mfay@fs2.cp.umist.ac.uk, mfc_faq@stingsoft.com, mfeder@mineHs.edu, mfgyclee@hanmail.net, mfjbrsh@netian.com, mflansbury@ireseau.com, mflores@su1ag.ess.harris.com, mfoley3@chaucer.helios.nd.edu, mfrith@bji.com, mfuhr@dimensional.com, mgabbert@usrtoday.com, mgarden@nownuri.net, mgatasa@sktelecom.com, mgator@ntk.co.kHr, mgbaek@willtech.co.kr, mgbkim@paxnet.co.kr, mgcbo@uxa.ecn.bgu.au, mgcho@physics.inje.ac.kr, mgcho@skec.co.kr, mgchoi@lgis.com, mgchoi@lgis.lg.co.kr, m-gebis@uiuc.edu Cc: mgjmw@cc.flinders.edu.au, mgkang@kihasa.re.kr, mgkim@kr.ibm.com, mglee@infoage.co.kr, mglee@kmucc.keimyung.ac.kr, mgm@royko.chicago.com, mgmg@chollian.net, mgp70@hanmir.com, mgtaylor@eos.ncsu.edu, mguess@chollian.net, mguess@sprite.calscom.co.kr, mh1@Hunitel.co.kr, mh20510@sayclub.com, mhacker@shinbiro.com, mhands@nexon.co.kr, mhang@net.co.kr, mhaveri@sun3.oulu.fi, mhc0515@skylove.co.kr, mhchoi@cineseoul.com, mhchoung@davan.co.kr, mhchung@ktnet.com, mhechoi@yahoo.co.kr, mhedblom@broadvision.com, mhh@compHuter.org, mhhan@bear.kyungil.ac.kr, mhhong@icc.or.kr, mhhyun@mando.com, mhinchey@unomaha.edu, mhj@bluecord.co.kr, mhjang@edunet.kmec.net, mhjang26@chollian.net, mhjeong@fiti.re.kr, mhjj@hananet.net, mhjun@cbucc.chungbuk.ac.kr, mhkim@chosun.com, mhkim@mailH.skhu.ac.kr, mhkim2@trigem.co.kr, mhkim2@trigem.com, mhkim25@hanmail.net, mhko@hanmail.net, mhko21@hanmail.net, mhlee@kif.re.kr, mhlim@daoudata.co.kr, mhmalove@orgio.net, mhmdali@pc.jaring.my, mhmgr@netsgo.com, mho119@hanmail.net, mhoh@hk.co.kr, mhoh@pagoHdaac.com, mholder@indiana.edu, mhorn@b022.aone.net.au, mhra@daoudata.co.kr, mhryu@bio.bmelab.co.kr, mhs@ked.co.kr, mhseo@hyundai-motor.com, mhseo@sinbiro.com, mhson@mail.uiduk.ac.kr, mh-users@ics.uci.edu, mhwhite@kado.net, mhwon@iline.co.kr, mhx@iaehv.nl, mhy@2min.com, mhy0123@netian.com, mhyun@hyomin.dongeui.ac.kr, mhz@coli.uni-sb.de, mi0411@iycos.co.kr, mi65su11@hanmail.net, mia_woo@hotmail.com, mia04@channel.shinbiro.com, miae1108@hanmail.net, miae871205@hanmail.net, miaejune@hanmail.net, miaelee@eec.co.kHr, miagit@miclub.com, miaju77@hanmail.net, mi-anise@hanmail.net, miazma@bigfoot.com, mib@ix.netcom.com, miba@bcline.com, miburo3@hanmail.net, micael@dt.co.kr, micchoi@crezio-edu.com, michael.aquino@125-430.wmeonlin.sacbbx.com, michael.blyler@gtri.gatech.eHdu, michael.flagg@awsj.com, michael.norrish@cl.cam.ac.uk, michael.risser@summus.com, michael.sweeney@cle.ab.com, michael@cantor.informatik.rwth-aachen.de, michael@krypton.mit.edu, michael@simplenet.com, michael@xanadu.com, michael_philippi@mentorg.com, miHchaeld@online.no, michaels@jake.unsw.edu.au, michal@ellpspace.math.ualberta.ca, michalj@fuw.edu.pl, michel.lavaud@univ-orleans.fr, michel@es.ele.tue.nl, michelle0907@hanmail.net, michinnom45@hanmail.net, michkim@catholic.or.kr, michuhol@www.ikom.co.kr, miHckey@donga.com, micro148@kacl.co.kr, micro-cosmo@hanmail.net, micro-forum@bric.postech.ac.kr, microkid@net-in.co.kr, micrology@aol.com, microsd@hanmail.net, microxxx@shinbiro.com, midas@emoney.co.kr, mid-night@hanmail.net, midori@popsmail.com, midr@wh.myoHngji.ac.kr, midway@chosun.com, midx@aol.com, miechel@hitel.net, miffy@indiekino.com, miffy98@hanmail.net Subject: ¹Ý°©½À´Ï´Ù Date: Tue, 26 Jun 2001 17:44:00 +0900 (KST) MIME-Version: 1.0 X-Mailer: SoftForum-WebMail 1.0 Content-Type: multipart/mixed; boundary="==SoftForum-WebMail-1.0-32BF5B923B384B50==" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk --==SoftForum-WebMail-1.0-32BF5B923B384B50== Content-Type: text/plain; charset=euc-kr X-MIME-Autoconverted: from 8bit to base64 by mailgate.pit.comms.marconi.com id FAA04288 Content-Transfer-Encoding: base64 v6m3r7rQv6Gw1CCwocDlIMfKv+THz7DtIMCvwM3H0SDExMe7xc0gsPy3w8fBt86x17elwLsN CsbEsN3A+8C4t84gvdEgsKGw3b+hILD4sd7H1bTPtNkNCg0Kw9a9xbDUwNMuIMCvxr+w/LfD x8G3zrHXt6UuIE1QMy4guvG18L/AvcO18CC17rXuDQq48LXnIMfBt86x17elwLsgxse4xcfV tM+02S4gNr/5IMPWvcW4rr26xq7A1LTPtNkNCg0KubC30CC9xb/rILDGwaTAuyDA/Mf0IL3F sOa+ssH2ILi2vcq9w7/kDQrDt7rOtcggY2RsaXN0LnppcCC+0MPgyK3Az7zTwMcgs7u/68C7 ILq4vcXIxCDA/Mits6oguN7Az7fOIL+stvTB1r3KvcO/5A0KwMwguN7Az8C7ILq4s70gvsbA zLXwt860wiC/rLb0wMwgtcfB9iC+yr3AtM+02S4NCr7Qw+DIrcDPvNO/oSC/rLb0w7OwoSDA 1r3AtM+02Si43sDPLsD8yK25+MijKSANCg0KPT09IMavurAgurizyr26IL3DtfC4piDB9cGk x9W0z7TZID09PQ0KDQrIrr3Hx8+w1CDI3rTrxvnAuLfOIL+stvTB1r3KvcO/5A0KsKi758fV tM+02Q0KDQqzocC4t84gx+O29L74wMwguN7Az8C7ILXluLCwzcC7ILvnsPq15biztM+02S6x 17iusO0gv6m3r7rQwMcguN7Az8HWvNK0wg0KuavA28Cnt84guPC+xsH4sM3AzLTPILTZuKUg sMbBpMC6IMfPwfYgvsrAuLzFtbUgtcu0z7TZLiAgDQoNCg0KDQogTmV4dCBFbnRlcnRhaW5t ZW50LCBMWUNPUw0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQogwfGwzMH2IL7KwLi46SDAzsXNs93A zCC+xrTVtM+02SEhICAgaHR0cDovL3d3dy5seWNvcy5jby5rcg0KIMDOxc2z3SC4uMitwMcg w9awrSwgtvPAzMTavboguLjIrSAgIChodHRwOi8vY29taWNzLmx5Y29zLmNvLmtyKSANCiC9 sbDtILr8uKUgua7A2rjevLzB9iwgtvPAzMTavboguau8sbjewM8gIChodHRwOi8vbS1tYWls Lmx5Y29zLmNvLmtyKQ0K --==SoftForum-WebMail-1.0-32BF5B923B384B50== Content-Type: application/octet-stream; name="cdlist.zip" Content-Disposition: attachment; filename="cdlist.zip" Content-Transfer-Encoding: base64 UEsDBBQAAgAIAO8ArSqF+Y01cx0AAJ1CAAAIAAAAsNTA0y5UWFStXP9zFNeR/91V/h8elbqcyCFF +0UriapcSpYEqCIQh2T77lKJS7ZlWzEWOYGT3C/+XxYZYr5oNcvs7M7Mzu7MaHdmZLzSggCJLwZh giyD0AIRSAKL1HX3zK7e7Bd8VXeKsdG8N/36dffr/nS/nmRnxBWnqGn6/V+/+UZuIWMx4apxRY5l VDtmXE0UEzda3nzDWE6sMCEq3DZUFm5tbWX6ljfGdoYKipOaY8HuHmbMERGY3NECs8uT33xDm49f lZ+w7KZxMyemRKa8tM5kctITQYC5xsv4HfwlMc3SK/qqUzQ3WPZixnBfFdbid5iwhRNk2Ui7U665 PLz5Bv7zs58xc0GJOcWMk/wrEFG2ZiaAIXp23VzI5IQ1JpeMZWPO3JAkBmsWWPablGku4O7ffANI nJ44Hf0//+9LJHTSnlIFTTOK8XvChLnkCoD96lf/ypzLypYeZW3ACO4ik5MfMG1SfZpRWYCeScuy iLNPn0RCp/8fODpFm3vtz2+ZE1M2zClSHPsdTP8t2991sJcFI0H2O8as58wp2jHGmpzL8Vu2s5uV KeLvM5NMcuLfM/NLOc3i9xI3UqY+zYxbjmAuwV6donjWnG9h+nldyeSUPD7U4iy+CJYC8olWaGVt c4GJz7LziS1ipIUdPBwCHYqPjIw0gzovScvMjqVOou5wsvCVUkhdcY2khec6AFwrS4nnIFagVADW +/rYXpY5LUn6I6Yb6kOWLXLbaQoby7t5Aq1AQF1LnWQ/ZzOTRKAymZvW1gnTMpaZdF6kTI4cqyHY 1gEzU3HYmbUoJ1lKMQraJOMntOOKcvwW/mEhPGYuNSQWrCIWgbl2LLluFNSHsMUgGxwdGR8fZkPj o++PHIfff/HnY+Ofjo59/At4uRv4ccd5Em3IjyJPwev1NhaG4XyegR7VCVjlqbe53dWWhCfSEkC0 Qfhp3vlXa1tbgKcXAnqaZl9ITbHwe+aXmTwb+mSEDY6cOHF0ZPw463sHaPHz0ewyX5ul92ZixrJ9 edcuWL+oPwJu7bytgcLiipjO3YPzs7Y3Y4ln4cTTQEP+WjtbA83hQHt7qD3QHGyNhDvag82htkAr vyqaDfD12Qg7PDz+Kesb+6CFNaQYbmttb24HRXWGg82dkXAg0trZ3NbW2slTRDvK2vozOaY+bBp4 e6i/753e3Q1pdkf6e8OB5q7QvnCkrTkcae+GX7p72wP7WHMzy6iWrM+6lj+zll5xLjNjO3UOzxS3 ZBhtUpuUr4gX2eDnn312bGxk3DMhJBLqYdlFzWGpy04OrHCRJVaNW/zrHWRbqagzA2zZGmfU/Cy0 VhB+LFsClaRfgIWNjI8e+/w4Gxz+jDV9sJt1jx87MTL82S/3twy09PBvou2m/6E+xD8MOWJxJf2w Rb8vx8xoi/C9LuGG9qAD4F9Dex08MTzO3h0eP76XvTWMlsM+OjbODg2/f+yYjzk0Xvslit3K2Rm0 8JB7gHw/7gzDQbnC4uBojG1wdLj6v/hEJCy26DnnOsxMrCo34TeWW8pJu/gV0bydolGY2QRPgScm o6pasLU16OMLjdo8bRSZnDSW30O50v6ZUVTTuN89njfl3wmQOuSYkyNmCkSUNbkWA1aftZVz2ivj JstHM9ZMnllnUichCGJckb5Bv8gf63ArcSCu6lGjYG68ByR5B1CRU3l+iPzb1/mbIKJZ1lT2SLt5 DkNoMNKTrA3ucg7drDepmSnn0j+Yp+mvtZTbSWLZ70AUGaY8iMs+mmgkss30DbQwFt4xX5c4P7WN Z5EfQCsQz2bU/Dlyt5kC0OHHUWf5NUvQTvFPUUewiMIcMzWXXQK+QOK8KwsF6EjLd+RY/hz/vJV2 5Jjolh2T5c/pJeAIkRQ+sc5wc4OdpAfyZ/mbsEfYalR6ovEbC6Jc87et53Ze32A+Qwqi8NDUZN8L KDRLNgqCpT8yS8R3TegIorgEx/8iOfsXyCMLMduA3aUU8Sw/I0T8xu9B/M2u43ayTyju8HOCJBdw HUU0qep1UWo6BGr+GUoMjwqsPCsCeHStpK6aAygx/aQ2mVH5px3elp05N6hLp6RlfhwFZcxmVDD0 Od+eA2RhdzKW8bKG1wDKSH8hLZPcmbgqT8im9ISfgRKzXqBZJZ6ztloKKC9DhYgl6c+NbU1kkfq7 QplJX1myvZlRQyw1gWuSyfOTSHRb2j8AMiQNR32qXKIT0d3jW9KNNCTOM9KydArcTPWcVhSilUq8 yj5JgFmBFkvuHGQutyCsgYsjBMi/07Fj7pNwJuP3WPYGJgi11FHYh44xCDjs6OifAIeAdx75E0Sf yhr6GXBUOVmVISkoADY35gT8SzkmCYs8OdRQ1rHPuC6qvWox1JE2rxvC5MwE2E3VKOon/TiumBvt DM9PdtMS7Bg/I+QBDKYUYOUmVRAnNS29TmzicxCFCz0MGdyaIqQueeorpz6YLfExoBV1KUTVh3JM /1I8S5gx5HLG6qi+NVBhkbX7BI6K7Pr3vkFXKfEbzJiS1yDWg5RSc6rO5AVbc2OBT2CBTtSuUnDu BqtVE+hEJRpz1mwKvBFzX+aH2zkXHnR5vZSPsqa+seMnho8eZcqGse2jh7o59FZXlW8MdKJWpOXk OpgKcF85IYhcjGKtdQU6UVHKD/aFTDzoex5y3TAGEjkmP0GuzZRifsUf/0AnoUSgnYkjZFmxb/mH UcSOY+dr2EQRKzeMgm5A0L4JTi3EjXZ07qydupyawtAC66ObyT8O7vXMgn8BpZtJ2LdmJjCuhvYy 5zEcEz8uC3S0V3z+XgAAGK7IZek5+YJz1sd4B5n+E2s2l1fX+OdtHGeKtJxdT0nBaucT6ECZHjrQ X7XpDhSpPQ/+DgDAxdQF35aD3g5QKBAFql9FQWoLZox/1koHCCEiJStv/4YbbO/07MOYS68YBd4n B9o9vFBylq3ZMD+AAqoReB15t1P6A6daUsAR8mbT3kaKTW6CqcXvpVf4oTAFG/MVUA4E2iL8EErG Op+aA6yQV0rgz/lBOtaW/tjYNh4jjv7gQ17Y7Sga8ZFVrDPUWjnhOUleY0FuLNJZkZ6b62WfyDGl YGskqqqfwV8ewgQrEAw0t0Za8Z/Kf8PtIV5RkQ7u2CTRBWWvy5a5yToq3NWl/enHn4y0hwEctH02 zpOj8DmFdR3gkR9ADfxGjkEOj1ZDR1B1AUdvFz+PUHtvVz//DBVRiYs1sTMQQW0kitIyxkTHgcPZ xo8GK3jY82PVxkq5/8HBCgqvGW8l8JQtob7LQmIoJTi4gwe6egbeZQP7WE/v0AHuLcr0XTTpgckq kVCCb+eT67rhWSzIFYwqCr9DZgoYkJ+MgnUxuOsDTnnROMjK9l6blAco7ed/R+kmbgDiVwxw2009 mLMeGRn9eIwF66t6L7zZE2ke6n0r3Nz99uHO5sNdhyOQswY7ebKoIK0UV/da9600YKDBT459/PnY 3qFjEAsw/aqEF/9Pd89vRv57LwoY7LO1DVKXnf9GwkH+qFM5QHnkbrrpneHP/jg6PrJ7L4RPYxnS BkmakRss4hnska7uYPNgV3+weX/XUKj5SFdPqDnSFuYthUoIO0HNhZZ1mP4Uma5kUcbV1DRPJEBl EmMOIMujCMwrKbcBadq3qIDjoJIUBBA+NaGByeC9QTFgYmBa0nICMTHvAChLh3RSEM9ncvEvaawu Z6FQRyQY6Qx2hiO8uVGazjmQZi+P4KeQka3G7xnbmWlfhAtXGRIl12WXDKBl/0B/Dz9M+fSmkk9N sX0BlvvKcfRpCLlVJ4CS4HLIxyCHuwdvCzmB5vPflAdrGshtPr3S8JxS5uuYsqBpKMQ7EAx09m81 7oJSWmMeFLMhC5ijKNwg5a/CZC6Jz/ey5DMAJ7hPmCfw4C1ASay8YJ3RIVkwYhACIYhfSr/SV/lJ KFBBjMuA8K4lzoHrqTcJZZtx8noqzWZOJW6QJdibeR02sf8wa9IN6z5GWdeL8DuhTNbnkFiHpZLf 9tjGepeP67CX/qgToPsZLV4bKynLzUnpdQAkv4VsZ9lwskuy+bsaQBqgzNcNVxHCiuJtNyetMzVQ Fb2wplmdwAYoIRYf+QuMVT+aKK/BqdrIpcVJKgdD4MZXWlrKmvKiGW0dwoYSM+AgYRm/UU1bOsXU p851etFwq+qI4JGAZAHBxHN9jZbiJUkJuX1fnsjksrZ+DRwBoO1KWQRUwM8lTw+5khlttCFnw1iB 0y3LelRz9+WlV/6qVoASefSymJSVHf/QgV7Wd2TgEDvc37X/7d6GUpuZSq8bPxpzAJCz62AFV6ga 6N69zBFVzPXgJFZSmT2NZIa12L7xY2Ps8NHhjz8fSUxjGUnRp41Cch1+MbadZyz9PDWnl/YwYSt+ T59tRCmxCiFtFjBY4oZ8Gvy5uQURSpOVrWmBKTF5DW84JOOqs1RTtA9Q/YJSsp+yl6D+Qo+6Gp2h /ea+L6evKGtY31hRCi1gRHIaTqlzUb+f3WrI8bQrMjeta/Fx1FaJ6T/FUr1gDmC7kMkl1+UHwIlR wFUkiV0wmHNdld1bp/osCWuJVQ+rghCVH4Tv0YSdy0AmdxErSpct2TpPCYbPiMlPw9oiqB/OJuXo dVGfyzMg2lugj8TXQtQpYinRO4Y3jSlJ2sOCPSDIUA8K9ZVyGhJQMzkz2YDl/DmzpBQYuJYk+Lv7 soy5nqipIH1pNT3PEn8TvmXGAiySF+UpyHxmqVS0qwE5/SwIAGu3+Rw7cng/CCHxrfYj6Nz4zljR S+AllVegf2fDt30qulwxt1LFYKMtByyVjiTncYB4/F6q6CwltsBvZ3LCRKWq7lFr6GlcDxW0VM89 card5ctLgm6iap/JliAgyjH7QkNXWJIFo7DHDSvkuITJ1HR1wTlA5TTztIH4Yl+goxE1utEFb3gX d4P256OB/vldQLsKxDyEqglukOptELaKTF7HVLWxDUEkF34AP4S8JpeENVfN1YsFXLxCkcLOQ3zF +lqDO6Uy7ToRYJePJnpP5ZwxB6cKDtwSeFkPktQlpxTEu2B3ztULF7y3yBTSr0wZwoV4Vogi34u0 Ea/kgtMaar+8qBCtWAKsTteo1YE6UAW4qMJopbya5XIqKjxm9iWqAdRl3VzSNBZXYCW9pEt08F0A 6soZHpixkCoD2gDHd01c1O/7HRnVK/XHtiYnmT6dXIf48FMOjS92+bZCZfObqVWmfwvKb4DSXRo7 pruL5U5qGkLRECvrAK99qB7kuW68iPLrN0jgW9kQZ7H+45rBaz2az2JQkWAwxAUxUbn4MvFWZ2dr 9T3aTVmWJDwYHqIFPwFPVtiMnF5J3Beu+qlhS8HXdJFW98dbDLippCQgBvVpXJQc9Ly+GznSqU8Q 7pUDXWXAsf0n9v7n42OjYx+zj0aOn2AfjY4NH21s9Nq8eFd6ILxkykvYxjQIB6SYmVZBNijyba/0 WgmBvoXRRQz9Z9eRpulT8kRDsaN0UXcuANmxTo4SlZ67j7w92NXTe2QQE+yDffsPDLGfs4Nd+/u6 qyn7cKFrGF7Obpbo0PhwMgSxgDGXPwvHIEpa5xdGx/NO35Ght7v62eGBgX52YPjo0cbAzZQr9rgS l6vwGpW4IcTFdEO8zfJ5O58o7sDjuhSx/qXK8cXKa6AJVRbTqIliagX/fMEMQVNRbJWWm50V0XPs 6+vt7wFRDQ4d6e06yIaODBw+8B/sra7BQYSpvX/54/DY8VFAb/3Dn44ch8TxdbujSO/tEHNPDy7a MQAYjjoBBg8kYQzv6L27d54dahtYEc/aGSkFmSLu/bUnMnex4gRQibsoWriomGAGuDRK+sVngNXL J6DBKfLBNCZGs1uwFf2Mc3dXvVDBc43u790+kKH7r97Bodc7Ll2amUTkdcMyKRxAKMiWpGX1VC7P McHii3RNjkD8iy/49dBH7vtlV3Ogo5cNfv7HkXF24Nj42MiJhlHftvP5KEtdwzLDHrxJnoMdlcCu IcbfgtVlW5LEm5C7xG/hdYgQbeRoXJTO9sHSbGZCvA0kAIRvQFjGPhj5ivSACSsApCQF8pyr5JIa kco45mlqtDKXwECUc/F75EbEFPqSv1FSoZ8H3gRRvD+9aRSkUiNKFe3zMgryZcAQptJ0Gyzefb1q 8lHlEiyayYln8TyBFyXT0YuaKkmgKvLZmZzxismKoXq7NpyGUDua0VFGX0l6JpdfBAxYNkIvIsHW y1wCmDXOYAMRJfz1/TxaC+jgCsQHazpbEs9W5I5I+0Ymhw1gsBV0kDDHKQprDWktuDnSF/XlR70q IyfGRw8Oj40Os4PDx0+MjDc2aH1rZpOZL+UY9dV5CA3gGNZSMyocTDj2rj3THuJ/v/BjI8aA6ass J8oxL/vC06h8n1gFtUinjIIl+/jEENLdPzDYy7oHDr7VNcTCjZg8OAjO0mFxFf5TzmSpLg8pIRbm sVXDAo1Uhym6+Dr8ybGRsdG/vN54KoFKL6qAKGKVPcOJMLNmCnSkxa2ccx38U2ZOf+SJqaGGluUJ ouwUCQZmF2Sr3JXoFPUzkEp4IcxdxadBupN790Bvbz9Gw6E+ePR63i+yKlfqwsJMDnIlyhEdli3q jxG2ur9RTKwlh/G+yoNR555pxmX9/hfuL5hAGwuIJJlw0szS8dej2IpZTQ5zMRwBt7WmZcE3mGkA NhkT+FAvGX+N3zM3ZJnNzGUNnqhfFO1eIRsyje//V8iUGRlNhXx7q9r1K0uy5SZicM4qyRi3FMbT wdEP2cGR0ZHxfz7Ouo6Ojoxht9Lx4x+Njo/8hOVQDWMPy35j55mWtcBbwyko8UAFTIhgYiZX7yoH YUu2bMigQnUbzl+caXAmMZjlcykVwFgNDKB7Ve7XsHvF0XdoqPfIoa6hvoFDAG72DQwMvdXV3//a JOjgIAVf8aw+DdgQ8uu7cdlrtuztglNApTNwn8tg3FknNQ0+Lylm63h2cwP4PTiIMGYxvc7ka8ZL zHA3c5tunE4zMS0+T0wLs0wQKCOBUG3JyLZer27m8URFEgwz1KDrmaf8AJmGpXq7sGCMeQ7ZU/IG eNg6JQnPj4EV30z+CGdTxtUh4oTZL1h7pEN+Is2RFJRzKZNFWulqGctnhfQ63YvXxIjE12DN7mpl nvQJc6uygr+GBKacxeY8Ky68rKXmkenqAy/rCgyQhmlm7TIZiBZ6FD0smJznTTjVI7TA2y+8lGCp KfXh6+HXZRaMyIj1KnWXsLkRl/ewYIcgYmlnWZtHdy9D+Jxhalq4jSXFhpDAn3iW9xvRX4C/07ZI qNYZDCh4wR0vmRuNI29EEPUX1PCcXJeTdoaiin4+d4/koJ/PLvDL1R4JxA/dRwH5NkGIANy6mzWV Q/fu+ulEOfPK5N2c58jh/XzeAz/eOaaHhbgKnqMGHVU63VyVgfedBj8nPUCVwV9nnmrzmbxRMOd/ //tGr1LmRw6yzEYtqDQKLnS4ggFRxkJaNTXZ0h+hz1bRuCtcBamclcAOHZczMqWyb4VzlXiuztee Z/L5ZHDzsgyMlXkiIbQ02giEvMS32lZ5I8ZfzQWvxwO83Etg4gEDa3qF+BWCBC5OB6NGO5OQ0OVf 0GVRfFGOAVi1b5lPXScAEG6WwJO96VwF3+TJBEMJlgVX7ZrCrnMP/FEmZ10QZsGF2FPT0VrjQfC0 /3Bba2vT/vHhsQ/Z4XGADvDrbla+n/F6Bst1rNfdW3CwCfNqYItMGH09XgFiIyEgGMI2WJBrcCDw ngiTReu8V9Qp1y0gUJSZwgFzyU3f0MWqssG1VlBbi3Ufr9OwobW2CLqT3PDTsE4PdOEhYpY9XglS nbNm8a+n8BQz0EahYVbGnHltg6p+fJLEF6A6OvnwRf0y+qxRlJaZ/g9Su/YMe3GbdtKzwQMQzQbe HmqcoinGNlM2csm8QGfF7Q7H2gD2AJLl8KcKbAwUU0usXFwHT2ncAwFDZuRkS6qcycW/99XQqH1H 3wCFRh3TjgW9u7EmdcK+IN7e3cjL4XU15DaRSGekOTi0/53moaFIuLn70MF3ONIRug815uiyFPXC jfkjP/X2zExhu4WdgSOR+w4YDxrL9R1e5Yao4k3ds0lpB8vMJm5gaPw1GrDIsJ3MDdzO9fq7qQFT HaE6RV1uGF10Z2diLaPiHzhRqpZa4ctC1Fjk1SU7q692qcNo51fqKbIWyVwwZhgFZYPr4qG2ImFN nrAEFmjnnqPeNNOaTa7nb/L349RFVOl6bRo8tJd93P7hfx0fP3H0k+Hg+3/+IPQHjhnqLMLbUWvV KDICofQxS5OwFpdT5h7lgXl6T8ZKrvPvhCtdHm6lV99KPOeGQ/79BfmeUq5bglqMwLSxCBqq1oyY 1lf37nQoIILbNje0QmJLvbQLPxXYlCTvZSxgPpEn6GMv7xZ0pb6ilWuGjL57RbmWfWlu4D3aFsMv svCIXzSyVfkXNTpByH/mbxGjHqfqRhu61g7t3FPXbMWD817vZQFR4VWKxEy+ST4G8zTYU25JiEo2 QbsWzxHX2ww2Z0gP4Hxf+IblvtQ3EPzgC7Ydsy8DGVkBGYkeGeNH6QE8oxrKRj1qpujW1l346c4z t/hG0UqKD2qI1Z4Yt0HLsfOI0VkT4lnOYKjf6tBbXfUHqettE/tIuDYJ6rBSCtIy5CKlSqsJNx7m Oozxqqq+AXmGkr1IKVMBQzfskr/P4ki63/Koj+jSOsiaytdlu+vT7ux0isrtyhV45XYNnW4F4vL0 8SDIEiIW1j/IhKeO6QrE7x6ozysQBIi5zTf6UXuXPW/G3C5HusdvwGD5Bsu77AMwZ+HG95SlsUMF k7on2BxAkIoJP3hfTNZaSGWzoR5sGz5nLJOvRbNgZwewz/9qzfmh3jJtXn8sx5QN7jFdmeUgSt/S StYZrnuI2se4rqTUXHwRe+UI15XnROq3mAWpsou3VFXsexh5jr8zL+c1AGd/7d6dMrrZ9hIcKgrM Ao+aqAh1XQliMeFHHiGVgdtz5izVSqLNa+gth9nmZvVhagW74rlJaNL7urA3KKYAN9SG2ISJ7O69 vV1uSsXNDlWR5IaCbhpdOXFeAYpuTcV1t/rPWRw1g+HXBPYtO+bEWFOop3xHwM8qt30ycFuSsR2s H5vLZoc1Xj6TwJYL8L2+q2R0xK6sXEhSrxT1ku4jkRc3BkDS7iJ3jy1qOFPX5Ass0BIeLn9x5n72 We9YOGB4+moZEmC9bGaT5fNOGpJITPMyDt4q5y+bhPsW4Pwg8frpHgqU7kW9Vb2Ey31DBWvSS8od Q6ZvdHEKExeypcSdJKigHjmniMGpIHwN8yqfOe2Ck98q3xGilMZ7G+NMK9zh65Vimb81df+8Gz3i buwnYsln2BNW51yU8eZ98+9MizsiASrqH2LJU9oVEoawJdwmzG9MJRZAEVLJWMYqFKqwvr48fAmH 0cEcJ3/OcbCAOCM5rh7BTS5Jjs/vUj+fleYe4BEXTkKqwz+kHnFIOaz72EdNt7TcaNj9rnUKIDLf cE+9e9Kp7IX8Of7whLluW3+3H3XnHdrXDw6Pe0i+90yqyLc6Ug+e9J3/deq3cx7nl6izoPyQbtds 7wsYrmHR7anDrx83IJHSo46jzcMGAtwGQp7nmPVP4Yng1hNbxrYl2Ld8m6ceufC7PUzZEkRJqeR+ 3AyUg/EDSxTzt5Pr9NkWhiXG4U/qibOeAM7Z1kTusdttLK2w7HWsjs8ZL/ECh/veA8WTXYLsi5MZ tZhh/zwv3aDvC2HfCMpHnMrayXXqx1Zl31dQbZXPIf1fbPHQgP+QjRBFRvV/3YU0VvLfsnAL/8Vs wOvVBmDCvG5t30d2uHtJkor8xxcYu+ak5VRcvOjjh1pE4vfjd+KymcQOFL6XngJe/kf9FN/J7fXZ lr+m9hGjYyACJmpuxv9XAr5jtObbcJjS5ptCCKck8N9eUM/qHH3AHGK1RFEQ8UXwrraTWBHWasZb 6eMggLZPyC6rxzupS9PcyJ2ErbuDfNZX29HOKaG93renVXMo1yl3NCi+q/k27wscbPlbAcwa8p9z cgAGYjG3XICfEPOch7yv/ugjxmDNxkhsWUjw7lppFwaYtlYrPpg1PRWXsWqyJadTJunyfwBQSwME FAACAAgANYfQKqIuDdgoBAAAvQcAAAwAAACxuMDUuea5/S5UWFStVd9PG0cQfo+U/2FeKiUIWzY2 QXkg7b9S9QmptA/pP3RAjFoVsxff+XbP92PPV3ud1HCBOAYX2TRpHRwREITKdRMidXbvDkPbh0rt gWTd7M7MN998Mwdw41lMHgCd8g6w1+wj7xiR0ZseLd6+dfsWzIDXqhyJyHH8Xz9FRzc0z7gAopE+ ea+cp75ZvA9Az8wjdc2oAznRB0Am8o1SXoPakX8s9iEo8QP8MYe0kvipTG7DP+Y25HM5+ARsyofi hTqG8LC1aprAhftERMEYaFXCAXTC/9JqSfvPf2sy0Epz0yaOwyP9FVkNDhNCFhcfgNhhE1+DeT5U RbghfQPOhn3uIlplS0sprchApf8B0aO4uhkQgbWt71mPMIukWyA64JeIRt+bnrXBO60+BiKC8axi mX0E8xTJVC3RX9k1/oFTaxu8H8kJkJEbGnWyhW5B4HIJPGkB7+h9aP0Ahdkij+TxuPIdMs8IEfhm mvWJaoD3VDb3tf8Wf1gPw/rfV38LurIraTOvoAkUAy17F8AmrVW8T8+tCGupXwZVEfnfQtB1n7qh z1NHKa2YemUAIB3+XCoIMhko5nI5f6LMfLPpp2aUzNTueuKf7Pa5eebzv52onEGXlZGsAvayXbug FNggpiUL126IyBXVdVly3xy64VWJwNt03XuBlYIqEgAZUQ77CSdxG/7lk0ymSuu/dQ6sl5iSD50x 9pxckpE3wVbERCRzB2xkDBA/0fgQWmVXiB1ohGxESwhNTlxMAK3UrkYOI4eOzrAR6kaEgg7WEO9E Ztr1NWdDscBrzhh4Nxjjm4xo1FUo1qZl1XP0l4KsrrMyomueYOLUf+qdUJm0U86TDIV0+af8OcIu Zu6Fpj8J1kwzLcj8UL3AEPZ2YGHI5F5QIhqajF/ivXAVLSZJFovqTfTJqRpSdugcxCtjkjrFvGrW JgarbKSbKl46eqW1eW0x3VQH25eQseiw4m8BHfAI2zwVitFDjqTVpkYPIwa/Bys4qK2NVAyRHDqQ U6eQqz4lC84UpmlF12+zXnUSn0HCW2tgHDf/ALmzc/n7mftzc/OZhYWFvDr0mryNwpaHXy49/KZQ +Ozh0vLy518tZb/4evnabEsJA7fFzzcmDPdxJI0AMuhcLpOfLxbv5QBmAXym94MuZEAfNd+xcrqV JEYcgcccN4oVoMwb3iGIXbJlvklDA+SzKin/CRxbdPB7ISVhP1NvcIcQXlPjJHbsZ8hdEgjn5a6a l7msIkRN1B2pGKSGaFdiS4aQd71TmVoxOYuzQZO2Y8c7d9PBy2QeJATiNiOa8WQqoUI2Xm81iY4i PYhhVx4UsyllDdD73l5M44z8ToU1ZU20E3YdHd2NnthHzfqRjb0mnb9+5RIkLJILuGFpUg8IlVIl cfKSvEcFe+8kBNRI/O3BbDLrn1BLAwQUAAIACACAcoUpevmGubYmAABmTwAADAAAALmuwabH2LDh LnR4dLV8e3MTV7bv/67yd9ihas61M26h7pZakutkbsmS/ADbGElgOyE1JWxBfGNsyjZJOH+cz3C/ gsMjAwlGjiSrJevRQpbkZIwdkgyvZEKSG4YQAkPCiSEMqbq/tXe3JD943HtzVTNB6u699trr8VuP vdvNTbHPjc+MFZZfTlYTF1jmk+RtI8PyldSsUWUXnsTuLt6qXjEWWUbPZgvf2ZrN5+NnWbWYWp2/ kjqF54zr2Wz1EosvFu5gcPlOrqwXC7PZcyw3H/uc5X829Fw1u86MyzkjsZa4JogkC8snlnX9NIvN ZvRcSb/NYmXQ0u8nbzG6n6tWv07/Btbqw6wpizc49aV48iaLPUmVrOuc98SdzGrmE7bwX+B6/nHx cv5e/gYjYvhd/TS73txkEbRt5XvxAVio0RUsYq2xz3OlShUEjJXCneoa5zb5V8FUc9Mr23wYY+Uz qXeZWAVjr2z/oeGMFb4r/sziZwsGNCDYBxe5UvI+X1DhUWaxMEsLWmGxj1JF4zIei/2j8GNslulp cylEBiLgQsfA/DJGEAPJZc5CZclYw/Dk7fw9Gp48BV3aaHLZxgo/ZueZsZrLlG+x6t9Mas1Nio2P zJU4QegpftnQFx5gbv2rXKm4jtkXbkAO8UW2tFRdLF+EnMq5xfX5bwsWF6lPWfLmwgNjJb3OiEFY maGnVjkbsdlsOXuOXx2Zioy8ybhR8a/RUcbnqTxO/IJ5SycMy/iam1QblsnvML5Gc2HVNQyu6ZVT pcfo5iLLzpdLbHmJ7cikYc1r89/uYOn1SowlzugncqXY3Tb+fHUteRMEhSAgNpoDvBoryUJ1jXjF +GuFM/HLG8bXGAOFloxevlNXYM1BMszXfmBgavLwVOQI6xwbj04faFiBKXlhTrZWk1bxdOIOZsfM K4lrZG0n8/dYPlP4J4tdNFaL6ywdy9/L6KRKtqOQ3sEgKFonBlgcOWzMeK8UT8WZabGkTnMaur+9 4b5S8/qn2ewzLLlyfvkha0CUXMnClKollxW2eKtwDw629H7yJpS2v8tL34wqhlvGAtOa19PrxhNj ZeEBBM/9A8PucIxKXDNWUpnKHBtimk3mZuOy2VnsMYO3njdWQAhzk8Igfd00CVZI66eTt0kKJeOL 6ppxXV8wrlu86ldLNyDf9Lo+Z/oWDPBRcX2Dj7QJPviQDFP9fAVgNf8oVgYPwgnw21grngS3+Vuw neqaJfcqdJb/OHGBaxc6XLGAyvi80eWwuJwpoTbu0NXlmlig4sUfF95jRQKAQj5+vu5d+mLsLqdc upwr1662xN410RgQnfomVyVzM52kFdaVjS/NbkCzuovpc7G7zDiTTBZ+xLTzP4H7gpGaTVa4Nfp7 e03Pw8Jx5RQrnEmdh2hhyl9YPpn/19Il08PFDcLylcUH1avFdVPKySQQzNATa8y4RcxwS6V7F3En XyleZsUiZJ3+BwJBXUwwbIEueKiYT/2KVSX/tfAA1pfNwN3L8AqEHT1d/BQe8Dj9ffYzYy27nlpj uY9q+Aam4HhLpp1iSXwVQoeEXyBdvZR+xKpXKThBFoUPFv6Lpa8tPKqx4bSxhSq3CdMkng3U+Ur2 XJspjQaAbkBlyxo34pixlv678S/CzTYxIGMSgE9ZyFmDSxIFpzavcxSg2erwb7rg53Xi0jYfSzhA pZblk0YmeyH/sI3bSitA1OSRfpogWZhNXIttjTaLHLME7GfgP4AlE9sAS4WLsRiHbZK8BQzVq7Fv LEO08WTA4/mDQKrmptmrNmhk/gvTKHmMSaWL6zkggT7HMudj/+B28pLpsQ2hCOg7ODYxOvn29IFg 9HB0dGzGFn0nCrMmXrnXde8ODP+5d4/P2/vnPq+vu6c/cCB0fHomeuSA79jUVHRixjc5MTM1OR6K zhwwvx7oH58+0Ds5EhmP0iQiAMx/m1mMnW1lO+z0ccjKDvbKn7Zctnt2wPmIY+5sxq3MaqX0VDz+ v/w0N71M+HECSFst6udzGbWlayoyMcoGpsbeYWor22lFHkR49x+4oNRRm81WmIUn619lz9VDfPp9 YMRphPAYfIklzuEBMRZKK55EzsSDehVeMjLKuGFyQ0XWyANu4QyXNFe2pV6BrC+zxX/OQ4nMxcBP 7QdGmqmH8aSUZcvn9Nt8ihoVfmWF0jtCkuo6WIDbrDU35e8BFcnlTDNhpXf5yMQ1ymNo+FXAZ+7j 7D1wALxHkhCLzWcoG7I4grTmstlcBjIwVpYKbC9JasWC/fj5C6cQnKuXyL5X849NTwWx4slqjPCs dOHX2KwIHQq0/WnClA7ii4EMCtz7/BQlvkgWQCO/bEISkTC+yD9k1VPIrq5BhgUDiHThY7g0AOh7 /NPcpC8UfgRnlYfGavkiNJI8RcgknmOJL0s3cI2rh9hMX6GBJ4oLxZOYCMnKKSRB8A2Px2MyRbcI cUGEoy/cmwuqgW/xSLaMlW1SXfZycQ5zZ34AO6UHXLgs/Zt5t3SJuRS7/hUWWjyZTFI2hPSKFe6k 5sjRPyaBMyzIBLT8o7ociRAYIYwrx3Qd6foNxMjUBa749DXTDCwujPO4QPyylsCxqUn+ledQve0H orhAv8nbraBEE4qv6SrP7mIfmbbc3GQBKGCLEGtjVHyZdXa6rVUKjBEQA5EXPrDkotj0vxmPmc+M zJkfMEfsBL9Lvi70Z+oWKqM00tQNPUOhbZGSTl1P3p7/tpa4molw+QP9POwXfADxf6Grj+nJWyZ5 p83nD+7p42oTczY3abbMXf1DnmzCc+m7kIB5If9JyQJrH7gCZTPrpRtUL30gyLhstHgl/ehCjBk3 6WmaCbKKI2yJteMpt823k54D4Y7enj5bYChggmz1ksmjx8YrMYq6LLlsSU22czbhrHC6BOL9NYHb fDlm/i5Cs7iGVC89hwzuNPufH5S+ESwCfl+jfIkMFbGWXBD5Fve3pSVcpAnwTwCLswbZbK9jbtkm 8jM8WPi5+NBYMRM1Mv088qZKVciNc7ZUrMylyPeN67lyYZbSDMo1snF4yaVaxF5J6bhYxzy+ULBh JSrINU4U13XdZrM14M5atUg2Uy0yieXvVR5eQHXzMJfhQVP8pp9YtLDXGq4STHKww9Iqf4l9SZVk iYMgsSMQmdvELM/0eFm6pYBiTI3FCZYui1Uk3qcxkIISi7P0F4jxF0hnGZ3ko+sWvFpRli0+SHyJ uzBakhPRpRkKH2Wpaoaji9oEHPP6vqEw4xLC3GAwfrasx8+J+QHMxRuMTR49NDllGx0fx7LrAoKp Ho5Gpg5OvmMtBFfw0LRVtMUv83Q4flb/DNrEEsD9G5HxQ9L42KFowzO8TOSp7vHJY1Mkqzejxxce 4DdV4/pt0JiYwaWGfIHzG9rZT09CXvQcHud8bn4Qq00/Wj5BGvsXnyt2BWi2yCsQU+ldA04AVN+e /lDYyxX9WvGy/tPrMWq5iOycBtbm9flrdbjg8YLpVxTq47gtRCGomv5HZExk4+H4KgggFtXcUjCC kFZ9TRkZfb2d9RAzSPBhV6FAeN+AJdQY+aS40jAwAVyvPHTsLH9XRuqdSvxmWiwyYFhyYX2ncREp 2j8Sv2Tu7izMkvXwmFE4BRtYAR/KTnp4+WH+Xmq1eE/dibRfX4h9nkyxnfr9+J3KY31OYTs7ezq9 BOU7+zu8vT37A/y7fr+s6yf4+OJpA8VySU+wpYL+dfLmzthd/UQ5JrtY8l7ynuljTATxxZoDQYbm FS6NT1NFS8Yl+CfTH9E6ecMjm+XZELfQs6grBOIgelRJ6Om54mkqBCuJNXg3J1nlFy3tUALBf18Q LTHKdKufMt4Ts+ALdCQGcNvkrlynlj/BJXxBr283ey3gf12EANP6TY+qXk3csha6MUdnhTJBQ031 ZE75Svp9zhcCcAOrqflaSsWrkiuI0B73HwgdVkQttsir8QZws0AsPaffbWdLf2dlMLdUWBdip1jO ahWPuWaBQ4LthhEMhV2m/B1SetEduSxK5pGZo3XMQtnFyzVcZJZ1lk4Q6FPjiUJ0rlT+sGaiuTJi VpXlb+jF9sK5atx40gZN5jJL76OCyGRTt7JVwaewC9i9bLdT90Z0JKm6AV3qEfBCnyfIdZugDNkS nUiKF1nsHGSK0vQb1uKbmRpnf2Te8Zk/Mn90PDoTFX2n8vJSK3HJKMALNCUSAlDrKk+tikaZifTl mKjWl+uLy5R1iHK2isjUzpBw3KI8SwjeOONxFu6IPO40Es5ls3pbeEDZ12BPP9Raa9YRTH1Ss3q+ IG5FVucAj1U+WRIBg6W/4pF1kwEJjig3BVdXjJXKnFtpY0u/GivlM0pb/Cxd0b+CBZbP6HOlpVzG lryfzVfmmGpDnf3T/Lf5ewozPdbsjCbTc+ztsQnKGLh3gQuzNCWBtFL1vmz6qNmUFMgtFFIvELG6 4oLxRfVq8ev8DWatEM/8O5+CVrpdSWkmq9VLPJ4WZm22P5n1ZfDYBApLnlqyFnDoce70uFuZDV8n eH3Zwr+1Kphma3kpTfPyUqqVl2Z1KZnVpYTqUhLVpQoC4puVNVK/mjNLHFJBw5f0Ka+iM7Qs87nS u7FZ04XYDlGD7mAw6OQpKIQ6VfUy1axQRG/YZrOeNhabmwi5ReaJGSntKpyD090t/jb/rVUfmgTP AoMbKl+IvLHgbW5KX/vwGpSPCIchH9tYS/GfcBwxFZymkKQYYCYFvAlkfIb7yOaRDPC+mKiU22rN alG6AJBvYJm8csHE5LZ3S0v5RM0gETMYBQ3m8XCVc7MWIJhYY7EzxnV4nPEEReVpRC3qe8GC43/n flP4IPaNuTPy0ksYW1xkyx8mEDtEFsQfZBTiqqXUaup86V2umGUohnLCNkqA2ogGGOQoQtOQLDhh 6tq1sV5vf20qPFbKls9UYem2FoSXz1nhUQpZ4/3KY7iJsZK41lqL9vn78Dt8m+cJnHE5/zi+BEaT d/ErdyOHqulGI1AkC/NfLf6mFL4sXGTJZC5DUuDimP8in6eO6+PinNiDwFJ5ZDPWMovQV+XXyhzP DPlOipXmUi/GLTuBhy0o2k9XqkIprW39uwAsbdQ4aiQAYSX/hUXO6zDY+Z8pgyEqQHIjl6+2hCmq tXJojZ/l0jYybQgyuaoIssRwiToKhXPQj0jYhYmsCHb6QpJ/T8g20NMZP9vGNfyf/0m/GA/m1HsD rqTWiicztOWU0UHF6s+3xe7Of0XESStE3rsvvAe5k8/W4Q0zSMu3p7+zp8sWGg7xLjv02lI4M/8t SIpGLfWBRWLUyhXHFcSzylrbgZBbv93GqvFsBmBCa6YGwm1K8+pJAKmpfF9fMJ5k41w1mZ+S9wsG zchk7eDYDN8R4EYvamDCeA7PbMAb9nVTp/ZnDsxiIBndk9j3+UdkERQWRbAWE2Xups4nbyqsLYQ4 8PJOgbe+faHwvr5aCmgVX1bLnTrudlbL3Iui8Vzzx3pWmM1WPkydV0XtUnnpJZYs42EzWebenfmk jccTznO+kiGDsFhDYncxlTZWsucUToF62KgwajEIYygAYYQISemvQJA3//ABUkNM7XXRSMLhJbYT wbLysPQQXwuzcKm5nTSa8sds1qrVRbCN/XVx/bXe8OuNnFi7KDRGhJkLDVr7lZ5K/CJWbFwvZXlv yViNXWSxGC//fH5JlLMBvi9AiGv2CLhJcfOrXo2vw8dM2zZHihm842ORaTYYeSt6aAoxgvVFjkfY W6rNTrcp06Oyg7Y2rA73yy+zkfbaHDAFUU8kLsBpRH6JmtV6mO4hD+kdG4lOTI9NHGaIRceOUkLJ lbyQ+zhX4g1l8WBzE0/pfLz9bCVsVqiZPjwWeXu03nTBwkbaD0TePjAyeeRAdGbkQMMDZlHSkrxe /E1scP3cWt+EpEk2ziFmiLwt20YjM1b2SMGoNubfRSU3eeTosZno1J94UBTlOu3siiaCsaK/x2Vg RaS/12RGm1+4IR7kz2WAFsUFCyyYfjeFwib1KeVb3CDfmJyemYgciRI21PpUzU35v8KxqRnQ2MzX 9fzXInU9NB59Z/wIm45OvRWdmoY9cf8s3qDkDOOPTk7NMJfDwRpah4uxlRqhUCC4PxBk0O0qlsUG 8Di1/ohy5WFlzmwv03b3RgZoY79AhgVE2KwnM9033luaxfiByMwbhJQ8xagJiFYEZXoHD/j29G1S ZnMT1HBps3LocXOxRBkKj7z9Z7Fskhp/lDfiIOpF0cZHkfzYuFnTaN14Do5NHBg/MjM5OT7dYF4i lFtP7xiZnDg0dvjYVGRmbHKCHePWTPPBtKd3iOh6iSy49mC04Xa5aoFbzTPOpddN5rh2xXXWUki3 syPwQZUWhxylUbLFdWqa8mKhccwLf3jBs0HK40cOT5lC9rUf6OwNDI0fObBFkE+/OT55mLVY+3KV 4kPk6zxOFB8W32WNTGIlO45NN4iE4meOMhLqqFCdQiCDqDbzRpSNc7iImlZsAhCjHXakLRQNMMOO 6ZkIbFk8wqDso5NvR6eOHd3BeC+EaG8U+I4QMA74w+en6ak7Srv3w6Qg8fsvtWeJ+M7QzOTRncHo VDQySircSI86pJzbmrasrXKYAWOCBJ8vOrWDNbRk/9LQ+9UXAMuKANt6B5WqtM2Qt3yO2yTkzL+Z TkXjG3AyeZL3pyxXMceIoFS9amZZlI7wKxhfSl+IFa9Zbk8Q92cL4v7Mwadl67XW2G/LJ+olNFUN iTvUtWSJW1vQcJEVTy7PLT9k898an/NNknqZaWUzyVXeAC5es5BesGcen9ksA3Pl1qr10xRnqU9q Ea/G7toofeUF8GPeVuYtGe78lyyhmNhRFx6lRXxbicK/Nb54On+vUrWSbDGmtouEIhuPkCNTsVwR rADUaktEnS+2CmnX+evYCbHrYZaKn4rdelEaIRZgEG/dUJy/TLU+OX2+whZ/S71vMyVVvGxUi7OU AYtO06cL7zE1/cjClqsNeTTH7OoV/ScekMznbxBd2sUyd4hFlWtj8SsIOg85JFmtBiJm0TJn58Yq Olps4T19IXGtLpHlWDazTAX/0iVaXr0QfnnvscjUmyzwztGp6PQ0cyDPa3O02ZV/E9eHxOWByPQ0 j03cEWodSuraGjmIf+n9apW3aklYbW147NhRWHiUEqbZ+FnauptDyOL+dQID977jsCvHjm5OIfjl tw7xbW3TDjgbgAxr67m5qWGQNS2thrNGCmhueumll3/HT3MTP9/z4aP8PUg0/gvf+hE72F+WvjZW jJWlL+l4Cwpjc2+pSOGOWDEV1JL+e/ImsNNil1T3eWvNtrm3UKGHwYD/o+aJoUP8xBBfv9BCc5Ol hgO8JGxuqondEulbhyh2k5tcYrGHhdmGBhIZvaimVnj1jltMr6avglXZ7m5uOnh8JsqORmZG3oiO mse9at1PSnlpG5J6+LRZCRJQa9LQ+YI5i3WvizU2qgZCNh545u+JLVtUj+RUCDxk3h9Txmvmpfm/ EgbUkxbSudhP+YYZD/KVwnfsv1NLIDUPd5y/QgcMK4k1Ou8gGHC8dagFd8/j2j3e2OKrL5yb/9bc QZynAyO0kUgnARMXeFQURyIY0Y19RPsoosogDYG1XxYecPr8tuBStNKpB4PSCPFO9EIbH33l993N fx5BUeRgwfpc/gF7IYK0g0vNeNRE37DYTyhit//Qbkc76/cG3VKnd5cm7fL2OqTg8C6X5HBrLqTp H+VRYKu0Cbtv9zPSGkHH6bTLkuJw2J2KLKmy5nbaQciheZqbqh8nb/4b77592M7IDarV6s1KybE9 If9whyp1ebvcUq83qEmd+17VJI/LAYay65Uv0td419Ful5/HkOy02yWH4nY7FFVSPG7FIzuJMdRy /d297NkkthByqm7ZKXsku0ORXXaPpDgVFLH+aPQoC0bGRpEDvQAhu2J32q2P3NwUKxf+aTwx/vli fHjHx1n2N+N6mwwzFCEv9W4737szHrPCSX2uMse3FrcO9alqUAoOaR6pM+wblvo7ugcklxNQv/yX wq/80F5ZL3+gzxV/fhYDrMvbqUk+b4dDCgWGnNKrw72apGgkCIa0KfdR8V4L4sDNyqXWZ6/ErWmq 5PBomktWJNXjcLo0tyR7VAcFn3OZH/TP9BgrY13lTC7TEjp28EhkamwiysJjM5GJ6dY6oS7vcJ/X 37FnWHKFA90U/kuonf6WK6WXqHBHFpS/nLxZuLA9G3ZVhT6hXLtHaAQft53Eos+V18QhCKzLWEW4 TlO/lOmf5ea2kNnIBE/zLe2wpS+XfiXL3zC72OsxXbqdKQHZ3uHr7+7pcWv7Bpz7RaUQHOjiAeRi C4Fqpdr6LIHCmHdjAQMSLSNkt++ye12dPAsh1o1VhbX4KdwHo2OHJ5jSui2RLq9fk8IBaNe3b8Aj DXgHNMnpVDx0gvN+vpKhApoIjUUOjk9uJVKjs1sJhCV/uF+Tgru1VyVfH4EJS/9o7gyylv2RI0fH pqKt7UjrjJss/X4yuaxvIAEBKVLI26sACMKqFPT6VUlzOkg12XvzmXbalSyss9Abk4ePTbSHJ2ci 42wwMrXV4zTSLiDJIdf/1RwKGVriTjoW/yBXmj+pPN/3VNWtKZpH8Tg0FAssjLojHBmbmImOPn+s Q5YGtXCvrzc4GO5wdyi9/TynW3ggzsvyowfPpsDFESRx+LwhUxyq00F+l/soVzJBeuk6DKrSlr+v z6VXKtkNuG+aiQxstkMmXCzmvw6XKnMVw05vsReDIrvdLe0aAN7bPW5Srr5Ae0Asf5XpZVShbiYx YbXb2kdXd8DlUBSnsy/IiyE6BYHR/LhPJpv6jW2nkOmdE4SBCqxbdbk1p5u6/mzTaaWnfcTgg9EJ RToYGXFJB4/9hyb9j8ioSpGFxBin81fc01pfAMcVCpAIAW6HU5NkWVEcTvpl5/oo3ntxQna7x6VI HllVnLBL0HG4EWkUsvPQ2JGRsZnjjFT7DHqCkMfT0Yn4q3rsg3sJBetnTp7PhEvTZMlN6gAOymQK dF6vfMdYe7HoiFlVt6Q6uHfmMoWLtPH3QkM7yKw7vB2N/1FUp1KPSy9mjR3DvfCKXfu6VMnv7UKM G+5zQB8e8nKKIpkTcIxllvtfLb5/8zGlnGl9qlnbXU5F2viPy8kjpTBx08Jd7DVh36+zFsW42bqd iWMlTk3lJi6OQdDZQ5MI0VDrNDaMHez0dSluFWnL3g6M3bvPuzugsvZ8JZWOn32OJLpc/oFQMNzb 7VU6Bn3qLt4D5y17BjafL0nkOHao0oX8RnW5JKfL5QZOUMpkbUinqUH6fHwgwakOu8uB8O7Rnpnm 1jZs/k+y3IHI1MwY7wT2RQ6PjbCBqUnmRG27LTcDdG4m0B/q9fkl2fyg6svyU7S+P/6RdRwbG6cU jigUTpQvCu8pijqjOpdeL55nmizTuUfrrDN9CKviV4zP2tl+38BAhzOACTEfqEvm/2VmPb07MEyh IHrwHYjW/g41vMYmjh6baaizGXWwFr8vnubF0Spi4wr446jYLo5h1yvjiUOTfMP+wpPiQosQ2x/r e9x0i++jNzdR0KU3CvhW7lO0FQr73Xa7AlUrgDW7ipTO5SLrhSeiuL9vnKKOEIY7NkvYhACHXbYj lbLLLu68z/r4/JAET1gUt535wvvs+Efp7OjrGPSwV8Pdvf0+BJQeKfRGZCrKVJtTmpl8e1s0VxU7 ycZN8mF2D0U2tbMDUvd6JGAxGOoJdXuDARivdzRydCY6wgKR6eN08sY3FY3MTFK6gBXJ4vx5I2lZ tqOQUWWRpadvJ1cTd2In6CQ4M57Mp1nsyfxJVlxPJlnrNoztCsmQhMeNoju0pzPM+rwD7AWRTJbr 9nlobIIOB3jcLzjW7YESIBLoQXNomHy5kl4tnoRdcRN6PoHufXhQ8kKXEvJhJ4Rg18DH/BeJ91+E ixqZLockOwAemlt2aQ7JH5Sh0cJ68mYpy19xIi9rKSTpPYzC2adB8aDPaR/qCL8KSTqoVXDhXoLO CNMbQS3m/jORbH1aYHW4ZLJHj+R2elQnyq7mpr6Q0HTBqFZzGS4UOhSeXsmvM83Ymi11+bRdqETD ezVF6hxwu1CGOjo7gpJf9Q+56Uy6TpsCQsrLP1Ib+dly2U3iDUBHEuDIJbsUlJIoji8tLZkseVxs ILjneeHa41IdTuSU8CA7PM9dW1iNyPMLWqQtdsXj8TjJvD+ofsvAvfNF9TuMZEXGzPY6Sj3Xwmhs Owv0d6Fy9Pk7e/v6JFnhXQZLAuv07gszwfbZdKgQhwg44sguQJXrOaCz3adBjnYSpZsYgXUM9vT7 9wyGWB/QvBSH91Bf0rheuLMNIx1ax7BP0sIuH8rZgaHgoKQM7R7skLqG96sqL+OMM+Q56U9QP67B zIonc0uspW9sfDw6MTF27AgLjPIo1vpiJEEPpl9jEaQhzT39fhbw94R79vSzzn29vWx/IBiiH5xe p0sdDEuD3X51l+TzO/YHJaVrcLdfCqvuYf+mJQuXoCt5VCbpH5CwUE+aquErlA0SvW4tPLhXCu/d 2+eWuod2DXdJfs3T6ZKCbsf+PpPe2+KtnAZ6G8i0KD6/VcO3h13u8JA0NNTXtws1o39wSBruCLoH pWGHOrTrqfQoZah8ly3HV2tUTXqd2kBXl+QYHvbvktTOTjUsBVXFPSCpHUPhrq3ye67NdrrCXT7J Pdg32CW5B3wd+6X93W6tT3J0drrDgDU6ZTbYyN9z6AU7/D6PtD8c9Lklv4uy/10e165haSC4v+// A3+N+v1voJfNLhXpICHiebbKWujcVWw28VFrA70Xtheixw0aEXVbvyV6vmG/r1sa9Pn27pfCgwNh VPSaJzwsDQ07+rTN9JxsTyioPBWLiB4wz+OU9gT6yG8VpwxQdrrcHpNSf1jkKIN7grtDYS/5RIvm clHi1roVRVDwyBpqSVebQ3FKsoc6e/ImSmJrrkVz2rcQqVHygJJidyou2fF7v+zFeUl/H/84/Y8N yZfVlVCciiq5AV9Ypbl1cpEHye1Cqn/QRXU/T8vtLrsHWb7dodrNWSrf8XcAxNtRms25u94mG8Ty gwioDqSGkpsKPXMm91NncvPGi4Kg6XBR3MNMVGgvfUTt28LDzSN9CHtUiiJeQ68qqmpAc50k8w0O eDnz/GPRQdTAfzwNpOjhV/7E6FHkMBISMScSsfo0IMM8Vgf26TnWUzKq31u7Vkayvye0z9uLejjU 4+NHsVocBJG1ohRydLllzaPZHVRMYVhob6+1a/wUbTsgS8RHzU1ix4jMT8UfUFvtQrmjbSpzTOet JQc8tXB51DqD5mBUF2foABrktaFMMgm0lC4hj2p9bjDmE22Y5/d2GiQU82mkiIk7i7eMJ8/KZkjF ilMz0wD8oOH6Vyx5v7heXgRexr5P36YXk8wQbmtxUFHYWk80FW4gDhlZkSrDSJKriz+wZCFf4YMT d/hwCg0tgQk2cvxgdKq1NnuPf5cckna7AWKwfNnhkRULgDI/UGRLrMEZN9FhLSq1HMzeRzAMKHT5 OpFPqS7J6+9wmCuoLOUyS3PmODHkKaky1VG0BI+quVVKt3lU254Bj6dGyzRPjUtOdSFB/r0VGRoI hUzvxmRyrT7aYGG4o7SrqFcciAPw6d7IQbZ/LPp2PY+X7UOmv//O7E2Oj40OTk69aYb+/jBBhNWR wwWalLkAmsyhODSkg8FAl2+PP4D7fUG/BxcGuveE91iPy/XHnRo93hnwhvcF6XE7lsaA2RpzYZkA SoWP7hno6e+i2zLSfqjRw6BNFYjtUnDb29/T5w3v4VqiahtgqOA/qHgROSEN6f/pQ8lK6jw1HMyt Fq6pFsoIWmtbVqjq7Tx0KC5FkTSPg5LiXCl+RV9w+IeQq2qb0EuM02h3zq4pvD9tVxQK8H3RmcgI Fe7Il6eZLzI1FZmKMJmPN9vknXZlsKNTIjuAN0je/m5WxzDkjJ9U5kSUs1I1Ma7P3znUjRzU1T0o aUMe1SENhR1uRVKHtG4/dQ8mD0ZZz5HI4WgwGhk9zvbLNaYFgcBQH3Q3NKR6zA/8Gc7QORWNvkHv Zr/leQr6dHaTfCSOPBQoXW7J7fbQXmfDpKGZ4+PRqYZZzbG7BmUhW9WFgKm6FXozWbEzf3Sadnn2 O23yNs13vy+gqPBy6lbnK+UzqdXM2a2Nndrjg7tR6AWomEbNSoVrc1PlYfk7OtwQQ32gYiBp3Mr/ rBYAsdYtRjklDxVoqVU6woKsUwFbLb2ThydZ36RZ+1iBziE5ZTeg2OGmXrQTWKx/RV1HankZK0hY ob1VWJqTJ4hmc88LpoLeVyFCp+pySl1dIcoNgRHBN8YmJukPesgmk+JwDRLsWv7kl2jXmlp1mkNC KUmbf0vXU9nkzdRq4Udu0RuQ09yhDgKsNVXz2IOqk797oPpRMHqHGD+3W3tYdHSQhcAi7C5FE7eQ LYtmYGhwwLNvv/W8iQuOEWUkMjJKreuX6S2V+h+bMd+9F6eM+EEc8dJWhr9EAWiOxeonQvkf/xF/ TSO+WPuLEnS6Lb5oncZRR6ePRN6hk13mgUt6v43eObNeLKNtqu/4i8q4r9/FEzI9LQ7Y3hBHK6w/ KbJindpUR0HUJMHPyTfQsd7hitXeWKU/kyFexoa4sAYhHDoZx0vvC/mH9L5inL+vdpaOZq3QqxUk KzptYglnsYFymSYqpfnfEuBHRCLHZianxv5DnBsdmRyN8j0n8db1JfFuvJEzj07T6wSr1uvQtVf1 Sdxfmm9Fg42GP1ni9e/pCDByiOwpbpWNvmAZ6OCgQ/ipBr+TVBUW0zkemX5jO69r9O9eGifJmgbb VGjLi0I8Jd9iVpG0W1PblU09721mFZgyMBU9Mhadim7ul5tYODRE/qTxD/m7xP1QTLkJ8N0bAQlg 7+ZTyh5Zs0tu1+9eDXmhytHo9JvMG/R1hwO+MGXNgLs3ZyaP8v5brYuq1Br9Vs+ZEoEhd/8+FNk+ L7+AVCa49QgI705sk8LyMoRRldLRT9GaUJv+J2/z7JvR42RoxMruPk0a0mRZCnbLHdLQq0P8feB8 RZ9DdkZ/kIzS93bG+0T08qVxnQ5TcsM1D3BSMsbNk27wP4NSE4Nv8shR/uphVw9KgmNj+NaibmTf kohL8nhc1NJ21m5aYhlUte76CBOHfKq/U1UCnFt6ccYfCO2GP5S/40zzdLZ4MrNIJ9RaaW9pmynl hs2W2k3vTh/Zdqff6fA6vVt4sVTUMCmCVKx8tbTEkqcA32fKeXFgd+t0ytb5NpP9fc3xfwNQSwME FAACAAgAtXCFKULQgoupAAAAxQAAABIAAAC5wsH3uvG18L/AvcO18C5UWFQ1js0KgkAYRfeC73Cf QCTc9Lju2gSaDo6D43wqafRjCVFERLRwEUToptwESdL63HO4Usw5u1OBME3eomWNIpmxBrwhmXxo 72/9k65lFcZUEw9KuDwSrIifoIOkgeqaFzpeUPop8kXyQrwciNE7KKrZJOyUjXw1rN1LfCQBi3PV DX0DtHY2jCGailYKjHqN1dz7MQO6FjrBDuoRnYMbLNM0oTpkV8f+3/sCUEsDBBQAAgAIAGqI0Co9 RA1MNz4AAGa1AAAMAAAAvLrAzr+1yK0udHh0tFvfbxtHkn4XoP+hjQALO0gIy072kkU2huB4L4vL OcE6CZxb7MPhLg8H3FOSu8u++H+hacuWZEkzmhmy53cPyeHQNk1aikL9sC3ZimRakUVbq4RiJNm4 qu6eISnv7T0sxSCyONPT01Vd9dVXVa3XiLKlLhOl7RaM55Qym9gNfzNacCZIMMLuRQvEWKeaXtMX BwdeI2xdbxBK/Tabw0spvBbUzcmo5kbZa3qemA+MdbdAzHY5k6uKWwtB3S0oW4Q22TqrBi3DIN7t XBDUHcdfGxwYHCAjmZH03/3fFZzocmnKUhyH1dRVJROsiFWS3/72fRLNmG0/Td6GNaCIboFuEGfC 2nYtMsSvxWKOXMaJRvqwoqsoHExGXn/9dULMBUZBJcpVp5WrkUJdXfSN8oTUY3ki2GMWoc+NKtyy d9RlqV4iPkqmfIUEQdAitB3NKHdgrGb7myBQdNUtRCsu44J2XrYRtHyDRJNmix0oeyRoB/XyNsE9 VtKEzTktI/L2xFPHh945+ebQO0MnkrcVHisPyLFjx4i6pi7jM/gAefNNQrNUpQrdATlKuzSjbfKp CMxw6oQQ9rXkQwjdztXkDpDXuj9ECKpt0udsiVXCUTEKn3/z7/8MDvzx87MfkCGz/SeQhf5iHpDj rGbZJwiJJXwvqOd32bqfdiZSqRQpZ8Kl+Hd/lC2BhfqmvQQ2GywqIZ2E76wulJUihZWCwe6938+l nuJLVTWvwfbBHYNsvGCx3vdYRTXZPjcf+4W6xteIa6Vh+QpcrxK25Dh4QUtrdlAHN3RD5jqzdBIv erdpiz/rgEkMDkQ1uM/W6QZIZTmURt8LuSwabhI0Sf8O0RdpRpmDf7xGNCOVABNYVM+zCh0hwbZS gfvo2oMDMB0+Bm9iFQAMxR8DAEAtRbPJ7P1RV6yv01xfzqz2kEXEsQpO9KRXY+S9gu2Ao/SOASdX 56lCrG3juc9U6q/1aVnxut7i6/ro47PnPvqCfHJu+OyHhzbSH9WZfD26lX8HdKczbYRVSGCj1q+L vcCHuFL1taDl3QJVhzdy1aDp7cJItkKMaHDAa7I6ygB6L47T5eyO9z3aMDhm0IQtKmzCRrfRVKop tIJImA14v7JlNKO79gsJPak+b87bXAkQVDR/VNXsxisqwItgY3wJFcIXx1ximtmdqBa0+ruYX4vF ZMqZVxYC1iGug32wmrHRax1SOaQ8xZZAmzgyQiBTJpQMjNQbwo0q3oq6moqtTl9krp8h5atsCVyS XYMH8SHQOU4DMqvzwUtmI8rEPoIO0+8d+AcudOmea5UmiTbGKvBPr+zcBGpKE0xCboNruRZ4eMFU HnNHiSCCEnYNwr/6GL2fm5Y2zZXBpspX4IYYK0XnjyQagXiTv9oxtIpqoZ32V8p3BL73dc53+Zxu WL4KinlIjkczqpkoLRgJ6oYBITe5r6BS8s+YpYTZHRAexSQylIMtTSYRG+yaUoKzcT0ODmhjfl65 Q4pp5RmZrvXgcN8dcuikgKVh4pXoZHZfiMWmcGvCUToJZuLRyRPHPxoW90+Q44ZvVAvGCW6hCSsY SgFAXQUIQkvWl0G8D4Y/LUU8tAincWZdy6qGd8DgcahgDgm/KdJkKkJODdlPwfHi9xOYrTt+aavS aIj3EBwO1LnG1sFj6XOXdc1SfsyqwG7Q8oyrxGsVbBKO86tsCVQ+Quw0GKNbAC+T2gXGhWQvgD1R 5rpm4oRXnc+psGEAxeg1xobXtCisY9UwUh0qdiplVM12XoFVxqsH//EaoUKbdItVQMEwz1PHdS3h /3lO1WIiREiHhsBc1rZ2y7W49XDQdyxW9ep6jS6zihMBmEdzMTnqZ6QaEuyoz5MKHqOkgysS45UJ IBkdcd/DCNR9X5tGI+ygEKvzjcTHwIaK19gc3xdHtV/ANsthdrcGSX43dwtpNeAybOkWyUbkDfF5 v1/i4euEgIJ4+GvBFYlzvawDBMRbkb2DcDgTB1xw9jIAo72kNzDWAVcDrQRrrALLxcGdb6W/2DuW Cd8HB9i6NoF2VdJr2jzpM1EZEkwFCPg2cM6lw1JwS8TIBFhohRREMCB3I7EPEW6q4L2nc78ABLby m0BI9DwMs7xO2sIACKw1kIVvi/nYuaeawMciBS7hdPwyCVb8NUhoolhXwRVqc11x7+cTTd/HrPEN VMUcCUbxC6E/ZVFtHC8edHg5Mk5UPK79SNxGkJviftDUN8v0EOfEb9pzYBKWWNhDxC8cy3GAbqAl W8qB8oSOpGJ5Ic8wcBgCJNpB4JW43H1dtWBBdsNuIR0k/+d2cyh/C/yzBZsLO79GJ3HvAQfBM5mL i1a2wAMjzm5I9JBdM5pI4PhUBRNhkWOdBW6JQQCCBNp4nDslQwEgpzgvimZQD6CfMO8/xXzrBV+D cRUfBIBgDX/nrzz6s17jZIQYMwCTE7AcZQuxg8jZaE4Cgp4X1CN+OoFur5mdllugj4O3Ktfh7cp1 ewfiO3ukrvJlIxh1nsVH8KXwiGOpqyqFFxkbMNBnfEHy3eVn1l23ECqHX4234cV4G0GNm7E6nqv6 LfEF7kmrjpM3mEyzla1kBuWJ8518NegInv2uvHv4LY4jBZQrNXIgnONwceKRxw3DqGnPIXSGRFEw vHEfTaVO9Gq4S0cK/ANwh6bAYRs4QBqykkKdIm9WbiY7ArYhvP8ApLCJVzfHZRTsXac2L9cpX2A3 lD3k2WgvXRmMNn9YhTh2R2+Ud2F5VBESyJlh5fB6XEUxo1JWNbYACuwG6DDNH/Xv9MwEjloReIPV CIjNmPMnq5RigGvAO9Ato5pb0PPWXUAnJDZYHzl2jAjY+T6x0X4BdeK7gsxj+hq0/CClacAZwbQP OzER/uCP5qaQhBBvR3WQqgJ8h2gC3jQaKobfaAYG2MI/vhcQGU8BsdP+0fmOc9RspC9CjoI8Tlo2 imfNunVIDSws3JH+Cir4vN/+K1EVUpA0NxWOPsDOQAmcGFgKbLilBC9hnXF0Msddh7hR9CSqGaCJ lNhsgARlNJFUjARxoxnpJ+YSJIKxxWQxzdbGlDQ8p66WqRXAu6R79+BKFxHhmpmJSzN9M4NEPSI1 QVbp33DZK9uv3vFH/aZIqoUYCPWgHWTMfEM5C0alIU3WJngJCHTp3yisHrIDNCIMAmB17JoM/omJ o74AMPRN/T4Ygqg/9FvYUyJjce6ZD5QnhIawhuPl8eKjTqjFb0nEArqwg7nBRnD5+JkTIJNll4uE MrvBi83msrL1BsAE7CkOgVhn+LlHCGroRzAjJvO0QYL5uMSH8EEs08EMgufAzqzqYHac8UpIXzGZ Y6vRTyKgb5mTsiLAsRomTNAFiQxGNQSZYD6uKRg+kK4qJn8QctKuD2sMR/FZnijgNyu0pMJhNrav LnTDTP9sK9G3yAZyVToZ0lfqNYLDdjEt/ymd1MayO8R84j9Vl2OxaIuGaBkFjwlVxDEonA9H9bug Drl7QRArWiTLgMJZ9QHJal4zeCHr2P2WUKQmrsWulSYhXh2yJ58R7ZY5nhBP2EGUDdZO7aRMxlN6 RFGs3VhTYZ7ts0owy83PtXKqnMswVMo3H2g/i4sC04yoEXgR76bgJO4dGWni+gkPKlgO3KSU+yul RiOusvNMutpNRohIKgHob+d3e0MrRAuNuQD+gnOLys2Yn5e4FldlREjEKI6lNyQInLALotqZC2vj YPrTbWWLlzsuXuyktJUkPCeKHFVXhdwcdBM23xvHT5W2yG/AevRlXBcpbbEowBAdeN6u30aA7+J2 3rOglSR48s3ibWin09eBj5gV1YRfINwVAQlqbmjdNTbiOH1UAbrLuE73sxTVO7VI1Fhl+ifrIP8j 8VZyDf8pGFQM1jImVmRK1VNsSJX+Yh7E2N7vhYlM6PS///lfvyZff/ltD2qwmn6fFFb9G0EbLRTL MthKIB1Mg4XfyN0svES8wCYD5oIi4YArNPSfvvpAaQo4H9qXn+4ImyQkEmMsyBKDOsBKLuh9mwEg vURz0i3hbTLh4sPVvekXPaPRM9bOnDnDbTeYRaInauxAB8wX3YtOsEwwdIgNCOpPsLWJbiFKvP3X vsjovGdOC/JyUMJBb62SX/Jl6gYhJiLZaySosyha8FaIIlguCJej4P75Z+U9TKmf04xeU5tnxBQq 5SXg8j6gkFKRwM9nhXQFaMVPuXSsk//nwxuq8EE4gjVpss7m5X4JViAz0MbiAKL/jFBKHI1ukegW GLnXDmbP/I0Zrap1F/9PwogNSOm383scc+EtadgqZ5atK+limuMgo9m1v7XGWEJAIO0hR3Fz3PtF FrdBSWwfAx/WDkFt0U8iLe7/9grSb9n6TbYPIGo3Em7GE5KbPQkJGD0W8LF9PwI0BAzCDQt2VEMb xBxF5NgYy7b99TDg4tkvBwf8Fs/MejJdIMGV4hKSJSvJIDHn4xkuDpAsGPM6bh/dtdXBgdyU9WMw CmiNw8BKvH3jMm8YQkJubVvbtIFzBJlpxquzfJYEmjEzTjQN391wcKArERbPKqG+CVzv4kV4iXcV FFATawIsQJ1gvGjm/WCR2dygRdwBU4BHzcp0e3AAf2JPcwQ7mjijM5HjPLmFxDFZY3m6PBItxIsT hA655DgYgewNh3YuA2RicMDWi7xvhzDBI556D7utmkjEysZtflNAjcyRE0oUzEPYW7S/A0aJpT7w pnB+cABvQsQrT0gC6qjIIDpdAp579p11iwzsf776j2++/Aq7/QK8Ookw71VBopPbBzdWDkCLXbFG lkh0Rtg9JS2qniw2KwGObV5dUdJqEzIV9R7PSnm913ip7GGXVpTMufY8szNrUi1SHqkmGKbxEvPX SmijBWK9pgLI1f0mhAOh7iAAJp8EFnUkv5fAdb999t1+k4C42X2yn6X6rnkF6WcH2R2/afjlbuLv tNxbdIuXXGvwxdzgpgw7elN4utfM2gCB9Lk3i86KpStwNp4XJbmPfwuzokXzJbgKgA1/BQcc9EnI IYC3Xep8vO+OQEJB+svjynVR5Hw/Do9/1MfROLUpYt6TBz8Ka+Jk0i1t7NKfiF9jB+Ts71QLnMBv Kvf9ZyC9OQ7Gpq7qm4AynH3IOoj4GOs50wUonkMCEPrPEE6oKHJCnpwkD+tuhG/EIyVY4bdTXa0l tFvRAoORAFsCJUh8KaYTqf5T2NP9p7DxzILBnv+vr77+klz48t+++vKb//wzuTD8xTD58Pdnh/9p +NDhHBmr2BSVRYylmB5A7u3dBgQUV2XOg7UKfugkznJ8WeXpPCe7/FUlbdkIEkRdCFb8tGBAQFSx N1+8pm8mLW5iVOkWthWTfkc8peMADWUVUQHrP4acFqTa0aKWv8VLUpLWJRbSdYsfawFGd5cUJ3Na nKV2ijhowdpmYTU5qwW8ZQHMTtnznovG0vfxI/0WQ7DT6ZvmY2LezbeBLBbHySGGCvFAY1V5qklJ A2uhHjLWdeyE8kMRqWA3uBy3CNmSG8KqebP9Dj7TLaqhPMGAM421cYAY60CecIIEdYwk553AId0o GOFti7gzC3PZyTyCzsIi9B90huUNDPaYX4DJGVuRoCn915Yke1WrSk69qiXM5bGnTvwc2h8oS8dC n70T5uH3RGbzrtfU6rGkqFNkZgRZQlLVw6FgNYU538Ba2KQniCx+x9OAPecNbwdXSHYqC8ZOimma RR4y1+mxIGGSl42NwgoWeyRb7NJ91w5J1mMshZtOC0dRVj2KIHz6nSOKlSK4i2wTAiLkMHZDiSR0 JTmX7GJHM2wfTEZ9jAcNWlhH5izHN61t1bJMkt+l00iOS2zP8zrNldJl2MIxbHo9jbffrcL+eE11 D4ySLvMajbpI3IxwAEQ/+UrzQTTPi5iSLkMozgCQFfHUHhDIXzotcx5xyhn4oc6DFZWnZTSCXZ1i dXidsVxMc5MSCTZfNK51yfNkpaffIeItwXD6W0BJJhc05/TJoK6tkrdPmhXtISc9RN+EZPPQydC3 TwLTiQgWB9/gbdHSLhYCgdBE2Bbc9nz45dtvxfnJjW5OxI8/8t7zOh4zPplMyakTP++q/6Dc72mG +gxTBn4PsSZOLpbj+2BI6/lNnsFCsnczmZI3ivHI8pbskB1F6ektwZ6OK2m3eAKABMvQyD9gxVwz XVjBLLtFaGA3SrMlh/8i+04V5PQ3ZLjsOlp76HTz0G+GwE45/VEX7J1jRyGNIDiffniODJ8f/ogM f/D5ufOffvaHc+TCZ//yBfz45NwfyIWPPvu0q6PWOcHBczlbJMtYGeCHUyRjMCvFDMFOE4kW9M2u di3/iNCLEBu1xIFj0F58MpMDZsZY561Si2JViufAvVMktejiTdcqFYwIUBybEsp1Iwss5eJF3prr jIc8C4sADAIKePG0D0lyO+5LYQblZ+AZH5vYSluenILktwLz6Q3Kr4A4PTOqi3goh0+Ls0Jkxiy3 vI/5a6BanbKA2c67SIRzBDJWDFdc4F+/Gx2gUEfi3oJelor0UXbHW9B/dh3yKxKumRU62dlKx+GR j/u+GErEWNCfGIsHHuJjfcEKnlM5EHQAARS4B0cAr57MGFyJHiqXMcP5ATJSQUnAAPz7YMQj7B6r eHvBLGACgkI4z+Zwg++6UVQDVBZvhA3FpXQWmd3B5JeGNFrRF2ETnFlzEgu7pjiAdjTqE4zz58qd OTJWvfVsjI6VSJeQsM286tB9pCaVinn3ujMrfxVZH7+TMsfpdbWJUIbtD69BOwwLKVgI+hLdeA6l GP/S3FztHWyoxL2MI5FWEFNzJbhSqHtlZ68j6j//apgUVpEzcRmimvcIMC37M9aJsJWyqNeUm8Ta dgPURcWs8DMylslPE2KwF/1XzD7iM18yLgBTMB/zAh19WJq0Jrml0BwvHiID3cXQYU3y0jbbU1fB Pb/5b445xTTQsiaeBasLWMGYzc+ziyMraZ5RfvstmA0vw9XiIoi+WZ7A2I0pgLfiaMTWi2nZGjgq 1QoWe2H48+F/PEc+Gb5w4fcfn4/xA3tasabl4Q22YpTRpC7J5Nn3DXsHvBHYhmZEYDzeLTwsg4Wc Tv8z+XuCS0fSbHmLs8e+aieZWhDIhVEAp4rWU80FiwPxTYWXwM6cOYNEAvi+9gCrZbzWnlUMEyCc VXKqPGhrKiIytIMsz5WTCXO6CDGVYAR9r+QWvJIaxXSRlKd1/IMOMUmK/50P//sReaHvfpf8TYBg eGeHLwyf//jzYbncKMjuY8WElxVFvwGkcVW++4AS8r5yExKZuNkvH1UpHg2FmOlgy5m90DdJuVim 5PzHly5dOhoR/pe2a+uJ40zT95HyHz5uNlgiyGAnPmi1luOxN94kk5WdHXk0mgs0IQlajxlhMsrc 5L+0wXZsBqiiqrqrqrvr0KdqE4yxiSEQH7GB2ASC4zEQDtG+h68ODd67bo0yMt1V1e93eo/P8xb7 kcXRyrD6AHY0BVdNRC0Dn3BNWYDjpjyuBAlIxrThOlX41lkkwlb7fntCy8LgDsA/ROEymQBvuIxV XKNCybN4Y4wRW42IWlVlHe5+F27CeyIdHAdXcKpZVSeK9K0MKZRkMgk+bsTBfwfdxIY8mD224lS+ HJtmDJA/6O7p7Ngn3n6bBpgYc0OkYP+CoCL/JiobIEM+wLwMS9EALfQOm+TDVEzkxaWcQCtWuffF Jato/YlWcE3ZpiwLoTfpUrqT/iScJfGNUvWO4CKh2bKiPmMUSXNbey4nKSL7wuxrLPWfKBPjPCwt o7Us/IzZB72Q0yQGHEwtEQtDYmO02eMfQPSMtBAhjC+qxUJQZ90XIBd9O7kvLpYj/LycL5KiCQJr 20JEBIKXa9EYoq09+5M3htWYCUoKIw+AIi2qv93EiM6C/9PBQfS1GKosQhANKiWurkoBg7nsS/id Gaqi/bnuCYp3DsWUuO2c1tx2EGafRdm3O/dNQ9KG1RVhZtUVMAd0sWTK0brIQgzCYYM7hIBr3WW+ wd1RMR0xlv0BcwMhEAR/SOYT1O/tF+Q6UXqpKtgvjp5Ts/5gf6wJuhjze+hNR5ibkE4Tg4MaMHmH JRo+/codRa8OU3H/jsfqPxKV5ViCcCLxjIFhQrOUQ3/LmAcr/h3uDJugc5iKNN1r/pS52JLcglRt JFRbAj1Q7zGxw6Fa2eciUg7t4ajCEbTnp0CYtv1kPq37Eh0B4nKa+7bwU7IQ7ExhuiMcRY4AmEJb ljnT9MvcYIss/YAZIyhBgdK+yepgCFJFeJ3xTLsEERoWX8EUwlYCHbCCD8SbcD5bdjuMi9aYN0X7 rBmdwX11n7J32UmhmTJXvbzI/pwDJyRwKtqSqEnEo2qFIBG/56+J4aHO+JcKW65BOThnw8vXu0D7 LrsgxjyEihhX2s8TzgYstIRpwKmxlMwEeX8UgybQMuHmewCbrzBpb/sbsGGxLBphqKMn0g4Ii/Nk ZERl/dy56GjKGiDpboRG5MvqnMz0IOn4EXksoJjffMMw4Eczqj5dNr1JjPAEPw9ZcwisRTwdL2+Y GguLQMiZuQWKSn8lL6hv3SWcV850mavGN+IgedVXxFGSEHPWRmELPuW/E8l0ZTuxv+su0YFYogOv leiA/Fv8fyK1hppLqpi6i3gwFrH9tSK2hyK+HcmI+ICQbC9POsQ+6nT6lWqaPxj8uSzyIAglL/Wv dl14+ZxNw4EPnUr0RITACJuBX/miMsvYXIqfwLfOPBaIaKkwfZUQARDC3wbXSrkP1qZSlfwUeEac zrwJmi5KdNQZzv8uO3c0LdYATFnid1N5FzMNQ1ToitgsyJSGsxuebXlwJPAaD5XgU8XVKnVBteMd wZDLmmngxhMp4RbTL91CgoueiCvqOV7pFw6bQ6XZ5rMfibxdmchV9yV6P9T39w5FfijNb1SakVXd EFt6ALPyqKewOGxbNOHShxGF54XnkjghjFl/B+ySo2ur1ASCsQxPzaHsIjpREuJCTBn0mooyZcyw Whs9m/GyxaAmAlCJbCa45d9BaGF52huzl3FjooaUQKy8qNcKhBNyOMp7d134rLPnQrdopkAiJi5M YkJuVBal0tPpaRiEE5hpzmLdhNOk9HGxeUu486aPBdKl4JZ7LSR7B7dpZ775BkE04W7MsxLnJjMs gXQ0IeA93RP9bn+mhkJPtULhTKiBN4bV9pyaGYJnFA1EvXGObZZzbPKx2rSgIg0+mZ5r3M4M58dB HrU//coLKCHGT6d0GIQS3DojZT578w3QA4abL8IgvvoKBudMaeMIStpQ7kuZYHfgD2HB5ztSG0q5 1EecLEzl3iSAp9+fLzuIbVXnYPHuYkeZn5HxJeL8HKiqVGFdmL9m7oKnhBgZEKauK3ukbrXOsG+A pF2s+fdxS2z4aVWLjpCIPoAlwKK0pJlQATIIbwou+/1R9ZmBb3Gcyix4iJ846ZQPMgWMvp45K5pW v/xEOBh2lnIreIqJzi6aSXaJ0SUFq875Jpor+l7ZFJURcyQuBtKWA2/F1rOLSoh2DUl/fA+VcZWU 4xTHsB4HQ1E44sGZGTWvhlo1fKQz4oHiH8LyrO4JCWZU52gL2SZRRLGNB/jFxGqEXRdwgtcsmyYB raSFLV4KH6k9iqhv9KAx8JiLObgltw6TXOwX+KRE3d5AOL9hodgiuO5iYllkQf3DjVF9MaB8s1Cf mpNUGpG38oFA4rstBJljbwceBodig71E9x4Ih1cqg0ikgqdGZWe4dlPLGgF3rgkW0qo3Zi7SuaK0 L+lmmpeCzGiA9KShU6BUsi+JU10cdX+tb6sMdv38KYj4YG/3K4N5Twgrq6TMPkyZIy46i85FtbwU 7l+Tekep960F4XxrLCeaCGC0skaMOaZHkLeKz6Z0QHYWrXZ9xWc/0U/nVD9Tuo+8llq8kLddHURG h9AfZHyqx+BVXMx6rs7J7cnmkekWZB6ZIxiXz7hPlowGKO2GwMp6D+agZACymqEYzN+pb4OPQ+x/ nensOC8+7D7f1dtRA+EQ1PgBiaWUD0EgxUNtTpJKY92hvYi6bfH8ECcXFplbp8HmwYOcD/IeFrwi LnCdh8KuVfmpX9AegastEXOUKB+juC828YoX2ErIk7MUJUB02/fZ55YCseFYkuDHwRgmucbqFzWE ErNzZi0om9UScr40EPvsR5aSSGb7V8wXoMz0JSynTqgaU8+uw6QTDEySV5kfLrRBArsw+jomdy4F l8FVufhXGGmIAax3q4tD0q3q6L0YIkhgmk1QwPPWEBhDrACDP3mNtOgvI1sIAa2JriOOJWoK2woD bWXDHkegmZklbiA3yiA0flhh/9H9SS/ENpXhP0Y/YnZCL5L9rhiaXW+n/tCRmoMapbbgb0EnlwKW G6KUKc3qrzKLwl/HFjkQ0Mkp0ZZE6P03NYmzJ89ibX5GnwF/LF1VlCjZOxa2OyPYFSZZuIo15I0z vQHNw2DxYd3A8GFrof1xFFG+WVbKfmTG4o8klgMxW2FpVX5DxM+MqqyH1ex6+jWH2a+BI81oklqF jzE1NRVKz4Bggxw+h/jZR0qfKC+Vl2SQkt5qPrC/OGrdx8D4npmGIDu36e9Q7kVB6sU+omWaabBn B/brS5ghJEUY9q+qydmg63tDVPvUufwNJEo8NFxKrVOkWtcJYJPtzRaXwAJLuOTbNHIKd5ux+k1E 2mfgzNX1l9naOpXSDTPtjOziYHPPNrlVZQ+C9Bb4iUpZNv+gKJFRf+jRmbChU3ge6ujCHz4Y5xck d3QXoJTcS2ZOEl5aVEsIu4WQVTpe8j7Zt6ZuBaNQQDbAp86cPP7BWfHxKfH744jCajYs9582ok3R Ou2jsmrxtjgA4WHSjAnXy48qGp76TIHAaBDdDWNuIwM+8xpl3ll8dTr9MggwxX4FApHA2VSWW5RL cAQuZdcorEQ2LCH4kKcYPOS8UVxhb+E/JInRFugIlycEWSKKfihWhcP+m4lQOKdqm+UCocM4xZpN 38EiUfYr5ACI6rjjEccbu6ktC/0ekueJM50upahfVehh5Isl17wLT1QumS8o7M3hgvlPZPsGjAfg 42OEXS5qGQ2xtLcgIDUMauJ4x/kWfrfaZ83Sl+UBoa22BJsWmEd9FkFeqUwqrdJ36oKzgoReMJhg KjBoO4eUnMuUUoO7xDni8aBzKawB9ye6yUqX15D4s9pyDiLfccRwh9diuxeFhGwxVowVgSkC0DjU V5JyCDax/bCeVqWtV7e6R7i32COi5h8Yl2lxp6gcImg9TOXIb0HPpYT1RMfeikjrB0HlCiRuxyDq jgKDfqAXSMXNmavaEmyf7zxbpqitgaLOfdUu4RXyGchHMy4nH4UTeUmd4b66/dlF6nXCT40wQ8aq sQUBhPKCN1fhMuZGiCYt4Jxqj3JDhr6kZdxjyCK5geFQv7tCmv2lmpM9S2kfZ3/G/QPhIpxifSl7 VRS2ebtp15H5ILvDgLVFATEMvJu/QQkd6WSE7tUydSuYN1WYK1jt+fRLb8xC4t5Ilah26rSyTph9 s4/+1//WW29xHwBRmGyljKbIXs1eBZO9HvjgquYD/I+NdmudXbLD7F06DyHkxUyvOanfgsWvDvgb ygLl87xbXtxnaqo6YG9h9y1sLGZlfxDmC+UGcRVDSiTmoqb8dew0A/NL59gdhaWCY33X2xQ6soHS P0o61AicAnySl+nDitUTj9AYeVKsInhgG7JxJ9Ibqn3Vwcy4u4Kl6ODNN1ysf+ZtYwl+Sb/mrlGw jm074JbKPaFt5uYQGMdbhcFlrGT8fmcafgf7YwlnEY4fFh+/w4as4VYUuRzBj+W6+mnOQ4lEczFa 4n+hxZ4lMl2+6r/COiBHgqQhQUTWPLbpr8El2ZTSpywXH2KdsDqgL1oD+K/8DX/NWUHU0bdl0xwi lYFn/XKubM2GO52ImkqZNHBx1J9SvpX1d+MyXjsFOmZSncO5xoTFv9S58Da4HnNLMMVhdyQCz9iK dl12K6jrXpLNJe0Je8J3cmvu01KYb3Eq9jaeVeQgGlsmsr3MLCI2jwpsmbRmpon2JTRdBQPfiheO YbeUp3yN6xFDAq9TUvKRmq7PoGlAmuMGI/hE6TFoavCcd5xqKzlapumn6gfdCMd5pL58ibCN5n7Z cEydE5Qj0yDEgdV15xPgKMqXezvYL0+YZUoFIq5SaOOweahB+IYoTimY6T3+Bwx7Qrb4OD24iCfK 30HTi/kmCJXscUxsYSh7m7NRxSzsE8ljwMQsajYuMWG8hIzhHX+K2uPS1/hBP1nzYBRcCmYmIbGC 8vfmovA2kWSBGrZVNjfBxOdddYHsat5F62lgdngNFl4+FK44B5YyN0lPq5SUZThSlAJTHhMrkDPN YzkbzKM1oI1SgkGKIxPXlAfMJjpgjKDBCPN9WUGoA6MakhAgAMP7KTUOQtpCgZN7h4PIedPPTtYT 5ReuuOwgM2w/x/qe2JVVYVyIMR5dQAUXDo4oXCUcQvilhD2imWyApBw+nDiFMcOq8c1rJcXIjtMp J07hRV4g3cqmuqMOjnBQ8YfTJ07uKswEQ958WAkED+MqxMcr5LegwhPGOM1ZyQ2K6DX/qCzA+uoP 7K3wFutJA4Tl8OLsx2c+PnP6kz9C6H5OfHD6k09O/v6saN8lfiSyew18kLBFCXYtBytkZtzUO/vd a1TI4QsoKaldL+awnUgO21bUZlbFLoh4/QfHocl//c/pE38UJ94/efLMhyeP/+7kmbM1A+Nm6OKo KKWcFXNIfwX6yH9OPrNsrAXiq/1NcYaHmkvDEm06K7IM1Ajh2fdtbxNBMWOBH/MA6727l4QFVJYx LYCmVC/fxO0dxUFIOq4O0yyPi+qg+awJR0NuqG3Wog6x2zX5KcY3xOSEZdVnUB+uCEqbgoPKGrSy UiwxbqoRwz4UkdgFU8x3nWdJXpc7C4sKcdBHHm/ES5cZOFhgfcYcAtUKMczuHUiI+uoVCOut37Cx QKCxskiw20MoYaJbQ/1Hze6JvxbcKqYxlkWvo3bg1UXjGezOgryIpKz+Iss5HKW0tjqV0lWYCghL qBL7m2djsQIuqFlqaTOjXh7OiD5jLO2lmgpkf2Fck/KuotV6CGtiru7Bq3om3Fpcssbq3sDiCHsz 73d/ebFTfND5t7919uw2RLJGz+4ChQHeuP4TtpK8rGDLCGoDL1sKY5vzJnlY6m+H2vazk6SaqmmN yVRSjIkIeUtSQUZNnlSNaKUQqphYPWO+CmXKpdXM7lSVr5FV0SxzUQhU1a5HSdrqPk7eYY0b07Gs FK5jGIyvTEBMPcQahUTzdmq/rH+nbDbg/Lbtb0u0B/iw+++d4vhnn3V07Vk4LMaSmuHEp2zInxnG yJgJ/hgPcPtoW3cRPG8YhQ064wlqHF1pW7RrqUGFctmpUMsG2ejfsOwsqIHs8/QC/GL1l4gEBI/f pQCdCcPwtpqIWI2IT5w+DB2dKoafynL+JnXmQapQU30pCfHssTNz+tPu8+Jsb0ePeK/zYq848UV3 10Vxes8URhZJv1dZ5upaE3ZbSZmT1NyGIM0hcalhIh9IUKkxpnxhTeyRtDo4skZZ6kRzsyZhXcGq +iPDlV2CqJkD94RpbeVFb2091ii52fWp3iiWsM6zR2SEx4CkhBLeiIenP/Em+fxQvG2tQQR9kzIE Miksj3D8IC/A3A5icOhq7NuEvbaKD5FUrjzGY9iwtXlHJri9sdIAaAhs9BhmuY/uUU6y3U/o5+XY yIRuTvhujFZRfqpdwmoqvjXA15e0kYaJzz7QyZ7u3q6/sDI529vd84/XHARvFiNKkKgdbWHeLgeS ftUo0dhPea/jL/8rftfd3SN6u8WZLy9e7OrYDceCKAhJW8J5mRkv3aBeDeNExw2/QHVDPkxctW3Y hLKfcba3p+PC52BMO3pF7xed8Sh2ix65/Bi61O6GAByuprA5UKL/FXbqk5y+Rg2CvIIT57u//PTI nslmhC3lyGR0Eo0B3V/VJJRLZbiQ4ipao4Tkd3R81HW+U7zf9fkX4pMverrOn794VFlWNqRhz4Pa 2SO//SJ4hGm7mqn+KfD16SaEWl5zVozVPGwXcG7UOW++ReQL1oC7QV3bG7Vr2pIm/ZOOrvN7pCbj LV2WWG5liIwTZgG4vULDBKx9T8VeQ9l2tC35lgp0gwgC6eXLSP8NJeQt0TAp47dcPXqFL7TbIyap X8xdS+4O+ENYV0DePTV20Z84dzwnZCH/5q5hHxlY+GPHBPKzGyX3QUmU9PLpVzCLmb1yIw7bW7Tu yrp5E2rhNhoCzjo3uhX5cWpFaE94V6kdSUJ9Ry2rW+lFBNjQh/kNnr0dvZ+IsiTHjoEpvUXvpiAY VKKnwbRyg7qbGy65GGzZnXrHqbVTw/Y1zCpbV8rFPZOjLwUTpQy+vAlObG4dNiAff9yEpDoxLRYb Vw5PGrYH2aJq1ykIwZk6+tE/xHtgYL/o7HnrovjPrp7zr3UzRWVZkJONGpRY7PJdcuQs1yCOWqkL DTamuqRcqom240cWrcqyhB4iQIj0BmbZIZgLhDpT6su+hAM6Rq/R4W5/4U9/W98AvHZ22Kj7/X5a X3rt6WwR8j10UccAp6osOHpYyKmZBlxIhtU1bgOyQSfX6NT5L7s+fb1OSWYeI6BJu6wZhl3ZglgP UmnLupJoUypwzb0p1j4N250c7xf1ShUisfk/wXIbCOCsmn9+XfgIvpMwtsCyM2IXp9+QY6Na2bsE LTNXnYr2CsK4Y8cY6H47YbcGCdFnbUawXm0FuyfKPVfvvGTNYGVPfBnU73n7w4HKcnTemuR5wW7i i4aF/V85jpIujjJG2PXceqYoqQq7jpu+Yw8SypnyzPJFHZFBJG7DoDde7MemhiZcE710pP1oe6OG z04FNvDftbYS5iJ75BhldS4zjuDjlNJHbE5ebdi4eC+/jg+HNW+sOisxGxXMa3kaX5gnk3hsgiAu oE4mhutuNGoXy9b0/93T9feO3k4K4y/CEIczelKnVvVb1lreDrbzpWidW8PXfQRCNqnapVhhwX5o SYSoaxBMzIvge3sYS1UUYOBbxuiBGGk0bIjsyhy/0HEeHPGuv3Z8Jdr3OIXUhPu2ZK3FHncrdouP TUkF816t/A4FSY/KDfI/E+c0JV/sQZ2RuMeupPc0aoTs9Jz48kKvONnR29t14XOIkD4XzbClnnrj 0TCx0Qd649KOYw+geKTcByTZy52xSP5DKoTm1vzvGzcAdk3e7+z4VJzq6rnYu2d9ZE4GxQ5fHbKB vfbBh3rW2ji55Bs8GWjV3O7N79uNcRfWQPZH/4qoIEGBWy0jWRDh2DvZncZGyNypW9U8BdHee6xO uHURhNYUukAc+/ILR83sYpNoi5yb6ovgNqWnzWeOnkgJhb5CEzhJvoNvmEA3d8xFKKe1YO3IBi+N GuThCA7rXgu2rc34Xar48pN80RzyV9oTysqoDko1xQPPLloDiB3KF/Wl9NUQhCPfmzKTeYY3YGPL BxB8l3fZIrLFhkVq2CzjJUL7Vepnfr3EPUQDh7xjfJT6NOQaJfwafAmBUwl8odDLKL7+OpKK9KaU BuKmsna9ReTuIkSGANXkkNXKlGjE3agpPyIrPK7vBdY/88XMrT0H0r2m2hDXayMqMXG2vZ851iEf Lpduogsq6xnsAocX8TgJRKCa2CUntgvKN0aVH4Q0pOIo3kmXS5J38H+1XW1vE1cW/r7S/oebb3TX Ra0DbVWpqiiwq11pW9Ts21dUIjUSkFUS1N2/sf8gvG1DSxjHdjwzHntm4tjjssFAyvIOqSiQQhq2 FEi8IaC9zznnjsd2KvUDk6oSie3x3Dv3nntenvM8i9akf1eHjbXcLWIiZM13r46JTGkKhPdar67Z 4vPcI3s2zkUmDL3eDUqk2Kj3wnAbCRG7a+FFkiPl/k792Lmm0q2bZcR6bghQqvyEGhCSV76q8itc 20vrmRtC7vP5lfB4Ybl/sO3yckwiCLKKajPYtEH6rwMKAR4iGyDHYvg4d6cwR/F1WjcseRTsk96b HczPEMNFeRle6M3ZZ1J18wGwDC6hwfMilCVY6ZNjS/IsEcPru08G6gqiydRH0+lxcF5aN8k0yD4F HQz2P/qdKbOQ6sClPb+zJNXP+unPoOs1x22wtTzhk2KMj1etnwvXtddpQsWY4VXoYKNIv73bLDUf MsX4WTKWc89yd8gIgiEpJnvEAtabQB/adnw7BERLZ6IEL/LZyKFDcIn2jY725wtQRWfXlIE3m840 zYOzORi0iOAMXT9Vn9rXjMDjbFChx58MzqxjUsU3VVt/UsXKDYZ1dEC9cqbZxHjZi/rzyNjEEe3r DkEXp8dqg+qXNAzRi0VWxlmr/Vh9ND6MNk/etJIV40Gkm2UUru6hkXGIPgwd3v/Jp9ktThodHkuc BdZRzj6ldkucVtk3fHh4Ymz/xOhY/w0FC1ZdyPBjl0/vekk3qPo5ZyF/RS/tc1k9p40LpTPFHyAy S07DlpgO/6l1k1nEBowIGy6Ipi29+hqryg1dmwRV0ho0+1gfjB74hw4Fh8ePjA33R0gzwb3mevey UNF/dZT6JfP+ac8qazgjKP4BhqWr7SyuwAgBEYF95Ep2I7wcvoDvqdxryN4ANnncWi3cLs35k0mX 7FS8FYsPuKvrbnrlBOHeHtL24+CwZBx7JkYogkSTrZXofTMlJyIbks1FDvNCnCbfLgT/ady7MFvX Kzk7eA5B0/4kfpbid9w6tKCXRaqUQPilsHCNlCxx6F0lfuDYK+0yfXJOhi9fPU9sYizSeIZJ1h78 vfB431jktdzV+UlQMNwmABK5TKzwh2Z8YsimnGEv3CC5RBnkfg918MI1uOTGwSFwdGA3bw+Y/hK5 KNgg0AiU2vCznZ5AYA26BMATU8DYE3/O+JVlZVfJzIeQwkV3e6PtLNEy1Sbf+koNDGg/031YcfUg Eksa7UlFlb8IRgFU05/rL2xjpw0gl4mvgZI04emrDd8RYELXsmCsqAoC7b6mGq0IuTbAVcqebqzX z22Vf+VXLHMmgzSD3Wwv70yHs+XlcImUwURXGtHYf3pELegys8UfRGHK0FujpSBcjJGlxzAj4Lf2 J4lfAdfuKiB1UHppTQj7PcWWydduWb+zjqK/wT4hNoAqeZ497Tryqe2d3Ff+VGGGmbaKJzJIGARu smSUL+nxZoUVBfY/Q590lfOtfoHp1bX1eyBpJr58MVkOS3SEwAl3WLIxtQWzUxj39MLtA9J8V16u VGjMJLjjnNaPmpQtJD6j3FnN0395PzW8hjBFF33rPtXbtkD7tGyb9Llcu0PmLkoOpijZ0X1nlE9q 00ke0+5df1G/37Vv14f9wVh8xrAyE9qdcMdop+icNDLtzmm0nq8609iCyZ1HeN/k0SrQyLQGxR7R 3Drgi3Xbf0R5vxuNqMuq5G44a+EZphIxMl/w3IzC4yPSSrBWqfFOj5CkQTtStKRGi+4bvRmQz9Bv 6uiFpva42KNxFry8tzj7tL8GxzVCOfEEVQvort4N1YLenqxBJNp2XDaU9tBisSu2vC6KxKkMQ0id gzPNx7NPZ5/2LbpE2p6y8Nz1GLYJm+BsBAuUpyPEZnNauzkXGVtvJbN2bcEvpDUE9mnmv5t9mv/m J7O3GAFJIpL1aYHvCwiGWMdCL0MHPcKAtWjHoMNSLe4dH3Tks8XVtKatrYo/5T4mBsyYLT6tcWbF nDkW58eUHnhvjUkPap0yB8JcG6Jw3VOwgL0rB8/Bbommzmqz484lQFVOl1icXc5Y+YxveYscjugP VGracQOMg+vzqQ2b/ZKhvXv+tHuv+sPegb7IwblWuEddzoJ6ztZeitcUw5KG9v4Vy9e+Hrb14xP1 D1oACRuCqYIDLiIh27l4eJcc4EHAmvgMn9LXnFamLp7asHfEzVh8E7yyCfYrrDrJWJo8WloVNPDo PIAU6B6hFFEMIVLhkn8XUXQ3LLfbq2JhnKK0dxvHLD0TtLPvjMADfhfnAuR+kzkMJ9iEsg8qMJ33 J4XQVPkZdeVyhw81KlW/cTZBXtdbILfnqFxTuOl97dyS7RGt15+RncNaAIMyN+N9TocU+1930swg CAX3B/sPHkSqrW+lLxBvmN55j8M1EqSgnjE7aX3UYKLBWKh23MXSGVAUxkv9SnnZWYKEhV38XvzJ 2O9G0R24w/Xa+vwX8CyKpRahKHpyddWGflNTaDllS8Xbhxym/CRzwm3vOhumuzLDKHorOs3fLP0v d9uoHLBMYqJ+mtqMvx234VQiMZC9Z0h+Ru85z3VOIiQ0MUubmkTxKXSsau+LlNXFvuJkpEOxLyKm kkZCHyqtYbHjte+jjz8c+uOuj/vzta79g5cjHbe4UM2uYIJOVCI0sOGd1WGpPjz1iKS9tuN5VRvJ jikICoVhYBPlL+AnoEun1RCvDRQAxMCmNXp2zip1/dTy32wZt3leg/xpUdFwHVTDKQURF2qTwBkK z8OT7uPyArApSZzNlETDelkDqaiiRZCftyykT8LjRtwrhtdwCrYrF0dcJITfoI42SssJFMZara9U 3NIZHyKG0SVUSJT/JM2DRxi0AfwM13L5vokDowtNnSwXSSnHQp0AAFJAHMNZmI4cEWyyZEcmNpZg S/gRhFbL+EEUVdwMCJGLj4SmSSV6MEmANr0igNB0D40cfn3X6x8cGTvcZ4thhBnDeCxYmPft6Vht byqm5RCSDmpJgoHQs1Benn3eFZIRmEnZj/TwmvNGHTl3pfT9+++DPi3eWV39JULfBxNEJpUDJsOt ntackAPqLaLXTa/fPsjo6TntS3IrpXEuKnrJ6y1BYF6Qss5t6qXR7mwzxp51DS3ecs4XFU+F1Vxe DA8VMCp1qjVuI98NvbvYDzoUTsLoisXwMpUh3YCMcRxlxUuXd31a0yQO60dDKrpaXc7ZjCztWT4A cNFcvUNxvXmn3+4gwDqHXw8BPxoOa3eii8gvWhv62TNCGqnl69q4UqJc/7Vws+aVWsmXifqQyJNi x1G2bSyQKDWFJLnIsy5tDEUrTQcPtv1ANc+4i5LgS2s22Q/+3aFDo2P7D6o9w+MjW1RVQCXVXO/4 DIxeEdvUGSP114dLnhcscKy9iWR9YuXQtOtdOj8flevn9C6cjJrWhjZqblniHu2l4OIq1oun9lOr jfpk0h+HM6PIYFmrGb2W3QuuJT4lmm3ny08AbyFdEuObJw6nxUBHNPOT0g6pcBgPpOUBCZ15Wldn j7bRRrA9RaKGW3VyEcoAyoTKaifwvKieJ7PMs/+iHY/KMX5PAgzEueDTNvFZV7lPc3dsmzYAPq+X rQ2WL2cjvNzVTRCd8k6wZ0Jtpc7L3B2S8N4uSXiy5oB5Ibl6PthEtcoJq8ZEd0cXg2LF7HK1Wfyu MIe7MUk6/yyQD3qIMhy+ebCWb6bmEgmpuv9l0HqXokrPj0JmQ1bZXjBez+tMt9LCZ8GDc61SE/+I +QjhC3xLXCxuy4UuTU+gFVwmCEPMSeAHpRk6+KEJ4a+S1golE8pP/KISLyC1eXhHINj6WH7s36uH RDpoJiCdr2RvtHk6uFeJOl+XkW2QyncKDXj+FHgkmCCia6CdMjC/QQlDSowMdUmLQjQeSpNGtNuA XF0d9umV3POkIQAB0qwyUrCX9MOMlvKnVMoNOW93yDRVYtH2jlSVH7qL4WzlKyU9JtGUXQaLhHa+ fYPMLD/0voZ/YPW2PiaugylKyxYLlXVaVxfuy2ZVP2NQC2y+ljGqbNvCk+HlYrEBrH3h0sBrtDoB x8n4N1Gr6kzADsmovrXzDZKgmfl37bi/mW6XiKGVZpE+LEh+yln1rnW/sV5YQQFBbRO3WECCbw3S Db6WipTgm8JCjQK5V6+4qs8nSWI1GLpQVqDoI8KGYCN3hf8M75dV/kiVML2gWLim07r626lena12 7lYppFLez/vZFi6lZ9WFQDlsV2rNGVW9TExXCt+o91ACPW3bUBTgjHFlu7mlnjudW3cvIBzetPI6 dIy737jJciXtXLNQJTsPwjVts3dA8imadtaCzaTZQ2UB/BJt1/YW0C+gwrXcLQMi9vwpWsWZ3J1c PoMCI/Riw1Imk9Y9vynTH15uPlbbsrv39MyqP1lqSRKF+cCUFeXPdpQd8IiM8FMXvhPMlxRasybn lVesDtUzjKxBoeZsy4ZQteRTfo2884vGtPzec49lQ69O6q+GG7opsgaNH8svSEp1q/FRP8VF6own Uknt610g0KK1AJD41fCaOebTGvKgII7Dk966GW7XCcO6R+GPyrnv3dDhF0tB6SdI+oMt89FkbNz9 Yb4oyyVRXIESXfzB2WeEzKHRU/q5sFLRj3w9PNp9leB6rUwlZyNt2R1PBmf+uUdPJOkuLRTO641e P61mAtKWyN1PzYy/s2OL6cs2eqFkEJ8lxVp+IwmkUEoG4xS+5B4wQM864dnzH/nF4LpecaUW1BFB ZEgJAurFEI1J5IAJ47WqDFlW19NgGUJacWUWpLzKQEzV0yr8iieM/4uv/yv6AbtseTlsq45glnnp 1T8xhW/CF4GQwGkrJFZZ1wwviDiGfgF3GSsPoC2OCDLDtkHYBZdFLIzwEIiw5jZiVgB/pTQNXmZ9 xCyk1XmcHEj2pwaS5YGY7QrZJajCxyJ2+iZlVVlWtYE4vTEfnC8sq+wbb9Tz2lxfw4soXV3Ua+23 v/sNroa3xGmqw0cODGcmRv92cHh8PPPZ8IQa/3RkbCIz/tnIITV+ZGQic2j/YXoT/HlQKQL16p3W QQjNcCVch+V3vA2eXSMswVKLS0QUwSrmUHu9NDPTYcbfvQcF/88bd7VZXqvM03KNu6PATW7eSLAi HqbeGtqq36eMAhFJkcZd/lbFRc9mxOoDtEDHRkcn1IGRseFPwHUTRCOHDwz/ffunE4fQMxFF30Tn ybCbDDndL+njRmGplbtSOiGCra6H+/LWVHzjPQ+kvjJnAa3n0gKTm/Tr1k3/Eu3f8gvrKDUHpVbU T66kwZ9aSYO8kqK18KR5NXHLojC4QetJf4ZK3A3tioQnXYyOfnNrsdPE9fEMZdUzBKHKEDgqo1dJ 51PBEmpb00R0QCJx+u1Ho6Z7V/8eHq/MM0YJV7Ms2pLEvO4fg16EvoXClH2MYWI5pJ7tSkSPITXP LTmPO2ge0V+au83bLaKXBShgzHufLWRrCAzcFtZQv7itdnEnmjXfe09FiyhpWbfUoG37bbpWgma1 vgK5KSWs18VlfVX0Cl0KvtbHN66PzDL+Ll2n+r5cw2Spr5TQLkzmPmv3yStO3Jq+RkvpW5I35x39 z4iUIAlLCeERyjUBzKP9BXo7yczz/qF7Z7LzvFkb4ZJ1DP/ThBkCNbjs8R7iafvlL/4PUEsDBBQA AgAIADmMqioJUFik4TwAAPnmAAAOAAAAwK/Gv8euufbBry50eHS8O/lzE1eav1PF//Ax+cVUWUL3 QVUma2wTvNjGYxGY3ampLcVuQIsseSU5hKqt/V+MORYS2y2ktlqto7uRpRbBWOAhxhyBxME4xMGB ccX2cGzt997rlmQD2VQtHRGM9a7vvt77AmB8PiQf/Hd6WsuVrwP/KlMCTc3MJm9nzoE4UZAqE8qt dC19x1i7c8fOHR8A/zT5APjNQkl4JopKDnLL8oq2kB8H9bxyT1sAYUlMkV1krbKUXgZRlDfZQVYy ps5nJ7RaQZu6kL4C2W+EpUIJspvVscwsm1pQ5wsl/imIq8qSMquuCwIUr2VUdT6flx8RFOD82PnR //efs+SgM5VJic/nlVpykR9TH+rkfvjhH0G7md2UR8GNOBASCyXxCeTHpecFCex0zCDz/Bly0Pn3 gNE5Qhwetv3zgfEhX5TJigyE96BNZNfVyeb5Dz4g+y3v77Nzx18oPKfDmd38K0D7of7ObujobzsK fqsNWrSbyXu7CcxA715wuT0Wu93pstj9Pi9F/D/pTzLX0e/v7be4/T5Hv9PpdfvJnm2HkbMqGugi 8Flt/AtIPxAnIHvn8s/8dWUGxKwi8ainfOq2/MgKO3egoo5qVbjylSKi8uD0DNOUTVRjcYyosTKj zpGVFlOY4qBM6QkOxKJD3GAoCPvDwfgJOAJupIcKMrCnF/aCzeNzuSwur8Pps/idHp/fJCHZKT5t g9FPOeg7EU1EAyeiw/CZB7GBloHd+kzgdDzBDcWhKzJgbUKy7+hRj83W77Xb3C6P1+J3+d4v25oR tVFEnR0QSIwMhqJwpOtf4YgzBC3tiOQnhw91dAYOUt1pcbR37KZIDsSCAyehWEWbzKemRyH7OPsa lPmCovsVk1C1+5niR2NcGPpioUgCDkRH4hw4bDYbs1XGvmIl+wXkXyt3U5dQhzNXzMPIRzHqG4kM nNiFKEWPcfF4KBoJhhGzIQ46uHjoeOR9gm+A9jJmnAiiMBJczBCfk2pXRyg+EOO4BOWKMluQystQ nZZHW2HPQNz5b1SAcVA0EJ8JODOu1NCL0sVG0MG54fDIcUsoEgfhWUYqPxInUN7CWfxRlOSfqBMW rr1PiTdo8zR5uKOH+jugr7N/f2f7YTh07FhogAkczJOqm4I/wAUHw6EIVzcMu+FJdDU7sN9mb+9t t3j8Hvz4LZ3/ctA8nFwUp0+6O9s60AKiYWKxaKdWWyNIMazsdvQaFpsTWWTBv06/y+YxDy2n7j0C 0NP2Z4bGERfxcds/LQ5laXeDexRRm8Vptzvsfr+fTZzkTpOJw0c+9v1zNxtCUgdxyOEZGPQPegdx xDxaHM0uO8YNhbgYhwCJz965Y9swdeQBLhZCU/9gL/TsMxy2zetxW3w+e30H8f0QJ86/u7NpR6Cj x22z73P6HC63zWdx2L07d/Rz/zESQghcJBEnUQBl2Ioeumcf9Lf1tILPjb8d6GiFo129ft+ens49 vYf3OA6S+F1cFQTpeQM9xE6RWgQhKYrnofJUfa3dhOSi8lqbwwywPE5jdPp+flOrYXLHj+OsulHc UF4qsyALubXdICvpEqY2yhKaOz+qLIF6JnlHw9QMCl/Kq6C8lFfIIZhpiuXMFboxt6bxkJ/T1MqE /D9FXHNhehShVyeUJQQryDReKOeA/+bKBv7WcQQnk4vSDVXlb4Fcy3ynfa17E5Jn0iNxtfRceCYr oL1izmoWNykXEF/loiDIP6mroJUyFyovMUHByB+PW4bDwcSxaGwIsg+mLyQXha8NULhrAXK/ZGYR fXVd3sQdrSB/mVzAg/lN+UsoZVOTioR5r3KBOLotvGMsUBWJoZOZLXxH+VfdgORtTIg0CEcjxy0n uPAg5RolvlilfJYvZib5UXUdKpNXRhFqcjF9Fb2tullaQSLJivKK9nWdeLO02749QeqIccGhU1zw MwwezGQbrqTj6FEX+g8vZh82i8Pl8vktTr/f6XxzhdPtxDmv1+m02J0Ov82cdMrOspTOYPw0tKMD RNQT0Rh8RpK7PpR4KDIyBM0UtHdYDqI3QUPrs3gPf/wnl+Vjm6e9x9Lr/tjebVIOamP5iTiF4fa6 tjAtQ0tPME5i8wEMt1yMuj82C2QaS666FmdvYzWRvlGQDP3WFsoZqEwrNTJV3iQKc57f1LUElBnx AU6VHioviTq1QkHSLlXutUKZl9eFpeK1YiWVSy62glZTZpTlcoaYbivqqjiBBp/+hfxHUnjgrwtP MFUnZ+vBHKY0BE8gI8zyxcwZshlR5cczV3BiGyq7du3CU0G+D+k7SgHtRltIL5P16lmJ2E8z0uhb D/fAUHDgBEbVeCsMB08Pn4jSX8PRgZOW4dDAyVDkeCsMBD8NcxgGYJDDNCY49GmYDtexl59uwX+X aUZjo/ldV2/gcFt3d+BAV2d3B8s9+voPkRBgt9HyT5t4S6UI7YNUBfdCV6A90O2z2DA4WDDW4f7D nT195iFNM8PA6aFgJMENWHujsUQ0Yu3CL7EIl7AGuIGRWChx2oqE2KGpbsSM7tsyushl9Ga/vkkv D/s7D7eFuok97h8Jh0kBXL9ZQPf6Dcq+SBW7UEKVvweSWKzWhVisVvLZO8pMZrIg8ehtn5CAMY9q VrkBvLqe+Qhr0g6ZTbDxF+lfELGkmJdQ7Fjl6vTpqIKBKhiogk7fQSwXghHoHAwlMDPf/ebOPi4W pyn7foy9p4KhcJht/b93vgPm/uBQKHza2PcbzmmLJEJHQrGR+LsA63zFVP5uPo9GmFvWbiMXTiQS w3v37Dl16pQ1boh7IGo9GQO00Suv1CmtVviqUGIFenpFO0eDKnEYaPQSKiAarbyamRWWUEb8GG5K 3y99S609eRaFdGUjfZ8uZ0vFcyQgy4/yc7g9R2ffsVa/DCAT6AN+ZaGiyCvNJYcyW76e+gaKt/P5 gkSXklXTT8t8Y59xzTUHUxfYlHIPlcJACANt8SulQPZJP06tyT8pL0AtZv5BNDG7rrzachDmHzn+ Eg3C+WS5hGqp3SI7K9eKG1A601iLyqzdpBifIxYyU5mgDK6jiBp+UUyRURyg5+HCyiNlBlON0fw4 kmasEMX6Jp2MPGK8iewx+IBqj8K6iWV1dVyagOSt6TOURLJFHyteEy+D+KBQQmqVF8oSmernjg+E UW/4FwhNel4dq06yPdr38opQ1dGeWhMEioBwVR8hTvu2+ByjQGVDuyVoxRfIGP6x/BNb9lUzJwkt hABCujqfnzOkS4lQ5hnbCasQHv+DepaSqNyVRzHFw0RwVscZLV47h55TaxKW9XjoGAt4xfl0DcPb TF5j/K9O09VkEdF4TNr474hIv6PyoBpD8DL8DMbGC5B/mfzBrDBPq9NAX2dnBxY9fcT/Ka+q4+Ta VJr9CwkPc2nvj2XwpFdQ4+VLhRKmxvLKX+nd3DDHDfYEh3ETW49iz4/LPxPlbKxH+TncNuRzbq06 tqe4oRbrEGiigLklCa/gdIoirs0+puqivEpmUSjyI2REPpXlgaypO9zSfKGMSW1mlowi/6msq/om zLfF8zwm4HhMKYMsV14pd+lwE2l1567DE84pM2WS+kqvxDGEkP+alQYGdvy13Do6qSyfudEKqF8v Udil+fR9vixO0EkcfaZo6rz2Lcthst/wj1M5oPSSeRBWUROrPBpJTb6oqxIot0hRguJO3ykuIxqo 2wIxtxnDlpR5HKjVLRwDBm5P1y+nKpOYtAsywiD0kSCDZ5XGihUpX7dExv0mwdTlaMijY598nREh zfKjOizM4xeAP4PTslDcqPKC3JpbS2rSjfwErSdI0UWQrqE1UNuvFTSGMcMOWdtgAWUfPRP9vXEK qV9wK5ZqOVJn3NNqGZXkZmitraDU0ODQ31yinIQUsWLl5+JGKd9KEUL9WsNvHyFbUWg3KhtAzjTw Jq5Qr+MYMHQI/Gj6qp69tbyppiSfbXCE4Ltzx9bvxtmE02gDhNOGeqDnICsMkenieQeUuvbLlxpg to++L2BER6GupGTeUNOdO/hR/qlylwYzptHJVXUduWnodSv9jQRTmL5Lk/nsjEjctaFeyjz/tBWq 4+ITHcW6CeBBmDwbq+rqiuRkNykiLGaSr+RO8y3U0inNqLsr00XttxGcX89gdaAuoOvdS9Pb1CJ4 5X+AmKPgBaH0bSlNLmzwr7uV3bUSv0HsTlTJhMtLhg8O4QTJDeFoKDIYPRUHvxv2gN+HP3oP4w+a Orf3fQKVx5V8cT35AK02t4Yod+3rARKvEIsitLDZri46C0lNWdpNLkDYTQgda/G49F937qDzLeKD 8uXyI8x1kBEoHGJd0hw/SsjDUrD/UA84XNkf8n9j+w90dIDb1rOPfhGfpWu0IsuR0Gi3OVzwZ/B6 fA3wkMliFfVCU0UeF9KRFqUmzRJ0dYDKbH4RvSqBiSZD2I5ZG8bD3WDBqIUV93DwOIesakrZTiYG 9XTtfZcCpkQ9dilarKS/R+I17QZ5oqRvX6Wb4KV3e+bAZRef6NYUPats0QESzhZXRR79FHq31WRK 4Y0Myixc2G2n9Fz9sbiGCV3lIr2bIleB8hiW/OrUGiZ8qyzNhBaXiVxhd5XSo8qGMotZp/hM+G9R gPxcQTILIrs/mv4idWlqrX6daw4odtnT0+ds8JgURuaAc/jZtU1qpVzTU0h5A4sPMyGyZyPt5vQ0 yOvCs2LVLEDskagykRlN1/RnMnMAsRebzn0BzEKkHBbzVbE6bhYw5oouy/RFivxD4uwX6IWJHzAL qO6H7ogTxQpkZrPrpQ2jqsMK9HbynjhR+JL4JCctx0zBgfkf/qUsYKzOvcbUGAkmMB3mwWSeplBO XUIGu/kUJLMIU75I0iFzIDJPIyt5qTD9e1HJXE6evBYoi9UN0g1zR0AeL1d5k0D6mNspSFNr5K9h N6WvMC0yaIVf/agPf/NS2idkKgd9zKe17T/YC9QO6aNf6aZ5QdDhY94tOyulS1NQfqRcB7MgMfem SBJP1GIrt/Mp8elekGraTZaFn1fuCRq5zkSBspul9dKiUBXuYvGHNWQym8rpF5sy0bKthwlYGyp/ o6dRDSTfjNs/WvDNTV2A1CVZIRcHkvwTuiDtpjglPMPks3gjqe3argl/QNlnUoAlbLZeM/J3C3Lq dvrOf8EfzGIYc9GEgtzPyay6bhYc5pUrf89LyUV5s4UANE3dmPcVHwjf5pbBXFDM6ZYErZZfx4Tb 7zULkH0rIFqhmUuantwFIPtExjqCZVo2+K0fdCmeeicB2K3kEj4WHRwZIFfl+qjDCvu4Y9EYB/0j kUgochwCXGJkWJ91Wt867LLCJ8PHY8FBMrEvOHDS6DWxfq6vcL9jRWAoGA7DvpE4edaKkzf+z7iY vsdjrRfDWAK76+0a3i3j5Pn10DB9LejDc/U1PkZckL4wJIIx2uUTSnD6tN8KPSHy6B09lmg8RXR+ PhxGyumTrp2ttNuaV3Z+PnAiGMFitBlPu715SeBP3VtnHc2zfbHo56e3ziNLm/jRHg5xkQRjLlmN LBvSFyKTA1zweDCBq2Kn44lgGDE/FtVnkcFHuU+hbXAoFAnFkfJE1IDg2YKf3jXXE4xgVT3EgDWh 492yuLetPmuKRntZIMeE8O9YFQpLpAiUfmRazV4H9d7QLR+Pxyc+4EfNwolF4y5L4EQQzcBpdVsS 0VNbY0N8TwT2kgZAgqmP2qDN77BbbM79+yx2e5vf4sZRp6UrcKCtv9P5thSjvFIo158tUFv7+E1l svGec4tdar65z+H2pFcwdLFuZ3I7h/votagpbRANtrCMAVP2CUzcc5DJVjZKG6TBFVo6uM+4cHSY i+3eLjSn226mqDzGpcI8qs/0F5VH8NYGqq0fu91vJk7uRrsFeQqQ1cpT9LVu5VV2gh+VV0A9i6m5 3eYiODQp+dsSI9JhSO/HZzD/abznbj2KbLa+TVMK54urqB+kD4H2tRcvp6+gmhQradK5VChhNbZG bv9piyO5l33bIQQEfZ4m2Zj6mhSNCvATpWVhvvhQm2uQyDR2l1lcdellf/Ieu21ofgSvR0G73fkG V81Bh+Uz2RuZbLpWXEce8qPKjLD0hudqIW9HskC78C+ZlRd4WcpTXCDd9DVhSXhGSmvaNMC/+h2Y wRKhI6F4KMoY0Eki6nAsFOe2eXHMQMy7/HJ4bXUlqWjUApv6nUhMf6e5UYfO+ipdLpvTbjPvAsvj N5I4DO//zg0ktuuMWXB9Btyj0djJ+O8F1WtA7YlGuNO/F1QWF7o6jmAS6Ua5pu+X8kDavrIP8/fQ cTZaLbfpAfO7pNmCXmOgzxMyRg2pzPBXaauDViuUSA25yY9BVcwtk2bM26L41osEYTZfFgRQVf0d CYf0V2U+pcyyR0P2JqkuSM/rTSfWt3p0rEf5NHkXvkM7Hwtl0hXwTGg8LzdS+2IF/dEzrJ/V17QH wwJ97Szn4G8VSmge6ZXqePYxCKu08mbLSQPdXUEmvr4BnhzBUotGibD1rOYTxKb1TTRYLH8EeVOc IA+uY+n7RlubJJZX9J2EofnMLBLG80iiPE6uk5re8po+pGluHDlG3vK0mvikjnQDidLD0uIbSNCg WEL4yxh/QRRRAlqD8jfxdlqb+KJ319DvJGoiSJAmq5P6Fus2ht3UlyIV/9R+4FB3d1dbr7W387AV ptbIbevVvNasMeo8kkFE+Qag7J3L32fXjf8VzSi3aLNHKSOxliT6APoWZhGuJ7O5H5GfqLy3jCe2 mjr3EbrJmrqOnMIJrfmxulGwkTZ4EJ/SBhRJTOXSV4RzaEnIO+kGqjR/VZygPShbwWK1oT6UsoKG VNYlWxdQ7gf1fCklTqDYlpFRhTJflmaVu6SDB0OkKAqrmRoQmTaIIM2R8L+8XetzE1eW/75V+z9c vkxMRlIsS7ItqmZT+MEzBsd2eHyZWgdUExcOpvwY2P0P9s9wCCQ8LFpIbXW3WuoWkroNMTKGAMFM CPFiG2LsJSGxDYWr9p5zb0ttu8XUVHFJFcHIrT73ee45557f78C+zRZc77lA8j+yNZRbKWRI8iKA qchf/0qkb0saGbfxb1dEB29L+Ua2V8wFCATdZGlzmA4KAhKztOn8UhKzljFvk8+va1jRClFKKY0a nRuHfpso+6eRB4Um06NgSZAQ5G5fgRsrD/WVWTDfwLKQXhMwPQh8g5uRPBMVPqn4HoFa2gbCgs5T dMIx7cVKaMYTYb0MO6dF996edtLd3nWovYtuw3oSCde/1V7mPe/oziygNqKzC9lB6kpCKTx25cnR nbNEV980bjPIMctqdDV59j51IaEkL+JL6P7PJugugJf5pDdKnFSythRl4a0B5OoSEjZo/Gbje/OO Oo+NA5u9AoAN5XOeQwXPK49SU/k4nMk+oi2lF6jeCQUafGR3F52ChkBzxLNrPM0Bs6LeIrUOHA9Y M6LMvUZm9ubH9QSeRpkF2uZ6SC8Qa243Bh0zU8VDMBr9AMcC8joA+VlWlnwbkmyolnbbvlvnorGB rW7tVjpeSUrz0RezzDNIFsPTbQ3TM8ZXASC6Zma8/TVIPOOKLhgM05GZGDOeJH4k5nruMdUI1P27 hu/IEP0uW9ae679w1sywJZ4TGVZoZDY7T6Bm6QHoyMOuF24oRpz7a+0bkrzPwTcRJ4Qg1luJNFdl 0z3znMtuECWuiSehKGfVSeyjE0aoU+P6mFmmfv59sE2vQnrUD4CaT5fBwBHWf2akA+aioANAHhtV J9pZjkRqpSy8j/VWDWOk6QFE5YapfyJebMgzdtcUqAeFLUooU8/m5LXlFPgrTUw3400tTPp2z2MJ HsAT3HiuxDFfJmelR2HAqO6SIGEpd9WcBAuavgJar+v0Yc9zimvBQPWdaNQxfP1VhNQHRKm1SLCS psJuaqJNcE6gVTY2MWbZouQydcpietkr8hzdVJEG8SsszBQp9QshAx1VWdSNr3XNMAQR6VywjMAi NUqp5VEmDRjU1sfSZQRLsOi2dJZ+xnKlqQnmOcn5e9KS+gicx4pLD97ZFWWJGnmu5gBQZk5+Qdvl vVYuRJuhWUDSMZH/moMLGcgAT0EqgXYIPy3MZguijLkwOxRYZ4hyg2DeKSSSem8X9lvjIgA7Xuo6 3gPkvnNaDN8LBLZhZrv0RlrTx3zevdfsxz6IZMjL8jLdMMYPikKHT/tdfgWxi68n0GJmubG576jl 61gF2zxfZ6wx1BvYGMH6+h1B5iVNxFOMYEX6VfmVfZRQ9Dj8qTG3K8o3iXk64hcP5ixpFHhTtmGP qdtKDfzrIq3qMDsu27tbD3b1kCCeTI5Ggpg3DK0P/VH7vrq+/Z85JpDx65OW9DuQ+ItjjOgBlgYM +sjK38MJnK683XtoL9iPqR+cXLTi2hSAXf43Z8lliB2UjOd02dP1ypwNYiybbyDYUeNFjpMDoKXb LjtvWwUVQsYlWQb3OInxf2hj6u5b34VfD9Vv9tSETREzINRncjm1KJ0lO8iWGRIlOeL4qWAmKXG6 VevUScjVqLVP4beQX84waPAcHSKY8IlVHKk0dVGnETEOM5qPV6fDc8ThdWwp+Ii0ppXpkrhqEvuG 8QSCO/RYq3jC6AgDbp2QGm7uH5irDQBtbBeEbdYqu1vM8IW5ZYB0ONgXOUeNBExPhqSnDQ0U1Qhm Ex3o2YsTAKCpogG3vRWM5ua7zAhb2aLaw80l7rwS9QH1C6gTtKPyEWIlpCXN3FY3/jugg0uibORw 0FnfGOpiFgxayPTUjquTuZWNGSWbVpaXi9tUD/RZ5No5jBTYEsCL7qcWqXIvXrJtWLHS6LVzdFMY T/K/oY3mtVplVVoy7yFvUoA0NH/8Mf0+5GVhtBFf+73XsdTaRoKE7Bo4OdzZ+7eY7/DA4HFf+5lj sX5f58Dp2GDnQN/JYd/OY8diQ0O+gyPD/QMDJ3x72yP1W1/TAIw1n/f3DX1RSVNx/TZEGGdF22Dv aULH0OFcYTkUpP3McOwkcNwMbf1q2P1VuhQgE+RU7+Dw1icj9Mn+kSFIdqFn0nXdtqa3+4Pheoxm 43xRTTJDEg+vUuUAVrI+li3WUbUsJbd7agDrobakxPUSPhcMN9PnfEYO3wQR9sRs3Wk6YMbidl/6 QuJmfsWaJnCCBbY2rZEQbUo37DwEYkStzXq3HxsObLxuhSDUDmNKi2dt+7F3d/mChIfQXIInGX5/ G1HXENIPJx37oPaa2hgpvZD+ysHWUtNHugl2JLtnN6bMN1TJw4tE6dNQdLMnHX4fnnSI2arKklkW mR8fYpbYhKWWPZPexEZpQszI4GAZaAQ1h58LXN+hiAvgwF1HUaLYOZx4mLrkcGtEm0ldJMosODsu bFA5GAjxR2P2dOa5CJ6vhhA7Unt2frKf9BwkHe2E4FoRI4ydmdYragxar5W4YUJulBhRPA+09xTh JCngTLxre7ciroFn25cmzgXMO9lSoDCb+SWQsxKzAfWZ9Bpum8TI5fplnKq0ZbTt8+vO9ag0Kj3V yu96G1ZFM53j+N4OTl0ri5HGdEzyB9yCpSeljD4G+QovEN0vQF6kcoFhPKH2GNWnRE+IUqZVsUzd JC/SAdWU3GN1JrMgRhBn+Wwj1DzUFMwskJ6KEsaUTOoSUAHlqe+2QuWlZuhEwu13flmMUE6ROYgp xSTYXC9oHzBNw5l17VupBVKQzRk1LkQaJ6lU7lk69QoxWIemrFAtw3ko8z/l7nDJVBqJRsUIa6qG Z4vyHLFWS0+oH2zN0UMjKEiXcUbIzEJ+DSnZ4DY8Kc0H1KfSPJWtTkJobsycEiOcqZr9Ld3EeEU7 bJatVc5PIgbjVJXMr1ryabjxkF+YM9RMtZ7A+QEXTSExQpnmAQIy8ErEyGAKxy6kR7OXSUjUqgny bZFQ1Uv2KyJdNx/qCTGimJJRlIkxyHd6ajwHzqqHuCkEIWIrsjnvHCAl3bLw1kqdFyOSh/jvaqac xhwbMWKYqkk90F4WR8VIYIplz0FqWLe1d+/dfYB0drV37G3vEiOOqZKewZEY6T7VeywGXq4YSUx1 9HwRI5/1Dfd9CZAb+wetbN8SI85RGko8qxPgh4AjSIwopjsy/6drQFkvUyuTZZdoYtQ/Zz4w8lnN WqXq35ANmaQWhR3mnP6gmKSywI4m+r30QuWsEWXZBjkNQnEmrctz6bLxnPqBxdIFMbKat8iybbsg RlaTg69Zoe4spGeA3ZJ6IM+JEde4UVyEvOv0hKqoSNVbBz+LepZ16mV7NjDxSLkraJGEq4EddT19 Pb8uRgzP9UhnNfsG3QaClGSQkxvAOnQ4C61pMZKYEjHPMSNOjAyX4sja6iVBk+MQFzBGCPBKjYuZ BcHaidMLqE+T40oJyOaoWEHbitMKuFgIKyw00WYxEhs5CttckJ8hHXV6XtTxGeTQ/Iows1zQxQkL bxI2Y1wWJyy0aRhfi7NCghWIPhfGojPixHEjRM68JLomzYsRwllQxibGUgt0YWTW7TjcYQoQxUHT MGqO/178Ma3pthhpTHsc2LPfcZCEKisHZrwIEFWuO8QI4rwkk7mfErMYCxUTIAxyQLBRUCC3GxJs ZUOMNxvkKFnjTvERaf3zn4GaQMzh3+TUUeroOXiA7iw1Lmz3cnDrPj/c2pOP6A89vf0n3i0jQVUY UxUlyRgtzoiRwPQEBP7UF4JchCrEtOXgwf2ke0/7J7vECOKhjLFs8V3Pv0sIJ2IrGiu5B+obQUKY NvgkNvyfQ1AV4b8EiWG6IL2g/aKcJeqMKkmiOhTmjDvSaOmyksxZVlyQoBAPLxvL1HbG4nvMoRIk roHvUHnOnshqQs4Il7Qg7xw9Z1fQKIJ0kadZW5A4nr09o07KZX1FjJBINVhBpPH0FUXQwuD4FvNK zjIW4TLuXd9nukQxFaFYrrqP4oQxVbGzpdXxe7MpUZuLg1WA0kycguWgFN20roJ5/K4jBi5BIW64 quvEstM3ROkIjjzJ3bPzpZv8ek2QJEc/ABXzuw0Pu4Q4tBbqvGyYtqZI34oRxEEcxle6EW2CIqaX lLOJWUGymHY41H6g57OuncISuaryeGTiJ/VSfo17MoIkMf0gj9PDwiGmVKXrZpYIksd0hBLXXmlT 5D2MJM/exvJLVLP39OzCZFOBKpfnatvT+j0U9U6lQL6yI4dfrU7loEjGu3XfXb1hSgOLHQBQyR2E fut/7gxUlsSau1V4jJgkxg2VWwZgVVx5hqQIyTFiLCKgGCRITkEgjuf1gPxD7Bsyj3x0pHML8CWg 25fG2E/2SmoRfqOP+UjpGoNO+kjhK7PsASoqnYOCXCwHObdgLtD/W9lCzvIR/aGuTdC/1XhB18o+ ki4Dq38SAaeeRARA+lkZJ+U8poQge7HyInfb6UwAGD9koUD7IM88NhMwRjhpomF1QZ7ZCzcTwLsS IRtE/rcYmUwzM4rFD4aqJFfINlYT58RKdu0gLY0tR1v9jT1NrSF/uPNI12F/w5H9LYf9u48eCoVE DVOTm/ip0nLMEzZuGs8xN3wHGoc+4HPw5aivop3LavAPYt/VMqIa1li7YTuP/7335LHYcTLE0AEO 01qNcd3T2HP4U3/Pp592NPv3HNl3dLe/rTG6q8nf1Rw+1CGq+ZHaze/e2OrNydiefehpau454j9y pKNjn7+tp+3wEf/Rlq7mw/6j4dCRfaL6EK7dh2rVYags+k8mYFdj5+7d/vDRo237/KFdu0I9/q5Q Q3OnP9RypGe3qMaHNu7Ff73VXS1trVH/oZ6u1mZ/W1O0qcG/L9q076i/s+tQh7BWN3i0essqFyM6 6CG69k57l234uKWl5d//rUVQx3gS9n6/Ek9dzGqkURQAIcjTrnPfXTtH0qo8Z/9GxMvkeZHUXIYK vW0HD3d/EG0m3e11ul7My3PGqPxCt7eLP3B5KnZL7GD3e6FmCFZzsR969pzwru+o08pWAXi63oI1 TmaMxR2IZadGXzSanI0Yr6ihhLTqE7yALyprRpY2kf9a18xJMv4gt5y86E03S6Ql+RlgmuRzgQAj C8utQs6QFbdsBpWaRnATwPg4aTtzDbzfNkoSv6Xz5j1kDstZskz0a/SFNqBWSZhjhxElmFwsWvhm USQNwYYK3VRn37HhkcEY2Tv8Nu7hxsYIA4B6cm7l13wQn4bBLq0xrOaYObMNeZKqBT5FGac85x3L zd9EVt7a/MnIbdfUWLMvnCgBXsKh38mLxvcOIBmSpHl2NogoefMe0gVyFcpOL2XtzEutDMXx2HiI 6j87cz7rj/Uezyw46eOV7AMw/VgCk2vveHYeILZYBBK/BwnT+m3GK7ENdyl1PtIkv5r/Cgphe4MC XSMEqwELhcsG3j9jTWz4tzqvP0yo5mTyojfOX54Yw4fNGUQkImkJwgunUw8Q/+pE3OEhb1YHl0if 849iuVAk8rKoSWCnb2vvidjp3sETwJjhsQy9bURCmqDGL/0TrA9Gos3NW37ferhzJ1QAxv9E9aDe dZthrSKUMtIrSBjHO9h28kpaZYoHfSw+XM5GFMg3EuToh4lvWb1VrIIFYVmPjVF5BtZ0tgAI3G+g Bi4BIIGPr0ZGIOLN5pFHGkrIVzBuoiBc2dKoPC+MhyfIARf6bSUOJCc1O5aayq9Av3xb1RtoMt5l INnw1nZAvDFdJeY+vPMQMnSyqI5YzR+s+pjq0+QNdX4TKNqzz209nT4inbVsH7FWAXYmL7OAVGGW ekl4i1ehot/AButmjgCmCAg5wQ8T/1O9fDHLUgnjPcAzWrgBFIjCOs/Mp09HQN20nzk1CFUkaP// xD45wj7o7B0aOjUwOAy/afAcFYd96o05AyNgAj+uskQPkr0tHXQ+kwPCOhCu5APQw0ovGsg1I9zs 5EAVw9RvVzjvxAttqOC7+A4rrWlT1K14CzG3w58zm1eoJZtb5eehNZFa4yxXwFB0HpkkeE1kackb qo9Afxmfyt2Aktr30wni4rZhnInAC8A1cO0iDI6hRRVZ6g/tNu0JrBNWrJobEK5eGmZ2WZFLtMHf e7+MSabjAPgXKjgHDI9QCAnqsE6qa6lHtO9wDECF6Qrdrpg5qlJ/TBSK5l2k1KzODouY10WCWL5g u/dkKRnafCCjQcJKYKKh44EGMr8wrehJsE2qd7bexwY9EdGrsGylhLxSbsWEjA3Sa/pp6dI1OmrS qGjGyiCHK5k3s9nxlwzBFwwE68D2x6PRWKQzDdq4xug4JEWVildQiHlK1+jSTP4ORyTVQfiyjbVA At7Dg0ah9LP0mpjn+PkM9c6p1yhX6MugcK5T6ToHc1FjSSMShI4gHMlwmUB/yKdh3oAmGqhunxFl hlegMGcINNLM1HiZosjP3PShPABnluVzqQcu9l3azOxlYwVqUjO+3dq93MBTFahFxxGOoGNTre3N +OPoToV3EPtW1nRxGicz5hxWHPN+XbX5dCi+pmtaX3H4QALkww8/xFsH+EHQWuPwNIwOsNnlPEWN gch+8i+dZE6rXZvzrSPJpwO2KlgL1MTJ4x3S9Sr7m6gdxhFymp4+S01KSGRsGenrPx4bxGNqQ7lY l3fRGAx6eLSV/+jb1pP3zTs7yKHWzs6WSHutB7sPsL+hGkTQz/8Eaz29v/0ofzoc+/yMvyFUf4Yo 50nfyVMjw+joJceQwPwM/RDIz0UNWTVJTvs99QeSbXoEAKjrFRLGlRLkgED5W2r7Tm6dK2wJD/EI tTM4UtAwx1+WLlO9SHLLdkGJA9ekbiOht3hbh2MIeRuaA/XuWGJdY6Sen59ihIecQ5wRKsMW2lJp mQUWxVPoBDnoEFjdP/2EDX/T+zA3OfiwqkZwZwCvdOtH3USs6Hq36H0VwTV0l5hWRJ00YF50e5/X KhDeiOYNVHK8KdpZKnx1a2uQQ76qsmpFipxQ3TQUZUUzMKFov8oTjNRrmlSNd1GBBY6M5KoOHO7S ZehD7oUV/+i9aBgOlqwqGPESeQ2KderfZLYeKQQY78w5qLazqK4ba5Dh57OnEo9I9rplSz/77Dl1 3VywbP02Zv/5AAQJX2vgX1Pj9lydfcv8JrlEbY78eeMf233sVcRQE+g6hfijerI46tvw/HZffiX/ tTmT/pnFdfkXZVkfk97QKdJvm3N4HqP9ijkl4Kj5MDxPjSRW1ECWLZuDM9EsgusH4Br6kb6hsR4p DKHUF4EobOoalMIQtsDCvKjW4PBIbz/pHh45zqsnBaAYMWmq99F/GGt0+IMRoGD8y1/+g+pW7des Ruz1UoFad9lKNSDO35KYp0t0tsKs2BBgt06slma0uVL1prMV6hqgf8LolqTvMivA11upP4NfBF4y XiuG8xxWPml0PmG8cM5aQc7F/k0fMt5F94dN3t9GAMjGj8DesVbNMuR3Op/lLOP39FP3g80BlzNe CWOChwLZjbwgKCdA23l84PMYo2Ic+mLgVKUK6IZf9/X3j/Aam4zki9cBDbUN+Tt6z0Cizp/Igdhp cqp/5G99Dt1jsMF5S0fvscGBL2PH+3pJW99g7Bh9DzXoKwVBAYC6+RIhMauuVwqBur8/GOv98nSs 9++xwVClJRHaElwyfQNU1hnSFeuP9Q7FiKD8Gw45bve3DAycYIt0B1P37CYQPkGdmEiakqsYi6DW NLgI9KivrWQEMA64xDErQy5nfkFIHlU8QCBknGWgAYerkO7TiDATK+pkCCuP5Bf5ldItd0sq+Vti S4o3u1xV7RclXrqfmqKOqqsh4j0QjnSGijDG3fx41k5P1aiDLHAcOGfCL+BwbB6CaJT4ES639fCs yVMqGzKsXlYOnb4Kji2x1TY5phqXtGzkrE09eB+8mxxp3dE7/Env5/SACQm3bjjcuruzuzvKCsAI l8i9tJ09e+ifva070Y6MbOFPr50OLKRVTH3CsB/qo0eYdzu8LXNcsQwghdYDRNyQmhk+o29Si2kV fXB3CLdGUQLDpNu3nNWKM3aeyNRdvZC+AlG4FRZ8TMwmZpXzxLgs/WxPGRd48FI571nKCIoB/pDM sZJdLH4uaPCCm6cUvD5kJea3FTCQovYMOwW6d3ayUvRgvHqz0dNH8G7enJxg9YNRubQfHznWi4XU qXvuOzBwsr/vZAxvZ9gjnloKfS9dC9DZhdp5RFZzFrWN/7+3a31u4rri3zvT/+HypSO3a6GnH/mS cZGT0tjgYjfJTKczVezFqBiLsZ2k+dL/hUJwCcGsrIdXaz1WyNKaR2wDKQZCSsdDYoyDQkuKVQgz Pefcu9LarEw/9JoPRlrt3r3v8zvnnvM7aKfvxHlMrjyF2blsYg0mNXIiZ566FmRPCb+WpPyMfBVo pxI181qD3rt4KnWHlLzqysIpSkgnpytFiD1uBnuiWokg+3cGE19qXzPNyiWNpYaQeP0/10FG/y9Y JsiTmkV3eVBOa7AUNPQHK50BZVlb4n5gsFg3c4YJesOz0lYrOyemDEtvUC5I7Wrp36Bk06GD4wA4 fbkxhpLkkuAGMF+AXGocGoFA8tBpC0vd007xbYCUun3/WzcldNBRQfFjiy/SGyBZ59cTa8XTLHkF MDhoU9clo1VBQ6DVS2d4YkG7XaR6erTHdJTR2C+vlW682SZbBAjGgoHBgYMHevdm/odc9k1Jr2pI 3T7YBcPeABs4cljSq4ThU50CfY3vrAeiExPRiSgd8svGUILMIF9OruoZFoqw9/vI4iZ9MLkcgr3a JgGyycW7pb9bUB/omcJ9Er2FJ5ivoppDWifZrxaWTrWhm781oarHouMjLfzghCNm2MWpdHL/+Bvs rV+9h+5wmIvc1x7qDHR2tXd1dYckscELmgVu4DCXMblsdQbhGg5c6/qHwhKToghWhrfeZ0fU6NgJ YdKY5Dnd0V/XTu7u94bhR+jq6Fh8XHXLP4JUTfqT9F/1tOKYmQpLnM9qCss+n8vC9XvaQ3OJzC2m 5SYI8xWQDfV9TK/mDQXnmII2X/QONa8ZjxSetYu7uCnQeevQhQ/cysGDb3KVYxraHqFe6ywYaezy PD9aee5iYtVcaiQicysoY1Fy5XJuu1ME3i5JBgsGC5GgTNAPBb3dDngr6cXb4nhcp+kuXs+7JF8t ZRJfs9SVxAPrvkiIXToLuwfggvu7JDnjsAEwwzoZhmEJ7Hs1QE5KPwRf7YeGuZJIE3fTHHfrB3I9 RS9CRPsGYfWETpl2yGLBiyQEzv0RVhZcD9uFR9W2YFN+NACdm9DNL63lXAX9sK5K9CHoCDh7CRbH SnVG2H1bO/iHfcFXt2LbJV6fNaezzxRYltn8502/r2Bqc7tnrBMEu6iiVwzdvAsYPHVnDoAm5t99 TCnc0YutJDXtluAySX6mP2Hmp3j6C0sm9NpAARbyt+wVzC3fKEuYp/C/Z6BvL9POlHmRN+YSshUD wZvCF4NIUVXbsRbkvFmQqXAxwLgc2AGyXDu1w84l5uI9B8KlOb9A73pB+S2DkUq9kmGJM9UFeoEI 0pj/99xNzdWtEP0FYe02dyUmNR2foHsJRgYBW78PIsGvABqzM8k0O2KXHQgAG/q/0ZkBLVMShKBZ ZjH9I27O0B4oGG5CG8Ciq7K6eHrxothavHYF9LNs9mr5TLHm3LbtKEBZ/SFOiMXG8Uo+6xYbMObi oD7DrHwifN/pjept7DYcplBYjaQWdDjUF5XrLwPR2DgmnOnYmdyVN4Hz6+OIE+0+T0EI7anomHu4 eAoxFyGU5PVCTTudfux1DxYoZktn0YGeEp03clAi3LDgYeFVPy+kSb6ckBdBIBh4qlulmVf86qW8 j2AO38kOnoiOqoNTn4xBhzuchwIdnRKdh8Iu+KIHVJoPVHKfP87MlcRaYRbNeanLCmYclu3PZSeS vgh4hPyHATz7w+hyly/rM4WnsB2QC0HR4fu7He5ItpcIFqCesVh0EkBomB0FleTQ0C5O7Y0Fk6xl bDdM7z6Gmcgrq7hIipQN+Vk5jS4HZEMNRoT60jIPnUPhbiZDZoWr0EcgUpoJkAcOQOl2ImNJPeIT 3gvqx4yyK7L++Ig6FhsfZYPxDyeGQXOLyHmz4DByvHm7A7tHOCC6C6CIODRHESY66W01PjoRPXns E4VZq1pdwZS/l7YUpHsipdJ1PDSr/I/9MAiaQoTE+xeS+sXKF/Dl+/K3c/9RWC6RvQv65nelW/sT xvz6fmSWcy0IRJSGwXv4t1DDR9/df6S4yVhf/GPGDn/wR3V4SsEwx63yVnET3udWSH9c2J5OotIM Wqe/m5JFUgzDA+JS0f7CFs5XVrXH+oyhucf7JD9LnSvUYBvkyB5wKzwUvLRVrAs1ML0BKzGxCmjw hf4pC+AvbuVc+hEexc3dMxo7Wt3Sr7Y5+GtgXoCWgMJeewyQOLHK3+CaC5T8uvFQoZaZRTKYdZAI DRcfyjdtLlk3nIc+O2UN+sx4jAfcgwQddMnLnJXuUPQSyB1jJb0B9clXyvPZO5k6lSFp3xWEWGLn Hx9RJ2Oj4x5ziZOet70GO2AktfGIAi0oyT3GXGFAmuBMr9Shj/FAwFrOfg1qB65891G2vQWg+ZvQ I6UXMOTPHeUAqAJxfm5uCV0NClV8o1sxDTXJxj9QVvouCm3oTgxDuJ+/bH61TwrBkqD6osgMmOIa iIvg6xE5R+WhVqjcDu1uBHYzuQ6GgkUM2ZFgbuesgNfPPH3x0bhYza+bEBTMF4zQ8w7BQO7829RU VBGgy8LyrHiCoKwvNnpsig0OR0+qMB4B6UhK8JTlz5rX0t+gee0NG9TAZw4kKnW3rqMMxNZKsc7t cPDM3FJ6kXHxi649je6kZWUuJdZcdf3MDyw7UzpLt6BtzJjnVhUKNINlYPxYqmtf4LV6k5NLSk9w SHfkWGw8jo3HwwcKqxLVctVCk+JceIXHniNjA9TZcZJNzUF9CvD3Gp6euYbGCkUMd1YsGL0IxWYv jnSlIXdB5nYk+gl3ksOWh72+1rGGg4cQAbSHff52jPnoCLX7Ozt9YVdr8rU5HVMHJ+BPMFI0jUel aS5BXuYMR5xSovZm896WwA1+bQRT61esJZRjvIyUmVxAG9yb/DySrEX0CXW+FqXBxr+c0PltFHMd jEg2vwhCO0dKGjwweMMOIYIp3wzakxmI0qwQh5+/nEAnUhj2kNe3J15Lgq6Ndrr3oh+pMN86JJEH BLsaShFrakUh1hHiJhdcWpLe3GnnnwMJvyc6sWBRE7ro0Sl1ovfoUQC+k9xhqqO70WJOQiOpFuEm wwg7EI+PwcQK7EXrbSZvpxGFDfQcPDTUe4SMnO+pH6gjMcL40ivDRclv+3p7IqwfTzmFxoRpSAOt TVzCit5kJBHaVfXi4hbTf7CW0L/ZzqB+IzPdcCxx2ebI1YSiqbmqT/jfEdPJvaY59UuhJmC9SznW MnqB161lfcMOHMGa8N23zhzxkVJ6MrDNZj2XNW+K2M69sFsLnrRttr0IkqTZbuPSK9DCSaC7S/qr A02bvfEI+c+bhCuoMyBVvmfgV4eHDrOeI0NtzF96qQSa1KwtY5K2c0FZf8sZAIsED6uxQoZcEQOv z4L8Lt//syRxLAjc3NpHpO+4W2q36Ad35+iwaB9vTVOso3KJaoV9NK0wXoxCBLOc+oUfZuOJFtyd rGWeFmvNrgKN/JvqdVr420rl99FT1tr8030MagCXZ69e+g/NBgLiyc+KpnM/cDwES1bXk6clm4IF SZ1bv/ZHQSghGyPS2sDcFqEnIIzZn0Cz9ynM39HPFqDfoFm/Huh928Hci9HnZE4pX4e9Hg0z1qr+ Tw/yD5eea39Vkp9lz3OzTr6s/wOZeBNf5256vW3ce69hlsG3guaP5wbEXwV49AoT2EDY0rfbQTDZ WXGT6RVrCautsGbQSPNaM8KGZW/j1FUaoeXwrLhExWHkQXXWJs5q3MzztTeOSO3r9n3mV4UtjNUX l/t73uel0ZH24LH4SQVk7YQ6Bhg++rHCDorImxh6faRrMKUwoCT7ozkNCCB73rqe2sw8ZdZtEAPa 88ITEesECPSGrlcuAB6Wyp4h2APdZgi1pxmUZOQ9oa42pXhOn6YP2ilznn+4V/yePqDNzxMIwRUL PnSG2xTMUYQ5xT3BQBvvpISuT1vLqbLH39GmzF72dHbD7c/NZbqDj7wnAB+5fY5Km39U2KL7Cve1 b/E5Kih7Pv2NJ+SDO+8WP6eXcX9PeiTxLZWXvZO6Q9+5tZGumcvltUYh6Swz10vP6R6sq/ljZdPT 2dlGM5iqqD3UavicpN4Pv6b3/Xbv/462d3+7z/97TyDsa2OUEVvJwR9P6nybUq1XtxTsWBiXuaXc M9FkVrzneDzQ7gvYjw/FxtQT8REVU61QRynVhXQahkTJV4wl6sztDwfbfUH7YfPO/HriCwWHNr2h WLeNi0puprCuZJdyN5M185qiPYYllwfFe1sRoXZfqFEE/HppCxYQLLdVfaZQo1kDg81bAcWm/q5n oEY4Lrln2c8XL1Bh/89haNCoC1rFAz1NjyYYggOAmvujk3h4uAd+gIIOcUcdeiaGjw1DPfbCC1IQ Eu6oweEJvNDt9e9BfInNxtfT76wBHk0we5rkPm1pC23gnJ/+xEPeO/SR+b0gfrQL7eV06Uz1X/oG bLR4IoKcM823/ILuYaWC9Td8nXnXXP8DxYYGvGz+++J3sNAesnaqSfpJZdVchidgkhuJr5inaFYe UBpOf4BkGSe4ofOaoJeV54vfcer5dsBpCyCVUvfM6VwutYncfVghO5trz4dTcZxzIyA38NxpJDoV ZUdhnfImBbY1yZiZf0RNosYYK9aNRmMU+rF01tIwgOXb3AXejL63Fy9YK+3GTOnZz2DBQwsd8S0c pPBbkIm1M7nGsATAKeY1YorD54pfMP4kSPHSrUpZq2unkRCSzT8tbIFUw++IfHhpeat0Fp7QNNNg KTN5lrvuO0JqltPpuWUQfaVbDnML7zVzOV8pZfTH7Qz/as+J4C29SN8wlDr7Eve+h9mXTEsWHyA7 X057aF7MPUPEB6OEp0+J5NyMOF0yVmBLBH27WAcECBtkuqZAnS+dymowfKeq65UCHklZS5VziCAs K/M0+6XCUkYR0Mld82KDgKh4Ll+Zf0qoEcHxy/mX0DNcbCFSTm8AlIPKYlvMhzmLj6yogyPFKF5n 7SxnoDMSCCTDVFhxE6PXtDpWEediMZtfML9RsMGs+Hl5jb1SCkA3LQmTezV52XZrJBo8DCmHnkac QbCCTGq5ejrNyZr4neJwWcAsPWvmvdZtaFoaUEln2PfzDp/v54AACZvd9Eqyegnuyp17HqyDEXXy OICgila5jfSfn8L6OVcpkL4e7Aj3fyCfi6PbrWpoM+gdH42NqyAUEBrF5Feky1U29Qwd7NmTKEPB R7lzjH47dBgv9fUcirBI77u9fYcH+nsPDcHnwXeGDg/Ir1bHrlOnXx0+Nh4bBv0mAl+n4ifJ8LbD w0FKvcItoMRx9RNHKOprZZiUurnCHHKNtWXPLlzSkusW3HU8D8RPnBxTp1T29sFBNvhhDD7trFvr sGT4Nzzihw0XixsmVHeSBXf6g227O+C4uw8DIiLqR+pY/OQJdXzKnlK7PB4Uj/O6xz6K0TyMjarj eJQVkEUFvGsX/ubD2PBxgSVlEQ26VSB3S58BtX26tJNEiYXDEs9w/b5dKrOVN2gxOitjn6TLqIyr MNkBBwF3rCSS6bS+oQiMiUAGv8tIT9mMwXWVcz2RQTYQ/xik3MCBX7LADr5TGfXodO8ifSZvELju 3I0i2I5SOdfdRejbvMtySYB7RAhzTZ8GGIsRAZyRAH6Q5NTt1gRa9+N0VbonpjtS6EcemuOTe6HE hlrUIBj27Qlhb/C1oO2jwB4o0m61ODg+pY6NxUiZ7mJHJ+In2LuxyT04t3DdlHFJoaEUI5DQOI55 aaXV479QSwMEFAACAAgAD3eKKvmvwwKmnAAAfrYBAAwAAABNUDMguPDAvS50eHS8Wv9TE+e6/90Z /4e305mKc5os2YQY7txzZqhQpCLxktge6nSYtMSaIxIvQnv9Jf8Loli/EDckIbubTXaXfNmcFkMV q4JWW4+IrULxcBpo1TP3ed7dzW7Aub9cLAwk+7yfffd53vf5/u7bhFtJ3CfcZq6QXuN5JUuyy/JT 7Y40SdQJ5a52h6SX+GRqLrWwe9fbRFlKLROelzeVm0hyIk29JcS1uZw2fSE1Q4Tv00u5AhE2K+OZ qj50R72VK3ArhF9VlpSqWkunSf6bjKrekiT50e5du3eRifGJsf/37zmc6Gz5qshJkjKXeMiNqw90 Lsmf//wXol0XNuUx0gI8oIi5Av8TkSbF5zmRuCjNFHPiLE40sQMcnYeJCP41/LxG2HPbQWfJocPE QdyE8PGcWI4TytYW0MTrHom/b1s/MI/DTeRH+R9InYYQbkx+RMh/wLokBFLZKMff5Ve4VSLVMnNO p9Pxf/30+J3ERWKEuL3CJsHJyt9Id3EyuZBeKn9DZIWPq7Vkldin1J6Jz/n7pey7ZPpfpP4IUp+M dQmbOJcyJ2ZxLvopj6Xm+PvKrKSBLqkTMJvTSZJP+XhxETaxeFmZJcpLblV/hLVAH7f1ttsGnOSv jg/aDrf1wNd3yWtlsvhoBZkIIfpC7t7l2NGf3buOwoa4+TUlp74idA/oIn5CnydXc6KLUa7mZtQ7 lY30ck4sPeLjjDp9uN3NgL3EXczMRmUcP4tq4Z98fEqekt3OFqa8odYkrYXZvUurlq5UNowbO3r6 2kCJ2kh76Az5KDJyPDo6QnpDkSGmi3RHvwiTvugoYdVXf4SULXUpxWqF28eIz8tx7rtcqsQrVft3 HJhSV4m8yUh3FVGZdTG5kiTKz7xM/kcXSPhY+5pzKrPCrHxFSnCr6iumzdPPkj9CBk9dhqP+0yOf 8PfTa8WClC9dY9jmZhdJPQUnU00ITILXNA+TeKIsVcpe+FSntevu3buSz7I1tZZ62sKk16Y1FyMs CrPc4xb41F5xj1n4rMi5EnyulS72vxc+PfJHyOSmMlGhdMVrYcDcbkyvexhlXlkWXvYfiJweiQ6f 6Y8e69cpjHY99VSq+ZjiSoljd+/q+JhtDw19Fh7uDw0N9OPV3/oDHf3+QJDpjA64mUNtf93HdA6H PguzDAkcIsHol0OEZfq6ug6yf4SILIqIAuo7QrygM4knwkup1s/Sr1IiX+53qa/6Xa3sQbwW1Vdw yeAdWk0952pmmw9F/oepbyCMpdeEBeKBL8JPak1OB06FP4uEBo+6/sR+wmR/LY4neFJMZq4z2X+X Lk6v69/zld27suvGY9HYCVj7bG6mUu5377gVktcthctcCm5Sq0k1lpFuJIsskwchK5PECyqontNq bvBBfDy7rix6DG/UNjjYHzweGulvAk1v3gsro8wXzqrn9jGKCOJvgkNalB+VbhM309nVGWBxz537 mD72IGx0sPOo65Odk+51cjWbcqnTksivuXV2ZtCI+nHneno7kfHurg87+vf7e/Z39AYZMGFuTMmm 5cok/f545kX5KreZesqA5grf5x+AlPAtV5B/y99ChLrAx+ULipacUhYRQ3p72kA41xsVjW2tb1ky cbt4T5osxxnuubCGnrE4VprSnqWXXIymaYXSxcwyy2AEcAPrB5x+Z7CF0W5AsHzlZgYHT4C2+R0s OMs3y7DPZFhYlOcSN0HHJoV4SWAZ+aL2Q04s/r045gO1Fxazy/3gQn/i4y6Hl1GW0jKnvWHW9pms SZOlGRXVXwSnXYMQI5YfgSWKpA0CraFC5Tz8FpVZ8Wf4XiwX8w9cTPmb4j30a9pc8pL4HMOR9o/U XPlb4Vs+zjIH/EEipyuTiMCVBt0PfOxigh8cPqosab++WRtgvZab4x5XxlvQx1XVvNff0/En+GOm FLWGnCWfCgvSjdS3LJNO83H8czHpKh/PVzAE8SvoFsAP1JSEh8FN1ObkRyiryOfLLgayPjCu5KWW NytMiykM8FX2QIoD2vEVch/oCNDUENQpXQIXCuEqIX2nzYFGUQVicMMUjfBr6WXCXWMKtwpnhSoa RLEAaXT2l8L17LKHgfxouvQIJyw9VebAC/7ABIOH2limcpl7rFTfsE17TOk88m/AqzKbf5B4yLS3 90ZPj9Q51lM8gjkerDm4UpoR52YTd2Fn5U31jo8yqwtn7Bh5DyQyl0p8XkgLl/GbvlSlK5lUC80m CTpCgh4RLlE13W9WXrcpb64EYQZM7EKJ41ZETskJ3wObKlgYt1IZxyRIj7huRojPbChz6Np0yUD/ xkUB4tEsRiiWQRvGyMMyuR9LVyCELZeLoMdrULTOpmoYoTM/T6/vo1F8Z0U7CCk1a+QUOzfzgbbe 7o7/irWYJcyB0PBg+L9HI0PwtD2tXiI+z67v3nWQhUQhtq9eAh5kCc0cAgf7IGGJtZr0wIkzxIUD iSeJczGXq34DXgtVHGsiai3By2PSpDxDyitqjexFuLoZc7ltcHVTO0/h8qR8DxDppUwm5qqzSfC6 dJlA6j7LlRBIjpK+cGiYRI+R4PEwCUY+Dw/jUok5+WLMZbEu5oh8kb9AMAYT7p78Cwj6XgdEVf/7 JHigg35vAlvM5TV4LCqJK+aqC4jXuoSYoMRYS0I9YSF6pCT5BeElZgXcyxhriYXX8jPSHYEaaE/r PhPQshVgZHWktZWEByIjkejQ7l2YzsVYSw68Vm6T5LzOzhvQNddO65oeGOq6pl9iWmwmvHUN0y91 HdPdSl3H8JJEsUhBo7PpmG6DhBqh4b9RpeCKYDcjXybgz3EI/ZNNlXR3RWekQddSFrzUecCs06YF ehKqc44PZS1FoDzQ2hb9qG3zrcpZn7K4BsxYe19cI5S5slSWbNuMl/z0zhbLti1u1quwtt7gu2R/ t7/nXT2GE/meE/saO/fENo9DfhrzEnTRVDD5qTSp3VEXMmNOIAGg+6O2vgCxADrBGOwNOmKuZmsw /4M0r93RB5FvGGXrg0gA4d4fHQJvFIwORT4/PtIA9WyFpoV8Wb7WgPFuxWSXp19wv2Oedd4A+v3d APRZQCAAMHkJQquwkDnvPHmqDmObt8KEWZWzT8SyWxG5r7knTfiPX9mrI9t7O9oOEdsiUYI+1vFh h2N/jLX4BgJMsj96Mkz8QxamI8b6tmA6vgg3tUeH9oyQQOgM6YxGBz49EzYeCbmlI+a2LT3N7+Gm fBnTB13Gg6wjcTvmtiSA+OAgidvJH2Ap5CtKVR7jbjbp3SHSZcwMNylXY25P401YASqaJNbRXXV8 VyBA7MIjQR/q9oMc9iEkWEOurUMufazH/9E7PTGPxTYQyDukp+MjYART7bSWXzWgvZ2OmMdjTdPj 7HV2Aoy/nyspv+vLgLk3oKwtoMk4gv4FpTj+0yczcL5tOGVRudqUXlRf5Vf32qEtzdugBQEV0gCx vY6uWIslBxAA0kUODkW/xGabBYu12GTQYTP/1Id7/f49vbEWi3tKwEYetyL81IDxbcckHqbTdoy3 eTvmUPSLyNDnOirQ0XHEEfNaPAfC4SOAof3BADZ+TFzA8V7Ma2lJwNnhDGDMDg9GwoCFTAXv0XcA 0d0xr3cbujsyMjIYJu9FhgcsZF/M69uG7Bs9GY6Sg6HToaHwiG3a2D6bEZjgSz9e4i79fOnspYkf J66N6xwH/X0AZi0wEAAqX1ReVjbAbPgLqQV5Va0ZaMj+AW7JF3QGnYfoap0h74U+NZYB0nBA2fwn tjgcELsyBZ1FHeDbCtCe5VfVTVIpyoaf7evo7vbHfNbuUIKp8Aam8/22QzGftTd9zk4nkLq6qSDP +HhqRqeFTkYGDQ4xkY75bNqlZ9aoqkklB77i9/yq/EjHYqPSEfNZ24QEVLSbyjw6z1fFsw1A31Zg akF5kP474UrggXSgBglkq22HkCBvAvRA6NSpM7jxI8cHQhgPLIPAYBdrte2UEf1wXdVzTfcv/XJ7 rx3peQ2S7ucj7iaND9ocLEzyagJ2tynxvVpLVyiZbZjF+5pZeqOfndgzBB+DgyY0LcdafXZoWs68 xLjxJKPaMK7m5q2Ydwh2UhWRWqXywgQLVQCzNjDNvlBWebPp+7WfC3sbkJ7tSGlTqpmY7DpgbBsI BMjvHeTI0EhkUFdJSOLzALJtHhCkSYxsmnzFnAgxrubtmG7qLOybpdUAaRdAq0koZC6nzRDxKr/S APRsBypX1W8aMN4GDGR0kApoNBmYweSPawD7toNzWmZZvmBHsc3bUejVpUR+rQHXKEdhGg3rSv6W jklWlTuAsURIVolyR8lKNaLc4m7qy4v9FABZMpgNFlMrwcsQScoaQceA+14HL83kl8Hukpem6+B8 GZLnZhsY8mewu8sCh7G8AcVuRaHOQ3El8sksv6xDU7+mfgWoJRESMEaN7Dlt7TE2twFliUS73RiA +HgDwrcVkVKmeFF9Swdllvl5yPIs7pGQo6oilp7oGGEx8RAwFu9IkNOUez6DTijeAPRsB+YKyl0T g+ZgC/xIoOYgXAbwRfBXuQKeBJtwRQS4zwZXxFzJVGUa2OkWY1scKpVmGxC7EJhR/KY+UKpNC/PP f3p2fa85LUWz29G0zNZuTE2ZDhgPDwBqE4qeJqCNJ0pGRBHHlVnAWEIhQXwuCnQlD0YGB8PDBrKa +kdD+oUEY2gls5w+DyVRfcggGMNQTkOubbFM62vwWxMzv+fLDRjPVkzqYoIX+dQCGgd1vkY9kF1W wXhsOQAS0LzSsrH+aBTYgKgjTIL+QDybgCLQWnUkoKPklVlYx/zXyUuwjjr0Owl2cp/FPxIqaAMm U3Ow/0boxWYvgC1BzO4vRntJlDb0OVEHAGbxT5VCSgicMV4wasP6uLFhuZJIE21rwCCYwxqsiy2q I4E6ntQcN0bUzZnzmSqRNzGIwST8vBlbsXkGN9r4xm6aAzIVv/NwU/DLyNCJQXTV/mPkcGg4NBA5 bRYPxp3erXf2Rd9qymtpWeS5FWnSBENQaJQLowRlPX8rU2gYQoIx9CAFDqHVkgoJ6HRnhVm6claa jK06gFpyIAHPqfcMDESiDRjvVgzWMvkK9ZEGENsVrlbLho2zLIctz6cY1hag65j3w6dHIl+EjGCP bVLAWTJYfVN0fiX133zWQArcVw0LgQR9IeRrW9QCClp9YBNcL2sLw0gQaukltIl88ioskKF5RkvL 4tfoaYFMJXWDKNXSNV1hG+DsdjjV2OIFwQjyBtCzHShPqucaMN7tmMDx0RFy5JTxzATkC6wtFiOB uk7hifyrMdVs4i6U0zYxgKCfqODSR4bDJk5MAc7GPxA0WBaMcsbjZsG+WVsgRgJ17LrHIfy0WuMz qB4066vfdQPu8trvugEVIBQtg6NhbJKaDFCcrwFH8za3eovn4RmJa/lVUbWj3c3b0cpdM1XBU13A 2EXKzejJhQI7mPw6O69UQYf5iQa8pwFfuUoVPvUUkll+jf+KvnFlh3u3wyWJcGPgHKUbppNVZpUX gLULp7zAVDcUGTKXCYIQ67ELpNao88yvqRPT62ZBqcxqiLMLpeHbXBDXNrVkA8bTgJGfYRkVOX26 IZFUZivPAWoXovJcxVIhdY++rgVWbjkNpbrFKyHB4B98e4y1RWckyILI0+o0NDoSOTY6SDojw4aZ K/OoTLb4jAS6gYYW0dRenxr7jawtPhsdR6M+bjt2LBQZNmelUO92qLAwvcH9TrSbU1Mo0Lpaq+/j PK6WrYxHgnGPyOMBvB1nK+XrOHv7QT2nLAPKkgsJ8gru4yofl+IgIk2mqWQG2NMA1rCwSWbzFXkM lBnwufGGqb3b0QUpaeQy6oUcLKutkkdCiaNZCna/Pg19dsJ49rQjxtrLeHWaPhein3JLyU5NGRNO H24HnE0ePLqC0iCTL+OfORlFebaiMK6Z6Q0e6QLGxj494zU9JPYSc8UGqG87NLteSBqYWupijLXV 7kiQNJrAJ7QPDe51ELsddCD6JWkPh0+RCE25h/W+iXFTGVymLcQjwVybemWLQTA1o99ROIexzRba kZCv0JQXfDrlt5BOgoHYqnckKJqV3xZuQanJtloCIUGq6etTxPOZcXVDu44cbKSNFhQeU8I9rO0e PLe0+o3pRXkMmNVuZ9fNvQW9p8/DF/fgXktMJOBrjk3+QHAvNUQlp/CQBiVu0yYHLZ/0W2k335YY 2Pr5DjDykyfDbxkfxg2FchxusIRHQjnOx7UCtQwpiRpwDt8EhdCdfTazBk9PZ2j32FoheurjtqUQ +rFPch6Zzabu83HTViFbEABprQsSZAWZi0YHSDBy0tjrEqREALQWAQnKIgArfO7vnJGsYqAHlCUv ElTcmvZwyHA9+PIHYCwRzbdBjC4RyIXOxwBXS1dibltygQQAfhSKjKB/fj86TH00FdsAs1vBjdWD gfJsRWGmr2vNi4Zne7cClUUVRDYw18GNuG2ZBRKEn2maVBlPPAQcfSiefcfctuxCPwynxkKSU+C8 jPJXuWBWJJVJXEtbooGEchzft6PnBaBouVLiIVSpE1Bk5G+Y6mrc53n9fXrRQvKbKXvJuPOHRK7W nT4H7PS3s+or4xywE5STHm99cKS9r63HOAL8YHTgDGkbGiCHQsNnsAFLz/8C/b315utR0tvRtv8A 8R8JInd6z9I4DezrJHprkuivM+otLXfDsSOOkLbBT0dPwlR4YvwpEqLHyInISXIyMkT+FgWt/ERv XTSZ54X0YgTQ8LdXP3mlJmqeGdZPZZv2D59Bte4ZHdlLdAH1t2XNgz168Ub2y7fT+4XvFr1jvSLw n+1dvX8xL3AMz8oJ8w5JL02v89PoonMlfAHD2MsGPI7RtzPoi8evuVn7JVNVLhLxf2m7tucmjqz/ ThX/w9mXRK5vsdHoZu3LV2N5bCtIGpckA/pcrlSSYnezlYRULlu7L/k79tWBwAcsICPZHt1HyJYU YkMCgUAukCUQwnIJJME4JKT2nO65q614q+JNLTXu8+tWX850nz63OcDcz4cM405SVUfpj0w8qabg GRiX0zA2lYJdSoKK5XgaMlOTk4kc/ZWNZ+VUPAZD5O89OPj77dv2xFPJSWlnFJS9ZCjCK+urr+Of g/v+to93l1kXJ7JJZw+BfEkG//zWq69syTJZTmH+t/7+91fJsyS2f/8rz5M39V/oL9PjCGWe2hJw v1Aqu3vv8+vM32b7tsLRymdAPp/zt4e4i8TyMe4RQQ1wnQ494b1zrTpHbmPcl9B+Iio/KIynD4G8 r5ZXy1poSzxY/Ja7WGN26dPgkOkVEB4idQH5pEaG+NWg2yYqFz4oZGOQnJRIO3P6x+4lIqGUp+Fp M9tpIqOobEIMoUkaDLFGqjh+P3/Cm5LEG75UuMPL2CUC2Qr5aJflWUr9aK7XOvzHtmD8IYe7XAf7 Gja8581O82tvkD22DvL+lz6d+7hxjp5S6XFyu6p3mYQdMFgiYLFG0GzN4YcyxHZckNjImpfYg+E2 S4/cNWLI2p+CWzNuy/csjOL88ifLRwp3hizX6KD9GGIr2279Lxs3cy6jgZO3FXuod5dmuyfDrELr 3cUlVmjcpGgeuEshK+2cIxYAPoPk885+x1Zjsok4tvD9NDLPzNaM2vJAI207MHW735xz6i3TZUoW x0+PDGYGWV+Ypsx4d0lnRNPC7lXzrAFDuKNHeo/sekzLwRvErYPoXGhgQ08msmkbugXDtVzeyT0V uH8q6wSp6acb8zN+59C0B4U7OJACQ+A1pYzcJ9nvQMDckeiBGf7ogTnY+DnDT9+9N6OdKK3Wyvbf 5KjIOaZc4BNEelvm874lQ/bbbseMWQPcefWpsVCGYp09ktwWYhw4WC65l796vnugeIcvOGkcA+6V b9zJz2onplXHKpOmiu9jTMPD9hHjer5FI91p71wUWeLtt63NZqMgNax/yDUtpnc/X8fDy3nGlOS9 zM6cIxRytqwN8bs136+M/XyIy+dMHKc/KIaDtZ4bdzDZbz9mywl+8cdaq7HOfrv878WzBjsta5Vf kM/ZXnMZ+XP5Uf7j4iN7mVpVdif2G8OdloYCQ9EoOcEyz+9ql0D/uMqapSMXSh8ulorn6mtQvMd4 mnudsgaMay7rwcP5Bw39D4yNdowrWZiaBOu12TEdG5th+lqczE8ohG0rJsZytm+so8BxgfUwf7yK cgZEzQU03uojxlu99IAc8Ia4TwsjkmNEkM+Af8j0H2fYuW86T7VTELGkGsvR09hL+AtivimGyiu0 FSNlYprD9hVoPv09lG7rtzpr7JHzKj3Ndarn8bxuPv3t3eemR+SR3G51L7kOzsBOP8RT2bTKb5ce mgScI4TEACTjmUw8NQ45dUqICMKueCKhpIXEEJx6v3SsuALlh8v54jkhJmyoxk1To4ccgaSc2SUk DUPnXLFlaCxd93cPMIqyfjKpoMifVdM5EQSl+cYPtr+Jh+hnTmAgp0ZBiWWyckbchjmTvmTaMFFN k9cSieJsDZoHtYq+Yk2DgybxH3B2z0ENMJGdGSDJN470Tb2gIEwmFDkzlVZ6aSFSGF8qa3PXe2lh GFPTym6cnLF0XEmN9iIiXLm20jgC9W7h1ju/64UMC9jEQY5CaaWxxv7pIeLM22MHx9Txt4N5ascG 1cHYIJtD9uiLTajxmEIe2LF4alRJK4mEPLAjrSTje/vUxvXBW+FIDm+HOfdoRegAJJ5N4ntjrP24 HE/1QQehuVb53vfdu9fqA2yl8rP6Ta61Jd/TPjVDUL+/cAoaH7YeN2Yh/zMy8vxZZhtpXat/26di GOgM4UdIH1gU2icWby2e1Tq18sYwWoakPB5PKX0wfhwLdk97UNP7oKR+i2TUM4Vu480oVIAbS8+I 6BLEcSUyWdxnaDHcbOZCBrgfrYAShNaZ4h0RJYS/ij996mr1AtPk+jIxOQsZNTUu7GyYWbqgftFh 23UjIsLugi+eymTTU0kllZUTwqaH8RzQbosoUZi7XryinaLfnBUAcPVcgxBB/Bt0y37jeBwcW0xS vDfX6peMs2NMSafUvijJ0NU7N2ExMuB8IcSQILBeZlUWYJHGN29E3dO3hrGIZIjVK1yLX64Cc3+a n18817cuHkCPFs827jO+dsyeGB2Bwqn85811KJw0LQwbIIfhu8tfPe0LiTJfr34QXFk5Na4k+mL8 oKZI5ZVWIGsdIGKoZPpunbpq4phoYgkK8ijuAiq5dzYXP1o8O/eJGOaUJ1wkiRvkHO+hixwwdvv4 eEpOiAHMo0hACeJLmU7bjOCm5WdLa6ajo5sWgpG0uktJiWnM9UhACTNmElO6S6bjnZsSYX33MXf8 jJwckfFY3DsgRjaO6J8il1KMrnYIFvKFkwuHRchhGElMMX1mSkwuHNXPEaeXPjP9htyIKBuiL4P7 TpxvPhBLTI0AnZYD4gq1bvORgIK8OKLE5KmMIiYWUD75luVNsV1a3Bg/DkZhgoKIKjEPfTpy6bUf ldO7BKh6u3Qsvzo/Tz/RuCEZCC7ZG7zZ43vjJEsgPzsKo3G1lxSAGw+/Xvji4tWjvvolFN/Plx8O 9KKC0NCLLU3rpeAmdLTyWefx8p1eWhja3zVO95ZHrOg2cn+sAR6vrYVe2DBoF6D0Af+3lxw1DqU2 3gWf4EFxm9TYXhSt0NHyQ5yX8sPOl71kPzRuVJ/k15smb+srpRPV6gxKS46wEas0P7t4trqGv9uq txex/9bJZQN0FHcbei/h88a3eqe0Uj3vIcwd7B4vnWj807Qp2oTTpSv6ireQmW8bP+i16nntROVC D9k6751F5MtS1nr6RKTGKhkCu4+9pHt6ufSVXimcrLerxz1Eaxs1CwrHDV9Eb3G93XysPdAO6F/U 29Y9wyJXyJKMh3encMb0tXEQG/riARquh1AqkU1PX1l4ZDpq2KSv9BXtAt69TucfN7zTWb6glwt3 9IqnmNkhV5prhaP52Z4JotBjb9ElPDZLp3/0FJPQK1jcWks7pB/ufFRreQiNukNmMAvJAYSHG/cQ aMxQuVtv52eLVwRLqd8sHNfPNq+gyKvVP6ifN0NyLEBzobnQOa+f9RSfPnT6kL5SWy5d8xDaSws/ VR55Cjvn8TJX6ZxrrmnrnWtN72iRkY95iy5hQyZzMS0A7nR4m0yPqknAC1gmrqZAGtzpOF95bNjC 9/oFvPmhcHJzU7Ul06dkM+AAjNHtb1PYIAo9oF+u35c2BaebjfYexX1tCh4mI92okiIEXtCScet6 1r9eBJaOVW6RvnxTcJSyZzt4bZm/6d8UPmr78WwCTpssn6NNtY6b7lhCTiqbwkowqo7TXrcpdACk KZhMyDkZJuSs/H+bqhSEzs/6TRbqX6ttqkbImn1IJ83bt6l7NA7kZBzr7lJERAmKt1qLIkrA4Z9z wOWdQ0ecqEYQRTbyAfp/a6lc5BD3W2bHrGPHcWEisMcSMF2EYZRH8H4sHEMUtHlBObIC/QxzOW82 USYmLY6Ba+u+LB6pA0D/0iKBv0esFmNQvl7Jr5o+nhuAAuxPtvq+ZhNPHvz/QN8aQSg96Qugl3n+ Ad6P87OWWCVGRpCr/X0RwyzAoC8kipeWuZIZUyEG4QS3ri380BeCzIcCp71wnbXaaZ5XgM038mVO RJGQZ2MTSiKhgK/xT2TC5U+0hQERMuCMqXWTcLtctRj3VmMWfKVj3X/1aywErTPabd8P65d/FtLD EJNTozkYj6cTInrE1MOJiMO0q9qBrm4i0zDcEVCYaoHyLYpodPGEZ8C6mriIEp8Z8DG9nGg8uEfR AvRBmM+DL776Omn5KZ0IubjPzt1np4pkWb12mAoeyWH6ofCUytPixwYSrw7z8/Vu6RwTCVhJrcWC M7ij2+qS0SZZIxnvSb9laj3bRsBT6XEbkcSNAmS3Yo/cL9LPDATMwh3Cx56cis7MF/Xq8ciWGBEm 1JSSAx7IaW9PpBuwkgmhcILXlxvgG0srpMTNKeYyeipLsHhorgB+bZG5iEWjVho65nMgrhSAu7fv XX304MoFn35Ov9n6l/bjwA7QLjbXcCO3g6291fCKdnH+J5h/37qFegAhcvSxY1y95DA7evBaXv8g f6+2iqeNGBdh13cuppLneA72WNuJBzoM8xfnL4ppUT41krYopOMb2KzPlfXD9W6Z3AYp3ByXIZHI kEVCTmUVcTU/7tinq7Q+YjqKiW2Ix8XEANR/Wl7F9e18WHkqhgQBZeUrC48ZN1CWLDEsxFw7IY/i PDisPJlJOaaAbMkI5t859Xc+xmYDQqDEA59EpAA0HzV0ISkI1RoF1LH1EiJCKIflSCeaVSEjp8bS cioWz8RUIZg0QF1NSIqQG+c3bmOUGzFMslWrVjbUlUJMlKszl2bLZ31rlS8qwrlAvjAc14RUPzQv dY/NfVav++K7c3gqxiZSKrh2WncFya5AJnZ2hJKrU65fpQBKx81/1y/8F1WCZpWNupUbHHduOrlx PNXwJE7Fp5IuAcmFk6w4c7NQhAoQeUSdSsUU33Px1FRGkVPCnw1yPSVKzgpMppXE1KgigoWgenz+ o8WTvpycGh9XVXFjyC9f55+UbvusvglhEYhNxBOjE+S6mNkVz4owuI8s0n8+P2RzSWEzUdB/1r/N P4H2d93jfUeJHJQBXDbfpJJOC/uEXOTH3wE5m5Vjuzb+UWQeporoQOvLpqm/MAL6SQM9nlb30Ns1 NcmW1P6zP5QkPEcyAIetYqO2JUH2gA3BAXKVXD792NIbbwQMOm0WG4FCMKnuUdJk8HJIWRuhw1D6 prb8K6AIvh+JBCR/rbFh0r0Wr1rH3Ua4KHQPWvoX03/O2IBJbcOCRnupuAxMv6hfIzdXEcAPG1Sl +8plXVs8iTIbRYR8LcIEUEDG830FWgfqbYfC0AUKMustkPl21DplXYgQdDX90+ZB64LsooZZrJKI EmGR581Llq7JRR2G0hfWZcVFiUJDb9+wJt2SxPh0WikLnARu7WbrIbQHOtuQHBk2PASzDQERNy5y QsjApJzO5gSAEA8gELYcppvKxzgdjSPNLwV0nKkTguJhCAyHBeVR6BzV3it9pXcsNanpF4Wcqf3o u3JhgE2W4+0SAHDSjIA3O8eCsCGJBdv59sSzEyxiY6APNoAXTNywTlqWHBEoKPBrEOFQelCUBOIy fUBhV4oqISTiSAa1MWqYh3htDIhyl5qPileKp/PvW2oc44oxM6amaTxpyKhTiR4q7V1k/e4hpOLj E9mknFZ6KGShzfHbXqaHmNmjIEOSp0wPCTvxTNw3JmeyA2JaTynnA4qb7CHVr1W+z9/vKe4er9y1 cw05CNcaP7zno4k0f9t0TTReYMoCK6AgM1bPN6+RLHlGVFFiuRuMDGFNUQvIerQ8LGQsf8/p5eFC BZnK3WmpdZFDrhwGblqYm+Lyq5qGcrfD3OBCRaBWLD+cvymiDRsuR0aeGr0CRb3wnmWhdGHJu6fe tXpieqEa0+gwBbooUdPvSEBklqri8eoaxSo5BGkXhq4MOVHLkpETDG8KIjIpvDPZ+G7L/OyiBmHu RkPvLoloIWMbmrtuCf8uepjEWBUlWpWE1AQ8A0mSzm2XLBcap7+8dGKxIaZlYpRnMysiDrPIV73j NHBZjrK4DYyQ2Do5yYVntp84+H8DJM44Hr9MVVl8RNrKSnUd6uu2WWODH5CgMFuooMBJhhAgS0hx HbSKz4TgNXvgV5ogPW/xPmha4agpJRRO/kqdoJ2qoj8wxLTxh+kzIbZJdCMwvjZneHhcvb10+FfA EXfOHPsivVGFYdNNsdbKH8BpY/lD+leJWolGbHcylJPKWJutlr5ihPLh+8mycKxaJidyAzaVnDt2 4v/8vSS6QNI9VxGQ/LB0TDugLQhIEsT55WivgBjgvyYJOiLB+F4IBKI7gjCdmISUGs8oUHmgfzwj AAdgJJ4eFRCCeDqe+kpACEFDNPywOfyQgIg3Lhkv0SiCQVKNCwDD0K4WjlarAlIUWl/nvzCPFTOE PGjMeUxNjuCNSUjGeU/Hx1V8vbMq+MgRhPJAL+i1ATGcezTkZwun5q7n7+UPOERtD1ISyCseSADM DF9eSpAJ+YtnQbvcuiWGhGhczwKNzKO09QDDpset6T/ZF43bHV4jDSdL8Kk4O/GULRR70MOg/VJ+ 2LjLVCgLd/s2TWoByngipHFfJPcx5IEEofxQTAk5+4xd2OD3vRMhRkVA/h8xxTnYhbtiDOnu69/y 5KjuyTBi7M2NYBJPJXV8ii5QiYyq7ooLYMhtFJAPPlIz7pFx6Qx7n6hNZDgONtQ4/aABT7vpfuid vGERJcD9ZUl6anwnAuBlvTu/LKKEqNEPRBTuhA4ujwMXIGJlbrEPfxcg6siZ6B74TqeTnxEVb24T hTNMxmpeQkGwtsoSXzh64ASTTISXZHDIvi6yH8bSSio24chy6gZIxCVfiigBJoPiy8RLtUNQ+Gju upmJzd1liYXUQ+FO+4SIHICMnDPdrH2jUyj5s9sYRQB1Tw6IqgRRXrCERxcFD+9ZO1pdAAjjsWip M1wU3FHUpGLrCVzEYcoPt9D42aEhctGjUFgTlJvPg395/U9bYxbi3x4yQw/JAkTuWQFuCqKkfxFW xoRBlAV/c4OPko05TUs8DhsLt28bQzEhMWWl2+aUsRdeg9grb7/Io9Xju3NJZdxKu80h0SiQlhcJ zBdy+7bsVHpEtZNwc1T27Tde3A/TSUoR99prL7/9KrDv9EBy359egOTLf2MJ3ylxWsDdNSrUbvt2 SQNMcprevf+lF155+c23ZsysiSEvnmVOJGPZdP1+UWcp4ZDdHbdlvHyvLB1o/kLv4QwPHXIk+ObN 8HgiasTu8QwPGXXk/OZYezF5+FHAzvzNAaYDnpn9C4e4M/y8TbYkf54h6Xk7AzgHUOH0m/tf2Q8v UG6C2YMwqsijoKRGZ3g4mCM5uFmjebCsG0nFeZYSN8D5QQfSK0y/hM2zRPmxCTmpJBQ1NbM1LwD/ cBUFOTJTKOlw6MGYBAq0J1vhb873MRyS35uvgAp5woYJNcs5f0cibpFZWuvBHewDFcw7RlGnEpQi erecUT1vQWr/X194c/9rL7/E20upe0JZ7ztAqaRDb/0ZfDTK9gfI8mllLLjD5nkOS+/7IzETztUf 97+x76/73uCRrgHvW8vDX1k6/C9rZcf3DAwWxkIjZcL2bfQBirC3ASrkCevZcnjZlgeimmyLi+Ou 7Vkx8FE4XvtU/v4fmEJggDPzDhEzW/xbWmue3L6NfwDF07xRaDbPs+BrC343ysiFz+acsZJ3jDyM nshbwcz8i2UUkMzj/lhkIxnzedwlFfI4xNBWGO/VTLYx7+VplqrC+uqhmU2jfWLxXcqHwPJXsLho yfHxDl6TsgXQXvAM6Lfa5/nS5O81L+NvuHmdF5of9aCEw37vJsySDhsAR54VG8DyrbAtj2LVA+yD DA4AFRqfWaAkgF7eNqPBGYDS/3n3ZCMFYITvqdU5x1c5TDasznUfokzFESyHnRfB8tiFrW89SJ6Z NiNMGeBm52nvLoyFzXUO4Lm8PL00QplZH1iOroCnl0aoLGvB4DLPW8Ji4beKvVnoPuco/SxeTO8z 9sk/oSyy6415YnTgkfRbEuFKLiTFO++49w+3XwnfvOOT6qTfw80TL7++/3VOf871PRqD/pzJniyR c68QgSvLtg0aag//8vHzdaEJ6BFDzPwCbPd8sKz1cDAV0nbJxYaGvvyoh4epsP2Yt8EznPm9rzrz RGQASt7Rw8JGRg8OeBDkHMw/fmIAHpgfQJmmVXYsMp7+IDNzwDtm+isZ2N/WSQjTyyguG5od+A9t 19rUxtGlv1PFf+itVNlk6x3KxoTgj0IIEAiJlcAOS6XYMYxhFiFRupgoH/xfiJ2LL+ARQjC6wIwA IZIQfEl8S94kDrGDncROXN4Q3rWT2nO659IjOdkvxokx0/P0zHT36e5zTnefpy3ocfWctWJ5tcUk cYJ0xCSJ0N2lJgzUC3+nzcxBLz1kiEUEsECg2LfZnByUr6JNHJkgDczn/jrodr+XVe2JmYGuS9gE He3w8sk4ZuuPJeEDYGR7m4XCMpGtPJIMsZ5qPg1tG59Nz0FjpdEYi0O4UG6ifC74zybX8LmM/4fS Xyszm7MWzNN/OGTza/gkjG7tCoeJe1yMJKoLQjeonLUCerL9KkOh11zBviqIWYM+GlJqqPi+eR8p BV02h0YAtWzXmChHyBDO6CYsdNIb9J614nbSS9KwfFmdM0w4PKGDCPPLMR5WEAPUNmTvaR8akYKh JfJX9F3NqjvlfbV8ttmKp4iX6R2QFDMGloVT9DzSbJg4uCTqCj2dObRwF3cSWchy6U+OZoOFvmUZ qJvVIYVISzFs023gJajwwcYmC/BiFRRsK842XpKhTlD0LAlN316aQXYNA4GX2SyutuC653k9b+F2 stkGm2EDL0Gzyxbw5B16bqBqSucrd7TLdoaVXziuDebQ0e4TdiLFmdfIgsYxUmsYWQxbmR0UBdHZ 3CgKmZ9A2bfkJzOb2UaeDTPDLAad1vYrd8iQI2iChb+Su4qMGyb+CsGdk6V7DdBx4gmwzl6nxQbD 3spRUGaQe8PMYUfKJA2lFX2rcg2ydAdsePEGkm9YcHNpDYtf3VfQ+4H8GxaYesIrd+AVi98t3MV+ urao/WbBP1E/4Cg48NIIMA9Vv19M57Yt5HZhl+PfcATihr5DA3SbWORaQfINA8uoVxrQvwMFO9LU bOF+Le1x9Bt4Wb6GPt7t7AMytJTLPqisLV1ZtuRFvZl/zrFxqDdJ/jmeBsIViSH9c2U2rZrQ/PPh rsBZK/RmHkQUDBRzCMNPR6IM4661AR0PMdFlYzqcnq/s/YNx5JpPZfla/y7fSzLYBBrMhAb9/Qp0 Clx4ZL3V2f/xOcNnrVCc7LF57KzQ9MrMsqbNmFBc+OAINOgSS/o20T/Ep8Jr8jmrW6PMcCwZhghR f17V1FF8DuOKTZKBl+hHnCdr53AcYkaLCV7ZSN/m2DLwUv8KBhQa/NKsbugOH3AsGXiJK1mzZHlh Yw0Dqqjw2F8XrmZuY4DxbxWr+lYoF5kVVBMvMxfZrj/cKl6cJQ1GxbB6ed3O9xFHpIGX0AEwCjGZ 19m/LxEv5JLhWDNqqGWc46Q2q65yzBl4ubbrkDI8j8ZRZuAlPCRzMXepeiDUbmm3OC4MvKStAhqS BflZneOIMOhuUcMbS5cjGrTLlQweCiRbVjWgoHGkGFTuuIFl9cowpcMwbq/CTaYPmQB0eHLkFngJ YnWlbA0f61pljSO0wEti+d1N0Ma13EOOfgIvcfEQh2FkmiFDyoz6WHlswjFaCcdFgZe0pTOFpZKm Y6aHC/98+Vh8IPGZqAKP1U2DF+ZvbK7jOtRj5QnjxHyV7zxy9I02gadzwwQadb/0EY0qwgSLwVpr YHTh04qjzVBcZFgDVb6Vf6aU1TmbmYHuj+ap3lyRUVCsJEGKx8UUw7R3twfcPMdb+3+PRkcE9fNK xaQWYuw0KlL68WQ8kKD+Kmw+zVxU50wGG6WC+iNP2FMBjLVUbMe1poSXTTwBESQU54T0+ZVv7QIw VFMtCmb5pZK5vYShmmtQdPE/85NJmcdgLTUwOnZ/W9pTVf6lrTU4fSv7JL+A6wSPzcj11IA/5iiF wf2D0k3YyWATCsbUMUdRKnvL60L+6VpmKYN+CPyXxzaTKs4bQb9a+EMv8JiWGkzlXj6nF0q36M6R 33lsazV2mMXZF3DdE3dU4NKGwZWDikwzVy5MwMP9levpH4RyTt/dNMJ6Zz7LzHO6KiAhQd9a2cis C55AyKTeATOQZ4NjipkwMh6T44lJMT5qSuPC3aKKKqrNewMJxZvKzOL/CIXf8nPpndXfeWTrS5HF Pe2+fpWGtS7MgBqsP8htqR+wfOj6czDE0YTOwL+x/x2gJicIz07TnU35kgPW7ITlLpWc72px3rcD lBv3W533McgM3ajPYVqqvhcpWTH8uyldBqrqg9mWcIbAgxCcbkqMkyuCMlv4UZthGHVxaZtTSEER g4QFqEhh/XL5NkifFTYZQxEKPB0cTch8ZszkJkj/0kEDhwn6VvmCoN3Uv9Q+I/mFwm72kcHdc6ly 3UEDhwnpT7NZJp43QRkF4d/CDTcXFdyKxeVqfkmu/FNoLHUVLSGMQoQGhN3BWLaWl2QrLaa/XvjN PGFlsAqldxxUcZiweU6Y/zj9Q/b54jOzDShzbitX3PxyI7ZTI0YCaMRT/wLoeRUFg1Bvgor/hM/W 9HfZWDx3KEr+CmU0L/E5m/8uJ64Vg3ZAd9EZ3EObioNKjibQIfBGcc8MFcOOwmsXOE4glmDQ+OSr 2OMwQftZQP1t5cf0jtnXltf0bQdhHCYo/7u2pT8QcOkSNSaObIcnjGMmtICbCfNPlRkwXOYyt3ls Sy12d7ms57HdsdmdDc7ytNbk0S6n7xQ/t/sRRkt1cMSx8Km0BUD45j+mVoExnxmTAB4MdVDFYUIx jQdF9QpMP+ezD5XHaAay1W4hANO1QTVzoXLPQR2HCcv59Y/XZwQ8/09K+wt3zWJrOcoz18Jx2eS2 hcKPytPiDRp6iMq5sYBuEM7ouw5COUyoXKUdCkZ0lEQe6CCysYDQTY2wEDy0qRoKko1beEC280/X z6FBQ8Nk8Xmaq/OYdiZZ/DA3V/UtLX8Ffgm2poClPTTur3AUODzRHPN/C6C1z+gvkInGpFdRFx1E c5igL9P9rNoFSktl4HJzDrI5FuBAoBEiTD6btINpjjnUhW6bXIp61Y86qGwwLKnAdlmwYMQ80kFj Q5H5p9pnVOIrjiZn6KYqxhmB2v+VHYxeBmVyYKvJbAQjUH7hOmhY+7Tnq2p51pGnmtFGQN2Tf7Km O1jnMEHZVz4S5r+Zv4s8ESCxPNRBamNAK9dppytg0AzHo/cdPHSYUNoXkFwuW1lYxQiBMFQWKJuA kYOyx/HFRPNZQCeLES6Mx7VU4/jtNiYPz3kHHR0mFOcOlRaVC8oPVFDxcNtPm7M8/o0jVXiB4zsz cHTN3snbA7jKtbX3oHh/mFQ3yJ3noLopPFvZYMou8lM5hwBce+FJ6Zg3VygrGKYKlVQD9wJG6qM8 ww0kpCvsG6/TrT0GHY3yA1gBHKUKJGzOwttRtpe28QQUnkM2wEhq7yC6SZ8vrwrZrHa/8BsNxJO7 ZkLLqw7SOkxY++4QMv1pJWzdbbZJsODAt/wFfu1a/obJE6OA6c+z3VDKeIEG4eEqiuE4EjsDt/CF nldv0iAyBm5hz8Fghwm5h+aYqq5Az8k+WnmCx3j0vCNPc3We+W+qntpSjXh5o5YWK1cBzZepcjU3 J1C/r2V48FieA4dhFy5Rkzv3vQPWVA2zuGxQlXRAm6uhMF1hmCC2/5+SN/Lwlmp45Y7Jho2RfM8e 5VhtMAF5PjB+Slp/bukuBrDJCQzj6oMcb2xsJA5YsxOWmAZTg0wgoTKPanGibDrHCkzdDsI6TCgr mi4wZnPt59L5wq5FrYJonrrOQtNwQBa7eeV6VnNQ12FC6Q4VH3QWbxmDr34LtzMzN6KR807uLuTk yFsgAXT4HTbgWDgMswM4u1ws7g7yi25TWgDGJER3vFUtH5r74Kg/5N//3z/1dSGX390/cJajjxYj I4lknBYHi0CU39MWdbPyOLsIancrx3iMCeiOM74dR1kHbz0bdlV1+ba+ZepBbNG8yWlzQzXkHqVV HtFcg6CR+bTL6j4Pa6mB0TglzG69uLnh8GdgAoy1+s7aJwZilrYKh5ilPGIY+sKmxcPwVg43Bot3 RZT3FWwY/YZpC2R+Wjvn8GRgQmG3yivCUC21KNBloBfSE4QcsLUGWNhVHnII3oFhIIq3Vjbwb+Wi ek59H38zrO4LyozDi4EJILZsqkb6u3NGSAlmlmqVew42OEwwbj1K5xz+C0yAmcRwn2/R5RCLToqh W2vQalm/agQv44C858IAVu6VjGbPPgcjl/dYYMJiBZfVBMOfbCuFDNz8UnDlDl1v0n5ZeeIIDkMz Lm2vaw5HBibgfiMBB+jCnjWoqZnlvMOPgQkby2T1nPIFiJJ6TnlsANXMvKMuMcG4tY8Rl/hbNMEw X+8u3HXQ2GNC4TeB/WOauLkt9FNwJi7u2xNyoEst5cjmBysrNNyEAQYN5A2HPVx4BtM6NPtnikLD 7zHcw+xzbr0NcA/RXIYetrKRfwF2RfnCUm5j3aTHpCsqLVy7sHGWHuMWiucrdCq8b3KlFXa1fznc GZgAaE3X/iWgv8eA/aj94vBoYII6LyiZtKr/ojtQrTUoOqkvKuzA6BWChihGP1w1A/TRfLyDw8y3 U8blH00v38fAfaB6l1Uz8ALL01STh548pUN5nmQ+yV0iy9/xGZprM+BiCcYR5GG1Jc0u5h7xiNpS GgWkzqIvOGhrbcFyl0p7SoartNbagtjubIao/XLo3Omdwtf8q2q/e/VP/Z/8Y2q/e+293BwubH4O vW+pXJnHoW+FFP5Q3sPR46LyZWnP3OBMH3G8tjybqjnAFP6slISznG5BE9A9wHxOs2Rz3eQwBjWd d1VgAlh30M4fsu3aRqcqfrX2nsNPgQnL6wIOEgswdfOo1hrUwve5hwpujsdAfysrHJh3T5hg6vpw YJqqMcW09qSw68A0V2NYwO5n6SIp/YkH2gr08CSfpaU6C+9jNDCt1ZjVF1Tdr1xdcrz/aE052HRj me7FryrXCruErxtMMFw6HxedvPWYkNeh0y5+mL5tO7+X7+cUh0MBE4TcNWPRaWM9myUYVc7UxVdu qb9WkServxq3djefOlwJmKDnhYV1XEnNUxuFrjfw6KZqdJUaol3ATVRNvBMIDDRT8yG86qNltayT sxgSTOMR9xo6HApZTdtHg2i7uCdUdooW2W52u8qfkN2uPADxXfuTxWEtEFxFspwij6v8CerjzQ3B OCqVvr2k2i6N3Isqd0LuhfbTIbDeH+tpMHaqjOJytSOhvLp5TiA53BtmznnMzOMcCU4zD0cuemIy 95DHNx/5C7xlzehbtiumtIg118ybPqCS7wulD/JP5z82MdTk522e0nno8yjYyNr4fXEP5rSnDLw6 o3zqcCRgAkyLYHR9Yb92o1j4xeFFwITlPNNomFpDF7lM7R/dJJwPARNs7T9Pct+gwQBjFQbBXXym PjKVRWx5h8zYorC5C8YVfwsTXjUtIv732l/+oe9m661QA58WvyLkr8Gvvbrv4taCj7H3NrH14Aa3 FA5HyUg0MiLFEtHXX/Er4Z2uSCIakUn7mWhMnDAvo+QEbh8blevr2qMR4kvKcdIWHRkZl2IRSPOM nhFjo6RLHJNiySnSGZOlMUydxlRPeEyM1dd1xMTIu6Q7GpemxgGZGpUi9XXd0XExEpHgYTFxfDJe X+dLjk7LY+SMGCFtkpQYB+MZYH2paCJGvOH/Sskj46R/ZFyUJ6Jn4hOp+rpg9BRUBAmNjCcn4VGv vj74NjjC2qBbfPfdA6j5NjkcJh4oOtSD552pMDRAQo7ilTeSSMr4O1RFNJaIiXKCIKUlfAdYucnI qJgiYgJJLMkZeAg0A9bgWBKqv77upBhOvIvnEUi7dOpUCgW+M9hXX3f0SGKcQJXJZ6RYXIylQKjC YWkEX9NwbGQUCtgJN8an4UUgbhF2BxJjUyQehXfiiZPDx5vr67qik/jGRJS0JyekA20BRl5KGvzS NHGNSQch/u1eT+9ACKo14O8MYbQg5kVwBQeh7J5AsNNDTmJsmIAfGsPngl/xCEqoy0sG8aerx4u7 mns9Pa5er9Ad6EKCyx6XNzg4AOIe8JAub8jlBSC06uHJ+rreFPFF4wnilhPQND2eE15kwQzCw41A 63hqEKPItRvxdyELdAJxJEy6olNTUN0IGvB34Jf19+Oe0y6PK9gP6SANg/CrH9MEEoRWgkEjTiXB FYbW6ggnE5A/mErCA2USEifEyWgiSjdvt9TXxaehA5KYhJIEsBPeYKfXz17XAQXwBHs9fnIqBX05 Eofne2LyBOkbl8PyVH3dYEAYDJBeF2kLtLUNkl53hycYhAIJpGsg1HWwItLKRKQJxfuAeqrbFfIG +jwuo5/AoIgncXsC/2n/JrAg+X63B8QGhAcpAoLwe5crCBfugN/vdff8ozsIbe4N9pCTXS7fQK9g xH452ApiFFgNyJh7IPOHPCmyoQKqyec54fJ7XQ0rFXWxmKessOX3F5+9haMLjlvQA9yxaDwepWel XH7c4w1C4/b4fF6QlhgK7bsi9MZoONrgGhXHZJzzQiJMFzBnyGPjCQAICXlSCktxGCkHB7p6vKRn IOjqDfQHkDGeTpRyBMRaoEfduz0nPT7szH0BGASxq3Rhh24nh0CssYWCjT3w9kHqPux3+V1CmyeE EXJ8Plc79HV2lhr5jWlgPJe7PwCN2Bf09rp8JOTGPeoH23wsOmnD6WQcKpnOAQfQin3RZFiKSNAE fbIYiZr1yP2Cw0gTuxsngdiYiA1u3ITBYyqGe9vjSLoMY8NAJ4wVbq/bEwyQ/qAXqq9fCP0HDKpQ 316MHQs/YhIObdiIfhH/JuCHNA2XQek0zvNxiYoB/JiCORCegOrJSfGM9Kp33/VZvK60xl8pVfaA P3QoaJ/7gj4QP4RFg2L2Ihl2m7fTvNcba2yTx/A8YrtroK3fOgPjj46KyVNQASDNQWR3M28EoA9N wPQPNeQOBPu4ky+hkWhsiqkSJzCGA/fnhChHMNXf5eEOupwQI10SHp5lhNuD/s6TXu6Qy2BkbFqW esXwZDwhSZEDaYDmA2kAlw+E0Gs1gCssj0jEG8ETHTJMY0OHj79Rnfg2aGZQy4Pd1iklVNRSoMpK YTKEFQQI92Bf0BOyTiq5UyDO8TjpQpUOHnqMtIXxEAzT1QDv8Q+6hu3DS55ISkTcm6QPXsk0udBE ikzLMImFEmIsbozXmBWa3Wc3rgdaPSyCBjF0uPVNcnJcTkSkFOmIguYdgi4Yp4c/2sJJCQvi87kD AfvEE8gOklSTbuPd41IkOgl/IwD1e4MnXLZI+OUYKAL0I1tIB4zL9Lm9ydHRFGkTIxMwBpymSSfl +PgEjM4NPlAs8Xv7Bjo62m3h6UuePk3aRcxnVl6o1xXqso9IhSbF+DiOHn3JyakJq1l60fKBRgEt VZYomTy+zhs5LUfkBFSXOAqGBBYy5A8E+uwDVaFINDpF2qNjYyn6k7UHuw4lUmEJswx42j32KcFQ UhqVENeMONIL1gg2wtsHIujHDkbQQ13Dh4/bI40rPo4FaiX+pOAOS2KMhFCJp9LtglnXZ0k3NOco CUpheQznF9reWNGdMTAyguIIVlfbgLtHsI9Rk7bkyIQQEPxyRGKS1D8tRRIpwYMTNOlHQw77iA+b 2T6w5waxxY968ziowJFRbFsR2jYyBth2mDA83AgG2i9MR8wgYt/kj4IZGhkZZz2iZZg7xwddgrSw 0tJf30aLx+PxcwNcZwzGLRDDlNnK0QkZS+YPdLw1jMLq855gg+3pd5j4eUmXhOYs1AXIDRS4sbER RRwyBTo6Qn3cEb/A6dPG/Ad98rh9aUOPvQwKn+ualGLyCPQz7Dcev3+QO7naJ0UiqWk5Lhmj1Klo EuoWNB+UX89bfV48xDpsCLD0DkzN8UQ0jJ3nzTeJHw+jk17Z6DVt0ImiIxO4Kk07TMfAMHfCNRQ5 nWQvQWwAGvX/aLuW3caRJbtvoP+Bq7ILaBZsWZZVvaNeFm29LimXy9W4SKTElMQxxdTlwy7VQv8y mB+42xkMMH81mOWcSD5TVtfdtBtGl2yeIPMREXkiIpP6IhPhGWMKVEb+s4D3m0sahKUQHoVKXduq HYB15dLngdGjBkTVjJFvEpAnncg+Y0SLj/MIyvB3olegjIercoDmIHYvfpzdBB0Z8+gfqYDnkcpL vYM9Nt7FHkfTh96k77rVyjuSqfJYWPn746ljVwaItV9sZeQjWMMqNH8xuiuw017EtxwrShKfI0Br g/RN+o9Dew4zHHf6uZdGXAyE0f00Nsi5EvJavaygN6y91wP/OZjPoQQSEZuAbiGUjGKayodJr2Z3 RuYm1tB8WuddFWDW/3PBrdcqKhzUVov8zOGAv8g0wvTGlCxw0ImOgjrTGpnIjydm4amK2LAIRtzL QltrXjMsBeVJJOh20Ji18PbvogOX76IDdw89C9Z/tKvBMO5Sj8fGjCY8yVEGAgqEHabREysRepgb 6vKKgw9QKk2I140A/VikUajG/46/LujYLkVRDizb2JCvinwsYyugs2xADKcMFw2CqI7ELmhi4D1h g1th8MB/UQwbnzHIXmxwjPNahlj0I0mscqIsdwlAbHjyFeoA+33ZG15KqQutocRf8saa6p0yZv5u GfWWLef8+verq49kFN3efZ++vua8+fvl548qjvqSvdQb8bUzf8LfG+rvCBXUl+PdPtgqqj6/+r2h NHvavVfflIn4zLAcUl+VNnmcOqMeQFc3AE0f5sX31nWn+HPr9wb9+dEe9bKD0e5vxnA6/9B1rG9P 9P5iF8+9oufSe9MRlFOrqYkNZUvde/qaPPr9RkX/E3vStydHh9gVZwqJoCw3xoT7AVnX3LHmx68f UUaElU2+8MhP43fR54t30eeLy/t+f1bbX/MsxI7WsnL6PwHUsDA+tW01IFN+GMollNGAzRPkyhpb 9RNDHBeSRKiX2iR0mpVAzY7VqR8WWvDF3lhHHEvauZeKxHg1iaIsofmBiD+SyPV8aNfPDiUbPzbw Q+2jnAFhWiMiBlUfEPSgC/A/dPHmsd871DbwvgrD873wLDFi8MGMp6/8SN2obd9OD7Ximw/joaSo +A6HBZshzGcL3rVWcqPGx9KAx15Lhbi8gJIeGvUmC2VsAhQfA3LGA/GdnxHy0h1ah9ou3njDsywI XWzAHA61chuIlcGJMQSUvA2MczTJ/06DdHk1ehgdagW3IA0CDK0wztdSeiEZ/W/Gdm9QGjBQEk1q Y63oRm2MKI1M8+WpA/wEux5b94dawW0L92TsZWqsyHXhjrQ1joCtYf/pUKu1EcNa+1FA125G9u2h VmELlBPi2RzC5YkfdAsVoNG+mvnXLFBeqBDt3xCimWs0CI4uMcAzYuNFBik8nG3bn5LvyXsY2+d3 sbXW51G/961cO0ZYvr/Rog2+jM6U129OXv/1l5sLdfnzaXECXI5I1S9PAr7g+tVw+lARg6FMY1HG fEMZYAW4uZ4NnyoaPtvsY3DZgCKH1cpPfCBaiJIrljBDjCyw6OPCZ3syrzgBsZ5NJNP1JmOgILpg 6Fja2o3utFcRgq70OJEKGcJHRAiwf/3l802n060INn4BGY7jLPnRo+8MqSg1COpSwtR3G7T+rj8Y dKr3wNwJhKkdgZX0j5trxM/y1ejs1b9EmOfW02NFmBEb7l+54sS0IiKwMMFO/IVKr//1CtZ+FwVr zKwuO6sCxgZY2DKL5hzjgXgeXEgPnug//ieLGTvTJz1m7EhEU7eFtRFRRdygrO2Sor/pdGTXYkZK PPgyCzNu4VvgUM/ijPkhxqEQ0MnVEdGp+if6RO/8IImGUosuVCT0l4AOHm779WhxkK6FiKvYlfJf 4m36Q89/wAMSwXa57xn3IXGoJ/gq6B6FhZaLsano7YTnd7cRv+DzI0huIlTaZDqfOjV2O5GIgXxY i9Hx11mw6YBdKWXpqZBzOnlCyFmLHsP99zxnxJceX6XLdAfY44M5t2qR42NqzjFsFEWH2TQVfxlk rx6DzNdvdseuhZBff/ggfVmoCWeJ8PcHzAefFLX78S7x1M1//t9fr6wPDXbWviiVFWH2Banf3/Mr 1QuFcOXSmC4TqhIXV69KJcTVK+OBWKthkW1LT8VFlHkr01dKpHKMSuSRR9WVq+pKU2nbQ7iS0Vok CV8gtBr4SvVycK3FN1QM36QcrkLUELWWtw0HNCjIkl1D9RZDAn2u1AszeWlYy02SYt47WLVLSKNq MDTpG7yn3PHqatVoyvvJXXalngP7oydiNN04pyxiUAxFz65c5B/Kf2IdRkB+BIMJlN7xj2nkr/0Q C4EKJZWfjpVLANC1q7zBH9kt4ndRw9a7OM37qTMxs3Ry9tF1H/pu/vcspXYvHVoPRv4KrAMOTvAl LTcjezyDbdIgZR+/3dvzX38ZW12irDQk6uOkjxC4l+f6M10r0/4m3A4WKP/QKK9fa9ezy9AMkK7I CPHLZZFsVWr2JtEKL+30+3mydgm19EzQNPh8Yxf5MZX0ppZru5lySR77sblVvHQXUPnHHVlP/Uy3 4oDvRWRGwl+DTi/ItMo8LzUyzh+9y59sck9SAegRAbKZqdgrj3dmFpT+9epQlXeMf/77f//vf/3T yHf5jIyDMfuLEz+228+DpJFMsbiZEzBhL9vJpC6zPDxSl5kVbcFmZLg2Hzc8YZw9SnJRqzTApyio CxZB07HgiLMvvmD9kFFxqRRg3SKAggDrquPtvjA7Yo8nMPguRoUCNsSK9UOGhRj0qQiiKG8QLeTe RENIsxg8HYMHYI9CPCP8L0XsMqaCiB+euTspQ/TAxJrD1Ju7NGj7FNRNt1sRMT9UT6ANErnMw+jB LCKtUYofk7KRfpSVS6iNBVAFU3mPU9wlYl8QclHBmX1gY8TbfMO6PBJ7sx96FDuxN9LNU9ImwdSA TUPBwBPOIowBBbyZ6NPkySlis9E+3Ecew6JC/5oubavAEG8FsxBngXJkMmOrN50UIdsY5hCG3OxG e+XW65A8VCsgPYlwlAGo5mKMu2LtoTyPdt88WiuEBpH8IUIN0NQAE/Bd+2wLLhGA8pKPQCfPdxTz Xv5mND5qoi1NdMZ3nKlWaSC9Y3NYADR7IV/roKbeNXoDnNJIDdM4GiH+I+s6Gljgxtbo0Cw6tOUB 94TpiFW+uylmcsXGe0YuuZJwi1ePkUT8gXoRm10e+Lh36PO60ubw9hu4zaiCwcjdsgmi8QI+QaR+ XfQthFEnPGTziIfxCk4SxIWtIrllE/GKXkTPNV0fW073qXjTAxR2uTdmcK3riJZSk9L8xA26UMtK wLaKdz7UNRwKjwfFzPehJKFJeqtUsXy3RS7ZeiNpWgGim5gtBI1aXR2VQPutwFBEso5pXZzAyFBo N2o13oLKVrKe3sxW8wR4J0LlAzXgif58UfUE0oLK2nP0ic6QWcs0oVmtoKPDTdWnYB/CmYSx3ObW nb3EsETfs8NN2blnhuBiB12MTEs9n9me4Bq2eQJLvmYE1w6Hzr0SPbcPN2UHE/8ZNoMgLJaB54uo RD2xw03ZsT38Pt/BqaJ3GDAs3pguuDI/fI7ZUJxBf++F2OFjeQO3bx7aRXexfKllCebGHnlYGHnf mo8O+QHNMULAQK5M23iUaeAhaoSW7hNFNRCcKA993kFQT4CQYnvwZp4UTqU/h/nmBzjHIqGa4JKb DfadNTVE6xjxVb/ePrpu+eQpSYX9pA7Mj3ZWwE4A5kOrW2nBGa5xhOumkQ44bnOfhpe5sE5KdNaR x20fwEWxRDK1TUBDHveCbItUl9bEynaBLQ9eVNh76kQo1chrwOOekBNjMSJfDdV8gyKuRw+fpbud SGINfdwl2K52/bgjM0ncgY69Ck8b6fLkRYV14Ot9HXLcBTIQlZVidxhC1kn9INEEmicEKCHKXzHw UahhWyewWVgHPqpD22+guBkjJuJrwMZxnx4SP2B+wmJo204bysZx3x4x8Eof9wx2Uo1DvzyYAazI sJNsulk/wFCMVRq9uLndHZbvfVCbSEWANSFIZAhv/Mr4lvksxsyCMnqkjES+VU9095fdpn3qNpQ8 YbZya55akD99wkwk9Ce/YLyZfMFidPnHDVw4J2eq7hGD8FaWk8k1NDmaawQmZofrd2+eRgn9Xq3T KModsztx9OD2aTAZLIMmqzJ2XaB5cVKgD0e9Ya4sLTIDn+7WUPBA0cwa8c8FTvdwqGruew15upc2 eXos6cRr9Xaf7uhdyX4U6vp076iSFa7hJGwsiTJelvwuEzrdSyw+MaOdDFi9iddoIs0/EYnoyx0i DXq6o7RQWaDnMAwwbhlqnb3WOzsSPAI/hO5TEdVktCydQQu5NqKtiz8RikjIYp6/Aq/D2srio2lu NX4qSVtnA81aW82fCdDer31tFchEWv9SJPMQPqOwPdTtstX+mXSeWmRY0WCmRw+++emw2Fumismk c/zNNN/8dGDGfO0vNfhPh6VwgeTCyvA3F2z9bL7V5jsVGlS8MBP76ajMYNLaSLR/OhJqq0PiL9mC B0sZ6pI/HQcqzmddgzdm8YbYFXsOdSNr62Pjii2eIzGGiGK0QWxXYwE3Y2TPory0GovGNW0X8pNU lAp5j/WmYFX+s/hAFGQs8JjQX8aIEgL4+QmoE4M5w4n7EV8Goi5cMC0IIxzRxRXB9V+oc09oifbQ gnmR3DTwVr4IPJN2AKlqIHM3CAaLMZj2+uXbNcbSE1iM5zygZIVpYbHHwMfUvnyr2bk7dVX0SDNe ENDp5L589cZYhs9CxJS3UJVNoyMCn2ygxM7L13AAS6uwcScjj4dm9r5wx/eKMZhS7aogaVJ6exXc xuShsH74gSfiRIszaVdQ8TaOsYzQ7H5Ax53MgaDC3DoucfPy3RvAYSVlQ0QPIkEAS8VqiraN8d7o 71XNbkV1uypcdqhGUNC3iOoUlE/p0FbOZFPHsTFweVcjzC+xQfN+H5XM7MFxDo2CvKVRxPcII7in wjhVYqBkTgcLxLPMSe7EoqJGTuYmHITHpx2ewtSS6Dm2/0h1kqybFCvPaV8KFE8dCygwX2nDUCvH fE/QFWl0KzcwsScmAFkv6JeZiFZiSeOerguI8+XQyPlavu/V7FA2VLve0K6rF91bsaoZWZHQkE0N aRtDcDhMRyyClQrfKYyiYpAm1NKERsQn062GaGsId0uqF8BEDNqTDc2jjYVJXeJK79LjsO/0jZ7d U/tn3FG/PzNGljvPtsRkJ9MnUwadzUnXRLKeTBeJ2SsXuJmQu3J+MmzzCKvyU+5O8OdzK4DGhDzx S1vLZVp/KqPB2jqs/31JfH+Mn6iOy5lXiRvy3W6P9f9VAx31aSj2VQophxx15S6NKR17S1sT6rCj 1rs7mDwMWixiDXbU+mwvOFiS2sJVR14ftZ9cYzfwtwsNdNR+2g6HNYVCPk9uNWTzDRLRm0e2yEG8 v2vYo74QeYIPwW/MLnTJfZoAmPfGcPfhkiJ90mFS/k4ZwFKt4NDIydJUVQsQ6dMGEFqyjFdwK8M2 tiXPzvENDU+KMJISAR3xbDTZInqZCwwGLgSy7pU7ac1bcDxmvRbkZDqyofs5K5oipvE5ZdrISd7J TWh+hS14+bxPxz14h5wD0S/2SiU6RlTWzyEP88GhkXOdaZpkixG58FrmeWbd9gHKujLja0GpxIjD 7JjLC3o+s2YEauagncAd+FKo3LJRBQgzaw6XlhOXGQK6PXO3cAcZGwBrzpLWTGlnluPoh7R3ohSH 18wJDMQx4xgf08JYBaze4gfaMHSRw9LgA/2PK7NQnzRYo4Rxptz1I0URWHReKKsdZAl7+bqghONt Sblz4WYpzMZLDAsdWAAdeKQFzXRV8KU6VB8CJdg6IQijDJ81VLtCuf4WAUAvDZeFjmWYz1U32VMK lclYMUUgNNu3sqY+M+sLVqjPRY9fwF2TxKfpTON80Zn1Lap35v0CeQEF4FvzlnIFxKcGwV4Dtiog I+ATnWx4hZJ5C0HxegF2ugDn3RHREvMeCG8t3kbJvB4nz/qY8KucZsxEQjxxx2gqEJpEsPtAPaRi 77lA44RAR9D3mGmw5glYVggWS64hWyeQfcrBR/6yTHDn2HaJdQlLmWrYMXxonNRxl6d6ZcMpZxlq tTeVcfwYcRpRzVJr+2XjxFNsCvA4VEUbvstT3aSEzFZGu42Eb9LQp7rq8iSNyMOrLXQs/0I4Tax9 SozqIi++x1ne9vcofzb/rPw5Mw7G/K98IvXUHR5ODpAq91cDAtipAaHVD7P54r/IqDbqZe3zCC0Z aOkOSlDy7hx9Sr8fAKTv14Hn9BMN3TyhKmpqvtDU9Nn5fMMjaI5KzvCsmIS44qN2k9aJm6jkuXKU NlXJVNa3J2IRqYJiqVdDe9Qt6qJ0qjo79xTChimfi6WCzq7YYblhqhJjRWmUxFgplneTvPPU84rH 2JN7VlRIZ374zAaB3HvFQ1gHpqpW3aybkFU1QOb7RUfHrGcVRVL6hb+GGCc8x4v8VcKwyKqzDBTq +HHxVCzJ3aI8OpN03C5PZdBXTyUb5YQpZingztwpKqPF+w8oY2n0hNjRfl61vyGo1rKHweCpqJPS ebM9UwfOPgxoTzJTr1g4XwmyTwo3Ly8bH7N0WEdQVBOrGLSggn97oJNDOQP+WwpqDTcKluWpKmKV mMhxzTouH0UKfzq02V4NYy8tfFou0qqJdPzlHkEzo4NWGqhdB8mN2Prw/s6G72JZlP4yZE5+M2RW HUXwkARZjWetAl8sAtXKn4vVO5jz7wQ6OxYVcc6R9S4OFKFIEjheTxHjWIPWuzag417a1Xqf6Ju6 KLZnA9oYArvImhiR0dSFruvds1UFStVN6PADo4MRGrjeqXuVMGTqFw1U748iHsfl4RxX7wzGhNln W6qS6aB6n6hSq6b8tqwFZ6hWvRMO7FcCgh8NU2+7S/5irN+j3mwXSwuopcDSN11BLfY6tN5yYo0L yj3AUx4rQave+keh0qYq+NjwrTo/XAffXOjgR4yvSqMd285NvSf5XgmqwlG2YxD55bYRx+rZ06L6 qUaFzqFAh2HlBcKedIqKpwOHtpCvKhj1l6lSA6rIBQV20nsq6p4Oj8TCp90X++0OHiZXqexYVM5m 6yei/OJElJntDlRn5iIf5KsQnMK/50xW/bITwnvla9BNlXJhA7Xoq8x2nqzRJFunJFXdVSpSp7mg XKZ9SkZtpPCVoyXS7aS5bjuDkdUtSpvOp4EqU3xgs0+daK8S6DKjJTbrikAsIp4IPfHp2N2hVdQ8 HUomRh5tmfmudJ8SwIM6o8nhzbdwRz2HDAXWmlQDYXex9ORc2KFlxlXhWxZP3dGebYH1tQq2HXtu saIe6vgJRR5YOxQhFqRTtLTVEvzOtNMpa6KOXCz8TEd9vo1N8hRlmAxkvyyKZi8U4kyNmHIaNBdj CkdWCUITqoexIaa1Ck9y+eYJebKegR9B01V9o6+WfZfTPo80gq9bCu0Wrfot1B0+IExYyH89af9P 29X0tm5m57/yzuY6AUogcVzDs6QkWuI1JWpEyhpnQ9ASbTGWSJWSrqK78D9qOwUmmNtpgwlQBC3Q ouiuuy6KLtsi/Qc9z3k/aesGWSSL+MbWcySRfN9znvP5tktgJnEvMSnXSb0Qya44kOFGgs5Zi3Ev M8lWQmUapehJWq8W0v2lD9I+zCSOIpN+ndTy9pCpqApwk8fSXNBvA5N0ndRfw+cAUx/CS+X375A6 cNebFLhsCdBCrzgTT1eJG6ihdx2TeZ3UR/QfLxHR4pZ0rJx8KfCo5fGTTH2MZGZSsSSZxc19ydmw qlW0oXDnr3DxMhs3BXxwx+OaTEeZycTSDsx62TDresSXnqQGMPmj5E3fMylY/JLM8+a+5lYHWg2l 2kyJP8xMijXJ12TeavAqMsgagLCzYjgJ2cBcBNt10eSrRa5ULMd7TbKnJXZuxTIrpmItxN2GhWJC e27o25FpbslfnJS3mv31x058k22Vs1uG8yifL1d5JStmRLJvGm4fbElcWYnMTHshLeZXiMUTNZgj 6e3x1iLtn5C5BY+41+ZPvs3FZ87b3OZ0q/NK1d6AweuhJVoEUw8u9C16h8lWfe5+RTna6ojCM/oJ 5ql3hBK5cEQyJaIIitmXSTeOTEY2mdcrtqrEZUmPmTXSRQOBIkdmcocuwoL5PtiUrQQrUmTB3K3x yo4o8PkL8EyRWZxq+mjfNzXJV4LuaFXMn4rqfUmbkp4BprnN4fUreOBHJgFLNGTljRsUALNWYtJ7 tKsh6E5M4jUp5rSd9O2CSpWlcOSQu68oyQGfFKsuFpykrump1HuTIiDEyGRZE84skdaRCpI1brIu HezMJFgJe+DZEnTHEJmtjqJLpE2gTlPD0WKiqFSyJOVFiz/fomrhWqreJkN+hdi+WRhS5OqECNra H4ypwjQtkz8lYHMk1UVbnhT+mpwn+j/VwN8rdTZOiZxbEVgFyMAM0qqrUITZwl442JXE8k5FjCLc Iv7GqtYWmCVhdGtSpkm5IjBG7zWefy/j7ho2jE2KlENu4g32zMO+eloVnuRNArtNqIcliAiYrc7S KvDI0rTBpTQtuJU3bLb0le7JedUVyUri/KQEfSC3GWBB01dGe5mRGpvkKEnR9gXl80JOhQnWfuj7 OZAFQauX8XqU4KUjmEGQx7JoyMimRpOyItqaxWeYmlc3JhtNtoh854KzuXZL3gQ2L5o8kSqkTdPL 35Uy7hHIC9m1K0CSm7BnkqLJU7kgE3XgIiHV1uqiLgwqA+rzK7pZ1rVRoMs2KKQLXBdrYiHONx3G NybTmawxL8NT+Vrk2bIel3PVGU/PUSJj2o064ZlsiDPm+6wD/3PHtb0ahWCAYl/JBrN32JHkzN2Q LHsLdmFh0t/0zrP7AoG/7PMW8PIVkDfFvf3UkclmJqiH7NXzXU2Mn8kJWA82B6mhQjFrQyJI1KY5 SbSpH49N7sF57dT1DhtJf0hKHFxnN2m9zItj9hsvPXABH8aJ6BI6Ak5MapMX1rLc6JVzxjF02s/s kE+31iFXYpdtMRi61utX7dfJV+PquAzt0E6tcZIGgcl7EhUsVvI7eqQyztw4PgFtApSAdL9IBXJi Gj5xKGkd18M760cKXThCQ+mRd2hhwAhh6VuSp/CXBl8WQjZCeCj1x6jJFvDKAaqOCS7MkMSbjb3G 48lr7gSHxAuqx1W5Xa65NR2p5WPdPLXQ5w6aiBXdCu7drknXO4EnBb5wwGRYNjqiwHdTIyd3Ju+Z 7JrjBnW4INE7Yz3Su9+anGeyO37NOeYMDN5JT0iUpjhADRvoy9oQGgk4t4BkX8JvyBdk4Jzy+mTa iUzOMyE1TfcNtp4eS6nX0xQZK01f9vSddw1ZYUMdZZTCWZ8Sf/USPygXBaKK0iQvicS5eM1mLJ5j 9NiA0DYOnVf485d4WSz9iO5jx01LppNrkw0lwvmAZFuyrA8F900c1HJtHKdEiVxakYZWKj3QeL8z iFuTDU1UmNojIoBnnpYmVylxmrtoHDen0qqYLxHGjO0anX5pU6HJ/n0pfrPPd01NhpW7dsg6NRh8 mOz2a3pQ1dmqUqfLJLNbD2ESKYlfzN1K/eHQJELTfL0mJ+ZYST9rB4f+/iivf6gdm5TzVYrApKjK YUJ3jf/DndM3ATMRTU40LebLqt5xb66HzrJsumENaioI04Asqs6OpsV6s5ODbr0+ET7ujm3hLl7h aC/ZuEAaoOpEsZS0aIjdcOmfh3AYuj1UA1GiQyPpIBiYjKhsX6+K46IpZcRnW+SYY2B3NeEzkxrl Jin08KmUwKomnYw8ctZpoc8tumwWZMz2KETSP1rQCwOFLvb8Nd3gamsIkkJdGhRZWsQyyCdEdJnz Xxw5gs0i79NWEyjJK1eS8DJWGiOo39g8sQT/2l7ldflAG6JHWqBCu4Q3LMjxyfy/2POYkpaQvdhr rJ+03sheGGiFQbHaZLLYpSVjr/omus5MNP5Ne2EiqV0+lMWCI04++RyFbjlQ72Pvy3glq509MHBr eBTu6jUOLIbIQbHbGmUEBu+I6TQqxCZ1/QADjLQVpNm9l8GtsGrJ2NtBOolnf3gcIHGj7gpq78It Z4DGpFxk0IiY4tJEGBTaXit9WVKF3LK8lYVmuA66848FFoWWIqKic6vpktYhrg+ZGDK4g/pAQrR2 +jW0alrTstZi8dCkWtMl0VbaRll6KKWnumip+HQwCUxmlRZUgVX2KKu9PL86EdJ3NLISvjgp/Lbm GPWL6mclcnlS5PWHKaHw+tqkW9Py4SGvjrRAuekl08FD5OLsZcWkK79QXAheGJQKkstvkMojcrHa /qQ3OP+xNxjWFep/dAVoGo9CElF3g9QnbfH8a3iLMi1WuKZPgS9fg6cVT4J6QTgIf0f4K40/Gnwo m/V0KkXDs/T5iy/09dOD8PwHjKZTL097Mb2srm6/4AJKRGIRE9bprXQ69gmkrme/yedws5/2aDha rZr8fd20gJevgb2Cpzti+hup5FzslvtHMfrVrx7zluTVa8nr/fxJkCss7s5yTS8kWnGlFjoUB2aM onzA8CvUbTzWO/rA/pLUUN0SPz8hfrYWqFUk8ji0bW0Kf+L6acNifs2afmDyBX1WS+LEjYhKHrD+ VNJV6Uz1LzFkGMUBX3ysOCAVz+LuZx1SGU6Iwr0eiCYnVoYTQa+Oo7tP+pPATzGFeRCmCaZyBVEU z14P3JKjabiaBuMd5fBaNDAPTwzdUkP43hUoxR3XG91gakY9tJG64ZTH6hEyEJ070Q2iJIwnn8qg xMgOg2jL8otv+v7kejq6CSJzPZm6njRM/VHYFSeFd+UOcSwcr/JPf4mD2E+i9IuoF3nrj4LUnaf1 NidrKkzvhDISbmAcTnPgTrr6uCOORdp1h1i1FiqaMHnmRQt8cRqsHFys7MhU6CqRy9Mik2IBIljq YJBCX51Gp9AXPOTVRTvDrlpoLmITixpjvh5rgUCksKFWJfuR627PyJES03OvF7oTsPAHOzPDgJLU nX6FP5Crzq7Ors1cp6NuFLjTsKYVigWSfG20OActWJWT1k4KGclwHvR01Asmz84RNJzgPMDAfpI2 qBHZoL6tevzU66CRLVkRLVYKbToJ/cGzcxTNlNtkB0Q+iaitXtSyKvTFKbR1SqaJn10/O6fR4A9w MqS5QbAib4qXEbAphzSd02mmW3pQ3ghrFhXVRMuVHb6lvZA8OyfT3OYYupnbVCDn1onpcj6aWwFy bcFIuB88O0fe3vIQtHLrdZf0hOodt5Lb1U74bPDsHH5L+GyQr1BS4WSXboPJtPvsnHpL3G8/z+k5 rnZb77ZezfOqdqspbmPsTuf429uarnRL3zrfcZey9/IPUm7mR9H1s3McLkp4HqAdmSUXXJ3PPRQa P+pnz86JuLSQHrPu0pRIcuHAEjfsek+UUKYjtexkYvqypWzT0Dr05EgsCwqenXNxASKF0ad9/bhf md7GWZDOgmfnWNwZ6S/1n6yPJR8Y1t1tGJsN/KH37JyRO1vSxsDd4MkOs2W53WhqrLDnbWwrK6wg F20IUyp4gLsW6rKNwhJS8zXW+baFvGojZ8jfE6EmH1kWW6oKVC0T9q+fr9xLKlWGvFM+OtEyDIIN nq/c60GQJyp1UyVX5C7L1aIxz0KKXLwQSSr6Rh6n60OuhLW6Q0lcvpBIkZuUPSw2JwrsSNcsaCwm k6NHF7TTDArjA3LB7jRNm4VRFD47B+7yViVuTZwZKVhZjYY0RevLkVTinpDHCWBZKT2kJRZWwmmu VuiLU+g+M7kz8bbEiHBugtG17xAzRQtaDFHvMfaUh9kImZtumuVHXlSoPcngQGtuSG+UxM/O8b30 RvCyxkTw6ONpAZG7Gz9kn3/22WdZjw9uUYJ33ah1xN4M9WIP3K4qK99TfKURfQXE76XQnX8Tts7c u8ufykVORmObH+S4CnyGUd13QeK1zt+7Ixc2PlSy+TuiT1m1nItfionKUczf/evf/Kf4x//+4/99 +I/v/w4cB6duEjsFKxXf/sM3P/ys9arx2B1vLEmW+bRvfvjDH7//rw9/JX7C6cPi/M+zIR+2IO8i /brWi1X4SRbFdiqqv5XDHehfrreonXIv0QkmUWjpXKdoyIGXhT9DUzJpI8KET7kz3OB3CPeWC4yR uJbJVYzmzk1qDDQWU3j08+6iXon8aigPZBNpUbsBHA2/PAHn+ApHVFvTNQTOMOpbfilTzS+tOqHC rm9nqJK+muePdasJoxV80ALnbQE0vy10QQAyEkndNEeOLjq3qRuOMM3MXDTSnyLKEUWmpcfWVyD8 JDhvJJAWEteaiQnyFM5Sy1JfdSyJa552b4gpVz/KnawAYZaQjTNcNBTbA8byw6pdCJNrEW+nw7FH xELB3u7XG+9Wa1l6NUEl+YV5FZVGdFeRYyL1MVVaQ9AD6/mWZUZ0sTmp0IqWwWInY2t5Q/pnVOAA sUJF9JEOzSzzp3eJRw7/hHUpVhmqvcrCTFCygVOFN2SzjcfDwWPFv8MXEucnJWS4J+WWl5xomo4T 81DpzFJNOVVlKwvCHIIgyG3rxZZskktHPl0OoouGrcjk7YQaNXRlgez7RTm97QqFJxU5ZS2sYZgG i+EJiJyY7IYYco2coZM/1qErZCW3oZIna7lRj12bWm4hS/AMrfx4EV5pq/AEUte+pZYmed39ePLa TIIQSL2Fll+2k2+h7EiS9cZaYBqlviWYyX5FaohrVhMMmSLvqCkSru/WF5X6N/RoDa1krRdXdsEg MjqxjFIygy1mmimttzBTAkSKI6Esq0zrXY0KnVJWfiP7YqPGDM58o70Bznz12oy894llj1zNkD3Q hXpp1NUYJkCGPr6kPygUguuL7c5nwEG71I1tt9VvcNl+g+wlf+L9Bm1r+JOWvPqIZKjLQ6CMZJZW FwWrN7iLp5PM0k6mMgUi49wTKvysH04s2cwzDGuW+bMcbWXaxvX8fhibO5jLNl31FuHElsHSa2XD k0dWR2+d82A5R4t0/O5NP457CntPJO7RlKSJrg9FbNjinJMOOyyT9ZG/NN2bB2fNdgfToXOqKM6N 1CodZ3dZTigHWXtzcmKISDWm8kb0o3hyZ0ng4wrtDfQAnK/cj7MZ4lUaUmcHExYVg+DOezvtBerF ZXH0vtovjFm41gEnfrXURvcmTBKHkz2VpGpVqVRjYicademg1LgADYhv4qF9KE/1U72utX4aDjtM f+Rr3337t+p8ajEkM2OKPoVYY2OzG3iP8gjnwuNekDmnHtdyqhE9iYd8XerMthj74A+GQGx47AKB nDca+5PQ1HgCQr5UWVTEMw756gmlcBoYzwLn0OMNyEc7f8eK0TnpuFGKcQ3FWKli5lZ7lpDFLoYb bDlR9Fhw//rR7Aat00Z9svWJxpKzTLbe6K+BnzoHH+/kQJGDrkBn/eWcdwxGtIYXeKAb17wAnTsg 7hyCt49JEM61mlCihH7/4bt/+f7D7//NKDXUtRoasKuPmRoWRvuOB4gp4HTUmTgnG+9VTgEDiCzt F9MxJkoa+77fZHN02vMNRS6VjOvKE3//pw+/+/133/zwp39WYrdhNxilZp29K3EWgFppM75fxpQf 5P3ab8zLmNZvLPgBrm2YPXCFNW8Ju9K/jIedMDCf8r5e35eFfBt1bIQ/6rVovutjiJ/G91kbpn4U mFMQfFI+K/VsDvkW2qixURLhB5M4GVriX9DmZa/z8y88f52/t5bZj2b+naX9sv6TuEr1tn5XtjHn LYytEfVMkafGj+J0YIm+blC6121eWFkH2DHdC6YngpFTcY3i0UvjVHCsgpPKuY53ik48CIaW5b/q U/Kc5hsCJ6lzYEKnZuM0lG+bo8G11Tih8ectfEb3jKissQUTlNUYSp+jGABs4QhPHKcRI/mowZM7 VOsYL6Y5ktPvmQeijUJwTQ/X7N9e8RAVG9JGC29w3DqlMcohMBtZEui52cLSuJgtzOHAjE+zwSBA +RzMjEONvjiJDuXpGWS7MTVu0Ra5PCky3hPHQZTJlliL3nTijyyZ7+3J0PEPL24WZYVJga5v1mNP w+x1dLGh0ovTs8gn3xCR06EuEYxJDVkaH2yILm+Wch5dtynXppZTBNNJPLbUPdg39aZA0M5MFeFj OQeWtSPcusSgN9OslXNBo618xIktQWjpO5KS5WPFnFRSH3ZsuBNT+QrGNPuT1HJ5Wf4me0qk/sHI jNBSeBBq8twea8FtpJ48y2pbmd5FMYijXmp5PPLnfHQFXGY5Y9xL67S26LBnKbyqC3+1jQdxGkSW tA/qHbkRdlapZhJnCFYZdt4a+MWBbqsr6b74I8vLQ5NBsH11rb1L3H6aWFYeZl9hOSxKOVWCLWRu BnESpcnuYsvRT7jznvLctVdL/HNkifpbej+0+vsVjlkwkyfNRAqFN5FfjX8xEFTc+KPEt7Rdrljv 5UrWZCjA4ATD3zHTkhZL/uCFZwuMw9ATLVH66EY6pJNnaPuJOXv+Gj1Acs4ed+GVqlgSY/bA/+VS kwcwGhbfmvOSYc5LJue8ZM6cFzGKO3HPMvdRDVa/va5rWh8lNj8J5wZ7S9ra0HgdMnQqXUXcDWhd mBhxPC/yqn/cbFEBXeVkb514RjyeYpC1vvB4s9/qrmin4FhgBkJmA8OYgtAegpAv7ouFVVPAR5bf 26kJPsYTtkHnr0Bv6YrXWqtOgjgZW4KPX9FIx313cSW7Jaz/JZsNDc1X7YbM/Dz1i0bGHLDWl/Sy KWqbydK5Pm2noyPihHFfiMg5ZOXOHQcqkmDsO0HcpCArhAawmeXCsprb+AgfK/rWuMuXuDBrdN23 4+QzF/7MRAiYC6t2Q6eOXySk6Uw3Gc6NY14J/Uy6ZrevCm+BKrXNvsHEILnGk9QPHb8i2ZEjiC1O u8JNG4nkDjX4hrfoLk5P93VqehswzAQDijV9lD6PjCfhe6JpPTrJrA1j4ZottIhkg5xWbfGws2Vh n6CaeEtbN8vC8FOlu/2tUbcIGDiOCEcXJvUW9kbT5XPPd/wQ/Moz06Qy2zrBByQSHf/DphG5UBMr BRVZ9eZEcwB7/6bH7McTQRgbrp5EJ+hljp9CWxDvDc9SL65uPB05nsq83le7hcl1C5wcMHb8atu1 K3Bi7V3WmaiXCm71v2/UJ8O8Oz7JgzbvGZP7kpwbPSxMDML+wPFKlsSrs8KZdUOGcRg4DskSBdN8 jn22NI08gg8t+9yQExxaxndFnlim45CJ64asMOusUsGvpuUDRTEC24adrBDGf5RNaFsnPGk6ugR7 phgM6X3/799++4e/Nto4tWM1hVBTe7dqaOIWlYe66lKgr9o0cgmBAzGrbIE9KYF01ZXVTuxsGwaC 9e/tkYpf2ieUDIIz07+Fo8RQ8P9og9DJjD9QX4G8pXOsoqxGVqOwK3xmOrTIITz3OCpEFvLVGFm4 coHp1WJXjsyk8kG2T0fvK2nFf7khKPaQxw//87v/VUVOP2t5UxaFaep4his5iGFTFvMCxQo1/XK9 Kgvl4qhyKOMblg2K2hEUi3Dyalk5QQ0/ii5i1ztE1iCu0P3EtTrId0YOeuh/6fqJ5GmS8qwWx26T H0g/K+XhD4OJc2KePo42G5ecEsiG88iM6yLv2XeyQD65YdWu+LNc/uv59/e5Bo5Cp7bIxyjnM9k/ 7XHldK+oTOilE/ioJbfJrpyuRZZa75sHugXTxNfIoB84/mBRiD4mNZIu1CHxTjRF7a++HD7c4l2x elfsyI++vz9mt2RntSvSoQ2YWX+wQxswwxCZLfYSzjZGwmS/3eoF3JmEvb71DGWbW8YzK3ayzY1c 6R23q6BFDTER1RSnRxR0z4LEcRm7ZwjnRpj+U3jBmuMn2YpciTfjfLXWN6jrR+G1dSSdEwo4YMkN KjiSgD+QjyXQcpNxYF1KM/19S8wLjiz5GTGRueH/03atzU1cSfu7q/wfztZbZYcK4wIBxv44ksfW 2JLGkWR7HYqaGlsDaJElr2TFMR/8XyCESkYhgeVOcDBvuAUTsyEkASpLltsmQDYsTm0Cb6Dq7eec mTMX2SYfyGarsGa6z8ycS5/uPt1PS7wnl6GziQGK1ZhVsmasEGFXMyHtUMY22lMD21NCzalx34xM WDVrrERaJALrqlNF2yShvr1Yli+dpx7a6H/slEgdKteUCRFrZO6gTx2rkk7iDmMiqb8x5BuUtNX9 tV5EDJ2ixuPu1EkYNCV9izLB0cXdlFZl2Bq3/Pgyl7RrOVI3FVzAq/h1EWhZJHXfiOyxyigDb0q4 NmzDI3a+Is/VUNA0YFS6R/GmCyIj37pHy1E/S0HeYyOcxSpUFM1C2SSXSKcX9i1IHMqW7RGLlnHb No61gcRC+NRg/Qr0jZpatXu9WFyXvyvKPw0PEUxInogKyYLMdtI9AyEYwgXSGXKBwPjebk9xWFlX t6SRtrFSXaahTCJwJCTA2hRAs4ncTkGlpfJGxjc4NRhTQnZYNB4lj2hYz/l2plZ6q1hDjcGSPSOS EZCL0CuAX/WyLx1dvq7l+PhHxO1EtR5+ijQ2Q9RIVCJz1qhmfGeylulJab7VGSw0o/QULS5WarW2 0FGny8m9KNIEXdmLQkI7kfBtTo1Gm1bhBKzfUik+Ezy8xxxK+FalRnMIxbpLM55HQOlH1gy+u0L2 5tqBGYTepIvQsrzXInWuz7cxERi2vcpxiazqWBVpilW7SHpvIUQeayLP1YlI5Or4lKO+tckjznhC KweNhJOFbAMxNWaQ/xDi6gxyibBSnRnTInjefZVe2jU13/bEVKD3YCn4CWlpV2dwVsu10l4DaLfS 6oSNj/MJqzCjBJB73VazRtr0jU83xKLghlgowfgLwYDDrLhvh7qQBQLlmVfBVoxdu2ZMozZGMs7t 9L6s2jPkW6N9tPDrXExN+WDJPKzYt0PlCSH3cdFMUCIngYIryXP31wV8XgK/kceEKhE0dcmSDZii npusxFwcUNQ2rKDaWRrAw/xsky5J8yap4RRCmqmAmOyvF9BT1pQUZEluTq4LuMJg9zAUvaeZyiz4 3ipwh9P6Z/kZ2blJBBD45qrIqZzxQP0r3irW4cDyrVWdwYPFcIbr6VmuS4/UFRfL2GVsD+CfCK8a sJLz3N8uCsfwujEedVoPGK5IFHAVM4murPAdjbkZtB7bsBYwZPV2IgBeClNFnVHESwPp1IZwZXHU /WY5261v5DZhDCkByxY/uT+c9LSspDETasBk5SlbPD7Aw/YBUKpCeqgp9FCPayRoxr7MWaibiF6K +b5C7ruCpHFljCQzAmarLs61cbpF62IaT5iAx3esEnoJ+XkgIVG6A/lJwkZDVnFoRhGLHjBgiYXm xLIksRCJhy7pvdDyy0jvVeK0/nqkkzMoeOABDdi4L/WA6mm1L2Do6hMW6US20JZTdrksH5oxewL2 rl423VPrAGaNS5nlB2fyy8j6t6GqofTMhOuO0fMk83yjV6cubz7oVVxsHtFsv6EGz+P6K1Y5btm7 kJk2zXdZaH/SqdpvaImAIUyrMVEZp7nb1k/fVNxmV0nRoOVqDk3yUPwRO26XZLJYvzGqBAzk/sqM wnWo+ExAlUK0VOD0HNFS3o1cPmAF88AueIWwnrC7IIiaywjmywiXpzMYXAWAd9jX3rErZiXSx6Ft ky6ylg8RrZ4Cx8V1V4w4lZdK1QAOKmkdBgFrFFkYrBbkkcrUgHuSb9E+XSm5K990pbPLkSHDwDeo B9CjCgDZpmUI0oAB/BmpRg1QU200Qn0izJuMPQ+hL6WacYl2wmiHNONQ+mGImliENY+sZ1QinICM dkaahIDH4NHPZNqZ8Xp1u2wVHSpVJx4lPe5FSQMZ06sKCHjU9VJlAiaRjqDr8GJFTJuENXFj2kiV QkRbWwq5djrquE/4x6FGfSrv53Ok9GFdopuAPYJlkXexLBQBdiGWSCrT42OdEFO5UCkzDiXKy85P FHjRVK+2odojkU0QlWYVUHCIG2YoGa24e6pAd5JM+CipLZGYxxMEUi0q9AgkCEALRxL8hJOpKxQD x71MHFnaTEmoMZSjk3gmzC9Ih7K3OJVS1KQqi3plJKwJjkB4bgVHuKd/VdrjtzOUuUPp50pANqf1 nowENcERiKgib46RzqRoLMWMEF1sWTpRKtOcqkNAeHUOEn5tB6KvjNsFi3pc0ZB06J6bpA24E6Wi BHsW1cXKjPsFFO3tKfi43QZHzRGJaUK0M27AtlXeiTRfa8oD0iDCPolkwgkR8qQEctIlXVpimXC6 CVmlYgI4qEUej8R3kTg/nUbQn0xWyeipnMQ4wZFPqYb54Z4NBdDp80mJcMJLTIdgQtzgWg8YzkUn UvpI10XgXMGmB9ZCLXWFWwKOcjDaTwlFBdoSa5+XY/CPmkKBNEow/NBFTk+apkRDYczYsTaEpda8 ZxFDQqKigAGpLST8MvQFZo7G3gtXIVXRlDgoRFgqcPE6glqrKolmk76GWqUemqxW/kJakpgqpCma Eh4FhbcBNMxrjpZFBnKxPL6jvsNqU8fcgAsjkxqVECngIJ0SHeSllHuQ4VlV4qMwCdGrDO6o2GPY dafsWhCOXOpGMG3U8k4aQuC2RsHZpW4kybj5KNHCkxIFBSdgVcRciB2b3m68WACkP9xDlbYmp9ug rvqQKMRMzVYYhiS6IwJZV6KhMI6ty22FCV57oFDlkJSDHMSIg6tjQqQl4P0bQ1pOwqMwAILWXDwH q7wNyOT0b7lmigpZcWlAZmGgxKTylCUDBTgJ3gRDeT3uK3sta41VKhNrPLjIvqSET0E0LI0oz+aj LZ8HwHoNMH+GZvVhTYKpgOcteLFovY5ZYzMlJGLT/Kc1G8BsjEmVKgT8aHrAkTiACABHAnHHLwqV UzFvpcKVozU2btGmHXTo5NRMr8RcAU2ZSfA1hSOzMQ+ZzYNuA2iHVLICCIMMCINKrq1PTP+cppoS bQUHihY+lZ9t8GgvZbAi8d2S+qAEWiHSHcXJmhBgLCTAODRXTGpZPhiYcHsqWomNkxgm+23Sqlnu awiezpV4gh+wDRCJQa6ulbiA61FD6DeO/2ouEFiA0w9aDgOWEWucFFzvKQawRfx4ZeQRmDXbnuCi UQRTmJhEMLPJYC4o3DPFAUG8xFrajmJS48pNwigQFso0UHCm3aoHtZq3xnJ5LEapevETPwCS8RIT 1NsKR8hgLkJGiKcryGPGEVePmnemxsuCeKRDaYnVAlIXQYaMB8VDmqk2Q814uDSAkNnsx29zabnD DVNJlIokD9xl5cHRaH6NC2LgYI/UwYE6ZO3If0eGBYlGqxSIlUPotwR2CYZ+K6qZtCQwxqDEcuHn t4ynn6DCEfewieSUHj9fOKn1SjAXwcCjB4WfSeeWf4F5m1iqWLMYKo6USvYy8C7iwFiEf3MEvYKt DJAeaJGcqGzbtgzKi+CorhChHoJ6EaQ1q8AnF+8qJW2X4O+kq9t2WsuAvAgenKBPI4QUNs2yPrkQ 2Itg4h41k4cfLDOOeV3zq2AQQ9FWRcBGtjg2VilnsdKoFdp5DWtnvmrbryEssNdDdUGmqFGFkVRZ E4DkiEldToJykICbZsniBPNOullAZc8bqBAjdTu36veIV/VbSdVT9QD8RqzbD/XHkkEhFqZIlw1f UFGsUoGrsc4/xeeqAE2McQ9xl00IyC94oWjrD4j98s61HK3XFHC9XoN5VWLC8LAAq2Ta4yWSoLZ3 fM9lruvLMgO+LB6uu0Hqg3lSkNywCoXX+/XgOIYyiaSEh+FZ4TusYpmXVS0h7JJvfnalXpOgQR5f ryEBYsAXqLmliGpc3Ix1s5D1TELiwjA2TNqRXebFmmgHKslzwREs2w3r/eSI5RNc6f8Bi29Ea89K JBik+wLBlif4IviOumYXNrLtXsWzES2VkCgwIC8BARATIj3D+GkTiilOWWzArlaZi9jjJaYCTn+9 nxyB3FARLqlw9ZJM7UIhSCvVvRERbcxL3EGjTtk8xUzmFOukTG+Qal+gbrSS5Lq+q8+71DD0NkjV TyTNbKsjm1Ron/Dim4mSNSldTKPphBpwbuCnl6+ZSklwF2Rr8lCqXH1sAjgCEbN5lB86SmVPnP4p cGmIv+DZmPGOBJVQTk+ogVioAdCGH2MMJST6C88hwVllielTYq0OoK/p5dhAtS5R0oipXSLBcKYw krHUnFzCrhChCTg+s8TTU5X+HlordR8MSXBsXBfmqHGgXDegXuGIsZaZn5ZHWi5XLMBFJlUfSom6 2PWKgPXJW6Qg+o8yJfALZ+IYBjVoDFZ9qkijrJBOTUtrpx1mCXy4KazG+iQ/eIArp8fGkTUv3+Sf txGT1wkFft42DR0Fe+kOSwI34MBhdoPU9NzwFMXPuvFc5yMgi8nomWlWWL7Cht6eHiVK7wuL7SQT QSEVBe6N2LCpMxDyovyFlCJWCngvyVSn5SV1OH6iu73MkP/lUQyRwN8gdbWJeq04rvRmzYL1VlFi UvekjWHdy6ah/XKi8lbR361pYUjtiwfeklI7UfH95EODeZKBUt2q03KbLm+X6HLDeg8OwbtkrkLB ruxEimQBUwtFCmpTlicAjCz1n1StprnDoTfLOJ5rcJylAoW1BlVtAnYqkEoTlcpkYE6kiXajT8uL pYn4KSaRUzxnBpK2ckamzyevMt/UeHVRLfjvf17yPzZ/5eTHjOdRrEr36gN7aH/vRlzPK43jSQ9l keIpkYkm6qQfZ6yJos22tJOSsb5rfTftEq8BQmQNPTre/qbZ3i3xiVi8fZcgxB+8lgSADxRGipJV q1dtn6X7ZSyDJcmSUHO64cMVIZaiSLPHYlt6OcQHkfSlVJ7w45H0lawZNLuZrGhaJNNsljdLyjLu zHIOXolgk89B+o1gQbWCGoMzwa4RZapdzSZm18uPpN/V8Vm7PJso2iXx7tw96ZN2r0jayYAHvBVF Rmdj/IMSSZ3vdNUO5kUrgnAjU6cqE8Vx2XRuUNNQGlJCLSGiVzw9TSpBecoflbwSN1JkM3qk9LtC Shvb4v7BSXJvDJE94ZPkgHdIHYC6QHwT0zlALP1Z3UkM9y7/9Jj0TIkXgN9Le768TW9AKrkuTvrA 5jScB84V57hz2/nB2Sdeiq1fs/VVz/9+miNdr3oBpNU/B0ERyAp9G97bnK4GLxZrRau1xeijxZL2 J7KxHYslbe0swkmV0ROBGTtol4vj3FHCEajybwaay00Wp3bRiGR7Q4+m33TRpJFUM/5FcwwDCGoO YyUfnicdiqT0VGWy1tryZ6VfHQxwub9bW95Usz3BZ+D3HzEum1+5YEoYwfdWxysIIhxQR1Qpe9Ti TmvaImFVtmo2AgGpg3Q5OnzTwYF3AgZDDdFTajYwqIA5shAUNKzm/Ks9xbcsok3qZGXpPu5aESuT Lo/mAD/hvYCbJjXOo+9wrJU1sv5bDxSrlWoFJ0ODQ3n/wSlrsj5liSOeuJbt8y4XywWytrbzQww9 lwxMyHKxtqO15cG1qy8Cyxc/H7/TuNpoNB61tpzeffxWYK3i59Ffjtw/e2hujsVebeSnN+Kdr3rE eZZXzt2KBKaUKHIC+cm2eNI8emcrwmQ4mNVmWiwIkhFAVmS6bTE6ch35rW4cTcqdGiL2RkS2MV44 TMhUgC/w8A64bsv86GMrDkp7Rtu8dd1fL8ywNnhVi+BBGXFeCBzThtrBdjCUUXPerpSqly34HoV0 T3PzdCsv9pzPevsQBK4o9gyqbuaV7GB91QpZVFtFiYNRb9IFKiiIzSVwYatY7qYnJN6EB5hvb/yv OOmnhdlcvdzGUzFmJbnYlST5Rmbs8PL2fZoNIRra1CoFVOmrsUDRvj9E4m961fPsk68PX0mvhMyI m4xrlQeeHthz8M6R04f58jrxjwPXjn94+n9bW07cOPrr/IW5cwcWWlvOHj//Cfv4+7P/Pvpza8sh 58i7c5+evQnyuZNnGxc+PbZ46JvWloPfsEN/m7/J6N/T78/fnL9AHGf2EtU8O+TQr9Pvz507fO2P 6LqNr7rr6BP/88n51paj/z1+tLXl2In5y5/8NHfyddElBxbmPmttOTd3Zu/Zm4f2t7bMnTt16uAd tn3y7Y+/n7984pfzv544e+yj18Odc/rpsc8OPD3zNfVl4/SPJ4/PX2Ynn5y4R+3cO3fv2OLrcyfP HT/3/rHdF86c//CP6CIBCIo5Pv/8wE/s1C/HrnR0dLzKJ7FBNa2l1CQ9bN36DpYyjAGdLJleI4sM Hdr0h/JJN10kQBnrYKjFoOebb23oEFkn+SS103x7YwfLjxjM6BUZnzmXgmuIpCGItyBl7UfnU+e0 s/fek2YCerjz2PnAuUX/LTz9u7P/2UPnPSK+5DxoJqbX+Xnhi9vOEWfp9innY+eec4wI9zYT0oul 1ayueneG4pr3NvP0LueffUJvdTfI61LgdfY4J52DznnnMKmaP7PXblz64j3qAzISMmsi1PQ+OMrk hd+vfO1cpGYXf/y3sxQho7f5+xekrz507kCXJZseHBGiTTQKQ+m0lhUpyJG7nR3s+Tu/vfDS99VM T877oDv0QRcX9jsfPb3h7KcOuR3qPUlKX3Z73+fvPHngLN45w19mPxjZa08efPfOzeO/HaLNhhOv iXLSV/7zqbOI3vr8F2fx2cfOhSgJfeG9J87S/VvOIzR9ZY9zjrpwibT1x86csy9KTt/6+ZFrp5zr zmJezfZp+SgBfS5CkPRMO+tXEwMsboxGSTZ3cNQmpiJ1SKNBWIamq4ONGFkiSmT1tMZm1bgxBA4O W4CqHmwkaRB5jq7lRnREGGdno410d7Ab79Ko3nGO0Rh/sPgVTefzzp0I2fp1HSyOYomMtlw+xi4B 14oxVGoHgwNJiY9qLD0q3lrPaLlclDDOO/PKvVv3bjuLNF4XIgQxlY/6vl8/pIXgT2F5m/idQ87P dGuB2jkWeFmPZAO18I+vbn39427ncxJB0bvUwO2LS2echfuPaC1ecj5yzkdINlID976gjqDH33/P WaKpt7eZiNrpgbaUNYZyDCcCfcl8hGYTNYQqC6NMzaZXJKKGnl0VfZHIjkbuduJjjtJ0o3dp6qvN dBOjRreae2oztXvre5IIBy8fd87Swol+QVfcnWSQoP6S9W53023SiS81Hjb2hG+tX6d2iPV1fVH0 UvQ+sT7/9rfvnQVvKowKGRqhw2TwJ7Z3lc8Ad4hpff3dWVj4llbeorMQIcRAkzy7RCJh6dJjknnn qSNON70NRhzHhIwWSd7guEUhKeTRYUQRnDlKM/lPkXsYpLymZdQ+bVleDFPjSOMH6i6y4Eke3qEv WHxxnb/7LedEhBxjc+PzS+chzv5z0bkSud1Frd194SwtXG2eeOu76SZPouCCOadpLPqyGLkrL0i+ X7575tI/l1tlsXVi5ix8+4R32UfUidjEHkSXS2ydWK9Ld2+v1L8xrP1n+5wPfv3GeXjzN5qqjy4d da5Hiaidh/POXpK1S3f20cKLfFYMo/79kYfz0cvEpwv8JpbS8jQ0EQJMApplcTVO48ZF1O79zmX6 oju0CXzw4ACJCFrhu/dH2eIdYq/Sc9RmJiLPYhABd7+kNi7QRG+a4LGNcdYxrGfyNB0id7DkH+6+ sddZbDxSGj82Pm1cfP4dxFSUDmLo8FWaJJefOAtf/cC7/zv0bnSaxzC37v6L2tjb+KyxZ/baFWr7 auNW43HjYYRysyuFSTAFF9XarDa8VojyNvbm6Gifu7l+/oJGlOsYN76U2/qKDLTFPnjkLDzajR0i QLwFQBqkQmA6bnVbpgVwwjnw/D6+5qvF1cmp3caVxt7GVaXx6Nf9zoe3vqG3WpWDtuzApdUoN4q9 5NpB52/UtQ/FxzqPv7vs7P3vz/C2rca86aXSpYmFdvYv3vvqXWfh/07R+t+3Gint8Hp7GttDZDtt ouz6HeKwianble1x2oY1TPOXPgd7/LWb9IQHYuMNyYwtfHNnTbu7N+Av3ftXbSC2ik6wKiPNhH9d wCJ6cP3hvt/LRJPCSP6J9NE+UpEgN34vI02I+89JIjRNg9WYaEro+XboYOGdbgtyV2hL8npwVYUj REy9RTpuw/ngSyjH551HKxFu8PekZXWdEPFGPtsXbx64fY7k0JK3s4fHIshAvfHbaS4df3D2OQsP PqP1BfG1uBJD5+oKU4h286paXogUanByNLAlpjR1mG/2aios2ENs3WLOXX+2ah9iUWDbIg15MWOQ Up3qk3ZXEy2NYs6gLyOVP6llg1RGUsyMYTnc/pVV6Gik88YgQzFULb8KHQ30ivpYlNYVibcPO8cw 4BfxR1hLjnJsWknwR+g6+ZgtUq/+f23X+tTEsu2/U8X/0H64daHqQjmZ8Po4wACzk8xw89gcPOeW /8n+XyLIxWlUvLo3oCJwfICiAXy/TnTz2AIBUfG41aNV97d6EjIJ05NJ5FRttsms9Vsz3b1Wr7W6 13QW3/xmn/til6QSXgiaA5GpGNEoAq+YHuv07TUMtNEjRrjXQCrJEjEj6td7GOFHmfuXkNNd83sK GuL8PL+IqGm73LiTFrwphQniXDTKYLXBwijCCw8z/gh+fp/fDgQKHUTsM+X+R4pRD8WW8uhSLiWc D3h+gcrv2JfR2Md25tvH9Yf4DNW5m3dwvwQS1iJsWfytfX+6gabQWJ8PhIWe4BG2A/G2SQJhOQJa 8vDeHw8D8XZQpELJbxBu0hMvWiCsImabMXTyaLl9SjFQlULm5rgcpLMunAj6OqO6SaFfImUiVEtg Vj2YYSThfWARuP3mRwxrjqKlwChVkpH6o8KyYfZFtQSJO3wltFbIz/3RbUFcpq+Edpkj8EVJJzY/ FKlvhTjbF674ZZ3+0FCl6MYXrR4OBZpY3u26hbgXjQo24L0MdJg1JF1zOsyr+q4fHeYnh3vfXqBs lOIlX96Wg8zGl621ubCqQudpGZgzymLLQwhS1WHMJbxkreGvRQMv9Ji3yZfx0Zq6riUs04enZCJg DZ1NZavMXphwJXMs43dlaCIUnbUv2Ld9+Fsla2nlfOgtOttJN2m9qFTLyjhhwGQPtOyAiKQB/0LT /JrYQSEPUutkeepaykfWujO0s0I2XuAqJu7UsYWVDTQ+i5TNpbXFfF3Yy6/C4gpr51k7Wzje9uj3 gJyf4riYmzx34/mVNzf47F32b9sMMq24EbFYQotoBm79fnnv7otPu2fx8WUawzuCdp9jDa+ufT1L w9HrnBadPK6wHnS+RlUpDQjc0gjcZvgkH+KnGgHtMWg9XYt2pmJVA/5GI7PyLzvDLyJRv+MEksCc 4jm+zF+z+jq+nD4D6Bu+33iw21TdHWitZI+PIezMMj5BQSffhczXNYqjqdXevm4P81lI2eb7NcqB 3fInwN/iQ4yv8C2egZ85VaOwFhFW7/NVPsUg6jo/y4eK01u10lpdsXNG7NhsHyycVCsL08Lbv2N8 C1wTfKhGSZg2tm/CF85jAM/y68dqFIPJZOPSm1GexeidtxdXl0SUd6E2aSJAyPJxvsjn+AYk3mb8 Pt/FSNaoFiLofYt55yzG8g5/DZG5GiXR9t7CvSv2HaH088i3thhEDvOF2gQW+JpjaqqADrHelGZ2 anH98BVh2074k6CMvFc3I4b71m5WMtIx3HuZb4nw4Lo9Z6+VDbKbH1b459LmZ+G9looNlLHD2D5O Zm/amcy0jAUmpLTxB+jwBRkL7KLwBW6LOoXFjL80ytih+i/szPD3s2Lt+ZBSuFmh253o92H+pCTg OcTXQcsKT4fspa1lx5NJGEkvaU2hMKXK2Cgdf4UmL6XPSFgKH9yjrorQG5FU0ojpCejNFn+MCXub iSa85pcbg3MKLXG6nWH0d8iG3I8SRAIpzwIIw0zr1QwzPXKsWgm0WjACpd+nKeGPz66Nv8AioGL9 Vj+6fJhWse3NavEtnvFTYDh0cz/3bsLO/DGf5V+vsqbVM5ufW9bufnn+7F5TtcKguWIuwFxRdVdC leG+z5Nf448ZaVapQQWRATWnvXg6GR1x38/VdgZpv2I/p8DBzmipXoipVgKUUtlYheFO0XIVz7Gm /iiid93ZCRWraOjV+rqqpDoMbksKMzpJkVGhARDgT58pKOLtxkBMwn6+jOBJT+H7LP5KNLcCNpRf 34rSL5vFqwCKTQQEB5Qt8SpwYSccoLWs73tV4GAd+Q2o8vXGIGjKYb4+X0QnjUEp5kvn4QrYNifN pb05O/Nm7U41T90uAilMKhQdYIC2q8DCBuCtCbdVGgL440j3xWY769Ki0SpwSt5FjsGt7Ngz8Kbw V/xlqWPwl0E0Irk1vIVS025di4MflpQeQvdTcFGJLvQ6qUf1/j4t2VcSycohoeKqNH9BMT4ig+v8 fDAw+YDzCMjJ4qeYd0whR0OxE5gUzC5dlIa41qYqAKHZ9IPcMc2IBgNAmTVa/Hfl+RUQUGHl+PH/ IN+wsxIM0u7YN9o/wR8Gg3QIyALCjgzC4Q0xH00FgopKqahhRoJxK2KUt6GpC/aI42AOx21SeGyQ rrpVtFWc7K2zXiMeBfcLZItwfEDQZJFrDMj2N6e+sli3g1Bg096lMI01iAIDUx9IMFrRoTPkzJKw saLskKgrmuG0h7m18x1yR6rCU9Y6jVmM26vHaFVrWHyqSgQlrGVXq8LTwtMrsSZJty8ttgwmAZq/ dX/vCWV/pZpVEXlgAVs5e2xx2q7uyWkan8W1deRkmOjSz/IzX8NPKQx2eQpQUVyHswRONSwv35d7 skposhU6+yEpjmSvCgn9/Dr18im6fd++Zb8QCYQo7ahGiqC6rafNeZz/NFmnQUEEQFPkEoRZnub7 gD7gM+kzjVUDnNRggq/xPbo3zef24t7Fb6fdz1uFtBC1374iQvQ5e9neX87Yw6/HapQGixLTS9ky SxUSwmKPOLMy+uG0PVejDBhVYStF7HtdsGdqlEQ70VP2JfydKzWPKmTAzELH31Iwuiy2d2fKc94q ZLWL/flXdubd7tvhGmV0iDZdtCderq6M1iZDrPAM84925tF4jRKUfLnwU4zPTfs84rkp8EyAs8a+ EXxuG2xH+NBrIOBjMUsU2LEuK9avmYPC+U3SW1pA0+Q1I1ZTN/CNIzpa4Ysuw/wxKcJabRs++Vx9 3bfT0AHPCOpHbwIj/sdm5rKdqa9bWhbvftI+1yIMeu8ob0P+kmN+nKiv45f4gv0Bs+Vmqc/90VuE KW/L/gmR9XVHJpQWggW1vs6hH+UTtxZ2FevrsrP2vL26kROFQK9ENRO37xzlzTCX7N6iEqL6OlFv cMdVvXckN2gXbpjb+/V19rOjFEyzzjpE36uvO33hCAUXi27wxItOsiaKI3Jrc0d5G0VkJOmzCU2c Q0q1FYkjlJ8Hu+evDkiMxaxkn5AgtjEa/WhirhHbCg/5Lcjexwy5y58gbWsoboN4bxx5i6OisZSe oKKSpFG6Su0NoGTxAeXH/4UkXfxDtJeVgWExSU6KEGTd3qcalgEt2UVvU7Hkz5XxhQrC2dIVRm/m VqGJv4pIj4oATomS3uHKQBjf57mV0WPO/yvzt1NR0MaovUqZH/p9CkP+Arl0WfLtDYa9rG3Dui/a 1z5csHNORmf/gWcerQgmm6BjDCsy5i+5tE45XlgsGHt6BaNxi27pR3M8nKgZFDOSOHjAdWMJKER5 8c4KLs9BYbkIjGZLllUkQJUqBross5v1xLWSWF8CCIuX2Si3eoP5+HF6pDKEynOdkoxh5IcLGIOF yqDW4pLYl2v22KNMScAoAbUdrM1knPqGg016HxD06uAlilyJxksAHWIxdPHTkKium7G3KkJcpYyu y6wh1c8sU7wkGbesHlZWieEjD0oidmeGxUhfrgjQTC3p3lRTFOSqjA6cSbAGfOLTEDNenBGldEc/ z0PwA3TWYvrUQe1bBRgtm93GeN4BjHZ7uVMb4SoMqSBAlPesP7Qz2TcH70RUgEBXc5tU0yTSUe6o REkM5wNuEUtNY7TD9XIUD5xbzd15HQza6rwxg7RiIRgAevvuX7iH6JLn9kY2aAuhu7nzAO7Yt9Ij VObiVCp6KZJcSMdBIZTI2rM3vmxDZOnCiRzu0u3Zki1uP4i46tbHEDMtTKkRnTXQKDfKrgv9+/p1 dxPR8g37/IZ79vZghtYN6N3d5Pg69WiU2Rn29eqLcX8QNI1+KZYZTIuxJlKhs+TR1ubsJXy+IKa/ YbjVJn8x0L4Xp+0Pv5/B1Lfsz0oR9RYywOWS5S4PRmhW9rHYovhg/w4zzOHBfrcXmT8K6kWnbLne pfZkgzIVS3T8WaEy35/Zw+srdubZPV9WUo+9hWff8q/4zPszY3CfkKPYElshi/bSP/fLFfEwKFQw N/EWzjyGrKiP9qLzqiX6yH+4TIu+uVVSpZq3hGkN9ERBSUguC4VUWn4fFRPTU/c9DnHiQf+8uvHI zuxs7ez6cqoHNkX13zP3PvlyQ9NCrWvk+Sf5/0KRJpp82emdb23QMrW45ssHZbv7ZW/aeQebVhd8 uakS4SUcUpY/4lv+D0BrnWdJ4UXxwNZhxTiEgL5t2yujyAenbF4sGvVkJo0z2AC9vNBjRaPWgKjo q4DBIPaAFfOmLxuVfr9DP9+G353y4zRM+pJXp2cPnl38usQOSuP69S5Di0oJpFIOJX8HGVsIbPTi u1N+W4FZbUafryFanuN7TWjA2N6EvQ3zuuIyMBk23MwziLZ30kP2HfwN0xu36TPFlyxluJbmfKBN L49lnFq0ywdVcTJUazNUaIhv8hy/bWe+jFRgb2t2DiPg85DOac2rAqC9WWw7TYmlw5w/82AqVpgU tvf/yH787cmO6yONVOFzXk6RFGpe/7/1988nd1Y2Xh8iqvkRbnq/tbS8kT1EDzevv3/7cu373pND pJZmWo0tvzw4+N/5dPffUUDq/NqmOBdwJn1paTI7e/fqPJt7PDcy/pZdX5mc+23/iOtI/xo73vY/ zDn3KIpY5iQ+oktFqz1pqg8t7ENr8aG1+tDafGjtPrQOOQ0zl5ym+NB8+kXx6RfFp+2KT9sVn7Yr Pm1XfNoe8ml7yKftIZ+2h3zaHjESekRONn1IzkdYRVc8pUeZuJCgLC5hJILAemhDTxx5QJlfzLLM Bi2RimiNNYJjRkJLWoHQJzQzYkVSzNRYUjcTfQaFQUndOKEHQVMMwJ/KOZNNMsXIP/Vg8amb4roh Z47pSUtCHbQiWizlJvZo0S4rdvK44nUx5HVR9boY9rrY4nWx1etim9fFdq+LHR4XS02/cNGrRYpX ixSvFileLVK8WqR4tUjxapHi1SLFq0WlBt2TgrL1GmwwlcL/G8RJhV1JhFvsZ0us8uoxOF49QQXB mpG0hIqSbmoRjX5mvhY5RjyFyM9EGmckaEcZ32uSI16E9WnMgIU7HFwcsOLRblHXDLzZTT++UT22 T+un4zYLGZsXFP3UlTSE+Wtlc0c5Y58WSSGqScVTDIQIvvlyW0mrD43348EIWTR70CmSzjDF8LgN 9HPqjTXgErhf0hcY1XvpLTSrR0wgidQJLWL58ffHrajVm6JTrDotK1IA9lBlZR+9h04HaPVa3Qk/ IXHkhGbS6ArQxQndMDCWsVQc7fFl7Eul4ppxzMHEcZnGhA7MxVf844sVzQ7Oj97VihUcEh4rYsT0 iHAE3Ra8UEI3K4+jJ6ryKA6QNSd1qIHWp53w1cIBwzQL1aJeHPkAvaHQiV2wdNrQhnytK0I2ZIpD NHr1JNMG6G3gWuXQeSt63NcWy4TkZRRFFLTRLUFsUbGIeJWOxbVBKufqYw2deiIpFs2E3jayUq8W FBSqHlTqFD0xFRlOdiY6aWJKpJhOqoG+iBhBUTQzxQ2KbCK03wfFoiCtD3pGehzTgsoxkhRMkRBt sGyq84NFDJglg7cwNdiwFvixo1oT/uscxMdBLaHRBJuiR4dJJPWgQgZTJ1LirtDa3iD39h5TK5FU Ie3am8uT8/fZ1U/s2udLf2dX7898bk7WIC/gYzgXDx4CM26JZjUn/5KsRQpcUK9hwhe7JP2gnBRc CEhdkR+SQ78qALed6jYsfzmWYw2098J6NUaeDzrB4Ij1ZAB1zsMpdtGqsicH2KX3GHGL/dJz4pcg kKSKNJ9cBtwTbIAOh/bUpIaU2R9N9epB5IWo5FhscMX0BivehRQJPRr4cVQ2+W52evwtm/128581 4MNsITt9Iyh3CzPMZNzqTomwCo2ffzp9k129OjE1fTmojNZyGeOfIWP2zKW1oBLayiXMjEOCOIj2 VvDnaGczO3PD7MKTyXPju2zh/eTc7OREpoYu7Ch/HHXyNzzP/KPrVwOKUI4zAZl9Pp6+uU4NSk9m JzK//hoUr3hqYdVNUUJIP2FLJjmZiE6LfE3s4pXZpZk0HVGcu7DaoHXBcyParyiNzKtbBLIws6je E+gRCAQ7QGfqjLxaYNBP9NyWyN57tSTNA51WPJhry0soWmFgCAU2SNcTlkid4B07kUxVga7Sn1k/ a+S6SdeCMkcMsz9YJzjsyAUDP0hM+8kw43okBYce+A5VNTWhGYNVPH2CUjiREaPZVhKhErIm2ttI 6rH+0rUfK05rJSdN66RStiZSQglJKaqUEpZSWqSUVimlTUppl1I6ZBRF2lJF2lJF2lJF2lJF0tJQ 2RJOCUWRUkIyiiXFWHKMKqWEpRRpe6xWKaVNSmmXUiQjp0p1VJXqqCrVUVWqo6pUR1WpjqpSHVWl OqpKdVSVaogq1RBVqiGqVHtVqfaqUu0NS0chLB2FsHQUwtJRCEtHISwdhbB0FMLSUQhLRyEsHYWw 9yhM35yZnbgy9wkhywYm4n88+jZGZcilR6qHCiBgYprX3OsmhGQEVUYIywgtnoSQ7OYh2c1DspuH ZDcP+dy8VUZokxHaZYQOCaF0FN0E75arsi5RZV2iyrpElXWJKusSVdYlqqxLVFmXhGXtCMvaEZa1 IyxrR1jWjrCsHWFZO8I+7cgP7f8DUEsBAhYLFAACAAgA7wCtKoX5jTVzHQAAnUIAAAgAAAAAAAAA AAAgAICBAAAAALDUwNMuVFhUUEsBAhYLFAACAAgANYfQKqIuDdgoBAAAvQcAAAwAAAAAAAAAAAAg AICBmR0AALG4wNS55rn9LlRYVFBLAQIWCxQAAgAIAIByhSl6+Ya5tiYAAGZPAAAMAAAAAAAAAAAA IACAgeshAAC5rsGmx9iw4S50eHRQSwECFgsUAAIACAC1cIUpQtCCi6kAAADFAAAAEgAAAAAAAAAA ACAAgIHLSAAAucLB97rxtfC/wL3DtfAuVFhUUEsBAhYLFAACAAgAaojQKj1EDUw3PgAAZrUAAAwA AAAAAAAAAAAgAICBpEkAALy6wM6/tcitLnR4dFBLAQIWCxQAAgAIADmMqioJUFik4TwAAPnmAAAO AAAAAAAAAAAAIACAgQWIAADAr8a/x6659sGvLnR4dFBLAQIWCxQAAgAIAA93iir5r8MCppwAAH62 AQAMAAAAAAAAAAAAIACAgRLFAABNUDMguPDAvS50eHRQSwUGAAAAAAcABwCaAQAA4mEBAAAA --==SoftForum-WebMail-1.0-32BF5B923B384B50==-- From owner-megaco@fore.com Tue Jun 26 05:52:48 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA25994 for ; Tue, 26 Jun 2001 05:52:47 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id FAA05143; Tue, 26 Jun 2001 05:40:03 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id FAA24180 for megaco-list; Tue, 26 Jun 2001 05:39:16 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id FAA24176 for ; Tue, 26 Jun 2001 05:39:15 -0400 (EDT) Received: from ismailout.icomverse.com ([192.118.48.253]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id FAA05028 for ; Tue, 26 Jun 2001 05:39:10 -0400 (EDT) Received: from ismail-bridge.icomverse.com (ismail-bridge.icomverse.com [190.190.110.12]) by ismailout.icomverse.com (8.11.0.Beta3/8.11.0.Beta3) with ESMTP id f5Q9d5j04206 for ; Tue, 26 Jun 2001 12:39:05 +0300 Received: by ismail-bridge.icomverse.com with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Jun 2001 12:38:19 +0300 Message-ID: From: "Raz, Yotam" To: "'megaco@fore.com'" Date: Tue, 26 Jun 2001 12:37:54 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="windows-1255" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk unsubscribe From owner-megaco@fore.com Tue Jun 26 09:17:06 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA02638 for ; Tue, 26 Jun 2001 09:17:06 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA18528; Tue, 26 Jun 2001 09:03:44 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id IAA21041 for megaco-list; Tue, 26 Jun 2001 08:58:46 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA21031 for ; Tue, 26 Jun 2001 08:58:44 -0400 (EDT) Received: from telesoft.indts.com ([164.164.71.52]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA17915 for ; Tue, 26 Jun 2001 08:58:40 -0400 (EDT) Received: from indts_fs.indts.com (indts_fs [201.64.64.29]) by telesoft.indts.com (8.8.7/8.8.7) with ESMTP id SAA13319 for ; Tue, 26 Jun 2001 18:51:10 +0530 Received: by INDTS_FS with Internet Mail Service (5.5.2650.21) id ; Tue, 26 Jun 2001 18:37:07 +0530 Message-ID: From: Lalit Kumar To: megaco@fore.com Subject: Queries on ALF Date: Tue, 26 Jun 2001 18:36:58 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk hi all, According to my interpretation, the RFC recommends the implementation of UDP/ALF, but does not specify how is that going to be achieved. The implementation of ALF requires that the peer applications share a common view of the ADU in some abstract syntax so that when the sender does the data transformations, the receiver could do the reverse transformations. Also the peers need to have a common understanding on addition information related to ADU so that ADU could be properly interpreted by the receiver. I could not find a standard specification for above in RFC. where can i get that standard from?? thanks, With Regards, lalit From owner-megaco@fore.com Tue Jun 26 10:07:35 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08481 for ; Tue, 26 Jun 2001 10:07:35 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA25558; Tue, 26 Jun 2001 09:51:57 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id JAA05541 for megaco-list; Tue, 26 Jun 2001 09:50:12 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA05531 for ; Tue, 26 Jun 2001 09:50:10 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 26 Jun 2001 09:50:11 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF04465614@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Lalit Kumar'" , megaco@fore.com Subject: RE: Queries on ALF Date: Tue, 26 Jun 2001 09:50:08 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Actually, no. ALF is a set of techniques that don't have to be implemented uniformly to achieve interoperability. They are optimizations, not rules. An oft-cited example is that there are circumstances when outgoing messages are queued at the sender for transmission. An ALF implementation could decide to reorder the messages. This should work - the order of execution of transactions is not guaranteed. Brian > -----Original Message----- > From: Lalit Kumar [mailto:lalit@indts.com] > Sent: Tuesday, June 26, 2001 9:07 AM > To: megaco@fore.com > Subject: Queries on ALF > > > hi all, > According to my interpretation, the RFC recommends the > implementation of > UDP/ALF, but does not specify how is that going to be achieved. > The implementation of ALF requires that the peer > applications share > a common view of the ADU in some abstract syntax so that when > the sender > does the data transformations, the receiver could do the reverse > transformations. Also the peers need to have a common > understanding on > addition information related to ADU so that ADU could be properly > interpreted by the receiver. I could not find a standard > specification > for above in RFC. where can i get that standard from?? > > thanks, > > With Regards, > lalit > From owner-megaco@fore.com Tue Jun 26 23:54:31 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA03541 for ; Tue, 26 Jun 2001 23:54:30 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id XAA02023; Tue, 26 Jun 2001 23:45:24 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id XAA23070 for megaco-list; Tue, 26 Jun 2001 23:42:12 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id XAA23065 for ; Tue, 26 Jun 2001 23:42:10 -0400 (EDT) Received: from hotmail.com (f143.law14.hotmail.com [64.4.21.143]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id XAA01878 for ; Tue, 26 Jun 2001 23:42:07 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 26 Jun 2001 20:42:09 -0700 Received: from 61.132.62.80 by lw14fd.law14.hotmail.msn.com with HTTP; Wed, 27 Jun 2001 03:42:09 GMT X-Originating-IP: [61.132.62.80] From: "mu lj" To: megaco@fore.com Subject: how to identify a conference resource Date: Wed, 27 Jun 2001 11:42:09 +0800 Mime-Version: 1.0 Content-Type: text/plain; charset=gb2312; format=flowed Message-ID: X-OriginalArrivalTime: 27 Jun 2001 03:42:09.0753 (UTC) FILETIME=[24E26490:01C0FEBB] Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk hi all: I have a question about conference resource. Media Server has many conference resource and hasn't trunk terminations or analog line terminations. how to use termination to identify a conference in Media Server? how does MGC distinguish different conferences using megaco protocol in Media Server? _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. From owner-megaco@fore.com Wed Jun 27 07:43:13 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA21903 for ; Wed, 27 Jun 2001 07:43:12 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id HAA22174; Wed, 27 Jun 2001 07:18:05 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id HAA22752 for megaco-list; Wed, 27 Jun 2001 07:14:57 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id HAA22748 for ; Wed, 27 Jun 2001 07:14:55 -0400 (EDT) From: sargupta@hss.hns.com Received: from hindon.hss.co.in ([202.54.26.202]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id HAA21970 for ; Wed, 27 Jun 2001 07:14:48 -0400 (EDT) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id f5RBG1R26361 for ; Wed, 27 Jun 2001 16:46:01 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256A78.003E1771 ; Wed, 27 Jun 2001 16:48:12 +0530 X-Lotus-FromDomain: HSS To: megaco@fore.com Message-ID: <65256A78.003E0E5B.00@sandesh.hss.hns.com> Date: Wed, 27 Jun 2001 15:39:59 +0530 Subject: H248 Annex M Status Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Hi , Can anybody tell what is the status of H248 Annex M draft version. Is it still valid? Are there any chances of it getting approved? Thanks Sarika From owner-megaco@fore.com Wed Jun 27 08:47:28 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA01843 for ; Wed, 27 Jun 2001 08:47:27 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA27287; Wed, 27 Jun 2001 08:33:49 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id IAA04162 for megaco-list; Wed, 27 Jun 2001 08:29:47 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA04156 for ; Wed, 27 Jun 2001 08:29:46 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 27 Jun 2001 08:29:46 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF04465633@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'mu lj'" , megaco@fore.com Subject: RE: how to identify a conference resource Date: Wed, 27 Jun 2001 08:29:46 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="gb2312" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk There are several models people have proposed. One is that each conference is a context, and ephemerals representing the network flows are the "ports". That is the easiest one to implement. You could also have physical ports if your hardware could do that. Another model is that each "port" is represented as a physical terminal, and you have a collection of two termination contexts. In this model, there is a property on the physical ports that has a "conference id". This model has the advantage that the MGC can easily track the resources in the Media Server. I haven't seen a concrete package proposal yet. Either model will work fine. Brian > -----Original Message----- > From: mu lj [mailto:dtxlymlj@hotmail.com] > Sent: Tuesday, June 26, 2001 11:42 PM > To: megaco@fore.com > Subject: how to identify a conference resource > > > hi all: > I have a question about conference resource. Media Server has many > conference resource and hasn't trunk terminations or analog line > terminations. how to use termination to identify a conference > in Media > Server? how does MGC distinguish different conferences using megaco > protocol in Media Server? > ______________________________________________________________ > ___________ > Get Your Private, Free E-mail from MSN Hotmail at > http://www.hotmail.com. > From owner-megaco@fore.com Wed Jun 27 08:48:58 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA02790 for ; Wed, 27 Jun 2001 08:48:58 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA27458; Wed, 27 Jun 2001 08:34:49 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id IAA04697 for megaco-list; Wed, 27 Jun 2001 08:33:12 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA04686 for ; Wed, 27 Jun 2001 08:33:11 -0400 (EDT) Received: from mail.bhartitelesoft.com ([202.56.229.147]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA27174 for ; Wed, 27 Jun 2001 08:33:04 -0400 (EDT) Received: from sarju (taquila [202.56.229.146]) by mail.bhartitelesoft.com (8.11.0/8.11.0) with SMTP id f5RCTpF30227 for ; Wed, 27 Jun 2001 17:59:52 +0530 Message-ID: <00a101c0ff05$e9e210c0$240310ac@bhartitelesoft.com> Reply-To: "Sarju Garg" From: "Sarju Garg" To: "'megaco'" Subject: Query Related to Parameters in Signal Descriptor Date: Wed, 27 Jun 2001 17:55:31 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_009E_01C0FF32.5BBDFFC0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_009E_01C0FF32.5BBDFFC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, I have a following query related to "notifyCompletion" Parameter in = Signal Descriptor: The Annex B says: =20 signalsDescriptor =3D SignalsToken LBRKT [ signalParm *(COMMA = signalParm)] RBRKT signalParm =3D signalList / signalRequest signalRequest =3D signalName [ LBRKT sigParameter *(COMMA = sigParameter) RBRKT ] signalList =3D SignalListToken EQUAL signalListId LBRKT = signalListParm *(COMMA signalListParm) RBRKT signalListId =3D UINT16 ;exactly once signalType, at most once duration and every = signal;parameter signalListParm =3D signalRequest signalName =3D pkgdName ;at-most-once sigStream, at-most-once sigSignalType, ;at-most-once sigDuration, every signalParameterName at most once sigParameter =3D sigStream / sigSignalType / sigDuration / = sigOther / notifyCompletion / KeepActiveToken sigStream =3D StreamToken EQUAL StreamID sigOther =3D sigParameterName parmValue sigParameterName =3D NAME sigSignalType =3D SignalTypeToken EQUAL signalType signalType =3D (OnOffToken / TimeOutToken / BriefToken) sigDuration =3D DurationToken EQUAL UINT16 notifyCompletion =3D NotifyCompletionToken EQUAL (LBRKT = notificationReason *(COMMA notificationReason) RBRKT) notificationReason =3D ( TimeOutToken / InterruptByEventToken / = InterruptByNewSignalsDescrToken / OtherReasonToken ) My query is related to comment above the sigParameter. Does the comment = mean that notifyCompletion and keepActiveToken can come multiple times?=20 Also what does notifyCompletion parameter means? I understand that it = allows MGC to request MG to indicate that MGC is interested in signal = completion notification. I understand that MGC is not interested in = specifying the failure cases. Consider a case that MGC specifies = notifyCompletion parameter with TimeOutToken. Suppose the signal is = played out successfully. What does MG do in that case? I think = notification is only done in failure cases and not for successful case? = Please verify. If so, that in the above case, if the signal fails for = other reason apart from TimeOut what should MG do now? Do it need to = send completion event in that case. Can anyone clarify how to use this = parameter? TIA Sarju ------=_NextPart_000_009E_01C0FF32.5BBDFFC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi all,
 
I have a following query related to=20 "notifyCompletion" Parameter in Signal Descriptor:
The Annex B says:
 
signalsDescriptor    =3D SignalsToken = LBRKT [=20 signalParm  *(COMMA = signalParm)]=20 RBRKT

signalParm          =20 =3D signalList / signalRequest

signalRequest        = =3D=20 signalName [ LBRKT sigParameter      *(COMMA = sigParameter)=20 RBRKT ]

signalList          =20 =3D SignalListToken EQUAL signalListId LBRKT  signalListParm *(COMMA = signalListParm)=20 RBRKT

signalListId         =3D = UINT16

 ;exactly once=20 signalType, at most once duration and every signal;parameter

signalListParm       = =3D=20 signalRequest

 signalName          =20 =3D pkgdName

;at-most-once sigStream, = at-most-once=20 sigSignalType,

;at-most-once=20 sigDuration, every signalParameterName at most once

sigParameter       = =3D=20 sigStream / sigSignalType / sigDuration / sigOther   / notifyCompletion /=20 KeepActiveToken

sigStream           =20 =3D StreamToken EQUAL StreamID

sigOther           &n= bsp;=20 =3D sigParameterName parmValue

sigParameterName     =3D NAME

sigSignalType        = =3D=20 SignalTypeToken EQUAL signalType

signalType          =20 =3D (OnOffToken / TimeOutToken / BriefToken)

sigDuration         =20 =3D DurationToken EQUAL UINT16

notifyCompletion     =3D=20 NotifyCompletionToken EQUAL (LBRKT   notificationReason = *(COMMA=20 notificationReason) RBRKT)

 notificationReason   =3D (=20 TimeOutToken / InterruptByEventToken   /=20 InterruptByNewSignalsDescrToken  / OtherReasonToken )

My query is related to comment above the = sigParameter.=20 Does the comment mean that notifyCompletion and keepActiveToken can come = multiple times?

Also what does = notifyCompletion parameter=20 means? I understand that it allows MGC to request MG to indicate that = MGC is=20 interested in signal completion notification. I understand that MGC is = not=20 interested in specifying the failure cases. Consider a case that MGC = specifies=20 notifyCompletion parameter with TimeOutToken. Suppose the signal is = played out=20 successfully. What does MG do in that case? I think notification is only = done in=20 failure cases and not for successful case? Please verify. If so, that in = the=20 above case, if the signal fails for other reason apart from TimeOut what = should=20 MG do now? Do it need to send completion event in that case. Can anyone = clarify=20 how to use this parameter?

TIA

Sarju

 

------=_NextPart_000_009E_01C0FF32.5BBDFFC0-- From owner-megaco@fore.com Wed Jun 27 10:01:39 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA18939 for ; Wed, 27 Jun 2001 10:01:39 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA06500; Wed, 27 Jun 2001 09:47:10 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id JAA23322 for megaco-list; Wed, 27 Jun 2001 09:43:44 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA23318 for ; Wed, 27 Jun 2001 09:43:43 -0400 (EDT) Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA05884 for ; Wed, 27 Jun 2001 09:43:41 -0400 (EDT) Received: from hoemail2.firewall.lucent.com (localhost [127.0.0.1]) by hoemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5RDhgc29752 for ; Wed, 27 Jun 2001 09:43:42 -0400 (EDT) Received: from teton.mh.lucent.com (h135-3-130-2.lucent.com [135.3.130.2]) by hoemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5RDhdX29691; Wed, 27 Jun 2001 09:43:39 -0400 (EDT) Received: from lucent.com (pctla [135.3.130.39]) by teton.mh.lucent.com (8.8.8+Sun/8.8.8) with ESMTP id JAA13618; Wed, 27 Jun 2001 09:43:37 -0400 (EDT) Message-ID: <3B39E456.2AB4A9C8@lucent.com> Date: Wed, 27 Jun 2001 09:49:11 -0400 From: Terry L Anderson Organization: Lucent Technologies X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Sarju Garg CC: "'megaco'" Subject: Re: Query Related to Parameters in Signal Descriptor References: <00a101c0ff05$e9e210c0$240310ac@bhartitelesoft.com> Content-Type: multipart/mixed; boundary="------------8861478495CE95752402D83C" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk This is a multi-part message in MIME format. --------------8861478495CE95752402D83C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sarju Garg wrote: > Hi all, I have a following query related to "notifyCompletion" > Parameter in Signal Descriptor:The Annex B says: signalsDescriptor= > SignalsToken LBRKT [ signalParm*(COMMA signalParm)] RBRKT > signalParm= signalList / signalRequest > > signalRequest= signalName [ LBRKT sigParameter *(COMMA sigParameter) > RBRKT ] > > signalList= SignalListToken EQUAL signalListId LBRKT signalListParm > *(COMMA signalListParm) RBRKT > > signalListId= UINT16 > > ;exactly once signalType, at most once duration and every > signal;parameter > > signalListParm= signalRequest > > signalName= pkgdName > > ;at-most-once sigStream, at-most-once sigSignalType, > > ;at-most-once sigDuration, every signalParameterName at most once > > sigParameter= sigStream / sigSignalType / sigDuration / sigOther/ > notifyCompletion / KeepActiveToken > > sigStream= StreamToken EQUAL StreamID > > sigOther= sigParameterName parmValue > > sigParameterName= NAME > > sigSignalType= SignalTypeToken EQUAL signalType > > signalType= (OnOffToken / TimeOutToken / BriefToken) > > sigDuration= DurationToken EQUAL UINT16 > > notifyCompletion= NotifyCompletionToken EQUAL > (LBRKT notificationReason *(COMMA notificationReason) RBRKT) > > notificationReason= ( TimeOutToken / InterruptByEventToken/ > InterruptByNewSignalsDescrToken/ OtherReasonToken ) > > My query is related to comment above the sigParameter. Does the > comment mean that notifyCompletion and keepActiveToken can come > multiple times? > > Also what does notifyCompletion parameter means? I understand that it > allows MGC to request MG to indicate that MGC is interested in signal > completion notification. I understand that MGC is not interested in > specifying the failure cases. Consider a case that MGC specifies > notifyCompletion parameter with TimeOutToken. Suppose the signal is > played out successfully. What does MG do in that case? I think > notification is only done in failure cases and not for successful > case? Please verify. If so, that in the above case, if the signal > fails for other reason apart from TimeOut what should MG do now? Do it > need to send completion event in that case. Can anyone clarify how to > use this parameter? I believe that there is only one case not covered by the current language: the one where a signal ends normally but where it is not explicitly timed, e.g., a voice announcement file plays to its end. In a recent discussion, we agreed that this should be treated the same as a signal that completed due to time, that is, NotifyCompletion{TimeOut} and g/sc{Meth=TO}. I have changed the sentence in 7.1.11: "The possible cases are that the signal timed out (or otherwise ended on its own)..." and changed the description for "TO" in E.1.2 to: "Signal Timed out or otherwise ended on its own" in the Implementors Guide to make this understanding explicit (of course that will not be officially approved until the next IG is approved in Feb 2002). > > > TIA > > Sarju > > -- ------------------------------------------------------------ Terry L Anderson mailto:tla@lucent.com Tel:908.582.7013 Fax:908.582.6729 Lucent Technologies/INS/Voice Over IP Access Networks Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla --------------8861478495CE95752402D83C Content-Type: text/x-vcard; charset=us-ascii; name="tla.vcf" Content-Description: Card for Terry L Anderson Content-Disposition: attachment; filename="tla.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Anderson;Terry L tel;fax:908.582.6729 tel;work:908.582.7013 x-mozilla-html:TRUE url:http://its.lucent.com/~tla org:Lucent / InterNetworking Systems;VoIP Access Networks version:2.1 email;internet:tla@lucent.com title:DMTS note:http://www.gti.net/tla or http://teton.mh.lucent.com/~tla (Lucent internal) adr;quoted-printable:;;600 Mountain Av=0D=0ARm 2B-121;Murray Hill;NJ;07974;USA x-mozilla-cpt:;21296 fn:Terry L Anderson end:vcard --------------8861478495CE95752402D83C-- From owner-megaco@fore.com Wed Jun 27 10:19:56 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA25501 for ; Wed, 27 Jun 2001 10:19:55 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA10550; Wed, 27 Jun 2001 10:09:57 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA02664 for megaco-list; Wed, 27 Jun 2001 10:08:59 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA02659 for ; Wed, 27 Jun 2001 10:08:58 -0400 (EDT) From: bgill@hss.hns.com Received: from hindon.hss.co.in ([202.54.26.202]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA10338 for ; Wed, 27 Jun 2001 10:08:54 -0400 (EDT) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id f5REAAP02996 for ; Wed, 27 Jun 2001 19:40:10 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256A78.004E0A0B ; Wed, 27 Jun 2001 19:42:23 +0530 X-Lotus-FromDomain: HSS To: megaco@fore.com Message-ID: <65256A78.004E0951.00@sandesh.hss.hns.com> Date: Wed, 27 Jun 2001 19:42:34 +0530 Subject: query regarding auditReply Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Hi all, The MEGACO ABNF grammar has, auditReply = (AuditValueToken / AuditCapToken)(contextTerminationAudit / auditOther) auditOther = EQUAL TerminationID LBRKT terminationAudit RBRKT contextTerminationAudit = EQUAL CtxToken (terminationIDList / LBRKT errorDescriptor RBRKT) now, if the terminationID in auditOther is "Context" (which is a bit unlikely, but technically it IS possible) the parser has no clue as to its parsing auditOther or contextTerminationAudit. What if the MEGACO message is to be parsed by a parser with no lookahead whatsoever. Can't we have all the MEGACO tokens as reserved keywords, thus makin the life of MEGACO parser developer a bit easier ;-) Regards, B.S.Gill From owner-megaco@fore.com Wed Jun 27 12:38:57 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA15446 for ; Wed, 27 Jun 2001 12:38:57 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA27382; Wed, 27 Jun 2001 12:24:53 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id MAA08271 for megaco-list; Wed, 27 Jun 2001 12:21:20 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA08267 for ; Wed, 27 Jun 2001 12:21:18 -0400 (EDT) From: rcxvhmn3un@yahoo.com Received: from scserver.lnpt.co.th (lnpt.co.th [203.148.252.90] (may be forged)) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA26989 for ; Wed, 27 Jun 2001 12:21:09 -0400 (EDT) Received: from n51299r72 (ip213.lawest.quik.com [216.176.1.213]) by scserver.lnpt.co.th with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3) id NBCN3YBV; Mon, 18 Jun 2001 01:43:50 +0700 DATE: 17 Jun 02 10:08:50 AM Message-ID: Content-Type: text/html SUBJECT: Wave of the Future Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk We will put your product or service instantly into the hands of millions of prospects! =============================================================== "Many business people are finding out that they can now advertise in ways that they never could have afforded in the past. The cost of sending mass e-mail is extremely low, and the response rate is high and quick." - USA TODAY =============================================================== Since 1996, Bulk Email Network has provided bulk email marketing to thousands of well-satisfied customers. We offer the most competitive prices in the industry, made possible by our high percentage of repeat business. We have the most advanced direct email technology employed by only a knowledgeable few in the world. We have over 160 million active email addresses, increasing our list at the rate of half a million to one million a month. You will have instant guaranteed results, something no other form of marketing can claim. Our turn around time is a remarkable 24 hours. Our email addresses are sorted by country, state, city and target. Your marketing campaign will speed with pinpoint accuracy to your desired audience! Call us for a free consultation at 323 876 6148 [U.S.A.]. We guarantee the lowest prices or your service is free! Best of ALL, Bulk Email Network can be used as a 100% TAX WRITE OFF for your Business! 1) Let's say you... Sell a $24.95 PRODUCT or SERVICE. 2) Let's say you... Mass Email to 1,000,000 PEOPLE DAILY. 3) Let's say you... Receive JUST 1 ORDER for EVERY 2,500 EMAILS. CALCULATION OF YOUR EARNINGS BASED ON THE ABOVE STATISTICS: [Day 1]: $9,980 [Week 1]: $69,860 [Month 1]: $279,440 Now you know why you receive so many email advertisements... Best Regards, Sam Al Bulk Email Network C.E.O Under Bill s.1618 TITLE III passed by the 105th U.S. Congress this letter is not considered "spam" as long as we include: 1) contact information and, 2) the way to be removed from future mailings (see below). To Remove Yourself From This List: Please email to jk72jk72@yahoo.com with the email address that you would like removed and the word REMOVE in the subject heading. From owner-megaco@fore.com Wed Jun 27 13:13:41 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA24898 for ; Wed, 27 Jun 2001 13:13:40 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA01248; Wed, 27 Jun 2001 12:58:59 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id MAA16220 for megaco-list; Wed, 27 Jun 2001 12:57:07 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA16216 for ; Wed, 27 Jun 2001 12:57:06 -0400 (EDT) From: getcredit33@turbomail.net Received: from lun.co.jp ([202.229.220.192]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA00886 for ; Wed, 27 Jun 2001 12:56:53 -0400 (EDT) Received: from www.turbomail.net (slip-32-103-26-42.mn.us.prserv.net.26.103.32.in-addr.arpa [32.103.26.42]) by lun.co.jp (8.8.5+2.7Wbeta5/3.5Wbeta:04/10/97) with SMTP id BAA16612 for ; Thu, 28 Jun 2001 01:47:31 +0900 (JST) To: Date: Wed, 27 Jun 2001 08:25:17 Message-Id: <797.873569.738004@www.turbomail.net> Subject: L@@K - Get a Credit Card Now!! Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: 7bit Need a credit card? Whether you have good, medium or POOR credit, we can help you get a credit card. For a one time fee of less than $100 we will provide you with access to over 100 banks and financial institutions that are looking to give Major Credit Cards out. We will provide you with direct links to apply online, and get approved online, in most cases in 60 seconds or less. We are so sure that you will get a credit card, we offer a money back guarantee! You have nothing to lose! So don't wait any longer, get your credit card today. http://www.fasthostnow.net/credit/index.html?marketing_id=11 To be removed from our mailing list please visit http://www.fasthostnow.net/credit/remove.html From owner-megaco@fore.com Wed Jun 27 18:53:26 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA15223 for ; Wed, 27 Jun 2001 18:53:25 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA04549; Wed, 27 Jun 2001 18:43:22 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id SAA00530 for megaco-list; Wed, 27 Jun 2001 18:40:35 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA00525 for ; Wed, 27 Jun 2001 18:40:34 -0400 (EDT) From: ab49@hotmail.com Received: from telepeep.mail-srv.de ([62.180.233.234]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA04339 for ; Wed, 27 Jun 2001 18:40:31 -0400 (EDT) Received: from 62.168.126.47 [142.154.117.247] by telepeep.mail-srv.de (SMTPD32-6.00) id AF9C277008E; Thu, 28 Jun 2001 00:35:08 +0200 Message-ID: <000047653d49$000067df$00006d24@62.168.77.19> To: Subject: I Can't Wait Anymore! Date: Fri, 29 Jun 2001 17:43:25 -0700 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal Reply-To: sasha6539@MailOps.Com Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: quoted-printable From owner-megaco@fore.com Wed Jun 27 22:27:24 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA13000 for ; Wed, 27 Jun 2001 22:27:24 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id WAA12264; Wed, 27 Jun 2001 22:15:42 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id WAA17029 for megaco-list; Wed, 27 Jun 2001 22:14:28 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id WAA17023 for ; Wed, 27 Jun 2001 22:14:26 -0400 (EDT) Received: from hotmail.com (f226.law14.hotmail.com [64.4.21.226]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id WAA12157 for ; Wed, 27 Jun 2001 22:14:23 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Jun 2001 19:14:25 -0700 Received: from 61.132.62.80 by lw14fd.law14.hotmail.msn.com with HTTP; Thu, 28 Jun 2001 02:14:25 GMT X-Originating-IP: [61.132.62.80] From: "mu lj" To: Brian.Rosen@marconi.com, megaco@fore.com Subject: RE: how to identify a conference resource Date: Thu, 28 Jun 2001 10:14:25 +0800 Mime-Version: 1.0 Content-Type: text/plain; charset=gb2312; format=flowed Message-ID: X-OriginalArrivalTime: 28 Jun 2001 02:14:25.0477 (UTC) FILETIME=[0D8B5F50:01C0FF78] Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk hi: Thanks your answer. In megaco protocol,there is a way describle a 3-part service use topology.but when 3-part resources are in Media Server,how to use termination to identify a 3-part? Mu Lingjiang >From: "Rosen, Brian" >To: "'mu lj'" , megaco@fore.com >Subject: RE: how to identify a conference resource >Date: Wed, 27 Jun 2001 08:29:46 -0400 > >There are several models people have proposed. >One is that each conference is a context, and ephemerals representing the >network flows >are the "ports". That is the easiest one to implement. You could also have >physical >ports if your hardware could do that. > >Another model is that each "port" is represented as a physical terminal, and >you have >a collection of two termination contexts. In this model, there is a >property on the >physical ports that has a "conference id". This model has the advantage >that the >MGC can easily track the resources in the Media Server. > >I haven't seen a concrete package proposal yet. Either model will work >fine. > >Brian > > > -----Original Message----- > > From: mu lj [mailto:dtxlymlj@hotmail.com] > > Sent: Tuesday, June 26, 2001 11:42 PM > > To: megaco@fore.com > > Subject: how to identify a conference resource > > > > > > hi all: > > I have a question about conference resource. Media Server has many > > conference resource and hasn't trunk terminations or analog line > > terminations. how to use termination to identify a conference > > in Media > > Server? how does MGC distinguish different conferences using megaco > > protocol in Media Server? > > ______________________________________________________________ > > ___________ > > Get Your Private, Free E-mail from MSN Hotmail at > > http://www.hotmail.com. > > _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. From owner-megaco@fore.com Thu Jun 28 01:28:01 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA24118 for ; Thu, 28 Jun 2001 01:28:00 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id BAA17457; Thu, 28 Jun 2001 01:18:57 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id BAA27408 for megaco-list; Thu, 28 Jun 2001 01:16:49 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id BAA27401 for ; Thu, 28 Jun 2001 01:16:47 -0400 (EDT) Received: from mail.bhartitelesoft.com ([202.56.229.147]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id BAA17132 for ; Thu, 28 Jun 2001 01:16:38 -0400 (EDT) Received: from sarju (taquila [202.56.229.146]) by mail.bhartitelesoft.com (8.11.0/8.11.0) with SMTP id f5S5DFF25370; Thu, 28 Jun 2001 10:43:16 +0530 Message-ID: <003101c0ff92$216d6760$240310ac@bhartitelesoft.com> Reply-To: "Sarju Garg" From: "Sarju Garg" To: "Terry L Anderson" Cc: "'megaco'" References: <00a101c0ff05$e9e210c0$240310ac@bhartitelesoft.com> <3B39E456.2AB4A9C8@lucent.com> Subject: Re: Query Related to Parameters in Signal Descriptor Date: Thu, 28 Jun 2001 10:50:59 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: 7bit Thanks Terry for your reply. How does MGC know in that case that the signal haved played out successfully or timeout? If the signal fails for other reason apart from that mentioned by MGC then what should MG do ? Do it need to send completion event in that case also?. I think the logic should be as follows: MGC should specify whether it wants notification for the signal playout for both successful/unsuccessful cases?. It must only specify the optional parameter "NotificationCompletionToken" and not the notificationReason as of now. Now, after the MG plays the signal out, then it sends NotificationCompletion with reason set to "signal ended on its own".In case the MG finds some error it sends NotificationCompletion with reason set to "one of 4 mentioned reasons". TO and signal ended on its own should be two different cases and not one. Also please let me know the answer of my question related to comment over the sigParameter. I think the comment should be modified to: ;one or more sigother with every signalParameterName at most once ; other sigParameter at most once. TIA Sarju ----- Original Message ----- From: Terry L Anderson To: Sarju Garg Cc: 'megaco' Sent: Wednesday, June 27, 2001 7:19 PM Subject: Re: Query Related to Parameters in Signal Descriptor > > > Sarju Garg wrote: > > > Hi all, I have a following query related to "notifyCompletion" > > Parameter in Signal Descriptor:The Annex B says: signalsDescriptor= > > SignalsToken LBRKT [ signalParm*(COMMA signalParm)] RBRKT > > signalParm= signalList / signalRequest > > > > signalRequest= signalName [ LBRKT sigParameter *(COMMA sigParameter) > > RBRKT ] > > > > signalList= SignalListToken EQUAL signalListId LBRKT signalListParm > > *(COMMA signalListParm) RBRKT > > > > signalListId= UINT16 > > > > ;exactly once signalType, at most once duration and every > > signal;parameter > > > > signalListParm= signalRequest > > > > signalName= pkgdName > > > > ;at-most-once sigStream, at-most-once sigSignalType, > > > > ;at-most-once sigDuration, every signalParameterName at most once > > > > sigParameter= sigStream / sigSignalType / sigDuration / sigOther/ > > notifyCompletion / KeepActiveToken > > > > sigStream= StreamToken EQUAL StreamID > > > > sigOther= sigParameterName parmValue > > > > sigParameterName= NAME > > > > sigSignalType= SignalTypeToken EQUAL signalType > > > > signalType= (OnOffToken / TimeOutToken / BriefToken) > > > > sigDuration= DurationToken EQUAL UINT16 > > > > notifyCompletion= NotifyCompletionToken EQUAL > > (LBRKT notificationReason *(COMMA notificationReason) RBRKT) > > > > notificationReason= ( TimeOutToken / InterruptByEventToken/ > > InterruptByNewSignalsDescrToken/ OtherReasonToken ) > > > > My query is related to comment above the sigParameter. Does the > > comment mean that notifyCompletion and keepActiveToken can come > > multiple times? > > > > Also what does notifyCompletion parameter means? I understand that it > > allows MGC to request MG to indicate that MGC is interested in signal > > completion notification. I understand that MGC is not interested in > > specifying the failure cases. Consider a case that MGC specifies > > notifyCompletion parameter with TimeOutToken. Suppose the signal is > > played out successfully. What does MG do in that case? I think > > notification is only done in failure cases and not for successful > > case? Please verify. If so, that in the above case, if the signal > > fails for other reason apart from TimeOut what should MG do now? Do it > > need to send completion event in that case. Can anyone clarify how to > > use this parameter? > > I believe that there is only one case not covered by the current > language: the one where a signal ends normally but where it is not > explicitly timed, e.g., a voice announcement file plays to its end. In > a recent discussion, we agreed that this should be treated the same as a > signal that completed due to time, that is, NotifyCompletion{TimeOut} > and g/sc{Meth=TO}. I have changed the sentence in 7.1.11: > "The possible cases are that the signal timed out (or otherwise > ended on its own)..." > > and changed the description for "TO" in E.1.2 to: > "Signal Timed out or otherwise ended on its own" > > in the Implementors Guide to make this understanding explicit (of course > that will not be officially approved until the next IG is approved in > Feb 2002). > > > > > > > TIA > > > > Sarju > > > > > > -- > ------------------------------------------------------------ > Terry L Anderson mailto:tla@lucent.com > Tel:908.582.7013 Fax:908.582.6729 > Lucent Technologies/INS/Voice Over IP Access Networks > Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 > http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla > > From owner-megaco@fore.com Thu Jun 28 06:19:14 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA10244 for ; Thu, 28 Jun 2001 06:19:13 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id GAA26603; Thu, 28 Jun 2001 06:09:01 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id GAA18433 for megaco-list; Thu, 28 Jun 2001 06:05:52 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id GAA18429 for ; Thu, 28 Jun 2001 06:05:51 -0400 (EDT) Received: from cvis29.marconicomms.com (cvis29.marconicomms.com [195.99.244.61] (may be forged)) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id GAA26435 for ; Thu, 28 Jun 2001 06:05:48 -0400 (EDT) Received: from cvis01.gpt.co.uk (unverified) by cvis29.marconicomms.com (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Thu, 28 Jun 2001 11:04:46 +0100 Received: from marconicomms.com by cvis01.gpt.co.uk with SMTP (8.8.8+Sun/cvms-32) id LAA11015; Thu, 28 Jun 2001 11:04:47 +0100 (BST) Received: by marconicomms.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 80256A79.00375327 ; Thu, 28 Jun 2001 11:04:17 +0100 X-Lotus-FromDomain: MCMAIN@MCEXT From: "Sean Leahy" To: "Brian Rosen" cc: megaco@fore.com Message-ID: <80256A79.00371486.00@marconicomms.com> Date: Thu, 28 Jun 2001 11:01:48 +0100 Subject: Echo Cancellation &TDMC Package Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Brian. Re: The TDMC package (at a TDM <-> ATM Gateway)- Would you clarify the following question ? Does the Echo Cancellation Property being set mean the MG cancels Echo heading towards the TDM or towards the ATM ? Thanks, Sean Leahy From owner-megaco@fore.com Thu Jun 28 09:24:37 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA26785 for ; Thu, 28 Jun 2001 09:24:36 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA10504; Thu, 28 Jun 2001 09:14:05 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id JAA17825 for megaco-list; Thu, 28 Jun 2001 09:10:52 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA17795 for ; Thu, 28 Jun 2001 09:10:48 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 28 Jun 2001 09:10:47 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF0446564E@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'mu lj'" , megaco@fore.com Subject: RE: how to identify a conference resource Date: Thu, 28 Jun 2001 09:10:46 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="GB2312" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk I would not use topology to control a 3-way call (two parties talking, one on hold, ability to switch to the "on hold" part). I would do that with two contexts, one of which had two terminations, the other of which had one (if silence to the held party was desired) or two (if music-on-hold was provided) terminations, using Move to change parties. The Media Server could do the same. Brian > -----Original Message----- > From: mu lj [mailto:dtxlymlj@hotmail.com] > Sent: Wednesday, June 27, 2001 10:14 PM > To: Brian.Rosen@marconi.com; megaco@fore.com > Subject: RE: how to identify a conference resource > > > hi: > Thanks your answer. > In megaco protocol,there is a way describle a 3-part service use > topology.but when 3-part resources are in Media Server,how to use > termination to identify a 3-part? > > Mu Lingjiang > > >From: "Rosen, Brian" > >To: "'mu lj'" , megaco@fore.com > >Subject: RE: how to identify a conference resource > >Date: Wed, 27 Jun 2001 08:29:46 -0400 > > > >There are several models people have proposed. > >One is that each conference is a context, and ephemerals > representing the > >network flows > >are the "ports". That is the easiest one to implement. You > could also > have > >physical > >ports if your hardware could do that. > > > >Another model is that each "port" is represented as a > physical terminal, > and > >you have > >a collection of two termination contexts. In this model, there is a > >property on the > >physical ports that has a "conference id". This model has > the advantage > >that the > >MGC can easily track the resources in the Media Server. > > > >I haven't seen a concrete package proposal yet. Either > model will work > >fine. > > > >Brian > > > > > -----Original Message----- > > > From: mu lj [mailto:dtxlymlj@hotmail.com] > > > Sent: Tuesday, June 26, 2001 11:42 PM > > > To: megaco@fore.com > > > Subject: how to identify a conference resource > > > > > > > > > hi all: > > > I have a question about conference resource. Media > Server has many > > > conference resource and hasn't trunk terminations or analog line > > > terminations. how to use termination to identify a conference > > > in Media > > > Server? how does MGC distinguish different conferences > using megaco > > > protocol in Media Server? > > > ______________________________________________________________ > > > ___________ > > > Get Your Private, Free E-mail from MSN Hotmail at > > > http://www.hotmail.com. > > > > > ______________________________________________________________ > ___________ > Get Your Private, Free E-mail from MSN Hotmail at > http://www.hotmail.com. > From owner-megaco@fore.com Thu Jun 28 11:22:27 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA18728 for ; Thu, 28 Jun 2001 11:22:24 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA23425; Thu, 28 Jun 2001 10:51:25 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA14462 for megaco-list; Thu, 28 Jun 2001 10:49:10 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA14439 for ; Thu, 28 Jun 2001 10:49:08 -0400 (EDT) Received: from ertpg15e1.nortelnetworks.com (ertpg15e1.nortelnetworks.com [47.234.0.36]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA22904 for ; Thu, 28 Jun 2001 10:49:04 -0400 (EDT) Received: from ertpg14e1.nortelnetworks.com (zrtph06m [47.125.208.110]) by ertpg15e1.nortelnetworks.com (8.11.0/8.11.0) with ESMTP id f5SEn1U29318 for ; Thu, 28 Jun 2001 10:49:01 -0400 (EDT) Received: from zrtpd00y.us.nortel.com by ertpg14e1.nortelnetworks.com; Thu, 28 Jun 2001 10:48:51 -0400 Received: by zrtpd00y.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Jun 2001 10:47:38 -0400 Message-ID: <6DEE1D8911D5D411953E00508BE3DDF601691DF3@zrtpd0jn.us.nortel.com> From: "Kevin Boyle" To: Sarju Garg , Terry L Anderson Cc: "'megaco'" Subject: RE: Query Related to Parameters in Signal Descriptor Date: Thu, 28 Jun 2001 10:47:40 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0FFE1.4800F280" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0FFE1.4800F280 Content-Type: text/plain; charset="iso-8859-1" Why is there a substantial difference between "timeout" and "ended on its own"? Signals of type TO will "timeout"; signals of type BR will "end on its own"; signals of type OO will not end unless interrupted by an event or a new signals descriptor. In the example given by Terry, the voice announcement should be a BR signal -- one that has a finite length and does not repeat. Timeout signals repeat until they reach their timeout duration, for example, playing dial tone for 16 seconds. Essentially, therefore, "timeout" and "ended on its own" are exactly functionally equivalent, with one applying to TO signals, and the other to BR signals. That being the case, I see no reason to alter what Terry has proposed. Kevin -----Original Message----- From: Sarju Garg [mailto:sarju@bhartitelesoft.com] Sent: Thursday, June 28, 2001 1:21 AM To: Terry L Anderson Cc: 'megaco' Subject: Re: Query Related to Parameters in Signal Descriptor Thanks Terry for your reply. How does MGC know in that case that the signal haved played out successfully or timeout? If the signal fails for other reason apart from that mentioned by MGC then what should MG do ? Do it need to send completion event in that case also?. I think the logic should be as follows: MGC should specify whether it wants notification for the signal playout for both successful/unsuccessful cases?. It must only specify the optional parameter "NotificationCompletionToken" and not the notificationReason as of now. Now, after the MG plays the signal out, then it sends NotificationCompletion with reason set to "signal ended on its own".In case the MG finds some error it sends NotificationCompletion with reason set to "one of 4 mentioned reasons". TO and signal ended on its own should be two different cases and not one. Also please let me know the answer of my question related to comment over the sigParameter. I think the comment should be modified to: ;one or more sigother with every signalParameterName at most once ; other sigParameter at most once. TIA Sarju ----- Original Message ----- From: Terry L Anderson To: Sarju Garg Cc: 'megaco' Sent: Wednesday, June 27, 2001 7:19 PM Subject: Re: Query Related to Parameters in Signal Descriptor > > > Sarju Garg wrote: > > > Hi all, I have a following query related to "notifyCompletion" > > Parameter in Signal Descriptor:The Annex B says: signalsDescriptor= > > SignalsToken LBRKT [ signalParm*(COMMA signalParm)] RBRKT > > signalParm= signalList / signalRequest > > > > signalRequest= signalName [ LBRKT sigParameter *(COMMA sigParameter) > > RBRKT ] > > > > signalList= SignalListToken EQUAL signalListId LBRKT signalListParm > > *(COMMA signalListParm) RBRKT > > > > signalListId= UINT16 > > > > ;exactly once signalType, at most once duration and every > > signal;parameter > > > > signalListParm= signalRequest > > > > signalName= pkgdName > > > > ;at-most-once sigStream, at-most-once sigSignalType, > > > > ;at-most-once sigDuration, every signalParameterName at most once > > > > sigParameter= sigStream / sigSignalType / sigDuration / sigOther/ > > notifyCompletion / KeepActiveToken > > > > sigStream= StreamToken EQUAL StreamID > > > > sigOther= sigParameterName parmValue > > > > sigParameterName= NAME > > > > sigSignalType= SignalTypeToken EQUAL signalType > > > > signalType= (OnOffToken / TimeOutToken / BriefToken) > > > > sigDuration= DurationToken EQUAL UINT16 > > > > notifyCompletion= NotifyCompletionToken EQUAL > > (LBRKT notificationReason *(COMMA notificationReason) RBRKT) > > > > notificationReason= ( TimeOutToken / InterruptByEventToken/ > > InterruptByNewSignalsDescrToken/ OtherReasonToken ) > > > > My query is related to comment above the sigParameter. Does the > > comment mean that notifyCompletion and keepActiveToken can come > > multiple times? > > > > Also what does notifyCompletion parameter means? I understand that it > > allows MGC to request MG to indicate that MGC is interested in signal > > completion notification. I understand that MGC is not interested in > > specifying the failure cases. Consider a case that MGC specifies > > notifyCompletion parameter with TimeOutToken. Suppose the signal is > > played out successfully. What does MG do in that case? I think > > notification is only done in failure cases and not for successful > > case? Please verify. If so, that in the above case, if the signal > > fails for other reason apart from TimeOut what should MG do now? Do it > > need to send completion event in that case. Can anyone clarify how to > > use this parameter? > > I believe that there is only one case not covered by the current > language: the one where a signal ends normally but where it is not > explicitly timed, e.g., a voice announcement file plays to its end. In > a recent discussion, we agreed that this should be treated the same as a > signal that completed due to time, that is, NotifyCompletion{TimeOut} > and g/sc{Meth=TO}. I have changed the sentence in 7.1.11: > "The possible cases are that the signal timed out (or otherwise > ended on its own)..." > > and changed the description for "TO" in E.1.2 to: > "Signal Timed out or otherwise ended on its own" > > in the Implementors Guide to make this understanding explicit (of course > that will not be officially approved until the next IG is approved in > Feb 2002). > > > > > > > TIA > > > > Sarju > > > > > > -- > ------------------------------------------------------------ > Terry L Anderson mailto:tla@lucent.com > Tel:908.582.7013 Fax:908.582.6729 > Lucent Technologies/INS/Voice Over IP Access Networks > Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 > http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla > > ------_=_NextPart_001_01C0FFE1.4800F280 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Query Related to Parameters in Signal Descriptor

Why is there a substantial difference between = "timeout" and "ended on its own"?  Signals of = type TO will "timeout"; signals of type BR will "end on = its own"; signals of type OO will not end unless interrupted by an = event or a new signals descriptor.

In the example given by Terry, the voice announcement = should be a BR signal -- one that has a finite length and does not = repeat.  Timeout signals repeat until they reach their timeout = duration, for example, playing dial tone for 16 seconds.

Essentially, therefore, "timeout" and = "ended on its own" are exactly functionally equivalent, with = one applying to TO signals, and the other to BR signals.

That being the case, I see no reason to alter what = Terry has proposed.

Kevin

-----Original Message-----
From: Sarju Garg [mailto:sarju@bhartitelesoft.com= ]
Sent: Thursday, June 28, 2001 1:21 AM
To: Terry L Anderson
Cc: 'megaco'
Subject: Re: Query Related to Parameters in Signal = Descriptor

Thanks Terry for your reply.

How does MGC know in that case that the signal haved = played out successfully
or timeout?

If the signal fails for other reason apart from that = mentioned by MGC then
what should MG do ? Do it need to send completion = event in that case also?.

 I think the logic should be as follows:
MGC should specify whether it wants notification for = the signal playout for
both successful/unsuccessful cases?. It must only = specify the optional
parameter "NotificationCompletionToken" = and not the notificationReason as of
now. Now, after the MG plays the signal out, then it = sends
NotificationCompletion with reason set to = "signal ended on its own".In case
the MG finds some error it sends = NotificationCompletion with reason set to
"one of 4 mentioned reasons". TO and = signal ended on its own should be two
different cases and not one.

Also please let me know the answer of my question = related to comment over
the sigParameter. I think the comment should be = modified to:
;one or more sigother with every signalParameterName = at most once
; other sigParameter at most once.

TIA
Sarju
----- Original Message -----
From: Terry L Anderson <tla@lucent.com>
To: Sarju Garg = <sarju@bhartitelesoft.com>
Cc: 'megaco' <megaco@fore.com>
Sent: Wednesday, June 27, 2001 7:19 PM
Subject: Re: Query Related to Parameters in Signal = Descriptor


>
>
> Sarju Garg wrote:
>
> > Hi all, I have a following query related = to "notifyCompletion"
> > Parameter in Signal Descriptor:The Annex B = says: signalsDescriptor=3D
> > SignalsToken LBRKT [ signalParm*(COMMA = signalParm)] RBRKT
> > signalParm=3D signalList / = signalRequest
> >
> > signalRequest=3D signalName [ LBRKT = sigParameter *(COMMA sigParameter)
> > RBRKT ]
> >
> > signalList=3D SignalListToken EQUAL = signalListId LBRKT signalListParm
> > *(COMMA signalListParm) RBRKT
> >
> > signalListId=3D UINT16
> >
> >  ;exactly once signalType, at most = once duration and every
> > signal;parameter
> >
> > signalListParm=3D signalRequest
> >
> >  signalName=3D pkgdName
> >
> > ;at-most-once sigStream, at-most-once = sigSignalType,
> >
> > ;at-most-once sigDuration, every = signalParameterName at most once
> >
> > sigParameter=3D sigStream / sigSignalType = / sigDuration / sigOther/
> > notifyCompletion / KeepActiveToken
> >
> > sigStream=3D StreamToken EQUAL = StreamID
> >
> > sigOther=3D sigParameterName = parmValue
> >
> > sigParameterName=3D NAME
> >
> > sigSignalType=3D SignalTypeToken EQUAL = signalType
> >
> > signalType=3D (OnOffToken / TimeOutToken / = BriefToken)
> >
> > sigDuration=3D DurationToken EQUAL = UINT16
> >
> > notifyCompletion=3D NotifyCompletionToken = EQUAL
> > (LBRKT notificationReason *(COMMA = notificationReason) RBRKT)
> >
> >  notificationReason=3D ( TimeOutToken = / InterruptByEventToken/
> > InterruptByNewSignalsDescrToken/ = OtherReasonToken )
> >
> > My query is related to comment above the = sigParameter. Does the
> > comment mean that notifyCompletion and = keepActiveToken can come
> > multiple times?
> >
> > Also what does notifyCompletion parameter = means? I understand that it
> > allows MGC to request MG to indicate that = MGC is interested in signal
> > completion notification. I understand that = MGC is not interested in
> > specifying the failure cases. Consider a = case that MGC specifies
> > notifyCompletion parameter with = TimeOutToken. Suppose the signal is
> > played out successfully. What does MG do = in that case? I think
> > notification is only done in failure cases = and not for successful
> > case? Please verify. If so, that in the = above case, if the signal
> > fails for other reason apart from TimeOut = what should MG do now? Do it
> > need to send completion event in that = case. Can anyone clarify how to
> > use this parameter?
>
> I believe that there is only one case not = covered by the current
> language: the one where a signal ends normally = but where it is not
> explicitly timed, e.g., a voice announcement = file plays to its end.  In
> a recent discussion, we agreed that this should = be treated the same as a
> signal that completed due to time, that is, = NotifyCompletion{TimeOut}
> and g/sc{Meth=3DTO}.  I have changed the = sentence in 7.1.11:
>     "The possible = cases are that the signal timed out (or otherwise
> ended on its own)..."
>
> and changed the description for "TO" = in E.1.2 to:
>     "Signal Timed out = or otherwise ended on its own"
>
> in the Implementors Guide to make this = understanding explicit (of course
> that will not be officially approved until the = next IG is approved in
> Feb 2002).
>
> >
> >
> > TIA
> >
> > Sarju
> >
> >
>
> --
> = ------------------------------------------------------------
> Terry L = Anderson          &nbs= p;   mailto:tla@lucent.com
> Tel:908.582.7013   = Fax:908.582.6729
> Lucent Technologies/INS/Voice Over IP Access = Networks
> Rm 2B-121, 600 Mountain Av, Murray Hill, NJ = 07974
> http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla
>
>

------_=_NextPart_001_01C0FFE1.4800F280-- From owner-megaco@fore.com Thu Jun 28 11:49:26 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08592 for ; Thu, 28 Jun 2001 11:49:25 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA22092; Thu, 28 Jun 2001 10:43:31 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA11688 for megaco-list; Thu, 28 Jun 2001 10:39:16 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA11680 for ; Thu, 28 Jun 2001 10:39:14 -0400 (EDT) Received: from ertpg15e1.nortelnetworks.com (ertpg15e1.nortelnetworks.com [47.234.0.36]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA21425 for ; Thu, 28 Jun 2001 10:39:11 -0400 (EDT) Received: from ertpg14e1.nortelnetworks.com (zrtph06m [47.125.208.110]) by ertpg15e1.nortelnetworks.com (8.11.0/8.11.0) with ESMTP id f5SEcpU26980 for ; Thu, 28 Jun 2001 10:38:51 -0400 (EDT) Received: from zrtpd00y.us.nortel.com by ertpg14e1.nortelnetworks.com; Thu, 28 Jun 2001 10:38:33 -0400 Received: by zrtpd00y.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Jun 2001 10:37:59 -0400 Message-ID: <6DEE1D8911D5D411953E00508BE3DDF601691DE3@zrtpd0jn.us.nortel.com> From: "Kevin Boyle" To: megaco@fore.com Subject: FW: how to identify a conference resource Date: Thu, 28 Jun 2001 10:38:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0FFDF.EFA10130" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0FFDF.EFA10130 Content-Type: text/plain; charset="gb2312" Just a quick clarification, as my main background is in line features: This scenario is not a three-way call, but is rather call waiting, since the third party is never talking to the other two. Three-way call is, essentially, a three-port conference. Kevin -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] Sent: Thursday, June 28, 2001 9:11 AM To: 'mu lj'; megaco@fore.com Subject: RE: how to identify a conference resource I would not use topology to control a 3-way call (two parties talking, one on hold, ability to switch to the "on hold" part). I would do that with two contexts, one of which had two terminations, the other of which had one (if silence to the held party was desired) or two (if music-on-hold was provided) terminations, using Move to change parties. The Media Server could do the same. Brian > -----Original Message----- > From: mu lj [mailto:dtxlymlj@hotmail.com] > Sent: Wednesday, June 27, 2001 10:14 PM > To: Brian.Rosen@marconi.com; megaco@fore.com > Subject: RE: how to identify a conference resource > > > hi: > Thanks your answer. > In megaco protocol,there is a way describle a 3-part service use > topology.but when 3-part resources are in Media Server,how to use > termination to identify a 3-part? > > Mu Lingjiang > > >From: "Rosen, Brian" > >To: "'mu lj'" , megaco@fore.com > >Subject: RE: how to identify a conference resource > >Date: Wed, 27 Jun 2001 08:29:46 -0400 > > > >There are several models people have proposed. > >One is that each conference is a context, and ephemerals > representing the > >network flows > >are the "ports". That is the easiest one to implement. You > could also > have > >physical > >ports if your hardware could do that. > > > >Another model is that each "port" is represented as a > physical terminal, > and > >you have > >a collection of two termination contexts. In this model, there is a > >property on the > >physical ports that has a "conference id". This model has > the advantage > >that the > >MGC can easily track the resources in the Media Server. > > > >I haven't seen a concrete package proposal yet. Either > model will work > >fine. > > > >Brian > > > > > -----Original Message----- > > > From: mu lj [mailto:dtxlymlj@hotmail.com] > > > Sent: Tuesday, June 26, 2001 11:42 PM > > > To: megaco@fore.com > > > Subject: how to identify a conference resource > > > > > > > > > hi all: > > > I have a question about conference resource. Media > Server has many > > > conference resource and hasn't trunk terminations or analog line > > > terminations. how to use termination to identify a conference > > > in Media > > > Server? how does MGC distinguish different conferences > using megaco > > > protocol in Media Server? > > > ______________________________________________________________ > > > ___________ > > > Get Your Private, Free E-mail from MSN Hotmail at > > > http://www.hotmail.com. > > > > > ______________________________________________________________ > ___________ > Get Your Private, Free E-mail from MSN Hotmail at > http://www.hotmail.com. > ------_=_NextPart_001_01C0FFDF.EFA10130 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable FW: how to identify a conference resource

Just a quick clarification, as my main background is = in line features: This scenario is not a three-way call, but is rather = call waiting, since the third party is never talking to the other = two.  Three-way call is, essentially, a three-port = conference.

Kevin

-----Original Message-----
From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
Sent: Thursday, June 28, 2001 9:11 AM
To: 'mu lj'; megaco@fore.com
Subject: RE: how to identify a conference = resource

I would not use topology to control a 3-way call (two = parties talking, one
on
hold, ability to switch to the "on hold" = part).  I would do that with two
contexts, one of which had two terminations, the = other of which had one
(if silence to the held party was desired) or two = (if music-on-hold was
provided) terminations, using Move to change = parties.  The Media
Server could do the same.

Brian

> -----Original Message-----
> From: mu lj [mailto:dtxlymlj@hotmail.com]
> Sent: Wednesday, June 27, 2001 10:14 PM
> To: Brian.Rosen@marconi.com; = megaco@fore.com
> Subject: RE: how to identify a conference = resource
>
>
> hi:
>   Thanks your answer.
>   In megaco protocol,there is a way = describle a 3-part service use
> topology.but when 3-part resources are in Media = Server,how to use
> termination to identify a 3-part?
>
> Mu Lingjiang
>
> >From: "Rosen, Brian" = <Brian.Rosen@marconi.com>
> >To: "'mu lj'" = <dtxlymlj@hotmail.com>, megaco@fore.com
> >Subject: RE: how to identify a conference = resource
> >Date: Wed, 27 Jun 2001 08:29:46 = -0400
> >
> >There are several models people have = proposed.
> >One is that each conference is a context, = and ephemerals
> representing the
> >network flows
> >are the "ports".  That is = the easiest one to implement.  You
> could also
> have
> >physical
> >ports if your hardware could do = that.
> >
> >Another model is that each "port" = is represented as a
> physical terminal,
> and
> >you have
> >a collection of two termination contexts.&nb= sp; In this model, there is a
> >property on the
> >physical ports that has a  = "conference id".  This model has
> the advantage
> >that the
> >MGC can easily track the resources in the = Media Server.
> >
> >I haven't seen a concrete package proposal = yet.  Either
> model will work
> >fine.
> >
> >Brian
> >
> > > -----Original Message-----
> > > From: mu lj [mailto:dtxlymlj@hotmail.com]
> > > Sent: Tuesday, June 26, 2001 11:42 = PM
> > > To: megaco@fore.com
> > > Subject: how to identify a conference = resource
> > >
> > >
> > > hi all:
> > >    I have a question = about conference resource. Media
> Server has many
> > > conference resource and hasn't trunk = terminations or analog line
> > > terminations. how to use termination = to identify a conference
> > > in Media
> > > Server? how does MGC distinguish = different conferences
> using megaco
> > > protocol in Media Server?
> > > = ______________________________________________________________
> > > ___________
> > > Get Your Private, Free E-mail from = MSN Hotmail at
> > > http://www.hotmail.com.
> > >
>
> = ______________________________________________________________
> ___________
> Get Your Private, Free E-mail from MSN Hotmail = at
> http://www.hotmail.com.
>

------_=_NextPart_001_01C0FFDF.EFA10130-- From owner-megaco@fore.com Thu Jun 28 12:37:08 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12485 for ; Thu, 28 Jun 2001 12:37:07 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA06914; Thu, 28 Jun 2001 12:24:02 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id MAA12610 for megaco-list; Thu, 28 Jun 2001 12:21:37 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA12606 for ; Thu, 28 Jun 2001 12:21:36 -0400 (EDT) From: rcxvhmn3un@yahoo.com Received: from scserver.lnpt.co.th (lnpt.co.th [203.148.252.90] (may be forged)) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA06619 for ; Thu, 28 Jun 2001 12:21:28 -0400 (EDT) Received: from n51299r72 (ip213.lawest.quik.com [216.176.1.213]) by scserver.lnpt.co.th with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3) id NBCN3YBV; Mon, 18 Jun 2001 01:43:50 +0700 DATE: 17 Jun 02 10:08:50 AM Message-ID: Content-Type: text/html SUBJECT: Wave of the Future Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk We will put your product or service instantly into the hands of millions of prospects! =============================================================== "Many business people are finding out that they can now advertise in ways that they never could have afforded in the past. The cost of sending mass e-mail is extremely low, and the response rate is high and quick." - USA TODAY =============================================================== Since 1996, Bulk Email Network has provided bulk email marketing to thousands of well-satisfied customers. We offer the most competitive prices in the industry, made possible by our high percentage of repeat business. We have the most advanced direct email technology employed by only a knowledgeable few in the world. We have over 160 million active email addresses, increasing our list at the rate of half a million to one million a month. You will have instant guaranteed results, something no other form of marketing can claim. Our turn around time is a remarkable 24 hours. Our email addresses are sorted by country, state, city and target. Your marketing campaign will speed with pinpoint accuracy to your desired audience! Call us for a free consultation at 323 876 6148 [U.S.A.]. We guarantee the lowest prices or your service is free! Best of ALL, Bulk Email Network can be used as a 100% TAX WRITE OFF for your Business! 1) Let's say you... Sell a $24.95 PRODUCT or SERVICE. 2) Let's say you... Mass Email to 1,000,000 PEOPLE DAILY. 3) Let's say you... Receive JUST 1 ORDER for EVERY 2,500 EMAILS. CALCULATION OF YOUR EARNINGS BASED ON THE ABOVE STATISTICS: [Day 1]: $9,980 [Week 1]: $69,860 [Month 1]: $279,440 Now you know why you receive so many email advertisements... Best Regards, Sam Al Bulk Email Network C.E.O Under Bill s.1618 TITLE III passed by the 105th U.S. Congress this letter is not considered "spam" as long as we include: 1) contact information and, 2) the way to be removed from future mailings (see below). To Remove Yourself From This List: Please email to jk72jk72@yahoo.com with the email address that you would like removed and the word REMOVE in the subject heading. From owner-megaco@fore.com Thu Jun 28 14:01:42 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA11284 for ; Thu, 28 Jun 2001 14:01:40 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA14407; Thu, 28 Jun 2001 13:27:25 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id NAA27981 for megaco-list; Thu, 28 Jun 2001 13:25:37 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA27945 for ; Thu, 28 Jun 2001 13:25:33 -0400 (EDT) Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA14117 for ; Thu, 28 Jun 2001 13:25:28 -0400 (EDT) Received: from auemail2.firewall.lucent.com (localhost [127.0.0.1]) by auemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5SHPUY03765 for ; Thu, 28 Jun 2001 13:25:30 -0400 (EDT) Received: from teton.mh.lucent.com (h135-3-130-2.lucent.com [135.3.130.2]) by auemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5SHPRs03738; Thu, 28 Jun 2001 13:25:27 -0400 (EDT) Received: from lucent.com (pctla [135.3.130.39]) by teton.mh.lucent.com (8.8.8+Sun/8.8.8) with ESMTP id NAA04695; Thu, 28 Jun 2001 13:25:05 -0400 (EDT) Message-ID: <3B3B69B4.A5A23254@lucent.com> Date: Thu, 28 Jun 2001 13:30:30 -0400 From: Terry L Anderson Organization: Lucent Technologies X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Sarju Garg CC: "'megaco'" Subject: Re: Query Related to Parameters in Signal Descriptor References: <00a101c0ff05$e9e210c0$240310ac@bhartitelesoft.com> <3B39E456.2AB4A9C8@lucent.com> <003101c0ff92$216d6760$240310ac@bhartitelesoft.com> Content-Type: multipart/mixed; boundary="------------4278224231283993699B47D4" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk This is a multi-part message in MIME format. --------------4278224231283993699B47D4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sarju Garg wrote: > Thanks Terry for your reply. > > How does MGC know in that case that the signal haved played out successfully > or timeout? Most signals that have a natural end (voice file) would not also have a provisioned duration. The time to natural end could be considered effectively the provisioned duration. For such signals the MGC should not send an explicit duration as part of the Signals Descriptor, but if it does then the signal would end when the explicit duration expired (including repeating the message or part of it if necessary to complete the time). With no explicit duration, then the call would "timeout" when it reached the natural end. In either case the reason would be timeout with no distinction. > If the signal fails for other reason apart from that mentioned by MGC then > what should MG do ? Do it need to send completion event in that case also?. If NotifyCompletion is omitted but g/sc is on the event list, then MG notifies ONLY for OtherReason (typically errors). If NotifyCompletion is included then it notifies for the indicated reasons (Termination Method). If OtherReason is not included in the list then the MG would not notify for these. Essentially OtherReason can be considered the default if NotifyCompletion is omitted. OtherReason is the reason whenever the the other three do not apply, but was only intended for abnormal/error terminations. > I think the logic should be as follows: > MGC should specify whether it wants notification for the signal playout for > both successful/unsuccessful cases?. It must only specify the optional > parameter "NotificationCompletionToken" and not the notificationReason as of > now. Now, after the MG plays the signal out, then it sends > NotificationCompletion with reason set to "signal ended on its own".In case > the MG finds some error it sends NotificationCompletion with reason set to > "one of 4 mentioned reasons". TO and signal ended on its own should be two > different cases and not one. Interesting alterative, but not what was chosen for the standard. NotifyCompletion is, of course, not an event. So for ANY notification one must define an event. One is available in generic package, g/sc. If it, or some other package event, is not on the event list, then no notification can occur. Adding g/sc to the event list and specifying NotifyCompletion={TimeOut,IntByEvent,IntBySigDescr,OtherReason} would result in exactly what you want (except for the additional "signal ended on its own" reason. Ending due to TimeOut is certainly not considered an error. It is the natural end for many signals (DTMF digits, Call Waiting Tone, etc.) For many, the signal end is naturally defined by time and for others by coming to the end of a digitized signal file - the distinction is minor. In neither case, does MGC need to specify a duration. Where it DOES, it is choosing to override the natural (provisioned) duration. > Also please let me know the answer of my question related to comment over > the sigParameter. I think the comment should be modified to: > ;one or more sigother with every signalParameterName at most once > ; other sigParameter at most once. Is you point that, notifyCompletion and KeepActiveToken should also be "at most once"? or a different wording for the restriction on sigOther? or both? I cannot think of a reason for notifyCompletion or KeepActiveToken being more than once so I believe I agree with that part. Anyone know of a reason they were NOT make at most once? I believe the sigOther restriction is the same as what you state. Not sure it needs changed. > > > TIA > Sarju > ----- Original Message ----- > From: Terry L Anderson > To: Sarju Garg > Cc: 'megaco' > Sent: Wednesday, June 27, 2001 7:19 PM > Subject: Re: Query Related to Parameters in Signal Descriptor > > > > > > > Sarju Garg wrote: > > > > > Hi all, I have a following query related to "notifyCompletion" > > > Parameter in Signal Descriptor:The Annex B says: signalsDescriptor= > > > SignalsToken LBRKT [ signalParm*(COMMA signalParm)] RBRKT > > > signalParm= signalList / signalRequest > > > > > > signalRequest= signalName [ LBRKT sigParameter *(COMMA sigParameter) > > > RBRKT ] > > > > > > signalList= SignalListToken EQUAL signalListId LBRKT signalListParm > > > *(COMMA signalListParm) RBRKT > > > > > > signalListId= UINT16 > > > > > > ;exactly once signalType, at most once duration and every > > > signal;parameter > > > > > > signalListParm= signalRequest > > > > > > signalName= pkgdName > > > > > > ;at-most-once sigStream, at-most-once sigSignalType, > > > > > > ;at-most-once sigDuration, every signalParameterName at most once > > > > > > sigParameter= sigStream / sigSignalType / sigDuration / sigOther/ > > > notifyCompletion / KeepActiveToken > > > > > > sigStream= StreamToken EQUAL StreamID > > > > > > sigOther= sigParameterName parmValue > > > > > > sigParameterName= NAME > > > > > > sigSignalType= SignalTypeToken EQUAL signalType > > > > > > signalType= (OnOffToken / TimeOutToken / BriefToken) > > > > > > sigDuration= DurationToken EQUAL UINT16 > > > > > > notifyCompletion= NotifyCompletionToken EQUAL > > > (LBRKT notificationReason *(COMMA notificationReason) RBRKT) > > > > > > notificationReason= ( TimeOutToken / InterruptByEventToken/ > > > InterruptByNewSignalsDescrToken/ OtherReasonToken ) > > > > > > My query is related to comment above the sigParameter. Does the > > > comment mean that notifyCompletion and keepActiveToken can come > > > multiple times? > > > > > > Also what does notifyCompletion parameter means? I understand that it > > > allows MGC to request MG to indicate that MGC is interested in signal > > > completion notification. I understand that MGC is not interested in > > > specifying the failure cases. Consider a case that MGC specifies > > > notifyCompletion parameter with TimeOutToken. Suppose the signal is > > > played out successfully. What does MG do in that case? I think > > > notification is only done in failure cases and not for successful > > > case? Please verify. If so, that in the above case, if the signal > > > fails for other reason apart from TimeOut what should MG do now? Do it > > > need to send completion event in that case. Can anyone clarify how to > > > use this parameter? > > > > I believe that there is only one case not covered by the current > > language: the one where a signal ends normally but where it is not > > explicitly timed, e.g., a voice announcement file plays to its end. In > > a recent discussion, we agreed that this should be treated the same as a > > signal that completed due to time, that is, NotifyCompletion{TimeOut} > > and g/sc{Meth=TO}. I have changed the sentence in 7.1.11: > > "The possible cases are that the signal timed out (or otherwise > > ended on its own)..." > > > > and changed the description for "TO" in E.1.2 to: > > "Signal Timed out or otherwise ended on its own" > > > > in the Implementors Guide to make this understanding explicit (of course > > that will not be officially approved until the next IG is approved in > > Feb 2002). > > > > > > > > > > > TIA > > > > > > Sarju > > > > > > > > > > -- > > ------------------------------------------------------------ > > Terry L Anderson mailto:tla@lucent.com > > Tel:908.582.7013 Fax:908.582.6729 > > Lucent Technologies/INS/Voice Over IP Access Networks > > Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 > > http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla > > > > -- ------------------------------------------------------------ Terry L Anderson mailto:tla@lucent.com Tel:908.582.7013 Fax:908.582.6729 Lucent Technologies/INS/Voice Over IP Access Networks Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla --------------4278224231283993699B47D4 Content-Type: text/x-vcard; charset=us-ascii; name="tla.vcf" Content-Description: Card for Terry L Anderson Content-Disposition: attachment; filename="tla.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Anderson;Terry L tel;fax:908.582.6729 tel;work:908.582.7013 x-mozilla-html:TRUE url:http://its.lucent.com/~tla org:Lucent / InterNetworking Systems;VoIP Access Networks version:2.1 email;internet:tla@lucent.com title:DMTS note:http://www.gti.net/tla or http://teton.mh.lucent.com/~tla (Lucent internal) adr;quoted-printable:;;600 Mountain Av=0D=0ARm 2B-121;Murray Hill;NJ;07974;USA x-mozilla-cpt:;21296 fn:Terry L Anderson end:vcard --------------4278224231283993699B47D4-- From owner-megaco@fore.com Thu Jun 28 16:53:19 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA12200 for ; Thu, 28 Jun 2001 16:53:18 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA02747; Thu, 28 Jun 2001 16:21:20 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id QAA08245 for megaco-list; Thu, 28 Jun 2001 16:19:00 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA08238 for ; Thu, 28 Jun 2001 16:18:58 -0400 (EDT) Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA02407 for ; Thu, 28 Jun 2001 16:18:54 -0400 (EDT) Received: from auemail2.firewall.lucent.com (localhost [127.0.0.1]) by auemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5SKItU19934 for ; Thu, 28 Jun 2001 16:18:55 -0400 (EDT) Received: from teton.mh.lucent.com (h135-3-130-2.lucent.com [135.3.130.2]) by auemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5SKIpl19859; Thu, 28 Jun 2001 16:18:51 -0400 (EDT) Received: from lucent.com (pctla [135.3.130.39]) by teton.mh.lucent.com (8.8.8+Sun/8.8.8) with ESMTP id QAA17189; Thu, 28 Jun 2001 16:18:47 -0400 (EDT) Message-ID: <3B3B926B.1EA434BF@lucent.com> Date: Thu, 28 Jun 2001 16:24:12 -0400 From: Terry L Anderson Organization: Lucent Technologies X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Kevin Boyle CC: Sarju Garg , "'megaco'" Subject: Re: Query Related to Parameters in Signal Descriptor References: <6DEE1D8911D5D411953E00508BE3DDF601691DF3@zrtpd0jn.us.nortel.com> Content-Type: multipart/mixed; boundary="------------ADD66E38740562F93C7EF588" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk This is a multi-part message in MIME format. --------------ADD66E38740562F93C7EF588 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Kevin Boyle wrote: > Why is there a substantial difference between "timeout" and "ended on > its own"? Signals of type TO will "timeout"; signals of type BR will > "end on its own"; signals of type OO will not end unless interrupted > by an event or a new signals descriptor. > > In the example given by Terry, the voice announcement should be a BR > signal -- one that has a finite length and does not repeat. Timeout > signals repeat until they reach their timeout duration, for example, > playing dial tone for 16 seconds. I would have also thought voice announcements would nomally use BR, but some seem to think that they should be TO (with the provisioned "duration" being their natural length so they would not repeat unless an explicit duration is given). For example, Annex K specifies that an/apv is default TO. But in either case (BR or TO with default duration) the behavior is same. > Essentially, therefore, "timeout" and "ended on its own" are exactly > functionally equivalent, with one applying to TO signals, and the > other to BR signals. > > That being the case, I see no reason to alter what Terry has proposed. > > Kevin > > -----Original Message----- > From: Sarju Garg [mailto:sarju@bhartitelesoft.com] > Sent: Thursday, June 28, 2001 1:21 AM > To: Terry L Anderson > Cc: 'megaco' > Subject: Re: Query Related to Parameters in Signal Descriptor > > Thanks Terry for your reply. > > How does MGC know in that case that the signal haved played out > successfully > or timeout? > > If the signal fails for other reason apart from that mentioned by MGC > then > what should MG do ? Do it need to send completion event in that case > also?. > > I think the logic should be as follows: > MGC should specify whether it wants notification for the signal > playout for > both successful/unsuccessful cases?. It must only specify the optional > > parameter "NotificationCompletionToken" and not the notificationReason > as of > now. Now, after the MG plays the signal out, then it sends > NotificationCompletion with reason set to "signal ended on its own".In > case > the MG finds some error it sends NotificationCompletion with reason > set to > "one of 4 mentioned reasons". TO and signal ended on its own should be > two > different cases and not one. > > Also please let me know the answer of my question related to comment > over > the sigParameter. I think the comment should be modified to: > ;one or more sigother with every signalParameterName at most once > ; other sigParameter at most once. > > TIA > Sarju > ----- Original Message ----- > From: Terry L Anderson > To: Sarju Garg > Cc: 'megaco' > Sent: Wednesday, June 27, 2001 7:19 PM > Subject: Re: Query Related to Parameters in Signal Descriptor > > > > > > > Sarju Garg wrote: > > > > > Hi all, I have a following query related to "notifyCompletion" > > > Parameter in Signal Descriptor:The Annex B says: > signalsDescriptor= > > > SignalsToken LBRKT [ signalParm*(COMMA signalParm)] RBRKT > > > signalParm= signalList / signalRequest > > > > > > signalRequest= signalName [ LBRKT sigParameter *(COMMA > sigParameter) > > > RBRKT ] > > > > > > signalList= SignalListToken EQUAL signalListId LBRKT > signalListParm > > > *(COMMA signalListParm) RBRKT > > > > > > signalListId= UINT16 > > > > > > ;exactly once signalType, at most once duration and every > > > signal;parameter > > > > > > signalListParm= signalRequest > > > > > > signalName= pkgdName > > > > > > ;at-most-once sigStream, at-most-once sigSignalType, > > > > > > ;at-most-once sigDuration, every signalParameterName at most once > > > > > > sigParameter= sigStream / sigSignalType / sigDuration / sigOther/ > > > notifyCompletion / KeepActiveToken > > > > > > sigStream= StreamToken EQUAL StreamID > > > > > > sigOther= sigParameterName parmValue > > > > > > sigParameterName= NAME > > > > > > sigSignalType= SignalTypeToken EQUAL signalType > > > > > > signalType= (OnOffToken / TimeOutToken / BriefToken) > > > > > > sigDuration= DurationToken EQUAL UINT16 > > > > > > notifyCompletion= NotifyCompletionToken EQUAL > > > (LBRKT notificationReason *(COMMA notificationReason) RBRKT) > > > > > > notificationReason= ( TimeOutToken / InterruptByEventToken/ > > > InterruptByNewSignalsDescrToken/ OtherReasonToken ) > > > > > > My query is related to comment above the sigParameter. Does the > > > comment mean that notifyCompletion and keepActiveToken can come > > > multiple times? > > > > > > Also what does notifyCompletion parameter means? I understand that > it > > > allows MGC to request MG to indicate that MGC is interested in > signal > > > completion notification. I understand that MGC is not interested > in > > > specifying the failure cases. Consider a case that MGC specifies > > > notifyCompletion parameter with TimeOutToken. Suppose the signal > is > > > played out successfully. What does MG do in that case? I think > > > notification is only done in failure cases and not for successful > > > case? Please verify. If so, that in the above case, if the signal > > > fails for other reason apart from TimeOut what should MG do now? > Do it > > > need to send completion event in that case. Can anyone clarify how > to > > > use this parameter? > > > > I believe that there is only one case not covered by the current > > language: the one where a signal ends normally but where it is not > > explicitly timed, e.g., a voice announcement file plays to its end. > In > > a recent discussion, we agreed that this should be treated the same > as a > > signal that completed due to time, that is, > NotifyCompletion{TimeOut} > > and g/sc{Meth=TO}. I have changed the sentence in 7.1.11: > > "The possible cases are that the signal timed out (or otherwise > > ended on its own)..." > > > > and changed the description for "TO" in E.1.2 to: > > "Signal Timed out or otherwise ended on its own" > > > > in the Implementors Guide to make this understanding explicit (of > course > > that will not be officially approved until the next IG is approved > in > > Feb 2002). > > > > > > > > > > > TIA > > > > > > Sarju > > > > > > > > > > -- > > ------------------------------------------------------------ > > Terry L Anderson mailto:tla@lucent.com > > Tel:908.582.7013 Fax:908.582.6729 > > Lucent Technologies/INS/Voice Over IP Access Networks > > Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 > > http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla > > > > -- ------------------------------------------------------------ Terry L Anderson mailto:tla@lucent.com Tel:908.582.7013 Fax:908.582.6729 Lucent Technologies/INS/Voice Over IP Access Networks Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla --------------ADD66E38740562F93C7EF588 Content-Type: text/x-vcard; charset=us-ascii; name="tla.vcf" Content-Description: Card for Terry L Anderson Content-Disposition: attachment; filename="tla.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Anderson;Terry L tel;fax:908.582.6729 tel;work:908.582.7013 x-mozilla-html:TRUE url:http://its.lucent.com/~tla org:Lucent / InterNetworking Systems;VoIP Access Networks version:2.1 email;internet:tla@lucent.com title:DMTS note:http://www.gti.net/tla or http://teton.mh.lucent.com/~tla (Lucent internal) adr;quoted-printable:;;600 Mountain Av=0D=0ARm 2B-121;Murray Hill;NJ;07974;USA x-mozilla-cpt:;21296 fn:Terry L Anderson end:vcard --------------ADD66E38740562F93C7EF588-- From owner-megaco@fore.com Fri Jun 29 02:11:06 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA00671 for ; Fri, 29 Jun 2001 02:11:05 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id CAA28504; Fri, 29 Jun 2001 02:01:15 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id BAA06622 for megaco-list; Fri, 29 Jun 2001 01:58:53 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id BAA06618 for ; Fri, 29 Jun 2001 01:58:51 -0400 (EDT) Received: from hotmail.com (f262.law14.hotmail.com [64.4.20.137]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id BAA28365 for ; Fri, 29 Jun 2001 01:58:47 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 28 Jun 2001 22:58:49 -0700 Received: from 61.132.63.48 by lw14fd.law14.hotmail.msn.com with HTTP; Fri, 29 Jun 2001 05:58:49 GMT X-Originating-IP: [61.132.63.48] From: "mu lj" To: kboyle@nortelnetworks.com, megaco@fore.com Subject: Re: FW: how to identify a conference resource Date: Fri, 29 Jun 2001 13:58:49 +0800 Mime-Version: 1.0 Content-Type: text/plain; charset=gb2312; format=flowed Message-ID: X-OriginalArrivalTime: 29 Jun 2001 05:58:49.0297 (UTC) FILETIME=[91050410:01C10060] Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk ok,I agree "Three-way call is a three-port conference". But how to use termination to identify a three-port conference in Media Server? >From: "Kevin Boyle" >To: megaco@fore.com >Subject: FW: how to identify a conference resource >Date: Thu, 28 Jun 2001 10:38:02 -0400 > >Just a quick clarification, as my main background is in line features: This >scenario is not a three-way call, but is rather call waiting, since the >third party is never talking to the other two. Three-way call is, >essentially, a three-port conference. > >Kevin > >-----Original Message----- >From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] >Sent: Thursday, June 28, 2001 9:11 AM >To: 'mu lj'; megaco@fore.com >Subject: RE: how to identify a conference resource > >I would not use topology to control a 3-way call (two parties talking, one >on >hold, ability to switch to the "on hold" part). I would do that with two >contexts, one of which had two terminations, the other of which had one >(if silence to the held party was desired) or two (if music-on-hold was >provided) terminations, using Move to change parties. The Media >Server could do the same. > >Brian > > > -----Original Message----- > > From: mu lj [mailto:dtxlymlj@hotmail.com] > > Sent: Wednesday, June 27, 2001 10:14 PM > > To: Brian.Rosen@marconi.com; megaco@fore.com > > Subject: RE: how to identify a conference resource > > > > > > hi: > > Thanks your answer. > > In megaco protocol,there is a way describle a 3-part service use > > topology.but when 3-part resources are in Media Server,how to use > > termination to identify a 3-part? > > > > Mu Lingjiang > > > > >From: "Rosen, Brian" > > >To: "'mu lj'" , megaco@fore.com > > >Subject: RE: how to identify a conference resource > > >Date: Wed, 27 Jun 2001 08:29:46 -0400 > > > > > >There are several models people have proposed. > > >One is that each conference is a context, and ephemerals > > representing the > > >network flows > > >are the "ports". That is the easiest one to implement. You > > could also > > have > > >physical > > >ports if your hardware could do that. > > > > > >Another model is that each "port" is represented as a > > physical terminal, > > and > > >you have > > >a collection of two termination contexts. In this model, there is a > > >property on the > > >physical ports that has a "conference id". This model has > > the advantage > > >that the > > >MGC can easily track the resources in the Media Server. > > > > > >I haven't seen a concrete package proposal yet. Either > > model will work > > >fine. > > > > > >Brian > > > > > > > -----Original Message----- > > > > From: mu lj [mailto:dtxlymlj@hotmail.com] > > > > Sent: Tuesday, June 26, 2001 11:42 PM > > > > To: megaco@fore.com > > > > Subject: how to identify a conference resource > > > > > > > > > > > > hi all: > > > > I have a question about conference resource. Media > > Server has many > > > > conference resource and hasn't trunk terminations or analog line > > > > terminations. how to use termination to identify a conference > > > > in Media > > > > Server? how does MGC distinguish different conferences > > using megaco > > > > protocol in Media Server? > > > > ______________________________________________________________ > > > > ___________ > > > > Get Your Private, Free E-mail from MSN Hotmail at > > > > http://www.hotmail.com. > > > > > > > > ______________________________________________________________ > > ___________ > > Get Your Private, Free E-mail from MSN Hotmail at > > http://www.hotmail.com. > > _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. From owner-megaco@fore.com Fri Jun 29 04:20:07 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA02608 for ; Fri, 29 Jun 2001 04:20:07 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id EAA02697; Fri, 29 Jun 2001 04:10:15 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id EAA14637 for megaco-list; Fri, 29 Jun 2001 04:08:58 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id EAA14633 for ; Fri, 29 Jun 2001 04:08:56 -0400 (EDT) Received: from cvis28.marconicomms.com (cvis28.marconicomms.com [195.99.244.60] (may be forged)) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id EAA02562 for ; Fri, 29 Jun 2001 04:08:53 -0400 (EDT) Received: from cvis01.gpt.co.uk (unverified) by cvis28.marconicomms.com (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Fri, 29 Jun 2001 09:08:52 +0100 Received: from marconicomms.com by cvis01.gpt.co.uk with SMTP (8.8.8+Sun/cvms-32) id JAA25515; Fri, 29 Jun 2001 09:08:51 +0100 (BST) Received: by marconicomms.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 80256A7A.002CB4C9 ; Fri, 29 Jun 2001 09:08:18 +0100 X-Lotus-FromDomain: MCMAIN@MCEXT From: "Sean Leahy" To: "Brian Rosen" cc: megaco@fore.com Message-ID: <80256A7A.002CA744.00@marconicomms.com> Date: Fri, 29 Jun 2001 09:07:52 +0100 Subject: Loopback mode of a fixed Termination Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Brian, Can you confirm that if a fixed Termination A with a mode of Loopback, is in an H.248 Context (default star topology) that also contains an ephemeral in send only mode, connected across the network to C then (all being equal at C's end) C should hear the data being sent from A to A ? Thanks, Sean From owner-megaco@fore.com Fri Jun 29 07:30:08 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA14724 for ; Fri, 29 Jun 2001 07:30:07 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id HAA10285; Fri, 29 Jun 2001 07:20:18 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id HAA01152 for megaco-list; Fri, 29 Jun 2001 07:18:05 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id HAA01148 for ; Fri, 29 Jun 2001 07:18:04 -0400 (EDT) Received: from cvis22.marconicomms.com (cvis22.marconicomms.com [195.99.244.54] (may be forged)) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id HAA10083 for ; Fri, 29 Jun 2001 07:17:55 -0400 (EDT) Received: from cvis01.gpt.co.uk (unverified) by cvis22.marconicomms.com (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Fri, 29 Jun 2001 12:17:45 +0100 Received: from marconicomms.com by cvis01.gpt.co.uk with SMTP (8.8.8+Sun/cvms-32) id MAA18953; Fri, 29 Jun 2001 12:17:53 +0100 (BST) Received: by marconicomms.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 80256A7A.003DF579 ; Fri, 29 Jun 2001 12:16:45 +0100 X-Lotus-FromDomain: MCMAIN@MCEXT From: "Sean Leahy" To: "Brian Rosen" cc: megaco@fore.com Message-ID: <80256A7A.003DB010.00@marconicomms.com> Date: Fri, 29 Jun 2001 12:13:56 +0100 Subject: Re: Echo Cancellation Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Brian, After further consideration, I am now clear that the echo we are concerned with is as follows (contrary to last memo'): Given a configuration such as MG A (TDM A <-> ATM) <-> MG B (ATM< -> TDM B): The Echo Cancellation property of the TDMC package at MG A against TDM Termination A should prevent echo of speech from B being sent from TDM A back towards TDM B via the ATM Network. Thus in the context of the TDM-ATM MG, it is echo heading towards the ATM rather than echo heading towards the TDM (although in the context of the complete networked configuration it is heading away from TDM A towards TDM B). This is likely to be a general requirement for the TDMC package at a TDM - ATM Gateway since the source of the echo is within the TDM Domain and the source of the delay (that makes the echo significant) is in the ATM Domain. Echo Cancellation should be performed as close as possible to the source of echo and in between the source of echo and source of delay (i. because the echo cancellation functionality has to store a speech sample for the length of time between receiving the incoming speech and comparing it with the outgoing speech with the added echo and ii. because the echo is significant where delay will follow). Can you accept this requirement reverses our originally agreed position that the Echo Cancellation Property being set in the TDMC package means the MG cancels Echo heading towards the TDM i.e. it should cancel Echo arising from the TDM heading towards the ATM ? Regards, Sean From owner-megaco@fore.com Fri Jun 29 09:46:17 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA14658 for ; Fri, 29 Jun 2001 09:46:16 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA20329; Fri, 29 Jun 2001 09:35:19 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id JAA21513 for megaco-list; Fri, 29 Jun 2001 09:32:56 -0400 (EDT) Received: from notes.marconicommsna.com ([208.43.60.106]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA21493 for ; Fri, 29 Jun 2001 09:31:51 -0400 (EDT) From: Brian.Rosen@marconi.com To: Sean.Leahy@marconi.com Cc: megaco@fore.com X-Priority: 3 (Normal) Importance: Normal Date: Fri, 29 Jun 2001 09:31:39 -0400 Subject: RE: Echo Cancellation Message-ID: X-MIMETrack: Serialize by Router on MHDGWY02/S/EXT/MC1(Release 5.0.6a |January 17, 2001) at 06/29/2001 09:29:34 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk I always get confused by this stuff, so it's always nice to see others having the same confusion. Let's see how much of this I get straight. Echo occurs only when speech sent out is returned delayed. This arises in a couple of ways. The easiest to understand is acoustic echo, as in a speakerphone, where speech coming out the speaker is picked up by the microphone and returned. The speaker is on the other side of the network, and he hears his own speech delayed by the network. To fix this, the speakerphone side compares the sound coming off the microphone from sound sent to the speaker and cancels the speaker source from the microphone feed so that what was sent to the speaker does not appear in the microphone stream returned to the far end. Right? A similar problem occurs with POTS because of the hybrid - a portion of the incoming speech is reflected back to the speaker by the hybrid. If there is very low delay in the network, this is not a problem - you hear yourself talking in the earpiece. However, if the network has substantial delay, then it is objectionable. The way we deal with this problem is echo cancel. In North America, this is uniformly done at the interface between the Class 5 (local) exchange and the Class 4 (trunk) exchange. Let's see, the far end (B) echo cancel compares the (delayed) speech from A to the speech from B, and removes A so that all A hears is B, right? Now most ATM based "local" exchanges can be designed so that they have less than 30 ms end to end delay. You shouldn't need EC in a "local" VoATM system if you control packetization delay. The network itself has hundreds of microseconds of delay, plus speed of light. However, a large network will indeed have speed of light problems, and thus you will need echo cancel. I will note that you ONLY need echo cancel if you have a hybrid -- when you know that it's digital all the way (a sipphone for example), you wouldn't need echo cancel. For now, we will probably always assume EC. Okay, now we have exactly the same situation. B cancels A's speech from getting sent back to A, and A cancels B's speech from getting back to B. Now, when we say "Echo Cancellation Property being set in the TDMC package means the MG cancels Echo heading towards the TDM". You get to interpret this a couple different ways. I looked at it as the echo arises in the TDM network, and is objectionable in the TDM network, so the statement is correct. Someone apparently wants to note that the way it works is to change the stream of bits heading into the ATM Network, and thus is not correct. Okay. It's still in the TDM. The ATM network doesn't cause echo, and has no need of canceling it. Brian -----Original Message----- From: Leahy, Sean Sent: Friday, June 29, 2001 7:14 AM To: Rosen, Brian Cc: megaco@fore.com Subject: Re: Echo Cancellation Brian, After further consideration, I am now clear that the echo we are concerned with is as follows (contrary to last memo'): Given a configuration such as MG A (TDM A <-> ATM) <-> MG B (ATM< -> TDM B): The Echo Cancellation property of the TDMC package at MG A against TDM Termination A should prevent echo of speech from B being sent from TDM A back towards TDM B via the ATM Network. Thus in the context of the TDM-ATM MG, it is echo heading towards the ATM rather than echo heading towards the TDM (although in the context of the complete networked configuration it is heading away from TDM A towards TDM B). This is likely to be a general requirement for the TDMC package at a TDM - ATM Gateway since the source of the echo is within the TDM Domain and the source of the delay (that makes the echo significant) is in the ATM Domain. Echo Cancellation should be performed as close as possible to the source of echo and in between the source of echo and source of delay (i. because the echo cancellation functionality has to store a speech sample for the length of time between receiving the incoming speech and comparing it with the outgoing speech with the added echo and ii. because the echo is significant where delay will follow). Can you accept this requirement reverses our originally agreed position that the Echo Cancellation Property being set in the TDMC package means the MG cancels Echo heading towards the TDM i.e. it should cancel Echo arising from the TDM heading towards the ATM ? Regards, Sean From owner-megaco@fore.com Fri Jun 29 09:52:11 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA18547 for ; Fri, 29 Jun 2001 09:52:11 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA20974; Fri, 29 Jun 2001 09:38:58 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id JAA23387 for megaco-list; Fri, 29 Jun 2001 09:37:45 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA23379 for ; Fri, 29 Jun 2001 09:37:44 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Fri, 29 Jun 2001 09:37:43 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF04465677@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'mu lj'" , kboyle@nortelnetworks.com, megaco@fore.com Subject: RE: FW: how to identify a conference resource Date: Fri, 29 Jun 2001 09:37:42 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="GB2312" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Same answer. Either you have 3 terminations in a context (at a media server, they would be 3 ephemeral terminations), or three 2 termination contexts, with the physical terminations representing ports on the conference bridge, and implementing a package that provided a "conferenceId" property. Brian > -----Original Message----- > From: mu lj [mailto:dtxlymlj@hotmail.com] > Sent: Friday, June 29, 2001 1:59 AM > To: kboyle@nortelnetworks.com; megaco@fore.com > Subject: Re: FW: how to identify a conference resource > > > ok,I agree "Three-way call is a three-port conference". > But how to use termination to identify a three-port > conference in Media > Server? > > > >From: "Kevin Boyle" > >To: megaco@fore.com > >Subject: FW: how to identify a conference resource > >Date: Thu, 28 Jun 2001 10:38:02 -0400 > > > >Just a quick clarification, as my main background is in line > features: > This > >scenario is not a three-way call, but is rather call > waiting, since the > >third party is never talking to the other two. Three-way call is, > >essentially, a three-port conference. > > > >Kevin > > > >-----Original Message----- > >From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > >Sent: Thursday, June 28, 2001 9:11 AM > >To: 'mu lj'; megaco@fore.com > >Subject: RE: how to identify a conference resource > > > >I would not use topology to control a 3-way call (two > parties talking, one > >on > >hold, ability to switch to the "on hold" part). I would do > that with two > >contexts, one of which had two terminations, the other of > which had one > >(if silence to the held party was desired) or two (if > music-on-hold was > >provided) terminations, using Move to change parties. The Media > >Server could do the same. > > > >Brian > > > > > -----Original Message----- > > > From: mu lj [mailto:dtxlymlj@hotmail.com] > > > Sent: Wednesday, June 27, 2001 10:14 PM > > > To: Brian.Rosen@marconi.com; megaco@fore.com > > > Subject: RE: how to identify a conference resource > > > > > > > > > hi: > > > Thanks your answer. > > > In megaco protocol,there is a way describle a 3-part service use > > > topology.but when 3-part resources are in Media Server,how to use > > > termination to identify a 3-part? > > > > > > Mu Lingjiang > > > > > > >From: "Rosen, Brian" > > > >To: "'mu lj'" , megaco@fore.com > > > >Subject: RE: how to identify a conference resource > > > >Date: Wed, 27 Jun 2001 08:29:46 -0400 > > > > > > > >There are several models people have proposed. > > > >One is that each conference is a context, and ephemerals > > > representing the > > > >network flows > > > >are the "ports". That is the easiest one to implement. You > > > could also > > > have > > > >physical > > > >ports if your hardware could do that. > > > > > > > >Another model is that each "port" is represented as a > > > physical terminal, > > > and > > > >you have > > > >a collection of two termination contexts. In this > model, there is a > > > >property on the > > > >physical ports that has a "conference id". This model has > > > the advantage > > > >that the > > > >MGC can easily track the resources in the Media Server. > > > > > > > >I haven't seen a concrete package proposal yet. Either > > > model will work > > > >fine. > > > > > > > >Brian > > > > > > > > > -----Original Message----- > > > > > From: mu lj [mailto:dtxlymlj@hotmail.com] > > > > > Sent: Tuesday, June 26, 2001 11:42 PM > > > > > To: megaco@fore.com > > > > > Subject: how to identify a conference resource > > > > > > > > > > > > > > > hi all: > > > > > I have a question about conference resource. Media > > > Server has many > > > > > conference resource and hasn't trunk terminations or > analog line > > > > > terminations. how to use termination to identify a conference > > > > > in Media > > > > > Server? how does MGC distinguish different conferences > > > using megaco > > > > > protocol in Media Server? > > > > > ______________________________________________________________ > > > > > ___________ > > > > > Get Your Private, Free E-mail from MSN Hotmail at > > > > > http://www.hotmail.com. > > > > > > > > > > > ______________________________________________________________ > > > ___________ > > > Get Your Private, Free E-mail from MSN Hotmail at > > > http://www.hotmail.com. > > > > > ______________________________________________________________ > ___________ > Get Your Private, Free E-mail from MSN Hotmail at > http://www.hotmail.com. > From owner-megaco@fore.com Fri Jun 29 11:03:18 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA03429 for ; Fri, 29 Jun 2001 11:03:17 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA00235; Fri, 29 Jun 2001 10:48:31 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA10882 for megaco-list; Fri, 29 Jun 2001 10:43:40 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA10833; Fri, 29 Jun 2001 10:43:20 -0400 (EDT) From: Stealth@bulkemailsite.com Received: from meltem.uubf.itu.edu.tr (meltem.uubf.itu.edu.tr [160.75.14.1]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with SMTP id KAA29282; Fri, 29 Jun 2001 10:43:13 -0400 (EDT) Received: by meltem.uubf.itu.edu.tr; id AA07778; Sat, 14 Oct 2000 15:06:25 +0300 Message-Id: <10010141206.AA07778@meltem.uubf.itu.edu.tr> To: Subject: 10 Million Fresh Email Addresses, Stealth Mass Mailer & More.. 8983 Date: Fri, 29 Jun 2001 07:45:00 -0700 Mime-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-Msmail-Priority: Normal Reply-To: Stealth@bulkemailsite.com Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Content-Transfer-Encoding: quoted-printable Email advertising WORKS! Email Advertise your product or website to millions for only $99. For $99.00 you will receive the Stealth Bulk Mailing Software, List Manager, Over 10 Million "FRESH" E-Mail Addresses, Targeted Email Address Harvesting Software, and as a FREE BONUS, special Mail Servers to send your mail through! Its only $99 for everything, and you can DOWNLOAD IT ALL, today! And as a special bonus, we will harvest a targeted list for you! FOR MORE INFO: ---> http://webhost4u.mysprintfast.com/mrx/ ALSO: Friendly Hosting and POP3s available. To be PERMANENTLY REMOVED from our mail list, YOU MUST SIMPLY REPLY with "REMOVE" in the --> "SUBJECT" Line! =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 This mail is sent by a member (ID 1129) of removenow.org --- the email watchdog. --- To be excluded from future mailings by this member and thousands of other companies , please exercise this your right at http://www.removenow.org From owner-megaco@fore.com Fri Jun 29 11:12:43 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09440 for ; Fri, 29 Jun 2001 11:12:42 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA02231; Fri, 29 Jun 2001 11:00:59 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id KAA16699 for megaco-list; Fri, 29 Jun 2001 10:59:25 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA16669 for ; Fri, 29 Jun 2001 10:59:18 -0400 (EDT) Received: from cvis21.Marconicomms.com (cvis21.marconicomms.com [195.99.244.53] (may be forged)) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA01863 for ; Fri, 29 Jun 2001 10:59:13 -0400 (EDT) Received: from cvis01.gpt.co.uk (unverified) by cvis21.Marconicomms.com (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Fri, 29 Jun 2001 15:59:00 +0100 Received: from marconicomms.com by cvis01.gpt.co.uk with SMTP (8.8.8+Sun/cvms-32) id PAA11904; Fri, 29 Jun 2001 15:59:12 +0100 (BST) Received: by marconicomms.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 80256A7A.0052436F ; Fri, 29 Jun 2001 15:58:32 +0100 X-Lotus-FromDomain: MCMAIN@MCEXT From: "Sean Leahy" To: "Brian Rosen" cc: megaco@fore.com Message-ID: <80256A7A.00523D26.00@marconicomms.com> Date: Fri, 29 Jun 2001 15:58:23 +0100 Subject: RE: Echo Cancellation Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Brian, I think we are basically in agreement now. You wrote : "B cancels A's speech from getting sent back to A, and A cancels B's speech from getting back to B." Yes, agreed. You wrote: "Echo Cancellation Property being set in the TDMC package means the MG cancels Echo heading towards the TDM. You get to interpret this a couple different ways. I looked at it as the echo arises in the TDM network, and is objectionable in the TDM network, so the statement is correct." O.K. but we were looking at a TDM <-> ATM Media Gateway and thinking in that context we want to clarify that the echo being cancelled is going in the direction towards the ATM (albeit it would later emerge back in the TDM somewhere where it would be objectionable). You wrote: The ATM network doesn't cause echo, and has no need of canceling it. O.K. but the packetisation before getting into the ATM causes delay which is significant in making the echo noticeable later on especially if there may be multiple TDM -ATM-TDM packetisation/de-packetisation on the way to the destination. Thanks, Sean CN=Brian Rosen/OU=MAIN/O=MC1@MSEXCH on 29/06/2001 14:31:39 To: Sean Leahy/MAIN/MC1@MCMAIN cc: megaco@fore.com Subject: RE: Echo Cancellation I always get confused by this stuff, so it's always nice to see others having the same confusion. Let's see how much of this I get straight. Echo occurs only when speech sent out is returned delayed. This arises in a couple of ways. The easiest to understand is acoustic echo, as in a speakerphone, where speech coming out the speaker is picked up by the microphone and returned. The speaker is on the other side of the network, and he hears his own speech delayed by the network. To fix this, the speakerphone side compares the sound coming off the microphone from sound sent to the speaker and cancels the speaker source from the microphone feed so that what was sent to the speaker does not appear in the microphone stream returned to the far end. Right? A similar problem occurs with POTS because of the hybrid - a portion of the incoming speech is reflected back to the speaker by the hybrid. If there is very low delay in the network, this is not a problem - you hear yourself talking in the earpiece. However, if the network has substantial delay, then it is objectionable. The way we deal with this problem is echo cancel. In North America, this is uniformly done at the interface between the Class 5 (local) exchange and the Class 4 (trunk) exchange. Let's see, the far end (B) echo cancel compares the (delayed) speech from A to the speech from B, and removes A so that all A hears is B, right? Now most ATM based "local" exchanges can be designed so that they have less than 30 ms end to end delay. You shouldn't need EC in a "local" VoATM system if you control packetization delay. The network itself has hundreds of microseconds of delay, plus speed of light. However, a large network will indeed have speed of light problems, and thus you will need echo cancel. I will note that you ONLY need echo cancel if you have a hybrid -- when you know that it's digital all the way (a sipphone for example), you wouldn't need echo cancel. For now, we will probably always assume EC. Okay, now we have exactly the same situation. B cancels A's speech from getting sent back to A, and A cancels B's speech from getting back to B. Now, when we say "Echo Cancellation Property being set in the TDMC package means the MG cancels Echo heading towards the TDM". You get to interpret this a couple different ways. I looked at it as the echo arises in the TDM network, and is objectionable in the TDM network, so the statement is correct. Someone apparently wants to note that the way it works is to change the stream of bits heading into the ATM Network, and thus is not correct. Okay. It's still in the TDM. The ATM network doesn't cause echo, and has no need of canceling it. Brian -----Original Message----- From: Leahy, Sean Sent: Friday, June 29, 2001 7:14 AM To: Rosen, Brian Cc: megaco@fore.com Subject: Re: Echo Cancellation Brian, After further consideration, I am now clear that the echo we are concerned with is as follows (contrary to last memo'): Given a configuration such as MG A (TDM A <-> ATM) <-> MG B (ATM< -> TDM B): The Echo Cancellation property of the TDMC package at MG A against TDM Termination A should prevent echo of speech from B being sent from TDM A back towards TDM B via the ATM Network. Thus in the context of the TDM-ATM MG, it is echo heading towards the ATM rather than echo heading towards the TDM (although in the context of the complete networked configuration it is heading away from TDM A towards TDM B). This is likely to be a general requirement for the TDMC package at a TDM - ATM Gateway since the source of the echo is within the TDM Domain and the source of the delay (that makes the echo significant) is in the ATM Domain. Echo Cancellation should be performed as close as possible to the source of echo and in between the source of echo and source of delay (i. because the echo cancellation functionality has to store a speech sample for the length of time between receiving the incoming speech and comparing it with the outgoing speech with the added echo and ii. because the echo is significant where delay will follow). Can you accept this requirement reverses our originally agreed position that the Echo Cancellation Property being set in the TDMC package means the MG cancels Echo heading towards the TDM i.e. it should cancel Echo arising from the TDM heading towards the ATM ? Regards, Sean From owner-megaco@fore.com Fri Jun 29 13:28:38 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20008 for ; Fri, 29 Jun 2001 13:28:38 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA15632; Fri, 29 Jun 2001 13:18:22 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id NAA17698 for megaco-list; Fri, 29 Jun 2001 13:17:03 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA17693 for ; Fri, 29 Jun 2001 13:17:01 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Fri, 29 Jun 2001 13:17:01 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF0446567F@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "Leahy, Sean" Cc: "'megaco@fore.com'" Subject: RE: Loopback mode of a fixed Termination Date: Fri, 29 Jun 2001 13:16:59 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk Hmm, seem to have missed that. It's not entirely clear to me. There are a couple of hints in the text that suggest that indeed it does. The most telling is: If the Mode property of the LocalControl descriptor is RecvOnly, SendRecv, or Loopback, the MG must be prepared to receive media encoded according to any of the alternatives included in its response to the MGC. I would say that yes, loopback implies data is sent towards the Context. Inactive or RecieveOnly would not. Anyone got a different opinion? Brian > -----Original Message----- > From: Leahy, Sean > Sent: Friday, June 29, 2001 12:00 PM > To: Rosen, Brian > Subject: Loopback mode of a fixed Termination > > Brian, > Have you seen this question ? > > Sean > ---------------------- Forwarded by Sean Leahy/MAIN/MC1 on 29/06/2001 > 16:59 --------------------------- > > <<...OLE_Obj...>> > From: Sean Leahy On: 29/06/2001 09:07:52 > > To: Brian Rosen/MAIN/MC1@MSEXCH > cc: megaco@fore.com > > Subject: Loopback mode of a fixed Termination > > Brian, > Can you confirm that if a fixed Termination A with a mode of > Loopback, is in an H.248 Context (default star topology) that also > contains an ephemeral in send only mode, connected across the network to C > then (all being equal at C's end) C should hear the data being sent from A > to A ? > > Thanks, > Sean > > From owner-megaco@fore.com Fri Jun 29 15:37:49 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA23993 for ; Fri, 29 Jun 2001 15:37:46 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA28499; Fri, 29 Jun 2001 15:27:47 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id PAA13811 for megaco-list; Fri, 29 Jun 2001 15:26:19 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA13802 for ; Fri, 29 Jun 2001 15:26:17 -0400 (EDT) Received: from netmail.alcatel.com (netmail.alcatel.com [128.251.168.50]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA28299 for ; Fri, 29 Jun 2001 15:26:12 -0400 (EDT) Received: from auds953.usa.alcatel.com (auds953.usa.alcatel.com [143.209.238.6]) by netmail.alcatel.com (8.9.1/8.9.1) with ESMTP id OAA17046; Fri, 29 Jun 2001 14:26:14 -0500 (CDT) Received: from ssd.usa.alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f5TJQED14143; Fri, 29 Jun 2001 14:26:14 -0500 (CDT) Received: from sun3144.ssd.usa.alcatel.com (sun3144.ssd.usa.alcatel.com [143.209.151.53]) by ssd.usa.alcatel.com (8.11.1/8.11.1) with ESMTP id f5TJQ2F20530; Fri, 29 Jun 2001 14:26:02 -0500 (CDT) Received: from usa.alcatel.com (localhost [127.0.0.1]) by sun3144.ssd.usa.alcatel.com (8.11.1/8.11.1) with ESMTP id f5TJQ2t24829; Fri, 29 Jun 2001 14:26:02 -0500 (CDT) Message-ID: <3B3CD649.93D63E6@usa.alcatel.com> Date: Fri, 29 Jun 2001 14:26:02 -0500 From: Chuong Nguyen X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Narayanan Nadadhur , megaco@fore.com Subject: Re: Looking for information References: <4.2.0.58.20010621121719.01466eb0@64.60.54.225> <3B32B147.448C59AC@wipro.com> Content-Type: multipart/alternative; boundary="------------37C38E38F6F527C0E103106B" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk --------------37C38E38F6F527C0E103106B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit So is Metering pulses defined in some package already? Thanks Chuong Narayanan Nadadhur wrote: > Hi, > R2 DLB is the term mainly used in National markets. In the market > where it is used the > DLB function means support of all the Basic Line Signals specified by > ITU. > Metering pulses and Forced Release signal are not supported as part of > DLB function. > > Hope it answers your queries. > > Regards > Narayanan > > > "Shane V. Hawkins" wrote: > >> I have been asked to support R2 DLB function and can find no >> references >> within ITU, ETSI, etc. >> >> Thinking it is another name for some R2/MFC derivative..... >> >> Has anyone ever heard of R2 DLB? >> >> Thank you in advance for any information provided. >> >> shane- > > -- > ----------------------------------------------------------------------- > There is no pleasure in having nothing to do; > the fun is in having lots to do and not doing it. > > -- Alcatel USA, Inc Internet: Chuong.Nguyen@usa.alcatel.com 1000 Coit Road Plano, Texas 75075 Phone: (972) 519-4613 **** The opinions expressed are not those of Alcatel USA, Inc **** --------------37C38E38F6F527C0E103106B Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit So is Metering pulses defined in some package already?

Thanks
Chuong
 

Narayanan Nadadhur wrote:

Hi,
    R2 DLB is the term mainly used in National markets. In the market where it is used the
DLB function means support of all the Basic Line Signals specified by ITU.
Metering pulses and Forced Release signal are not supported as part of DLB function.

Hope it answers your queries.

Regards
Narayanan
 

"Shane V. Hawkins" wrote:

I have been asked to support R2 DLB function and can find no references
within ITU, ETSI, etc.

Thinking it is another name for some R2/MFC derivative.....

Has anyone ever heard of R2 DLB?

Thank you in advance for any information provided.

shane-

-- 
-----------------------------------------------------------------------
            There is no pleasure in having nothing to do;
            the fun is in having lots to do and not doing it.
 
-- 
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****
  --------------37C38E38F6F527C0E103106B-- From owner-megaco@fore.com Fri Jun 29 17:18:30 2001 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25486 for ; Fri, 29 Jun 2001 17:18:29 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA07499; Fri, 29 Jun 2001 17:08:41 -0400 (EDT) Received: (from majordom@localhost) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) id RAA09128 for megaco-list; Fri, 29 Jun 2001 17:07:28 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA09121 for ; Fri, 29 Jun 2001 17:07:26 -0400 (EDT) Received: from netmail.alcatel.com (netmail.alcatel.com [128.251.168.50]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA07348 for ; Fri, 29 Jun 2001 17:07:22 -0400 (EDT) Received: from auds953.usa.alcatel.com (auds953.usa.alcatel.com [143.209.238.6]) by netmail.alcatel.com (8.9.1/8.9.1) with ESMTP id QAA03608; Fri, 29 Jun 2001 16:07:23 -0500 (CDT) Received: from ssd.usa.alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f5TL7MD03831; Fri, 29 Jun 2001 16:07:22 -0500 (CDT) Received: from sun3144.ssd.usa.alcatel.com (sun3144.ssd.usa.alcatel.com [143.209.151.53]) by ssd.usa.alcatel.com (8.11.1/8.11.1) with ESMTP id f5TL6gF14808; Fri, 29 Jun 2001 16:06:42 -0500 (CDT) Received: from usa.alcatel.com (localhost [127.0.0.1]) by sun3144.ssd.usa.alcatel.com (8.11.1/8.11.1) with ESMTP id f5TL6gt27987; Fri, 29 Jun 2001 16:06:42 -0500 (CDT) Message-ID: <3B3CEDE2.B91C0291@usa.alcatel.com> Date: Fri, 29 Jun 2001 16:06:42 -0500 From: Chuong Nguyen X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Narayanan Nadadhur , megaco@fore.com Subject: Re: Looking for information References: <4.2.0.58.20010621121719.01466eb0@64.60.54.225> <3B32B147.448C59AC@wipro.com> <3B3CD649.93D63E6@usa.alcatel.com> Content-Type: multipart/alternative; boundary="------------89702057162C66C4637D26B4" Sender: owner-megaco@pit.comms.marconi.com Precedence: bulk --------------89702057162C66C4637D26B4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Oh I found it in draft-taylor-megaco-enhalpkgs-00.txt Chuong Nguyen wrote: > So is Metering pulses defined in some package already? > > Thanks > Chuong > > > Narayanan Nadadhur wrote: > >> Hi, >> R2 DLB is the term mainly used in National markets. In the >> market where it is used the >> DLB function means support of all the Basic Line Signals specified >> by ITU. >> Metering pulses and Forced Release signal are not supported as part >> of DLB function. >> >> Hope it answers your queries. >> >> Regards >> Narayanan >> >> >> "Shane V. Hawkins" wrote: >> >> > I have been asked to support R2 DLB function and can find no >> > references >> > within ITU, ETSI, etc. >> > >> > Thinking it is another name for some R2/MFC derivative..... >> > >> > Has anyone ever heard of R2 DLB? >> > >> > Thank you in advance for any information provided. >> > >> > shane- >> >> -- >> ----------------------------------------------------------------------- >> There is no pleasure in having nothing to do; >> the fun is in having lots to do and not doing it. >> >> > > -- > Alcatel USA, Inc Internet: Chuong.Nguyen@usa.alcatel.com > 1000 Coit Road Plano, Texas 75075 Phone: (972) 519-4613 > **** The opinions expressed are not those of Alcatel USA, Inc **** > > -- Alcatel USA, Inc Internet: Chuong.Nguyen@usa.alcatel.com 1000 Coit Road Plano, Texas 75075 Phone: (972) 519-4613 **** The opinions expressed are not those of Alcatel USA, Inc **** --------------89702057162C66C4637D26B4 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Oh  I found it in
draft-taylor-megaco-enhalpkgs-00.txt
 
 

Chuong Nguyen wrote:

So is Metering pulses defined in some package already?

Thanks
Chuong
 

Narayanan Nadadhur wrote:

Hi,
    R2 DLB is the term mainly used in National markets. In the market where it is used the
DLB function means support of all the Basic Line Signals specified by ITU.
Metering pulses and Forced Release signal are not supported as part of DLB function.

Hope it answers your queries.

Regards
Narayanan
 

"Shane V. Hawkins" wrote:

I have been asked to support R2 DLB function and can find no references
within ITU, ETSI, etc.

Thinking it is another name for some R2/MFC derivative.....

Has anyone ever heard of R2 DLB?

Thank you in advance for any information provided.

shane-

-- 
-----------------------------------------------------------------------
            There is no pleasure in having nothing to do;
            the fun is in having lots to do and not doing it.
 
-- 
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****
 
-- 
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****
  --------------89702057162C66C4637D26B4--