From rem-conf Wed Dec 01 03:52:26 1999 From rem-conf-request@es.net Wed Dec 01 03:52:26 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11t8Dt-0000Az-00; Wed, 1 Dec 1999 03:47:01 -0800 Received: from motgate.mot.com [129.188.136.100] by mail1.es.net with esmtp (Exim 1.81 #2) id 11t8Dr-0000Ap-00; Wed, 1 Dec 1999 03:46:59 -0800 Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (MOT-motgate 1.0) with ESMTP id EAA17596; Wed, 1 Dec 1999 04:42:17 -0700 (MST)] Received: [from hpux4.miel.mot.com (hpux4.miel.mot.com [217.1.84.89]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id EAA13545; Wed, 1 Dec 1999 04:42:08 -0700 (MST)] Received: from miel.mot.com (pc84156.miel.mot.com [217.1.84.156]) by hpux4.miel.mot.com (8.9.3/8.9.3) with ESMTP id RAA28569; Wed, 1 Dec 1999 17:15:50 +0530 (IST) Message-ID: <38459CC9.EE4B28BB@miel.mot.com> Date: Wed, 01 Dec 1999 17:10:17 -0500 From: GeeVarghese John Organization: Motorola India Electronics Ltd. X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Tmima Koren , casner@cisco.com, micke@cdt.luth.se, brucet@cisco.com, dwing@cisco.com, pruddy@cisco.com, rem-conf@es.net, pazhynnr@cig.mot.com, gvjohn@miel.mot.com Subject: Re: Extensions to CRTP References: <4.1.19991118024030.01aeaa50@jindo.cisco.com> <38358615.D8679DA0@miel.mot.com> <4.1.19991122104601.038605e0@jindo.cisco.com> <4.1.19991124103940.01ec4b60@jindo.cisco.com> <383DC57E.9D1FAA52@miel.mot.com> Content-Type: multipart/alternative; boundary="------------A3E7B089981A98D17916828B" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --------------A3E7B089981A98D17916828B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Tmima, team and Lars (and all u there in the rem list) At this point one thing came to mind I am just presenting here Could you please commnet on this .. Apart from F_HDR, C_RTP & C_UDP packet if we can have C_UDP with IP id transmitted as it is in the IP/UDP/RTP packet .. we may have the following advantages .. 1) Avoiding negative cache : Compression can be at 3 stage first start compressing a flow with CRTP at this state when this state when the flow is detected as too much inconsistent, compression state can be moved to C_UDP if still inconsistent move to C_UDP with IP id send as it is (Say C_UDPi) packet. For the inconsistent flow C_UDPi state is the last state and can avoid moving to negative cache ..Advantage of this mechanism is 2) We use heuristics to find RTP flow .. Even if the flow identified is not RTP which can be started with C_RTPcomperssion and if the flow is found to be too much inconsistent move to the sucsseeding states. Still we get a compression benifit . 3) It is the experiance that CRTP is more processor intensive .. When there has to be a balance, C_UDPi packet sending need not be that processor intensive and can improve the throughput. Because here the delta encoding is less .. So compressor can decide on whether to send only C_UDPi packet for particular flows or all flows. 4) "Extension to CRTP" draft talks on running CRTP algo over ATM links, In that case .. Is the sequence number space 1-16 sufficient ? C_UDPi packet need not be sequentially aligned .. So we can avoid looking at the sequence number. Compression rate will be as follows C_RTP -> 2 (or 4 ) bytes from 40 bytes C_UDP-> 2 (or 4) from 28 C_UDPi -> 4 or (6) from 28 but there will not encoding. I feel tmima's change to the draft should be to indicate an explicit IP id value .. and if people agree on these points you may append these points . Yes, In my previous mail I suggested as having one bit to indicate deltaT and IP id. Please comment .... Rgds GVJ GeeVarghese John wrote: > Tmima, > > Thanks for the reply and I have added some more comments on the CU+ > packets in this > mail. I read the first mail from "Lars-Erik Jonsson", and your reply > to that, Good > you are changing the CU+ with IP ID but you may not need to set M bit > there, > by settting deltaT bit you can encode both deltaT and IP ID, because > you need both values... > I have added whatever comments I have about CU+, please read that > below > According to me CU+ with IP ID also will not give a robust solution. > Reason stated below. > > I think we should windup our discussion on CU + with this mail unless > someone else is > interested. If you want to reply to me please ..If you want more > clarrification on my point > I will reply back. > > My next mail will address few things about ACCEPT/REJECT > packet use, you & team proposed. Please reply to that mail. > > My comments on CU+ are : > > Point 1.1: > > IP ID can be assigned by an host in three ways > a) sequence number in ascending order with variace 1 > b) random number > c) sequence number with variance n (n >1) > > I am not aware of any other implementation ..(May be possible) > IF the IP id variance is not in the ascending order, > CU+ will have problem. You expect that, host will implement this > while transmitting the RTP packets. I dont know how many (non > compliant) people > will change this for the new proposal came in "extending CRTP". > Or you are agreed for IP ID in CU+, it is a positive move. > > Point # 1.2 > > Infact looking at the sequence number of CUDP packets helps to get > rid of > IP id sync problem which we discussed . (What I meant is if CUDP came > in with a > non expected link seqnumber, decompressor send out a CS packet to > compressor to synchronise the context) > This will take care all issues with the IP id variance (variance in > any manner random, ascending order). > If we extend CRTP with the new extension you proposed, > we may loose this synchronization chance between compressor and > decompressor, > because we are NOT expected to look at CUDP+ (or CU+) link sequence > number > to synchronize anymore as far as IP ID variance is concerned. > Otherwise CU+ packet should always carry IP ID field then we can avoid > > looking at sequnce number but not in the case with CU packet. > > What is your comment about CUDP with extension co-exist? > Should it look for link seq number match further also ? > > Point #2 > > One solution to IP ID prolem you stated as "Twics Algo" > Solution to this problem could be using twice algorithm. > But "twice" algorithm is not mandatory. There are implementations > without preserving UDP checksum. In this case I dont have an answer. > May be we have to force a standard that everyone should implement > UDP checksum while transmitting out. I dont know how many people will > do that. > > Point #3.1 > > In our discussion we have addressed two kinds of packet loss > > 1) RTP packet loss in the network before reaching compessor (Say L1) > 2) Compressed packet loss sent from compressor to decompressor (Say > L2) > > > In a lossy environment (L1), we end up in sending more number of > encoded bytes > with CU+ than what we used to send with CR+. > Because in CU+ we encode deltaT of the next expected RTP packet, with > the current packet. > I can understand your point that source generate with same periodic > time gap for > each packet within a talkburst. But the carrier network is IP datagram > service and > (+ link lossy nature). So should we rely on the possible network > behaviour or should we, on the source behaviour. > > If L2 is greater than L1 then you claimed advantage of CU+ sync > between compressor > and decompressor can be achieved. > > But What is the likely chance for L2 > L1 ? > Only for some specific lossy links. > > Point # 3.2 > > As far as I know CRTP use some heuristic mechanism to identify a RTP > flow. > It is not a definite mechanism. In this case does it make sense to > send the deltaT of the next expected packet. Consider L1 case > mentioned above. > Not only that, assume the time gap between talkburst is (T1) and time > gap between > inter packet arrival of same session is T2. Consider a case of, > If we have identified a non-RTP flow as RTP flow and started > compression > with our heuristics how do we determine when to send CU+. > Will we end up in sending continuous CU+ ? we may .. > There need not be talkburst gap with some what high definite gap > when compare to interpacket gap of the same session... > (See Pt # 4 on CU+ size comparison with CR+) > > > Point #4 > > Size of the CU+ is more than CR+ because of the compressed RTP header > .. > in CR+. In CU+ you send complete RTP header as it is (i.e 12 byts). > In old CRTP, Assume that for some situation we have to encode RTP seq > number and > Timestamp, For ideal case encoded byte size will be 2 byts (1 for seq > number > + 1 for deltaT) or otherwise 4 or max 6 (still less than 12 bytes). > Over a lossy link (L2), which is particular to the link, advantage of > CU+ is missing. > > Continuous sending of CU+ for a talk burst may avoid send CS from > decompressor to > compressor. But What kind of loss is more likey L1 or L2. > > > My personal comment to CU+ is > > May be we can claim some advantage only if > the stated assumptions (about packet loss (L1 < L2), twice algo..etc) > are met .. > That also with the modification of IP ID inside the CU+ packet. > > Thanks & Rgds > > GVJ > > Tmima Koren wrote: > >> At 10:17 PM 11/23/99 -0500, GeeVarghese John wrote: >> >> > >> > >> >> >> > >> >> >> > The decompressor will stay in sync as long as he received at >> >> >> > least one of the CU+ >> >> >> >> >> > I think any of the CU+ loss will lead to CONTEXT_STATE packet >> >> > generation from >> >> > decompressor to compressor because of the link seq number >> >> > mismatch ..Is nt it ? >> >> >> >> The decompressor should be in sync after receiving a CU+. There >> >> is no reason for a CS >> >> Tmima >> > >> > Tmima, >> > >> > Could you please explain, how IP id variance should be treated in >> > this case ? >> > For IP id field first order difference is sent as delta in CUDP >> > with I bit set. >> > In this case, if there is a CU+ packet loss how IP ID delta >> > encoding should be treated .. >> >> >> Usually the IP id will not increment uniformly in packets of an RTP >> stream (the host sends packets other then the RTP streams, silence >> periods). >> This means that if we want to compress a stream, we might have to >> send a new deltaID often, maybe in each packet. This will increase >> the size of the packets. >> To optimize the compression, the host can assign IP id's to the >> packets of each stream in a constant increment. >> This keeps the deltaID constant for each stream. >> >> The advantage of a CU+ packet is that in one packet we restore all >> RTP-related parameters at the decompressor. >> The sequence of: CU followed by a CR+ is very vulnerable: the CU >> zeroes the deltaT, so if the CR+ was lost, the decompressor is out >> of sync. >> The CU+ does not restore the IP id. But if the implementation keeps >> the deltaID constant.. >> >> After a silence period, the sequence number will still increment by >> 1 and the IP id by deltaID: there is no reason to skip RTP sequence >> numbers or IP id's. deltaT is the only difference that is not >> correct for the first packet after a silence period. >> >> To optimize CRTP over lossy links >> 1. Use a constant deltaID >> 2. Check udp checksum >> 3. Use CU+ as necessary >> >> >> >> > and also I am not still convinced with the advantage of CU+ over >> > CR+ after >> > the silence period. Could you please explain your point ..(please >> > ref my previous mail) >> >> >> Let's say that the characteristics of the link is that we may lose >> at most 1 packet in a row >> If we use: >> >> 11 200 CR+ dt=100 >> 12 210 CR+ dt=10 >> 13 220 CR >> >> If 11 is lost, the decompressor does not have the correct RTP >> timestamp for packet 12. >> If 12 is lost, the decompressor has a wrong deltaT. >> In both cases the decompressor is out of sync. >> This is a very weak sequence to use after a silence period. >> >> If instead we use: >> >> 11" 200 CU+ dt=10 >> 12" 210 CU+ dt=10 >> 13" 220 CR >> >> In this case If one of 11" or 12" is lost, the decompressor remains >> in sync. So this is a very strong sequence >> >> Tmima >> >> >> >> > Please reply . >> > >> > Rgds >> > >> > GVJ >> > - --------------A3E7B089981A98D17916828B Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Tmima, team and Lars (and all u there in the rem list)

At this point one thing came to mind I am just presenting here
Could you please commnet on this ..

Apart from F_HDR, C_RTP & C_UDP packet
if we can have C_UDP with IP id transmitted as it is in the IP/UDP/RTP packet ..
we may have the following advantages ..

1) Avoiding negative cache :
Compression can be at 3 stage  first start compressing a flow  with
CRTP at this state  when this state when the flow is detected as too much inconsistent,
compression state can be moved to C_UDP if still inconsistent move to C_UDP with
IP id send as it is (Say C_UDPi) packet.
For the inconsistent flow C_UDPi state is the last state and   can avoid moving
to negative cache ..Advantage of this mechanism is

2) We use heuristics to find RTP flow ..
Even if the flow identified is not RTP which can be started with C_RTPcomperssion and
if the flow is found to be too much inconsistent  move to the sucsseeding states.
Still we get a compression benifit .

3) It is the experiance that CRTP is more processor intensive ..
When there has to be a balance, C_UDPi packet sending need not be that processor intensive
and can improve the throughput. Because here the delta encoding is less ..
So compressor can decide on whether to send only C_UDPi packet for  particular flows
or all flows.

4) "Extension to CRTP" draft talks on running CRTP algo over ATM links, In that case ..
Is the sequence number space 1-16 sufficient ?
C_UDPi packet need not be sequentially aligned .. So we can avoid looking at the sequence number.

Compression rate will be as follows

C_RTP -> 2 (or 4 ) bytes from 40 bytes
C_UDP-> 2 (or 4) from 28
C_UDPi -> 4 or (6) from 28 but there will not encoding.

I feel tmima's change to the draft should be to indicate an explicit IP id value ..
and if people agree on these points you may append these points .
Yes, In my previous mail I suggested as having one bit to indicate deltaT and IP id.

Please comment ....

Rgds
GVJ

GeeVarghese John wrote:

Tmima,

Thanks for the reply and I have added some more comments on the CU+ packets in this
mail. I read the first mail from "Lars-Erik Jonsson", and your reply to that, Good
you are changing the CU+ with IP ID but you may not need to set M bit there,
by settting deltaT bit you can encode both deltaT and IP ID, because you need both values...
I have added whatever comments I have about CU+,  please read that below
According to me CU+ with IP ID also will not give a robust solution.
Reason stated below.

I think we should windup our discussion on CU + with this mail unless someone else is
interested. If you want to reply to me please ..If you want more clarrification on my point
I will reply back.

My next mail will address few things about ACCEPT/REJECT
packet use, you & team proposed. Please reply to that mail.

My comments on CU+ are :

Point 1.1:

IP ID can be assigned by an host in three ways
a) sequence number in ascending order with variace 1
b) random number
c) sequence number with variance n (n >1)

I am not aware of any other implementation ..(May be possible)
IF the IP id variance is not in the ascending order,
CU+ will have problem. You expect that, host will implement this
while transmitting the RTP packets. I dont know how many (non compliant) people
will change this for the new proposal came in "extending CRTP".
Or you are agreed for IP ID in CU+, it is a positive move.

Point # 1.2

Infact looking at the sequence number of CUDP packets helps to  get rid of
IP id sync problem which we discussed .  (What I meant is if CUDP came in with a
non expected link seqnumber, decompressor send out a CS packet to
compressor to synchronise the context)
This will take care all issues with the IP id variance (variance in any manner random, ascending order).
If we extend CRTP with the new extension you proposed,
we may loose this synchronization chance between compressor and decompressor,
because we are NOT expected to look at CUDP+ (or CU+) link sequence number
to synchronize anymore as far as IP ID variance is concerned.
Otherwise CU+ packet should always carry IP ID field then we can avoid
looking at sequnce number but not in the case with CU packet.

What is your comment about CUDP with extension co-exist?
Should it look for link seq number match further also  ?

Point #2

One solution to IP ID prolem you stated as "Twics Algo"
Solution to this problem could be using twice algorithm.
But "twice" algorithm is not mandatory. There are implementations
without preserving UDP checksum. In this case I dont have an answer.
May be we have to force a standard that everyone should implement
UDP checksum while transmitting out. I dont know how many people will do that.

Point #3.1

In our discussion we have addressed two kinds of packet loss

1)  RTP packet loss in the network before reaching compessor (Say L1)
2) Compressed packet loss sent from compressor to decompressor (Say L2)
 

In a lossy environment (L1), we end up in sending more number of encoded bytes
with CU+ than what we used to send with CR+.
Because in CU+ we encode deltaT of the next expected RTP packet, with the current packet.
I can understand your point that source generate with same periodic time gap for
each packet within a talkburst. But the carrier network is IP datagram service and
(+ link lossy nature). So should we rely on the possible network behaviour or should we, on the source behaviour.

If L2 is greater than L1 then you claimed advantage of CU+ sync between compressor
and decompressor can be achieved.

But What is the likely chance for L2 >  L1 ?
Only for some specific lossy links.

Point # 3.2

As far as I know CRTP use some heuristic mechanism to identify a RTP flow.
It is not a definite mechanism. In this case  does it make sense to
send the deltaT of the next expected packet. Consider L1 case mentioned above.
Not only that, assume the time gap between talkburst is (T1) and time gap between
inter packet arrival of same session is T2. Consider a case of,
If we have identified a non-RTP flow as RTP flow and started compression
with our heuristics how do we determine when to send CU+.
Will we end up in sending continuous CU+ ?  we may ..
There need not be talkburst gap with some what high definite gap
when  compare to interpacket gap of the same session...
(See Pt # 4 on CU+ size comparison with CR+)
 

Point #4

Size of the CU+ is more than CR+ because of the compressed RTP header ..
in CR+. In CU+ you send complete RTP header as it is (i.e 12 byts).
In old CRTP, Assume that for some situation we have to encode RTP seq number and
Timestamp, For ideal case encoded byte size will be 2 byts (1 for seq number
+ 1 for deltaT) or otherwise 4 or max 6 (still less than 12 bytes).
Over a lossy link (L2), which is particular to the link, advantage of CU+ is missing.

Continuous sending of CU+ for a talk burst may avoid send CS from decompressor to
compressor. But What kind of loss is more likey L1 or L2.
 

My personal comment to CU+ is

May be we can claim some advantage only if
the stated assumptions (about packet loss (L1 < L2),  twice algo..etc) are met ..
That also with the modification of IP ID inside the CU+  packet.

Thanks & Rgds

GVJ

Tmima Koren wrote:

 At 10:17 PM 11/23/99 -0500, GeeVarghese John wrote:
 
 
The decompressor will stay in sync as long as he received at least one of the CU+
I think any of the CU+ loss will lead to CONTEXT_STATE packet generation from
decompressor to compressor because of the link seq number mismatch ..Is nt it ?
The decompressor should be in sync after receiving a CU+. There is no reason for a CS
Tmima
Tmima,

Could you please explain, how IP id variance should be treated in this case ?
For IP id field  first order difference is sent as delta in CUDP with I bit set.
In this case, if there is a CU+ packet loss how IP ID delta encoding should be treated ..


Usually the IP id will not increment uniformly in packets of an RTP stream (the host sends packets other then the RTP streams, silence periods).
This means that if we want to compress a stream, we might have to send a new deltaID often, maybe in each packet. This will increase the size of the packets.
To optimize the compression, the host can assign IP id's to the packets of each stream in a constant increment.
This keeps the deltaID constant for each stream.

The advantage of a CU+ packet is that in one packet we restore all RTP-related parameters at the decompressor.
The sequence of:  CU followed by a CR+  is very vulnerable: the CU zeroes the deltaT, so if the CR+ was lost, the decompressor is out of sync.
The CU+ does not restore the IP id. But if the implementation keeps the deltaID constant..

After a silence period, the sequence number will still increment by 1 and the IP id by deltaID: there is no reason to skip RTP sequence numbers or IP id's. deltaT is the only difference that is not correct for the first packet after a silence period.

To optimize CRTP over lossy links
1. Use a constant deltaID
2. Check udp checksum
3. Use CU+ as necessary
 
 

and also I am not still convinced with the advantage of CU+ over CR+ after
the  silence period. Could you please explain your point  ..(please ref my previous mail)


Let's say that the characteristics of the link is that we may lose at most 1 packet in a row
If we use:

11      200       CR+    dt=100
12      210       CR+    dt=10
13      220       CR

If 11 is lost, the decompressor does not have the correct RTP timestamp for packet 12.
If 12 is lost, the decompressor has a wrong deltaT.
In both cases the decompressor is out of sync.
This is a very weak sequence to use after a silence period.

If instead we use:

11"    200       CU+    dt=10
12"    210       CU+    dt=10
13"    220       CR

In this case If one of 11" or 12" is lost, the decompressor remains in sync. So this is a very strong sequence

Tmima
 
 

Please reply .

Rgds

GVJ

-

 
  --------------A3E7B089981A98D17916828B-- From rem-conf Wed Dec 01 11:47:45 1999 From rem-conf-request@es.net Wed Dec 01 11:47:43 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11tFWY-0005KW-00; Wed, 1 Dec 1999 11:34:46 -0800 Received: from jindo.cisco.com [171.69.43.22] by mail1.es.net with esmtp (Exim 1.81 #2) id 11tFWW-0005KG-00; Wed, 1 Dec 1999 11:34:44 -0800 Received: from tmima-nt (dhcp-vm22-89-167.cisco.com [171.69.89.167]) by jindo.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with SMTP id LAA06925; Wed, 1 Dec 1999 11:32:54 -0800 (PST) Message-Id: <4.1.19991201103902.01ef61f0@jindo.cisco.com> X-Sender: tmima@jindo.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 01 Dec 1999 11:33:40 -0800 To: GeeVarghese John , Tmima Koren , casner@cisco.com, micke@cdt.luth.se, brucet@cisco.com, dwing@cisco.com, pruddy@cisco.com, rem-conf@es.net, pazhynnr@cig.mot.com, gvjohn@miel.mot.com From: Tmima Koren Subject: CRTP and IP ID In-Reply-To: <38459CC9.EE4B28BB@miel.mot.com> References: <4.1.19991118024030.01aeaa50@jindo.cisco.com> <38358615.D8679DA0@miel.mot.com> <4.1.19991122104601.038605e0@jindo.cisco.com> <4.1.19991124103940.01ec4b60@jindo.cisco.com> <383DC57E.9D1FAA52@miel.mot.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list When the IP ID is changing arbitrarily, we have to change the deltaID very frequently - probably in every packet. In such cases it might be more useful to include the full IP ID in a CR instead of the deltaID. This can be done if we could change the meaning of the 'I' flag in the CR packet to mean either full IP ID or deltaID. Maybe we can add an option to the CRTP negotiation about the usage of the 'I' flag in CR: full IP ID or deltaID Then if a host requires preserving the IP ID and cannot assign them sequentially for the compressed RTP streams, the host will negotiate the 'I' flag in CR packets to mean full IP ID. Or if we want this to be per stream, add a flag in the FH. Are there cases when it's ok for the CRTP compressor to reasign the IP ID? Tmima From rem-conf Thu Dec 02 02:05:14 1999 From rem-conf-request@es.net Thu Dec 02 02:05:13 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11tSyM-00052i-00; Thu, 2 Dec 1999 01:56:22 -0800 Received: from maild.telia.com [194.22.190.3] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 11tSyK-00052Y-00; Thu, 2 Dec 1999 01:56:20 -0800 Received: from gunnar (t4o74p112.telia.com [62.20.225.232]) by maild.telia.com (8.9.3/8.9.3) with SMTP id KAA05854 for ; Thu, 2 Dec 1999 10:56:16 +0100 (CET) From: =?iso-8859-1?Q?Gunnar_Hellstr=F6m?= To: Subject: RE: I-D ACTION:draft-ietf-avt-tones-03.txt,.ps Date: Thu, 2 Dec 1999 10:58:32 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <199911301157.GAA04824@ietf.org> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by maild.telia.com id KAA05854 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list A question on tones. In the draft-ietf-avt-tones-03.txt, a set of modem and fax related tones = are specified. I miss two modem related signals used by calling modems in the same way a= s the faxes use the CNG tone: The V.25 CT, Calling tone. 1300 Hz for 0.5 s with 2 s. intervals ( more precisely defined in V.25). All modems not starting with V.8 CI starts with this tone nowadays (at le= ast in Europe). The V.8 CI. That is a V.21 (1) modulated signal. Therefore it could be tranmitted as V.21 tones, but it might be of interest to have a specific code for it with a parameter for the data contents of the CI. Since their inclusion would complete the modem handshake support in the tones spec, I suggest that they are added. Regards ______________________________________________ Gunnar Hellstr=F6m Omnitor AB Alsn=F6gatan 7 , 4 tr S-116 41 Stockholm Sweden Tel +46 8 556 002 03 Mob: + 46 708 204 288 Txt and video +46 8 556 002 05 Fax +46 8 556 002 06 e-mail: gunnar.hellstrom@omnitor.se web: www.omnitor.se > -----Original Message----- > From: nsyracus@cnri.reston.va.us [mailto:nsyracus@cnri.reston.va.us]On > Behalf Of Internet-Drafts@ietf.org > Sent: Tuesday, November 30, 1999 12:57 PM > To: IETF-Announce: ; > Cc: rem-conf@es.net > Subject: I-D ACTION:draft-ietf-avt-tones-03.txt,.ps > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > This draft is a work item of the Audio/Video Transport Working > Group of the IETF. > > Title : RTP Payload for DTMF Digits, Telephony Tones and > Telephony Signals > Author(s) : H. Schulzrinne, S. Petrack > Filename : draft-ietf-avt-tones-03.txt,.ps > Pages : 28 > Date : 29-Nov-99 > > This memo describes how to carry dual-tone multifrequency (DTMF) > signaling, other tone signals and telephony events in RTP packets. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-avt-tones-03.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-avt-tones-03.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-avt-tones-03.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. > From rem-conf Thu Dec 02 06:15:56 1999 From rem-conf-request@es.net Thu Dec 02 06:15:55 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11tWx0-0007PC-00; Thu, 2 Dec 1999 06:11:14 -0800 Received: from motgate2.mot.com [136.182.1.10] by mail1.es.net with esmtp (Exim 1.81 #2) id 11tWwy-0007P2-00; Thu, 2 Dec 1999 06:11:12 -0800 Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (MOT-motgate2 1.0) with ESMTP id HAA14149; Thu, 2 Dec 1999 07:11:02 -0700 (MST)] Received: [from hpux4.miel.mot.com (hpux4.miel.mot.com [217.1.84.89]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id HAA24510; Thu, 2 Dec 1999 07:10:53 -0700 (MST)] Received: from miel.mot.com (pc84156.miel.mot.com [217.1.84.156]) by hpux4.miel.mot.com (8.9.3/8.9.3) with ESMTP id TAA15815; Thu, 2 Dec 1999 19:44:38 +0530 (IST) Message-ID: <3847112E.AEA8382@miel.mot.com> Date: Thu, 02 Dec 1999 19:39:10 -0500 From: GeeVarghese John Organization: Motorola India Electronics Ltd. X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Tmima Koren CC: casner@cisco.com, micke@cdt.luth.se, brucet@cisco.com, dwing@cisco.com, pruddy@cisco.com, rem-conf@es.net, pazhynnr@cig.mot.com Subject: Re: CRTP and IP ID References: <4.1.19991118024030.01aeaa50@jindo.cisco.com> <38358615.D8679DA0@miel.mot.com> <4.1.19991122104601.038605e0@jindo.cisco.com> <4.1.19991124103940.01ec4b60@jindo.cisco.com> <383DC57E.9D1FAA52@miel.mot.com> <4.1.19991201103902.01ef61f0@jindo.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, Tmima Koren wrote: > When the IP ID is changing arbitrarily, we have to change the deltaID very frequently - probably in every packet. > In such cases it might be more useful to include the full IP ID in a CR instead of the deltaID. Exactly, you are correct .. This is the thing I was mentioning by saying three stages of compression. At the first stage we can start compressing a flow at CRTP then if we found the flow is inconsistent then move the state to CUDP and send only CUDP packet then CUDPid packet. Inconsistency can be interms of anything .. One thing could be like what you said about IP id variance rate or other delta encoding rate or CONTEX_STATE packet received etc .. > > This can be done if we could change the meaning of the 'I' flag in the CR packet to mean either full IP ID or deltaID. > Maybe we can add an option to the CRTP negotiation about the usage of the 'I' flag in CR: full IP ID or deltaID > Then if a host requires preserving the IP ID and cannot assign them sequentially for the compressed RTP streams, the host will negotiate the 'I' flag in CR packets to mean full IP ID. > Or if we want this to be per stream, add a flag in the FH. It looks Very good. I am in favour of negotation at CRTP level not only for this point I have something more on seq number extension also. May be later we will discuss this. But Adding the information bit in the FH packet how do we ensure the reliable delivery of the FH packet ..If Accept and Reject packet is the soln in your mind That could be one possibility but Accept and Reject packet will have many other dsadvantes. Instead of that, why cant we have a protocol negotiation packet which needs to be sent only one time when the stack is initialised. For this packet we can have a design where negotation parameters can be exteneded so that future requirement also will be taken care. > > > Are there cases when it's ok for the CRTP compressor to reasign the IP ID? Do you mean that CRTP will reassign a new IP id to the decompressed IP packet ..? Rgds GeevJohn -- ------------------------------------------------------------------------------- [ ] Motorola Confidential Proprietory [ ] Motorola Internal Use Only [x] Not an MCP or MIU ------------------------------------------------------------------------------- Geevarghese John, DataCom Group, Motorola India Electronics Ltd, "The Senate", No-33 A, Ulsoor Road, Bangalore - 42. Phone : 91-80-5598615 Xnt-4005 E-mail : gvjohn@miel.mot.com ------------------------------------------------------------------------------- ------------------------------------------------------------------------------- From rem-conf Thu Dec 02 16:04:00 1999 From rem-conf-request@es.net Thu Dec 02 16:03:59 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11tg55-00058r-00; Thu, 2 Dec 1999 15:56:11 -0800 Received: from public.xf.hb.cn (public.) [202.103.7.46] by mail1.es.net with smtp (Exim 1.81 #2) id 11tg53-00057n-00; Thu, 2 Dec 1999 15:56:09 -0800 Received: from mail.tor.mailerwhjke235.com by public. (SMI-8.6/SMI-SVR4) id HAA05591; Fri, 3 Dec 1999 07:50:59 +0800 From: To: Date: Sat, 4 Dec 1999 11:02:22 Message-Id: <219.612874.545092@mail.tor.mailerwhjke235.com> Subject: have your own web space for only 11.95 per month Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list BECOME A VIRTUAL MERCHANT! 100% ON LINE "REAL TIME" SEAMLESS E-COMMERCE CREDIT CARD SYSTEM WILL PUMP UP YOUR WEBSTORE BUSINESS VOLUME! INTERNET AND DIRECT MARKETING PROS KNOW THAT CUSTOMER'S ON THE WEB WILL SPEND 2.5 TIMES AS MUCH BEING ABLE TO PAY WITH A CREDIT CARD AS OPPOSED TO CASH! A SECURE "SSL" SERVER BASED PLATFORM THAT WILL LEND IMMEDIATE CREDIBILITY TO YOUR ON-LINE STORE! FAST APPROVALS AND SET UP! LOWEST ON LINE PROCESSING RATES AVAILABLE! NO APPLICATION OR SET UP FEES!! TRUE MERCHANT SERVICES / SYSTEM OWNERSHIP PROGRAM! COME ENJOY THE TOTAL CARDSERVICE EXPERIENCE TODAY!!!!! For further information please call 877 205 9117. _________________________________________________________________ ________________________________ Have a product or service to market on the internet? Try our bulk email service today! Check out our introductory offer today ! 150,000 emails sent advertising your product or service for only $295.00! Want to bulk email yourself? Call 877 205 9117 TODAY and check out our latest bulk email programs today! Want bulk email freindly web hosting? Give us a call today! Professional Express System Holdings Inc Montreal Quebec 877 205 9117 From rem-conf Fri Dec 03 05:54:22 1999 From rem-conf-request@es.net Fri Dec 03 05:54:21 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11tt28-0003rb-00; Fri, 3 Dec 1999 05:46:00 -0800 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 11tt27-0003rR-00; Fri, 3 Dec 1999 05:45:59 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25861; Fri, 3 Dec 1999 08:45:56 -0500 (EST) Message-Id: <199912031345.IAA25861@ietf.org> To: IETF-Announce: ; Cc: rem-conf@es.net From: The IESG SUBJECT: Last Call: Real-Time Transport Protocol Management Information Base to Proposed Standard Reply-to: iesg@ietf.org Date: Fri, 03 Dec 1999 08:45:56 -0500 Sender: scoya@cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list The IESG has received a request from the Audio/Video Transport Working Group to consider Real-Time Transport Protocol Management Information Base as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by December 16, 1999. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-mib-07.txt From rem-conf Fri Dec 03 08:23:21 1999 From rem-conf-request@es.net Fri Dec 03 08:23:21 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11tvRR-0005lh-00; Fri, 3 Dec 1999 08:20:17 -0800 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 11tvRQ-0005lV-00; Fri, 3 Dec 1999 08:20:16 -0800 Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 3 Dec 1999 16:19:51 +0000 To: rem-conf@es.net Subject: RTP interoperability statements for draft standard Date: Fri, 03 Dec 1999 16:19:49 +0000 Message-ID: <2929.944237989@cs.ucl.ac.uk> From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list To the AVT working group, As noted in the AVT meeting at the Washington DC IETF, it is necessary to collect interoperability reports for RTP implementations before we can progress the RTP specification and audio/video profile to draft standard. Two internet-drafts describe the type of interoperability statement required: draft-ietf-avt-rtp-interop-02.txt draft-ietf-avt-profile-interop-00.txt and a third draft (draft-ietf-avt-rtptest-02.txt) describes possible testing strategies. This message is a plea for vendors with RTP implementations to make available results of their interoperability tests, in order that we can advance the specifications. Results of the tests to date are available from http://www-mice.cs.ucl.ac.uk/multimedia/misc/avt/RTPinterop/ Please send additions to this table to me (if you have a problem with making this information publically available, please contact me privately and we can discuss alternatives). Thanks, Colin From rem-conf Fri Dec 03 14:23:52 1999 From rem-conf-request@es.net Fri Dec 03 14:23:52 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11u0zS-000236-00; Fri, 3 Dec 1999 14:15:46 -0800 Received: from jindo.cisco.com [171.69.43.22] by mail1.es.net with esmtp (Exim 1.81 #2) id 11u0zR-00022k-00; Fri, 3 Dec 1999 14:15:45 -0800 Received: from tmima-nt (dhcp-vm22-89-167.cisco.com [171.69.89.167]) by jindo.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with SMTP id OAA01900; Fri, 3 Dec 1999 14:14:02 -0800 (PST) Message-Id: <4.1.19991202135725.01f5eb00@jindo.cisco.com> Message-Id: <4.1.19991202135725.01f5eb00@jindo.cisco.com> X-Sender: tmima@jindo.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Fri, 03 Dec 1999 14:13:20 -0800 To: GeeVarghese John , Tmima Koren From: Tmima Koren Subject: Re: CRTP and IP ID Cc: casner@cisco.com, micke@cdt.luth.se, brucet@cisco.com, dwing@cisco.com, pruddy@cisco.com, rem-conf@es.net, pazhynnr@cig.mot.com In-Reply-To: <3847112E.AEA8382@miel.mot.com> References: <4.1.19991118024030.01aeaa50@jindo.cisco.com> <38358615.D8679DA0@miel.mot.com> <4.1.19991122104601.038605e0@jindo.cisco.com> <4.1.19991124103940.01ec4b60@jindo.cisco.com> <383DC57E.9D1FAA52@miel.mot.com> <4.1.19991201103902.01ef61f0@jindo.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list At 07:39 PM 12/2/99 -0500, GeeVarghese John wrote: >Hi, > >Tmima Koren wrote: > >> When the IP ID is changing arbitrarily, we have to change the deltaID very >frequently - probably in every packet. >> In such cases it might be more useful to include the full IP ID in a CR >instead of the deltaID. > >Exactly, you are correct .. >This is the thing I was mentioning by saying three stages of compression. >At the first stage we can start compressing a flow at CRTP then if we found >the flow is >inconsistent then move the state to CUDP and send only CUDP packet then >CUDPid packet. >Inconsistency can be interms of anything .. >One thing could be like what you said about IP id variance rate or other >delta encoding rate or CONTEX_STATE packet received etc .. Yes. This is the same idea. The CRid can be used when the RTP parameters are consistent, but the IP ID is not. Mikael Degermark suggested to enhance the COMPRESSED_NON_TCP packet instead of the CUDP The COMPRESSED_NON_TCP packet includes the IP ID, the udp checksum (if nonzero) and also includes one byte of data which currently holds the 4-bit CRTP sequence# (see rfc2507). 2 of the 4 unused bits can be used to flag 'T' and 'I', so the packet may also include the deltaT and deltaID if necessary. Such a packet will restore all parameters at the decompressor, same as CUDPid > >> >> This can be done if we could change the meaning of the 'I' flag in the CR >packet to mean either full IP ID or deltaID. >> Maybe we can add an option to the CRTP negotiation about the usage of the >'I' flag in CR: full IP ID or deltaID >> Then if a host requires preserving the IP ID and cannot assign them >sequentially for the compressed RTP streams, the host will negotiate the 'I' >flag in CR packets to mean full IP ID. >> Or if we want this to be per stream, add a flag in the FH. > >It looks Very good. I am in favour of negotation at CRTP level not only >for this point >I have something more on seq number extension also. May be later we will >discuss this. >But Adding the information bit in the FH packet how do we ensure the reliable >delivery of the FH packet ..If Accept and Reject packet is the soln in your >mind >That could be one possibility but Accept and Reject packet will have many >other dsadvantes. >Instead of that, why cant we have a protocol negotiation packet which needs >to be sent >only one time when the stack is initialised. For this packet we can have a >design where >negotation parameters can be exteneded so that future requirement also will >be taken care. I meant adding options to the IP header compression negotiation as described in rfc2509 >> >> >> Are there cases when it's ok for the CRTP compressor to reasign the IP ID? > >Do you mean that CRTP will reassign a new IP id to the decompressed IP >packet ..? Yes. I suggest a mode where CRTP does not preserve the IP ID. Tmima > > >Rgds >GeevJohn >-- >------------------------------------------------------------------------------- >[ ] Motorola Confidential Proprietory >[ ] Motorola Internal Use Only >[x] Not an MCP or MIU >------------------------------------------------------------------------------- >Geevarghese John, >DataCom Group, >Motorola India Electronics Ltd, >"The Senate", No-33 A, >Ulsoor Road, >Bangalore - 42. >Phone : 91-80-5598615 Xnt-4005 >E-mail : gvjohn@miel.mot.com >------------------------------------------------------------------------------- >------------------------------------------------------------------------------- > > > > > From rem-conf Fri Dec 03 15:28:13 1999 From rem-conf-request@es.net Fri Dec 03 15:28:12 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11u25d-0003M1-00; Fri, 3 Dec 1999 15:26:13 -0800 Received: from deliverator.sgi.com [204.94.214.10] by mail1.es.net with esmtp (Exim 1.81 #2) id 11u25a-0003Lq-00; Fri, 3 Dec 1999 15:26:11 -0800 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id PAA01292 for <@external-mail-relay.sgi.com:rem-conf@es.net>; Fri, 3 Dec 1999 15:21:54 -0800 (PST) mail_from (kordale@relic.engr.sgi.com) Received: from relic.engr.sgi.com (relic.engr.sgi.com [198.29.115.71]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via SMTP id PAA20012 for <@cthulhu.engr.sgi.com:rem-conf@es.net>; Fri, 3 Dec 1999 15:26:07 -0800 (PST) mail_from (kordale@relic.engr.sgi.com) Received: (from kordale@localhost) by relic.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id PAA08675 for rem-conf@es.net; Fri, 3 Dec 1999 15:26:06 -0800 From: "Ram Kordale" Message-Id: <9912031526.ZM8673@relic.engr.sgi.com> Date: Fri, 3 Dec 1999 15:26:06 -0800 In-Reply-To: Colin Perkins "RTP interoperability statements for draft standard" (Dec 3, 4:19pm) References: <2929.944237989@cs.ucl.ac.uk> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: rem-conf@es.net Subject: MPEG-1 over RTP (RFC 2250) conflict? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Could someone please clarify the following "conflict" I see in the spec? In the event of data loss, RFC 2250 has mechanisms to recover at the slice level(basically by discarding RTP packets until you find one with the BeginningOfSlice bit set to 1). However, if you lose a few RTP packets, one is **really forced** to skip until the beginning of the next GOP! This is an incredible amount of loss or I have misunderstood the spec. Could someone please clarify? Details: ------- Consider the following segment of MPEG-1 system stream. ...GOP_H P11 P12 P13 ... P1n GOP_H P21 P22 P23 ... GOP_H refers to GOP Headers. Pij refers to picture j of the ith GOP. For simplicity, assume that the stream and display order are the same. Thus, Pij will have a "Temporal Reference" of j. For simplicity, assume each picture is split into 5 RTP packets. Suppose I receive RTP packets containing all of the first GOP header and P11 and I receive 1 RTP packet containing the first "piece" of P12. Suppose the next RTP packet I received contains the "Temporal Reference" of 3, how do I know which GOP this picture belongs to. In other words, how do I know it belongs to P13 or P23 or in general Pi3. If I cannot know, I will have to insert a broken GOP thus essentially losing data until the next GOP header is received. Thanks for your help. Ram -- Ram Kordale Advanced Media Products From rem-conf Fri Dec 03 23:59:49 1999 From rem-conf-request@es.net Fri Dec 03 23:59:48 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11u9yQ-0007QI-00; Fri, 3 Dec 1999 23:51:18 -0800 Received: from mailer2.tis.co.jp [210.148.44.26] by mail1.es.net with esmtp (Exim 1.81 #2) id 11u9yO-0007Q8-00; Fri, 3 Dec 1999 23:51:17 -0800 Received: from 756476tu (ip70.midland.mi.pub-ip.psi.net [38.11.207.70]) by mailer2.tis.co.jp (8.9.1/3.7Wpre7-99032716) id QAA01429; Sat, 4 Dec 1999 16:35:04 +0900 (JST) Date: Sat, 4 Dec 1999 16:35:04 +0900 (JST) X-Authentication-Warning: mailer2.tis.co.jp: Host ip70.midland.mi.pub-ip.psi.net [38.11.207.70] claimed to be 756476tu To: wude6@daelimchem.co.kr From: wude6@daelimchem.co.kr (simon2) Comments: Authenticated sender is Subject: THE RULES HAVE CHANGED! Message-Id: <199912044415OAA33033@293k2make82h.tis.co.jp> X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list ******************************************************* This list is opt-in only. We are linked to many web sites that offer free subscriptions to our opt-in list. You will be removed from this list at any time by following the simple instructions that can be found at the end of this email. THIS IS NOT SPAM! You are on our mailing list because you subscribed or someone you know subscribed for you at one of our associate web sites. ******************************************************* Cyber Investigator "EASY WAY TO FIND OUT ANYTHING ABOUT ANYONE" http://3437342643/10.html Cyber Investigator TAKES YOU BEYOND WHAT SEARCH ENGINES CAN DO! Cyber Investigator is an amazing new tool that allows you to find EVERYTHING you ever wanted to know about your EMPLOYEES, FRIENDS, RELATIVES, SPOUSE, NEIGHBORS, even your BOSS! You can check out ANYONE, ANYTIME, ANYWHERE, right on the internet... Here's the best part: With our SECURE ORDER SYSTEM you can have this amazing tool in your hands right away and you can be doing your own on-line investigations IMMEDIATELY. To find out more about what Cyber Investigator can do for YOU! CLICK HERE: http://3437342643/10.html Thanks, P.J. Software Company Security Software Developers Since 1995 P.J. Software Company respects others right to privacy. To help us insure quality control, you may inform P.J. Software Company management directly at micro82@angelfire.com if you have any concerns regarding the delivery of this message. This message has been delivered by a third party marketing agency in compliance with federal guidelines. You may rcmove your name from our opt-in list by sending an e-mail to the address below with the word rcmove in the subj. 23834U3-3I38D-K3 S From rem-conf Sun Dec 05 06:51:16 1999 From rem-conf-request@es.net Sun Dec 05 06:51:15 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11ucng-0003rI-00; Sun, 5 Dec 1999 06:38:08 -0800 Received: from ecis.eiger.com.ph [208.169.146.3] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 11ucnc-0003qZ-00; Sun, 5 Dec 1999 06:38:05 -0800 Received: from 216.153.6.72 (host72.tnproweb.com [216.153.6.72] (may be forged)) by ecis.eiger.com.ph (8.9.0/8.9.0) with SMTP id DAA17304; Mon, 6 Dec 1999 03:36:22 +0800 From: mlnw4@aol.com Message-Id: <199912051936.DAA17304@ecis.eiger.com.ph> To: mlln2@aol.com Subject: BLAST Your AD to 1 Million Eager Prospects $$$ Date: Sun, 05 Dec 99 09:25:02 Eastern Standard Time Reply-To: mlnw4@aol.com X-Priority: 3 X-MSMailPriority: Normal Importance: Normal MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_018C_01BD9940.715D52A0" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_018C_01BD9940.715D52A0 Content-Type: text/html; Make BIG PROFITS NOW!!!!!

NOW YOUR ONLY REAL SOLUTION TO E-MAIL MARKETING...
BULK EMAIL YOUR AD OUT TO 1 MILLION EMAIL PROSPECTS!

Reach up to 1,000,000+ of potential customers at one time....anytime
you like and We SEND IT OUT FOR YOU!

NEW! You Can Now Choose Fresh businesses by SIC code! ex: Physcians,
Travel Agencies, Consultants, Real Estate, Financial Brokers,
Or Fresh Targeted MLM, Business Opportunity Seekers Email Addresses!

100,000 - $349
200,000 - $649
500,000 - $1,200
1,000,000 - $1,900

CALL TOLL FREE 1-888-821-1951
(Serious inquires only.)

PLUS 50% OFF Sale this week only.
100,000 Hot MLM/Biz- OPP FAX Numbers Only $300.

Thank You.

GSM
1-888-821-1951

 From rem-conf Sun Dec 05 09:24:51 1999 From rem-conf-request@es.net Sun Dec 05 09:24:50 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11ufN3-0005T3-00; Sun, 5 Dec 1999 09:22:49 -0800 Received: from basil.cdt.luth.se [130.240.64.67] by mail1.es.net with esmtp (Exim 1.81 #2) id 11ufN2-0005Sr-00; Sun, 5 Dec 1999 09:22:48 -0800 Received: from komperdell.cdt.luth.se ([130.240.52.26]) by basil.cdt.luth.se (8.9.3/8.7.3) with SMTP id SAA23171; Sun, 5 Dec 1999 18:22:04 +0100 (MET) Message-Id: <199912051722.SAA23171@basil.cdt.luth.se> X-Sender: micke@mailhost.cdt.luth.se X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Sun, 05 Dec 1999 18:39:14 +0100 To: Tmima Koren , GeeVarghese John , Tmima Koren From: Mikael Degermark Subject: Re: CRTP and IP ID Cc: casner@cisco.com, micke@cdt.luth.se, brucet@cisco.com, dwing@cisco.com, pruddy@cisco.com, rem-conf@es.net, pazhynnr@cig.mot.com In-Reply-To: <4.1.19991202135725.01f5eb00@jindo.cisco.com> References: <3847112E.AEA8382@miel.mot.com> <4.1.19991118024030.01aeaa50@jindo.cisco.com> <38358615.D8679DA0@miel.mot.com> <4.1.19991122104601.038605e0@jindo.cisco.com> <4.1.19991124103940.01ec4b60@jindo.cisco.com> <383DC57E.9D1FAA52@miel.mot.com> <4.1.19991201103902.01ef61f0@jindo.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I feel that I have to inform you people that when we were pushing 2507 and 2508 to Proposed Standard, we originally proposed not to maintain the IP ID. The IESG would not agree to that due to potential problems and we had to back off. Before going too far along the path of not maintaining the IP ID, I would recommend sounding out the IESG to see if they changed their minds. Mikael Degermark At 02:13 PM 99/12/03 -0800, Tmima Koren wrote: >At 07:39 PM 12/2/99 -0500, GeeVarghese John wrote: >>Hi, >> >>Tmima Koren wrote: >> >>> When the IP ID is changing arbitrarily, we have to change the deltaID very >>frequently - probably in every packet. >>> In such cases it might be more useful to include the full IP ID in a CR >>instead of the deltaID. >> >>Exactly, you are correct .. >>This is the thing I was mentioning by saying three stages of compression. >>At the first stage we can start compressing a flow at CRTP then if we found >>the flow is >>inconsistent then move the state to CUDP and send only CUDP packet then >>CUDPid packet. >>Inconsistency can be interms of anything .. >>One thing could be like what you said about IP id variance rate or other >>delta encoding rate or CONTEX_STATE packet received etc .. > >Yes. This is the same idea. >The CRid can be used when the RTP parameters are consistent, but the IP ID is not. > >Mikael Degermark suggested to enhance the COMPRESSED_NON_TCP packet instead of the CUDP >The COMPRESSED_NON_TCP packet includes the IP ID, the udp checksum (if nonzero) and also includes one byte of data which currently holds the 4-bit CRTP sequence# (see rfc2507). 2 of the 4 unused bits can be used to flag 'T' and 'I', so the packet may also include the deltaT and deltaID if necessary. >Such a packet will restore all parameters at the decompressor, same as CUDPid > >> >>> >>> This can be done if we could change the meaning of the 'I' flag in the CR >>packet to mean either full IP ID or deltaID. >>> Maybe we can add an option to the CRTP negotiation about the usage of the >>'I' flag in CR: full IP ID or deltaID >>> Then if a host requires preserving the IP ID and cannot assign them >>sequentially for the compressed RTP streams, the host will negotiate the 'I' >>flag in CR packets to mean full IP ID. >>> Or if we want this to be per stream, add a flag in the FH. >> >>It looks Very good. I am in favour of negotation at CRTP level not only >>for this point >>I have something more on seq number extension also. May be later we will >>discuss this. >>But Adding the information bit in the FH packet how do we ensure the reliable >>delivery of the FH packet ..If Accept and Reject packet is the soln in your >>mind >>That could be one possibility but Accept and Reject packet will have many >>other dsadvantes. >>Instead of that, why cant we have a protocol negotiation packet which needs >>to be sent >>only one time when the stack is initialised. For this packet we can have a >>design where >>negotation parameters can be exteneded so that future requirement also will >>be taken care. > >I meant adding options to the IP header compression negotiation as described in rfc2509 > >>> >>> >>> Are there cases when it's ok for the CRTP compressor to reasign the IP ID? >> >>Do you mean that CRTP will reassign a new IP id to the decompressed IP >>packet ..? > >Yes. I suggest a mode where CRTP does not preserve the IP ID. >Tmima > > >> >> >>Rgds >>GeevJohn >>-- >>-------------------------------------------------------------------------- ----- >>[ ] Motorola Confidential Proprietory >>[ ] Motorola Internal Use Only >>[x] Not an MCP or MIU >>-------------------------------------------------------------------------- ----- >>Geevarghese John, >>DataCom Group, >>Motorola India Electronics Ltd, >>"The Senate", No-33 A, >>Ulsoor Road, >>Bangalore - 42. >>Phone : 91-80-5598615 Xnt-4005 >>E-mail : gvjohn@miel.mot.com >>-------------------------------------------------------------------------- ----- >>-------------------------------------------------------------------------- ----- >> >> >> >> >> > From rem-conf Sun Dec 05 12:21:55 1999 From rem-conf-request@es.net Sun Dec 05 12:21:54 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11ui5I-00074d-00; Sun, 5 Dec 1999 12:16:40 -0800 Received: from cs.columbia.edu [128.59.16.20] by mail1.es.net with esmtp (Exim 1.81 #2) id 11ui5H-00074N-00; Sun, 5 Dec 1999 12:16:39 -0800 Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id PAA25172 for ; Sun, 5 Dec 1999 15:16:38 -0500 (EST) Received: (from hgs@localhost) by bart.cs.columbia.edu (8.9.1/8.9.1) id PAA18357; Sun, 5 Dec 1999 15:16:33 -0500 (EST) Date: Sun, 5 Dec 1999 15:16:33 -0500 (EST) From: Henning Schulzrinne Message-Id: <199912052016.PAA18357@bart.cs.columbia.edu> To: rem-conf@es.net Subject: CFP: JCN Special Issue on QoS in IP Networks List: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list JOURNAL OF COMMUNICATIONS AND NETWORKING (JCN) CALL FOR PAPERS - SPECIAL ISSUE ON QoS IN IP NETWORKS JUNE, 2000 A Special Issue of JCN dedicated to the realization of QoS-sensitive services in IP networks will be published in June, 2000. It will be Guest Edited by Prof. Henning Schulzrinne of Columbia University, Prof. Hideo Miyahara of Osaka University, and Prof. Luigi Fratta of the University of Milan. The topics include but are not limited to: Differentiated Services Integrated Services MPLS Real-time multicast IP network traffic engineering Performance measurement and evaluation Pricing and billing User perception of QOS QOS policy management Adaptive and other new service models Light-weight reservation protocols and aggregation Continuing JCN's tradition of fast turnaround together with full peer reviews, the following schedule has been set: Dec. 31, 1999 Submit manuscript via web page (see below) Mar. 31, 2000 First reviews returned to author, revisions returned within three weeks June, 2000 Special Issue published The guest editors are Prof. Luigi Fratta Prof. Hideo Miyahara Prof. Henning Schulzrinne Papers should be submitted via the procedure described at http://www.cs.columbia.edu/~hgs/edas/JCN Only PostScript and PDF formats are accepted. Further information about JCN is available at http://JCN.snu.ac.kr. JCN is a high-quality quarterly archival journal, published by the Korean Institute of Communications Sciences with the technical cosponsorship of the IEEE Communications Society, covering the fields of Communication Theory and Systems, Wireless Communications, and Networks and Services. JCN began publication in March, 1999. From rem-conf Sun Dec 05 15:41:41 1999 From rem-conf-request@es.net Sun Dec 05 15:41:40 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11ulBM-00012x-00; Sun, 5 Dec 1999 15:35:08 -0800 Received: from cs.columbia.edu [128.59.16.20] by mail1.es.net with esmtp (Exim 1.81 #2) id 11ulBK-00012n-00; Sun, 5 Dec 1999 15:35:07 -0800 Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id SAA09674; Sun, 5 Dec 1999 18:35:04 -0500 (EST) Sender: hgs@cs.columbia.edu Message-ID: <384AF6A3.66C0EE3E@cs.columbia.edu> Date: Sun, 05 Dec 1999 18:34:59 -0500 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Gunnar =?iso-8859-1?Q?Hellstr=F6m?= , rem-conf@es.net Subject: Re: I-D ACTION:draft-ietf-avt-tones-03.txt,.ps References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by cs.columbia.edu id SAA09674 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Gunnar Hellstr=F6m wrote: >=20 > A question on tones. > In the draft-ietf-avt-tones-03.txt, a set of modem and fax related tone= s are > specified. >=20 > I miss two modem related signals used by calling modems in the same way= as > the faxes use the CNG tone: >=20 > The V.25 CT, Calling tone. 1300 Hz for 0.5 s with 2 s. intervals ( more > precisely defined in V.25). > All modems not starting with V.8 CI starts with this tone nowadays (at = least > in Europe). >=20 I tentatively added this, but since it is not quite clear where the spec is in the pipeline right now, it may be too late for this round. Adding additional tones, however, can be done at any time, by normal IANA registration procedures. > The V.8 CI. That is a V.21 (1) modulated signal. Therefore it could be > tranmitted as V.21 tones, but it might be of interest to have a specifi= c > code for it with a parameter for the data contents of the CI. We currently don't really have tone parameters, so this would be somewhat difficult to do. >=20 > Since their inclusion would complete the modem handshake support in the > tones spec, I suggest that they are added. >=20 > Regards > ______________________________________________ > Gunnar Hellstr=F6m > Omnitor AB > Alsn=F6gatan 7 , 4 tr > S-116 41 Stockholm > Sweden >=20 --=20 Henning Schulzrinne http://www.cs.columbia.edu/~hgs From rem-conf Mon Dec 06 03:14:05 1999 From rem-conf-request@es.net Mon Dec 06 03:14:04 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11uvwv-0005Wb-00; Mon, 6 Dec 1999 03:04:57 -0800 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 11uvwu-0005WR-00; Mon, 6 Dec 1999 03:04:56 -0800 Received: from maclab-207.dcs.st-and.ac.uk by bells.cs.ucl.ac.uk with UK SMTP id ; Mon, 6 Dec 1999 11:04:51 +0000 Received: from cperkins-d.cs.ucl.ac.uk (localhost [127.0.0.1]) by cperkins-d.cs.ucl.ac.uk (8.9.3/8.8.7) with ESMTP id LAA01235; Mon, 6 Dec 1999 11:04:19 GMT Message-Id: <199912061104.LAA01235@cperkins-d.cs.ucl.ac.uk> To: Henning Schulzrinne cc: m , rem-conf@es.net PP-Warning: Parse error in original version of preceding line Original-cc: Gunnar Hellström , rem-conf@es.net Subject: Re: I-D ACTION:draft-ietf-avt-tones-03.txt,.ps In-Reply-To: Message from Henning Schulzrinne of "Sun, 05 Dec 1999 18:34:59 EST." <384AF6A3.66C0EE3E@cs.columbia.edu> Date: Mon, 06 Dec 1999 11:04:19 +0000 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> Henning Schulzrinne writes: >Gunnar Hellström wrote: >> >> A question on tones. >> In the draft-ietf-avt-tones-03.txt, a set of modem and fax related tones are >> specified. >> >> I miss two modem related signals used by calling modems in the same way as >> the faxes use the CNG tone: >> >> The V.25 CT, Calling tone. 1300 Hz for 0.5 s with 2 s. intervals ( more >> precisely defined in V.25). >> All modems not starting with V.8 CI starts with this tone nowadays (at least >> in Europe). > >I tentatively added this, but since it is not quite clear where the spec >is in the pipeline right now, it may be too late for this round. Adding >additional tones, however, can be done at any time, by normal IANA >registration procedures. We were taking the latest draft as being a revision to address working group last call comments, and something we could send to the IESG. If this is just a new tone, which has no impact on the rest of the document, it is appropriate to add it now and make one final revision to the document. Any additional tones after this should, in my opinion, be registered with IANA rather than added to this draft. >> The V.8 CI. That is a V.21 (1) modulated signal. Therefore it could be >> tranmitted as V.21 tones, but it might be of interest to have a specific >> code for it with a parameter for the data contents of the CI. > >We currently don't really have tone parameters, so this would be >somewhat difficult to do. Does this imply a need for parameters? Or are the cases which would require them sufficiently unusual that they can always be defined as sequences of the existing tones? I'm hesitent about making this draft more complex, unless there is a definite need. Colin From rem-conf Mon Dec 06 05:37:34 1999 From rem-conf-request@es.net Mon Dec 06 05:37:33 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11uyFT-00073z-00; Mon, 6 Dec 1999 05:32:15 -0800 Received: from mailf.telia.com [194.22.194.25] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 11uyFR-00073o-00; Mon, 6 Dec 1999 05:32:13 -0800 Received: from d1o74.telia.com (d1o74.telia.com [62.20.224.241]) by mailf.telia.com (8.9.3/8.9.3) with ESMTP id OAA18277; Mon, 6 Dec 1999 14:32:10 +0100 (CET) Received: from gunnar (t4o74p80.telia.com [62.20.225.200]) by d1o74.telia.com (8.8.8/8.8.8) with SMTP id OAA01305; Mon, 6 Dec 1999 14:32:00 +0100 (CET) From: =?iso-8859-1?Q?Gunnar_Hellstr=F6m?= To: "Colin Perkins" , "Henning Schulzrinne" Cc: Subject: RE: I-D ACTION:draft-ietf-avt-tones-03.txt,.ps Date: Mon, 6 Dec 1999 14:34:44 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <199912061104.LAA01235@cperkins-d.cs.ucl.ac.uk> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mailf.telia.com id OAA18277 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list OK, 1. For V.25 Calling tone: Here is the definition of Calling Tone from V.25: "The calling tone consists of a series of interrupted bursts of binary 1 signal or 1300 Hz,= ON for a duration of not less than 0.5 s and not more than 0.7 s and OFF for= a duration of not less than 1.5 s and not more than 2.0 s." In practice you can ignore the option of sending it as the "binary 1" signal. All modems I know, transmit Calling Tone as 1300 Hz. I believe the tones draft would gain by adding this definition, but I do = not want to hold up progress by requiring it. 2. V.8 CI. This signal is meaningful only if communicated with its data contents. It starts with a general CI identifier, but that is followed by contents declaring possible modes and modulations. It is V.21 (1) modulated at 300 bits/s. So, it may be true that the solution is to transmit it with the codes for V.21 transmission. Regards Gunnar Hellstr=F6m ______________________________________________ Gunnar Hellstr=F6m Omnitor AB Alsn=F6gatan 7 , 4 tr S-116 41 Stockholm Sweden Tel +46 8 556 002 03 Mob: + 46 708 204 288 Txt and video +46 8 556 002 05 Fax +46 8 556 002 06 e-mail: gunnar.hellstrom@omnitor.se web: www.omnitor.se > -----Original Message----- > From: Colin Perkins [mailto:c.perkins@cs.ucl.ac.uk] > Sent: Monday, December 06, 1999 12:04 PM > To: Henning Schulzrinne > Cc: m; rem-conf@es.net > Subject: Re: I-D ACTION:draft-ietf-avt-tones-03.txt,.ps > > > --> Henning Schulzrinne writes: > >Gunnar Hellstr=F6m wrote: > >> > >> A question on tones. > >> In the draft-ietf-avt-tones-03.txt, a set of modem and fax > related tones are > >> specified. > >> > >> I miss two modem related signals used by calling modems in the > same way as > >> the faxes use the CNG tone: > >> > >> The V.25 CT, Calling tone. 1300 Hz for 0.5 s with 2 s. intervals ( m= ore > >> precisely defined in V.25). > >> All modems not starting with V.8 CI starts with this tone > nowadays (at least > >> in Europe). > > > >I tentatively added this, but since it is not quite clear where the sp= ec > >is in the pipeline right now, it may be too late for this round. Addin= g > >additional tones, however, can be done at any time, by normal IANA > >registration procedures. > > We were taking the latest draft as being a revision to address > working group > last call comments, and something we could send to the IESG. If > this is just > a new tone, which has no impact on the rest of the document, it > is appropriate > to add it now and make one final revision to the document. > > Any additional tones after this should, in my opinion, be > registered with IANA > rather than added to this draft. > > >> The V.8 CI. That is a V.21 (1) modulated signal. Therefore it could = be > >> tranmitted as V.21 tones, but it might be of interest to have > a specific > >> code for it with a parameter for the data contents of the CI. > > > >We currently don't really have tone parameters, so this would be > >somewhat difficult to do. > > Does this imply a need for parameters? Or are the cases which > would require > them sufficiently unusual that they can always be defined as sequences = of > the existing tones? I'm hesitent about making this draft more complex, > unless there is a definite need. > > Colin > > From rem-conf Mon Dec 06 08:20:05 1999 From rem-conf-request@es.net Mon Dec 06 08:20:04 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11v0gY-000136-00; Mon, 6 Dec 1999 08:08:22 -0800 Received: from cs.columbia.edu [128.59.16.20] by mail1.es.net with esmtp (Exim 1.81 #2) id 11v0gW-00012w-00; Mon, 6 Dec 1999 08:08:21 -0800 Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id LAA00756; Mon, 6 Dec 1999 11:08:09 -0500 (EST) Sender: hgs@cs.columbia.edu Message-ID: <384BDF64.645436B0@cs.columbia.edu> Date: Mon, 06 Dec 1999 11:08:04 -0500 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Colin Perkins CC: m , rem-conf@es.net Subject: Re: I-D ACTION:draft-ietf-avt-tones-03.txt,.ps References: <199912061104.LAA01235@cperkins-d.cs.ucl.ac.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Colin Perkins wrote: > > > We were taking the latest draft as being a revision to address working group > last call comments, and something we could send to the IESG. If this is just > a new tone, which has no impact on the rest of the document, it is appropriate > to add it now and make one final revision to the document. I'll await the outcome of this discussion and then submit -04 with this change. This is indeed a trivial change. > > Any additional tones after this should, in my opinion, be registered with IANA > rather than added to this draft. Agreed; or added when the draft progresses along the standards track, assuming there's demonstrable need and usage. > > >> The V.8 CI. That is a V.21 (1) modulated signal. Therefore it could be > >> tranmitted as V.21 tones, but it might be of interest to have a specific > >> code for it with a parameter for the data contents of the CI. > > > >We currently don't really have tone parameters, so this would be > >somewhat difficult to do. > > Does this imply a need for parameters? Or are the cases which would require > them sufficiently unusual that they can always be defined as sequences of > the existing tones? I'm hesitent about making this draft more complex, > unless there is a definite need. Adding a parameter would indeed require significant changes and complexity. Also, this type of information is not really a tone anymore, but basically a text or octet string of variable length. I've had recent discussions about creating a third payload format (in addition to the two in the current draft) suitable for caller-id. I suspect that the V.8 CI fits there. My intent is to make this a separate document, although many of the reliability and timing discussions from the current draft will apply there, too. One of the items to be discussed is whether caller-id is to be sent all at once or in the "incremental" fashion we've used for DTMF. Caller-id consists of a relatively long preamble, which consists of invalid characters, for example, followed by roughly 30 to 40 information-bearing octets. A summary of caller id can be found at http://www-s.ti.com/sc/psheets/spra462/spra462.pdf > > Colin -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From rem-conf Mon Dec 06 13:12:19 1999 From rem-conf-request@es.net Mon Dec 06 13:12:19 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11v5LC-000417-00; Mon, 6 Dec 1999 13:06:38 -0800 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 11v5LB-00040x-00; Mon, 6 Dec 1999 13:06:37 -0800 Received: from cperkins-d.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 6 Dec 1999 21:06:28 +0000 Received: from cperkins-d.cs.ucl.ac.uk (localhost [127.0.0.1]) by cperkins-d.cs.ucl.ac.uk (8.9.3/8.8.7) with ESMTP id RAA01022; Mon, 6 Dec 1999 17:32:18 GMT Message-Id: <199912061732.RAA01022@cperkins-d.cs.ucl.ac.uk> To: Henning Schulzrinne cc: m , rem-conf@es.net Subject: Re: I-D ACTION:draft-ietf-avt-tones-03.txt,.ps In-Reply-To: Message from Henning Schulzrinne of "Mon, 06 Dec 1999 11:08:04 EST." <384BDF64.645436B0@cs.columbia.edu> Date: Mon, 06 Dec 1999 17:32:18 +0000 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> Henning Schulzrinne writes: >Colin Perkins wrote: >> We were taking the latest draft as being a revision to address working group >> last call comments, and something we could send to the IESG. If this is just >> a new tone, which has no impact on the rest of the document, it is appropriate >> to add it now and make one final revision to the document. > >I'll await the outcome of this discussion and then submit -04 with this >change. This is indeed a trivial change. Okay. >> Any additional tones after this should, in my opinion, be registered with IANA >> rather than added to this draft. > >Agreed; or added when the draft progresses along the standards track, >assuming there's demonstrable need and usage. > >> >> >> The V.8 CI. That is a V.21 (1) modulated signal. Therefore it could be >> >> tranmitted as V.21 tones, but it might be of interest to have a specific >> >> code for it with a parameter for the data contents of the CI. >> > >> >We currently don't really have tone parameters, so this would be >> >somewhat difficult to do. >> >> Does this imply a need for parameters? Or are the cases which would require >> them sufficiently unusual that they can always be defined as sequences of >> the existing tones? I'm hesitent about making this draft more complex, >> unless there is a definite need. > >Adding a parameter would indeed require significant changes and >complexity. Also, this type of information is not really a tone anymore, >but basically a text or octet string of variable length. > >I've had recent discussions about creating a third payload format (in >addition to the two in the current draft) suitable for caller-id. I >suspect that the V.8 CI fits there. My intent is to make this a separate >document, although many of the reliability and timing discussions from >the current draft will apply there, too. One of the items to be >discussed is whether caller-id is to be sent all at once or in the >"incremental" fashion we've used for DTMF. Caller-id consists of a >relatively long preamble, which consists of invalid characters, for >example, followed by roughly 30 to 40 information-bearing octets. This seems to be a good approach, and one that won't hold up the current tones payload format unnecessarily. Colin From rem-conf Mon Dec 06 15:28:43 1999 From rem-conf-request@es.net Mon Dec 06 15:28:42 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11v7WS-0005r0-00; Mon, 6 Dec 1999 15:26:24 -0800 Received: from mail.pi.se [195.7.64.8] by mail1.es.net with esmtp (Exim 1.81 #2) id 11v7WR-0005qq-00; Mon, 6 Dec 1999 15:26:23 -0800 Received: from pigpen (ap01-067.mp.pi.se [195.7.86.67]) by mail.pi.se (8.8.8/8.8.8) with SMTP id AAA10296; Tue, 7 Dec 1999 00:26:16 +0100 (MET) From: "Gunnar Hellstrom" To: "Colin Perkins" , "Henning Schulzrinne" Cc: Subject: RE: I-D ACTION:draft-ietf-avt-tones-03.txt,.ps Date: Tue, 7 Dec 1999 00:26:36 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <199912061732.RAA01022@cperkins-d.cs.ucl.ac.uk> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mail.pi.se id AAA10296 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Caller ID is sent in PSTN before or between the Rings. Some networks use DTMF, other use V.22, I think. Usually consists of the caller=B4s telepho= ne number. V.8 CI is V.21(1) modulated. Can be as little as two bytes. Starts with a= CI identifier. Still, your mechanism for V.21 transmission could carry it. Regards Gunnar -----Original Message----- From: Colin Perkins [mailto:c.perkins@cs.ucl.ac.uk] Sent: Monday, December 06, 1999 6:32 PM To: Henning Schulzrinne Cc: m; rem-conf@es.net Subject: Re: I-D ACTION:draft-ietf-avt-tones-03.txt,.ps --> Henning Schulzrinne writes: >Colin Perkins wrote: >> We were taking the latest draft as being a revision to address working group >> last call comments, and something we could send to the IESG. If this i= s just >> a new tone, which has no impact on the rest of the document, it is appropriate >> to add it now and make one final revision to the document. > >I'll await the outcome of this discussion and then submit -04 with this >change. This is indeed a trivial change. Okay. >> Any additional tones after this should, in my opinion, be registered w= ith IANA >> rather than added to this draft. > >Agreed; or added when the draft progresses along the standards track, >assuming there's demonstrable need and usage. > >> >> >> The V.8 CI. That is a V.21 (1) modulated signal. Therefore it could= be >> >> tranmitted as V.21 tones, but it might be of interest to have a specific >> >> code for it with a parameter for the data contents of the CI. >> > >> >We currently don't really have tone parameters, so this would be >> >somewhat difficult to do. >> >> Does this imply a need for parameters? Or are the cases which would require >> them sufficiently unusual that they can always be defined as sequences= of >> the existing tones? I'm hesitent about making this draft more complex, >> unless there is a definite need. > >Adding a parameter would indeed require significant changes and >complexity. Also, this type of information is not really a tone anymore, >but basically a text or octet string of variable length. > >I've had recent discussions about creating a third payload format (in >addition to the two in the current draft) suitable for caller-id. I >suspect that the V.8 CI fits there. My intent is to make this a separate >document, although many of the reliability and timing discussions from >the current draft will apply there, too. One of the items to be >discussed is whether caller-id is to be sent all at once or in the >"incremental" fashion we've used for DTMF. Caller-id consists of a >relatively long preamble, which consists of invalid characters, for >example, followed by roughly 30 to 40 information-bearing octets. This seems to be a good approach, and one that won't hold up the current tones payload format unnecessarily. Colin From rem-conf Mon Dec 06 19:55:58 1999 From rem-conf-request@es.net Mon Dec 06 19:55:58 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11vBfj-0000Rg-00; Mon, 6 Dec 1999 19:52:15 -0800 Received: from redale.cisco.com [171.71.154.68] by mail1.es.net with esmtp (Exim 1.81 #2) id 11vBfi-0000RM-00; Mon, 6 Dec 1999 19:52:14 -0800 Received: from bfoster-nt (sj-dial-1-57.cisco.com [171.68.179.58]) by redale.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id TAA10699; Mon, 6 Dec 1999 19:50:24 -0800 (PST) Message-Id: <4.2.0.58.19991206192731.01c805e0@redale.cisco.com> X-Sender: bfoster@redale.cisco.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Mon, 06 Dec 1999 19:47:30 -0800 To: Henning Schulzrinne From: Bill Foster Subject: Named signaling events - minor request. Cc: rem-conf@es.net Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list One minor comment/request for "draft-ietf-avt-tones-03.txt". It would be nice to have a separate named signaling event (NSE) for ringing versus ring-back. The place where a NSE for ringback tone comes in useful is in a device control situation using MGCP or Megacop. The particular case is where the Media Gateway Controller (MGC) requests the media gateway (MG) to do ringback from the far end as follows: Call between two residential media gateways MG A and MG B - MG A originates a call to MG B - once the MGC sets up a half duplex connection from MG B it requests ringing and ringback to MGB (in MGCP S: rg, rt@connection) - if during the capabilities exchange earlier when the half duplex connection was set up (SDP passed between endpoints), the endpoints realized that they supported ringback tone using NSEs, they might use the NSE rather than a tone (some advantages in terms of use of bandwidth prior to call, as well as implementation advantages - MIPS required etc.). On the other hand, the same MG may be used in other RTP trunking applications where an MGC may set up the trunk and NSE's used for signaling (e.g. ringing request passed across the RTP stream). If we leave ringing and ringback as the same event that depends on context (like hook status) there are problems in the trunking application. If one end sends a ringing request to the other end - but when it gets there the person just happens to have gone off-hook (because they wanted to originate a call just as a call was coming in) - if the MG is left to interpret the meaning of the ringing NSE event based on hook-status - they will suddenly hear ringback - not quite what was intended. In Summary: Any chance of getting to separate NSE events - one for ringing and another for ringback - they are both useful but only if the are separate events. Bill ----------------------------- Bill Foster Phone: (408) 527-8791 Page: (800) 365-4578 Fax: (781) 998-6492 From rem-conf Tue Dec 07 09:31:39 1999 From rem-conf-request@es.net Tue Dec 07 09:31:38 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11vOEA-0006Yl-00; Tue, 7 Dec 1999 09:16:38 -0800 Received: from motgate.mot.com [129.188.136.100] by mail1.es.net with esmtp (Exim 1.81 #2) id 11vOE8-0006Yb-00; Tue, 7 Dec 1999 09:16:36 -0800 Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (MOT-motgate 1.0) with ESMTP id KAA10791; Tue, 7 Dec 1999 10:13:56 -0700 (MST)] Received: [from hpux4.miel.mot.com (hpux4.miel.mot.com [217.1.84.89]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id KAA15547; Tue, 7 Dec 1999 10:13:47 -0700 (MST)] Received: from miel.mot.com (pc84156.miel.mot.com [217.1.84.156]) by hpux4.miel.mot.com (8.9.3/8.9.3) with ESMTP id WAA17325; Tue, 7 Dec 1999 22:47:32 +0530 (IST) Message-ID: <384DD3A6.3E61E0E3@miel.mot.com> Date: Tue, 07 Dec 1999 22:42:31 -0500 From: GeeVarghese John Organization: Motorola India Electronics Ltd. X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Tmima Koren CC: casner@cisco.com, micke@cdt.luth.se, brucet@cisco.com, dwing@cisco.com, pruddy@cisco.com, rem-conf@es.net, pazhynnr@cig.mot.com Subject: Re: CRTP and IP ID References: <4.1.19991118024030.01aeaa50@jindo.cisco.com> <38358615.D8679DA0@miel.mot.com> <4.1.19991122104601.038605e0@jindo.cisco.com> <4.1.19991124103940.01ec4b60@jindo.cisco.com> <383DC57E.9D1FAA52@miel.mot.com> <4.1.19991201103902.01ef61f0@jindo.cisco.com> <4.1.19991202135725.01f5eb00@jindo.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Tmima Koren wrote: > At 07:39 PM 12/2/99 -0500, GeeVarghese John wrote: > >Hi, > > > >Tmima Koren wrote: > > > >> When the IP ID is changing arbitrarily, we have to change the deltaID very > >frequently - probably in every packet. > >> In such cases it might be more useful to include the full IP ID in a CR > >instead of the deltaID. > > > >Exactly, you are correct .. > >This is the thing I was mentioning by saying three stages of compression. > >At the first stage we can start compressing a flow at CRTP then if we found > >the flow is > >inconsistent then move the state to CUDP and send only CUDP packet then > >CUDPid packet. > >Inconsistency can be interms of anything .. > >One thing could be like what you said about IP id variance rate or other > >delta encoding rate or CONTEX_STATE packet received etc .. > > Yes. This is the same idea. > The CRid can be used when the RTP parameters are consistent, but the IP ID is not. > > Mikael Degermark suggested to enhance the COMPRESSED_NON_TCP packet instead of the CUDP > The COMPRESSED_NON_TCP packet includes the IP ID, the udp checksum (if nonzero) and also includes one byte of data which currently holds the 4-bit CRTP sequence# (see rfc2507). 2 of the 4 unused bits can be used to flag 'T' and 'I', so the packet may also include the deltaT and deltaID if necessary. > Such a packet will restore all parameters at the decompressor, same as CUDPid What I read about COMPRESSED_NON_TCP packet is, it is optional for CRTP and mainly meant for fragmented packet etc ..Are we nt restricting the advantages here .. (CUDP with IP ID can compress more (UDP etc ) fields than NON_TCP packet) But having a mechanis to send IP ID will definitely give some sort of improvement in CUDP. > > > > > >> > >> This can be done if we could change the meaning of the 'I' flag in the CR > >packet to mean either full IP ID or deltaID. > >> Maybe we can add an option to the CRTP negotiation about the usage of the > >'I' flag in CR: full IP ID or deltaID > >> Then if a host requires preserving the IP ID and cannot assign them > >sequentially for the compressed RTP streams, the host will negotiate the 'I' > >flag in CR packets to mean full IP ID. > >> Or if we want this to be per stream, add a flag in the FH. > > > >It looks Very good. I am in favour of negotation at CRTP level not only > >for this point > >I have something more on seq number extension also. May be later we will > >discuss this. > >But Adding the information bit in the FH packet how do we ensure the reliable > >delivery of the FH packet ..If Accept and Reject packet is the soln in your > >mind > >That could be one possibility but Accept and Reject packet will have many > >other dsadvantes. > >Instead of that, why cant we have a protocol negotiation packet which needs > >to be sent > >only one time when the stack is initialised. For this packet we can have a > >design where > >negotation parameters can be exteneded so that future requirement also will > >be taken care. > > I meant adding options to the IP header compression negotiation as described in rfc2509 > > >> > >> > >> Are there cases when it's ok for the CRTP compressor to reasign the IP ID? > > > >Do you mean that CRTP will reassign a new IP id to the decompressed IP > >packet ..? > > Yes. I suggest a mode where CRTP does not preserve the IP ID. > Tmima > > > > > > >Rgds > >GeevJohn > >-- > >------------------------------------------------------------------------------- > >[ ] Motorola Confidential Proprietory > >[ ] Motorola Internal Use Only > >[x] Not an MCP or MIU > >------------------------------------------------------------------------------- > >Geevarghese John, > >DataCom Group, > >Motorola India Electronics Ltd, > >"The Senate", No-33 A, > >Ulsoor Road, > >Bangalore - 42. > >Phone : 91-80-5598615 Xnt-4005 > >E-mail : gvjohn@miel.mot.com > >------------------------------------------------------------------------------- > >------------------------------------------------------------------------------- > > > > > > > > > > -- From rem-conf Tue Dec 07 09:31:40 1999 From rem-conf-request@es.net Tue Dec 07 09:31:40 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11vOFl-0006ZF-00; Tue, 7 Dec 1999 09:18:17 -0800 Received: from motgate2.mot.com [136.182.1.10] by mail1.es.net with esmtp (Exim 1.81 #2) id 11vOFk-0006Z3-00; Tue, 7 Dec 1999 09:18:16 -0800 Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (MOT-motgate2 1.0) with ESMTP id KAA11358; Tue, 7 Dec 1999 10:16:49 -0700 (MST)] Received: [from hpux4.miel.mot.com (hpux4.miel.mot.com [217.1.84.89]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id KAA18551; Tue, 7 Dec 1999 10:16:41 -0700 (MST)] Received: from miel.mot.com (pc84156.miel.mot.com [217.1.84.156]) by hpux4.miel.mot.com (8.9.3/8.9.3) with ESMTP id WAA17499; Tue, 7 Dec 1999 22:50:27 +0530 (IST) Message-ID: <384DD456.4ED6D3EA@miel.mot.com> Date: Tue, 07 Dec 1999 22:45:26 -0500 From: GeeVarghese John Organization: Motorola India Electronics Ltd. X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Tmima Koren CC: casner@cisco.com, micke@cdt.luth.se, brucet@cisco.com, dwing@cisco.com, pruddy@cisco.com, rem-conf@es.net, pazhynnr@cig.mot.com, gvjohn@miel.mot.com Subject: Re: Extensions to CRTP References: <4.1.19991118024030.01aeaa50@jindo.cisco.com> Content-Type: multipart/alternative; boundary="------------15D6398F85975468E05872C5" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --------------15D6398F85975468E05872C5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Tmima, I wanted to ask you some doubts on ACCEPT/REJECT packet in CRTP extension draft.. It is a continuation of the old mail. In you answer below, though you wrote the ACCPET/REJECT packe is optional, I think definition of these packet are bit confusing. First of all I feel no need of a ACCEPT packet Second Why to have a REJECT packet as separate packet to invalidate the context .. Why cant we use CONTEXT_STATE packet for the same .. We can have a bit in CS packet indicating that context need to be invalidated or resynchronised using FH packet. If there is no CS packet it is assumed that flow ACCEPT. Here the issue of interoperability also arise when an implementation interopeate with the old CRTP (2508) implemnetation new implemetation expected ACCEPT or REJECT packet for each FH packet .. If it does not receive either packet what action compressor is expected to take. To make interoperation possible there is a need for some sort of negotiation, here also a protocol level negotiation is expected .. So I feel the approach with ACCEPT/REJECT packet is not optimal. But the solution I suggested does not cause any interoptation issue also. No extra packet overhead, no protocol modification etc ... Could please answer your points on this .. Thanks & Rgds GVJ > > >> Q3) Section III : Acknowledgement to a new compressed stream >> >> Context Invalidation was one point which I had pointed out to >> Steve/tmima long time back .. >> I am having those mails with me .. >> >> But, (i) Do we need ACCEPT and REJECT packet ?? >> Having a NACK mechnism sounds reasonable .. >> I feel there shouldnt be both .. >> But what compressor is supposed to do after sending the first >> FULL_HEADER packet >> when compressor waiting for the ACCEPT or REJECT >> should it queue the packets till the reply/or timeout >> or Should it send the compressed packets assuming the decompressor >> will drop if there are >> REJECT state at the decompressor side. >> >> But (ii) what about the backword compatibility issue because this >> ACCEPT/REJECT mechanism has dependancy and it will not work with >> CRTP-2508 >> >> As per the current proposal we need to send ACCEPT/REJECT packet for >> every >> FULL_HEADER packet ... (iii)Is it not adding extra bandwidth >> consuption .. >> Draft talks about FULL_HEADER retransmit as well .. > > > The REJECT packet is useful when the decompressor runs out of > resources. The compressor initiates compression of a stream by sending > a FH. With CRTP today the decompressor can send a CS to invalidate the > context, but the compressor does not know the reason and will attempt > to compress this stream again. A REJECT will notify the compressor > that the decompressor cannot handle compresstion of additional streams > at this moment. > An implementation that was not enhanced to use REJECT will still use > CS to invalidate the context each time the compressor attempts to > compress the stream. > The compressor continues to send the compressed packets of the stream > until he receives CS or REJECT > The intent is to make the ACCEPT/REJECT packet optional - an > optimization. > > Tmima > --------------15D6398F85975468E05872C5 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Tmima,

I wanted to ask you some doubts on ACCEPT/REJECT packet in CRTP extension draft..
It is a continuation of the old mail. In you answer below, though you wrote the
ACCPET/REJECT packe is optional, I think definition of these packet are bit confusing.
First of all I feel no need of a ACCEPT packet
Second Why to have a REJECT packet as separate packet to invalidate the context ..
Why cant we use CONTEXT_STATE packet for the same ..
We can have a bit in CS packet  indicating that context need to be invalidated or
resynchronised using FH packet. If there is no CS packet it is assumed that
flow ACCEPT.

Here the issue of interoperability also arise when an implementation interopeate with the
old CRTP (2508) implemnetation new implemetation expected ACCEPT or REJECT packet
for each FH packet .. If it does not receive either packet what action compressor is expected to take. To make interoperation possible there is a need for some sort of negotiation, here also a protocol level negotiation is expected ..
So I feel the approach with ACCEPT/REJECT packet is not optimal.
But the solution I suggested  does not cause any interoptation issue also.
No extra packet overhead, no protocol modification etc  ...

Could please answer your points on this ..

Thanks & Rgds

GVJ

 
Q3) Section III : Acknowledgement to a new compressed stream

Context Invalidation was one point which I had pointed out to Steve/tmima long time back ..
I am having those mails with me ..

But, (i) Do we need ACCEPT and REJECT packet  ??
Having a NACK mechnism sounds reasonable ..
I feel there shouldnt be both ..
But what compressor is supposed to do after sending the first FULL_HEADER packet
when compressor waiting for the ACCEPT or REJECT
should it queue the packets till the reply/or timeout
or Should it send the compressed packets assuming the decompressor will drop if there are
REJECT state at the decompressor side.

But (ii) what about the backword compatibility issue because this ACCEPT/REJECT mechanism has dependancy and it will not work with CRTP-2508

As per the current proposal we need to send ACCEPT/REJECT packet for every
FULL_HEADER packet ... (iii)Is it not adding extra bandwidth consuption ..
Draft talks about FULL_HEADER retransmit as well ..


The REJECT packet is useful when the decompressor runs out of resources. The compressor initiates compression of a stream by sending a FH. With CRTP today the decompressor can send a CS to invalidate the context, but the compressor does not know the reason and will attempt to compress this stream again. A REJECT will notify the compressor that the decompressor cannot handle compresstion of additional streams at this moment.
An implementation that was not enhanced to use REJECT will still use CS to invalidate the context each time the compressor attempts to compress the stream.
The compressor continues to send the compressed packets of the stream until he receives CS or REJECT
The intent is to make the ACCEPT/REJECT packet optional - an optimization.

Tmima
 

--------------15D6398F85975468E05872C5-- From rem-conf Tue Dec 07 10:49:48 1999 From rem-conf-request@es.net Tue Dec 07 10:49:47 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11vPe4-0000pk-00; Tue, 7 Dec 1999 10:47:28 -0800 Received: from vanessa.diee.unica.it [192.167.131.150] by mail1.es.net with esmtp (Exim 1.81 #2) id 11vPe2-0000oa-00; Tue, 7 Dec 1999 10:47:26 -0800 Received: from gwen.diee.unica.it (gwen.diee.unica.it [192.167.131.77]) by vanessa.diee.unica.it (8.9.1/8.9.1) with SMTP id TAA08852; Tue, 7 Dec 1999 19:11:54 GMT Message-Id: <3.0.1.32.19991207193306.00694338@vanessa.diee.unica.it> X-Sender: pv2000@vanessa.diee.unica.it X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Tue, 07 Dec 1999 19:33:06 +0100 To: pv2000@diee.unica.it From: pv2000 Subject: pv2000 call for papers Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D PACKET VIDEO 2000 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The 10th International Packet Video Workshop =20 1-2 May 2000 Forte Village Resort, Cagliari, Sardinia, Italy http://www.diee.unica.it/pv2000/ ********** Submission Date Extended to December 31 ********** ------------------------------------------------------------------------ PV 2000 will be held in the middle of the Mediterranean Sea, at the Forte Village Resort near Cagliari (Sardinia island), Italy. The workshop is devoted to present technological advancements and innovations in video communications over packet networks, in particular, the Internet. PVs have been unique in providing a common ground for people from video coding and networking fields; presentations on theory and practice, standards activities, and business and consumer applications are= encouraged. We cordially invite you to take part in this workshop by submitting your work and look forward to welcoming you in Sardinia in May 2000 for what will be a rewarding and exciting experience! ------------------------------------------------------------------------ SUBMISSIONS Please submit an electronic manuscript written in Word or HTML, not exceeding 10 printed pages. We will produce a CD-ROM (pdf format) containing all the accepted papers. Please note that the author of the best paper will receive a $250=20 prize and a diploma suitable for framing.=20 Additionally, SELECTED PAPERS ARE LIKELY TO BE PUBLISHED, AFTER REVISION, IN THE FOLLOWING JOURNALS: - European Transactions on Telecommunications - Image Communication DEADLINES Paper submission: DECEMBER 31, 1999,=20 Notification of acceptance: February 29, 2000 Final paper delivery: March 31, 2000=20 SUBMISSIONS PROCEDURES Submit your work in a Word document OR a set of HTML=20 files organized in a single directory to: pv2000@diee.unica.it Detailed instructions for authors and help with manuscript preparation can be found on the conference web page. ---------------------------------------------------------------------- GENERAL CHAIRS: Francesco G.B. De Natale, University of Trento, Italy Daniel D. Giusto, University of Cagliari, Italy TECHNICAL COMMITTEE CHAIRS: Leonardo Chiariglione, CSELT, Italy Maurizio D=E8cina, Cefriel and Politecnico di Milano, Italy TECHNICAL COMMITTEE (members): John Arnold, Univ. New South Wales, Australia Andrea Basso, AT&T, USA Stephen Casner, CISCO, USA Shih-Fu Chang, Columbia University, USA M. Reha Civanlar, AT&T, USA Jon Crowcroft, Univ. College London, UK Edward Delp, Purdue Univ., USA Touradj Ebrahimi, EPFL, Switzerland Mohamed Ghanbari, Univ. Essex, UK Barry G. Haskell, AT&T, USA Yu Hen Hu, Univ. Wisconsin, USA Aggelos Katsaggelos, Northwestern Univ., USA Jae-Kyoon Kim, Kaist, Korea Faouzi Kossentini, Univ. British Columbia, Canada C.-C. Jay Kuo, Univ. Southern California, USA Steven McCanne, U.C. Berkeley, USA James Modestino, Rensselaer Polytechnic Institute, USA Geoff Morrison, BT, UK Hans-Georg Musmann, TU Hannover, Germany Naohisa Ohta, Sony, Japan Sakae Okubo, Telecommunications Adv. Org., Japan Joerg Ott, Univ. Bremen, Germany Fernando Pereira, Instituto Superiore T=E9cnico, Portugal Majid Rabbani, Eastman Kodak, USA Amy Reibman, AT&T, USA Philippe Salembier, UPC, Spain Henning Schulzrinne, Columbia Univ., USA Gary Sullivan, Microsoft, USA A. Murat Tekalp, Univ. Rochester, USA Thierry Turletti, INRIA, France Stephan Wenger, TU Berlin, Germany John Woods, Rensselaer Polytechnic Institute, USA Hiroshi Yasuda, Tokyo Univ., Japan PUBLICATIONS AND DEMOS: Luigi Atzori, University of Cagliari, Italy=20 ------------------------------------------------------------------------=20 TECHNICAL PROGRAM The technical program of Packet Video 2000 will consist of invited talks, submitted paper presentations, poster sessions and demos.=20 Topics of interest include, but are not limited to: Video processing and transmission Video streaming over the Internet Network adaptive video coding and transport Packetized video for home LANs Packetized video for wireless/mobile systems Packet video protocols and storage formats Layered coding for error resilience and heterogeneous networks Packet loss resilient coding and transport=20 Terminal and server architectures for Internet TV Efficient transcoding for heterogeneous networks=20 Congestion control Error concealment Pre and post-processing for picture quality enhancement Statistical multiplexing for greater network and terminal utilization Traffic shaping for efficient network and terminal utilization=20 Interstream synchronization for multiple video presentations=20 Packet network performance modeling and evaluation Rate control for VBR video Standards: MPEG4, MPEG7, H.26L, H.323, RTP, RTSP, SIP, SDP Multicasting, MBONE applications Implementations and commercial applications ------------------------------------------------------------------------ LOCAL ARRANGEMENTS PV2000 Organizing Committee Dept. of Electrical and Electronic Engineering University of Cagliari Piazza d'Armi 09123 Cagliari, Italy pv2000@diee.unica.it From rem-conf Tue Dec 07 11:11:09 1999 From rem-conf-request@es.net Tue Dec 07 11:11:08 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11vPyW-0001fE-00; Tue, 7 Dec 1999 11:08:36 -0800 Received: from basil.cdt.luth.se [130.240.64.67] by mail1.es.net with esmtp (Exim 1.81 #2) id 11vPyU-0001f4-00; Tue, 7 Dec 1999 11:08:35 -0800 Received: from komperdell.cdt.luth.se ([130.240.52.26]) by basil.cdt.luth.se (8.9.3/8.7.3) with SMTP id UAA22039; Tue, 7 Dec 1999 20:04:19 +0100 (MET) Message-Id: <199912071904.UAA22039@basil.cdt.luth.se> X-Sender: micke@mailhost.cdt.luth.se X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Tue, 07 Dec 1999 20:21:38 +0100 To: GeeVarghese John , Tmima Koren From: Mikael Degermark Subject: Re: CRTP and IP ID Cc: casner@cisco.com, micke@cdt.luth.se, brucet@cisco.com, dwing@cisco.com, pruddy@cisco.com, rem-conf@es.net, pazhynnr@cig.mot.com In-Reply-To: <384DD3A6.3E61E0E3@miel.mot.com> References: <4.1.19991118024030.01aeaa50@jindo.cisco.com> <38358615.D8679DA0@miel.mot.com> <4.1.19991122104601.038605e0@jindo.cisco.com> <4.1.19991124103940.01ec4b60@jindo.cisco.com> <383DC57E.9D1FAA52@miel.mot.com> <4.1.19991201103902.01ef61f0@jindo.cisco.com> <4.1.19991202135725.01f5eb00@jindo.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list At 10:42 PM 99/12/07 -0500, GeeVarghese John wrote: >> Mikael Degermark suggested to enhance the COMPRESSED_NON_TCP packet instead of the CUDP >> The COMPRESSED_NON_TCP packet includes the IP ID, the udp checksum (if nonzero) and also includes one byte of data which currently holds the 4-bit CRTP sequence# (see rfc2507). 2 of the 4 unused bits can be used to flag 'T' and 'I', so the packet may also include the deltaT and deltaID if necessary. >> Such a packet will restore all parameters at the decompressor, same as CUDPid > >What I read about COMPRESSED_NON_TCP packet is, it is optional for CRTP and >mainly meant for fragmented packet etc. CNTCP can be used for any header. It does not use delta-encoding. For a UDP/IP header, the difference from CUDP is that the IP identifier is not sent using delta encoding. Instead, it is sent as an absolute value. It is not true that CUDP compresses more fields than CNTCP (except for IP ID of course). What fields did you have in mind? > ..Are we nt restricting the advantages here .. >(CUDP with IP ID can compress more (UDP etc ) fields than NON_TCP packet) >But having a mechanis to send IP ID will definitely give some sort of improvement in CUDP. The real question here is whether one wants to have more than one way to do things. If one decides to go with CUDP with the option of sending the IP ID as-is, there will be two ways. Moreover, when we want to support IPv6, where there is no IP ID field, CUDP becomes more or less obsolete. >> >> This can be done if we could change the meaning of the 'I' flag in the CR >> >packet to mean either full IP ID or deltaID. The case where the IP ID increments as expected would then not be covered. That would be bad for the well-behaved stack which increments IP ID by one for each packet. >> >> Maybe we can add an option to the CRTP negotiation about the usage of the >> >'I' flag in CR: full IP ID or deltaID >> >> Then if a host requires preserving the IP ID and cannot assign them >> >sequentially for the compressed RTP streams, the host will negotiate the 'I' >> >flag in CR packets to mean full IP ID. Won't work when the host is on the receiving end of the RTP stream. >> >> Or if we want this to be per stream, add a flag in the FH. Negotiating on that level will add considerably to the complexity of the protocol in the presence of dropped packets, etc. Do we really want that? >> I meant adding options to the IP header compression negotiation as described in rfc2509 Please make sure that what you propose makes sense for the case where none of the endpoints of the narrow link is the sender. It does not seem to me that the information needed to negotiate for example the meaning of the 'I' bit is necessarily available to either side of the link. >> >> Are there cases when it's ok for the CRTP compressor to reasign the IP ID? >> > >> >Do you mean that CRTP will reassign a new IP id to the decompressed IP >> >packet ..? >> >> Yes. I suggest a mode where CRTP does not preserve the IP ID. Please make sure that the IESG has changed their mind before you pursue that any further. Might save you some work & trouble. Micke Degermark From rem-conf Tue Dec 07 12:25:04 1999 From rem-conf-request@es.net Tue Dec 07 12:25:04 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11vR7Q-00031j-00; Tue, 7 Dec 1999 12:21:52 -0800 Received: from jindo.cisco.com [171.69.43.22] by mail1.es.net with esmtp (Exim 1.81 #2) id 11vR7N-000312-00; Tue, 7 Dec 1999 12:21:49 -0800 Received: from tmima-nt (dhcp-vm22-89-167.cisco.com [171.69.89.167]) by jindo.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with SMTP id MAA04862; Tue, 7 Dec 1999 12:19:51 -0800 (PST) Message-Id: <4.1.19991207120640.04132ed0@jindo.cisco.com> X-Sender: tmima@jindo.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 07 Dec 1999 12:21:21 -0800 To: GeeVarghese John From: Tmima Koren Subject: Re: Extensions to CRTP Cc: casner@cisco.com, micke@cdt.luth.se, brucet@cisco.com, dwing@cisco.com, pruddy@cisco.com, rem-conf@es.net, pazhynnr@cig.mot.com, gvjohn@miel.mot.com, tmima@cisco.com In-Reply-To: <384DD456.4ED6D3EA@miel.mot.com> References: <4.1.19991118024030.01aeaa50@jindo.cisco.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_4754281==_" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --=====================_4754281==_ Content-Type: multipart/alternative; boundary="=====================_4754296==_.ALT" --=====================_4754296==_.ALT Content-Type: text/plain; charset="us-ascii" At 10:45 PM 12/7/99 -0500, GeeVarghese John wrote: > > Tmima, > > I wanted to ask you some doubts on ACCEPT/REJECT packet in CRTP extension > draft.. > It is a continuation of the old mail. In you answer below, though you wrote > the > ACCPET/REJECT packe is optional, I think definition of these packet are bit > confusing. > First of all I feel no need of a ACCEPT packet > Second Why to have a REJECT packet as separate packet to invalidate the > context .. > Why cant we use CONTEXT_STATE packet for the same .. > We can have a bit in CS packet indicating that context need to be > invalidated or > resynchronised using FH packet. If there is no CS packet it is assumed that > flow ACCEPT. Yes, we suggested two formats for the REJECT packet: one is using a new code, and the other is using the CS with an extra bit See attached presentation (presented in DC) We also prefer to use the 'CS + extra bit' format Tmima > > Here the issue of interoperability also arise when an implementation > interopeate with the > old CRTP (2508) implemnetation new implemetation expected ACCEPT or REJECT > packet > for each FH packet .. If it does not receive either packet what action > compressor is expected to take. To make interoperation possible there is a > need for some sort of negotiation, here also a protocol level negotiation is > expected .. > So I feel the approach with ACCEPT/REJECT packet is not optimal. > But the solution I suggested does not cause any interoptation issue also. > No extra packet overhead, no protocol modification etc ... > > Could please answer your points on this .. All the enhancements are not backward compatible so we'll have to change the negotiation: maybe negotiate a version of CRTP, or negotiate the new options separately Tmima > > Thanks & Rgds > > GVJ >> >> >>> >>> Q3) Section III : Acknowledgement to a new compressed stream >>> >>> Context Invalidation was one point which I had pointed out to Steve/tmima >>> long time back .. >>> I am having those mails with me .. >>> >>> But, (i) Do we need ACCEPT and REJECT packet ?? >>> Having a NACK mechnism sounds reasonable .. >>> I feel there shouldnt be both .. >>> But what compressor is supposed to do after sending the first FULL_HEADER >>> packet >>> when compressor waiting for the ACCEPT or REJECT >>> should it queue the packets till the reply/or timeout >>> or Should it send the compressed packets assuming the decompressor will >>> drop if there are >>> REJECT state at the decompressor side. >>> >>> But (ii) what about the backword compatibility issue because this >>> ACCEPT/REJECT mechanism has dependancy and it will not work with CRTP-2508 >>> >>> As per the current proposal we need to send ACCEPT/REJECT packet for every >>> FULL_HEADER packet ... (iii)Is it not adding extra bandwidth consuption .. >>> Draft talks about FULL_HEADER retransmit as well .. >> >> >> >> The REJECT packet is useful when the decompressor runs out of resources. The >> compressor initiates compression of a stream by sending a FH. With CRTP >> today the decompressor can send a CS to invalidate the context, but the >> compressor does not know the reason and will attempt to compress this stream >> again. A REJECT will notify the compressor that the decompressor cannot >> handle compresstion of additional streams at this moment. >> An implementation that was not enhanced to use REJECT will still use CS to >> invalidate the context each time the compressor attempts to compress the >> stream. >> The compressor continues to send the compressed packets of the stream until >> he receives CS or REJECT >> The intent is to make the ACCEPT/REJECT packet optional - an optimization. >> >> Tmima >> > --=====================_4754296==_.ALT Content-Type: text/html; charset="us-ascii" At 10:45 PM 12/7/99 -0500, GeeVarghese John wrote:
Tmima,

I wanted to ask you some doubts on ACCEPT/REJECT packet in CRTP extension draft..
It is a continuation of the old mail. In you answer below, though you wrote the
ACCPET/REJECT packe is optional, I think definition of these packet are bit confusing.
First of all I feel no need of a ACCEPT packet
Second Why to have a REJECT packet as separate packet to invalidate the context ..
Why cant we use CONTEXT_STATE packet for the same ..
We can have a bit in CS packet  indicating that context need to be invalidated or
resynchronised using FH packet. If there is no CS packet it is assumed that
flow ACCEPT.

Yes, we suggested two formats for the REJECT packet: one is using a new code, and the other is using the CS with an extra bit
See attached presentation (presented in DC)
We also prefer to use the 'CS + extra bit' format
Tmima


Here the issue of interoperability also arise when an implementation interopeate with the
old CRTP (2508) implemnetation new implemetation expected ACCEPT or REJECT packet
for each FH packet .. If it does not receive either packet what action compressor is expected to take. To make interoperation possible there is a need for some sort of negotiation, here also a protocol level negotiation is expected ..
So I feel the approach with ACCEPT/REJECT packet is not optimal.
But the solution I suggested  does not cause any interoptation issue also.
No extra packet overhead, no protocol modification etc  ...

Could please answer your points on this ..

All the enhancements are not backward compatible so we'll have to change the negotiation: maybe negotiate a version of CRTP, or negotiate the new options separately
Tmima


Thanks & Rgds

GVJ
 
Q3) Section III : Acknowledgement to a new compressed stream

Context Invalidation was one point which I had pointed out to Steve/tmima long time back ..
I am having those mails with me ..

But, (i) Do we need ACCEPT and REJECT packet  ??
Having a NACK mechnism sounds reasonable ..
I feel there shouldnt be both ..
But what compressor is supposed to do after sending the first FULL_HEADER packet
when compressor waiting for the ACCEPT or REJECT
should it queue the packets till the reply/or timeout
or Should it send the compressed packets assuming the decompressor will drop if there are
REJECT state at the decompressor side.

But (ii) what about the backword compatibility issue because this ACCEPT/REJECT mechanism has dependancy and it will not work with CRTP-2508

As per the current proposal we need to send ACCEPT/REJECT packet for every
FULL_HEADER packet ... (iii)Is it not adding extra bandwidth consuption ..
Draft talks about FULL_HEADER retransmit as well ..


The REJECT packet is useful when the decompressor runs out of resources. The compressor initiates compression of a stream by sending a FH. With CRTP today the decompressor can send a CS to invalidate the context, but the compressor does not know the reason and will attempt to compress this stream again. A REJECT will notify the compressor that the decompressor cannot handle compresstion of additional streams at this moment.
An implementation that was not enhanced to use REJECT will still use CS to invalidate the context each time the compressor attempts to compress the stream.
The compressor continues to send the compressed packets of the stream until he receives CS or REJECT
The intent is to make the ACCEPT/REJECT packet optional - an optimization.

Tmima
 

--=====================_4754296==_.ALT-- --=====================_4754281==_ Content-Type: application/octet-stream; name="crtp-enhance-DC.ppt"; x-mac-type="534C4433"; x-mac-creator="50505433" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="crtp-enhance-DC.ppt" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAACAAAAxQAAAAAAAAAA EAAAxwAAAAEAAAD+////AAAAAM0AAADGAAAA//////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////9A PRrw1hAAAGZeZwnCDreuWP3Duh98F6UMeAAAAAAAAAAAAAAABAAAsAIAAMawlABH2mMApBAAAAD+ eJzlXWtsHNUVvndsB2woNWBRQgl1aIGUvIizzoP+aNJAGpEQVSQlaYhEoSARCyfbGEwsArLaqP8i VSAFIUpaCqWYulkwWXBJKhA/mzZgXgEaAkHBYWFNVl5wHlRyz9k5d/fM2TuPTb3pOEx0c2bmu/fM N+ec+5yZtVZKrYZ0AaQmSPkapR5yVHH7zTqlXlmsVPO118P/Wp29SamRCUqdpcRWB6lWqRu0UudA mgyHZ0K6FNLZkEZhs51rANnI1ASVuwTShSzvKHBNOZXlvZDyvvzyy2oi7eN2OaSLFd6heyt8u4zy ae9+940gr4K0BtIkSHtA/wrHLb8GzuxxMK1w1ihMk4rXcFT5ZvQiNsVyvTPgemYftm7bPfP74fdp bLGG8iDPVY7LGc+/DfufgPwCbLRFl/SAanUe4/Jt5foK9TQ5Xs7cLnMoH14H8/Fyb0EGjuMxx7cJ fJvAVwl8lcAnCnyiwN9TXvw9cV+PCPwRga8V+FqBTxL4pAp9aPOb2UwM+/mNx7Bisru72xPDJr7Q b37+5bxl3Mv748cY/3OYHnlcDXucTL2Kct9+cW3uy5T7qeU+Jd4k8CaB83ph6gnHtwl8m8BXCXyV wCcKfKLAeb0w9YTjjwj8EYGvFfhagU9S5XHA7c7tZ+KI46sD7PuwwB8W+D6B7xP4BdqL4zHHVwp8 pcAfFPiDAh8Q+IDAGx0v3ijuf7nAlwt8q8C3CnyPwI19/eqh2f9GBXWyjtIJqJNPj7HuVZAugvQq 6P1ZFXXf6Pi3oaNKVdSGdkG6V3vLXEHXdJje7mZve2N81A/pJVZHzbHBR5S3jTDHBm+F/YMMN8cG 74D9www3xwbvg/0sw82xwXOwf4Th5tjgM+Fmhhlujg3eDsd5hptjg/fC8ZesT6uR/hgt2a1Gedt2 7oOE9ubj9k0I+yaEfRPCvglh34Swb0LYNyHsmxD2TQj7JoR9E8K+CWHfhLBvQtg3IeybEPZNBIwZ 1Kg93muEfTMixrl9M8K+GWHfjLBvRtg3I+ybEfbNCPtmhH0zwr4ZYd+MsG9G2Dcj7JsR9s0I+2aE fTMB8YsBHCV+lwTE7xJh3yXCvo8J+z4m7LtX2HevsO9zwr7PCfvuFfbdK+x7UNj3oLDvXmHfvcK+ +4V99wv7fhIUv2o0UvwuUv7xu0h57btIee3L8RGBoz05bo65fTneIfA+gfcJPCfwnMDRnhw3x9y+ HG8XeC8d+7a/Klr8Lg2I36UifpeK+OX4iMDRnhw3x9y+HO8QeJ/A+wSeE3hO4GhPjptjbl+Otwu8 l47NmKBkV3fzG2vIuQ4vZ5vr1KjSuAfz8DWC81h+nzmPMmscnZA2wYnNIO/X7livC85shlFOF5zp LMhN2m/8U+lYzbaWgfz9xm1h/NOQdsOJXSBfIf79cGYXjKr64Uy6IHdrHo8vxYh/HtLrcOI4yHeI /wicOQ6jvhE4ky/I1zWvL2/FiH8LHByANA/SIeLfqg/oefqgbtWHdEtBHtC8Ph+MEf8k8e6E9Cnx 7wDenfqw7tCf6mRBHtK8vTkcI/4pGt+ktTtOR/59OqPTOqv79BGdKsiM5u1hNkb8h4gPzhGGiX8O OOeBe04P66GCzGreXh+JEf9pjsunheY1yH+mc0S3OMN6pvOlnlaQRzTvT4ZjxL/NcW2aBDlC/Nud nE46ed3ujOi2gsxp3t/lY8S/h+yJ64XHiH8v2DwFtu91jumeghwu8jfzz1PFv9J5rsP1ijx8ncHo UMpro6mUB/v1WXCxe0HO0d6xW2Ks73803H81PjzTxPNFwdPM2+PCM088jwmeZv0gLjyxP0aec7WX p1nHiAvPJPG8W/DsiBnPFPHcKXj2xYznEPEcFjxzMeOJ/SXynOV4eZp1rrjwbCOeGwTP9pjx7CGe OwTP3lPM0/RztVTG9HN8vREx2/xV5jH9XA3ToZTXFtj/T1NuPzdI81ccR2L5LjizGY46IeG+37rm WNhERfBdrQ/3NHHfxbj3w5ldcJSG1M+4m3XWuHDPE/fjjPsInDkOR3lII4y7WQOOC3fsIwdpzmq4 t+pBmLNmYb6a1bgv16fjwj1J3DsZ9w7g2wm8k5A6GPeOmHFPEfc0494HfHGu6s5TBz3z1DhxHyLu ecY9B3zzwHsIUo5xz8WMO/a5gzRHNdxnOoMwR83C/DSrcV8+D4kL9zbinmTc24FvEni3QWpn3Ntj xr2HuKcY917gmwLePZB6GffeU8zd9Nd1yv+9ODxv+utaj95RTx7TX2Me0+93N3vtY8Yrd0O6BjLd D/J6XeIxgcqVxg2la0xgPOrYvfq9xyafr2F5sz6P44VrdXleg+M4YmkA3hmCbyb9J+tHbuOx8t0E 5Y0Pnsfmo53ko79X0UfmuabNR2nhI/kMdJcqf8bE8XQIvus08NEwpEfhHr4C+WSVfGSeLdt8hOO/ 7bo8r8FxXPhEAJ4PwY+T/vHsI5yX/QPS1ZDeqJKPzPN9m49wnLtHl+c1OI5/BwLwlhB8Hukfzz7a oN1xKT4D7a+Sj8w7FjYf4Xj+GV2et9jfwP7zAXgyBO8k/ePZRzuoHr1QxXpk3nOx+Sgl6pF8JyYt 6onEUyF4+jSoRzi+fV+7z1YGq+Qj866RzUc4Pzugy/MW+xvtPuf1w4dC8DzpH88+muq49SjhVK8e mfe9bD7CeSivR/LdMJyfDgTg00LwFmf816N1jvseyEbHjb9q+Mi8c2fzEc6339XleYv9DRx/EIC3 heBJ0j+effSU47YVzzpuu1ENH5n3IG0+wnWFj3V53mJ/A8efBeA9IXiK9FfTR2bNoE7Z1wy4f9D2 /PmCn0/584UJnIcatfqXr9vUKe8axQ+Vu0axRAX4V9n9WxvBv/IdVblGscCSl68xLA7AO0PwzSH6 uyLgi9UYxIcKr8OV+LsSH+MaB/oY1ziq5WPzbrHfGscCS16+RrE4AE+H4LtC9PdHwMe7j3GNBH2M ayTV8rF5P9xvjWSBJS9f41gcgOdD8OMh+kci4OPdx7jGgj7GNZZq+di84++3xrLAkpevkSwOwFtC 8Hkh+lsj4OPdxxvIx5uq6OOOAB8nhY3lNx2dwocST4bgnSH6OyLg493HO8jHL1TRx30BPk4JG8vv ctLChxJPheDpEP19EfDx7uMs+fjLKvo4F+DjIWFj+W1VXvhQ4kMheD5Efy4CPt59jGtM6GNcY6qW j803b35rTAssefka0eIAfFoI3hKif2YEfLz7eB35eGMVfdwe4OM2YWP5jWNS+FDibSF4MkR/ewR8 vPv4KfLxs1X0cW+Aj3uEjXuFjVPChxLvCcFTIfp7I+DV9jF/r8bNOerr3zrlXffkPuLf9Mp1z+K7 vT5rZHIN9EpV+r4E36nA70uuZ2uJ8tvgsfm+xt9GYTzTxPNFwbM/ZjzzxPOY4DkSM544X0We+H0J 52m+044LzyTxvFvw7IgZzxTx3Cl49sWM5xDxHBY8czHjieM35Infl3Ce5jv+uPBsI54bBM/2mPHs IZ47BM/e/xPPal7nf/kNqrDrmM38tt3pdp0LWX6/cR+PrxsgLdPuGCQ3ar5kdbfflgaXzQvVRrVO 3aLuVO5v0+H2O5KPktxO8vck/0DyMZJ/JPk4ySdI/onkkyT/TPIpkj0knyb5F5K9JP9KcgfJFMln SD5Lso/kcyR3kkyTfJ7kCyT7Sf5N+W+6uHnHzyspXQPpOvDLMpA3OTQWXPDGQkwGw3PLfPT/RLnf V9eTvtWQfgDpLNJ5sdBpMCdE5yzQWm/R+0/tlsN3iKRexML0tvjo3Up6t1v0bo2gd7aP3uWk92aL 3uUR9CZ89DaS3skWvY0R9Lb66B2gch+pcr2Ihemd46P3ASr3uEXvAxH0zvXRu4LK3WbRuyKC3nk+ epuo3GUWvU0R9M5nek+2bR3rttpPn1/ba2sv8J2HW6DMfcpd1+G2MVhYezGL2RvTTiq326JzZ0Sd LULnMJU7YdE5HFHnbKETnyFiufm6XKfBwnQmhM4NVO4ei84NEXW2Cp07qNzzFp07IuqcI3RmqdwX Fp3ZiDrnCp24BozlZjvlOg0WpnOe0LmOyv3SonNdRJ3zlbc9eJzK7bToNFgl/Vnc2oONcEP3OO77 4NsD2gMzFoPrqIwYi+12iruesRhu/6Jx2l6Sr5J8jeQAyddL47nC9iYdv0XybZL7SL5D8l2S75H8 N8n9JN8neYDkByQ/JHmQ5Efi+ofo+GOSgyQPk/yEZIbkp6K83GxjMbQlxhnaCp/v3ue49fchEWcG w/mXX5xhrC4q2P1O1QH756qC7wvXOIP24xZ7yPGocutxlw6PPSxrYm9LjZuKsdfojb2L6fwkkpeQ /A7JZpKTSV5K8rskv0fyMpKXk7yC5BSS3yd5JcmpJKeRnE5yBsmZJK8iOYtkC8nZJBMkW0nOITmX 5DyS80leXaqDZZst9tCWGHtblPv3H3ANDNvoTWJMaTBsu/xi7+eQfgR2Xw8jsXvAA7epu9QdqhSD 34R0DqTzlRuL59D18TyvC2bN+Uw19rFq1r3PtPDnNuFr5cU57ah93ZvzRG7muYj5bX78expbxnr9 g70vuw+uk6Hr/PoUXsf/GYL93Vx+Db/nPPsdty2wrTXhPZhnKkcpX2m9Ifx3LfE6+L01zlUHcRwD MkvjQ7xOxvkCjo+CPAH40cJxlLUKwz1DnHg79XnE9YrVzoMaOZzvrKC9Jme1M1A8N1A81+i45xSx xnPLHZPP3cNzW4vnthbP7Sme2+NgizodmgJX1hTu4CunsVADTXuqHefSFV0dd93erta7+eoK+a/Q o1ihIDLcs7UkFUnHfVfbwZvHvXoHf28dNV9Q+7RzoqZO1RWfVJVvpXbqkrJ2aj+k/wC3LMihGtcB vJ0yGPrNr53Cd5p/rGZAO9cC47xm0LsIfLYSxmjNaom6Bsotgj0crTWrduhFb1e/KLRVeCcNLNWp Yn0qpLNVKWbNuQaSdaIc6qun47EYD45VGxBW1+uNj0jy351DjLebfvX7XO0tw+snr9+Yr9QORfvd WtP2Yv3Gv0H0GcjzdbQ1R16POUcTe68pN/YmAPYm2OUiS+whhn2lX+xtUt7YO9m4+7rEm+xb+O8/ 8b6lXvnH21Rt708wXni8TeVxEiHe+O93YLxN0W5/MoPawYwzRWedGXoQEu5XGoNTLTH4jnJjsBmw gzXu73bJGETsWyp6+xfe+uV0UBx+XWJRtn38m62obR//LQl+7/x30Y9Svkq/TatX3u+pwuIXy5r3 RurZfXU3ezmaNvVjKLwQMn0O8jrGryHALg3CLlHintuogdkF69iPdHleg2PdWxKAD4bgWdLP66ms f4eUW//wG4Jsjbt+L+sfYniffvWvW/mPPxbCv2Vqumotq4Oq4jHIWZQw3wSW/3Soi2X9gs97S3hf fnXxZp9+Ae3A6yLmM/WkQdnrCY9zLM/bDL+6K9sM/p5XWN3lvsJr8zp6E9XR207CXqg3Sh2VtuN1 bK0uz8vr2K0B+GAIng3Rn4mA3xpSx00fi3/j6w2IuzssdXxlhX1seP2eHtjHfl3qddn8QlXex3b5 9LG8Lzkq8vH3IxuU/7uOtrrI34HB+O2kece9JzHv4JzknHc9YB+CvX5licf1urI5b5Qep5Ix3+kQ k2ar1jNWro+3t7br1LJ91Mmvg2Uamd7JljxR/qYu+qOJ8Eba/y9MEtH0AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPAOgDNyoAAAEA 6QMoAAAAgBYAAOAQAABIEQAAzxYAAAUAAAAKAAAAIgEAAC0BAAABAAQAAAAAAA8ACQS6AAAAAAAK BAQAAAAMAAAADwDMD6YAAAAAAM0PCAAAAAAAAAABAAAwAQDDDxgAAAABAAAAAAAAAAEAAAADAAAA hQEAAACsEgAQALoPEgAAAFcAbwByAGsAcwBoAGUAZQB0ACAAug8aAAAARQB4AGMAZQBsAC4AUwBo AGUAZQB0AC4AOAAwALoPMgAAAE0AaQBjAHIAbwBzAG8AZgB0ACAARQB4AGMAZQBsACAAVwBvAHIA awBzAGgAZQBlAHQADwDyA/YBAAAvAMgPDAAAADAA0g8EAAAAAAAAAA8A1QcwAQAAAAC3D0QAAABU AGkAbQBlAHMAIABOAGUAdwAgAFIAbwBtAGEAbgAAAJSwEgCUsBIAoKwSAPjTAzDErBIACAAAAMSs EgB+1AMwAAAEABAAtw9EAAAAVABhAGgAbwBtAGEAAABlAHcAIABSAG8AbQBhAG4AAACUsBIAlLAS AKCsEgD40wMwxKwSAAgAAADErBIAftQDMAAABiIgALcPRAAAAEEAcgBpAGEAbAAAAAAAZQB3ACAA UgBvAG0AYQBuAAAAlLASAJSwEgCgrBIA+NMDMMSsEgAIAAAAxKwSAH7UAzAAAAYiMAC3D0QAAABD AG8AdQByAGkAZQByACAATgBlAHcAAABtAGEAbgAAAJSwEgCUsBIAoKwSAPjTAzDErBIACAAAAMSs EgB+1AMwAAAGMQAApA8IAAAAAAADAAEAHgAAAKUPCgAAAAAAASAAAAEAFAAAAKkPCgAAAAcAAAAC AAkEAABAAKMPbgAAAAUA//0/AAAAIiAAAGQAAAAAAAAAZAAAAAAAAAAAAEACAAAAAAIAAAD//+8A gAAAAP///////xgAAAAAAQAAAAUAACABIAEAAAAAAAUAAEACQAIAAAAAAAUAAGADYAMAAAAAAAUA AIAEgAQAAAAADwALBMIRAAAPAADwuhEAAAAABvB4DgAAAjwHAM4BAAB9AQAAHgAAAAAAAAAHAAAA AgAAAA8AAAAAAAAABAAAAAAAAAAEAAAAAAAAAA4AAAAAAAAABwAAAAAAAAAEAAAAAAAAAAQAAAAA AAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAA AAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAA AAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAA BAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAE AAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQA AAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAA AAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAA AAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAA AAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAA AAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAA AAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAA BAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAE AAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQA AAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAA AAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAA AAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAA AAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAA AAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAA AAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAA BAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAE AAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQA AAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAA AAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAA AAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAA AAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAA AAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAA AAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAA BAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAE AAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQA AAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAA AAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAA AAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAA AAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAA AAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAA AAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAA BAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAE AAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQA AAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAA AAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAYAAAAAAAAABAAAAAAAAAAGAAAA AAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAA AAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAA AAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAA AAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAA BAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAE AAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQA AAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABgAA AAAAAAAMAAAAAAAAABgAAAAAAAAABgAAAAAAAAAFAAAAAAAAAAUAAAAAAAAABAAAAAAAAAAEAAAA AAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAA AAAABAAAAAAAAAAKAAAAAAAAAAoAAAADAAAADgAAAAAAAAAKAAAAAAAAAAoAAAAAAAAABgAAAAAA AAAKAAAAAAAAAAoAAAAAAAAACgAAAAAAAAAKAAAAAQAAABUAAAADAAAADQAAAAMAAAAGAAAAAAAA AAgAAAAAAAAANQAAAAcAAABBAAAAAAAAAAsAAAARAAAAIwAAAAAAAAAlAAAAAAAAAC0AAAAAAAAA KwAAAAAAAAAEAAAABwAAAAQAAAAAAAAABAAAAAAAAAAzAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAE AAAAAAAAAAoAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAABUA AAAKAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABgAAAAIAAAAuAAAAAAAAAAQAAAAAAAAABAAA AAAAAAAEAAAAAAAAAAQAAAAAAAAAGQAAAAAAAAAbAAAABAAAAGwAAAAAAAAAQQAAAAAAAABRAAAA CAAAAEQAAAAAAAAABQAAAAAAAAACAAAAAAAAAAMAAAAFAAAABAAAABMAAAAEAAAAAAAAAAQAAAAW AAAABAAAAAkAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAA AAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAGwAA AAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAA BAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAIAAAAGgAAABYAAAAE AAAAAAAAAAQAAAAHAAAABAAAAAsAAAAEAAAACQAAAAQAAAAPAAAABAAAAAIAAAAEAAAAGQAAAAQA AAAEAAAAGwAAAA0AAAAEAAAAAAAAAAUAAAAAAAAABAAAAA0AAAAEAAAAHAAAAAQAAAAaAAAABAAA AAAAAAAEAAAADgAAAG4AAAAYAAAABAAAAA8AAAAFAAAAHgAAAAQAAAAAAAAAAwAAAAAAAAAEAAAA EQAAAAQAAAAQAAAA9QAAAAYAAAAEAAAAFAAAAAQAAAAfAAHwLAAAACIAB/AkAAAAAgRmXmcJwg63 rlj9w7offBel/wDeEAAAAQAAAAAAAAAAAIQAUwcL8L4CAAAMAfQAABANAQAAACAOAQAAACCAAQAA AACBAQQAAAiCAQAAAQCDAf///wCEAQAAAQCFAQAAACCGQQAAAACHwQAAAACIAQAAAACJAQAAAACK AQAAAACLAQAAAACMAQAAAACNAQAAAACOAQAAAACPAQAAAACQAQAAAACRAQAAAACSAQAAAACTAQAA AACUAQAAAACVAQAAAACWAQAAAACXwQAAAACYAQAAAACZAQAAAACaAQAAAACbAQAAAACcAQMAAEC/ ARgAHgDAAQEAAAjBAQAAAQDCAf///wDDAQAAACDEAQAAAADFQQAAAADGwQAAAADHAQAAAADIAQAA AADJAQAAAADKAQAAAADLATUlAADMAQAACADNAQAAAADOAQAAAADPwQAAAADWAQEAAADXAQIAAAD/ AQwADgAAAgAAAAABAoCAgAACAsvLywADAgAAACAEAgAAAQAFAjhjAAAGAjhjAAAHAgAAAAAIAgAA AAAJAgAAAQAKAgAAAAALAgAAAAAMAgAAAQANAgAAAAAOAgAAAAAPAgABAAAQAgAAAAARAgAAAAA/ AgAAAwCAAgAAAACBAgAAAQCCAgUAAACDApwxAACEAgAAAACFAvD5BgCGAgAAAACHAvcAABCIAgAA ACC/AgEADwDAAgAAAADBAgAAAADCAmQAAADDAgAAAADEAgAAAADFAgAAAADGAgAAAADHAgAAAADI AgAAAADJAgAAAADKAjB1AADLAtASEwDMAjDt7P/NAkBUiQDOAgCAAADPAgCA///QAgAAef/RAjIA AADSAiBOAADTAlDDAADUAgAAAADVAhAnAADWAnCUAADXArA8///YAgAAAADZAhAnAADaAnCUAAD/ AhYAHwAEAwEAAABAAwMAAABBA6gpAQBCAwAAAABDAwMAAABEA3y+AQBFAwAAAAB/AxAAPwCAABrx IAAAAN3d3QBm/2YA//9mAP+ZzADMmQAAzGb/AP//mQCZmf8AQAAe8RAAAAD////////////////3 AAAQHwDwDzgAAAAAAPMDFAAAACsBAAAEAAAAAAAAAAoAAIAAAAAAAADzAxQAAAAsAQAAAAAAAAAA AAALAACAAAAAAA8A0AeCAQAAHwD/AxQAAAACAAAEDAAAAAAAAAAAAAAAAAAAAA8A+gNnAAAAAAD+ AwMAAAAAAQAAAP0DNAAAAEsAAABkAAAASwAAAGQAAADQrBIAftQDMMisEgAIAAAAph0AALATAACg +f//fPz//wAAAABwAPsDCAAAAAAAAABQEAAAcAD7AwgAAAABAAAAEBQAAB8ABwQ8AAAAAAD9AzQA AAAhAAAAZAAAACEAAABkAAAAOIx4AAAAAACUsBIAAQAAAAQaAACMEAAAAAAAAAAAAAAAAP//HwAI BDwAAAAAAP0DNAAAAEIAAABkAAAAQgAAAGQAAAA4jHgAAAAAAJSwEgABAAAAph0AAEwUAAAAAAAA AAAAAAAA//8fAPoDZwAAAAAA/gMDAAAAAAEAAAD9AzQAAABkAAAAZAAAAGQAAABkAAAA0KwSAH7U AzDIrBIACAAAAKYdAACwEwAA1vn//7j///8AAAAAcAD7AwgAAAAAAAAAaAsAAHAA+wMIAAAAAQAA AKQIAAA/ANkPDAAAAAAA2g8EAAAAAAAqAE8A2Q8MAAAAAADaDwQAAAAAAD0ADwDwD8sRAAAAAPMD FAAAAAQAAAAEAAAAAgAAAAABAAAAAAAAAACfDwQAAAAGAAAAAACoDzIAAABFeHRlbnNpb25zIHRv IENSVFALC1JUUCBNdWx0aXBsZXhpbmcgdXNpbmcgVHVubmVscwAAoQ8UAAAAMwAAAAAAAAgAAAEA MwAAAAAAAAAQAJ8PBAAAAAUAAAAAAKoPCgAAAAEAAAABAAAAAAAAAPMDFAAAAIgBAAAEAAAAAgAA AE4CAAAAAAAAAACfDwQAAAAAAAAAAACoDwYAAABTdGF0dXMAAKEPFAAAAAcAAAAAAAAIAAABAAcA AAAAAAAAEACfDwQAAAABAAAAAACoDzUBAABSVFAgTXVsdGlwbGV4aW5nIHVzaW5nIFR1bm5lbHMN ZHJhZnQtd2luZy1hdnQtdGNydHAtMDAudHh0DVN1Ym1pdHRlZCBpbiBPc2xvDUJyb2tlbiBpbnRv IGRpc3RpbmN0IHBhcnRzOg1JUCBUdW5uZWxpbmcsIFBQUCBNdWx0aXBsZXhpbmcsIENSVFAgZW5o YW5jZW1lbnRzDURyYWZ0IHRvIGJlIHVwZGF0ZWQgdG8gcmVmbGVjdCBjaGFuZ2VzDUV4dGVuc2lv bnMgdG8gQ1JUUA1kcmFmdC1rb3Jlbi1hdnQtY3J0cC1lbmhhbmNlLTAwLnR4dA1UaHJlZSBlbmhh bmNlbWVudHMgdG8gUkZDIDI1MDgNQ2FuIGJlIGNvbnNpZGVyZWQgc2VwYXJhdGVseQ0AAKEP0gAA AB8AAAAAAAAAAABKAAAAAQAAAAAAMgAAAAIAAAAAACcAAAABAAAAAAATAAAAAAAAAAAAYAAAAAEA AAAAAAEAAAAAAAAAAAAeAAAAgAACABAAHAABAAAAgAAAABAASgAAAIAAAgAQABgAMQAAAIAAAgAQ ABYAAQAAAIAAAAAQACYAAACAAAIAEAAYAAEAAACAAAAAEAASAAAAgAACABAAHAABAAAAgAAAABAA IwAAAAAAAgAYADwAAACAAAIAEAAYAAEAAACAAAAAEAABAAAAAAAAAAAAqg+GAAAAKgAAAAAAAAAD AAAAAQAAAAMAAQAAAAAAAAAFAAAAAQAAAAMABAAAAAAAAAADAAAAAQAAAAMAoQAAAAAAAAAFAAAA AQAAAAMAAQAAAAAAAAADAAAAAQAAAAMAAQAAAAAAAAAEAAAAAQAAAAMADAAAAAAAAAADAAAAAQAA AAMAPgAAAAAAAAAAAPMDFAAAAHEBAAAEAAAAAgAAAEMCAAAAAAAAAACfDwQAAAAAAAAAAACgDywA AABDAE8ATQBQAFIARQBTAFMARQBEAF8AVQBEAFAAIAAiAFQAIABiAGkAdAAdIAAAoQ8UAAAAFwAA AAAAAAgAAAEAFwAAAAAAAAAQAJ8PBAAAAAEAAAAAAKgPBQEAAEN1cnJlbnRseSBvbmx5IHRoZSBJ IGJpdCBtYXkgYmUgc2V0DUEgQ09NUFJFU1NFRF9VRFAgcGFja2V0IHRoYXQgaW5jbHVkZXMgdGhl IGRlbHRhVCBjYW4gZnVsbHkgcmVzdG9yZSB0aGUgc3RhdGUgYXQgdGhlIGRlY29tcHJlc3Nvcg1O byBuZWVkIHRvIGluY2x1ZGUgdGhlIGRlbHRhVCBpbiB0aGUgZm9sbG93aW5nIENPTVBSRVNTRURf UlRQIHBhY2tldA1Vc2VkIGZvciBkZWNvbXByZXNzb3Igc3RhdGUgcmVmcmVzaCB3aXRob3V0IENP TlRFWFRfU1RBVEUNDQAAoQ8oAAAABgEAAAAAAAAAAAQBAACAAAAAEAABAAAAgAACABAAJQABAAAA AAAAAAAAqg9QAAAATgAAAAAAAAAHAAAAAQAAAAMAIwAAAAAAAAAMAAAAAQAAAAMAFwAAAAAAAAAH AAAAAQAAAAMAMQAAAAAAAAAMAAAAAQAAAAMAJwAAAAAAAAAAAPMDFAAAAG8BAAAEAAAAAgAAAEIC AAAAAAAAAACfDwQAAAAAAAAAAACoDxwAAABDT01QUkVTU0VEX1VEUCBwYWNrZXQgZm9ybWF0AACh Dx4AAAAdAAAAAAAACAAAAQAcAAAAAAACACIAAQAAAAAAAAAQAJ8PBAAAAAEAAAAAAKoPCgAAAAEA AAABAAAAAAAAAPMDFAAAAHMBAAAEAAAAAgAAAEQCAAAAAAAAAACfDwQAAAAAAAAAAACoDxMAAABO T04tUlRQIHN0cmVhbSBmbGFnAAChDxQAAAAUAAAAAAAACAAAAQAUAAAAAAAAABAAnw8EAAAAAQAA AAAAqA/xAAAATm90aWZpZXMgdGhlIGRlY29tcHJlc3NvciB0aGF0IHRoaXMgc3RyZWFtIGlzIG5v dCBhbiBSVFAgc3RyZWFtDURlY29tcHJlc3NvciBjYW4gZW50ZXIgZmxvdyBpbiBuZWdhdGl2ZSBj YWNoZSB3aXRob3V0IFJUUCBjb21wcmVzc2lvbiBhdHRlbXB0cw1MZXNzIENJRCB0aHJhc2hpbmcN VXNlZnVsIGZvciBhcHBsaWNhdGlvbiBub2RlcyB3aGVyZSBjb21wcmVzc29yIGhhcyBoaW50cyBm cm9tIGFwcGxpY2F0aW9uIGxheWVyLgAAqg8sAAAADQAAAAAAAAANAAAAAQAAAAMAJgAAAAAAAAAM AAAAAQAAAAMApgAAAAAAAAAAAPMDFAAAAEYBAAAEAAAAAgAAADICAAAAAAAAAACfDwQAAAAAAAAA AACoDy0AAABOT04tUlRQIHN0cmVhbSBmbGFnIGluIHRoZSBGVUxMX0hFQURFUiBwYWNrZXQAAKEP HgAAAC4AAAAAAAAIAAABAC0AAAAAAAAAAQAAAAAAAgAeABAAnw8EAAAAAQAAAAAAqg8KAAAAAQAA AAEAAAAAAAAA8wMUAAAAdQEAAAAAAAACAAAARQIAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPIQAAAFJl amVjdGluZyBhIG5ldyBjb21wcmVzc2VkIHN0cmVhbQAAoQ8UAAAAIgAAAAAAAAgAAAEAIgAAAAAA AAAQAJ8PBAAAAAEAAAAAAKgP1AAAAERlY29tcHJlc3NvciBpbXBsZW1lbnRhdGlvbnMgbWF5IHNo YXJlIHJlc291cmNlcyBhY3Jvc3MgbXVsdGlwbGUgbGlua3MNRGVjb21wcmVzc29yIG1heSBvdmVy IGNvbW1pdCBkZWNvbXByZXNzaW9uIHJlc291cmNlcyBpbiBSRkMgMjUwOSBuZWdvdGlhdGlvbg1E ZWNvbXByZXNzb3IgbWF5IFJFSkVDVCBhIGNvbXByZXNzZWQgc3RlYW0gd2hlbiBvdXQgb2YgcmVz b3VyY2VzAACqDzYAAAANAAAAAQAAAAMAOgAAAAAAAAANAAAAAQAAAAMAQAAAAAAAAAAMAAAAAQAA AAMANQAAAAAAAAAAAPMDFAAAAHcBAAAEAAAAAgAAAEYCAAAAAAAAAACfDwQAAAAAAAAAAACoDysA AABSZWplY3QgcGFja2V0CyAoVXNpbmcgQ09OVEVYVF9TVEFURSBvcGNvZGUpAAChDyYAAAAsAAAA AAAACAAAAQAWAAAAAAAAABQAAAAAAAIAIgACAAAAAAAAAAAAqg8aAAAAJAAAAAAAAAAGAAAAAQAA AAMAAgAAAAAAAAAQAJ8PBAAAAAEAAAAAAKoPCgAAAAEAAAABAAAAAAAAAPMDFAAAAFMBAAAEAAAA AQAAAD4CAAAAAAAAAACfDwQAAAAAAAAAAACoDw0AAABUdW5uZWxlZCBDUlRQAAChDxQAAAAOAAAA AAAACAAAAQAOAAAAAAAAAAAA8wMUAAAAfAEAAAAAAAACAAAASAIAAAAAAAAAAJ8PBAAAAAAAAAAA AKgPCwAAAENvbXByZXNzaW9uAAChDxQAAAAMAAAAAAAACAAAAQAMAAAAAAAAABAAnw8EAAAAAQAA AAAAoA+QAQAAQwBSAFQAUAAgAC0AIABSAEYAQwAyADUAMAA4AA0AQwBvAG0AcAByAGUAcwBzAGUA ZAAgAFUARABQACAAVAAtAGIAaQB0ACAAZQB4AHQAZQBuAHMAaQBvAG4ADQBBAGwAbABvAHcAcwAg AGQAcgBvAHAAcwAgAGkAbgAgAHQAdQBuAG4AZQBsACAAdwBpAHQAaABvAHUAdAAgAEMATwBOAFQA RQBYAFQAXwBTAFQAQQBUAEUADQBkAHIAYQBmAHQALQBrAG8AcgBlAG4ALQBhAHYAdAAtAGMAcgB0 AHAALQBlAG4AaABhAG4AYwBlAC0AMAAwAC4AdAB4AHQADQBNAHUAbAB0AGkAcABsAGUAeABlAGQA IABzAGUAcwBzAGkAbwBuAHMAIABkAG8AbgAZIHQAIABzAGgAYQByAGUAIABjAG8AbgB0AGUAeAB0 AA0AQwBSAFQAUAAgAHMAZQBzAHMAaQBvAG4AcwAgAGMAYQBuACAAYgBlACAAZABpAHMAdAByAGkA YgB1AHQAZQBkAAAAoQ9aAAAADwAAAAAAAAAAAB8AAAABAAAAAABRAAAAAgAAAAAAKQAAAAEAAAAA ACEAAAACAAAAAAAPAAAAAAAAAB8AAAAAAAAAUQAAAAAAAAApAAAAAAAAACEAAAAAAAAAAACqD1AA AABhAAAAAAAAAAUAAAABAAAAAwABAAAAAAAAAAMAAAABAAAAAwABAAAAAAAAAAQAAAABAAAAAwAM AAAAAAAAAAQAAAABAAAAAwBKAAAAAAAAAAAA8wMUAAAAfwEAAAQAAAACAAAASgIAAAAAAAAAAJ8P BAAAAAAAAAAAAKgPDAAAAE11bHRpcGxleGluZwAAoQ8UAAAADQAAAAAAAAgAAAEADQAAAAAAAAAQ AJ8PBAAAAAEAAAAAAKgPWgAAAFBQUCBNdWx0aXBsZXhpbmcNZHJhZnQtaWV0Zi1wcHBleHQtcHBw bXV4LTAwLnR4dA1OZXcgcGF5bG9hZCB0eXBlIGZvciBtdWx0aXBsZXhlZCBwYXlsb2FkcwAAoQ8k AAAAEQAAAAAAAAAAAEoAAAABAAAAAAARAAAAAAAAAEoAAAAAAAAAAACqD1AAAAAXAAAAAAAAAAQA AAABAAAAAwABAAAAAAAAAAYAAAABAAAAAwABAAAAAAAAAAYAAAABAAAAAwAEAAAAAAAAAAQAAAAB AAAAAwAqAAAAAAAAAAAA8wMUAAAAgQEAAAQAAAACAAAASwIAAAAAAAAAAJ8PBAAAAAAAAAAAAKgP CQAAAFR1bm5lbGluZwAAoQ8UAAAACgAAAAAAAAgAAAEACgAAAAAAAAAQAJ8PBAAAAAEAAAAAAKgP 5AAAAEVmZmljaWVudCB0dW5uZWwgaGVhZGVyIHJlcXVpcmVkDUwyVFAgd2l0aCBIZWFkZXIgQ29t cHJlc3Npb24gKEwyVFBIQykNZHJhZnQtaWV0Zi1sMnRwZXh0LWwydHBoYy0wMy50eHQNUmVtb3Zl cyBzZXNzaW9uIElELCB0dW5uZWwgSUQgZnJvbSBMMlRQDVJlbW92ZXMgVURQIGhlYWRlcg1OZWdv dGlhdGVkIElQIHByb3RvY29sIElEDU90aGVyIHR1bm5lbGluZyBlbmNhcHN1bGF0aW9ucyBwb3Nz aWJsZQAAoQ9qAAAARwAAAAAAAAAAAFwAAAABAAAAAAAaAAAAAgAAAAAAKAAAAAAAAAAAAEcAAAAA AAIAGgAgAAAAAAACABgAKAAAAAAAAAAUAAAAAAACABgAGgAAAAAAAgAWACcAAAAAAAIAGgABAAAA AAAAAAAAqg8sAAAATQAAAAAAAAAEAAAAAQAAAAMAEwAAAAAAAAAEAAAAAQAAAAMAfQAAAAAAAAAA APMDFAAAAIcBAAAEAAAAAgAAAE0CAAAAAAAAAACfDwQAAAAAAAAAAACoDxsAAABUdW5uZWxlZCBD UlRQIEVuY2Fwc3VsYXRpb24AAKEPFgAAABwAAAAAAAAIAAABABwAAAAAAAIAJgAQAJ8PBAAAAAEA AAAAAKoPCgAAAAEAAAABAAAAAAAAAPMDFAAAAIYBAAAEAAAAAAAAAEwCAAAAAAAALwDwD1ABAAAA APMDFAAAAFQBAAAAAAAAAAAAAAMBAAAAAAAAAADzAxQAAABWAQAAAAAAAAAAAAAFAQAAAAAAAAAA 8wMUAAAAYwEAAAAAAAAAAAAADgEAAAAAAAAAAPMDFAAAAHABAAAAAAAAAAAAABoBAAAAAAAAAADz AxQAAAByAQAAAAAAAAAAAAAbAQAAAAAAAAAA8wMUAAAAdAEAAAAAAAAAAAAAHAEAAAAAAAAAAPMD FAAAAHYBAAAAAAAAAAAAAB0BAAAAAAAAAADzAxQAAAB4AQAAAAAAAAAAAAAeAQAAAAAAAAAA8wMU AAAAfQEAAAAAAAAAAAAAIAEAAAAAAAAAAPMDFAAAAIABAAAAAAAAAAAAACIBAAAAAAAAAADzAxQA AACCAQAAAAAAAAAAAAAjAQAAAAAAAAAA8wMUAAAAiQEAAAAAAAAAAAAAJAEAAAAAAAABAAEEUAAA AAAAAAH///9/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAABABIAAADqAwAAAAAPAPgDqQsAAAIA7wMYAAAAAQAAAAECBwkI AAAAAAAAAAAAAAAAAAAAYADwByAAAAAAZmYA////AE1NTQDMmQAAzJkAAIAAAADAwMAAlpaWAGAA 8AcgAAAAwMDAAAEAAADAwMAAAQAAAJaWlgAAAAAA////AOrq6gBgAPAHIAAAAJnM/wBNTU0AAAAA AE1NTQCZAJkA/8wAAP///wDq6uoAYADwByAAAAAAAGYA//8AAAAAAACZzAAAmcwAAP//AACZmf8A mTP/AGAA8AcgAAAA/2YAAP/MAACWlpYAAJkAAP/MAAAAmQAA////AP+ZZgBgAPAHIAAAAP/MAAAA AAAAlpaWADNmAAAzZgAAzMwAAP///wD//68AYADwByAAAACZzP8AAQAAAJaWlgBmZjMAZmYzAP/M AAD///8AzOz/AGAA8AcgAAAA/8wAAJkAzACWlpYA/zMAAP8zAAD/zAAA////AP//zAAAAKMPPgAA AAEA//0/AAAAIiAAAGQAAAAAAAAAVQAAAAAAAAAAAEACAAAAAAIAAAD//+8AkAABAP///////yoA AAAAAwAAEACjD44AAAAFAP/9PwAFACIgAABkAAAAAAEAAGQAPAAAANgAAABAAgAAAAACAAAA///v AJAAAQD///////8eAAAAAAEAAIAlAAATICgA1AEgAQAAAgAaAKQ1AAABACIgAAAAAF8AIwDQAkAC AAACABgAgDUAABMgSwAeAPADYAMAAAIAFACABQAAuwAQBYAEAAACABIAIACjD24AAAAFAP/9PwAA ACIgAABkAAAAAAAAAGQAHgAAAAAAAABAAgAAAAACAAAA///vAIAAAAD///////8MAAAAAAEAAAAF AAAgASABAAAAAAAFAABAAkACAAAAAAAFAABgA2ADAAAAAAAFAACABIAEAAAAAEAAow9uAAAABQD/ /T8AAAAiIAAAZAAAAAAAAABkAAAAAAAAAAAAQAIAAAAAAgAAAP//7wAAAAAA////////GAAAAAAB AAAABQAAIAEgAQAAAAAABQAAQAJAAgAAAAAABQAAYANgAwAAAAAABQAAgASABAAAAABQAKMPUAAA AAUAAAABAQAABAAAAAAAAAABAAEJAAAEAAEAIAEAAAAAAgABCQAAAAABAEACAAAAAAMAAQkAAAAA AQBgAwAAAAAEAAEJAAAAAAEAgAQAAAAAYACjDw4AAAABAAAAAAAAAAAAAgAwAHAAow8+AAAABQAA AAAAAAAAAAIAGgABAAAAAAAAAAIAFgACAAAAAAAAAAIAFAADAAAAAAAAAAIAEgAEAAAAAAAAAAIA EACAAKMPPgAAAAUAAAAAAAAAAAACABUAAQAAAAAAAAACABQAAgAAAAAAAAACABIAAwAAAAAAAAAC ABAABAAAAAAAAAACAA8ADwAMBFcHAAAPAALwTwcAABAACPAIAAAACwAAABSoBQAPAAPw7QYAAA8A BPAoAAAAAQAJ8BAAAAABAQAAAAAAAGStDgFQAAAAAgAK8AgAAAAAqAUABQAAAA8ABPDTAAAAEgAK 8AgAAAAKqAUAAAoAAMMAC/BIAAAAfwABAAEAgABkHngAhQACAAAAvwAAAA8AgQEEAAAIvwEJAB8A wAEBAAAI/wEFAA8APwIAAAMAvwIBAA8A/wIWAB8AfwMQAD8AAAAQ8AgAAACgDhACwAZgDw8AEfAQ AAAAAADDCwgAAAACAAAABwF4AA8ADfBDAAAAAACfDwQAAAAEAAAAAACoDwEAAAAqAAChDxoAAAAC AAAAAAAAIAAAFAACAAAAgAADAAAAAQAOAAAA+A8EAAAAAAAAAA8ABPDVAAAAEgAK8AgAAAALqAUA AAoAAMMAC/BIAAAAfwABAAEAgADEHngAhQACAAAAvwAAAA8AgQEEAAAIvwEJAB8AwAEBAAAI/wEF AA8APwIAAAMAvwIBAA8A/wIWAB8AfwMQAD8AAAAQ8AgAAABgDxACMAmAEA8AEfAQAAAAAADDCwgA AAADAAAACQJ4AA8ADfBFAAAAAACfDwQAAAAEAAAAAACoDwEAAAAqAAChDxwAAAACAAAAAAAAKAAA AQAUAAIAAACAAAMAAAABAA4AAAD6DwQAAAAAAAAADwAE8NUAAAASAArwCAAAAAyoBQAACgAAwwAL 8EgAAAB/AAEAAQCAACQfeACFAAIAAAC/AAAADwCBAQQAAAi/AQkAHwDAAQEAAAj/AQUADwA/AgAA AwC/AgEADwD/AhYAHwB/AxAAPwAAABDwCAAAAGAPUBAAFYAQDwAR8BAAAAAAAMMLCAAAAAQAAAAI AngADwAN8EUAAAAAAJ8PBAAAAAQAAAAAAKgPAQAAACoAAKEPHAAAAAIAAAAAAAAoAAACABQAAgAA AIAAAwAAAAEADgAAANgPBAAAAAAAAAAPAATwtgAAABIACvAIAAAADagFAAAKAADzAAvwWgAAAH8A AAABAIAAhB94AIEAQR0BAIIAoI4AAIMAQR0BAIQAoI4AAIcAAQAAAL8AEAAfAIEBBAAACIMBAAAA CL8BAAARAMABAQAACP8BAAAJAAECAgAACD8CAAACAAAAEPAIAAAAfACXAUUS/AIPAA3wLAAAAAAA nw8EAAAAAAAAAAAAog8GAAAAAQAAAAAAAACqDwoAAAABAAAAAQAAAAAADwAE8LYAAAASAArwCAAA AA6oBQAACgAA8wAL8FoAAAB/AAAAAQCAAOQfeACBAEEdAQCCAKCOAACDAEEdAQCEAKCOAACHAAQA AAC/ABAAHwCBAQQAAAiDAQAAAAi/AQAAEQDAAQEAAAj/AQAACQABAgIAAAg/AgAAAgAAABDwCAAA AHsDAQH/EqcMDwAN8CwAAAAAAJ8PBAAAAAEAAAAAAKIPBgAAAAEAAAAAAAAAqg8KAAAAAQAAAAEA AAAAAA8AA/CkAgAADwAE8EYAAAABAAnwEAAAAP3///8AAAAAdAEAACICAAACAArwCAAAABCoBQAB AgAAEwAL8AYAAACIAwAAAAAAABDwCAAAAAAAAAB3ASICDwAE8GYAAAASAArwCAAAABGoBQACCgAA kwAL8DYAAACFAAIAAACHAAEAAACBAQCKrgC/ARAAEADAAQIAAAjLAZwxAAD/AQgACAABAgIAAAg/ AgAAAgAAAA/wEAAAAAEAAAAEAAAAbwEAAI8BAAAPAATwZgAAABIACvAIAAAAEqgFAAIKAACTAAvw NgAAAIUAAgAAAIcAAQAAAIEBBQAACL8BEAAQAMABAgAACMsBnDEAAP8BCAAIAAECAgAACD8CAAAC AAAAD/AQAAAAAQAAAAkBAABvAQAAHQIAAA8ABPB4AAAAQgEK8AgAAAATqAUAQgoAAMMAC/BIAAAA hQACAAAAhwABAAAAvwEAABAAwAECAAAIywE4YwAA0gEAAAAA0wEAAAAA1AEAAAAA1QEAAAAA/wEI AAgAAQICAAAIPwIAAAIAAAAP8BAAAAD9////BQEAAHMBAAAFAQAADwAE8PIAAAACAArwCAAAABSo BQACCgAAowEL8MIAAABCAXcBAABDASICAABEAQQAAABFwQwAAABGwRQAAAB/AQEAAQCBAQQAAAiD AQAAAAi/AQAAEADAAQIAAAjBAQAAAQDEAQAAAADLAThjAADNAQAAAADOAQAAAADQAQAAAADRAQAA AADSAQAAAADTAQAAAADUAQAAAADVAQAAAADXAQAAAAD/ARgAGAABAgIAAAg/AgAAAgCIAwAAAAAD AAMA8P8AACECdgEhAnYBAAAHAAgAAgAAQACwAQAAsAEAALAAgAAAD/AQAAAA/f///wAAAAB0AQAA IgIAAA8ABPBCAAAAEgAK8AgAAAABqAUAAAwAAHMAC/AqAAAAgQEGAAAIkwGOn4sAlAHevWgAvwEe AB8A/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAACZzP8ATU1NAAAAAABNTU0AmQCZAP/MAAD///8A 6urqAA8A7gPEBQAAAgDvAxgAAAACAAAAAwQHCQgAAAAKAACAAAAAAAAAAAAPAAwEdAUAAA8AAvBs BQAAMAAI8AgAAAAGAAAADKwFAA8AA/AKBQAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAA AAACAArwCAAAAACsBQAFAAAADwAE8BIBAAASAArwCAAAAAOsBQAACgAAswAL8EIAAAB/AAEAAQCA AGQkeACHAAEAAAC/AAAADwA/AQAABgCBAQQAAAi/AQ0AHwDAAQEAAAj/AQcADwA/AgAAAwB/AxAA PwAAABDwCAAAAMADQAJgFZAGDwAR8BAAAAAAAMMLCAAAAAAAAAADAHgADwAN8IgAAAAAAJ8PBAAA AAQAAAAAAKgPIAAAAENsaWNrIHRvIGVkaXQgTWFzdGVyIFRpdGxlIFN0eWxlAAChDx4AAAAhAAAA AAAAEAAAVQAhAAAAEAAHAJAAAQAqAAAAAAMAAKoPCgAAACEAAAABAAAAAAAAAKYPFAAAAPAeAAAA AAAAAAAAAAAAAAAAAAAADwAE8CMBAAASAArwCAAAAASsBQAACgAA4wAL8FQAAAB/AAEAAQCAACQl eAC/AAAADwA/AQAABgCBAQQAAAi/AQ0AHwDAAQUAAAj/AQcADwAFAgz4AAAGAnDGAAAHAqgpAQAI AnDGAAA/AgAAAwB/AxAAPwAAABDwCAAAABAIQAIAEmAMDwAR8BAAAAAAAMMLCAAAAAEAAAAEAHgA DwAN8IcAAAAAAJ8PBAAAAAQAAAAAAKgPIwAAAENsaWNrIHRvIGVkaXQgTWFzdGVyIHN1YnRpdGxl IHN0eWxlAAChDyAAAAAkAAAAAAAlIAAABQAAAAABPAAkAAAAEAADAJAAAQAeAAAAqg8KAAAAJAAA AAEAAAAAAAAApg8OAAAA+AAAANgA1AHQAvADEAUPAATw0wAAABIACvAIAAAACqwFAAAKAADDAAvw SAAAAH8AAQABAIAAhCV4AIUAAgAAAL8AAAAPAIEBBAAACL8BCQAfAMABAQAACP8BBQAPAD8CAAAD AL8CAQAPAP8CFgAfAH8DEAA/AAAAEPAIAAAAoA4QAsAGYA8PABHwEAAAAAAAwwsIAAAAAgAAAAcB eAAPAA3wQwAAAAAAnw8EAAAABAAAAAAAqA8BAAAAKgAAoQ8aAAAAAgAAAAAAACAAABQAAgAAAIAA AwAAAAEADgAAAPgPBAAAAAAAAAAPAATw1QAAABIACvAIAAAAC6wFAAAKAADDAAvwSAAAAH8AAQAB AIAA5CV4AIUAAgAAAL8AAAAPAIEBBAAACL8BCQAfAMABAQAACP8BBQAPAD8CAAADAL8CAQAPAP8C FgAfAH8DEAA/AAAAEPAIAAAAYA8QAjAJgBAPABHwEAAAAAAAwwsIAAAAAwAAAAkCeAAPAA3wRQAA AAAAnw8EAAAABAAAAAAAqA8BAAAAKgAAoQ8cAAAAAgAAAAAAACgAAAEAFAACAAAAgAADAAAAAQAO AAAA+g8EAAAAAAAAAA8ABPDVAAAAEgAK8AgAAAAMrAUAAAoAAMMAC/BIAAAAfwABAAEAgABEJngA hQACAAAAvwAAAA8AgQEEAAAIvwEJAB8AwAEBAAAI/wEFAA8APwIAAAMAvwIBAA8A/wIWAB8AfwMQ AD8AAAAQ8AgAAABgD1AQABWAEA8AEfAQAAAAAADDCwgAAAAEAAAACAJ4AA8ADfBFAAAAAACfDwQA AAAEAAAAAACoDwEAAAAqAAChDxwAAAACAAAAAAAAKAAAAgAUAAIAAACAAAMAAAABAA4AAADYDwQA AAAAAAAADwAE8EIAAAASAArwCAAAAAGsBQAADAAAcwAL8CoAAACBAQYAAAiTAY6fiwCUAd69aAC/ AR4AHwD/AQAACAAEAwkAAAA/AwEAAQAQAPAHIAAAAJnM/wBNTU0AAAAAAE1NTQCZAJkA/8wAAP// /wDq6uoADwDwA8wGAAABAPEDCAAAAAoAAIAAAAwwDwAMBIwGAAAPAALwhAYAAFAACPAIAAAABwAA AA2IBQAPAAPwIgYAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAAiAUA BQAAAA8ABPAFAQAAEgAK8AgAAAAIiAUAAAoAAPMAC/BaAAAAfwABAAEAgACkbeYAgQCbawEAggDP tQAAgwCbawEAhADPtQAAvwAQAB8AgQEEAAAIvwEJAB8AwAEBAAAI/wEFAA8APwIAAAMAvwIBAA8A /wIWAB8AfwMQAD8AAAAQ8AgAAAAAAAAAfQckAQ8AEfAQAAAAAADDCwgAAAAAAAAACgJ4AA8ADfBj AAAAAACfDwQAAAAEAAAAAACoDwEAAAAqAAChDxwAAAACAAAAAAABIAAAAQAUAAIAAACAAAMAAAAB AAwAAAD5DwQAAAAAAAAAAACmDxYAAADxHgAASgIlASUBSgJKAm8DbwOUBJQEDwAE8F4AAAASAArw CAAAAAmIBQAACgAAUwAL8B4AAACHAAEAAAB/AQAAAQC/AQEAAQD/AQgACQB/AxAAPwAAABDwCAAA ALUB8AJZDkQKDwAR8BAAAAAAAMMLCAAAAAIAAAAFAHgADwAE8EABAAASAArwCAAAAAqIBQAACgAA 8wAL8FoAAAB/AAEAAQCAAARu5gCBAJtrAQCCAM+1AACDAJtrAQCEAM+1AAC/ABAAHwCBAQQAAAi/ AQkAHwDAAQEAAAj/AQUADwA/AgAAAwC/AgEADwD/AhYAHwB/AxAAPwAAABDwCAAAANYKTgL6DhoV DwAR8BAAAAAAAMMLCAAAAAMAAAAGAngADwAN8J4AAAAAAJ8PBAAAAAIAAAAAAKgPUgAAAENsaWNr IHRvIGVkaXQgTWFzdGVyIHRleHQgc3R5bGVzDVNlY29uZCBsZXZlbA1UaGlyZCBsZXZlbA1Gb3Vy dGggbGV2ZWwNRmlmdGggbGV2ZWwAAKIPHgAAACEAAAAAAA0AAAABAAwAAAACAA0AAAADAAwAAAAE AAAAqg8KAAAAUwAAAAEAAAAAAA8ABPAHAQAAEgAK8AgAAAALiAUAAAoAAPMAC/BaAAAAfwABAAEA gABkbuYAgQCbawEAggDPtQAAgwCbawEAhADPtQAAvwAQAB8AgQEEAAAIvwEJAB8AwAEBAAAI/wEF AA8APwIAAAMAvwIBAA8A/wIWAB8AfwMQAD8AAAAQ8AgAAAAAAMsJSBEkAQ8AEfAQAAAAAADDCwgA AAABAAAABwB4AA8ADfBlAAAAAACfDwQAAAAEAAAAAACoDwEAAAAqAAChDx4AAAACAAAAAAABKAAA AQACABQAAgAAAIAAAwAAAAEADAAAAPgPBAAAAAAAAAAAAKYPFgAAAPEeAABKAiUBJQFKAkoCbwNv A5QElAQPAATwCwEAABIACvAIAAAADIgFAAAKAAADAQvwYAAAAH8AAQABAIAAxG7mAIEAm2sBAIIA z7UAAIMAm2sBAIQAz7UAAIcAAgAAAL8AEAAfAIEBBAAACL8BCQAfAMABAQAACP8BBQAPAD8CAAAD AL8CAQAPAP8CFgAfAH8DEAA/AAAAEPAIAAAAqxUAAH0HzxYPABHwEAAAAAAAwwsIAAAABAAAAAkC eAAPAA3wYwAAAAAAnw8EAAAABAAAAAAAqA8BAAAAKgAAoQ8cAAAAAgAAAAAAASAAAAEAFAACAAAA gAADAAAAAQAMAAAA+g8EAAAAAAAAAAAApg8WAAAA8R4AAEoCJQElAUoCSgJvA28DlASUBA8ABPAN AQAAEgAK8AgAAAANiAUAAAoAAAMBC/BgAAAAfwABAAEAgAAkb+YAgQCbawEAggDPtQAAgwCbawEA hADPtQAAhwACAAAAvwAQAB8AgQEEAAAIvwEJAB8AwAEBAAAI/wEFAA8APwIAAAMAvwIBAA8A/wIW AB8AfwMQAD8AAAAQ8AgAAACrFcsJSBHPFg8AEfAQAAAAAADDCwgAAAAFAAAACAJ4AA8ADfBlAAAA AACfDwQAAAAEAAAAAACoDwEAAAAqAAChDx4AAAACAAAAAAABKAAAAQACABQAAgAAAIAAAwAAAAEA DAAAANgPBAAAAAAAAAAAAKYPFgAAAPEeAABKAiUBJQFKAkoCbwNvA5QElAQPAATwQgAAABIACvAI AAAAAYgFAAAMAABzAAvwKgAAAIEBAAAACJMBykJrAJQBc4mNAL8BEgASAP8BAAAIAAQDCQAAAD8D AQABABAA8AcgAAAA////AAAAAACWlpYAAAAAAADMmQAzM8wAzMz/ALKysgAPAMkPRgUAAA8ADAQW BQAADwAC8A4FAABAAAjwCAAAAAUAAAAFsAUADwAD8KwEAAAPAATwKAAAAAEACfAQAAAA9fX19fX1 9fX19fX19fX19QIACvAIAAAAALAFAAUAAAAPAATwIwEAABIACvAIAAAAArAFAAAKAADzAAvwWgAA AH8AAQABAIAAJGzmAIEAm2sBAIIAz7UAAIMAm2sBAIQAz7UAAL8AEAAfAIEBBAAACL8BCQAfAMAB AQAACP8BBQAPAD8CAAADAL8CAQAPAP8CFgAfAH8DEAA/AAAAEPAIAAAAAAAAAH0HJAEPABHwEAAA AAAAwwsIAAAAAAAAAAoCeAAPAA3wgQAAAAAAnw8EAAAABAAAAAAAqA8LAAAAVG1pbWEgS29yZW4A AKEPGgAAAAwAAAAAAAAgAAAUAAwAAACAAAMAAAABAAwAAACqDxoAAAAFAAAAAAAAAAYAAAABAAAA AwABAAAAAAAAAAAApg8WAAAA8R4AAEoCJQElAUoCSgJvA28DlASUBA8ABPAFAQAAEgAK8AgAAAAD sAUAAAoAAPMAC/BaAAAAfwABAAEAgACEbOYAgQCbawEAggDPtQAAgwCbawEAhADPtQAAvwAQAB8A gQEEAAAIvwEJAB8AwAEBAAAI/wEFAA8APwIAAAMAvwIBAA8A/wIWAB8AfwMQAD8AAAAQ8AgAAAAA AMsJSBEkAQ8AEfAQAAAAAADDCwgAAAABAAAABwJ4AA8ADfBjAAAAAACfDwQAAAAEAAAAAACoDwEA AAAqAAChDxwAAAACAAAAAAAAKAAAAgAUAAIAAACAAAMAAAABAAwAAAD4DwQAAAAAAAAAAACmDxYA AADxHgAASgIlASUBSgJKAm8DbwOUBJQEDwAE8CkBAAASAArwCAAAAASwBQAACgAAAwEL8GAAAAB/ AAEAAQCAAORs5gCBAJtrAQCCAM+1AACDAJtrAQCEAM+1AACHAAIAAAC/ABAAHwCBAQQAAAi/AQkA HwDAAQEAAAj/AQUADwA/AgAAAwC/AgEADwD/AhYAHwB/AxAAPwAAABDwCAAAAKsVAAB9B88WDwAR 8BAAAAAAAMMLCAAAAAIAAAAJAngADwAN8IEAAAAAAJ8PBAAAAAQAAAAAAKgPLQAAAFR1bm5lbGVk IG11bHRpcGxleGVkIENvbXByZXNzZWQgUlRQICgiVENSVFAiKQAAoQ8aAAAALgAAAAAAACAAABQA LgAAAIAAAwAAAAEADAAAAKYPFgAAAPEeAABKAiUBJQFKAkoCbwNvA5QElAQPAATwCwEAABIACvAI AAAABbAFAAAKAAADAQvwYAAAAH8AAQABAIAARG3mAIEAm2sBAIIAz7UAAIMAm2sBAIQAz7UAAIcA AgAAAL8AEAAfAIEBBAAACL8BCQAfAMABAQAACP8BBQAPAD8CAAADAL8CAQAPAP8CFgAfAH8DEAA/ AAAAEPAIAAAAqxXLCUgRzxYPABHwEAAAAAAAwwsIAAAAAwAAAAgCeAAPAA3wYwAAAAAAnw8EAAAA BAAAAAAAqA8BAAAAKgAAoQ8cAAAAAgAAAAAAACgAAAIAFAACAAAAgAADAAAAAQAMAAAA2A8EAAAA AAAAAAAApg8WAAAA8R4AAEoCJQElAUoCSgJvA28DlASUBA8ABPBCAAAAEgAK8AgAAAABsAUAAAwA AHMAC/AqAAAAgQEAAAAIkwHKQmsAlAFziY0AvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAA AAD///8AAAAAAJaWlgAAAAAAAMyZADMzzADMzP8AsrKyAA8A7gM7AwAAAgDvAxgAAAAAAAAADxAA AAAAAAALAACAAwEAAAcAAAAPAAwE6wIAAA8AAvDjAgAAIAAI8AgAAAAEAAAADggAAA8AA/CBAgAA DwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAAIAAAFAAAADwAE8HIAAAAS AArwCAAAAAIIAAAgAgAAUwAL8B4AAAAEAAAAAACAAKQmeACHAAEAAAD/AQAAAQABAwOsBQAAABDw CAAAADAD4AEAFQAGDwAR8BAAAAAAAMMLCAAAAAAAAAAPAHgADwAN8AwAAAAAAJ4PBAAAAAAAAAAP AATwugAAAKIMCvAIAAAADQgAAAAKAADDAAvwSAAAAIAABGvmAIUAAgAAAIcABgAAAL8AAgACAIEB BAAACL8BCAAeAMABAQAACP8BBAAOAD8CAAADAL8CAQAPAP8CFgAfAH8DEAA/AAAAEPAIAAAAIAoL C38LegsPAA3wQgAAAAAAnw8EAAAABAAAAAAAoQ8cAAAAAQAAAAAAACgAAAEAFAABAAAAgAADAAAA AQAeAAAAqg8KAAAAAQAAAAEAAAAAAA8ABPANAQAAogwK8AgAAAAOCAAAAAoAAMMAC/BIAAAAgABk a+YAhQACAAAAhwAGAAAAvwACAAIAgQEEAAAIvwEIAB4AwAEBAAAI/wEEAA4APwIAAAMAvwIBAA8A /wIWAB8AfwMQAD8AAAAQ8AgAAACQCYAHaA/4Dg8ADfCVAAAAAACfDwQAAAAEAAAAAACoDy0AAABC cnVjZSBUaG9tcHNvbg1UbWltYSBLb3Jlbg0NQ2lzY28gU3lzdGVtcyBJbmMAAKEPKgAAAC4AAAAA AAAoAAABABQALQAAAIAAAwAAAAEAHgABAAAAgQADAAEAAQAeAAAAqg8aAAAADwAAAAAAAAAMAAAA AQAAAAMAEwAAAAAAAAAPAATwQgAAABIACvAIAAAAAQgAAAAMAABzAAvwKgAAAIEBAAAACJMBjp+L AJQB3r1oAL8BEgASAP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAAwMDAAAEAAADAwMAAAQAAAJaW lgAAAAAA////AOrq6gAPAO4D5AEAAAIA7wMYAAAAAQAAAA0OAAAAAAAACgAAgCQBAAAHAAAADwAM BJQBAAAPAALwjAEAAGAACPAIAAAAAwAAAAMwBwAPAAPwJAEAAA8ABPAoAAAAAQAJ8BAAAAAAAAAA AAAAAAAAAAAAAAAAAgAK8AgAAAAAMAcABQAAAA8ABPByAAAAEgAK8AgAAAACMAcAAAIAAFMAC/Ae AAAAgADkb+YAvwEAABEA/wEAAAkAAQMAAAAAiAMAAAAAAAAQ8AgAAABgAEACQBQwAw8AEfAQAAAA AADDCwgAAAAAAAAADQB4AA8ADfAMAAAAAACeDwQAAAAAAAAADwAE8HIAAAASAArwCAAAAAMwBwAA AgAAUwAL8B4AAACAAMRx5gC/AQAAEQD/AQAACQABAwAAAACIAwAAAAAAABDwCAAAAHAC8AAwFXAO DwAR8BAAAAAAAMMLCAAAAAEAAAAOAHgADwAN8AwAAAAAAJ4PBAAAAAEAAAAPAATwSAAAABIACvAI AAAAATAHAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMBjp+LAJQB3r1oAL8BHgAfAP8BAAAIAAQD CQAAAD8DAQABABAA8AcgAAAAwMDAAAEAAADAwMAAAQAAAJaWlgAAAAAA////AOrq6gAPAO4D5AEA AAIA7wMYAAAAAQAAAA0OAAAAAAAACgAAgBsBAAAHAAAADwAMBJQBAAAPAALwjAEAAHAACPAIAAAA AwAAAAPYBgAPAAPwJAEAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAngAAAHcAAAAAAAAAAgAK8AgAAAAA 2AYABQAAAA8ABPByAAAAEgAK8AgAAAAC2AYAAAIAAFMAC/AeAAAAgACEcuYAvwEAABEA/wEAAAkA AQMAAAAAiAMAAAAAAAAQ8AgAAACAAUACQBRQBA8AEfAQAAAAAADDCwgAAAAAAAAADQB4AA8ADfAM AAAAAACeDwQAAAAAAAAADwAE8HIAAAASAArwCAAAAAPYBgAAAgAAUwAL8B4AAACAAORy5gC/AQAA EQD/AQAACQABAwAAAACIAwAAAAAAABDwCAAAAFAEIAFgFVAQDwAR8BAAAAAAAMMLCAAAAAEAAAAO AHgADwAN8AwAAAAAAJ4PBAAAAAEAAAAPAATwSAAAABIACvAIAAAAAdgGAAAMAACDAAvwMAAAAIEB AAAACIMBBQAACJMBjp+LAJQB3r1oAL8BHgAfAP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAAwMDA AAEAAADAwMAAAQAAAJaWlgAAAAAA////AOrq6gAPAO4DoxMAAAIA7wMYAAAAAQAAAA0OAAAAAAAA CgAAgBoBAAAHAAAADwAMBFMTAAAPAALwSxMAAIAACPAIAAAAGQAAABnMBgAPAAPw4xIAAA8ABPAo AAAAAQAJ8BAAAAAAAAAAngAAAHcAAAAAAAAAAgAK8AgAAAAAzAYABQAAAA8ABPByAAAAEgAK8AgA AAACzAYAAAIAAFMAC/AeAAAAgAAEdOYAvwEAABEA/wEAAAkAAQMAAAAAiAMAAAAAAAAQ8AgAAADA AEACQBSQAw8AEfAQAAAAAADDCwgAAAAAAAAADQB4AA8ADfAMAAAAAACeDwQAAAAAAAAADwAE8NoA AAASAArwCAAAAAPMBgAACgAAswAL8EIAAACAAMR05gCFAAIAAACHAAEAAACBAZmZ/wC/ARgAHgDA AQEAAAj/AQwADgA/AgAAAwC/AgEADwD/AhYAHwB/AxAAPwAAABDwCAAAAFAEIAFQCnAFDwAN8GgA AAAAAJ8PBAAAAAQAAAAAAKgPEgAAACBsc2Igb2YgY29udGV4dCBJRAAAoQ8YAAAAEwAAAAAAACgA AAEAFAATAAAAAAACABwAAACqDxoAAAABAAAAAAAAAAMAAAABAAAAAwAPAAAAAAAAAA8ABPC2AAAA EgAK8AgAAAAEzAYAAAoAALMAC/BCAAAAgACEdeYAhQACAAAAhwABAAAAgQGZmf8AvwEYAB4AwAEB AAAI/wEMAA4APwIAAAMAvwIBAA8A/wIWAB8AfwMQAD8AAAAQ8AgAAACQBiABUAoACQ8ADfBEAAAA AACfDwQAAAAEAAAAAACoDwwAAABVRFAgQ2hlY2tzdW0AAKEPHAAAAA0AAAAAAAAoAAABABQADQAA AIAAAwAAAAEAHgAPAATwyAAAABIACvAIAAAABcwGAAAKAACzAAvwQgAAAIAARHbmAIUAAgAAAIcA AQAAAIEBmZn/AL8BGAAeAMABAQAACP8BDAAOAD8CAAADAL8CAQAPAP8CFgAfAH8DEAA/AAAAEPAI AAAAAAkgAVAKoAsPAA3wVgAAAAAAnw8EAAAABAAAAAAAoA8eAAAAHCBSAEEATgBEAE8ATQAdICAA ZgBpAGUAbABkAHMAAAChDxwAAAAQAAAAAAAAKAAAAQAUABAAAACAAAMAAAABAB4ADwAE8LcAAAAS AArwCAAAAAbMBgAACgAAswAL8EIAAACAABQA+ACFAAIAAACHAAEAAACBAZmZ/wC/ARgAHgDAAQEA AAj/AQwADgA/AgAAAwC/AgEADwD/AhYAHwB/AxAAPwAAABDwCAAAAKALIAFQCsAMDwAN8EUAAAAA AJ8PBAAAAAQAAAAAAKgPDQAAAERlbHRhIElQdjQgSUQAAKEPHAAAAA4AAAAAAAAoAAABABQADgAA AIAAAwAAAAEAHgAPAATw6AAAABIACvAIAAAAB8wGAAAKAACzAAvwQgAAAIAA1AD4AIUAAgAAAIcA AQAAAIEBmZn/AL8BGAAeAMABAQAACP8BDAAOAD8CAAADAL8CAQAPAP8CFgAfAH8DEAA/AAAAEPAI AAAAwAwgAVAKAA8PAA3wdgAAAAAAnw8EAAAABAAAAAAAqA8iAAAAVURQIGRhdGENKHVuY29tcHJl c3NlZCBSVFAgaGVhZGVyKQAAoQ84AAAAIwAAAAAAACgAAAEAFAAJAAAAgAADAAAAAQAeABkAAACA AAMAAAABABYAAQAAAIAAAwAAAAEAHgAPAATw4wAAABIACvAIAAAACMwGAAAKAACzAAvwQgAAAIAA lAH4AIUAAgAAAIcAAQAAAIEBmZn/AL8BGAAeAMABAQAACP8BDAAOAD8CAAADAL8CAQAPAP8CFgAf AH8DEAA/AAAAEPAIAAAAcAWgBVAKkAYPAA3wcQAAAAAAnw8EAAAABAAAAAAAqA8LAAAAQ1JUUCBz ZXEgIyAAAKEPKAAAAAwAAAAAAAAoAAABABQACwAAAIAAAQAAAAEAAQAAAIAAAwAAAAEAIgAAAKoP GgAAAAUAAAAAAAAAAwAAAAEAAAADAAQAAAAAAAAADwAE8KsAAAASAArwCAAAAAnMBgAACgAAswAL 8EIAAACAAPQB+ACFAAIAAACHAAEAAACBAZmZ/wC/ARgAHgDAAQEAAAj/AQwADgA/AgAAAwC/AgEA DwD/AhYAHwB/AxAAPwAAABDwCAAAAHAFgASgBZAGDwAN8DkAAAAAAJ8PBAAAAAQAAAAAAKgPAQAA AEkAAKEPHAAAAAIAAAAAAAAoAAABABQAAgAAAIAAAwAAAAEAHgAPAATwqwAAABIACvAIAAAACswG AAAKAACzAAvwQgAAAIAAVAL4AIUAAgAAAIcAAQAAAIEBmZn/AL8BGAAeAMABAQAACP8BDAAOAD8C AAADAL8CAQAPAP8CFgAfAH8DEAA/AAAAEPAIAAAAcAUgAUACkAYPAA3wOQAAAAAAnw8EAAAABAAA AAAAqA8BAAAAMAAAoQ8cAAAAAgAAAAAAACgAAAEAFAACAAAAgAADAAAAAQAeAA8ABPCrAAAAEgAK 8AgAAAALzAYAAAoAALMAC/BCAAAAgAC0AvgAhQACAAAAhwABAAAAgQGZmf8AvwEYAB4AwAEBAAAI /wEMAA4APwIAAAMAvwIBAA8A/wIWAB8AfwMQAD8AAAAQ8AgAAABwBUACYAOQBg8ADfA5AAAAAACf DwQAAAAEAAAAAACoDwEAAAAwAAChDxwAAAACAAAAAAAAKAAAAQAUAAIAAACAAAMAAAABAB4ADwAE 8KsAAAASAArwCAAAAAzMBgAACgAAswAL8EIAAACAABQD+ACFAAIAAACHAAEAAACBAZmZ/wC/ARgA HgDAAQEAAAj/AQwADgA/AgAAAwC/AgEADwD/AhYAHwB/AxAAPwAAABDwCAAAAHAFYAOABJAGDwAN 8DkAAAAAAJ8PBAAAAAQAAAAAAKgPAQAAADAAAKEPHAAAAAIAAAAAAAAoAAABABQAAgAAAIAAAwAA AAEAHgAPAATw2gAAABIACvAIAAAADcwGAAAKAACzAAvwQgAAAIAA1AP4AIUAAgAAAIcAAQAAAIEB mZn/AL8BGAAeAMABAQAACP8BDAAOAD8CAAADAL8CAQAPAP8CFgAfAH8DEAA/AAAAEPAIAAAAUAQA DDAVcAUPAA3waAAAAAAAnw8EAAAABAAAAAAAqA8SAAAAIGxzYiBvZiBjb250ZXh0IElEAAChDxgA AAATAAAAAAAAKAAAAQAUABMAAAAAAAIAHAAAAKoPGgAAAAEAAAAAAAAAAwAAAAEAAAADAA8AAAAA AAAADwAE8LYAAAASAArwCAAAAA7MBgAACgAAswAL8EIAAACAAJQE+ACFAAIAAACHAAEAAACBAZmZ /wC/ARgAHgDAAQEAAAj/AQwADgA/AgAAAwC/AgEADwD/AhYAHwB/AxAAPwAAABDwCAAAAJAGAAww FQAJDwAN8EQAAAAAAJ8PBAAAAAQAAAAAAKgPDAAAAFVEUCBDaGVja3N1bQAAoQ8cAAAADQAAAAAA ACgAAAEAFAANAAAAgAADAAAAAQAeAA8ABPDIAAAAEgAK8AgAAAAPzAYAAAoAALMAC/BCAAAAgABU BfgAhQACAAAAhwABAAAAgQGZmf8AvwEYAB4AwAEBAAAI/wEMAA4APwIAAAMAvwIBAA8A/wIWAB8A fwMQAD8AAAAQ8AgAAAAACQAMMBWgCw8ADfBWAAAAAACfDwQAAAAEAAAAAACgDx4AAAAcIFIAQQBO AEQATwBNAB0gIABmAGkAZQBsAGQAcwAAAKEPHAAAABAAAAAAAAAoAAABABQAEAAAAIAAAwAAAAEA HgAPAATwtwAAABIACvAIAAAAEMwGAAAKAACzAAvwQgAAAIAAFAb4AIUAAgAAAIcAAQAAAIEBmZn/ AL8BGAAeAMABAQAACP8BDAAOAD8CAAADAL8CAQAPAP8CFgAfAH8DEAA/AAAAEPAIAAAAoAsADDAV wAwPAA3wRQAAAAAAnw8EAAAABAAAAAAAqA8NAAAARGVsdGEgSVB2NCBJRAAAoQ8cAAAADgAAAAAA ACgAAAEAFAAOAAAAgAADAAAAAQAeAA8ABPDoAAAAEgAK8AgAAAARzAYAAAoAALMAC/BCAAAAgADU BvgAhQACAAAAhwABAAAAgQGZmf8AvwEYAB4AwAEBAAAI/wEMAA4APwIAAAMAvwIBAA8A/wIWAB8A fwMQAD8AAAAQ8AgAAADgDQAMMBUgEA8ADfB2AAAAAACfDwQAAAAEAAAAAACoDyIAAABVRFAgZGF0 YQ0odW5jb21wcmVzc2VkIFJUUCBoZWFkZXIpAAChDzgAAAAjAAAAAAAAKAAAAQAUAAkAAACAAAMA AAABAB4AGQAAAIAAAwAAAAEAFgABAAAAgAADAAAAAQAeAA8ABPDBAAAAEgAK8AgAAAASzAYAAAoA ALMAC/BCAAAAgACUB/gAhQACAAAAhwABAAAAgQH//5kAvwEYAB4AwAEzzDMA/wEMAA4APwIAAAMA vwIBAA8A/wIWAB8AfwMQAD8AAAAQ8AgAAADADAAMMBXgDQ8ADfBPAAAAAACfDwQAAAAEAAAAAACo DxMAAABkZWx0YSBSVFAgdGltZXN0YW1wAAChDyAAAAAUAAAAAAAAKAAAAQAUABMAAAAAAAIAIAAB AAAAAAAAAA8ABPDjAAAAEgAK8AgAAAATzAYAAAoAALMAC/BCAAAAgABUCPgAhQACAAAAhwABAAAA gQGZmf8AvwEYAB4AwAEBAAAI/wEMAA4APwIAAAMAvwIBAA8A/wIWAB8AfwMQAD8AAAAQ8AgAAABw BYAQMBWQBg8ADfBxAAAAAACfDwQAAAAEAAAAAACoDwsAAABDUlRQIHNlcSAjIAAAoQ8oAAAADAAA AAAAACgAAAEAFAALAAAAgAABAAAAAQABAAAAgAADAAAAAQAiAAAAqg8aAAAABQAAAAAAAAADAAAA AQAAAAMABAAAAAAAAAAPAATwqwAAABIACvAIAAAAFMwGAAAKAACzAAvwQgAAAIAAtAj4AIUAAgAA AIcAAQAAAIEBmZn/AL8BGAAeAMABAQAACP8BDAAOAD8CAAADAL8CAQAPAP8CFgAfAH8DEAA/AAAA EPAIAAAAcAVgD4AQkAYPAA3wOQAAAAAAnw8EAAAABAAAAAAAqA8BAAAASQAAoQ8cAAAAAgAAAAAA ACgAAAEAFAACAAAAgAADAAAAAQAeAA8ABPCrAAAAEgAK8AgAAAAVzAYAAAoAALMAC/BCAAAAgAAU CfgAhQACAAAAhwABAAAAgQGZmf8AvwEYAB4AwAEBAAAI/wEMAA4APwIAAAMAvwIBAA8A/wIWAB8A fwMQAD8AAAAQ8AgAAABwBQAMIA2QBg8ADfA5AAAAAACfDwQAAAAEAAAAAACoDwEAAAAwAAChDxwA AAACAAAAAAAAKAAAAQAUAAIAAACAAAMAAAABAB4ADwAE8KsAAAASAArwCAAAABbMBgAACgAAswAL 8EIAAACAAHQJ+ACFAAIAAACHAAEAAACBAZmZ/wC/ARgAHgDAAQEAAAj/AQwADgA/AgAAAwC/AgEA DwD/AhYAHwB/AxAAPwAAABDwCAAAAHAFIA1ADpAGDwAN8DkAAAAAAJ8PBAAAAAQAAAAAAKgPAQAA ADAAAKEPHAAAAAIAAAAAAAAoAAABABQAAgAAAIAAAwAAAAEAHgAPAATwqwAAABIACvAIAAAAF8wG AAAKAACzAAvwQgAAAIAA1An4AIUAAgAAAIcAAQAAAIEB//+ZAL8BGAAeAMABM8wzAP8BDAAOAD8C AAADAL8CAQAPAP8CFgAfAH8DEAA/AAAAEPAIAAAAcAVADmAPkAYPAA3wOQAAAAAAnw8EAAAABAAA AAAAqA8BAAAAVAAAoQ8cAAAAAgAAAAAAACgAAAEAFAACAAAAgAADAAAAAQAeAA8ABPDaAAAAEgAK 8AgAAAAYzAYAAAoAALMAC/BCAAAAgACUCvgAhQACAAAAhwABAAAAgQGZmf8AvwEYAB4AwAEBAAAI /wEMAA4APwIAAAMAvwIBAA8A/wIWAB8AfwMQAD8AAAAQ8AgAAAAwAyABUApQBA8ADfBoAAAAAACf DwQAAAAEAAAAAACoDxIAAAAgbXNiIG9mIGNvbnRleHQgSUQAAKEPGAAAABMAAAAAAAAoAAABABQA EwAAAAAAAgAcAAAAqg8aAAAAAQAAAAAAAAADAAAAAQAAAAMADwAAAAAAAAAPAATw2gAAABIACvAI AAAAGcwGAAAKAACzAAvwQgAAAIAAVAv4AIUAAgAAAIcAAQAAAIEBmZn/AL8BGAAeAMABAQAACP8B DAAOAD8CAAADAL8CAQAPAP8CFgAfAH8DEAA/AAAAEPAIAAAAMAMADDAVUAQPAA3waAAAAAAAnw8E AAAABAAAAAAAqA8SAAAAIG1zYiBvZiBjb250ZXh0IElEAAChDxgAAAATAAAAAAAAKAAAAQAUABMA AAAAAAIAHAAAAKoPGgAAAAEAAAAAAAAAAwAAAAEAAAADAA8AAAAAAAAADwAE8EgAAAASAArwCAAA AAHMBgAADAAAgwAL8DAAAACBAQAAAAiDAQUAAAiTAY6fiwCUAd69aAC/AR4AHwD/AQAACAAEAwkA AAA/AwEAAQAQAPAHIAAAAMDAwAABAAAAwMDAAAEAAACWlpYAAAAAAP///wDq6uoADwDuA+QBAAAC AO8DGAAAAAEAAAANDgAAAAAAAAoAAIAcAQAABwAAAA8ADASUAQAADwAC8IwBAACQAAjwCAAAAAMA AAAD4AYADwAD8CQBAAAPAATwKAAAAAEACfAQAAAAAAAAAJ4AAAB3AAAAAAAAAAIACvAIAAAAAOAG AAUAAAAPAATwcgAAABIACvAIAAAAAuAGAAACAABTAAvwHgAAAIAAtAv4AL8BAAARAP8BAAAJAAED AAAAAIgDAAAAAAAAEPAIAAAA8ABAAkAUwAMPABHwEAAAAAAAwwsIAAAAAAAAAA0A+AAPAA3wDAAA AAAAng8EAAAAAAAAAA8ABPByAAAAEgAK8AgAAAAD4AYAAAIAAFMAC/AeAAAAgACkP/gAvwEAABEA /wEAAAkAAQMAAAAAiAMAAAAAAAAQ8AgAAADAA0AC0BTgDQ8AEfAQAAAAAADDCwgAAAABAAAADgD4 AA8ADfAMAAAAAACeDwQAAAABAAAADwAE8EgAAAASAArwCAAAAAHgBgAADAAAgwAL8DAAAACBAQAA AAiDAQUAAAiTAY6fiwCUAd69aAC/AR4AHwD/AQAACAAEAwkAAAA/AwEAAQAQAPAHIAAAAMDAwAAB AAAAwMDAAAEAAACWlpYAAAAAAP///wDq6uoADwDuAxQPAAACAO8DGAAAAAEAAAANDgAAAAAAAAoA AIAFAQAABwAAAA8ADATEDgAADwAC8LwOAACgAAjwCAAAABQAAAAtHAYAIAAY8QgAAAABAAAAAgAB AA8AA/BEDgAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAAcBgAFAAAA DwAE8HIAAAASAArwCAAAAAIcBgAAAgAAUwAL8B4AAACAACRB+AC/AQAAEQD/AQAACQABAwAAAACI AwAAAAAAABDwCAAAAMAAQAJAFJADDwAR8BAAAAAAAMMLCAAAAAAAAAANAPgADwAN8AwAAAAAAJ4P BAAAAAAAAAAPAATwrQAAABIACvAIAAAAFhwGAAAKAACzAAvwQgAAAIAAhEH4AIUAAgAAAIcAAQAA AIEBmZn/AL8BGAAeAMABAQAACP8BDAAOAD8CAAADAL8CAQAPAP8CFgAfAH8DEAA/AAAAEPAIAAAA kAYQC0AUsAcPAA3wOwAAAAAAnw8EAAAABAAAAAAAqA8DAAAAQ0lEAAChDxwAAAAEAAAAAAAAKAAA AQAUAAQAAACAAAMAAAABAB4ADwAE8KsAAAASAArwCAAAABocBgAACgAAswAL8EIAAACAAORB+ACF AAIAAACHAAEAAACBAZmZ/wC/ARgAHgDAAQEAAAj/AQwADgA/AgAAAwC/AgEADwD/AhYAHwB/AxAA PwAAABDwCAAAABAI4AFwDjAJDwAN8DkAAAAAAJ8PBAAAAAQAAAAAAKgPAQAAADAAAKEPHAAAAAIA AAAAAAAoAAABABQAAgAAAIAAAwAAAAEAHgAPAATwzwAAABIACvAIAAAAHRwGAAAKAACzAAvwQgAA AIAApEL4AIUAAgAAAIcAAQAAAIEBmZn/AL8BGAAeAMABAQAACP8BDAAOAD8CAAADAL8CAQAPAP8C FgAfAH8DEAA/AAAAEPAIAAAAkAYgBBALsAcPAA3wXQAAAAAAnw8EAAAABAAAAAAAqA8LAAAAR2Vu ZXJhdGlvbiAAAKEPNgAAAAwAAAAAAAAoAAABABQACgAAAIAAAwAAAAEAIAABAAAAgAABAAAAAQAB AAAAgAADAAAAAQAiAA8ABPCrAAAAEgAK8AgAAAAfHAYAAAoAALMAC/BCAAAAgAAEQ/gAhQACAAAA hwABAAAAgQGZmf8AvwEYAB4AwAEBAAAI/wEMAA4APwIAAAMAvwIBAA8A/wIWAB8AfwMQAD8AAAAQ 8AgAAACQBuABAAOwBw8ADfA5AAAAAACfDwQAAAAEAAAAAACoDwEAAAAwAAChDxwAAAACAAAAAAAA KAAAAQAUAAIAAACAAAMAAAABAB4ADwAE8KsAAAASAArwCAAAACAcBgAACgAAswAL8EIAAACAAGRD +ACFAAIAAACHAAEAAACBAZmZ/wC/ARgAHgDAAQEAAAj/AQwADgA/AgAAAwC/AgEADwD/AhYAHwB/ AxAAPwAAABDwCAAAAJAGAAMgBLAHDwAN8DkAAAAAAJ8PBAAAAAQAAAAAAKgPAQAAADEAAKEPHAAA AAIAAAAAAAAoAAABABQAAgAAAIAAAwAAAAEAHgAPAATwqwAAABIACvAIAAAAIRwGAAAKAACzAAvw QgAAAIAAxEP4AIUAAgAAAIcAAQAAAIEB//+ZAL8BGAAeAMABM8wzAP8BDAAOAD8CAAADAL8CAQAP AP8CFgAfAH8DEAA/AAAAEPAIAAAAEAhwDpAPMAkPAA3wOQAAAAAAnw8EAAAABAAAAAAAqA8BAAAA VQAAoQ8cAAAAAgAAAAAAACgAAAEAFAACAAAAgAADAAAAAQAeAA8ABPDDAAAAogwK8AgAAAAiHAYA AAoAAKMAC/A8AAAAgACERPgAvwACAAIAgQEEAAAIvwEIAB4AwAEBAAAI/wEEAA4APwIAAAMAvwIB AA8A/wIWAB8AfwMQAD8AAAAQ8AgAAADwA1AB4BAQBQ8ADfBXAAAAAACfDwQAAAAEAAAAAACoDyUA AABOZXcgRlVMTF9IRUFERVIgbGVuZ3RoIGZpZWxkcyBmb3JtYXQ6AAChDxYAAAAmAAAAAAAAKAAA AQAyACYAAAAAAAAADwAE8LMAAACiDArwCAAAACMcBgAACgAAowAL8DwAAACAAERF+AC/AAIAAgCB AQQAAAi/AQgAHgDAAQEAAAj/AQQADgA/AgAAAwC/AgEADwD/AhYAHwB/AxAAPwAAABDwCAAAABAF EAIwCTAGDwAN8EcAAAAAAJ8PBAAAAAQAAAAAAKgPFQAAAEZvciA4LWJpdCBjb250ZXh0IElEOgAA oQ8WAAAAFgAAAAAAACgAAAEAMgAWAAAAAAAAAA8ABPC0AAAAogwK8AgAAAAkHAYAAAoAAKMAC/A8 AAAAgAAERvgAvwACAAIAgQEEAAAIvwEIAB4AwAEBAAAI/wEEAA4APwIAAAMAvwIBAA8A/wIWAB8A fwMQAD8AAAAQ8AgAAADACRACMAngCg8ADfBIAAAAAACfDwQAAAAEAAAAAACoDxYAAABGb3IgMTYt Yml0IGNvbnRleHQgSUQ6AAChDxYAAAAXAAAAAAAAKAAAAQAyABcAAAAAAAAADwAE8NcAAAASAArw CAAAACUcBgAACgAAswAL8EIAAACAAGRG+ACFAAIAAACHAAEAAACBAZmZ/wC/ARgAHgDAAQEAAAj/ AQwADgA/AgAAAwC/AgEADwD/AhYAHwB/AxAAPwAAABDwCAAAABAIkA9AFDAJDwAN8GUAAAAAAJ8P BAAAAAQAAAAAAKgPBQAAAFNlcSAjAAChDyoAAAAGAAAAAAAAKAAAAQAUAAUAAACAAAMAAAABACIA AQAAAIAAAwAAAAEAHgAAAKoPEgAAAAQAAAABAAAAAwACAAAAAAAAAA8ABPDXAAAAEgAK8AgAAAAm HAYAAAoAALMAC/BCAAAAgADERvgAhQACAAAAhwABAAAAgQGZmf8AvwEYAB4AwAEBAAAI/wEMAA4A PwIAAAMAvwIBAA8A/wIWAB8AfwMQAD8AAAAQ8AgAAABAC5APQBRgDA8ADfBlAAAAAACfDwQAAAAE AAAAAACoDwUAAABTZXEgIwAAoQ8qAAAABgAAAAAAACgAAAEAFAAFAAAAgAADAAAAAQAiAAEAAACA AAMAAAABAB4AAACqDxIAAAAEAAAAAQAAAAMAAgAAAAAAAAAPAATwrQAAABIACvAIAAAAJxwGAAAK AACzAAvwQgAAAIAAJEf4AIUAAgAAAIcAAQAAAIEBmZn/AL8BGAAeAMABAQAACP8BDAAOAD8CAAAD AL8CAQAPAP8CFgAfAH8DEAA/AAAAEPAIAAAAwAzgAUAU4A0PAA3wOwAAAAAAnw8EAAAABAAAAAAA qA8DAAAAQ0lEAAChDxwAAAAEAAAAAAAAKAAAAQAUAAQAAACAAAMAAAABAB4ADwAE8M8AAAASAArw CAAAACgcBgAACgAAswAL8EIAAACAAORH+ACFAAIAAACHAAEAAACBAZmZ/wC/ARgAHgDAAQEAAAj/ AQwADgA/AgAAAwC/AgEADwD/AhYAHwB/AxAAPwAAABDwCAAAAEALIAQQC2AMDwAN8F0AAAAAAJ8P BAAAAAQAAAAAAKgPCwAAAEdlbmVyYXRpb24gAAChDzYAAAAMAAAAAAAAKAAAAQAUAAoAAACAAAMA AAABACAAAQAAAIAAAQAAAAEAAQAAAIAAAwAAAAEAIgAPAATwqwAAABIACvAIAAAAKRwGAAAKAACz AAvwQgAAAIAAREj4AIUAAgAAAIcAAQAAAIEBmZn/AL8BGAAeAMABAQAACP8BDAAOAD8CAAADAL8C AQAPAP8CFgAfAH8DEAA/AAAAEPAIAAAAQAvgAQADYAwPAA3wOQAAAAAAnw8EAAAABAAAAAAAqA8B AAAAMQAAoQ8cAAAAAgAAAAAAACgAAAEAFAACAAAAgAADAAAAAQAeAA8ABPCrAAAAEgAK8AgAAAAq HAYAAAoAALMAC/BCAAAAgACkSPgAhQACAAAAhwABAAAAgQGZmf8AvwEYAB4AwAEBAAAI/wEMAA4A PwIAAAMAvwIBAA8A/wIWAB8AfwMQAD8AAAAQ8AgAAABACwADIARgDA8ADfA5AAAAAACfDwQAAAAE AAAAAACoDwEAAAAxAAChDxwAAAACAAAAAAAAKAAAAQAUAAIAAACAAAMAAAABAB4ADwAE8KsAAAAS AArwCAAAACscBgAACgAAswAL8EIAAACAAARJ+ACFAAIAAACHAAEAAACBAf//mQC/ARgAHgDAATPM MwD/AQwADgA/AgAAAwC/AgEADwD/AhYAHwB/AxAAPwAAABDwCAAAAEALcA6QD2AMDwAN8DkAAAAA AJ8PBAAAAAQAAAAAAKgPAQAAAFUAAKEPHAAAAAIAAAAAAAAoAAABABQAAgAAAIAAAwAAAAEAHgAP AATwuQAAABIACvAIAAAALBwGAAAKAACzAAvwQgAAAIAAZEn4AIUAAgAAAIcAAQAAAIEBmZn/AL8B GAAeAMABAQAACP8BDAAOAD8CAAADAL8CAQAPAP8CFgAfAH8DEAA/AAAAEPAIAAAAQAsQC3AOYAwP AA3wRwAAAAAAnw8EAAAABAAAAAAAqA8BAAAAMAAAoQ8qAAAAAgAAAAAAACgAAAEAFAABAAAAgAAD AAAAAQAiAAEAAACAAAMAAAABAB4ADwAE8NQAAACiDArwCAAAAC0cBgAACgAAwwAL8EgAAACAACRK +ACFAAIAAACHAAYAAAC/AAIAAgCBAQQAAAi/AQgAHgDAAQEAAAj/AQQADgA/AgAAAwC/AgEADwD/ AhYAHwB/AxAAPwAAABDwCAAAAIUO1gGqEt8PDwAN8FwAAAAAAJ8PBAAAAAQAAAAAAKgPJgAAAFNl dCBVID0gMSB0byBpbmRpY2F0ZSBhIG5vbi1SVFAgc3RyZWFtAAChDxoAAAAnAAAAAAAAIAAAFAAn AAAAgAADAAAAAQAeAA8ABPBIAAAAEgAK8AgAAAABHAYAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAI kwGOn4sAlAHevWgAvwEeAB8A/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAADAwMAAAQAAAMDAwAAB AAAAlpaWAAAAAAD///8A6urqAA8A7gPkAQAAAgDvAxgAAAABAAAADQ4AAAAAAAAKAACAHQEAAAcA AAAPAAwElAEAAA8AAvCMAQAAsAAI8AgAAAADAAAAA+gGAA8AA/AkAQAADwAE8CgAAAABAAnwEAAA AAAAAACeAAAAdwAAAAAAAAACAArwCAAAAADoBgAFAAAADwAE8HIAAAASAArwCAAAAALoBgAAAgAA UwAL8B4AAACAAIRK+AC/AQAAEQD/AQAACQABAwAAAACIAwAAAAAAABDwCAAAAIABQAJAFFAEDwAR 8BAAAAAAAMMLCAAAAAAAAAANAPgADwAN8AwAAAAAAJ4PBAAAAAAAAAAPAATwcgAAABIACvAIAAAA A+gGAAACAABTAAvwHgAAAIAA5Er4AL8BAAARAP8BAAAJAAEDAAAAAIgDAAAAAAAAEPAIAAAA4AQQ AqAU4A0PABHwEAAAAAAAwwsIAAAAAQAAAA4A+AAPAA3wDAAAAAAAng8EAAAAAQAAAA8ABPBIAAAA EgAK8AgAAAAB6AYAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwGOn4sAlAHevWgAvwEeAB8A/wEA AAgABAMJAAAAPwMBAAEAEADwByAAAADAwMAAAQAAAMDAwAABAAAAlpaWAAAAAAD///8A6urqAA8A 7gPIEgAAAgDvAxgAAAABAAAADQ4AAAAAAAAKAACAHgEAAAcAAAAPAAwEeBIAAA8AAvBwEgAAwAAI 8AgAAAAZAAAAGvAGAA8AA/AIEgAADwAE8CgAAAABAAnwEAAAAAAAAACeAAAAdwAAAAAAAAACAArw CAAAAADwBgAFAAAADwAE8LkAAAASAArwCAAAABbwBgAACgAAswAL8EIAAACAAFRR+ACFAAIAAACH AAEAAACBAZmZ/wC/ARgAHgDAAQEAAAj/AQwADgA/AgAAAwC/AgEADwD/AhYAHwB/AxAAPwAAABDw CAAAAFwHAAwwFZwJDwAN8EcAAAAAAJ8PBAAAAAQAAAAAAKgPEwAAACBzZXNzaW9uIGNvbnRleHQg SUQAAKEPGAAAABQAAAAAAAAoAAABABQAFAAAAAAAAgAcAA8ABPByAAAAEgAK8AgAAAAC8AYAAAIA AFMAC/AeAAAAgAC0UfgAvwEAABEA/wEAAAkAAQMAAAAAiAMAAAAAAAAQ8AgAAADAAEACQBSQAw8A EfAQAAAAAADDCwgAAAAAAAAADQB4AA8ADfAMAAAAAACeDwQAAAAAAAAADwAE8LQAAAASAArwCAAA AAPwBgAACgAAswAL8EIAAACAAHRS+ACFAAIAAACHAAEAAACBAZmZ/wC/ARgAHgDAAQEAAAj/AQwA DgA/AgAAAwC/AgEADwD/AhYAHwB/AxAAPwAAABDwCAAAADwGIAFQClwHDwAN8EIAAAAAAJ8PBAAA AAQAAAAAAKgPDgAAACBjb250ZXh0IGNvdW50AAChDxgAAAAPAAAAAAAAKAAAAQAUAA8AAAAAAAIA HAAPAATw4gAAABIACvAIAAAABPAGAAAKAACzAAvwQgAAAIAANFP4AIUAAgAAAIcAAQAAAIEBmZn/ AL8BGAAeAMABAQAACP8BDAAOAD8CAAADAL8CAQAPAP8CFgAfAH8DEAA/AAAAEPAIAAAAfAigBVAK nAkPAA3wcAAAAAAAnw8EAAAABAAAAAAAqA8KAAAAQ1JUUCBzZXEjIAAAoQ8oAAAACwAAAAAAACgA AAEAFAAKAAAAgAABAAAAAQABAAAAgAADAAAAAQAiAAAAqg8aAAAABQAAAAAAAAADAAAAAQAAAAMA AwAAAAAAAAAPAATwqwAAABIACvAIAAAABfAGAAAKAACzAAvwQgAAAIAAlFP4AIUAAgAAAIcAAQAA AIEBmZn/AL8BGAAeAMABAQAACP8BDAAOAD8CAAADAL8CAQAPAP8CFgAfAH8DEAA/AAAAEPAIAAAA fAiABKAFnAkPAA3wOQAAAAAAnw8EAAAABAAAAAAAqA8BAAAAMAAAoQ8cAAAAAgAAAAAAACgAAAEA FAACAAAAgAADAAAAAQAeAA8ABPCrAAAAEgAK8AgAAAAG8AYAAAoAALMAC/BCAAAAgAD0U/gAhQAC AAAAhwABAAAAgQH//5kAvwEYAB4AwAEzzDMA/wEMAA4APwIAAAMAvwIBAA8A/wIWAB8AfwMQAD8A AAAQ8AgAAAB8CEACYAOcCQ8ADfA5AAAAAACfDwQAAAAEAAAAAACoDwEAAAAxAAChDxwAAAACAAAA AAAAKAAAAQAUAAIAAACAAAMAAAABAB4ADwAE8KsAAAASAArwCAAAAAfwBgAACgAAswAL8EIAAACA AFRU+ACFAAIAAACHAAEAAACBAZmZ/wC/ARgAHgDAAQEAAAj/AQwADgA/AgAAAwC/AgEADwD/AhYA HwB/AxAAPwAAABDwCAAAAHwIIAFAApwJDwAN8DkAAAAAAJ8PBAAAAAQAAAAAAKgPAQAAADEAAKEP HAAAAAIAAAAAAAAoAAABABQAAgAAAIAAAwAAAAEAHgAPAATwqwAAABIACvAIAAAACPAGAAAKAACz AAvwQgAAAIAAtFT4AIUAAgAAAIcAAQAAAIEBmZn/AL8BGAAeAMABAQAACP8BDAAOAD8CAAADAL8C AQAPAP8CFgAfAH8DEAA/AAAAEPAIAAAAfAhgA4AEnAkPAA3wOQAAAAAAnw8EAAAABAAAAAAAqA8B AAAAMAAAoQ8cAAAAAgAAAAAAACgAAAEAFAACAAAAgAADAAAAAQAeAA8ABPDLAAAAEgAK8AgAAAAJ 8AYAAAoAALMAC/BCAAAAgAB0VfgAhQACAAAAhwABAAAAgQGZmf8AvwEYAB4AwAEBAAAI/wEMAA4A PwIAAAMAvwIBAA8A/wIWAB8AfwMQAD8AAAAQ8AgAAAAcBSABUAo8Bg8ADfBZAAAAAACfDwQAAAAE AAAAAACoDxMAAAAgMT1SZWplY3QgOC1iaXQgQ0lEAAChDyoAAAAUAAAAAAAAKAAAAQAUAAEAAAAA AAIAHAABAAAAAAACACAAEgAAAAAAAAAPAATwuQAAABIACvAIAAAACvAGAAAKAACzAAvwQgAAAIAA NFb4AIUAAgAAAIcAAQAAAIEBmZn/AL8BGAAeAMABAQAACP8BDAAOAD8CAAADAL8CAQAPAP8CFgAf AH8DEAA/AAAAEPAIAAAAXAcgAVAKfAgPAA3wRwAAAAAAnw8EAAAABAAAAAAAqA8TAAAAIHNlc3Np b24gY29udGV4dCBJRAAAoQ8YAAAAFAAAAAAAACgAAAEAFAAUAAAAAAACABwADwAE8MEAAAASAArw CAAAAAvwBgAACgAAswAL8EIAAACAAPRW+ACFAAIAAACHAAEAAACBAZmZ/wC/ARgAHgDAAQEAAAj/ AQwADgA/AgAAAwC/AgEADwD/AhYAHwB/AxAAPwAAABDwCAAAAJwJYANQCrwKDwAN8E8AAAAAAJ8P BAAAAAQAAAAAAKgPCwAAAGdlbmVyYXRpb24gAAChDygAAAAMAAAAAAAAKAAAAQAUAAsAAACAAAEA AAABAAEAAACAAAMAAAABACIADwAE8KsAAAASAArwCAAAAAzwBgAACgAAswAL8EIAAACAAFRX+ACF AAIAAACHAAEAAACBAZmZ/wC/ARgAHgDAAQEAAAj/AQwADgA/AgAAAwC/AgEADwD/AhYAHwB/AxAA PwAAABDwCAAAAJwJIAFAArwKDwAN8DkAAAAAAJ8PBAAAAAQAAAAAAKgPAQAAADAAAKEPHAAAAAIA AAAAAAAoAAABABQAAgAAAIAAAwAAAAEAHgAPAATwqwAAABIACvAIAAAADfAGAAAKAACzAAvwQgAA AIAAtFf4AIUAAgAAAIcAAQAAAIEBmZn/AL8BGAAeAMABAQAACP8BDAAOAD8CAAADAL8CAQAPAP8C FgAfAH8DEAA/AAAAEPAIAAAAnAlAAmADvAoPAA3wOQAAAAAAnw8EAAAABAAAAAAAqA8BAAAAMAAA oQ8cAAAAAgAAAAAAACgAAAEAFAACAAAAgAADAAAAAQAeAA8ABPC0AAAAEgAK8AgAAAAP8AYAAAoA ALMAC/BCAAAAgAB0WPgAhQACAAAAhwABAAAAgQGZmf8AvwEYAB4AwAEBAAAI/wEMAA4APwIAAAMA vwIBAA8A/wIWAB8AfwMQAD8AAAAQ8AgAAAA8BgAMMBVcBw8ADfBCAAAAAACfDwQAAAAEAAAAAACo Dw4AAAAgY29udGV4dCBjb3VudAAAoQ8YAAAADwAAAAAAACgAAAEAFAAPAAAAAAACABwADwAE8OMA AAASAArwCAAAABDwBgAACgAAswAL8EIAAACAADRZ+ACFAAIAAACHAAEAAACBAZmZ/wC/ARgAHgDA AQEAAAj/AQwADgA/AgAAAwC/AgEADwD/AhYAHwB/AxAAPwAAABDwCAAAAJwJgBAwFbwKDwAN8HEA AAAAAJ8PBAAAAAQAAAAAAKgPCwAAAENSVFAgc2VxICMgAAChDygAAAAMAAAAAAAAKAAAAQAUAAsA AACAAAEAAAABAAEAAACAAAMAAAABACIAAACqDxoAAAAFAAAAAAAAAAMAAAABAAAAAwAEAAAAAAAA AA8ABPCrAAAAEgAK8AgAAAAR8AYAAAoAALMAC/BCAAAAgACUWfgAhQACAAAAhwABAAAAgQGZmf8A vwEYAB4AwAEBAAAI/wEMAA4APwIAAAMAvwIBAA8A/wIWAB8AfwMQAD8AAAAQ8AgAAACcCWAPgBC8 Cg8ADfA5AAAAAACfDwQAAAAEAAAAAACoDwEAAAAwAAChDxwAAAACAAAAAAAAKAAAAQAUAAIAAACA AAMAAAABAB4ADwAE8KsAAAASAArwCAAAABLwBgAACgAAswAL8EIAAACAAPRZ+ACFAAIAAACHAAEA AACBAf//mQC/ARgAHgDAATPMMwD/AQwADgA/AgAAAwC/AgEADwD/AhYAHwB/AxAAPwAAABDwCAAA AJwJIA1ADrwKDwAN8DkAAAAAAJ8PBAAAAAQAAAAAAKgPAQAAADEAAKEPHAAAAAIAAAAAAAAoAAAB ABQAAgAAAIAAAwAAAAEAHgAPAATwqwAAABIACvAIAAAAE/AGAAAKAACzAAvwQgAAAIAAVFr4AIUA AgAAAIcAAQAAAIEBmZn/AL8BGAAeAMABAQAACP8BDAAOAD8CAAADAL8CAQAPAP8CFgAfAH8DEAA/ AAAAEPAIAAAAnAkADCANvAoPAA3wOQAAAAAAnw8EAAAABAAAAAAAqA8BAAAAMQAAoQ8cAAAAAgAA AAAAACgAAAEAFAACAAAAgAADAAAAAQAeAA8ABPCrAAAAEgAK8AgAAAAU8AYAAAoAALMAC/BCAAAA gAC0WvgAhQACAAAAhwABAAAAgQGZmf8AvwEYAB4AwAEBAAAI/wEMAA4APwIAAAMAvwIBAA8A/wIW AB8AfwMQAD8AAAAQ8AgAAACcCUAOYA+8Cg8ADfA5AAAAAACfDwQAAAAEAAAAAACoDwEAAAAwAACh DxwAAAACAAAAAAAAKAAAAQAUAAIAAACAAAMAAAABAB4ADwAE8MwAAAASAArwCAAAABXwBgAACgAA swAL8EIAAACAAHRb+ACFAAIAAACHAAEAAACBAZmZ/wC/ARgAHgDAAQEAAAj/AQwADgA/AgAAAwC/ AgEADwD/AhYAHwB/AxAAPwAAABDwCAAAABwFAAwwFTwGDwAN8FoAAAAAAJ8PBAAAAAQAAAAAAKgP FAAAACAyPVJlamVjdCAxNi1iaXQgQ0lEAAChDyoAAAAVAAAAAAAAKAAAAQAUAAEAAAAAAAIAHAAB AAAAAAACACAAEwAAAAAAAAAPAATwwQAAABIACvAIAAAAF/AGAAAKAACzAAvwQgAAAIAANFz4AIUA AgAAAIcAAQAAAIEBmZn/AL8BGAAeAMABAQAACP8BDAAOAD8CAAADAL8CAQAPAP8CFgAfAH8DEAA/ AAAAEPAIAAAAvApADjAV3AsPAA3wTwAAAAAAnw8EAAAABAAAAAAAqA8LAAAAZ2VuZXJhdGlvbiAA AKEPKAAAAAwAAAAAAAAoAAABABQACwAAAIAAAQAAAAEAAQAAAIAAAwAAAAEAIgAPAATwqwAAABIA CvAIAAAAGPAGAAAKAACzAAvwQgAAAIAAVN/4AIUAAgAAAIcAAQAAAIEBmZn/AL8BGAAeAMABAQAA CP8BDAAOAD8CAAADAL8CAQAPAP8CFgAfAH8DEAA/AAAAEPAIAAAAvAoADCAN3AsPAA3wOQAAAAAA nw8EAAAABAAAAAAAqA8BAAAAMAAAoQ8cAAAAAgAAAAAAACgAAAEAFAACAAAAgAADAAAAAQAeAA8A BPCrAAAAEgAK8AgAAAAZ8AYAAAoAALMAC/BCAAAAgAC03/gAhQACAAAAhwABAAAAgQGZmf8AvwEY AB4AwAEBAAAI/wEMAA4APwIAAAMAvwIBAA8A/wIWAB8AfwMQAD8AAAAQ8AgAAAC8CiANQA7cCw8A DfA5AAAAAACfDwQAAAAEAAAAAACoDwEAAAAwAAChDxwAAAACAAAAAAAAKAAAAQAUAAIAAACAAAMA AAABAB4ADwAE8OoAAACiDArwCAAAABrwBgAACgAAwwAL8EgAAACAABTg+ACFAAIAAACHAAYAAAC/ AAIAAgCBAQQAAAi/AQgAHgDAAQEAAAj/AQQADgA/AgAAAwC/AgEADwD/AhYAHwB/AxAAPwAAABDw CAAAAMwMdgFiDQAPDwAN8HIAAAAAAJ8PBAAAAAQAAAAAAKgPQgAAAENJRCwgQ1JUUCBzZXF1ZW5j ZSMgYW5kIGdlbmVyYXRpb24NIGFyZSB0YWtlbiBmcm9tIHRoZSBGVUxMX0hFQURFUgAAoQ8UAAAA QwAAAAAAACAAABQAQwAAAAAAAAAPAATwSAAAABIACvAIAAAAAfAGAAAMAACDAAvwMAAAAIEBAAAA CIMBBQAACJMBjp+LAJQB3r1oAL8BHgAfAP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAAwMDAAAEA AADAwMAAAQAAAJaWlgAAAAAA////AOrq6gAPAO4DhQMAAAIA7wMYAAAABwAAAA0AAAAAAAAACgAA gA4BAAAHAAAADwAMBDUDAAAPAALwLQMAANAACPAIAAAAAwAAAANUBgAPAAPwxQIAAA8ABPAoAAAA AQAJ8BAAAAAAAAAAngAAAHcAAAAAAAAAAgAK8AgAAAAAVAYABQAAAA8ABPByAAAAEgAK8AgAAAAC VAYAAAIAAFMAC/AeAAAAgAB04PgAvwEAABEA/wEAAAkAPwIAAAIAAQMAAAAAAAAQ8AgAAABQAXAC cBQgBA8AEfAQAAAAAADDCwgAAAAAAAAADQD4AA8ADfAMAAAAAACeDwQAAAAAAAAADwAE8BMCAACi DArwCAAAAANUBgAACgAAwwAL8EgAAACAANTg+ACFAAIAAACHAAYAAAC/AAIAAgCBAQQAAAi/AQgA HgDAAQEAAAj/AQQADgA/AgAAAwC/AgEADwD/AhYAHwB/AxAAPwAAABDwCAAAAGADcAKFFIoPDwAN 8JsBAAAAAJ8PBAAAAAQAAAAAAKgPEwEAAEVuY2Fwc3VsYXRpb24gZm9yIGVuZCB0byBlbmQgbXVs dGlwbGV4aW5nDUNvbnNpc3RzIG9mOg1Db21wcmVzc2lvbiAtIFJGQyAyNTA4DU11bHRpcGxleGlu ZyAtIFBQUCBsYXllciBtdWx0aXBsZXhpbmcNSVAgdHVubmVsaW5nIGZvciBQUFAgLSBMMlRQDUNS VFAgbmVnb3RpYXRpb24gLSBSRkMgMjUwOQ1BcHBsaWNhdGlvbiBydW5zIHdpdGggUlRQIGVuY2Fw c3VsYXRpb24NQ1JUUCwgbXVsdGlwbGV4aW5nIGF0IGxheWVyIDINVHVubmVsIGFkZHMgZGVzdGlu YXRpb24gSVAgaGVhZGVyAAChD2wAAAA3AAAAAAABIAAAAQAUAHUAAAABAAAgAAAUACgAAAAAAAEg AAABABQAQAAAAAEAACAAABQANwAAAIAAAwAAAAEAHgB1AAAAgAADAAAAAQAeACgAAACAAAMAAAAB AB4AQAAAAIAAAwAAAAEAHgAPAATwSAAAABIACvAIAAAAAVQGAAAMAACDAAvwMAAAAIEBAAAACIMB BQAACJMBjp+LAJQB3r1oAL8BEgASAP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAAwMDAAAEAAADA wMAAAQAAAJaWlgAAAAAA////AOrq6gAPAO4D5AEAAAIA7wMYAAAAAQAAAA0OAAAAAAAACgAAgCAB AAAHAAAADwAMBJQBAAAPAALwjAEAAOAACPAIAAAAAwAAAAMABwAPAAPwJAEAAA8ABPAoAAAAAQAJ 8BAAAAAAAAAAngAAAHcAAAAAAAAAAgAK8AgAAAAAAAcABQAAAA8ABPByAAAAEgAK8AgAAAACAAcA AAIAAFMAC/AeAAAAgAA04fgAvwEAABEA/wEAAAkAAQMAAAAAiAMAAAAAAAAQ8AgAAACAAUACQBRQ BA8AEfAQAAAAAADDCwgAAAAAAAAADQD4AA8ADfAMAAAAAACeDwQAAAAAAAAADwAE8HIAAAASAArw CAAAAAMABwAAAgAAUwAL8B4AAACAAJTh+AC/AQAAEQD/AQAACQABAwAAAACIAwAAAAAAABDwCAAA AOAEEAKgFOANDwAR8BAAAAAAAMMLCAAAAAEAAAAOAPgADwAN8AwAAAAAAJ4PBAAAAAEAAAAPAATw SAAAABIACvAIAAAAAQAHAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMBjp+LAJQB3r1oAL8BHgAf AP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAAwMDAAAEAAADAwMAAAQAAAJaWlgAAAAAA////AOrq 6gAPAO4DOh0AAAIA7wMYAAAAAQAAAA0OAAAAAAAACgAAgCIBAAAHAAAADwAMBOocAAAPAALw4hwA APAACPAIAAAAMgAAAG0QBwDAABjxMAAAAAEAAAACAAEAAwABAAQAAQAFAAEABgAAAAcABgAIAAYA CQAAAAoAAAALAAAADAAAAA8AA/BCHAAADwAE8CgAAAABAAnwEAAAAAAAAACeAAAAdwAAAAAAAAAC AArwCAAAAAAQBwAFAAAADwAE8HIAAAASAArwCAAAAAIQBwAAAgAAUwAL8B4AAACAAFTi+AC/AQAA EQD/AQAACQABAwAAAACIAwAAAAAAABDwCAAAAIABQAJAFFAEDwAR8BAAAAAAAMMLCAAAAAAAAAAN APgADwAN8AwAAAAAAJ4PBAAAAAAAAAAPAATwcgAAABIACvAIAAAAAxAHAAACAABTAAvwHgAAAIAA tOL4AL8BAAARAP8BAAAJAAEDAAAAAIgDAAAAAAAAEPAIAAAA4AQQAqAUEAgPABHwEAAAAAAAwwsI AAAAAQAAAA4A+AAPAA3wDAAAAAAAng8EAAAAAQAAAA8ABPCuAAAAAgAK8AgAAAAsEAcAAAoAANMA C/CGAAAABAAAAAAAQgGOAAAAQwFgAgAARAEEAAAARcEUAAAARsEeAAAAfwEBAAEAgAEAAAAAgQHg swAAgwH///8AvwEQABAA/wEQABgAiAMJAAAABQAFAPD/jgCNAI4AYAIAANMBAAAAAI4AjQAMABAA AgAAQACsAQAArAEAAKwBAACsAQAArAFgAIAAABDwCAAAAFAKkAbFBkkLDwAE8K4AAAACAArwCAAA AC0QBwAACgAA0wAL8IYAAAAEAAAAAABCAfwEAABDAY0AAABEAQQAAABFwRQAAABGwR4AAAB/AQEA AQCAAQAAAACBAZd5AACDAf///wC/ARAAEAD/ARAAGACIAwkAAAAFAAUA8P/8BI0AjgCNAAAAAABu BAAA/ASNAAwAEAACAABAAKwBAACsAQAArAEAAKwBAACsAWAAgAAAEPAIAAAAUAqQBnAIigoPAAPw DgIAAA8ABPBMAAAAAQAJ8BAAAAB1GgAAlSMAAHEfAAD1JQAAAgAK8AgAAAAGEAcAAQIAACMAC/AM AAAABAAAAAAAiAMJAAAAAAAQ8AgAAABQCiAKkAxJCw8ABPCwAAAAAgAK8AgAAAAHEAcAAgoAAMMA C/CAAAAAQgGOAAAAQwFgAgAARAEEAAAARcEUAAAARsEeAAAAfwEBAAEAgAEAAAAAgQHgswAAgwH/ //8AvwEQABAA/wEQABgAiAMAAAAABQAFAPD/jgCNAI4AYAIAANMBAAAAAI4AjQAMABAAAgAAQACs AQAArAEAAKwBAACsAQAArAFgAIAAAA/wEAAAAHUaAACVIwAAAxsAAPUlAAAPAATwsAAAAAIACvAI AAAACBAHAAIKAADDAAvwgAAAAEIB/AQAAEMBjQAAAEQBBAAAAEXBFAAAAEbBHgAAAH8BAQABAIAB AAAAAIEBl3kAAIMB////AL8BEAAQAP8BEAAYAIgDAAAAAAUABQDw//wEjQCOAI0AAAAAAG4EAAD8 BI0ADAAQAAIAAEAArAEAAKwBAACsAQAArAEAAKwBYACAAAAP8BAAAAB1GgAAlSMAAHEfAAAiJAAA DwAE8EIAAAASAArwCAAAAAkQBwACCgAAMwAL8BIAAACBAcOcAAC/ARAAEAD/AQAACAAAAA/wEAAA AAMbAAAiJAAAcR8AAPUlAAAPAATwswAAABIACvAIAAAAChAHAAAKAACjAAvwPAAAAIAAFOP4AIEA AAAAAIIAAAAAAIMAAAAAAIQAAAAAAIUAAgAAAL8AFgAXAL8BAAAQAP8BAAAIAIgDCQAAAAAAEPAI AAAAsAqwCsMLEAsPAA3wRwAAAAAAnw8EAAAABAAAAAAAqA8HAAAAUGF5bG9hZAAAoQ8kAAAACAAA AAAAAAAAAAcAAAABAAYAgQAKAP////4BAAAAAAACAAoADwAE8KYAAAASAArwCAAAAAsQBwAACgAA owAL8DwAAACAAHTj+ACBAAAAAACCAAAAAACDAAAAAACEAAAAAACFAAIAAAC/ABYAFwC/AQAAEAD/ AQAACACIAwkAAAAAABDwCAAAAOAKvwq/CkALDwAN8DoAAAAAAJ8PBAAAAAQAAAAAAKEPFAAAAAEA AAAAAAAAAAABAAAAAAACAAoAAACqDwoAAAABAAAAAQAAAAAADwAD8BgCAAAPAATwOAAAAAEACfAQ AAAAxQYAAPAJAABwCAAASQsAAAIACvAIAAAAahAHAAECAAAAABDwCAAAAPAJxQZwCEkLDwAE8EgA AAASAArwCAAAAC4QBwACCgAAQwAL8BgAAACBAcOcAAC/ARAAEAD/AQAACACIAwkAAAAAAA/wEAAA AMUGAACKCgAAcAgAAEkLAAAPAATwvAAAABIACvAIAAAALxAHAAIKAACjAAvwPAAAAIAA1OP4AIEA AAAAAIIAAAAAAIMAAAAAAIQAAAAAAIUAAgAAAL8AFgAXAL8BAAAQAP8BAAAIAIgDCQAAAAAAD/AQ AAAAIAcAALAKAAAUCAAAEAsAAA8ADfBIAAAAAACfDwQAAAAEAAAAAACoDwYAAABMZW5ndGgAAKEP JgAAAAcAAAAAAAAIAAABAAYAAAABAAYAgQAKAP////4BAAAAAAACAAoADwAE8LwAAAASAArwCAAA ADAQBwACCgAAowAL8DwAAACAADTk+ACBAAAAAACCAAAAAACDAAAAAACEAAAAAACFAAIAAAC/ABYA FwC/AQAAEAD/AQAACACIAwkAAAAAAA/wEAAAAPAGAADwCQAA3wcAAFAKAAAPAA3wSAAAAAAAnw8E AAAABAAAAAAAqA8GAAAAMSBCeXRlAAChDyYAAAAHAAAAAAAAAAAABgAAAAEABwCBAAIACgAAAAD+ AQAAAAAAAgAKAA8AA/AsAwAADwAE8EwAAAABAAnwEAAAAKYGAAC+BQAAcAgAAMAGAAACAArwCAAA ADEQBwABAgAAIwAL8AwAAAAEAAAAAACIAwkAAAAAABDwCAAAAFAKdAhUClILDwAD8BYCAAAPAATw VAAAAAEACfAQAAAAdRoAAJUjAABxHwAA9SUAAAIACvAIAAAAMhAHAAMCAAAjAAvwDAAAAAQAAAAA AIgDAAAAAAAAD/AQAAAApgYAAL4FAABwCAAAtwYAAA8ABPCwAAAAAgAK8AgAAAAzEAcAAgoAAMMA C/CAAAAAQgGOAAAAQwFgAgAARAEEAAAARcEUAAAARsEeAAAAfwEBAAEAgAEAAAAAgQHgswAAgwH/ //8AvwEQABAA/wEQABgAiAMAAAAABQAFAPD/jgCNAI4AYAIAANMBAAAAAI4AjQAMABAAAgAAQACs AQAArAEAAKwBAACsAQAArAFgAIAAAA/wEAAAAHUaAACVIwAAAxsAAPUlAAAPAATwsAAAAAIACvAI AAAANBAHAAIKAADDAAvwgAAAAEIB/AQAAEMBjQAAAEQBBAAAAEXBFAAAAEbBHgAAAH8BAQABAIAB AAAAAIEBl3kAAIMB////AL8BEAAQAP8BEAAYAIgDAAAAAAUABQDw//wEjQCOAI0AAAAAAG4EAAD8 BI0ADAAQAAIAAEAArAEAAKwBAACsAQAArAEAAKwBYACAAAAP8BAAAAB1GgAAlSMAAHEfAAAiJAAA DwAE8EIAAAASAArwCAAAADUQBwACCgAAMwAL8BIAAACBAcOcAAC/ARAAEAD/AQAACAAAAA/wEAAA AAMbAAAiJAAAcR8AAPUlAAAPAATwsgAAABIACvAIAAAANhAHAAIKAACTAAvwNgAAAIAA9OT4AIEA AAAAAIIAAAAAAIMAAAAAAIQAAAAAAIUAAgAAAL8AFgAXAL8BAAAQAP8BAAAIAAAAD/AQAAAAPgcA AAAGAABECAAAwAYAAA8ADfBEAAAAAACfDwQAAAAEAAAAAACoDwwAAABQYXlsb2FkDVR5cGUAAKEP HAAAAA0AAAAAAAAIAAABAA0AAAABAAYAgQAKAP////4PAATwtgAAABIACvAIAAAANxAHAAAKAACj AAvwPAAAAIAAtOX4AIEAAAAAAIIAAAAAAIMAAAAAAIQAAAAAAIUAAgAAAL8AFgAXAL8BAAAQAP8B AAAIAIgDCQAAAAAAEPAIAAAA8AnQCAYKUAoPAA3wSgAAAAAAnw8EAAAABAAAAAAAqA8IAAAAMS0y IEJ5dGUAAKEPJgAAAAkAAAAAAAAAAAAIAAAAAQAHAIEAAgAKAAAAAP4BAAAAAAACAAoADwAD8H0M AAAPAATwRgAAAAEACfAQAAAAcAUAAPAJAADjCwAAUgsAAAIACvAIAAAATRAHAAECAAATAAvwBgAA AIgDAAAAAAAAEPAIAAAA8AmQDJASUgsPAAPwFgIAAA8ABPBUAAAAAQAJ8BAAAAB1GgAAlSMAAHEf AAD1JQAAAgAK8AgAAABOEAcAAwIAACMAC/AMAAAABAAAAAAAiAMAAAAAAAAP8BAAAABwBQAAUAoA AFAHAABJCwAADwAE8LAAAAACAArwCAAAAE8QBwACCgAAwwAL8IAAAABCAY4AAABDAWACAABEAQQA AABFwRQAAABGwR4AAAB/AQEAAQCAAQAAAACBAeCzAACDAf///wC/ARAAEAD/ARAAGACIAwAAAAAF AAUA8P+OAI0AjgBgAgAA0wEAAAAAjgCNAAwAEAACAABAAKwBAACsAQAArAEAAKwBAACsAWAAgAAA D/AQAAAAdRoAAJUjAAADGwAA9SUAAA8ABPCwAAAAAgAK8AgAAABQEAcAAgoAAMMAC/CAAAAAQgH8 BAAAQwGNAAAARAEEAAAARcEUAAAARsEeAAAAfwEBAAEAgAEAAAAAgQGXeQAAgwH///8AvwEQABAA /wEQABgAiAMAAAAABQAFAPD//ASNAI4AjQAAAAAAbgQAAPwEjQAMABAAAgAAQACsAQAArAEAAKwB AACsAQAArAFgAIAAAA/wEAAAAHUaAACVIwAAcR8AACIkAAAPAATwQgAAABIACvAIAAAAURAHAAIK AAAzAAvwEgAAAIEBw5wAAL8BEAAQAP8BAAAIAAAAD/AQAAAAAxsAACIkAABxHwAA9SUAAA8AA/AJ CgAADwAE8E4AAAABAAnwEAAAANAFAADwCQAA4wsAAFILAAACAArwCAAAAFIQBwADAgAAEwAL8AYA AACIAwAAAAAAAA/wEAAAANAFAADwCQAA4wsAAFILAAAPAAPwFgIAAA8ABPBUAAAAAQAJ8BAAAAB1 GgAAlSMAAHEfAAD1JQAAAgAK8AgAAABTEAcAAwIAACMAC/AMAAAABAAAAAAAiAMAAAAAAAAP8BAA AAAACQAAUAoAAOMLAABJCwAADwAE8LAAAAACAArwCAAAAFQQBwACCgAAwwAL8IAAAABCAY4AAABD AWACAABEAQQAAABFwRQAAABGwR4AAAB/AQEAAQCAAQAAAACBAeCzAACDAf///wC/ARAAEAD/ARAA GACIAwAAAAAFAAUA8P+OAI0AjgBgAgAA0wEAAAAAjgCNAAwAEAACAABAAKwBAACsAQAArAEAAKwB AACsAWAAgAAAD/AQAAAAdRoAAJUjAAADGwAA9SUAAA8ABPCwAAAAAgAK8AgAAABVEAcAAgoAAMMA C/CAAAAAQgH8BAAAQwGNAAAARAEEAAAARcEUAAAARsEeAAAAfwEBAAEAgAEAAAAAgQGXeQAAgwH/ //8AvwEQABAA/wEQABgAiAMAAAAABQAFAPD//ASNAI4AjQAAAAAAbgQAAPwEjQAMABAAAgAAQACs AQAArAEAAKwBAACsAQAArAFgAIAAAA/wEAAAAHUaAACVIwAAcR8AACIkAAAPAATwQgAAABIACvAI AAAAVhAHAAIKAAAzAAvwEgAAAIEBw5wAAL8BEAAQAP8BAAAIAAAAD/AQAAAAAxsAACIkAABxHwAA 9SUAAA8ABPC1AAAAEgAK8AgAAABXEAcAAgoAAJMAC/A2AAAAgAAU5vgAgQAAAAAAggAAAAAAgwAA AAAAhAAAAAAAhQACAAAAvwAWABcAvwEAABAA/wEAAAgAAAAP8BAAAAAgCgAAsAoAAEcLAAAQCwAA DwAN8EcAAAAAAJ8PBAAAAAQAAAAAAKgPBwAAAFBheWxvYWQAAKEPJAAAAAgAAAAAAAAAAAAHAAAA AQAGAIEACgD////+AQAAAAAAAgAKAA8ABPCoAAAAEgAK8AgAAABYEAcAAgoAAJMAC/A2AAAAgAB0 5vgAgQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAhQACAAAAvwAWABcAvwEAABAA/wEAAAgAAAAP8BAA AACfCQAA4AoAAJ8JAABACwAADwAN8DoAAAAAAJ8PBAAAAAQAAAAAAKEPFAAAAAEAAAAAAAAAAAAB AAAAAAACAAoAAACqDwoAAAABAAAAAQAAAAAADwAE8KgAAAASAArwCAAAAFkQBwACCgAAkwAL8DYA AACAANTm+ACBAAAAAACCAAAAAACDAAAAAACEAAAAAACFAAIAAAC/ABYAFwC/AQAAEAD/AQAACAAA AA/wEAAAAPAJAADwCQAA8AkAAFAKAAAPAA3wOgAAAAAAnw8EAAAABAAAAAAAoQ8UAAAAAQAAAAAA AAAAAAEAAAAAAAIACgAAAKoPCgAAAAEAAAABAAAAAAAPAATwtgAAABIACvAIAAAAWhAHAAIKAACT AAvwNgAAAIAANOf4AIEAAAAAAIIAAAAAAIMAAAAAAIQAAAAAAIUAAgAAAL8AFgAXAL8BAAAQAP8B AAAIAAAAD/AQAAAA9gUAALAKAAD9BgAAEAsAAA8ADfBIAAAAAACfDwQAAAAEAAAAAACoDwYAAABM ZW5ndGgAAKEPJgAAAAcAAAAAAAAIAAABAAYAAAABAAYAgQAKAP////4BAAAAAAACAAoADwAE8LYA AAASAArwCAAAAFsQBwACCgAAkwAL8DYAAACAAJTn+ACBAAAAAACCAAAAAACDAAAAAACEAAAAAACF AAIAAAC/ABYAFwC/AQAAEAD/AQAACAAAAA/wEAAAANAFAADwCQAA0QYAAFAKAAAPAA3wSAAAAAAA nw8EAAAABAAAAAAAqA8GAAAAMSBCeXRlAAChDyYAAAAHAAAAAAAAAAAABgAAAAEABwCBAAIACgAA AAD+AQAAAAAAAgAKAA8AA/A0AwAADwAE8FQAAAABAAnwEAAAAKYGAAC+BQAAcAgAAMAGAAACAArw CAAAAFwQBwADAgAAIwAL8AwAAAAEAAAAAACIAwAAAAAAAA/wEAAAAFQHAABQCgAANAkAAFILAAAP AAPwFgIAAA8ABPBUAAAAAQAJ8BAAAAB1GgAAlSMAAHEfAAD1JQAAAgAK8AgAAABdEAcAAwIAACMA C/AMAAAABAAAAAAAiAMAAAAAAAAP8BAAAACmBgAAvgUAAHAIAAC3BgAADwAE8LAAAAACAArwCAAA AF4QBwACCgAAwwAL8IAAAABCAY4AAABDAWACAABEAQQAAABFwRQAAABGwR4AAAB/AQEAAQCAAQAA AACBAeCzAACDAf///wC/ARAAEAD/ARAAGACIAwAAAAAFAAUA8P+OAI0AjgBgAgAA0wEAAAAAjgCN AAwAEAACAABAAKwBAACsAQAArAEAAKwBAACsAWAAgAAAD/AQAAAAdRoAAJUjAAADGwAA9SUAAA8A BPCwAAAAAgAK8AgAAABfEAcAAgoAAMMAC/CAAAAAQgH8BAAAQwGNAAAARAEEAAAARcEUAAAARsEe AAAAfwEBAAEAgAEAAAAAgQGXeQAAgwH///8AvwEQABAA/wEQABgAiAMAAAAABQAFAPD//ASNAI4A jQAAAAAAbgQAAPwEjQAMABAAAgAAQACsAQAArAEAAKwBAACsAQAArAFgAIAAAA/wEAAAAHUaAACV IwAAcR8AACIkAAAPAATwQgAAABIACvAIAAAAYBAHAAIKAAAzAAvwEgAAAIEBw5wAAL8BEAAQAP8B AAAIAAAAD/AQAAAAAxsAACIkAABxHwAA9SUAAA8ABPCyAAAAEgAK8AgAAABhEAcAAgoAAJMAC/A2 AAAAgABU6PgAgQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAhQACAAAAvwAWABcAvwEAABAA/wEAAAgA AAAP8BAAAAA0BwAAAAYAAE8IAADABgAADwAN8EQAAAAAAJ8PBAAAAAQAAAAAAKgPDAAAAFBheWxv YWQNVHlwZQAAoQ8cAAAADQAAAAAAAAgAAAEADQAAAAEABgCBAAoA/////g8ABPC4AAAAEgAK8AgA AABiEAcAAgoAAJMAC/A2AAAAgAAU6fgAgQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAhQACAAAAvwAW ABcAvwEAABAA/wEAAAgAAAAP8BAAAACwBwAA8AkAAP0IAABQCgAADwAN8EoAAAAAAJ8PBAAAAAQA AAAAAKgPCAAAADAtMiBCeXRlAAChDyYAAAAJAAAAAAAAAAAACAAAAAEABwCBAAIACgAAAAD+AQAA AAAAAgAKAA8AA/AOAgAADwAE8EwAAAABAAnwEAAAAHUaAACVIwAAcR8AAPUlAAACAArwCAAAAGQQ BwABAgAAIwAL8AwAAAAEAAAAAACIAwsAAAAAABDwCAAAAFAK0AKqBkkLDwAE8LAAAAACAArwCAAA AGUQBwACCgAAwwAL8IAAAABCAY4AAABDAWACAABEAQQAAABFwRQAAABGwR4AAAB/AQEAAQCAAQAA AACBAeCzAACDAf///wC/ARAAEAD/ARAAGACIAwAAAAAFAAUA8P+OAI0AjgBgAgAA0wEAAAAAjgCN AAwAEAACAABAAKwBAACsAQAArAEAAKwBAACsAWAAgAAAD/AQAAAAdRoAAJUjAAADGwAA9SUAAA8A BPCwAAAAAgAK8AgAAABmEAcAAgoAAMMAC/CAAAAAQgH8BAAAQwGNAAAARAEEAAAARcEUAAAARsEe AAAAfwEBAAEAgAEAAAAAgQGXeQAAgwH///8AvwEQABAA/wEQABgAiAMAAAAABQAFAPD//ASNAI4A jQAAAAAAbgQAAPwEjQAMABAAAgAAQACsAQAArAEAAKwBAACsAQAArAFgAIAAAA/wEAAAAHUaAACV IwAAcR8AACIkAAAPAATwQgAAABIACvAIAAAAZxAHAAIKAAAzAAvwEgAAAIEBw5wAAL8BEAAQAP8B AAAIAAAAD/AQAAAAAxsAACIkAABxHwAA9SUAAA8ABPDAAAAAEgAK8AgAAABoEAcAAAoAAKMAC/A8 AAAAgADU6fgAgQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAhQACAAAAvwAWABcAvwEAABAA/wEAAAgA iAMMAAAAAAAQ8AgAAACACksDgwZACw8ADfBUAAAAAACfDwQAAAAEAAAAAACoDxwAAABQYXlsb2Fk IFR5cGUNTVVYRURfUFBQX0ZSQU1FAAChDxwAAAAdAAAAAAAACAAAAQAdAAAAAQAGAIEACgD////+ DwAE8LYAAAASAArwCAAAAGsQBwAACgAAowAL8DwAAACAAJTq+ACBAAAAAACCAAAAAACDAAAAAACE AAAAAACFAAIAAAC/ABYAFwC/AQAAEAD/AQAACACIAwwAAAAAABDwCAAAAPAJBwQ9BVAKDwAN8EoA AAAAAJ8PBAAAAAQAAAAAAKgPCAAAADEtMiBCeXRlAAChDyYAAAAJAAAAAAAAAAAACAAAAAEABwCB AAIACgAAAAD+AQAAAAAAAgAKAA8ABPBIAAAAEgAK8AgAAAABEAcAAAwAAIMAC/AwAAAAgQEAAAAI gwEFAAAIkwGOn4sAlAHevWgAvwEeAB8A/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAADAwMAAAQAA AMDAwAABAAAAlpaWAAAAAAD///8A6urqAA8A7gNcAwAAAgDvAxgAAAABAAAADQ4AAAAAAAAKAACA IwEAAAcAAAAPAAwEDAMAAA8AAvAEAwAAAAEI8AgAAAAEAAAABBgHAA8AA/CiAgAADwAE8CgAAAAB AAnwEAAAAAAAAACeAAAAdwAAAAAAAAACAArwCAAAAAAYBwAFAAAADwAE8HIAAAASAArwCAAAAAIY BwAAAgAAUwAL8B4AAACAANRf+QC/AQAAEQD/AQAACQABAwAAAACIAwAAAAAAABDwCAAAAGAA0ALQ FDADDwAR8BAAAAAAAMMLCAAAAAAAAAANAPkADwAN8AwAAAAAAJ4PBAAAAAAAAAAPAATwcgAAABIA CvAIAAAAAxgHAAACAABTAAvwHgAAAIAANGD5AL8BAAARAP8BAAAJAAEDAAAAAIgDAAAAAAAAEPAI AAAAQALgAXAUcAUPABHwEAAAAAAAwwsIAAAAAQAAAA4A+QAPAA3wDAAAAAAAng8EAAAAAQAAAA8A BPB2AQAAEgAK8AgAAAAEGAcAAAoAAKMAC/A8AAAAgACUYPkAvwACAAIAgQEEAAAIvwEIAB4AwAEB AAAI/wEEAA4APwIAAAMAvwIBAA8A/wIWAB8AfwMQAD8AAAAQ8AgAAADQCyABoBTwDw8ADfAKAQAA AACfDwQAAAAEAAAAAACoD9AAAABMMlRQSEMgZW5jYXBzdWxhdGlvbjoNMCAgIDEgICAyIDMgNCAg IDUgICA2ICAgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDgNKy0tLSstLS0rLSstKy0tLSstLS0rLS0t Ky0rLSstKy0rLSstKy0rLSstKy0rLSsNfFQ9MHxMPTB8eHx4fFM9MHxJPTB8Tz0wfFB8IFBQUCBw YWNrZXQuLi4gDSstLS0rLS0tKy0rLSstLS0rLS0tKy0tLSstKy0rLSstKy0rLSstKy0rLSstKy0r AAChDx4AAADRAAAAAAAAAAAAFgAAAAAAAAC7AAAAAAADAAMAFAAPAATwQgAAABIACvAIAAAAARgH AAAMAABzAAvwKgAAAIEBBgAACJMBjp+LAJQB3r1oAL8BHgAfAP8BAAAIAAQDCQAAAD8DAQABABAA 8AcgAAAAwMDAAAEAAADAwMAAAQAAAJaWlgAAAAAA////AOrq6gAPAO4DI3cAAAIA7wMYAAAAAQAA AA0OAAAAAAAACgAAgAAAAAAHAAAADwAMBNN2AAAPAALwy3YAABABCPAIAAAAnQAAAPQsBwBwABjx HAAAAAEAAAACAAAAAwACAAQAAAAFAAAABgAAAAcAAAAPAAPwP3YAAA8ABPAoAAAAAQAJ8BAAAAAA AAAAngAAAHcAAAAAAAAAAgAK8AgAAAAALAcABQAAAA8ABPDAAAAAEgAK8AgAAAACLAcAAAIAACMB C/BsAAAABAAAAAAAgAAUYvkAgQBmSwEAggCzpQAAgwBmSwEAhACzpQAAhQAAAAAAhgAAAAAAhwAA AAAAiAAAAAAAiQAAAAAAigAAAAAAiwAAAAAAvwAQAB8AvwEAAAEA/wEAAAkAAQMAAAAAiAMAAAAA AAAQ8AgAAADeAKQCRBXXAQ8AEfAQAAAAAADDCwgAAAAAAAAADQD5AA8ADfAMAAAAAACeDwQAAAAA AAAADwAE8M0AAAASAArwCAAAAAMsBwAACgAAowAL8DwAAACAAHRi+QCBAAAAAACCAAAAAACDAAAA AACEAAAAAACFAAIAAACKAAMsBwC/ABYAHwC/AQAAEAD/AQAACAAAABDwCAAAAMcKvwW/BXkLDwAN 8GEAAAAAAJ8PBAAAAAQAAAAAAKgPAQAAAA0AAKEPFAAAAAIAAAAAAAAAAAACAAAAAAACAAkAAACq DwoAAAACAAAAAQAAAAAAAACmDxYAAADxHgAAFgILAQsBFgIWAiIDIgMtBC0EDwAE8NcAAAASAArw CAAAAAQsBwAACgAAowAL8DwAAACAANRi+QCBAAAAAACCAAAAAACDAAAAAACEAAAAAACFAAIAAACK AAQsBwC/ABYAHwC/AQAAEAD/AQAACAAAABDwCAAAAMcKhAqECnkLDwAN8GsAAAAAAJ8PBAAAAAQA AAAAAKgPAQAAAA0AAKEPHgAAAAIAAAAAAAAIAAABAAIAAAABAAcAgQACAAkAAAAA/gAAqg8KAAAA AgAAAAEAAAAAAAAApg8WAAAA8R4AABYCCwELARYCFgIiAyIDLQQtBA8AA/C0PAAADwAE8DgAAAAB AAnwEAAAALECAACgAgAAcBQAAHUGAAACAArwCAAAAPQsBwABAgAAAAAQ8AgAAACwBEAC/xOFCA8A A/CJBQAADwAE8E4AAAABAAnwEAAAAHMIAACjAgAAuAkAAAYEAAACAArwCAAAAOAsBwADAgAAEwAL 8AYAAACIAwAAAAAAAA/wEAAAANALAACgAgAAFQ0AAAMEAAAPAAPwTwQAAA8ABPBUAAAAAQAJ8BAA AACmBgAAvgUAAHAIAAC3BgAAAgAK8AgAAADhLAcAAwIAACMAC/AMAAAABAAAAAAAiAMAAAAAAAAP 8BAAAABzCAAAHgMAALgJAAAGBAAADwAD8BIDAAAPAATwnAAAAAEACfAQAAAAdRoAAJUjAABxHwAA 9SUAAAIACvAIAAAA4iwHAAMCAADjAAvwVAAAAAQAAAAAAIEAAAAAAIIAAAAAAIMAAAAAAIQAAAAA AIUAAgAAAIYAAAAAAIcAAAAAAIgAAAAAAIkAAAAAAIoAAAAAAIsAAAAAAL8AFgAfAIgDAAAAAAAA D/AQAAAApgYAAL4FAABwCAAAtwYAAA8ABPD4AAAAAgAK8AgAAADjLAcAAgoAAIMBC/DIAAAAgQAA AAAAggAAAAAAgwAAAAAAhAAAAAAAhQACAAAAhgAAAAAAhwAAAAAAiAAAAAAAiQAAAAAAigAAAAAA iwAAAAAAvwAWAB8AQgGOAAAAQwFgAgAARAEEAAAARcEUAAAARsEeAAAAfwEBAAEAgAEAAAAAgQHg swAAgwH///8AvwEQABAA/wEQABgAiAMAAAAABQAFAPD/jgCNAI4AYAIAANMBAAAAAI4AjQAMABAA AgAAQACsAQAArAEAAKwBAACsAQAArAFgAIAAAA/wEAAAAHUaAACVIwAAAxsAAPUlAAAPAATw+AAA AAIACvAIAAAA5CwHAAIKAACDAQvwyAAAAIEAAAAAAIIAAAAAAIMAAAAAAIQAAAAAAIUAAgAAAIYA AAAAAIcAAAAAAIgAAAAAAIkAAAAAAIoAAAAAAIsAAAAAAL8AFgAfAEIB/AQAAEMBjQAAAEQBBAAA AEXBFAAAAEbBHgAAAH8BAQABAIABAAAAAIEBl3kAAIMB////AL8BEAAQAP8BEAAYAIgDAAAAAAUA BQDw//wEjQCOAI0AAAAAAG4EAAD8BI0ADAAQAAIAAEAArAEAAKwBAACsAQAArAEAAKwBYACAAAAP 8BAAAAB1GgAAlSMAAHEfAAAiJAAADwAE8GYAAAASAArwCAAAAOUsBwACCgAAkwAL8DYAAACBAAAA AACCAAAAAACDAAAAAACEAAAAAACFAAIAAAC/ABYAHwCBAcOcAAC/ARAAEAD/AQAACAAAAA/wEAAA AAMbAAAiJAAAcR8AAPUlAAAPAATw0QAAABIACvAIAAAA5iwHAAIKAACTAAvwNgAAAIAANGP5AIEA AAAAAIIAAAAAAIMAAAAAAIQAAAAAAIUAAgAAAL8AFgAfAL8BAAAQAP8BAAAIAAAAD/AQAAAAZAcA AP8FAAAeCAAAXAYAAA8ADfBjAAAAAACfDwQAAAAEAAAAAACoDwMAAABQUFAAAKEPJgAAAAQAAAAA AAAIAAABAAMAAAABAAYAgQAJAP////4BAAAAAAACAAkAAACmDxYAAADxHgAAFgILAQsBFgIWAiID IgMtBC0EDwAE8NQAAAASAArwCAAAAOcsBwACCgAAkwAL8DYAAACAAJRj+QCBAAAAAACCAAAAAACD AAAAAACEAAAAAACFAAIAAAC/ABYAHwC/AQAAEAD/AQAACAAAAA/wEAAAAJgIAACjAgAAcAkAAPkC AAAPAA3wZgAAAAAAnw8EAAAABAAAAAAAqA8GAAAAMSBCeXRlAAChDyYAAAAHAAAAAAAAAAAABgAA AAEABwCBAAIACQAAAAD+AQAAAAAAAgAJAAAApg8WAAAA8R4AABYCCwELARYCFgIiAyIDLQQtBA8A BPCiAAAAQgEK8AgAAAB0LAcAQgoAADMBC/ByAAAAgQB4YQEAggCirQAAgwB4YQEAhACirQAAhwAB AAAAvwACAA8ARAEEAAAAfwEAAAEAvwEAABAAwAEBAAAIywGcMQAA0gEAAAAA0wEAAAAA1AEAAAAA 1QEAAAAA/wEeAB4AAQIBAAAIPwIAAAMAfwMAAA8AAAAP8BAAAADKEgAAIAQAAEAUAAASBQAADwAE 8EYBAACiDArwCAAAAE8sBwACCgAAUwEL8H4AAACAAPRj+QCBAPNHAQCCABmhAACDAPNHAQCEABmh AACFAAIAAACHAAYAAAC/ABIAHwCBAQQAAAiDAQAAAAi/AQwAHgDAAQEAAAjLAZwxAADSAQAAAADT AQAAAADUAQAAAADVAQAAAAD/AQYADgABAgEAAAg/AgAAAwB/AwAADwAAAA/wEAAAALECAADEBQAA mA8AAHUGAAAPAA3wkAAAAAAAnw8EAAAABAAAAAAAqA8+AAAAVk9JUCBHLjcyOUEsIEFBTC01LCBJ UCwgVHVubmVsZWQgQ1JUUCwgMSBBdWRpbyBTYW1wbGUgLyAxIENlbGwAAKEPGAAAAD8AAAAAAAAA AAA/AAAAAQADAIEAAgANAAAApg8WAAAA8R4AABYCCwELARYCFgIiAyIDLQQtBA8ABPCiAAAAQgEK 8AgAAABQLAcAAgoAADMBC/ByAAAAgQB4YQEAggCirQAAgwB4YQEAhACirQAAhwABAAAAvwACAA8A RAEEAAAAfwEAAAEAvwEAABAAwAEBAAAIywGcMQAA0gEAAAAA0wEAAAAA1AEAAAAA1QEAAAAA/wEe AB4AAQIBAAAIPwIAAAMAfwMAAA8AAAAP8BAAAADXBAAABgQAAJ4GAADZBAAADwAD8M0JAAAPAATw VAAAAAEACfAQAAAAaAQAAFYOAABQEAAAqw8AAAIACvAIAAAAUSwHAAMCAAAjAAvwDAAAAAQAAAAA AIgDAAAAAAAAD/AQAAAAsQIAAIAEAAA0EwAAxAUAAA8AA/CTBAAADwAE8JYAAAABAAnwEAAAADcH AAC3DgAAUBAAAKoPAAACAArwCAAAAFIsBwADAgAA0wAL8E4AAACBAAAAAACCAAAAAACDAAAAAACE AAAAAACFAAIAAACGAAAAAACHAAAAAACIAAAAAACJAAAAAACKAAAAAACLAAAAAAC/ABYAHwCIAwAA AAAAAA/wEAAAADcHAAC3DgAAUBAAAKoPAAAPAAPwEgMAAA8ABPCcAAAAAQAJ8BAAAACSHQAACyoA AIYnAABqLAAAAgAK8AgAAABTLAcAAwIAAOMAC/BUAAAABAAAAAAAgQAAAAAAggAAAAAAgwAAAAAA hAAAAAAAhQACAAAAhgAAAAAAhwAAAAAAiAAAAAAAiQAAAAAAigAAAAAAiwAAAAAAvwAWAB8AiAMA AAAAAAAP8BAAAAA3BwAAtw4AAFAQAACqDwAADwAE8PgAAAACAArwCAAAAFQsBwACCgAAgwEL8MgA AACBAAAAAACCAAAAAACDAAAAAACEAAAAAACFAAIAAACGAAAAAACHAAAAAACIAAAAAACJAAAAAACK AAAAAACLAAAAAAC/ABYAHwBCAY0AAABDAV8CAABEAQQAAABFwRQAAABGwR4AAAB/AQEAAQCAAQAA AACBAeAsAACDAf///wC/ARAAEAD/ARAAGACIAwAAAAAFAAUA8P+NAI0AjQBfAgAA0wEAAAAAjQCN AAwAEAACAABAAKwBAACsAQAArAEAAKwBAACsAWAAgAAAD/AQAAAAkh0AAAsqAAAfHgAAaiwAAA8A BPD4AAAAAgAK8AgAAABVLAcAAgoAAIMBC/DIAAAAgQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAhQAC AAAAhgAAAAAAhwAAAAAAiAAAAAAAiQAAAAAAigAAAAAAiwAAAAAAvwAWAB8AQgH0CQAAQwGNAAAA RAEEAAAARcEUAAAARsEeAAAAfwEBAAEAgAEAAAAAgQGXHgAAgwH///8AvwEQABAA/wEQABgAiAMA AAAABQAFAPD/9AmNAI0AjQAAAAAAZgkAAPQJjQAMABAAAgAAQACsAQAArAEAAKwBAACsAQAArAFg AIAAAA/wEAAAAJIdAAALKgAAhicAAJgqAAAPAATwZgAAABIACvAIAAAAViwHAAIKAACTAAvwNgAA AIEAAAAAAIIAAAAAAIMAAAAAAIQAAAAAAIUAAgAAAL8AFgAfAIEBwycAAL8BEAAQAP8BAAAIAAAA D/AQAAAAHx4AAJgqAACGJwAAaiwAAA8ABPDTAAAAEgAK8AgAAABXLAcAAgoAAJMAC/A2AAAAgABU ZPkAgQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAhQACAAAAvwAWAB8AvwEAABAA/wEAAAgAAAAP8BAA AADGCAAAIg8AAHgJAAB9DwAADwAN8GUAAAAAAJ8PBAAAAAQAAAAAAKgPBwAAAFBheWxvYWQAAKEP JAAAAAgAAAAAAAAAAAAHAAAAAQAGAIEACQD////+AQAAAAAAAgAJAAAApg8WAAAA8R4AABYCCwEL ARYCFgIiAyIDLQQtBA8AA/ASAwAADwAE8JwAAAABAAnwEAAAAIwWAAALKgAA4R0AAGwsAAACAArw CAAAAFgsBwADAgAA4wAL8FQAAAAEAAAAAACBAAAAAACCAAAAAACDAAAAAACEAAAAAACFAAIAAACG AAAAAACHAAAAAACIAAAAAACJAAAAAACKAAAAAACLAAAAAAC/ABYAHwCIAwAAAAAAAA/wEAAAAGgE AAC3DgAAVwcAAKsPAAAPAATw+AAAAAIACvAIAAAAWSwHAAIKAACDAQvwyAAAAIEAAAAAAIIAAAAA AIMAAAAAAIQAAAAAAIUAAgAAAIYAAAAAAIcAAAAAAIgAAAAAAIkAAAAAAIoAAAAAAIsAAAAAAL8A FgAfAEIBjgAAAEMBYQIAAEQBBAAAAEXBFAAAAEbBHgAAAH8BAQABAIABAAAAAIEBFWlvAIMB//// AL8BEAAQAP8BEAAYAIgDAAAAAAUABQDw/44AjQCOAGECAADUAQAAAACOAI0ADAAQAAIAAEAArAEA AKwBAACsAQAArAEAAKwBYACAAAAP8BAAAACMFgAACyoAABoXAABsLAAADwAE8PgAAAACAArwCAAA AFosBwACCgAAgwEL8MgAAACBAAAAAACCAAAAAACDAAAAAACEAAAAAACFAAIAAACGAAAAAACHAAAA AACIAAAAAACJAAAAAACKAAAAAACLAAAAAAC/ABYAHwBCAVUHAABDAY0AAABEAQQAAABFwRQAAABG wR4AAAB/AQEAAQCAAQAAAACBAQ5HSwCDAf///wC/ARAAEAD/ARAAGACIAwAAAAAFAAUA8P9VB40A jgCNAAAAAADHBgAAVQeNAAwAEAACAABAAKwBAACsAQAArAEAAKwBAACsAWAAgAAAD/AQAAAAjBYA AAsqAADhHQAAmCoAAA8ABPBmAAAAEgAK8AgAAABbLAcAAgoAAJMAC/A2AAAAgQAAAAAAggAAAAAA gwAAAAAAhAAAAAAAhQACAAAAvwAWAB8AgQETW2EAvwEQABAA/wEAAAgAAAAP8BAAAAAaFwAAmCoA AOEdAABsLAAADwAE8NcAAAASAArwCAAAAFwsBwACCgAAkwAL8DYAAACAABRl+QCBAAAAAACCAAAA AACDAAAAAACEAAAAAACFAAIAAAC/ABYAHwC/AQAAEAD/AQAACAAAAA/wEAAAAC4FAAAhDwAAOQYA AHwPAAAPAA3waQAAAAAAnw8EAAAABAAAAAAAqA8LAAAAQ2VsbCBIZWFkZXIAAKEPJAAAAAwAAAAA AAAAAAALAAAAAQAGAIEACQD////+AQAAAAAAAgAJAAAApg8WAAAA8R4AABYCCwELARYCFgIiAyID LQQtBA8ABPDVAAAAEgAK8AgAAABdLAcAAgoAAJMAC/A2AAAAgAB0ZfkAgQAAAAAAggAAAAAAgwAA AAAAhAAAAAAAhQACAAAAvwAWAB8AvwEAABAA/wEAAAgAAAAP8BAAAABcBQAAVg4AABQGAACxDgAA DwAN8GcAAAAAAJ8PBAAAAAQAAAAAAKgPBwAAADUgQnl0ZXMAAKEPJgAAAAgAAAAAAAAAAAAHAAAA AQAHAIEAAgAJAAAAAP4BAAAAAAACAAkAAACmDxYAAADxHgAAFgILAQsBFgIWAiIDIgMtBC0EDwAD 8BIDAAAPAATwnAAAAAEACfAQAAAAdRoAAJUjAABxHwAA9SUAAAIACvAIAAAAXywHAAMCAADjAAvw VAAAAAQAAAAAAIEAAAAAAIIAAAAAAIMAAAAAAIQAAAAAAIUAAgAAAIYAAAAAAIcAAAAAAIgAAAAA AIkAAAAAAIoAAAAAAIsAAAAAAL8AFgAfAIgDBAAAAAAAD/AQAAAAwBIAADADAABwFAAAFwQAAA8A BPD4AAAAAgAK8AgAAABgLAcAAgoAAIMBC/DIAAAAgQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAhQAC AAAAhgAAAAAAhwAAAAAAiAAAAAAAiQAAAAAAigAAAAAAiwAAAAAAvwAWAB8AQgGOAAAAQwFgAgAA RAEEAAAARcEUAAAARsEeAAAAfwEBAAEAgAEAAAAAgQHgswAAgwH///8AvwEQABAA/wEQABgAiAMA AAAABQAFAPD/jgCNAI4AYAIAANMBAAAAAI4AjQAMABAAAgAAQACsAQAArAEAAKwBAACsAQAArAFg AIAAAA/wEAAAAHUaAACVIwAAAxsAAPUlAAAPAATw+AAAAAIACvAIAAAAYSwHAAIKAACDAQvwyAAA AIEAAAAAAIIAAAAAAIMAAAAAAIQAAAAAAIUAAgAAAIYAAAAAAIcAAAAAAIgAAAAAAIkAAAAAAIoA AAAAAIsAAAAAAL8AFgAfAEIB/AQAAEMBjQAAAEQBBAAAAEXBFAAAAEbBHgAAAH8BAQABAIABAAAA AIEBl3kAAIMB////AL8BEAAQAP8BEAAYAIgDAAAAAAUABQDw//wEjQCOAI0AAAAAAG4EAAD8BI0A DAAQAAIAAEAArAEAAKwBAACsAQAArAEAAKwBYACAAAAP8BAAAAB1GgAAlSMAAHEfAAAiJAAADwAE 8GYAAAASAArwCAAAAGIsBwACCgAAkwAL8DYAAACBAAAAAACCAAAAAACDAAAAAACEAAAAAACFAAIA AAC/ABYAHwCBAcOcAAC/ARAAEAD/AQAACAAAAA/wEAAAAAMbAAAiJAAAcR8AAPUlAAAPAAPw4gIA AA8ABPBAAAAAAQAJ8BAAAADBEQAAnQIAAO8SAAAABAAAAgAK8AgAAADQLAcAAwIAAAAAD/AQAAAA IBMAAKACAABOFAAAAwQAAA8ABPDhAAAAEgAK8AgAAABjLAcAAgoAAKMAC/A8AAAAgAA0ZvkAgQAA AAAAggAAAAAAgwAAAAAAhAAAAAAAhQACAAAAvwAWAB8AvwEAABAA/wEAAAgAiAMEAAAAAAAP8BAA AADvEQAAUgMAAMsSAAD+AwAADwAN8G0AAAAAAJ8PBAAAAAQAAAAAAKgPDQAAAEFBTC01DVRyYWls ZXIAAKEPJgAAAA4AAAAAAAAIAAABAA0AAAABAAYAgQAJAP////4BAAAAAAACAAkAAACmDxYAAADx HgAAFgILAQsBFgIWAiIDIgMtBC0EDwAE8MwAAAASAArwCAAAAGQsBwACCgAAowAL8DwAAACAAJRm +QCBAAAAAACCAAAAAACDAAAAAACEAAAAAACFAAIAAAC/ABYAHwC/AQAAEAD/AQAACACIAwQAAAAA AA/wEAAAAMERAACqAwAAwREAAAAEAAAPAA3wWAAAAAAAnw8EAAAABAAAAAAAoQ8UAAAAAQAAAAAA AAAAAAEAAAAAAAIACQAAAKoPCgAAAAEAAAABAAAAAAAAAKYPFgAAAPEeAAAWAgsBCwEWAhYCIgMi Ay0ELQQPAATw1QAAABIACvAIAAAAZSwHAAIKAACTAAvwNgAAAIAA9Gb5AIEAAAAAAIIAAAAAAIMA AAAAAIQAAAAAAIUAAgAAAL8AFgAfAL8BAAAQAP8BAAAIAAAAD/AQAAAA7xEAAJ0CAADvEgAA8wIA AA8ADfBnAAAAAACfDwQAAAAEAAAAAACoDwcAAAA4IEJ5dGVzAAChDyYAAAAIAAAAAAAAAAAABwAA AAEABwCBAAIACQAAAAD+AQAAAAAAAgAJAAAApg8WAAAA8R4AABYCCwELARYCFgIiAyIDLQQtBA8A A/BJBAAADwAE8FQAAAABAAnwEAAAAPgNAAC+BQAAGBAAALcGAAACAArwCAAAAGYsBwADAgAAIwAL 8AwAAAAEAAAAAACIAwAAAAAAAA/wEAAAAOAQAAAwAwAA2RIAABcEAAAPAAPwDAMAAA8ABPCcAAAA AQAJ8BAAAADrKwAAkiMAAJovAADyJQAAAgAK8AgAAABnLAcAAwIAAOMAC/BUAAAABAAAAAAAgQAA AAAAggAAAAAAgwAAAAAAhAAAAAAAhQAAAAAAhgAAAAAAhwAAAAAAiAAAAAAAiQAAAAAAigAAAAAA iwAAAAAAvwAWAB8AiAMAAAAAAAAP8BAAAAD4DQAAvgUAABgQAAC3BgAADwAE8PgAAAACAArwCAAA AGgsBwACCgAAgwEL8MgAAACBAAAAAACCAAAAAACDAAAAAACEAAAAAACFAAAAAACGAAAAAACHAAAA AACIAAAAAACJAAAAAACKAAAAAACLAAAAAAC/ABYAHwBCAY4AAABDAWACAABEAQQAAABFwRQAAABG wR4AAAB/AQEAAQCAAQAAAACBAeCzAACDAf///wC/ARAAEAD/ARAAGACIAwAAAAAFAAUA8P+OAI0A jgBgAgAA0wEAAAAAjgCNAAwAEAACAABAAKwBAACsAQAArAEAAKwBAACsAWAAgAAAD/AQAAAA6ysA AJIjAAB5LAAA8iUAAA8ABPD4AAAAAgAK8AgAAABpLAcAAgoAAIMBC/DIAAAAgQAAAAAAggAAAAAA gwAAAAAAhAAAAAAAhQAAAAAAhgAAAAAAhwAAAAAAiAAAAAAAiQAAAAAAigAAAAAAiwAAAAAAvwAW AB8AQgGvAwAAQwGNAAAARAEEAAAARcEUAAAARsEeAAAAfwEBAAEAgAEAAAAAgQGXeQAAgwH///8A vwEQABAA/wEQABgAiAMAAAAABQAFAPD/rwONAI4AjQAAAAAAIQMAAK8DjQAMABAAAgAAQACsAQAA rAEAAKwBAACsAQAArAFgAIAAAA/wEAAAAOsrAACSIwAAmi8AAB8kAAAPAATwYAAAABIACvAIAAAA aiwHAAIKAACDAAvwMAAAAIEAAAAAAIIAAAAAAIMAAAAAAIQAAAAAAL8AFgAfAIEBw5wAAL8BEAAQ AP8BAAAIAAAAD/AQAAAAeSwAAB8kAACaLwAA8iUAAA8ABPDRAAAAEgAK8AgAAABrLAcAAgoAAIMA C/AwAAAAgAC0Z/kAgQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAvwAWAB8AvwEAABAA/wEAAAgAAAAP 8BAAAACDDgAA8AUAANcPAACpBgAADwAN8GkAAAAAAJ8PBAAAAAQAAAAAAKgPCQAAAFBBRA1BQUwt NQAAoQ8mAAAACgAAAAAAAAgAAAEACQAAAAEABgCBAAkA/////gEAAAAAAAIACQAAAKYPFgAAAPEe AAAWAgsBCwEWAhYCIgMiAy0ELQQPAAPwEgMAAA8ABPCcAAAAAQAJ8BAAAADXIwAAlSMAADcsAAD1 JQAAAgAK8AgAAAB3LAcAAwIAAOMAC/BUAAAABAAAAAAAgQAAAAAAggAAAAAAgwAAAAAAhAAAAAAA hQACAAAAhgAAAAAAhwAAAAAAiAAAAAAAiQAAAAAAigAAAAAAiwAAAAAAvwAWAB8AiAMHAAAAAAAP 8BAAAACxDgAAJQMAAA0RAAAMBAAADwAE8PgAAAACAArwCAAAAHgsBwACCgAAgwEL8MgAAACBAAAA AACCAAAAAACDAAAAAACEAAAAAACFAAIAAACGAAAAAACHAAAAAACIAAAAAACJAAAAAACKAAAAAACL AAAAAAC/ABYAHwBCAY4AAABDAWACAABEAQQAAABFwRQAAABGwR4AAAB/AQEAAQCAAQAAAACBAeCz AACDAf///wC/ARAAEAD/ARAAGACIAwAAAAAFAAUA8P+OAI0AjgBgAgAA0wEAAAAAjgCNAAwAEAAC AABAAKwBAACsAQAArAEAAKwBAACsAWAAgAAAD/AQAAAA1yMAAJUjAABlJAAA9SUAAA8ABPD4AAAA AgAK8AgAAAB5LAcAAgoAAIMBC/DIAAAAgQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAhQACAAAAhgAA AAAAhwAAAAAAiAAAAAAAiQAAAAAAigAAAAAAiwAAAAAAvwAWAB8AQgFgCAAAQwGNAAAARAEEAAAA RcEUAAAARsEeAAAAfwEBAAEAgAEAAAAAgQGXeQAAgwH///8AvwEQABAA/wEQABgAiAMAAAAABQAF APD/YAiNAI4AjQAAAAAA0gcAAGAIjQAMABAAAgAAQACsAQAArAEAAKwBAACsAQAArAFgAIAAAA/w EAAAANcjAACVIwAANywAACIkAAAPAATwZgAAABIACvAIAAAAeiwHAAIKAACTAAvwNgAAAIEAAAAA AIIAAAAAAIMAAAAAAIQAAAAAAIUAAgAAAL8AFgAfAIEBw5wAAL8BEAAQAP8BAAAIAAAAD/AQAAAA ZSQAACIkAAA3LAAA9SUAAA8ABPDfAAAAEgAK8AgAAAB7LAcAAgoAAKMAC/A8AAAAgAB0aPkAgQAA AAAAggAAAAAAgwAAAAAAhAAAAAAAhQACAAAAvwAWAB8AvwEAABAA/wEAAAgAiAMHAAAAAAAP8BAA AAAtDwAAagMAAOMQAADAAwAADwAN8GsAAAAAAJ8PBAAAAAQAAAAAAKgPDQAAAFZvaWNlIFBheWxv YWQAAKEPJAAAAA4AAAAAAAAAAAANAAAAAQAGAIEACQD////+AQAAAAAAAgAJAAAApg8WAAAA8R4A ABYCCwELARYCFgIiAyIDLQQtBA8ABPDcAAAAEgAK8AgAAAB8LAcAAgoAAKMAC/A8AAAAgAA0afkA gQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAhQACAAAAvwAWAB8AvwEAABAA/wEAAAgAiAMHAAAAAAAP 8BAAAAAKDwAAoAIAACoQAAD2AgAADwAN8GgAAAAAAJ8PBAAAAAQAAAAAAKgPCAAAADEwIGJ5dGVz AAChDyYAAAAJAAAAAAAAAAAACAAAAAEABwCBAAIACQAAAAD+AQAAAAAAAgAJAAAApg8WAAAA8R4A ABYCCwELARYCFgIiAyIDLQQtBA8AA/DLBQAADwAE8EAAAAABAAnwEAAAACANAACgAgAA3Q4AAAwE AAACAArwCAAAAOgsBwADAgAAAAAP8BAAAAAgDQAAoAIAAN0OAAAMBAAADwAD8JgEAAAPAATwnAAA AAEACfAQAAAApgYAAL4FAABwCAAAtwYAAAIACvAIAAAAfSwHAAMCAADjAAvwVAAAAAQAAAAAAIEA AAAAAIIAAAAAAIMAAAAAAIQAAAAAAIUAAgAAAIYAAAAAAIcAAAAAAIgAAAAAAIkAAAAAAIoAAAAA AIsAAAAAAL8AFgAfAIgDBwAAAAAAD/AQAAAAIA0AACUDAADdDgAADAQAAA8AA/ASAwAADwAE8JwA AAABAAnwEAAAAHUaAACVIwAAcR8AAPUlAAACAArwCAAAAH4sBwADAgAA4wAL8FQAAAAEAAAAAACB AAAAAACCAAAAAACDAAAAAACEAAAAAACFAAIAAACGAAAAAACHAAAAAACIAAAAAACJAAAAAACKAAAA AACLAAAAAAC/ABYAHwCIAwAAAAAAAA/wEAAAAKYGAAC+BQAAcAgAALcGAAAPAATw+AAAAAIACvAI AAAAfywHAAIKAACDAQvwyAAAAIEAAAAAAIIAAAAAAIMAAAAAAIQAAAAAAIUAAgAAAIYAAAAAAIcA AAAAAIgAAAAAAIkAAAAAAIoAAAAAAIsAAAAAAL8AFgAfAEIBjgAAAEMBYAIAAEQBBAAAAEXBFAAA AEbBHgAAAH8BAQABAIABAAAAAIEB4LMAAIMB////AL8BEAAQAP8BEAAYAIgDAAAAAAUABQDw/44A jQCOAGACAADTAQAAAACOAI0ADAAQAAIAAEAArAEAAKwBAACsAQAArAEAAKwBYACAAAAP8BAAAAB1 GgAAlSMAAAMbAAD1JQAADwAE8PgAAAACAArwCAAAAIAsBwACCgAAgwEL8MgAAACBAAAAAACCAAAA AACDAAAAAACEAAAAAACFAAIAAACGAAAAAACHAAAAAACIAAAAAACJAAAAAACKAAAAAACLAAAAAAC/ ABYAHwBCAfwEAABDAY0AAABEAQQAAABFwRQAAABGwR4AAAB/AQEAAQCAAQAAAACBAZd5AACDAf// /wC/ARAAEAD/ARAAGACIAwAAAAAFAAUA8P/8BI0AjgCNAAAAAABuBAAA/ASNAAwAEAACAABAAKwB AACsAQAArAEAAKwBAACsAWAAgAAAD/AQAAAAdRoAAJUjAABxHwAAIiQAAA8ABPBmAAAAEgAK8AgA AACBLAcAAgoAAJMAC/A2AAAAgQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAhQACAAAAvwAWAB8AgQHD nAAAvwEQABAA/wEAAAgAAAAP8BAAAAADGwAAIiQAAHEfAAD1JQAADwAE8NIAAAASAArwCAAAAIIs BwACCgAAkwAL8DYAAACAAJRp+QCBAAAAAACCAAAAAACDAAAAAACEAAAAAACFAAIAAAC/ABYAHwC/ AQAAEAD/AQAACAAAAA/wEAAAAFsHAAAABgAAJQgAAFwGAAAPAA3wZAAAAAAAnw8EAAAABAAAAAAA qA8EAAAAQ1JUUAAAoQ8mAAAABQAAAAAAAAgAAAEABAAAAAEABgCBAAkA/////gEAAAAAAAIACQAA AKYPFgAAAPEeAAAWAgsBCwEWAhYCIgMiAy0ELQQPAATw2wAAABIACvAIAAAAgywHAAIKAACjAAvw PAAAAIAA9Gn5AIEAAAAAAIIAAAAAAIMAAAAAAIQAAAAAAIUAAgAAAL8AFgAfAL8BAAAQAP8BAAAI AIgDBwAAAAAAD/AQAAAATQ0AAKACAABNDgAA9gIAAA8ADfBnAAAAAACfDwQAAAAEAAAAAACoDwcA AAAyIEJ5dGVzAAChDyYAAAAIAAAAAAAAAAAABwAAAAEABwCBAAIACQAAAAD+AQAAAAAAAgAJAAAA pg8WAAAA8R4AABYCCwELARYCFgIiAyIDLQQtBA8AA/BXFQAADwAE8EAAAAABAAnwEAAAAJADAACg AgAAdgsAAAgEAAACAArwCAAAAOksBwADAgAAAAAP8BAAAADwAwAAoAIAANYLAAAIBAAADwAD8DIF AAAPAATwVAAAAAEACfAQAAAAsgcAAJ0CAABwCQAAAgQAAAIACvAIAAAA1iwHAAMCAAAjAAvwDAAA AAQAAAAAAIgDBgAAAAAAD/AQAAAAugYAAKACAAB4CAAABQQAAA8AA/ASAwAADwAE8JwAAAABAAnw EAAAAHUaAACVIwAAcR8AAPUlAAACAArwCAAAAIUsBwADAgAA4wAL8FQAAAAEAAAAAACBAAAAAACC AAAAAACDAAAAAACEAAAAAACFAAIAAACGAAAAAACHAAAAAACIAAAAAACJAAAAAACKAAAAAACLAAAA AAC/ABYAHwCIAwEAAAAAAA/wEAAAALIHAAAbAwAAcAkAAAIEAAAPAATw+AAAAAIACvAIAAAAhiwH AAIKAACDAQvwyAAAAIEAAAAAAIIAAAAAAIMAAAAAAIQAAAAAAIUAAgAAAIYAAAAAAIcAAAAAAIgA AAAAAIkAAAAAAIoAAAAAAIsAAAAAAL8AFgAfAEIBjgAAAEMBYAIAAEQBBAAAAEXBFAAAAEbBHgAA AH8BAQABAIABAAAAAIEB4LMAAIMB////AL8BEAAQAP8BEAAYAIgDAAAAAAUABQDw/44AjQCOAGAC AADTAQAAAACOAI0ADAAQAAIAAEAArAEAAKwBAACsAQAArAEAAKwBYACAAAAP8BAAAAB1GgAAlSMA AAMbAAD1JQAADwAE8PgAAAACAArwCAAAAIcsBwACCgAAgwEL8MgAAACBAAAAAACCAAAAAACDAAAA AACEAAAAAACFAAIAAACGAAAAAACHAAAAAACIAAAAAACJAAAAAACKAAAAAACLAAAAAAC/ABYAHwBC AfwEAABDAY0AAABEAQQAAABFwRQAAABGwR4AAAB/AQEAAQCAAQAAAACBAZd5AACDAf///wC/ARAA EAD/ARAAGACIAwAAAAAFAAUA8P/8BI0AjgCNAAAAAABuBAAA/ASNAAwAEAACAABAAKwBAACsAQAA rAEAAKwBAACsAWAAgAAAD/AQAAAAdRoAAJUjAABxHwAAIiQAAA8ABPBmAAAAEgAK8AgAAACILAcA AgoAAJMAC/A2AAAAgQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAhQACAAAAvwAWAB8AgQHDnAAAvwEQ ABAA/wEAAAgAAAAP8BAAAAADGwAAIiQAAHEfAAD1JQAADwAE8NgAAAASAArwCAAAAIksBwACCgAA owAL8DwAAACAAFRq+QCBAAAAAACCAAAAAACDAAAAAACEAAAAAACFAAIAAAC/ABYAHwC/AQAAEAD/ AQAACACIAwEAAAAAAA/wEAAAAG4IAABYAwAAHgkAAK4DAAAPAA3wZAAAAAAAnw8EAAAABAAAAAAA qA8EAAAATDJUUAAAoQ8mAAAABQAAAAAAAAgAAAEABAAAAAEABgCBAAkA/////gEAAAAAAAIACQAA AKYPFgAAAPEeAAAWAgsBCwEWAhYCIgMiAy0ELQQPAATw1AAAABIACvAIAAAAiiwHAAIKAACTAAvw NgAAAIAAtGr5AIEAAAAAAIIAAAAAAIMAAAAAAIQAAAAAAIUAAgAAAL8AFgAfAL8BAAAQAP8BAAAI AAAAD/AQAAAA8gcAAJ0CAADKCAAA8wIAAA8ADfBmAAAAAACfDwQAAAAEAAAAAACoDwYAAAAxIEJ5 dGUAAKEPJgAAAAcAAAAAAAAAAAAGAAAAAQAHAIEAAgAJAAAAAP4BAAAAAAACAAkAAACmDxYAAADx HgAAFgILAQsBFgIWAiIDIgMtBC0EDwAD8BIDAAAPAATwnAAAAAEACfAQAAAAdRoAAJUjAABxHwAA 9SUAAAIACvAIAAAAbiwHAAMCAADjAAvwVAAAAAQAAAAAAIEAAAAAAIIAAAAAAIMAAAAAAIQAAAAA AIUAAgAAAIYAAAAAAIcAAAAAAIgAAAAAAIkAAAAAAIoAAAAAAIsAAAAAAL8AFgAfAIgDBgAAAAAA D/AQAAAAkAMAABADAADSBgAA9wMAAA8ABPD4AAAAAgAK8AgAAABvLAcAAgoAAIMBC/DIAAAAgQAA AAAAggAAAAAAgwAAAAAAhAAAAAAAhQACAAAAhgAAAAAAhwAAAAAAiAAAAAAAiQAAAAAAigAAAAAA iwAAAAAAvwAWAB8AQgGOAAAAQwFgAgAARAEEAAAARcEUAAAARsEeAAAAfwEBAAEAgAEAAAAAgQHg swAAgwH///8AvwEQABAA/wEQABgAiAMAAAAABQAFAPD/jgCNAI4AYAIAANMBAAAAAI4AjQAMABAA AgAAQACsAQAArAEAAKwBAACsAQAArAFgAIAAAA/wEAAAAHUaAACVIwAAAxsAAPUlAAAPAATw+AAA AAIACvAIAAAAcCwHAAIKAACDAQvwyAAAAIEAAAAAAIIAAAAAAIMAAAAAAIQAAAAAAIUAAgAAAIYA AAAAAIcAAAAAAIgAAAAAAIkAAAAAAIoAAAAAAIsAAAAAAL8AFgAfAEIB/AQAAEMBjQAAAEQBBAAA AEXBFAAAAEbBHgAAAH8BAQABAIABAAAAAIEBl3kAAIMB////AL8BEAAQAP8BEAAYAIgDAAAAAAUA BQDw//wEjQCOAI0AAAAAAG4EAAD8BI0ADAAQAAIAAEAArAEAAKwBAACsAQAArAEAAKwBYACAAAAP 8BAAAAB1GgAAlSMAAHEfAAAiJAAADwAE8GYAAAASAArwCAAAAHEsBwACCgAAkwAL8DYAAACBAAAA AACCAAAAAACDAAAAAACEAAAAAACFAAIAAAC/ABYAHwCBAcOcAAC/ARAAEAD/AQAACAAAAA/wEAAA AAMbAAAiJAAAcR8AAPUlAAAPAATw6gAAABIACvAIAAAAciwHAAIKAACjAAvwPAAAAIAAdGv5AIEA AAAAAIIAAAAAAIMAAAAAAIQAAAAAAIUAAgAAAL8AFgAfAL8BAAAQAP8BAAAIAIgDBgAAAAAAD/AQ AAAAGQQAAD8DAACVBgAA6wMAAA8ADfB2AAAAAACfDwQAAAAEAAAAAACoDxYAAABJUA0oTDJUUCBw YXlsb2FkIHR5cGUpAAChDyYAAAAXAAAAAAAACAAAAQAWAAAAAQAGAIEACQD////+AQAAAAAAAgAJ AAAApg8WAAAA8R4AABYCCwELARYCFgIiAyIDLQQtBA8ABPDcAAAAEgAK8AgAAABzLAcAAgoAAKMA C/A8AAAAgABk0PkAgQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAhQACAAAAvwAWAB8AvwEAABAA/wEA AAgAiAMGAAAAAAAP8BAAAACtBAAAoQIAANUFAAD3AgAADwAN8GgAAAAAAJ8PBAAAAAQAAAAAAKgP CAAAADIwIEJ5dGVzAAChDyYAAAAJAAAAAAAAAAAACAAAAAEABwCBAAIACQAAAAD+AQAAAAAAAgAJ AAAApg8WAAAA8R4AABYCCwELARYCFgIiAyIDLQQtBA8AA/CnBQAADwAE8EAAAAABAAnwEAAAAHMI AACjAgAAuAkAAAcEAAACAArwCAAAAN8sBwADAgAAAAAP8BAAAABzCAAAowIAALgJAAAHBAAADwAD 8HUEAAAPAATwVAAAAAEACfAQAAAApgYAAL4FAABwCAAAuAYAAAIACvAIAAAAiywHAAMCAAAjAAvw DAAAAAQAAAAAAIgDBgAAAAAAD/AQAAAAcwgAAB4DAAC4CQAABwQAAA8AA/ASAwAADwAE8JwAAAAB AAnwEAAAAHUaAACVIwAAcR8AAPUlAAACAArwCAAAAIwsBwADAgAA4wAL8FQAAAAEAAAAAACBAAAA AACCAAAAAACDAAAAAACEAAAAAACFAAIAAACGAAAAAACHAAAAAACIAAAAAACJAAAAAACKAAAAAACL AAAAAAC/ABYAHwCIAwAAAAAAAA/wEAAAAKYGAAC+BQAAcAgAALcGAAAPAATw+AAAAAIACvAIAAAA jSwHAAIKAACDAQvwyAAAAIEAAAAAAIIAAAAAAIMAAAAAAIQAAAAAAIUAAgAAAIYAAAAAAIcAAAAA AIgAAAAAAIkAAAAAAIoAAAAAAIsAAAAAAL8AFgAfAEIBjgAAAEMBYAIAAEQBBAAAAEXBFAAAAEbB HgAAAH8BAQABAIABAAAAAIEB4LMAAIMB////AL8BEAAQAP8BEAAYAIgDAAAAAAUABQDw/44AjQCO AGACAADTAQAAAACOAI0ADAAQAAIAAEAArAEAAKwBAACsAQAArAEAAKwBYACAAAAP8BAAAAB1GgAA lSMAAAMbAAD1JQAADwAE8PgAAAACAArwCAAAAI4sBwACCgAAgwEL8MgAAACBAAAAAACCAAAAAACD AAAAAACEAAAAAACFAAIAAACGAAAAAACHAAAAAACIAAAAAACJAAAAAACKAAAAAACLAAAAAAC/ABYA HwBCAfwEAABDAY0AAABEAQQAAABFwRQAAABGwR4AAAB/AQEAAQCAAQAAAACBAZd5AACDAf///wC/ ARAAEAD/ARAAGACIAwAAAAAFAAUA8P/8BI0AjgCNAAAAAABuBAAA/ASNAAwAEAACAABAAKwBAACs AQAArAEAAKwBAACsAWAAgAAAD/AQAAAAdRoAAJUjAABxHwAAIiQAAA8ABPBmAAAAEgAK8AgAAACP LAcAAgoAAJMAC/A2AAAAgQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAhQACAAAAvwAWAB8AgQHDnAAA vwEQABAA/wEAAAgAAAAP8BAAAAADGwAAIiQAAHEfAAD1JQAADwAE8PcAAAASAArwCAAAAJAsBwAC CgAAkwAL8DYAAACAAMTQ+QCBAAAAAACCAAAAAACDAAAAAACEAAAAAACFAAIAAAC/ABYAHwC/AQAA EAD/AQAACAAAAA/wEAAAAFwHAAD/BQAAJwgAALgGAAAPAA3wiQAAAAAAnw8EAAAABAAAAAAAqA8H AAAAUFBQDU11eAAAoQ8mAAAACAAAAAAAAAgAAAEABwAAAAEABgCBAAkA/////gEAAAAAAAIACQAA AKoPGgAAAAQAAAAAAAAAAwAAAAEAAAADAAEAAAAAAAAAAACmDxYAAADxHgAAFgILAQsBFgIWAiID IgMtBC0EDwAE8NoAAAASAArwCAAAAJEsBwACCgAAowAL8DwAAACAACTR+QCBAAAAAACCAAAAAACD AAAAAACEAAAAAACFAAIAAAC/ABYAHwC/AQAAEAD/AQAACACIAwYAAAAAAA/wEAAAAJgIAACjAgAA cAkAAPkCAAAPAA3wZgAAAAAAnw8EAAAABAAAAAAAqA8GAAAAMSBCeXRlAAChDyYAAAAHAAAAAAAA AAAABgAAAAEABwCBAAIACQAAAAD+AQAAAAAAAgAJAAAApg8WAAAA8R4AABYCCwELARYCFgIiAyID LQQtBA8AA/AuBQAADwAE8FQAAAABAAnwEAAAALIHAACdAgAAcAkAAAIEAAACAArwCAAAANcsBwAD AgAAIwAL8AwAAAAEAAAAAACIAwYAAAAAAA/wEAAAALgJAACjAgAAdgsAAAgEAAAPAAPwEgMAAA8A BPCcAAAAAQAJ8BAAAAB1GgAAlSMAAHEfAAD1JQAAAgAK8AgAAADYLAcAAwIAAOMAC/BUAAAABAAA AAAAgQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAhQACAAAAhgAAAAAAhwAAAAAAiAAAAAAAiQAAAAAA igAAAAAAiwAAAAAAvwAWAB8AiAMAAAAAAAAP8BAAAACyBwAAGwMAAHAJAAACBAAADwAE8PgAAAAC AArwCAAAANksBwACCgAAgwEL8MgAAACBAAAAAACCAAAAAACDAAAAAACEAAAAAACFAAIAAACGAAAA AACHAAAAAACIAAAAAACJAAAAAACKAAAAAACLAAAAAAC/ABYAHwBCAY4AAABDAWACAABEAQQAAABF wRQAAABGwR4AAAB/AQEAAQCAAQAAAACBAeCzAACDAf///wC/ARAAEAD/ARAAGACIAwAAAAAFAAUA 8P+OAI0AjgBgAgAA0wEAAAAAjgCNAAwAEAACAABAAKwBAACsAQAArAEAAKwBAACsAWAAgAAAD/AQ AAAAdRoAAJUjAAADGwAA9SUAAA8ABPD4AAAAAgAK8AgAAADaLAcAAgoAAIMBC/DIAAAAgQAAAAAA ggAAAAAAgwAAAAAAhAAAAAAAhQACAAAAhgAAAAAAhwAAAAAAiAAAAAAAiQAAAAAAigAAAAAAiwAA AAAAvwAWAB8AQgH8BAAAQwGNAAAARAEEAAAARcEUAAAARsEeAAAAfwEBAAEAgAEAAAAAgQGXeQAA gwH///8AvwEQABAA/wEQABgAiAMAAAAABQAFAPD//ASNAI4AjQAAAAAAbgQAAPwEjQAMABAAAgAA QACsAQAArAEAAKwBAACsAQAArAFgAIAAAA/wEAAAAHUaAACVIwAAcR8AACIkAAAPAATwZgAAABIA CvAIAAAA2ywHAAIKAACTAAvwNgAAAIEAAAAAAIIAAAAAAIMAAAAAAIQAAAAAAIUAAgAAAL8AFgAf AIEBw5wAAL8BEAAQAP8BAAAIAAAAD/AQAAAAAxsAACIkAABxHwAA9SUAAA8ABPDUAAAAEgAK8AgA AADcLAcAAgoAAJMAC/A2AAAAgACE0fkAgQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAhQACAAAAvwAW AB8AvwEAABAA/wEAAAgAAAAP8BAAAABYCAAAWAMAADQJAACuAwAADwAN8GYAAAAAAJ8PBAAAAAQA AAAAAKgPBgAAAExlbmd0aAAAoQ8mAAAABwAAAAAAAAgAAAEABgAAAAEABgCBAAkA/////gEAAAAA AAIACQAAAKYPFgAAAPEeAAAWAgsBCwEWAhYCIgMiAy0ELQQPAATw1AAAABIACvAIAAAA3SwHAAIK AACTAAvwNgAAAIAA5NH5AIEAAAAAAIIAAAAAAIMAAAAAAIQAAAAAAIUAAgAAAL8AFgAfAL8BAAAQ AP8BAAAIAAAAD/AQAAAA8gcAAJ0CAADKCAAA8wIAAA8ADfBmAAAAAACfDwQAAAAEAAAAAACoDwYA AAAxIEJ5dGUAAKEPJgAAAAcAAAAAAAAAAAAGAAAAAQAHAIEAAgAJAAAAAP4BAAAAAAACAAkAAACm DxYAAADxHgAAFgILAQsBFgIWAiIDIgMtBC0EDwAD8M82AAAPAATwOAAAAAEACfAQAAAAEAIAADAM AABvFAAAcw4AAAIACvAIAAAA8ywHAAECAAAAABDwCAAAABAL4AE/FFMNDwAD8FELAAAPAATwVAAA AAEACfAQAAAA9AIAAEwNAABjBgAAzg4AAAIACvAIAAAAkiwHAAMCAAAjAAvwDAAAAAQAAAAAAIgD AAAAAAAAD/AQAAAAEAIAADAMAABABQAAlg0AAA8ABPDVAAAAEgAK8AgAAACTLAcAAgoAAJMAC/A2 AAAAgABE0vkAgQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAhQACAAAAvwAWAB8AvwEAABAA/wEAAAgA AAAP8BAAAAAKAwAATA0AAB0EAACpDQAADwAN8GcAAAAAAJ8PBAAAAAQAAAAAAKgPBwAAADQgQnl0 ZXMAAKEPJgAAAAgAAAAAAAAAAAAHAAAAAQAHAIEAAgAJAAAAAP4BAAAAAAACAAkAAACmDxYAAADx HgAAFgILAQsBFgIWAiIDIgMtBC0EDwAD8JQEAAAPAATwnAAAAAEACfAQAAAAZgQAAP4MAAAwBgAA 9w0AAAIACvAIAAAAlCwHAAMCAADjAAvwVAAAAAQAAAAAAIEAAAAAAIIAAAAAAIMAAAAAAIQAAAAA AIUAAgAAAIYAAAAAAIcAAAAAAIgAAAAAAIkAAAAAAIoAAAAAAIsAAAAAAL8AFgAfAIgDAAAAAAAA D/AQAAAAmQQAANUNAABjBgAAzg4AAA8AA/ASAwAADwAE8JwAAAABAAnwEAAAAHUaAACVIwAAcR8A APUlAAACAArwCAAAAJUsBwADAgAA4wAL8FQAAAAEAAAAAACBAAAAAACCAAAAAACDAAAAAACEAAAA AACFAAIAAACGAAAAAACHAAAAAACIAAAAAACJAAAAAACKAAAAAACLAAAAAAC/ABYAHwCIAwAAAAAA AA/wEAAAAGYEAAD+DAAAMAYAAPcNAAAPAATw+AAAAAIACvAIAAAAliwHAAIKAACDAQvwyAAAAIEA AAAAAIIAAAAAAIMAAAAAAIQAAAAAAIUAAgAAAIYAAAAAAIcAAAAAAIgAAAAAAIkAAAAAAIoAAAAA AIsAAAAAAL8AFgAfAEIBjgAAAEMBYAIAAEQBBAAAAEXBFAAAAEbBHgAAAH8BAQABAIABAAAAAIEB 4LMAAIMB////AL8BEAAQAP8BEAAYAIgDAAAAAAUABQDw/44AjQCOAGACAADTAQAAAACOAI0ADAAQ AAIAAEAArAEAAKwBAACsAQAArAEAAKwBYACAAAAP8BAAAAB1GgAAlSMAAAMbAAD1JQAADwAE8PgA AAACAArwCAAAAJcsBwACCgAAgwEL8MgAAACBAAAAAACCAAAAAACDAAAAAACEAAAAAACFAAIAAACG AAAAAACHAAAAAACIAAAAAACJAAAAAACKAAAAAACLAAAAAAC/ABYAHwBCAfwEAABDAY0AAABEAQQA AABFwRQAAABGwR4AAAB/AQEAAQCAAQAAAACBAZd5AACDAf///wC/ARAAEAD/ARAAGACIAwAAAAAF AAUA8P/8BI0AjgCNAAAAAABuBAAA/ASNAAwAEAACAABAAKwBAACsAQAArAEAAKwBAACsAWAAgAAA D/AQAAAAdRoAAJUjAABxHwAAIiQAAA8ABPBmAAAAEgAK8AgAAACYLAcAAgoAAJMAC/A2AAAAgQAA AAAAggAAAAAAgwAAAAAAhAAAAAAAhQACAAAAvwAWAB8AgQHDnAAAvwEQABAA/wEAAAgAAAAP8BAA AAADGwAAIiQAAHEfAAD1JQAADwAE8M4AAAASAArwCAAAAJksBwACCgAAkwAL8DYAAACAAKTS+QCB AAAAAACCAAAAAACDAAAAAACEAAAAAACFAAIAAAC/ABYAHwC/AQAAEAD/AQAACAAAAA/wEAAAAD4F AABADQAAiwUAAJwNAAAPAA3wYAAAAAAAnw8EAAAABAAAAAAAqA8CAAAASVAAAKEPJAAAAAMAAAAA AAAAAAACAAAAAQAGAIEACQD////+AQAAAAAAAgAJAAAApg8WAAAA8R4AABYCCwELARYCFgIiAyID LQQtBA8AA/CWBAAADwAE8JwAAAABAAnwEAAAAK8CAAAFDQAAcwQAAP4NAAACAArwCAAAAJosBwAD AgAA4wAL8FQAAAAEAAAAAACBAAAAAACCAAAAAACDAAAAAACEAAAAAACFAAIAAACGAAAAAACHAAAA AACIAAAAAACJAAAAAACKAAAAAACLAAAAAAC/ABYAHwCIAwAAAAAAAA/wEAAAAPQCAADVDQAAuAQA AM4OAAAPAAPwEgMAAA8ABPCcAAAAAQAJ8BAAAAB1GgAAlSMAAHEfAAD1JQAAAgAK8AgAAACbLAcA AwIAAOMAC/BUAAAABAAAAAAAgQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAhQACAAAAhgAAAAAAhwAA AAAAiAAAAAAAiQAAAAAAigAAAAAAiwAAAAAAvwAWAB8AiAMAAAAAAAAP8BAAAACvAgAABQ0AAHME AAD+DQAADwAE8PgAAAACAArwCAAAAJwsBwACCgAAgwEL8MgAAACBAAAAAACCAAAAAACDAAAAAACE AAAAAACFAAIAAACGAAAAAACHAAAAAACIAAAAAACJAAAAAACKAAAAAACLAAAAAAC/ABYAHwBCAY4A AABDAWACAABEAQQAAABFwRQAAABGwR4AAAB/AQEAAQCAAQAAAACBAeCzAACDAf///wC/ARAAEAD/ ARAAGACIAwAAAAAFAAUA8P+OAI0AjgBgAgAA0wEAAAAAjgCNAAwAEAACAABAAKwBAACsAQAArAEA AKwBAACsAWAAgAAAD/AQAAAAdRoAAJUjAAADGwAA9SUAAA8ABPD4AAAAAgAK8AgAAACdLAcAAgoA AIMBC/DIAAAAgQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAhQACAAAAhgAAAAAAhwAAAAAAiAAAAAAA iQAAAAAAigAAAAAAiwAAAAAAvwAWAB8AQgH8BAAAQwGNAAAARAEEAAAARcEUAAAARsEeAAAAfwEB AAEAgAEAAAAAgQGXeQAAgwH///8AvwEQABAA/wEQABgAiAMAAAAABQAFAPD//ASNAI4AjQAAAAAA bgQAAPwEjQAMABAAAgAAQACsAQAArAEAAKwBAACsAQAArAFgAIAAAA/wEAAAAHUaAACVIwAAcR8A ACIkAAAPAATwZgAAABIACvAIAAAAniwHAAIKAACTAAvwNgAAAIEAAAAAAIIAAAAAAIMAAAAAAIQA AAAAAIUAAgAAAL8AFgAfAIEBw5wAAL8BEAAQAP8BAAAIAAAAD/AQAAAAAxsAACIkAABxHwAA9SUA AA8ABPDQAAAAEgAK8AgAAACfLAcAAgoAAJMAC/A2AAAAgAAE0/kAgQAAAAAAggAAAAAAgwAAAAAA hAAAAAAAhQACAAAAvwAWAB8AvwEAABAA/wEAAAgAAAAP8BAAAAAhAwAAUA0AAAEEAACtDQAADwAN 8GIAAAAAAJ8PBAAAAAQAAAAAAKgPBAAAAEhETEMAAKEPJAAAAAUAAAAAAAAAAAAEAAAAAQAGAIEA CQD////+AQAAAAAAAgAJAAAApg8WAAAA8R4AABYCCwELARYCFgIiAyIDLQQtBA8ABPDWAAAAEgAK 8AgAAACgLAcAAgoAAJMAC/A2AAAAgADE0/kAgQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAhQACAAAA vwAWAB8AvwEAABAA/wEAAAgAAAAP8BAAAADMBAAATA0AAAsGAACpDQAADwAN8GgAAAAAAJ8PBAAA AAQAAAAAAKgPCAAAADIwIEJ5dGVzAAChDyYAAAAJAAAAAAAAAAAACAAAAAEABwCBAAIACQAAAAD+ AQAAAAAAAgAJAAAApg8WAAAA8R4AABYCCwELARYCFgIiAyIDLQQtBA8ABPBGAQAAogwK8AgAAACh LAcAAgoAAFMBC/B+AAAAgAAk1PkAgQDzRwEAggAZoQAAgwDzRwEAhAAZoQAAhQACAAAAhwAGAAAA vwASAB8AgQEEAAAIgwEAAAAIvwEMAB4AwAEBAAAIywGcMQAA0gEAAAAA0wEAAAAA1AEAAAAA1QEA AAAA/wEGAA4AAQIBAAAIPwIAAAMAfwMAAA8AAAAP8BAAAAACBQAAwg0AAEsSAABzDgAADwAN8JAA AAAAAJ8PBAAAAAQAAAAAAKgPPgAAAFZPSVAgRy43MjlBLCBIRExDLCBJUCwgVHVubmVsZWQgQ1JU UCwgMyBBdWRpbyBTYW1wbGVzIC8gUGFja2V0AAChDxgAAAA/AAAAAAAAAAAAPwAAAAEAAwCBAAIA DQAAAKYPFgAAAPEeAAAWAgsBCwEWAhYCIgMiAy0ELQQPAAPwWB4AAA8ABPBUAAAAAQAJ8BAAAAB2 BwAASw0AAE8UAADhDgAAAgAK8AgAAACiLAcAAwIAACMAC/AMAAAABAAAAAAAiAMAAAAAAAAP8BAA AADeBgAARAwAAMsSAAC8DQAADwAE8M8AAAASAArwCAAAAKMsBwACCgAAkwAL8DYAAACAAITU+QCB AAAAAACCAAAAAACDAAAAAACEAAAAAACFAAIAAAC/ABYAHwC/AQAAEAD/AQAACAAAAA/wEAAAAO8H AAD3DQAAiggAAFQOAAAPAA3wYQAAAAAAnw8EAAAABAAAAAAAqA8DAAAAUlRQAAChDyQAAAAEAAAA AAAAAAAAAwAAAAEABgCBAAkA/////gEAAAAAAAIACQAAAKYPFgAAAPEeAAAWAgsBCwEWAhYCIgMi Ay0ELQQPAATw3gAAABIACvAIAAAApCwHAAIKAACTAAvwNgAAAIAARNX5AIEAAAAAAIIAAAAAAIMA AAAAAIQAAAAAAIUAAgAAAL8AFgAfAL8BAAAQAP8BAAAIAAAAD/AQAAAAag0AAEwNAADKDwAAqQ0A AA8ADfBwAAAAAACfDwQAAAAEAAAAAACoDxAAAABHLjcyOWEsIDEwIGJ5dGVzAAChDyYAAAARAAAA AAAAAAAAEAAAAAEABwCBAAIACQAAAAD+AQAAAAAAAgAJAAAApg8WAAAA8R4AABYCCwELARYCFgIi AyIDLQQtBA8ABPDVAAAAEgAK8AgAAAClLAcAAgoAAJMAC/A2AAAAgACk1fkAgQAAAAAAggAAAAAA gwAAAAAAhAAAAAAAhQACAAAAvwAWAB8AvwEAABAA/wEAAAgAAAAP8BAAAADtCwAASw0AAAENAACo DQAADwAN8GcAAAAAAJ8PBAAAAAQAAAAAAKgPBwAAADQgQnl0ZXMAAKEPJgAAAAgAAAAAAAAAAAAH AAAAAQAHAIEAAgAJAAAAAP4BAAAAAAACAAkAAACmDxYAAADxHgAAFgILAQsBFgIWAiIDIgMtBC0E DwAD8BIDAAAPAATwnAAAAAEACfAQAAAA1yMAAJUjAAA3LAAA9SUAAAIACvAIAAAApiwHAAMCAADj AAvwVAAAAAQAAAAAAIEAAAAAAIIAAAAAAIMAAAAAAIQAAAAAAIUAAgAAAIYAAAAAAIcAAAAAAIgA AAAAAIkAAAAAAIoAAAAAAIsAAAAAAL8AFgAfAIgDAAAAAAAAD/AQAAAApxEAAOUNAABPFAAA3g4A AA8ABPD4AAAAAgAK8AgAAACnLAcAAgoAAIMBC/DIAAAAgQAAAAAAggAAAAAAgwAAAAAAhAAAAAAA hQACAAAAhgAAAAAAhwAAAAAAiAAAAAAAiQAAAAAAigAAAAAAiwAAAAAAvwAWAB8AQgGOAAAAQwFg AgAARAEEAAAARcEUAAAARsEeAAAAfwEBAAEAgAEAAAAAgQHgswAAgwH///8AvwEQABAA/wEQABgA iAMAAAAABQAFAPD/jgCNAI4AYAIAANMBAAAAAI4AjQAMABAAAgAAQACsAQAArAEAAKwBAACsAQAA rAFgAIAAAA/wEAAAANcjAACVIwAAZSQAAPUlAAAPAATw+AAAAAIACvAIAAAAqCwHAAIKAACDAQvw yAAAAIEAAAAAAIIAAAAAAIMAAAAAAIQAAAAAAIUAAgAAAIYAAAAAAIcAAAAAAIgAAAAAAIkAAAAA AIoAAAAAAIsAAAAAAL8AFgAfAEIBYAgAAEMBjQAAAEQBBAAAAEXBFAAAAEbBHgAAAH8BAQABAIAB AAAAAIEBl3kAAIMB////AL8BEAAQAP8BEAAYAIgDAAAAAAUABQDw/2AIjQCOAI0AAAAAANIHAABg CI0ADAAQAAIAAEAArAEAAKwBAACsAQAArAEAAKwBYACAAAAP8BAAAADXIwAAlSMAADcsAAAiJAAA DwAE8GYAAAASAArwCAAAAKksBwACCgAAkwAL8DYAAACBAAAAAACCAAAAAACDAAAAAACEAAAAAACF AAIAAAC/ABYAHwCBAcOcAAC/ARAAEAD/AQAACAAAAA/wEAAAAGUkAAAiJAAANywAAPUlAAAPAATw 2QAAABIACvAIAAAAqiwHAAIKAACTAAvwNgAAAIAAZNb5AIEAAAAAAIIAAAAAAIMAAAAAAIQAAAAA AIUAAgAAAL8AFgAfAL8BAAAQAP8BAAAIAAAAD/AQAAAAIhIAACcOAAD6EwAAhA4AAA8ADfBrAAAA AACfDwQAAAAEAAAAAACoDw0AAABWb2ljZSBQYXlsb2FkAAChDyQAAAAOAAAAAAAAAAAADQAAAAEA BgCBAAkA/////gEAAAAAAAIACQAAAKYPFgAAAPEeAAAWAgsBCwEWAhYCIgMiAy0ELQQPAATw3gAA ABIACvAIAAAAqywHAAIKAACTAAvwNgAAAIAAJNf5AIEAAAAAAIIAAAAAAIMAAAAAAIQAAAAAAIUA AgAAAL8AFgAfAL8BAAAQAP8BAAAIAAAAD/AQAAAApxEAAEsNAAAHFAAAqA0AAA8ADfBwAAAAAACf DwQAAAAEAAAAAACoDxAAAABHLjcyOWEsIDEwIGJ5dGVzAAChDyYAAAARAAAAAAAAAAAAEAAAAAEA BwCBAAIACQAAAAD+AQAAAAAAAgAJAAAApg8WAAAA8R4AABYCCwELARYCFgIiAyIDLQQtBA8AA/AS AwAADwAE8JwAAAABAAnwEAAAAHUaAACVIwAAcR8AAPUlAAACAArwCAAAAKwsBwADAgAA4wAL8FQA AAAEAAAAAACBAAAAAACCAAAAAACDAAAAAACEAAAAAACFAAIAAACGAAAAAACHAAAAAACIAAAAAACJ AAAAAACKAAAAAACLAAAAAAC/ABYAHwCIAwAAAAAAAA/wEAAAANgPAADlDQAAuBEAAN4OAAAPAATw +AAAAAIACvAIAAAArSwHAAIKAACDAQvwyAAAAIEAAAAAAIIAAAAAAIMAAAAAAIQAAAAAAIUAAgAA AIYAAAAAAIcAAAAAAIgAAAAAAIkAAAAAAIoAAAAAAIsAAAAAAL8AFgAfAEIBjgAAAEMBYAIAAEQB BAAAAEXBFAAAAEbBHgAAAH8BAQABAIABAAAAAIEB4LMAAIMB////AL8BEAAQAP8BEAAYAIgDAAAA AAUABQDw/44AjQCOAGACAADTAQAAAACOAI0ADAAQAAIAAEAArAEAAKwBAACsAQAArAEAAKwBYACA AAAP8BAAAAB1GgAAlSMAAAMbAAD1JQAADwAE8PgAAAACAArwCAAAAK4sBwACCgAAgwEL8MgAAACB AAAAAACCAAAAAACDAAAAAACEAAAAAACFAAIAAACGAAAAAACHAAAAAACIAAAAAACJAAAAAACKAAAA AACLAAAAAAC/ABYAHwBCAfwEAABDAY0AAABEAQQAAABFwRQAAABGwR4AAAB/AQEAAQCAAQAAAACB AZd5AACDAf///wC/ARAAEAD/ARAAGACIAwAAAAAFAAUA8P/8BI0AjgCNAAAAAABuBAAA/ASNAAwA EAACAABAAKwBAACsAQAArAEAAKwBAACsAWAAgAAAD/AQAAAAdRoAAJUjAABxHwAAIiQAAA8ABPBm AAAAEgAK8AgAAACvLAcAAgoAAJMAC/A2AAAAgQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAhQACAAAA vwAWAB8AgQHDnAAAvwEQABAA/wEAAAgAAAAP8BAAAAADGwAAIiQAAHEfAAD1JQAADwAE8NcAAAAS AArwCAAAALAsBwACCgAAkwAL8DYAAACAAOTX+QCBAAAAAACCAAAAAACDAAAAAACEAAAAAACFAAIA AAC/ABYAHwC/AQAAEAD/AQAACAAAAA/wEAAAAJcQAAAnDgAAahEAAOEOAAAPAA3waQAAAAAAnw8E AAAABAAAAAAAqA8JAAAAUFBQLw1DUlRQAAChDyYAAAAKAAAAAAAACAAAAQAJAAAAAQAGAIEACQD/ ///+AQAAAAAAAgAJAAAApg8WAAAA8R4AABYCCwELARYCFgIiAyIDLQQtBA8ABPDVAAAAEgAK8AgA AACxLAcAAgoAAJMAC/A2AAAAgABE2PkAgQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAhQACAAAAvwAW AB8AvwEAABAA/wEAAAgAAAAP8BAAAAANEAAATA0AACERAACpDQAADwAN8GcAAAAAAJ8PBAAAAAQA AAAAAKgPBwAAADMgQnl0ZXMAAKEPJgAAAAgAAAAAAAAAAAAHAAAAAQAHAIEAAgAJAAAAAP4BAAAA AAACAAkAAACmDxYAAADxHgAAFgILAQsBFgIWAiIDIgMtBC0EDwAD8BIDAAAPAATwnAAAAAEACfAQ AAAA1yMAAJUjAAA3LAAA9SUAAAIACvAIAAAAsiwHAAMCAADjAAvwVAAAAAQAAAAAAIEAAAAAAIIA AAAAAIMAAAAAAIQAAAAAAIUAAgAAAIYAAAAAAIcAAAAAAIgAAAAAAIkAAAAAAIoAAAAAAIsAAAAA AL8AFgAfAIgDAAAAAAAAD/AQAAAAfw0AAN4NAAD+DwAA1w4AAA8ABPD4AAAAAgAK8AgAAACzLAcA AgoAAIMBC/DIAAAAgQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAhQACAAAAhgAAAAAAhwAAAAAAiAAA AAAAiQAAAAAAigAAAAAAiwAAAAAAvwAWAB8AQgGOAAAAQwFgAgAARAEEAAAARcEUAAAARsEeAAAA fwEBAAEAgAEAAAAAgQHgswAAgwH///8AvwEQABAA/wEQABgAiAMAAAAABQAFAPD/jgCNAI4AYAIA ANMBAAAAAI4AjQAMABAAAgAAQACsAQAArAEAAKwBAACsAQAArAFgAIAAAA/wEAAAANcjAACVIwAA ZSQAAPUlAAAPAATw+AAAAAIACvAIAAAAtCwHAAIKAACDAQvwyAAAAIEAAAAAAIIAAAAAAIMAAAAA AIQAAAAAAIUAAgAAAIYAAAAAAIcAAAAAAIgAAAAAAIkAAAAAAIoAAAAAAIsAAAAAAL8AFgAfAEIB YAgAAEMBjQAAAEQBBAAAAEXBFAAAAEbBHgAAAH8BAQABAIABAAAAAIEBl3kAAIMB////AL8BEAAQ AP8BEAAYAIgDAAAAAAUABQDw/2AIjQCOAI0AAAAAANIHAABgCI0ADAAQAAIAAEAArAEAAKwBAACs AQAArAEAAKwBYACAAAAP8BAAAADXIwAAlSMAADcsAAAiJAAADwAE8GYAAAASAArwCAAAALUsBwAC CgAAkwAL8DYAAACBAAAAAACCAAAAAACDAAAAAACEAAAAAACFAAIAAAC/ABYAHwCBAcOcAAC/ARAA EAD/AQAACAAAAA/wEAAAAGUkAAAiJAAANywAAPUlAAAPAATw2QAAABIACvAIAAAAtiwHAAIKAACT AAvwNgAAAIAABNn5AIEAAAAAAIIAAAAAAIMAAAAAAIQAAAAAAIUAAgAAAL8AFgAfAL8BAAAQAP8B AAAIAAAAD/AQAAAA8g0AACAOAADKDwAAfQ4AAA8ADfBrAAAAAACfDwQAAAAEAAAAAACoDw0AAABW b2ljZSBQYXlsb2FkAAChDyQAAAAOAAAAAAAAAAAADQAAAAEABgCBAAkA/////gEAAAAAAAIACQAA AKYPFgAAAPEeAAAWAgsBCwEWAhYCIgMiAy0ELQQPAAPwEgMAAA8ABPCcAAAAAQAJ8BAAAAB1GgAA lSMAAHEfAAD1JQAAAgAK8AgAAAC3LAcAAwIAAOMAC/BUAAAABAAAAAAAgQAAAAAAggAAAAAAgwAA AAAAhAAAAAAAhQACAAAAhgAAAAAAhwAAAAAAiAAAAAAAiQAAAAAAigAAAAAAiwAAAAAAvwAWAB8A iAMAAAAAAAAP8BAAAACzCwAA3A0AAJMNAADVDgAADwAE8PgAAAACAArwCAAAALgsBwACCgAAgwEL 8MgAAACBAAAAAACCAAAAAACDAAAAAACEAAAAAACFAAIAAACGAAAAAACHAAAAAACIAAAAAACJAAAA AACKAAAAAACLAAAAAAC/ABYAHwBCAY4AAABDAWACAABEAQQAAABFwRQAAABGwR4AAAB/AQEAAQCA AQAAAACBAeCzAACDAf///wC/ARAAEAD/ARAAGACIAwAAAAAFAAUA8P+OAI0AjgBgAgAA0wEAAAAA jgCNAAwAEAACAABAAKwBAACsAQAArAEAAKwBAACsAWAAgAAAD/AQAAAAdRoAAJUjAAADGwAA9SUA AA8ABPD4AAAAAgAK8AgAAAC5LAcAAgoAAIMBC/DIAAAAgQAAAAAAggAAAAAAgwAAAAAAhAAAAAAA hQACAAAAhgAAAAAAhwAAAAAAiAAAAAAAiQAAAAAAigAAAAAAiwAAAAAAvwAWAB8AQgH8BAAAQwGN AAAARAEEAAAARcEUAAAARsEeAAAAfwEBAAEAgAEAAAAAgQGXeQAAgwH///8AvwEQABAA/wEQABgA iAMAAAAABQAFAPD//ASNAI4AjQAAAAAAbgQAAPwEjQAMABAAAgAAQACsAQAArAEAAKwBAACsAQAA rAFgAIAAAA/wEAAAAHUaAACVIwAAcR8AACIkAAAPAATwZgAAABIACvAIAAAAuiwHAAIKAACTAAvw NgAAAIEAAAAAAIIAAAAAAIMAAAAAAIQAAAAAAIUAAgAAAL8AFgAfAIEBw5wAAL8BEAAQAP8BAAAI AAAAD/AQAAAAAxsAACIkAABxHwAA9SUAAA8ABPDXAAAAEgAK8AgAAAC7LAcAAgoAAJMAC/A2AAAA gADE2fkAgQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAhQACAAAAvwAWAB8AvwEAABAA/wEAAAgAAAAP 8BAAAAByDAAAHg4AAEUNAADXDgAADwAN8GkAAAAAAJ8PBAAAAAQAAAAAAKgPCQAAAFBQUC8NQ1JU UAAAoQ8mAAAACgAAAAAAAAgAAAEACQAAAAEABgCBAAkA/////gEAAAAAAAIACQAAAKYPFgAAAPEe AAAWAgsBCwEWAhYCIgMiAy0ELQQPAAPwEgMAAA8ABPCcAAAAAQAJ8BAAAADXIwAAlSMAADcsAAD1 JQAAAgAK8AgAAAC8LAcAAwIAAOMAC/BUAAAABAAAAAAAgQAAAAAAggAAAAAAgwAAAAAAhAAAAAAA hQACAAAAhgAAAAAAhwAAAAAAiAAAAAAAiQAAAAAAigAAAAAAiwAAAAAAvwAWAB8AiAMAAAAAAAAP 8BAAAABWCQAA5Q0AANULAADeDgAADwAE8PgAAAACAArwCAAAAL0sBwACCgAAgwEL8MgAAACBAAAA AACCAAAAAACDAAAAAACEAAAAAACFAAIAAACGAAAAAACHAAAAAACIAAAAAACJAAAAAACKAAAAAACL AAAAAAC/ABYAHwBCAY4AAABDAWACAABEAQQAAABFwRQAAABGwR4AAAB/AQEAAQCAAQAAAACBAeCz AACDAf///wC/ARAAEAD/ARAAGACIAwAAAAAFAAUA8P+OAI0AjgBgAgAA0wEAAAAAjgCNAAwAEAAC AABAAKwBAACsAQAArAEAAKwBAACsAWAAgAAAD/AQAAAA1yMAAJUjAABlJAAA9SUAAA8ABPD4AAAA AgAK8AgAAAC+LAcAAgoAAIMBC/DIAAAAgQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAhQACAAAAhgAA AAAAhwAAAAAAiAAAAAAAiQAAAAAAigAAAAAAiwAAAAAAvwAWAB8AQgFgCAAAQwGNAAAARAEEAAAA RcEUAAAARsEeAAAAfwEBAAEAgAEAAAAAgQGXeQAAgwH///8AvwEQABAA/wEQABgAiAMAAAAABQAF APD/YAiNAI4AjQAAAAAA0gcAAGAIjQAMABAAAgAAQACsAQAArAEAAKwBAACsAQAArAFgAIAAAA/w EAAAANcjAACVIwAANywAACIkAAAPAATwZgAAABIACvAIAAAAvywHAAIKAACTAAvwNgAAAIEAAAAA AIIAAAAAAIMAAAAAAIQAAAAAAIUAAgAAAL8AFgAfAIEBw5wAAL8BEAAQAP8BAAAIAAAAD/AQAAAA ZSQAACIkAAA3LAAA9SUAAA8ABPDZAAAAEgAK8AgAAADALAcAAgoAAJMAC/A2AAAAgACE2vkAgQAA AAAAggAAAAAAgwAAAAAAhAAAAAAAhQACAAAAvwAWAB8AvwEAABAA/wEAAAgAAAAP8BAAAADJCQAA Jw4AAKELAACEDgAADwAN8GsAAAAAAJ8PBAAAAAQAAAAAAKgPDQAAAFZvaWNlIFBheWxvYWQAAKEP JAAAAA4AAAAAAAAAAAANAAAAAQAGAIEACQD////+AQAAAAAAAgAJAAAApg8WAAAA8R4AABYCCwEL ARYCFgIiAyIDLQQtBA8AA/ASAwAADwAE8JwAAAABAAnwEAAAAHUaAACVIwAAcR8AAPUlAAACAArw CAAAAMEsBwADAgAA4wAL8FQAAAAEAAAAAACBAAAAAACCAAAAAACDAAAAAACEAAAAAACFAAIAAACG AAAAAACHAAAAAACIAAAAAACJAAAAAACKAAAAAACLAAAAAAC/ABYAHwCIAwAAAAAAAA/wEAAAAHYH AADVDQAAVgkAAM4OAAAPAATw+AAAAAIACvAIAAAAwiwHAAIKAACDAQvwyAAAAIEAAAAAAIIAAAAA AIMAAAAAAIQAAAAAAIUAAgAAAIYAAAAAAIcAAAAAAIgAAAAAAIkAAAAAAIoAAAAAAIsAAAAAAL8A FgAfAEIBjgAAAEMBYAIAAEQBBAAAAEXBFAAAAEbBHgAAAH8BAQABAIABAAAAAIEB4LMAAIMB//// AL8BEAAQAP8BEAAYAIgDAAAAAAUABQDw/44AjQCOAGACAADTAQAAAACOAI0ADAAQAAIAAEAArAEA AKwBAACsAQAArAEAAKwBYACAAAAP8BAAAAB1GgAAlSMAAAMbAAD1JQAADwAE8PgAAAACAArwCAAA AMMsBwACCgAAgwEL8MgAAACBAAAAAACCAAAAAACDAAAAAACEAAAAAACFAAIAAACGAAAAAACHAAAA AACIAAAAAACJAAAAAACKAAAAAACLAAAAAAC/ABYAHwBCAfwEAABDAY0AAABEAQQAAABFwRQAAABG wR4AAAB/AQEAAQCAAQAAAACBAZd5AACDAf///wC/ARAAEAD/ARAAGACIAwAAAAAFAAUA8P/8BI0A jgCNAAAAAABuBAAA/ASNAAwAEAACAABAAKwBAACsAQAArAEAAKwBAACsAWAAgAAAD/AQAAAAdRoA AJUjAABxHwAAIiQAAA8ABPBmAAAAEgAK8AgAAADELAcAAgoAAJMAC/A2AAAAgQAAAAAAggAAAAAA gwAAAAAAhAAAAAAAhQACAAAAvwAWAB8AgQHDnAAAvwEQABAA/wEAAAgAAAAP8BAAAAADGwAAIiQA AHEfAAD1JQAADwAE8NcAAAASAArwCAAAAMUsBwACCgAAkwAL8DYAAACAAETb+QCBAAAAAACCAAAA AACDAAAAAACEAAAAAACFAAIAAAC/ABYAHwC/AQAAEAD/AQAACAAAAA/wEAAAADUIAAAXDgAACAkA ANEOAAAPAA3waQAAAAAAnw8EAAAABAAAAAAAqA8JAAAAUFBQLw1DUlRQAAChDyYAAAAKAAAAAAAA CAAAAQAJAAAAAQAGAIEACQD////+AQAAAAAAAgAJAAAApg8WAAAA8R4AABYCCwELARYCFgIiAyID LQQtBA8ABPDVAAAAEgAK8AgAAADGLAcAAgoAAJMAC/A2AAAAgACk2/kAgQAAAAAAggAAAAAAgwAA AAAAhAAAAAAAhQACAAAAvwAWAB8AvwEAABAA/wEAAAgAAAAP8BAAAADZBwAATA0AAO0IAACpDQAA DwAN8GcAAAAAAJ8PBAAAAAQAAAAAAKgPBwAAADQgQnl0ZXMAAKEPJgAAAAgAAAAAAAAAAAAHAAAA AQAHAIEAAgAJAAAAAP4BAAAAAAACAAkAAACmDxYAAADxHgAAFgILAQsBFgIWAiIDIgMtBC0EDwAE 8N4AAAASAArwCAAAAMcsBwACCgAAkwAL8DYAAACAAIR2+wCBAAAAAACCAAAAAACDAAAAAACEAAAA AACFAAIAAAC/ABYAHwC/AQAAEAD/AQAACAAAAA/wEAAAAFYJAABMDQAAtgsAAKkNAAAPAA3wcAAA AAAAnw8EAAAABAAAAAAAqA8QAAAARy43MjlhLCAxMCBieXRlcwAAoQ8mAAAAEQAAAAAAAAAAABAA AAABAAcAgQACAAkAAAAA/gEAAAAAAAIACQAAAKYPFgAAAPEeAAAWAgsBCwEWAhYCIgMiAy0ELQQP AAPwngUAAA8ABPBAAAAAAQAJ8BAAAADLEgAATQwAAG8UAAC5DQAAAgAK8AgAAADqLAcAAwIAAAAA D/AQAAAAyxIAAE0MAABvFAAAuQ0AAA8AA/BNBAAADwAE8FQAAAABAAnwEAAAAK8CAAAFDQAAcwQA AP4NAAACAArwCAAAAMgsBwADAgAAIwAL8AwAAAAEAAAAAACIAwAAAAAAAA/wEAAAAMsSAADTDAAA bxQAALkNAAAPAAPwEgMAAA8ABPCcAAAAAQAJ8BAAAAB1GgAAlSMAAHEfAAD1JQAAAgAK8AgAAADJ LAcAAwIAAOMAC/BUAAAABAAAAAAAgQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAhQACAAAAhgAAAAAA hwAAAAAAiAAAAAAAiQAAAAAAigAAAAAAiwAAAAAAvwAWAB8AiAMAAAAAAAAP8BAAAACvAgAABQ0A AHMEAAD+DQAADwAE8PgAAAACAArwCAAAAMosBwACCgAAgwEL8MgAAACBAAAAAACCAAAAAACDAAAA AACEAAAAAACFAAIAAACGAAAAAACHAAAAAACIAAAAAACJAAAAAACKAAAAAACLAAAAAAC/ABYAHwBC AY4AAABDAWACAABEAQQAAABFwRQAAABGwR4AAAB/AQEAAQCAAQAAAACBAeCzAACDAf///wC/ARAA EAD/ARAAGACIAwAAAAAFAAUA8P+OAI0AjgBgAgAA0wEAAAAAjgCNAAwAEAACAABAAKwBAACsAQAA rAEAAKwBAACsAWAAgAAAD/AQAAAAdRoAAJUjAAADGwAA9SUAAA8ABPD4AAAAAgAK8AgAAADLLAcA AgoAAIMBC/DIAAAAgQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAhQACAAAAhgAAAAAAhwAAAAAAiAAA AAAAiQAAAAAAigAAAAAAiwAAAAAAvwAWAB8AQgH8BAAAQwGNAAAARAEEAAAARcEUAAAARsEeAAAA fwEBAAEAgAEAAAAAgQGXeQAAgwH///8AvwEQABAA/wEQABgAiAMAAAAABQAFAPD//ASNAI4AjQAA AAAAbgQAAPwEjQAMABAAAgAAQACsAQAArAEAAKwBAACsAQAArAFgAIAAAA/wEAAAAHUaAACVIwAA cR8AACIkAAAPAATwZgAAABIACvAIAAAAzCwHAAIKAACTAAvwNgAAAIEAAAAAAIIAAAAAAIMAAAAA AIQAAAAAAIUAAgAAAL8AFgAfAIEBw5wAAL8BEAAQAP8BAAAIAAAAD/AQAAAAAxsAACIkAABxHwAA 9SUAAA8ABPDPAAAAEgAK8AgAAADNLAcAAgoAAJMAC/A2AAAAgADkdvsAgQAAAAAAggAAAAAAgwAA AAAAhAAAAAAAhQACAAAAvwAWAB8AvwEAABAA/wEAAAgAAAAP8BAAAAAhAwAAUA0AAMkDAACtDQAA DwAN8GEAAAAAAJ8PBAAAAAQAAAAAAKgPAwAAAENSQwAAoQ8kAAAABAAAAAAAAAAAAAMAAAABAAYA gQAJAP////4BAAAAAAACAAkAAACmDxYAAADxHgAAFgILAQsBFgIWAiIDIgMtBC0EDwAE8PkAAAAS AArwCAAAAM4sBwACCgAAkwAL8DYAAACAAKR3+wCBAAAAAACCAAAAAACDAAAAAACEAAAAAACFAAIA AAC/ABYAHwC/AQAAEAD/AQAACAAAAA/wEAAAAPoSAABNDAAAIhQAAKMMAAAPAA3wiwAAAAAAnw8E AAAABAAAAAAAqA8JAAAANCBCeXRlcyAgAAChDyYAAAAKAAAAAAAAAAAACQAAAAEABwCBAAIACQAA AAD+AQAAAAAAAgAJAAAAqg8aAAAACAAAAAAAAAABAAAAAQAAAAAAAQAAAAAAAAAAAKYPFgAAAPEe AAAWAgsBCwEWAhYCIgMiAy0ELQQPAAPw2gUAAA8ABPBOAAAAAQAJ8BAAAADLEgAATQwAAG8UAADE DQAAAgAK8AgAAADrLAcAAwIAABMAC/AGAAAAiAMAAAAAAAAP8BAAAABABQAAMAwAAOQGAACnDQAA DwAD8HsEAAAPAATwVAAAAAEACfAQAAAArwIAAAUNAABzBAAACg4AAAIACvAIAAAA7CwHAAMCAAAj AAvwDAAAAAQAAAAAAIgDAAAAAAAAD/AQAAAAyxIAANMMAABvFAAAxA0AAA8AA/ASAwAADwAE8JwA AAABAAnwEAAAAHUaAACVIwAAcR8AAPUlAAACAArwCAAAAO0sBwADAgAA4wAL8FQAAAAEAAAAAACB AAAAAACCAAAAAACDAAAAAACEAAAAAACFAAIAAACGAAAAAACHAAAAAACIAAAAAACJAAAAAACKAAAA AACLAAAAAAC/ABYAHwCIAwAAAAAAAA/wEAAAAK8CAAAFDQAAcwQAAP4NAAAPAATw+AAAAAIACvAI AAAA7iwHAAIKAACDAQvwyAAAAIEAAAAAAIIAAAAAAIMAAAAAAIQAAAAAAIUAAgAAAIYAAAAAAIcA AAAAAIgAAAAAAIkAAAAAAIoAAAAAAIsAAAAAAL8AFgAfAEIBjgAAAEMBYAIAAEQBBAAAAEXBFAAA AEbBHgAAAH8BAQABAIABAAAAAIEB4LMAAIMB////AL8BEAAQAP8BEAAYAIgDAAAAAAUABQDw/44A jQCOAGACAADTAQAAAACOAI0ADAAQAAIAAEAArAEAAKwBAACsAQAArAEAAKwBYACAAAAP8BAAAAB1 GgAAlSMAAAMbAAD1JQAADwAE8PgAAAACAArwCAAAAO8sBwACCgAAgwEL8MgAAACBAAAAAACCAAAA AACDAAAAAACEAAAAAACFAAIAAACGAAAAAACHAAAAAACIAAAAAACJAAAAAACKAAAAAACLAAAAAAC/ ABYAHwBCAfwEAABDAY0AAABEAQQAAABFwRQAAABGwR4AAAB/AQEAAQCAAQAAAACBAZd5AACDAf// /wC/ARAAEAD/ARAAGACIAwAAAAAFAAUA8P/8BI0AjgCNAAAAAABuBAAA/ASNAAwAEAACAABAAKwB AACsAQAArAEAAKwBAACsAWAAgAAAD/AQAAAAdRoAAJUjAABxHwAAIiQAAA8ABPBmAAAAEgAK8AgA AADwLAcAAgoAAJMAC/A2AAAAgQAAAAAAggAAAAAAgwAAAAAAhAAAAAAAhQACAAAAvwAWAB8AgQHD nAAAvwEQABAA/wEAAAgAAAAP8BAAAAADGwAAIiQAAHEfAAD1JQAADwAE8P0AAAASAArwCAAAAPEs BwACCgAAkwAL8DYAAACAAGR4+wCBAAAAAACCAAAAAACDAAAAAACEAAAAAACFAAIAAAC/ABYAHwC/ AQAAEAD/AQAACAAAAA/wEAAAACEDAABQDQAAXQQAAAoOAAAPAA3wjwAAAAAAnw8EAAAABAAAAAAA qA8NAAAATDJUUC8NUFBQIE11eAAAoQ8mAAAADgAAAAAAAAgAAAEADQAAAAEABgCBAAkA/////gEA AAAAAAIACQAAAKoPGgAAAAoAAAAAAAAAAwAAAAEAAAADAAEAAAAAAAAAAACmDxYAAADxHgAAFgIL AQsBFgIWAiIDIgMtBC0EDwAE8PkAAAASAArwCAAAAPIsBwACCgAAkwAL8DYAAACAACR5+wCBAAAA AACCAAAAAACDAAAAAACEAAAAAACFAAIAAAC/ABYAHwC/AQAAEAD/AQAACAAAAA/wEAAAAPoSAABN DAAAIhQAAKMMAAAPAA3wiwAAAAAAnw8EAAAABAAAAAAAqA8JAAAAMiBCeXRlcyAgAAChDyYAAAAK AAAAAAAAAAAACQAAAAEABwCBAAIACQAAAAD+AQAAAAAAAgAJAAAAqg8aAAAACAAAAAAAAAABAAAA AQAAAAAAAQAAAAAAAAAAAKYPFgAAAPEeAAAWAgsBCwEWAhYCIgMiAy0ELQQPAATwSAAAABIACvAI AAAAASwHAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMBjp+LAJQB3r1oAL8BHgAfAP8BAAAIAAQD CQAAAD8DAQABABAA8AcgAAAA////AAAAAABgyQAAAAAAAP8A/wD6/QAAAP//AP9QCAAPAO4D2gIA AAIA7wMYAAAAEAAAAAAAAAAAAAAACgAAgAAAAAAHAAAADwAMBIoCAAAPAALwggIAACABCPAIAAAA AwAAAAMoBwAPAAPwGgIAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAngAAAHcAAAAAAAAAAgAK8AgAAAAA KAcABQAAAA8ABPBgAAAAsgQK8AgAAAACKAcAEAoAAGMAC/AkAAAABEEBAAAACwEBAAAAPwEAAAEA vwEAABAA/wEAAAgAPwIAAAIAAAAQ8AgAAABwAw4BTRVkDw8AEfAMAAAAAADBCwQAAAABAAAADwAE 8HoBAACiDArwCAAAAAMoBwAACgAAMwEL8HIAAACAAIR5+wCBALGRAQCCANnIAACDALGRAQCEANnI AACFAAIAAACHAAYAAAC/ABIAHwCBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAjSAQAAAADTAQAAAADU AQAAAADVAQAAAAD/AQAACAABAgEAAAg/AgAAAgAAABDwCAAAANgA5gGjFDUDDwAN8NgAAAAAAJ8P BAAAAAQAAAAAAKgPNAAAAFRDUlRQIHZzLiBSVFAgLyBDUlRQIEJhbmR3aWR0aA0xMCBtc2VjIHBh Y2tldGl6YXRpb24AAKEPNgAAADUAAAAAAAAIAAABAB8AAAABAAMAgQACACQAFQAAAAEAAwCBAAIA FAABAAAAAQADAIEAAgAkAAAAqg8sAAAABgAAAAAAAAACAAAAAQAAAAMAGgAAAAAAAAASAAAAAQAA AAMAAQAAAAAAAAAAAKYPFgAAAPEeAACIAkQBRAGIAogCzAPMAxAFEAUPAATwSAAAABIACvAIAAAA ASgHAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMBjp+LAJQB3r1oAL8BHgAfAP8BAAAIAAQDCQAA AD8DAQABABAA8AcgAAAA////AAAAAAAAAAAAAAAAAABsiADPDjAA////AP/lmwAPAPADmAIAAAEA 8QMIAAAAAAEAAAcADDAPAAwEWAIAAA8AAvBQAgAAMAEI8AgAAAADAAAAA1gGAA8AA/DoAQAADwAE 8CgAAAABAAnwEAAAAAAAAACeAAAAdwAAAAAAAAACAArwCAAAAABYBgAFAAAADwAE8FgAAAASAArw CAAAAAJYBgAgAgAAQwAL8BgAAAAEAAAAAAC/AQEAAQD/AQEAAQABAwmIBQAAABDwCAAAALUB8AJZ DkQKDwAR8BAAAAAAAMMLCAAAAAAAAAALAFABDwAE8FABAAASAArwCAAAAANYBgAgAgAAUwAL8B4A AAAEAAAAAACAAOR5+wC/AQAAAQD/AQAAAQABAwqIBQAAABDwCAAAANYKTgL6DhoVDwAR8BAAAAAA AMMLCAAAAAEAAAAMAFABDwAN8OoAAAAAAJ8PBAAAAAIAAAAAAKgPmAAAAFRoZSBleHRlbnNpb25z IGFyZSB1c2VmdWwgaW4gZ2VuZXJhbCBidXQgYXJlIGVzcGVjaWFsbHkgaW1wb3J0YW50IGZvciBj b21wcmVzc2lvbiBvdmVyIG11bHRpcGxlIGhvcCB3aGVyZSBsb3NzIGFuZCBtaXNvcmRlcmluZyBh cmUgbW9yZSBsaWtlbHkgdG8gaGFwcGVuAAChDxQAAACZAAAAAAAAAAAAmQAAAAAAAgAYAAAAqg8a AAAAcwAAAAAAAAAMAAAAAQAAAAMAGgAAAAAAAAAPAATwSAAAABIACvAIAAAAAVgGAAAMAACDAAvw MAAAAIEBAAAACIMBBQAACJMBykJrAJQBc4mNAL8BEgASAP8BAAAIAAQDCQAAAD8DAQABABAA8Acg AAAA////AAAAAACWlpYAAAAAAADMmQAzM8wAzMz/ALKysgAPAPADzAEAAAEA8QMIAAAAMgIAAAcA DDAPAAwEjAEAAA8AAvCEAQAAgAEI8AgAAAADAAAAA2AGAA8AA/AcAQAADwAE8CgAAAABAAnwEAAA AAAAAAAAAAAA/////wACAAACAArwCAAAAABgBgAFAAAADwAE8FgAAAASAArwCAAAAAJgBgAgAgAA QwAL8BgAAAAEAAAAAAC/AQEAAQD/AQEAAQABAwmIBQAAABDwCAAAALUB8AJZDkQKDwAR8BAAAAAA AMMLCAAAAAAAAAALAFABDwAE8IQAAAASAArwCAAAAANgBgAgAgAAUwAL8B4AAAAEAAAAAACAAGR+ +wC/AQEAAQD/AQEAAQABAwqIBQAAABDwCAAAAN0KQALsDiEVDwAR8BAAAAAAAMMLCAAAAAEAAAAM AFABDwAN8B4AAAAAAJ8PBAAAAAIAAAAAAKoPCgAAAAEAAAABAAAAAAAPAATwSAAAABIACvAIAAAA AWAGAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMBykJrAJQBc4mNAL8BEgASAP8BAAAIAAQDCQAA AD8DAQABABAA8AcgAAAA////AAAAAACWlpYAAAAAAADMmQAzM8wAzMz/ALKysgAPAPADzAEAAAEA 8QMIAAAAPgIAAAcADDAPAAwEjAEAAA8AAvCEAQAAsAEI8AgAAAADAAAAA5gGAA8AA/AcAQAADwAE 8CgAAAABAAnwEAAAAAAAAAALAwAASAIAAAAAAAACAArwCAAAAACYBgAFAAAADwAE8FgAAAASAArw CAAAAAKYBgAgAgAAQwAL8BgAAAAEAAAAAAC/AQEAAQD/AQEAAQABAwmIBQAAABDwCAAAALUB8AJZ DkQKDwAR8BAAAAAAAMMLCAAAAAAAAAALAFABDwAE8IQAAAASAArwCAAAAAOYBgAgAgAAUwAL8B4A AAAEAAAAAACAAIR/+wC/AQEAAQD/AQEAAQABAwqIBQAAABDwCAAAANYKTgL6DhoVDwAR8BAAAAAA AMMLCAAAAAEAAAAMAFABDwAN8B4AAAAAAJ8PBAAAAAIAAAAAAKoPCgAAAAEAAAABAAAAAAAPAATw SAAAABIACvAIAAAAAZgGAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMBykJrAJQBc4mNAL8BEgAS AP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAA////AAAAAACWlpYAAAAAAADMmQAzM8wAzMz/ALKy sgAPAPAD9AEAAAEA8QMIAAAAQgIAAAcADDAPAAwEtAEAAA8AAvCsAQAAYAEI8AgAAAADAAAAA9AG AA8AA/BEAQAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAABgAAAAAAAAACAArwCAAAAADQBgAFAAAA DwAE8F4AAAASAArwCAAAAALQBgAgAgAAUwAL8B4AAAAEAAAAAAC/AQEAAQD/AQEAAQABAwmIBQCI AwAAAAAAABDwCAAAALUB8AJZDkQKDwAR8BAAAAAAAMMLCAAAAAAAAAALAFABDwAE8KYAAAASAArw CAAAAAPQBgAgAgAAYwAL8CQAAAAEAAAAAACAAER9+wC/AQEAAQD/AQEAAQABAwqIBQCIAwAAAAAA ABDwCAAAANYKTgL6DhoVDwAR8BAAAAAAAMMLCAAAAAEAAAAMAFABDwAN8DoAAAAAAJ8PBAAAAAIA AAAAAKEPFAAAAAEAAAAAAAAAAAABAAAAAAACABgAAACqDwoAAAABAAAAAQAAAAAADwAE8EgAAAAS AArwCAAAAAHQBgAADAAAgwAL8DAAAACBAQAAAAiDAQUAAAiTAcpCawCUAXOJjQC/AR4AHwD/AQAA CAAEAwkAAAA/AwEAAQAQAPAHIAAAAP///wAAAAAAlpaWAAAAAAAAzJkAMzPMAMzM/wCysrIADwDw A9ACAAABAPEDCAAAAEMCAAAHAAwwDwAMBJACAAAPAALwiAIAAFABCPAIAAAAAwAAAAPcBgAPAAPw IAIAAA8ABPAoAAAAAQAJ8BAAAAAGAAAAAAAAAAAAAAAGAAAAAgAK8AgAAAAA3AYABQAAAA8ABPBe AAAAEgAK8AgAAAAC3AYAIAIAAFMAC/AeAAAABAAAAAAAvwEBAAEA/wEBAAEAAQMJiAUAiAMAAAAA AAAQ8AgAAACvAQEDag4+Cg8AEfAQAAAAAADDCwgAAAAAAAAACwBQAQ8ABPCCAQAAEgAK8AgAAAAD 3AYAIAIAAGMAC/AkAAAABAAAAAAAgACkevsAvwEAAAEA/wEAAAEAAQMKiAUAiAMAAAAAAAAQ8AgA AADWCk4C+g4aFQ8AEfAQAAAAAADDCwgAAAABAAAADABQAQ8ADfAWAQAAAACfDwQAAAACAAAAAACo D4wAAABDVURQKyBpbmNsdWRlcyB0aGUgd2hvbGUgUlRQIGhlYWRlciBhbmQgbWF5IGluY2x1ZGUg dGhlIGRlbHRhSSBhbmQgZGVsdGFULCBzbyBhbGwgdGhlIHN0YXRlIHBhcmFtZXRlcnMgYXQgdGhl IGRlY29tcHJlc3NvciBjYW4gYmUgcmVzdG9yZWQNDQAAoQ8eAAAAjQAAAAAAAAAAAIwAAAAAAAIA GAABAAAAAAACABIAAACqD0gAAAA4AAAAAAAAAAcAAAABAAAAAwAEAAAAAAAAAAYAAAABAAAAAwAl AAAAAAAAAA0AAAABAAAAAwARAAAAAAAAAAEAAAABAAAAAAAPAATwSAAAABIACvAIAAAAAdwGAAAM AACDAAvwMAAAAIEBAAAACIMBBQAACJMBykJrAJQBc4mNAL8BHgAfAP8BAAAIAAQDCQAAAD8DAQAB ABAA8AcgAAAA////AAAAAACWlpYAAAAAAADMmQAzM8wAzMz/ALKysgAPAPADGwIAAAEA8QMIAAAA RAIAAAcADDAPAAwE2wEAAA8AAvDTAQAAcAEI8AgAAAADAAAAA+QGAA8AA/BrAQAADwAE8CgAAAAB AAnwEAAAAAAAAAAAAQAABgAAAFAAAQACAArwCAAAAADkBgAFAAAADwAE8F4AAAASAArwCAAAAALk BgAgAgAAUwAL8B4AAAAEAAAAAAC/AQEAAQD/AQEAAQABAwmIBQCIAwAAAAAAABDwCAAAALUB8AJZ DkQKDwAR8BAAAAAAAMMLCAAAAAAAAAALAFABDwAE8M0AAAASAArwCAAAAAPkBgAgAgAAYwAL8CQA AAAEAAAAAACAAAR++wC/AQAAAQD/AQAAAQABAwqIBQCIAwAAAAAAABDwCAAAANYKTgL6DhoVDwAR 8BAAAAAAAMMLCAAAAAEAAAAMAFABDwAN8GEAAAAAAJ8PBAAAAAIAAAAAAKgPJwAAAEdlbmVyYWwg ZXh0ZW5zaW9uLCBub3QgcmVsYXRlZCB0byBUQ1JUUAAAoQ8eAAAAKAAAAAAAAAAAACcAAAAAAAIA GAABAAAAAAACABIADwAE8EgAAAASAArwCAAAAAHkBgAADAAAgwAL8DAAAACBAQAAAAiDAQUAAAiT AcpCawCUAXOJjQC/AR4AHwD/AQAACAAEAwkAAAA/AwEAAQAQAPAHIAAAAP///wAAAAAAlpaWAAAA AAAAzJkAMzPMAMzM/wCysrIADwDwA/QBAAABAPEDCAAAAEUCAAAHAAwwDwAMBLQBAAAPAALwrAEA AJABCPAIAAAAAwAAAAPsBgAPAAPwRAEAAA8ABPAoAAAAAQAJ8BAAAAAAAAAABgAAAAAAAAAAAAAA AgAK8AgAAAAA7AYABQAAAA8ABPBeAAAAEgAK8AgAAAAC7AYAIAIAAFMAC/AeAAAABAAAAAAAvwEB AAEA/wEBAAEAAQMJiAUAiAMAAAAAAAAQ8AgAAAC1AfACWQ5ECg8AEfAQAAAAAADDCwgAAAAAAAAA CwBQAQ8ABPCmAAAAEgAK8AgAAAAD7AYAIAIAAGMAC/AkAAAABAAAAAAAgADEfvsAvwEBAAEA/wEB AAEAAQMKiAUAiAMAAAAAAAAQ8AgAAADWCk4C+g4aFQ8AEfAQAAAAAADDCwgAAAABAAAADABQAQ8A DfA6AAAAAACfDwQAAAACAAAAAAChDxQAAAABAAAAAAAAAAAAAQAAAAAAAgAQAAAAqg8KAAAAAQAA AAEAAAAAAA8ABPBIAAAAEgAK8AgAAAAB7AYAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwHKQmsA lAFziY0AvwEeAB8A/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAJaWlgAAAAAAAMyZ ADMzzADMzP8AsrKyAA8A8AP0AQAAAQDxAwgAAABGAgAABwAMMA8ADAS0AQAADwAC8KwBAACgAQjw CAAAAAMAAAAD9AYADwAD8EQBAAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAI AAAAAPQGAAUAAAAPAATwXgAAABIACvAIAAAAAvQGACACAABTAAvwHgAAAAQAAAAAAL8BAQABAP8B AQABAAEDCYgFAIgDAAAAAAAAEPAIAAAAtQHwAlkORAoPABHwEAAAAAAAwwsIAAAAAAAAAAsAUAEP AATwpgAAABIACvAIAAAAA/QGACACAABjAAvwJAAAAAQAAAAAAIAAJH/7AL8BAQABAP8BAQABAAED CogFAIgDAAAAAAAAEPAIAAAA1gpOAvoOGhUPABHwEAAAAAAAwwsIAAAAAQAAAAwAUAEPAA3wOgAA AAAAnw8EAAAAAgAAAAAAoQ8UAAAAAQAAAAAAAAAAAAEAAAAAAAIAFAAAAKoPCgAAAAEAAAABAAAA AAAPAATwSAAAABIACvAIAAAAAfQGAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMBykJrAJQBc4mN AL8BHgAfAP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAA////AAAAAACWlpYAAAAAAADMmQAzM8wA zMz/ALKysgAPAPAD9AEAAAEA8QMIAAAASAIAAAcADDAPAAwEtAEAAA8AAvCsAQAAwAEI8AgAAAAD AAAAAwQHAA8AA/BEAQAADwAE8CgAAAABAAnwEAAAAAYAAACWAQAAAAAAAAYAAAACAArwCAAAAAAE BwAFAAAADwAE8F4AAAASAArwCAAAAAIEBwAgAgAAUwAL8B4AAAAEAAAAAAC/AQEAAQD/AQEAAQAB AwmIBQCIAwAAAAAAABDwCAAAALUB8AJZDkQKDwAR8BAAAAAAAMMLCAAAAAAAAAALAFABDwAE8KYA AAASAArwCAAAAAMEBwAgAgAAYwAL8CQAAAAEAAAAAACAAOR/+wC/AQEAAQD/AQEAAQABAwqIBQCI AwAAAAAAABDwCAAAANYKTgL6DhoVDwAR8BAAAAAAAMMLCAAAAAEAAAAMAFABDwAN8DoAAAAAAJ8P BAAAAAIAAAAAAKEPFAAAAAEAAAAAAAAAAAABAAAAAAACABAAAACqDwoAAAABAAAAAQAAAAAADwAE 8EgAAAASAArwCAAAAAEEBwAADAAAgwAL8DAAAACBAQAAAAiDAQUAAAiTAcpCawCUAXOJjQC/AR4A HwD/AQAACAAEAwkAAAA/AwEAAQAQAPAHIAAAAP///wAAAAAAlpaWAAAAAAAAzJkAMzPMAMzM/wCy srIADwDwA/IBAAABAPEDCAAAAEoCAAAHAAwwDwAMBLIBAAAPAALwqgEAANABCPAIAAAAAwAAAAMU BwAPAAPwQgEAAA8ABPAoAAAAAQAJ8BAAAAAQAAAAaAAAAAYAAABsAAAAAgAK8AgAAAAAFAcABQAA AA8ABPBeAAAAEgAK8AgAAAACFAcAIAIAAFMAC/AeAAAABAAAAAAAvwEBAAEA/wEBAAEAAQMJiAUA iAMAAAAAAAAQ8AgAAAC1AfACWQ5ECg8AEfAQAAAAAADDCwgAAAAAAAAACwBQAQ8ABPCkAAAAEgAK 8AgAAAADFAcAIAIAAGMAC/AkAAAABAAAAAAAgACkgPsAvwEAAAEA/wEAAAEAAQMKiAUAiAMAAAAA AAAQ8AgAAADWCk4C+g4aFQ8AEfAQAAAAAADDCwgAAAABAAAADABQAQ8ADfA4AAAAAACfDwQAAAAC AAAAAACoDwgAAABNb3Rvcm9sYQAAoQ8UAAAACQAAAAAAAAAAAAkAAAAAAAIAEAAPAATwSAAAABIA CvAIAAAAARQHAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMBykJrAJQBc4mNAL8BHgAfAP8BAAAI AAQDCQAAAD8DAQABABAA8AcgAAAA////AAAAAACWlpYAAAAAAADMmQAzM8wAzMz/ALKysgAPAPAD 3gUAAAEA8QMIAAAASwIAAAcADDAPAAwEngUAAA8AAvCWBQAA4AEI8AgAAAADAAAAAxwHAA8AA/Au BQAADwAE8CgAAAABAAnwEAAAAAYAAACZAQAAAAAAAAYAAAACAArwCAAAAAAcBwAFAAAADwAE8F4A AAASAArwCAAAAAIcBwAgAgAAUwAL8B4AAAAEAAAAAAC/AQEAAQD/AQEAAQABAwmIBQCIAwAAAAAA ABDwCAAAALUB8AJZDkQKDwAR8BAAAAAAAMMLCAAAAAAAAAALAFABDwAE8JAEAAASAArwCAAAAAMc BwAgAgAAYwAL8CQAAAAEAAAAAACAAASB+wC/AQAAAQD/AQAAAQABAwqIBQCIAwAAAAAAABDwCAAA ANYKTgL6DhoVDwAR8BAAAAAAAMMLCAAAAAEAAAAMAFABDwAN8CQEAAAAAJ8PBAAAAAIAAAAAAKgP 3AMAAEEgc2lnbmlmaWNhbnQgYXBwbGljYXRpb24gb2YgTDJUUCBoYXMgZW1lcmdlZCwga25vd24g YXMgYGB2b2x1bnRhcnkgdHVubmVsaW5nJycNWzFdLiBJbiB0aGlzIGVudmlyb25tZW50LCB0aGUg TDJUUCB0dW5uZWwgcnVucyBmcm9tIHRoZSBkaWFsLXVwDWNsaWVudCBpdHNlbGYsIHRocm91Z2gg YSBwdWJsaWMgSVAgaW5mcmFzdHJ1Y3R1cmUsIGFuZCB0aGVuDXRlcm1pbmF0aW5nIGF0IHRoZSB0 YXJnZXQgTE5TLiBCZWNhdXNlIHRoaXMgbW9kZSBvZiBvcGVyYXRpb24NcmVzdWx0cyBpbiB0aGUg TDJUUCBoZWFkZXIgdHJhdmVyc2luZyB0aGUgc2xvdywgaGlnaC1sYXRlbmN5IGRpYWwtdXANbGlu aywgZWFjaCBieXRlIG9mIHR1bm5lbCBvdmVyaGVhZCBjYW4gaGF2ZSBhIG1lYXN1cmFibGUgaW1w YWN0IG9uDXRoZSBvcGVyYXRpb24gb2YgdGhlIGNhcnJpZWQgcHJvdG9jb2xzLg1bMV0gRy4gWm9y biwgYGBSQURJVVMgQXR0cmlidXRlcyBmb3IgVHVubmVsIFByb3RvY29sIFN1cHBvcnQnJywgSW50 ZXJuZXQNZHJhZnQsIEF1Z3VzdCAxOTk5DUZvcnR1bmF0ZWx5LCBzZXZlcmFsIHNpbXBsaWZ5aW5n IGFzc3VtcHRpb25zIG1heSBiZSBtYWRlIGluIHRoZQ12b2x1bnRhcnkgdHVubmVsaW5nIGVudmly b25tZW50Og0tIFRoZSBjbGllbnQgd2lsbCBub3Qgb3BlcmF0ZSB0aHJvdWdoIGEgTkFUIGludGVy ZmFjZQ0tIFRoZSBjbGllbnQgdXNlcyBhIHNpbmdsZSBJUCBhZGRyZXNzIGZvciB0aGUgbGlmZSBv ZiB0aGUgdHVubmVsDS0gVGhlIGNsaWVudCBoYXMgb25seSBvbmUgcHVibGljIElQIG5ldHdvcmsg aW50ZXJmYWNlDS0gVGhlcmUgbWF5IGJlIG9ubHkgb25lIHR1bm5lbCBiZXR3ZWVuIHRoZSBjbGll bnQgYW5kIGl0cyBMTlMNLSBUaGVyZSB3aWxsIGJlIG9ubHkgb25lIHNlc3Npb24gd2l0aGluIGEg dHVubmVsDS0gQWxpZ25tZW50IGlzIG5vdCByZXF1aXJlZA0tIFBhY2tldCBsZW5ndGggaXMgcHJl c2VydmVkIGJ5IHRoZSBJUCBoZWFkZXIAAKoPLAAAAAIAAAAAAAAADAAAAAEAAAAAALIBAAAAAAAA BQAAAAEAAAADABgCAAAAAAAADwAE8EgAAAASAArwCAAAAAEcBwAADAAAgwAL8DAAAACBAQAAAAiD AQUAAAiTAcpCawCUAXOJjQC/AR4AHwD/AQAACAAEAwkAAAA/AwEAAQAQAPAHIAAAAP///wAAAAAA lpaWAAAAAAAAzJkAMzPMAMzM/wCysrIADwDwA9ACAAABAPEDCAAAAE4CAAAHAAwwDwAMBJACAAAP AALwiAIAAEABCPAIAAAAAwAAAAM0BwAPAAPwIAIAAA8ABPAoAAAAAQAJ8BAAAACSAQAAAAAAAAYA AACTAQAAAgAK8AgAAAAANAcABQAAAA8ABPBeAAAAEgAK8AgAAAACNAcAIAIAAFMAC/AeAAAABAAA AAAAvwEBAAEA/wEBAAEAAQMJiAUAiAMAAAAAAAAQ8AgAAACvAQEDag4+Cg8AEfAQAAAAAADDCwgA AAAAAAAACwBQAQ8ABPCCAQAAEgAK8AgAAAADNAcAIAIAAGMAC/AkAAAABAAAAAAAgAAkfPsAvwEA AAEA/wEAAAEAAQMKiAUAiAMAAAAAAAAQ8AgAAADWCk4C+g4aFQ8AEfAQAAAAAADDCwgAAAABAAAA DABQAQ8ADfAWAQAAAACfDwQAAAACAAAAAACoD4wAAABDVURQKyBpbmNsdWRlcyB0aGUgd2hvbGUg UlRQIGhlYWRlciBhbmQgbWF5IGluY2x1ZGUgdGhlIGRlbHRhSSBhbmQgZGVsdGFULCBzbyBhbGwg dGhlIHN0YXRlIHBhcmFtZXRlcnMgYXQgdGhlIGRlY29tcHJlc3NvciBjYW4gYmUgcmVzdG9yZWQN DQAAoQ8eAAAAjQAAAAAAAAAAAIwAAAAAAAIAGAABAAAAAAACABIAAACqD0gAAAA4AAAAAAAAAAcA AAABAAAAAwAEAAAAAAAAAAYAAAABAAAAAwAlAAAAAAAAAA0AAAABAAAAAwARAAAAAAAAAAEAAAAB AAAAAAAPAATwSAAAABIACvAIAAAAATQHAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMBykJrAJQB c4mNAL8BHgAfAP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAA////AAAAAACWlpYAAAAAAADMmQAz M8wAzMz/ALKysgAQABEQnRAAAABGAAB4nO1beXBcxZn/3v1mYkvPtnxiS4NsYtk6PJYskINBI1sy kDLgQyq7Egdj2VJs8IWlJJA4hSB416mCkINykCEHJNmE2irl2NrdkCLgHFT4Q1zJZoFUsmsoUsmu SYUk5KrCnnzf190zb7rfWAd2Aol7pvu99+vv6uN9/b3rmaennXjg6/NeBC1dDg6czqfAj2GWzJwi AFsen87n8wrOn09vqXQKc0aO4YW49TDTmAeYQ8wpzGnMb8M8BfNUzBWYK8UUgGmYp2OegbkK80zM szDPxjwH81zM8zBfgHk+5gWYqzHXSJ0qn09/m7QR9uNvEDLQBftwexBu0V3BGdMsnDFKFvmDTGgz flxUry0hvv/Www+94zHLoXpH+ZRrYQ/0TUhnPKXBtuLtGS9fFSj9a7D9e+EA2tELN0xY/3TUTz7Q BeH7xsND9P1yfzNqPwg3om4ahxsnox8m2n6ytedisX9ajhttCVfnPx2f6fw/f87+fSRLLOMlaUuu iiZBF04UCx39ihZKXbkQj+38Mqg5Nkzp/9o7cSpbOBOctJj7+rlPfv/q3TsO7h/Y3z+Y6bp5R9+e zOb9B28c2NXXN8izbPXu/v42nk9c27SJapra4LWV37ip1Cb7uC8sctCirk5Kq8ii03maz0YT+Bw7 cfhzv/3ztbuif/1ECPWL/+2FLGL3y/lN9W3yXMiBWOu2gFjLDsi5fgTEunYPiE562RVrF619qw++ b0dfpnvX/r0HBvbvOzMemf3AOoeuO3n9D1961JKuEO1Snd3KnR1one0fr47Am1k9H5yZ1VnwO+ZC dbn2E2L/+Mkf3990QfSpT2P7G/480knnt4alQrTO9+BH0WjQIfvmReT+mvsdlvES5q3YIxV60zLn Nq1mG7ZbZMNlVggnV1mI/HLV/VhWwP/geM3CoVmMDmku2zmdyxlcfpW5HhG8WPMv+Y+e/lLj/2ZW yZmxxc4x3V1c1nJZgaUF/8k8P2FkOcYtT+A2f+vHZdDrWR3oq3fDdlyxzm3tDKtQa5u13zsj73V4 TuZvfcSeDO+rUE5vtTsf1waM6moX1S5sWLgwu23JpVvr1MHWJdXuhTh35pfUv3tj3873lBLVYmC5 oEjUlC2Vg8dEtRiHt1an0qRJ0ktgKTQDbCN8aUZplodb66RiBdQ21nJtbhuyNsES/CFrnK+USeNo hwZ4R6kyYVupPjYtprK9vSjiYqjHni4qVfwGs8Z5QkYsv+doXaXjGcIthb82PtyeIA7/gLiFEXEx qf6sF/R/0vElZfCGMvjSMnjKwD9luxANOXnaThvyeTt9yOXtjKGAtzAEvK0a8vKfRI/dxry4IAOH g7Kg2JAR3BkiSBZDQ1wC7Rw/fhw3uL/nCDxdkRUyfn5fsSP6R2F0VMjlWDO2wyjx0hZpRvOUR7F6 GIaJZxh5h3E7Ogwt/XloGR1FHKkpD2PGkLi/fxiOHj0KSAAtwwi04B/zMGfEWpAXga1RBTiFVlK6 3iL/fRj9+C8oVLV9WLNr+8HB5YQ8RIsweieOLhj57NIY0kzIP9fHkJY7OfSxYMRyac+djQ5J3P2w 4HX4Mq+SlNEfXtF0SfPKzJqN3eszV3auW5NZns3sHejbMaekpqNjXWOrUdVtcM0trSphm6XqdKbZ 8YoSljzYbgiXByKcObfJlTnliuDqwYUjcM3TvQbd1qd6+YJCpe+P9sLd9VFWHXc3jsBXT1VmaUs3 Ieqe+Uz2TwlyVEpbybiEjzyi8dZ0/PGxz085ZFFW2PYPHsgeQ3vJ/rVI70p+dazqblk0Pfsw8h3B 7YiU8XBMzkUQu0GGqXPxCNzxh03Z17DNgxKz4QfY1sezMTJuJ6UXV+3NVmD9s7h/Mep9HcQF2JMz XeZ55QvFulNy2/ZsL7zy/3aW9kkfJcKUvo/dXcm6VmA96aFAfc/bR2Dw2V6pez1efh+EHVjuK3Bl 4T1YPr96pGDjFnjgdr2Pw4yof+IZIUv1W92vP8M6t8K98H2sI+yFCLJHb+jObjzQnf3uE1H23+cd g26s70OctnRMC9DPjlQW6ojvEO6zLjx+3bq3oPt7ElepXW6vRH0r/6ky60veJbJ/ffteeD/1C2aS RVgO81Pv6mZbyY4DaN8r7jFYJ+2lfcLWSbqNyLvl2dL59OAPoizNeZUWYb7nN73wu49UZl+WbX9+ 7THIfVnYu+maA1nCFuP2ppmQpf5xZV/euWQE5my+zVL7X9lVmaX9qH2EbeaRYfvFDbb1uP8VpDuE 2289FmUHZR1l2j+5pzI7m882EeZnSsJ8dbvuI9zvd3B5NZymPsQ5kYFOnBEDcCO8E7d0g6gVZ0UW 1uDeeg4LabbQzElILnj/BXXgHB0K7MIZQc6zgd10g1XmpD0LiSQ7oN2sxtRhXWcdQ+AQ6/6m9d8c 6j9sPSe34tiCBzDytGAnW0uUDQUhJ9qL2xbsLQeuj9Lwzks/VjfHohsndLTu0vvqKLT3C3W7UF8Q q7NwdETdXYtf5SVfXLpYEUfsUVSw+ET+tH0ib9stCH2er3xd2BmFhbY50RS2MY0/QohuQ1QpL+gD ilQJnhqtwHKOdQU0wSUYK6/EAezGYdyIJQ3zlTjQ63hYl+PwZmAvDnofuoMN0QzgPoG3waUg+yPN sF2ERZcTHIIju8rHfXUniozaxk1bgXtdhb1xGG+z8XRyzioxfoKG23xlNwHDrYJBkzTcYcPxqgRm lxg+4T538Dch02224g2Y7rLpdG9wbtkJ04G/ddCI/mAM8zl2moj5DnfdGzDfK9PzEzbdw9+ETHe5 696A6X6ZU3US/e7jb0LGe9xx5YzvjFxeQxZFNL0uijIoVLCfxFjiRL540/nruH5kIiHp2qgK7IQb U29HKT7boNwz6SDZzlmRHRqy10bkADoiurW3AXG8vIAHMaz67ZRSaeS3ycXXY2NbKwAWMIeeiCMT hdIfWtArqeLrza+hOqqmFSJxmVuILRG2ptg+0mMSkp6aaGmSgMRUY41X54XcH0Gkrgny+RTWkiXx /v8iTolB7AU6/BUe38YSkvt/OYgHeyQ/KOn/qRHd3PWsNXwTaQ/O18WRLy/ddI3U1jtR62eJD0lu s0njuxI1krbeMhrp8WPKWo0a9+E6/gGMVHZipLKLNdsFza2YmyM6aR3WQP3Bl76cMGrClZguhymR 6FlwLfNVRVWQlEjGHD5naqPi9U0lzET6arwkvQxbthfV3Yctc6yaQqs8tEnVqzTWeVBuHFSiXvGM 80DPYFdwnbCW/E8fn+GOxFV6tV0gloHYBuIYiGsgnoaUTNicQCwDsQ3EMRDXQDwNifdVKBHLQGwD cQzENRBPQ2L2QSQRy0BsA3EMxDUQT0NiLYcqiVgGYhuIYyCugXgaEutTmCMRy0BsA3EMxDUQT0Pi r5/Ml4hlILaBOAbiGoinIQEUU0YiloHYBuIYiGsgnoaEMV21ErEMxDYQx0BcA/E0JBXTtUgiloHY BuIYiGsgXgzp43Wl6D34SVZLR67oPZ4cpbQ2V/QeAsnmit5DPW3UvUdPTvceXbmi9xBPyS6JeY+4 LsvQZRm6LEOXZeiKe48VMe8R12UbuoT3UM8sde/RY3iPrpj3EH3YHPMecV2OocuJtavV8B49hvfo inmPmsMnN3yzennMe8R1uYYu4T0OXpZ+7gsHVhreo8fwHl0x7/HefkrZmPeI6/IMXZ7RLs/Q5Rm6 hPfYcujxzYceXxbzHnFdvqFLeI/HXqp/9KX6ZsN79Bjeo8vwHsti3iOuKzB0BUa7AkNXYOgKY33Y FPMecV2hoUt4jzsan7+98flmw3v0GN6jK+Y9aGYcPtkY8x5xXSlDl/Aef6jbevd3f68QXVeqRFcf XwFcbqch5Stc3fUo3sGKSu5gTeXzbwqWOzHSov1pbEmE7Xj9od/88Ore9e3bGF/KeD2XtzMyFPPB F9n8+g7GuDZ8x/3r3Bcrxjhvxftidpn7Yj1AV2Afls8bFs2rFP5QrgniHKHnM6EdyX0Z2FqH7iLM KsEEnV2C9TLmFLDeAp1bgv3ubsK8BDq/BOvFK2fhJyrh27Ca1dKLHK+2Uwk5KkMuIy6ruJzD5Xwu M1zWcrkol4ZT8iK/ki33cX5YLFOth3SupvM1pe/RyFc7LgBnpsfHvmC0kVEtbsx4qpTR1hhtxehw KyitYEZb0+hojI5idAumNjOjozG6GqOrGD1kVGsIMboao6cxeoqR3ntRCwIxehqjrzH6ijFARuXd idHXGAONMVCMYaFzBGOgMYYaY6gYUwVTm5gx1BhTGmNKMaaRUTlRYkxpjGmNMX3cp3lk8zxyeR4t ZL9VWfC85L2t/NSimOqV4Akyu4TMLkfmaGR2MpmrkTnJZJ5G5iaT+RqZl0wWaGR+MlmokQXJZCmN LEwmS2tkqdMaGY2JAyCnDzE5sTER07e0s2cK2U5sTIjMKUfmaGR2MpmrkTnJZJ5G5iaT+RqZl0wW aGR+MlmokQXJZCmNLEwmS2tkKZ2MxsTlMXFg3O8tJrxKZ9GpV90KBf/bxUFvqSBHE2SPIajce4s4 EssS/XE5QY4S5GpvCXqaIHcMQa4SRHNDRe8kyNcEeWMI8pSgyby3GBfkK0E0v1TcTYJCTVAwhqBA CQo1i1KaoHAMQaESRHNURcwkKK0JSo0hKKUE0SxW4TDNYl1QegxBcj3weJ5TSbGKJ2OVntzkShGr +CzTkjJ9KbMrN7kyDc/BdPgpXjbcjPHwlfY91j3WL+1ujOynw3+w18zFok+K8GfAXFhAZ68tg1N+ Ymf97YN+CnmJQoS89F6Lis+LIW+lDHlViFsMrpMbvEC6qRjhm7ChhXTWG3puToZHYZ48GczfuZvk N4Vqkm8AmuQNoit8vStKJrkjJzk/233zTXLr/CQ/C5PcDOTF/BMBykI5/0RUU8eRZroY1bzQXl0j gh8/FjQSmR8PGuNkjkZmJ5O5GpmTTOZpZG4yma+ReclkgUbmJ5OFGlmQTJbSyMJksrRGltLJaEwC HhN+OQzdUqAFjT67JRErzkvyRgV5WtAYxIJGCj9QsBBkj1eQrQQ5miBbCHLGK8hRgmjkn+L+WMaC HCHIHa8gVwnySlx3wGGsiBXHJ8hTgvxCPNzAgjwhyB+vIF8Jovn1yUVX4b+JBflCUDBeQYESVLgp MLSUBQVCUDheQaESlNKaFgpBqfEKSilBNItHrnjxg1UjjSwoJQSlxytI+p4Q1M0oWvtCufa15iZX 0to3C1ZU0romAjwK78S2fJA3Ta1/RW+JZqXfjMtCOn2OloU3W0NVOvvr3/n0VkkebIL3wV78bedv v6+CfdDP3yQTMgi7cX/fGfjrwObvFykKz+fH9/0x0Y8W9Heihh1sg3gBfWL2tMHEv3+mFf/ls/ik ZaL6z3Z6I/rX0UMRS3xmQF2yHsTNTfoWll4xp29h6YHNzSC+Yx0C8U0sfRtLL1p9HMQ34fRyOj30 oXElb6O+laW6HbsHduzfdMvAYN/eAYDN+2n8b4hClgtSftIWLwLZT9F4iW93irvNxd0W3hWf+8AU yVMt5RS+Nx7gaefIqgLHQOGhmGiDeukhI9GLZXsul8e0Ty5u2/qrOrdd0XNVZ6G15NGvwfwhWAvL cVYvx20HrMFtI6zA5bwNjxrxiOpacK8NVqL0Ltyjh4dt+MtK+k4ss9AKH57oYE4i/QV98sBTAABy F7AAAAABABAAAAAAAAQAEADeRwAAIgEQALw7AAArATAAPyoAAPA1AACQQgAARgEQAJBkAABTASAA aIgAAJQoAQBWARAANCsBAGMBEAAILQEAbwGgAPlOAADcLgEADU0AANgwAQCkYgAAsDMBAKxzAADT NQEAmHUAAM83AQB8ASAA9YsAAMs5AQB/AUAA4Y0AAMc7AQAjqwAAwT0BAIUBUAB/RgEAsiUBAIeu AAAhSwAAp0MBAAAA9Q8cAAAAAAEAAIMVAAMAAAAAJFcBAAEAAACJAQAAAQAAAP7/AAAEAAIAAAAA AAAAAAAAAAAAAAAAAAEAAADghZ/y+U9oEKuRCAArJ7PZMAAAAGwKAAANAAAAAQAAAHAAAAACAAAA eAAAAAQAAACwAAAABwAAAMAAAAAIAAAAzAAAAAkAAADcAAAAEgAAAOgAAAAKAAAACAEAAAsAAAAU AQAADAAAACABAAANAAAALAEAAA8AAAA4AQAAEQAAAEABAAACAAAA5AQAAB4AAAAuAAAAVHVubmVs ZWQgbXVsdGlwbGV4ZWQgQ29tcHJlc3NlZCBSVFAgKCJUQ1JUUCIpAHdlHgAAAAYAAAB0bWltYQBl ZB4AAAABAAAAAG1pbR4AAAAGAAAAdG1pbWEAZWQeAAAABAAAADMzOQAeAAAAFQAAAE1pY3Jvc29m dCBQb3dlclBvaW50AENvbUAAAAAA0XONigIAAEAAAABAeoQzCSi/AUAAAACgh+SQAcS+AUAAAADw 5YGFqTq/AQMAAAB6AwAARwAAACQJAAD/////AwAAAAgAbxBNDAAAAQAJAAADigQAAAYAKAAAAAAA EQAAACYGDwAYAP////8AABAAAAAAAAAAAAC6AwAAygIAAAkAAAAmBg8ACAD/////AgAAABcAAAAm Bg8AIwD/////BAAbAFROUFAUAMjwADAAAAAAFAAAAEQNeAAAAAAAAAAKAAAAJgYPAAoAVE5QUAAA AgD0AwkAAAAmBg8ACAD/////AwAAAA8AAAAmBg8AFABUTlBQBAAMAAEAAAABAAAAAAAAAAUAAAAL AgAAAAAFAAAADALKAroDBQAAAAQBDQAAAAcAAAD8AgAA////AAAABAAAAC0BAAAIAAAA+gIFAAEA AAAAAAAABAAAAC0BAQAEAAAALQEAAAkAAAAdBiEA8ADQAsADAAAAAAQAAAAtAQAABwAAAPwCAAD/ //8AAAAEAAAALQECAAQAAADwAQAACAAAAPoCAAAAAAAAAAAAAAQAAAAtAQAAEAAAACYGDwAWAP// //8AAFcAAACPAgAAiQEAAMECAAAIAAAAJgYPAAYA/////wEAHAAAAPsCAAAAAAAAAAAAAAAAAAAA AAAAAAAAABgAAACqBwrrSojtd1OI7XfQZ+93qgcK6wAACgAEAAAALQEDAAUAAAAJAgAAAAIFAAAA FAIAAAAABQAAAAIBAgAAABAAAAAmBg8AFgD/////AAC3AgAAjwIAAIEDAADBAgAACAAAACYGDwAG AP////8BAAUAAAAJAgAAAAIFAAAAFAIAAAAAHAAAAPsC7f8AAAAAAACQAQAAAAAAAAAiVGFob21h AABpCAoSSojtd1OI7XfQZ+93aQgKEgAACgAEAAAALQEEAAQAAADwAQMABQAAAAkCTU1NAgUAAAAU AgAAAAAFAAAALgEYAAAABQAAAAIBAQAAAAkAAAAyCqcCbQMBAAAAMQAKAAUAAAAuAQEAAAAFAAAA AgECAAAABQAAAAIBAgAAAAcAAAD8AgEAAAAAAAAABAAAAC0BAwAEAAAALQEBAAcAAAAbBAEBgQOI AFAABAAAAC0BAgAEAAAALQEAAAUAAAAJAk1NTQIFAAAAFAIAAAAAHAAAAPsCwP8AAAAAAACQAQAA AAAAAAAiVGFob21hAACqBwrsSojtd1OI7XfQZ+93qgcK7AAACgAEAAAALQEFAAQAAADwAQQABQAA AAkCwMDAAgUAAAAUAgAAAAAFAAAALgEYAAAABQAAAAIBAQAAACIAAAAyCnoA2QASAAAARXh0ZW5z aW9ucyB0byBDUlRQJAAgABUAIgAjAB0ADgAjACQAHAAUABYAIwAUACYAKAAlACMABQAAAC4BAQAA AAUAAAACAQIAAAAFAAAACQJNTU0CBQAAABQCAAAAAAUAAAAuARgAAAAFAAAAAgEBAAAAIgAAADIK eADXABIAAABFeHRlbnNpb25zIHRvIENSVFAkACAAFQAiACMAHQAOACMAJAAcABQAFgAjABQAJgAo ACUAIwAFAAAALgEBAAAABQAAAAIBAgAAAAUAAAAJAsDAwAIFAAAAFAIAAAAABQAAAC4BGAAAAAUA AAACAQEAAAAoAAAAMgr8AKsAFgAAAFJUUCBNdWx0aXBsZXhpbmcgdXNpbmcoACUAIwAUADIAIwAP ABUADwAjAA8AIgAfAA8AJAAjABQAJAAcAA8AJAAjAAUAAAAuAQEAAAAFAAAAAgECAAAABQAAAAkC TU1NAgUAAAAUAgAAAAAFAAAALgEYAAAABQAAAAIBAQAAACgAAAAyCvoAqQAWAAAAUlRQIE11bHRp cGxleGluZyB1c2luZygAJQAjABQAMgAjAA8AFQAPACMADwAiAB8ADwAkACMAFAAkABwADwAkACMA BQAAAC4BAQAAAAUAAAACAQIAAAAFAAAACQLAwMACBQAAABQCAAAAAAUAAAAuARgAAAAFAAAAAgEB AAAAEgAAADIKPgF8AQcAAABUdW5uZWxzAiUAJAAkACMAIgAPABwABQAAAC4BAQAAAAUAAAACAQIA AAAFAAAACQJNTU0CBQAAABQCAAAAAAUAAAAuARgAAAAFAAAAAgEBAAAAEgAAADIKPAF6AQcAAABU dW5uZWxzAiUAJAAkACMAIgAPABwABQAAAC4BAQAAAAUAAAACAQIAAAAFAAAAAgECAAAABAAAAC0B AwAEAAAALQEBAAcAAAAbBOsB7AGwAdcBBAAAAC0BAgAEAAAALQEAAAUAAAAJAk1NTQIFAAAAFAIA AAAABQAAAAIBAgAAAAQAAAAtAQMABAAAAC0BAQAHAAAAGwSAApICmAFAAQQAAAAtAQIABAAAAC0B AAAFAAAACQJNTU0CBQAAABQCAAAAABwAAAD7Atj/AAAAAAAAkAEAAAAAAAAAIlRhaG9tYQAAaQgK E0qI7XdTiO130Gfvd2kIChMAAAoABAAAAC0BBAAEAAAA8AEFAAUAAAAJAk1NTQIFAAAAFAIAAAAA BQAAAC4BGAAAAAUAAAACAQEAAAAcAAAAMgrFAVQBDgAAAEJydWNlIFRob21wc29uGAAOABYAEwAV AAwAGAAWABYAIQAWABIAFgAWAAUAAAAuAQEAAAAFAAAAAgECAAAABQAAAAkCTU1NAgUAAAAUAgAA AAAFAAAALgEYAAAABQAAAAIBAQAAABgAAAAyCv4BcwELAAAAVG1pbWEgS29yZW4AFwAiAAkAIgAV AAwAGAAWAA4AFQAWAAUAAAAuAQEAAAAFAAAAAgECAAAABQAAAAkCTU1NAgUAAAAUAgAAAAAFAAAA LgEYAAAABQAAAAIBAQAAACEAAAAyCnICSgERAAAAQ2lzY28gU3lzdGVtcyBJbmNQGAAJABIAEwAV AA0AFgAUABIADQAVACIAEgAMAA8AFwASAAUAAAAuAQEAAAAFAAAAAgECAAAABQAAAAIBAgAAAAQA AAAtAQEABAAAAC0BAwAcAAAA+wIQAAcAAAAAALwCAAAAAAECAiJTeXN0ZW0Ad10IZj8HAIoBAAAK AAYAAAAHAIoBAAAKAAQAAAAtAQUABAAAAPABBAAPAAAAJgYPABQAVE5QUAQADAAAAAAAAAAAAAAA AAAJAAAAJgYPAAgA/////wEAAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABAACAAAAAAAAAAAAAAAA AAAAAAACAAAAAtXN1ZwuGxCTlwgAKyz5rkQAAAAF1c3VnC4bEJOXCAArLPmu5AMAAKADAAAQAAAA AQAAAIgAAAADAAAAkAAAAA8AAACkAAAABAAAALwAAAAGAAAAxAAAAAcAAADMAAAACAAAANQAAAAJ AAAA3AAAAAoAAADkAAAAFwAAAOwAAAALAAAA9AAAABAAAAD8AAAAEwAAAAQBAAAWAAAADAEAAA0A AAAUAQAADAAAABgDAAACAAAA5AQAAB4AAAAJAAAAT3ZlcmhlYWQAAFQAHgAAAA0AAABjaXNjb1N5 c3RlbXMAAHQAAwAAAN5oAQADAAAA4gAAAAMAAAAOAAAAAwAAAAwAAAADAAAAAAAAAAMAAAAAAAAA AwAAADEVCAALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAB4QAAAUAAAAEAAAAFRpbWVz IE5ldyBSb21hbgAHAAAAVGFob21hAAYAAABBcmlhbAAMAAAAQ291cmllciBOZXcADwAAAERlZmF1 bHQgRGVzaWduABoAAABNaWNyb3NvZnQgRXhjZWwgV29ya3NoZWV0ADMAAABFeHRlbnNpb25zIHRv IENSVFAgIFJUUCBNdWx0aXBsZXhpbmcgdXNpbmcgVHVubmVscwAHAAAAU3RhdHVzABcAAABDT01Q UkVTU0VEX1VEUCAiVCBiaXSUAB0AAABDT01QUkVTU0VEX1VEUCBwYWNrZXQgZm9ybWF0ABQAAABO T04tUlRQIHN0cmVhbSBmbGFnAC4AAABOT04tUlRQIHN0cmVhbSBmbGFnIGluIHRoZSBGVUxMX0hF QURFUiBwYWNrZXQAIgAAAFJlamVjdGluZyBhIG5ldyBjb21wcmVzc2VkIHN0cmVhbQAsAAAAUmVq ZWN0IHBhY2tldCAgKFVzaW5nIENPTlRFWFRfU1RBVEUgb3Bjb2RlKQAOAAAAVHVubmVsZWQgQ1JU UAAMAAAAQ29tcHJlc3Npb24ADQAAAE11bHRpcGxleGluZwAKAAAAVHVubmVsaW5nABwAAABUdW5u ZWxlZCBDUlRQIEVuY2Fwc3VsYXRpb24ADwAAAE5vIFNsaWRlIFRpdGxlAAwQAAAIAAAAHgAAAAsA AABGb250cyBVc2VkAAMAAAAEAAAAHgAAABAAAABEZXNpZ24gVGVtcGxhdGUAAwAAAAEAAAAeAAAA FQAAAEVtYmVkZGVkIE9MRSBTZXJ2ZXJzAAMAAAABAAAAHgAAAA0AAABTbGlkZSBUaXRsZXMAAwAA AA4AAAAAAACYAAAAAwAAAAAAAAAgAAAAAQAAADYAAAACAAAAPgAAAAEAAAACAAAACgAAAF9QSURf R1VJRAACAAAA5AQAAEEAAABOAAAAewA4AEQAMwAyADAAOQA4ADAALQA5ADUARgAxAC0AMQAxAEQA MwAtAEIAMQBDADAALQA0ADQANAA1ADUAMwA1ADQAMAAwADAAMAB9AAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUgBvAG8AdAAgAEUAbgB0AHIAeQAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYABQH//////////wMAAAAQjYFk m0/PEYbqAKoAuSnoAAAAAAAAAAAAAAAAUGzCgO9AvwHIAAAAQAAAAAAAAABQAGkAYwB0AHUAcgBl AHMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgACAf// //8CAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADeEAAAAAAA AEMAdQByAHIAZQBuAHQAIABVAHMAZQByAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAaAAIA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAACUAAAAAAAAABQBTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAACgAAgEBAAAABQAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAC1AAAAABAAAAAAAACBAAAAggAAAIMAAACEAAAAhQAAAIYAAACHAAAA iAAAAIkAAACKAAAAiwAAAIwAAACNAAAAjgAAAI8AAACQAAAAkQAAAJIAAACTAAAAlAAAAJUAAACW AAAAlwAAAJgAAACZAAAAmgAAAJsAAACcAAAAnQAAAJ4AAACfAAAAoAAAAKEAAACiAAAAowAAAKQA AAClAAAApgAAAKcAAACoAAAAqQAAAKoAAACrAAAArAAAAK0AAACuAAAArwAAALAAAACxAAAAsgAA ALMAAAC0AAAA/v///7YAAAC3AAAAuAAAALkAAAC6AAAAuwAAALwAAAD+////vgAAAL8AAADAAAAA wQAAAMIAAADDAAAAxAAAAP7////QAAAA/f////7////+//////////////////////////3///// //////////7///////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////7///////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////AAD2Dx0AAAAUAAAAX8CR49xXAQAFAPQDAwD//3Rt aW1hCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABSAG8AbwB0ACAARQBuAHQAcgB5AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFgAFAf//////////AwAAABCNgWSbT88R huoAqgC5KegAAAAAAAAAAAAAAABgUIklKj2/AcwAAABAAAAAAAAAAFAAaQBjAHQAdQByAGUAcwAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASAAIB/////wIA AAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAN4QAAAAAAAAQwB1 AHIAcgBlAG4AdAAgAFUAcwBlAHIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAABoAAgD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAJQAAAAAAAAAFAFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAKAACAQEAAAAFAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAALUAAAAAEAAAAAAAAIEAAACCAAAAgwAAAIQAAACFAAAAhgAAAIcAAACIAAAA iQAAAIoAAACLAAAAjAAAAI0AAACOAAAAjwAAAJAAAACRAAAAkgAAAJMAAACUAAAAlQAAAJYAAACX AAAAmAAAAJkAAACaAAAAmwAAAJwAAACdAAAAngAAAJ8AAACgAAAAoQAAAKIAAACjAAAApAAAAKUA AACmAAAApwAAAKgAAACpAAAAqgAAAKsAAACsAAAArQAAAK4AAACvAAAAsAAAALEAAACyAAAAswAA ALQAAAD+////tgAAALcAAAC4AAAAuQAAALoAAAC7AAAAvAAAAP7///++AAAAvwAAAMAAAADBAAAA wgAAAMMAAADEAAAA/v/////////////////////////QAAAA/f////7////+/////f////////// /////v////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////v////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////8AAPYPHQAAABQAAABfwJHj3FcBAAUA9AMDAP//dG1pbWEI AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAACAAAAAwAAAAQAAAAFAAAABgAAAAcAAAAIAAAA/v// /woAAAALAAAADAAAAA0AAAAOAAAADwAAABAAAAARAAAAEgAAABMAAAAUAAAAFQAAABYAAAAXAAAA GAAAABkAAAAaAAAAGwAAABwAAAAdAAAAHgAAAB8AAAAgAAAAIQAAACIAAAAjAAAAJAAAACUAAAAm AAAAJwAAACgAAAApAAAAKgAAACsAAAAsAAAALQAAAC4AAAAvAAAAMAAAADEAAAAyAAAAMwAAADQA AAA1AAAANgAAADcAAAA4AAAAOQAAADoAAAA7AAAAPAAAAD0AAAA+AAAAPwAAAEAAAABBAAAAQgAA AEMAAABEAAAARQAAAEYAAABHAAAASAAAAEkAAABKAAAASwAAAEwAAABNAAAATgAAAE8AAABQAAAA UQAAAFIAAABTAAAAVAAAAFUAAABWAAAAVwAAAFgAAABZAAAAWgAAAFsAAABcAAAAXQAAAF4AAABf AAAAYAAAAGEAAABiAAAAYwAAAGQAAABlAAAAZgAAAGcAAABoAAAAaQAAAGoAAABrAAAAbAAAAG0A AABuAAAAbwAAAHAAAABxAAAAcgAAAHMAAAB0AAAAdQAAAHYAAAB3AAAAeAAAAHkAAAB6AAAAewAA AHwAAAB9AAAAfgAAAH8AAACAAAAAgQAAAIIAAACDAAAAhAAAAIUAAACGAAAAhwAAAIgAAACJAAAA igAAAIsAAACMAAAAjQAAAI4AAACPAAAAkAAAAJEAAACSAAAAkwAAAJQAAACVAAAAlgAAAJcAAACY AAAAmQAAAJoAAACbAAAAnAAAAJ0AAACeAAAAnwAAAKAAAAChAAAAogAAAKMAAACkAAAApQAAAKYA AACnAAAAqAAAAKkAAACqAAAAqwAAAKwAAACtAAAArgAAAK8AAACwAAAAsQAAALIAAACzAAAAtAAA AP7///+2AAAAtwAAALgAAAC5AAAAugAAALsAAAC8AAAA/v///74AAAC/AAAAwAAAAMEAAADCAAAA wwAAAMQAAAD+////xgAAAMcAAADIAAAAyQAAAMoAAADLAAAAzAAAAP7////9/////f///9AAAAD+ //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////9SAG8AbwB0ACAARQBuAHQAcgB5AAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFgAFAf//////////AwAAABCNgWSbT88RhuoAqgC5 KegAAAAAAAAAAAAAAAAAAAAAAAAAAP7///8AAAAAAAAAAFAAaQBjAHQAdQByAGUAcwAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASAAIB//////////////// AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAN4QAAAAAAAAQwB1AHIAcgBl AG4AdAAgAFUAcwBlAHIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABoA AgEBAAAA//////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADFAAAAABAA AAAAAAAFAFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAKAACAQIAAAAFAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAALUAAAAAEAAAAAAAAFAAbwB3AGUAcgBQAG8AaQBuAHQAIABEAG8AYwB1AG0AZQBuAHQA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAIB////////////////AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAACQAAAABYAQAAAAAABQBEAG8AYwB1AG0AZQBuAHQAUwB1AG0A bQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAADgAAgEEAAAA//////////8A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC9AAAAABAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAA --=====================_4754281==_-- From rem-conf Tue Dec 07 19:10:27 1999 From rem-conf-request@es.net Tue Dec 07 19:10:26 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11vXQJ-0006Qk-00; Tue, 7 Dec 1999 19:05:47 -0800 Received: from cs.columbia.edu [128.59.16.20] by mail1.es.net with esmtp (Exim 1.81 #2) id 11vXQH-0006QX-00; Tue, 7 Dec 1999 19:05:45 -0800 Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id WAA21463; Tue, 7 Dec 1999 22:05:41 -0500 (EST) Sender: hgs@cs.columbia.edu Message-ID: <384DCAFF.3C901E52@cs.columbia.edu> Date: Tue, 07 Dec 1999 22:05:35 -0500 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Bill Foster CC: rem-conf@es.net Subject: Re: Named signaling events - minor request. References: <4.2.0.58.19991206192731.01c805e0@redale.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Bill Foster wrote: > > One minor comment/request for "draft-ietf-avt-tones-03.txt". > > It would be nice to have a separate named signaling event (NSE) for ringing versus ring-back. This seems reasonable. The only minor complications are naming (since there's the potential for confusion between ringing tone = ringback and "ring") and that this tone doesn't have a canonical representation. To minimize the confusion, I used the term "alert". My suggested wording is: --- begin spec excerpt --- \item[Alert:] This named signal event causes the recipient to generate an alert signal (``ringing''). The tone rendition is up to the receiver. (This differs from the ringing tone, below, heard by the {\bf caller}.) --- end excerpt --- Please let me know if this definition is clear enough. A meta comment: since the last call periods are over, I will now declare a last and final chance. Any tone request, however reasonable, that doesn't reach me by tomorrow 5 pm EST will not be included in this round so that I can package up -04 and get this to the IESG, finally. Additional requests will have to wait > > The place where a NSE for ringback tone comes in useful is in a device control situation using MGCP or Megacop. The particular case is where the Media Gateway Controller (MGC) requests the media gateway (MG) to do ringback from the far end as follows: > > Call between two residential media gateways MG A and MG B > - MG A originates a call to MG B > - once the MGC sets up a half duplex connection from MG B it requests ringing and ringback to MGB (in MGCP S: rg, rt@connection) > - if during the capabilities exchange earlier when the half duplex connection was set up (SDP passed between endpoints), the endpoints realized that they supported ringback tone using NSEs, they might use the NSE rather than a tone (some advantages in terms of use of bandwidth prior to call, as well as implementation advantages - MIPS required etc.). > > On the other hand, the same MG may be used in other RTP trunking applications where an MGC may set up the trunk and NSE's used for signaling (e.g. ringing request passed across the RTP stream). > > If we leave ringing and ringback as the same event that depends on context (like hook status) there are problems in the trunking application. If one end sends a ringing request to the other end - but when it gets there the person just happens to have gone off-hook (because they wanted to originate a call just as a call was coming in) - if the MG is left to interpret the meaning of the ringing NSE event based on hook-status - they will suddenly hear ringback - not quite what was intended. > > In Summary: > > Any chance of getting to separate NSE events - one for ringing and another for ringback - they are both useful but only if the are separate events. > > Bill > ----------------------------- > Bill Foster > Phone: (408) 527-8791 > Page: (800) 365-4578 > Fax: (781) 998-6492 -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From rem-conf Wed Dec 08 04:10:23 1999 From rem-conf-request@es.net Wed Dec 08 04:10:21 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11vfry-0002dd-00; Wed, 8 Dec 1999 04:06:54 -0800 Received: from ftpbox.mot.com [129.188.136.101] by mail1.es.net with esmtp (Exim 1.81 #2) id 11vfrw-0002dT-00; Wed, 8 Dec 1999 04:06:52 -0800 Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (MOT-ftpbox 1.0) with ESMTP id FAA22688; Wed, 8 Dec 1999 05:06:46 -0700 (MST)] Received: [from hpux4.miel.mot.com (hpux4.miel.mot.com [217.1.84.89]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id FAA16190; Wed, 8 Dec 1999 05:06:37 -0700 (MST)] Received: from miel.mot.com (pc84156.miel.mot.com [217.1.84.156]) by hpux4.miel.mot.com (8.9.3/8.9.3) with ESMTP id RAA25921; Wed, 8 Dec 1999 17:40:21 +0530 (IST) Message-ID: <384EDD2C.30F12C7E@miel.mot.com> Date: Wed, 08 Dec 1999 17:35:24 -0500 From: GeeVarghese John Organization: Motorola India Electronics Ltd. X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Tmima Koren CC: casner@cisco.com, micke@cdt.luth.se, brucet@cisco.com, dwing@cisco.com, pruddy@cisco.com, rem-conf@es.net, gvjohn@miel.mot.com Subject: Re: Extensions to CRTP References: <4.1.19991118024030.01aeaa50@jindo.cisco.com> <4.1.19991207120640.04132ed0@jindo.cisco.com> Content-Type: multipart/alternative; boundary="------------2469912007B0B7FB30D56393" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --------------2469912007B0B7FB30D56393 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Tmima, It is a good news for me that you added the bit solution in CS packet for contex invalidation. I remeber on 15 April 1999 when I pointed out this problem and this soln to Steven Casener the response I got from him was not in favour of this idea. He just replied :: >>> you can't just have an error flag. May be I didnot communicate properly. Anyway this solution is in place though the ownership is for different people, No problem. Could you please send me the latest draft ... Thanks & Rgds GVJ Tmima Koren wrote: > At 10:45 PM 12/7/99 -0500, GeeVarghese John wrote: > >> Tmima, >> >> I wanted to ask you some doubts on ACCEPT/REJECT packet in CRTP >> extension draft.. >> It is a continuation of the old mail. In you answer below, though >> you wrote the >> ACCPET/REJECT packe is optional, I think definition of these packet >> are bit confusing. >> First of all I feel no need of a ACCEPT packet >> Second Why to have a REJECT packet as separate packet to invalidate >> the context .. >> Why cant we use CONTEXT_STATE packet for the same .. >> We can have a bit in CS packet indicating that context need to be >> invalidated or >> resynchronised using FH packet. If there is no CS packet it is >> assumed that >> flow ACCEPT. > > > Yes, we suggested two formats for the REJECT packet: one is using a > new code, and the other is using the CS with an extra bit > See attached presentation (presented in DC) > We also prefer to use the 'CS + extra bit' format > Tmima > > > >> Here the issue of interoperability also arise when an implementation >> interopeate with the >> old CRTP (2508) implemnetation new implemetation expected ACCEPT or >> REJECT packet >> for each FH packet .. If it does not receive either packet what >> action compressor is expected to take. To make interoperation >> possible there is a need for some sort of negotiation, here also a >> protocol level negotiation is expected .. >> So I feel the approach with ACCEPT/REJECT packet is not optimal. >> But the solution I suggested does not cause any interoptation issue >> also. >> No extra packet overhead, no protocol modification etc ... >> >> Could please answer your points on this .. > > > All the enhancements are not backward compatible so we'll have to > change the negotiation: maybe negotiate a version of CRTP, or > negotiate the new options separately > Tmima > > > >> Thanks & Rgds >> >> GVJ >> >> > >> > >> >> Q3) Section III : Acknowledgement to a new compressed stream >> >> >> >> Context Invalidation was one point which I had pointed out to >> >> Steve/tmima long time back .. >> >> I am having those mails with me .. >> >> >> >> But, (i) Do we need ACCEPT and REJECT packet ?? >> >> Having a NACK mechnism sounds reasonable .. >> >> I feel there shouldnt be both .. >> >> But what compressor is supposed to do after sending the first >> >> FULL_HEADER packet >> >> when compressor waiting for the ACCEPT or REJECT >> >> should it queue the packets till the reply/or timeout >> >> or Should it send the compressed packets assuming the >> >> decompressor will drop if there are >> >> REJECT state at the decompressor side. >> >> >> >> But (ii) what about the backword compatibility issue because this >> >> ACCEPT/REJECT mechanism has dependancy and it will not work with >> >> CRTP-2508 >> >> >> >> As per the current proposal we need to send ACCEPT/REJECT packet >> >> for every >> >> FULL_HEADER packet ... (iii)Is it not adding extra bandwidth >> >> consuption .. >> >> Draft talks about FULL_HEADER retransmit as well .. >> > >> > The REJECT packet is useful when the decompressor runs out of >> > resources. The compressor initiates compression of a stream by >> > sending a FH. With CRTP today the decompressor can send a CS to >> > invalidate the context, but the compressor does not know the reason >> > and will attempt to compress this stream again. A REJECT will >> > notify the compressor that the decompressor cannot handle >> > compresstion of additional streams at this moment. >> > An implementation that was not enhanced to use REJECT will still >> > use CS to invalidate the context each time the compressor attempts >> > to compress the stream. >> > The compressor continues to send the compressed packets of the >> > stream until he receives CS or REJECT >> > The intent is to make the ACCEPT/REJECT packet optional - an >> > optimization. >> > >> > Tmima >> -- ------------------------------------------------------------------------------- [ ] Motorola Confidential Proprietory [ ] Motorola Internal Use Only [x] Not an MCP or MIU ------------------------------------------------------------------------------- Geevarghese John, DataCom Group, Motorola India Electronics Ltd, "The Senate", No-33 A, Ulsoor Road, Bangalore - 42. Phone : 91-80-5598615 Xnt-4005 E-mail : gvjohn@miel.mot.com ------------------------------------------------------------------------------- ------------------------------------------------------------------------------- --------------2469912007B0B7FB30D56393 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Tmima,

It is a good news for me that you added the bit solution in CS packet for contex invalidation.
I remeber on 15 April 1999 when I pointed out this problem and this soln to Steven Casener
the response I got from him was not in favour of this idea. He just replied ::
>>> you can't just have an error flag.
May be I didnot communicate properly.
Anyway this solution is in place though the ownership is for different people, No problem.

Could you please send me the latest draft ...

Thanks & Rgds
GVJ

Tmima Koren wrote:

 At 10:45 PM 12/7/99 -0500, GeeVarghese John wrote:
Tmima,

I wanted to ask you some doubts on ACCEPT/REJECT packet in CRTP extension draft..
It is a continuation of the old mail. In you answer below, though you wrote the
ACCPET/REJECT packe is optional, I think definition of these packet are bit confusing.
First of all I feel no need of a ACCEPT packet
Second Why to have a REJECT packet as separate packet to invalidate the context ..
Why cant we use CONTEXT_STATE packet for the same ..
We can have a bit in CS packet  indicating that context need to be invalidated or
resynchronised using FH packet. If there is no CS packet it is assumed that
flow ACCEPT.


Yes, we suggested two formats for the REJECT packet: one is using a new code, and the other is using the CS with an extra bit
See attached presentation (presented in DC)
We also prefer to use the 'CS + extra bit' format
Tmima
 
 

Here the issue of interoperability also arise when an implementation interopeate with the
old CRTP (2508) implemnetation new implemetation expected ACCEPT or REJECT packet
for each FH packet .. If it does not receive either packet what action compressor is expected to take. To make interoperation possible there is a need for some sort of negotiation, here also a protocol level negotiation is expected ..
So I feel the approach with ACCEPT/REJECT packet is not optimal.
But the solution I suggested  does not cause any interoptation issue also.
No extra packet overhead, no protocol modification etc  ...

Could please answer your points on this ..


All the enhancements are not backward compatible so we'll have to change the negotiation: maybe negotiate a version of CRTP, or negotiate the new options separately
Tmima
 
 

Thanks & Rgds

GVJ

 
Q3) Section III : Acknowledgement to a new compressed stream

Context Invalidation was one point which I had pointed out to Steve/tmima long time back ..
I am having those mails with me ..

But, (i) Do we need ACCEPT and REJECT packet  ??
Having a NACK mechnism sounds reasonable ..
I feel there shouldnt be both ..
But what compressor is supposed to do after sending the first FULL_HEADER packet
when compressor waiting for the ACCEPT or REJECT
should it queue the packets till the reply/or timeout
or Should it send the compressed packets assuming the decompressor will drop if there are
REJECT state at the decompressor side.

But (ii) what about the backword compatibility issue because this ACCEPT/REJECT mechanism has dependancy and it will not work with CRTP-2508

As per the current proposal we need to send ACCEPT/REJECT packet for every
FULL_HEADER packet ... (iii)Is it not adding extra bandwidth consuption ..
Draft talks about FULL_HEADER retransmit as well ..

The REJECT packet is useful when the decompressor runs out of resources. The compressor initiates compression of a stream by sending a FH. With CRTP today the decompressor can send a CS to invalidate the context, but the compressor does not know the reason and will attempt to compress this stream again. A REJECT will notify the compressor that the decompressor cannot handle compresstion of additional streams at this moment.
An implementation that was not enhanced to use REJECT will still use CS to invalidate the context each time the compressor attempts to compress the stream.
The compressor continues to send the compressed packets of the stream until he receives CS or REJECT
The intent is to make the ACCEPT/REJECT packet optional - an optimization.

Tmima

--
-------------------------------------------------------------------------------
[ ]  Motorola Confidential Proprietory
[ ]  Motorola Internal Use Only
[x]  Not an MCP or MIU
-------------------------------------------------------------------------------
Geevarghese John,
DataCom Group,
Motorola India Electronics Ltd,
"The Senate", No-33 A,
Ulsoor Road,
Bangalore - 42.
Phone  : 91-80-5598615  Xnt-4005
E-mail : gvjohn@miel.mot.com
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
  --------------2469912007B0B7FB30D56393-- From rem-conf Wed Dec 08 06:44:44 1999 From rem-conf-request@es.net Wed Dec 08 06:44:43 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11viIZ-0004Eb-00; Wed, 8 Dec 1999 06:42:31 -0800 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 11viIX-0004D4-00; Wed, 8 Dec 1999 06:42:30 -0800 Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 8 Dec 1999 14:42:23 +0000 To: rem-conf@es.net Subject: WG last call announcement Date: Wed, 08 Dec 1999 14:42:22 +0000 Message-ID: <3354.944664142@cs.ucl.ac.uk> From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This message is to announce the start of a two week working group last call on the following drafts: Civanlar and Cash, "RTP Payload Format for Real-Time Pointers", draft-ietf-avt-pointer-00.txt Hellstrom, "RTP Payload for Text Conversation", draft-ietf-avt-rtp-text-02.txt If no comments requiring substantive changes are received in the next two weeks (by 22nd December), these drafts will be submitted for publication as standards track RFCs. Colin From rem-conf Wed Dec 08 07:16:12 1999 From rem-conf-request@es.net Wed Dec 08 07:16:12 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11vil2-0004zq-00; Wed, 8 Dec 1999 07:11:56 -0800 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 11vil0-0004zg-00; Wed, 8 Dec 1999 07:11:55 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06645; Wed, 8 Dec 1999 10:11:51 -0500 (EST) Message-Id: <199912081511.KAA06645@ietf.org> To: IETF-Announce: ; Cc: RFC Editor Cc: Internet Architecture Board Cc: rem-conf@es.net From: The IESG Subject: Document Action: Sampling of the Group Membership in RTP to Experimental Date: Wed, 08 Dec 1999 10:11:51 -0500 Sender: scoya@cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list The IESG has approved the Internet-Draft 'Sampling of the Group Membership in RTP' as an Experimental RFC. This document is the product of the Audio/Video Transport Working Group. The IESG contact persons are Scott Bradner and Vern Paxson From rem-conf Wed Dec 08 08:55:15 1999 From rem-conf-request@es.net Wed Dec 08 08:55:14 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11vkHj-0006Ll-00; Wed, 8 Dec 1999 08:49:47 -0800 Received: from redale.cisco.com [171.71.154.68] by mail1.es.net with esmtp (Exim 1.81 #2) id 11vkHi-0006LS-00; Wed, 8 Dec 1999 08:49:46 -0800 Received: from bfoster-nt (dhcp-71-147-186.cisco.com [171.71.147.186]) by redale.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id IAA06265; Wed, 8 Dec 1999 08:48:12 -0800 (PST) Message-Id: <4.2.0.58.19991208083306.018d8230@redale.cisco.com> X-Sender: bfoster@redale.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 08 Dec 1999 08:42:13 -0800 To: Henning Schulzrinne From: Bill Foster Subject: Re: Named signaling events - minor request. Cc: rem-conf@es.net In-Reply-To: <384DCAFF.3C901E52@cs.columbia.edu> References: <4.2.0.58.19991206192731.01c805e0@redale.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Usually alerting is coming from the far end (callee to caller) as in Q.931. How about: Caller => Callee: Ringing Caller <= Callee: Alerting At 10:05 PM 12/7/99 -0500, Henning Schulzrinne wrote: >Bill Foster wrote: > > > > One minor comment/request for "draft-ietf-avt-tones-03.txt". > > > > It would be nice to have a separate named signaling event (NSE) for ringing versus ring-back. > >This seems reasonable. The only minor complications are naming (since >there's the potential for confusion between ringing tone = ringback and >"ring") and that this tone doesn't have a canonical representation. To >minimize the confusion, I used the term "alert". My suggested wording >is: > >--- begin spec excerpt --- > >\item[Alert:] This named signal event causes the recipient to generate >an alert signal (``ringing''). The >tone rendition is up to the receiver. (This differs from the ringing >tone, below, heard by the {\bf caller}.) > >--- end excerpt --- > >Please let me know if this definition is clear enough. > >A meta comment: since the last call periods are over, I will now declare >a last and final chance. Any tone request, however reasonable, that >doesn't reach me by tomorrow 5 pm EST will not be included in this round >so that I can package up -04 and get this to the IESG, finally. >Additional requests will have to wait > > > > > The place where a NSE for ringback tone comes in useful is in a device control situation using MGCP or Megacop. The particular case is where the Media Gateway Controller (MGC) requests the media gateway (MG) to do ringback from the far end as follows: > > > > Call between two residential media gateways MG A and MG B > > - MG A originates a call to MG B > > - once the MGC sets up a half duplex connection from MG B it requests ringing and ringback to MGB (in MGCP S: rg, rt@connection) > > - if during the capabilities exchange earlier when the half duplex connection was set up (SDP passed between endpoints), the endpoints realized that they supported ringback tone using NSEs, they might use the NSE rather than a tone (some advantages in terms of use of bandwidth prior to call, as well as implementation advantages - MIPS required etc.). > > > > On the other hand, the same MG may be used in other RTP trunking applications where an MGC may set up the trunk and NSE's used for signaling (e.g. ringing request passed across the RTP stream). > > > > If we leave ringing and ringback as the same event that depends on context (like hook status) there are problems in the trunking application. If one end sends a ringing request to the other end - but when it gets there the person just happens to have gone off-hook (because they wanted to originate a call just as a call was coming in) - if the MG is left to interpret the meaning of the ringing NSE event based on hook-status - they will suddenly hear ringback - not quite what was intended. > > > > In Summary: > > > > Any chance of getting to separate NSE events - one for ringing and another for ringback - they are both useful but only if the are separate events. > > > > Bill > > ----------------------------- > > Bill Foster > > Phone: (408) 527-8791 > > Page: (800) 365-4578 > > Fax: (781) 998-6492 > >-- >Henning Schulzrinne http://www.cs.columbia.edu/~hgs ----------------------------- Bill Foster Phone: (408) 527-8791 Page: (800) 365-4578 Fax: (781) 998-6492 From rem-conf Wed Dec 08 11:57:44 1999 From rem-conf-request@es.net Wed Dec 08 11:57:43 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11vn3u-0000v1-00; Wed, 8 Dec 1999 11:47:42 -0800 Received: from tnt.isi.edu [128.9.128.128] by mail1.es.net with esmtp (Exim 1.81 #2) id 11vn3t-0000un-00; Wed, 8 Dec 1999 11:47:41 -0800 Received: from rum.isi.edu (rum-e.isi.edu [128.9.160.237]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA28663 for ; Wed, 8 Dec 1999 11:47:40 -0800 (PST) Received: (from touch@localhost) by rum.isi.edu (8.8.7/8.8.6) id LAA13665; Wed, 8 Dec 1999 11:47:40 -0800 (PST) Message-Id: <199912081947.LAA13665@rum.isi.edu> To: rem-conf@es.net Date: Tue, 07 Dec 1999 16:53:45 -0800 From: Joe Touch Reply-To: sigcomm2000-info@acm.org Organization: Sigcomm 2000 MIME-Version: 1.0 Subject: Sigcomm 2000 CFP Content-Type: multipart/mixed; boundary="------------F90EB79E2531E0F3907217D3" X-Lines: 507 Old-Status: O X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --------------F90EB79E2531E0F3907217D3 Content-Type: text/plain; charset="us-ascii" X-Sun-Content-Length: 5278 Call for Papers ACM SIGCOMM 2000 Conference Applications, Technologies, Architectures and Protocols for Computer Communications August 28 - September 1, 2000 Grand Hotel, Stockholm, Sweden http://www.acm.org/sigcomm/sigcomm2000 Sponsored by Ericsson, Sprint, and Telia Important dates Paper submission: January 28, 2000 Tutorial proposals: February 28, 2000 Paper acceptance: April 21, 2000 http://www.acm.org/sigcomm/sigcomm2000 sigcomm2000-info@acm.org The SIGCOMM 2000 conference seeks papers describing significant research contributions to the field of computer and data communication networks. Authors are invited to submit full papers concerned with both theory and practice. Areas of interest include, but are not limited to: - Distributed application networking infrastructure. - Distributed common application services, middleware protocols, and signaling. - Routing, switching, and addressing. - Resource sharing, quality of service, multimedia networks, and OS support. - Multimedia networking. - Networking aspects of the WWW. - Heterogeneous internetworking, large-scale networks. - Network management. - Active network architectures and protocols. - Important experimental results from operational networks and lessons learned from prototype implementations. - Wireless networking and support for nomadic computing. - Analysis and design of computer network architectures and algorithms. SIGCOMM 2000 is a single-track, highly selective conference at which successful submissions typically report results firmly substantiated by experiment, implementation, simulation, or mathematical analysis. In addition to the technical program (paper presentations), SIGCOMM 2000 will offer tutorials by noted instructors on the two days preceding the actual conference, and a session during the conference at which speakers may present speculative results and outrageous opinions. Submission Instructions: ------------------------ Papers must be less than 20 double-spaced pages long (formatted for printing in the Proceedings, papers may not be longer than 12 pages), have an abstract of 100-150 words, and be original material that has not been previously published nor is currently under review by another conference or journal. Authors must submit papers electronically, using the instructions at http://www.acm.org/sigcomm/sigcomm2000/submit. Authors not able to comply with these instructions should contact the Program Co-Chairs, or send mail to sigcomm2000-info@acm.org for more information. Papers submitted after the deadline will not be considered without an ahead-of-time extension from the Program Co-Chairs. All submitted papers will be judged based on their quality and relevance through double-blind reviewing, where the identities of the authors are withheld from the reviewers. Consult the on-line submission instructions for information on preparing a manuscript for double-blind review. Authors of accepted papers will need to sign an ACM copyright release form and present their paper at the conference. The Proceedings of the conference will be published as a special issue of ACM SIGCOMM Computer Communication Review. The Program Committee may also select a few papers for possible publication in the IEEE/ACM Transactions on Networking. Electronic copies of the accepted papers will be published on the SIGCOMM 2000 web site prior to the conference unless authors specifically request that this not be done. Tutorials: ---------- SIGCOMM 2000 will begin with two days of full-day and half-day tutorials covering single topics in detail, at both the introductory or advanced level. Individuals interested in submitting tutorial proposals are encouraged to contact the Tutorial Chair before the deadline to discuss the proposed content. Student Paper Award: -------------------- Papers submitted by students may be considered for a student-paper award, which includes full conference registration and a partial travel grant. To be eligible, the student must be the sole author of the paper, or the first author and primary contributor. A cover letter or email to the Program Chairs must identify the paper as a candidate for this competition. SIGCOMM Award: -------------- The keynote speaker at SIGCOMM 2000 will be the 2000 winner of the ACM SIGCOMM Award for lifetime contributions to the field of computer communication. Procedures for nominating candidates for the SIGCOMM Award can be obtained from Craig Partridge (craig@bbn.com). General Co-Chairs Per Gunningberg Steve Pink Uppsala U., Sweden Lulea U. Tech., Sweden perg@docs.uu.se steve@cdt.luth.se +46 18 471 3171 +46 920 72529 Program Co-Chairs Christophe Diot Jim Kurose Sprint ATL, USA U. Massachusetts, USA cdiot@sprintlabs.com kurose@cs.umass.edu +1 650 375-4539 +1 413 545-2742 Publicity Chair Joe Touch USC/ISI, USA touch@isi.edu (also sigcomm2000-info@acm.org) +1 310 448-9151 Local Arrangements Co-Chairs Bengt Ahlgren Christian Tschudin SICS, Sweden Uppsala U, Sweden Bengt.Ahlgren@sics.se tschudin@docs.uu.se +46 8 633 1562 +46 18 471 1066 Tutorials Chair Steve Pink Lulea U Tech., Sweden steve@cdt.luth.se +46 920 72529 --------------F90EB79E2531E0F3907217D3 Content-Type: text/html; charset="us-ascii"; name="Sc2000CFP-long.html" Content-Disposition: inline; filename="Sc2000CFP-long.html" X-Sun-Content-Length: 8770 Sigcomm 2000 CFP - long
Paper submission: January 28, 2000
Tutorial proposals: February 28, 2000
Paper acceptance: April 21, 2000
The SIGCOMM 2000 conference seeks papers describing significant research contributions to the field of computer and data communication networks. Authors are invited to submit full papers concerned with both theory and practice. Areas of interest include, but are not limited to:
  • Distributed application networking infrastructure.
  • Distributed common application services, middleware protocols, and signaling.
  • Routing, switching, and addressing.
  • Resource sharing, quality of service, multimedia networks, and OS support.
  • Multimedia networking.
  • Networking aspects of the WWW.
  • Heterogeneous internetworking, large-scale networks.
  • Network management.
  • Active network architectures and protocols.
  • Important experimental results from operational networks and lessons learned >from prototype implementations.
  • Wireless networking and support for nomadic computing.
  • Analysis and design of computer network architectures and algorithms.
SIGCOMM 2000 is a single-track, highly selective conference at which successful submissions typically report results firmly substantiated by experiment, implementation, simulation, or mathematical analysis.In addition to the technical program (paper presentations), SIGCOMM 2000 will offer tutorials by noted instructors on the two days preceding the actual conference, and a session during the conference at which speakers may present speculative results and outrageous opinions.

Submission Instructions:

Papers must be less than 20 double-spaced pages long (formatted for printing in the Proceedings, papers may not be longer than 12 pages), have an abstract of 100-150 words, and be original material that has
not been previously published nor is currently under review by another conference or journal.

Authors must submit papers electronically, using the instructions at http://www.acm.org/sigcomm/sigcomm2000/submit. Authors not able to comply with these instructions should contact the Program Co-Chairs, or send mail to sigcomm2000-info@acm.org for more information.  Papers submitted after the deadline will not be considered without an ahead-of-time extension from the Program Co-Chairs.

All submitted papers will be judged based on their quality and relevance through double-blind reviewing, where the identities of the authors are withheld from the reviewers. Consult the on-line submission instructions for information on preparing a manuscript for double-blind review.  Authors of accepted papers will need to sign an ACM copyright release form and present their paper at the conference. The Proceedings of the conference will be published as a special issue of ACM SIGCOMM Computer Communication Review. The Program Committee may also select a few papers for possible publication in the IEEE/ACM Transactions on Networking. Electronic copies of the accepted papers will be published on the SIGCOMM 2000 web site prior to the conference unless authors specifically request that this not be done.

Tutorials:

SIGCOMM 2000 will begin with two days of full-day and half-day tutorials covering single topics in detail, at both the introductory or advanced level. Individuals interested in submitting tutorial proposals are encouraged to contact the Tutorial Chair before the deadline to discuss the proposed content.

Student Paper Award:

Papers submitted by students may be considered for a student-paper award, which includes full conference registration and a partial travel grant. To be eligible, the student must be the sole author of
the paper, or the first author and primary contributor. A cover letter or email to the Program Chairs must identify the paper as a candidate for this competition.

SIGCOMM Award:

The keynote speaker at SIGCOMM 2000 will be the 2000 winner of the ACM SIGCOMM Award for lifetime contributions to the field of computer communication. Procedures for nominating candidates for the SIGCOMM Award can be obtained >from Craig Partridge (craig@bbn.com).
 

Conference Committee:

General Co-Chairs

Per Gunningberg
Uppsala U., Sweden
perg@docs.uu.se
+46 18 471 3171
Steve Pink
Luleå U. Tech., Sweden
steve@cdt.luth.se
+46 920 72529

Program Co-Chairs

Christophe Diot
Sprint ATL, USA
cdiot@sprintlabs.com
+1 650 375-4539
Jim Kurose
U. Massachusetts, USA
kurose@cs.umass.edu
+1 413 545-2742

Publicity Chair

Joe Touch
USC/ISI, USA
touch@isi.edu (also sigcomm2000-info@acm.org)

+1 310 448-9151

Local Arrangements Co-Chairs

Bengt Åhlgren
SICS, Sweden
Bengt.Ahlgren@sics.se
+46 8 633 1562
Christian Tschudin
Uppsala U, Sweden
tschudin@docs.uu.se
+46 18 471 1066

Tutorials Chair

Steve Pink
Luleå U. Tech., Sweden
steve@cdt.luth.se
+46 920 72529

  --------------F90EB79E2531E0F3907217D3-- From rem-conf Wed Dec 08 18:54:40 1999 From rem-conf-request@es.net Wed Dec 08 18:54:38 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11vteO-0004pX-00; Wed, 8 Dec 1999 18:49:48 -0800 Received: from cs.columbia.edu [128.59.16.20] by mail1.es.net with esmtp (Exim 1.81 #2) id 11vteM-0004pJ-00; Wed, 8 Dec 1999 18:49:46 -0800 Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id VAA19342; Wed, 8 Dec 1999 21:49:44 -0500 (EST) Sender: hgs@cs.columbia.edu Message-ID: <384F18C7.7184802@cs.columbia.edu> Date: Wed, 08 Dec 1999 21:49:43 -0500 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Bill Foster CC: rem-conf@es.net Subject: Re: Named signaling events - minor request. References: <4.2.0.58.19991206192731.01c805e0@redale.cisco.com> <4.2.0.58.19991208083306.018d8230@redale.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Bill Foster wrote: > > Usually alerting is coming from the far end (callee to caller) as in Q.931. > > How about: > > Caller => Callee: Ringing > Caller <= Callee: Alerting > Unfortunately, the ITU specs (E.182, p. 2, item 7) seem to insist on "ringing tone" as the tone heard by the caller, so I think this would be rather confusing. Other suggestions are welcome. Henning -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From rem-conf Thu Dec 09 01:31:25 1999 From rem-conf-request@es.net Thu Dec 09 01:31:23 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11vzq4-0000T2-00; Thu, 9 Dec 1999 01:26:16 -0800 Received: from razor.arnes.si [193.2.1.80] by mail1.es.net with esmtp (Exim 1.81 #2) id 11vzq2-0000Sl-00; Thu, 9 Dec 1999 01:26:15 -0800 Received: from wilfred (unknown [193.2.1.243]) by razor.arnes.si (Postfix) with SMTP id 7AF48BEC94 for ; Thu, 9 Dec 1999 10:25:06 +0100 (MET) Received: by localhost with Microsoft MAPI; Thu, 9 Dec 1999 10:22:27 +0100 Message-ID: <01BF422F.4A9BE4D0.chris@arnes.si> From: Chris van der Merwe Reply-To: "chris@arnes.si" To: "rem-conf@es.net" Subject: Creating Simultaneous Mbone and RealMedia Streams... Date: Thu, 9 Dec 1999 10:22:26 +0100 Organization: Arnes X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 Encoding: 11 TEXT X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi; We're interested in creating presentations broadcast to the Mbone and to RealPlayers. Has anyone had any experience doing this and maybe have some advice or cautionary warnings to share? Also is there a way to convert incoming mbone streams to RealMedia streams on the fly? Regards Chris From rem-conf Thu Dec 09 05:22:52 1999 From rem-conf-request@es.net Thu Dec 09 05:22:51 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11w3TO-0002zF-00; Thu, 9 Dec 1999 05:19:06 -0800 Received: from wodc7-2.corprelay.mail.uu.net [192.48.96.69] by mail1.es.net with esmtp (Exim 1.81 #2) id 11w3TM-0002z5-00; Thu, 9 Dec 1999 05:19:04 -0800 Received: from neserve0.corp.us.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: neserve0.corp.us.uu.net [153.39.203.88]) id QQhsvt04985; Thu, 9 Dec 1999 13:18:58 GMT Received: by neserve0.corp.us.uu.net id QQhsvt21662; Thu, 9 Dec 1999 08:18:39 -0500 (EST) From: jhall@UU.NET (Jeremy Hall) Message-Id: Subject: Re: Creating Simultaneous Mbone and RealMedia Streams... In-Reply-To: <01BF422F.4A9BE4D0.chris@arnes.si> from Chris van der Merwe at "Dec 9, 1999 10:22:26 am" To: "chris@arnes.si" Date: Thu, 9 Dec 1999 08:18:39 -0500 (EST) CC: "rem-conf@es.net" X-Mailer: ELM [version 2.4ME+ PL60 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list The first task would be to get the real* thing to accept audio either on a socket or on stdin. If that is possible, then it is relatively simple to do what you wish. What about windoze media player? _J Chris van der Merwe said: > Hi; > > We're interested in creating presentations broadcast to the Mbone and to > RealPlayers. Has anyone had any experience doing this and maybe have some > advice or cautionary warnings to share? > > Also is there a way to convert incoming mbone streams to RealMedia streams > on the fly? > > Regards > Chris > > From rem-conf Thu Dec 09 06:51:47 1999 From rem-conf-request@es.net Thu Dec 09 06:51:46 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11w4pu-0004EA-00; Thu, 9 Dec 1999 06:46:26 -0800 Received: from sophia.inria.fr [138.96.32.20] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 11w4pq-0004E0-00; Thu, 9 Dec 1999 06:46:25 -0800 Received: from w3.org by sophia.inria.fr (8.8.8/8.8.5) with ESMTP id PAA11850; Thu, 9 Dec 1999 15:45:41 +0100 (MET) X-Authentication-Warning: sophia.inria.fr: Host trux.inria.fr [138.96.249.67] claimed to be w3.org Message-ID: <384FC0A3.4CD3FA45@w3.org> Date: Thu, 09 Dec 1999 15:45:55 +0100 From: Philipp Hoschka X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr MIME-Version: 1.0 To: Jeremy Hall CC: "chris@arnes.si" , "rem-conf@es.net" Subject: Re: Creating Simultaneous Mbone and RealMedia Streams... References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list actually, i think realplayer supports multicast; and some common datatypes used in Mbone transmissions (PCM for audio, h.261 for video, i believe). So you don't need to do conversion, unless you want to reduce bandwidth. > Chris van der Merwe said: > > Hi; > > > > We're interested in creating presentations broadcast to the Mbone and to > > RealPlayers. Has anyone had any experience doing this and maybe have some > > advice or cautionary warnings to share? > > > > Also is there a way to convert incoming mbone streams to RealMedia streams > > on the fly? > > > > Regards > > Chris > > > > From rem-conf Thu Dec 09 09:32:02 1999 From rem-conf-request@es.net Thu Dec 09 09:32:02 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11w7LW-0006CS-00; Thu, 9 Dec 1999 09:27:14 -0800 Received: from redale.cisco.com [171.71.154.68] by mail1.es.net with esmtp (Exim 1.81 #2) id 11w7LV-0006CD-00; Thu, 9 Dec 1999 09:27:13 -0800 Received: from bfoster-nt (sj-dial-1-192.cisco.com [171.68.179.193]) by redale.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id JAA13591; Thu, 9 Dec 1999 09:25:32 -0800 (PST) Message-Id: <4.2.0.58.19991209081356.01f2bd10@redale.cisco.com> X-Sender: bfoster@redale.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 09 Dec 1999 09:21:56 -0800 To: Henning Schulzrinne From: Bill Foster Subject: Re: Named signaling events - minor request. Cc: rem-conf@es.net In-Reply-To: <384F18C7.7184802@cs.columbia.edu> References: <4.2.0.58.19991206192731.01c805e0@redale.cisco.com> <4.2.0.58.19991208083306.018d8230@redale.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list What about: Caller => Callee: Power Ringing Caller <= Callee: Audible Ringing or Ringing Tone At 09:49 PM 12/8/99 -0500, Henning Schulzrinne wrote: >Bill Foster wrote: > > > > Usually alerting is coming from the far end (callee to caller) as in Q.931. > > > > How about: > > > > Caller => Callee: Ringing > > Caller <= Callee: Alerting > > >Unfortunately, the ITU specs (E.182, p. 2, item 7) seem to insist on >"ringing tone" as the tone heard by the caller, so I think this would be >rather confusing. Other suggestions are welcome. > >Henning >-- >Henning Schulzrinne http://www.cs.columbia.edu/~hgs ----------------------------- Bill Foster Phone: (408) 527-8791 Page: (800) 365-4578 Fax: (781) 998-6492 From rem-conf Thu Dec 09 13:45:05 1999 From rem-conf-request@es.net Thu Dec 09 13:45:03 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11wBAG-00018x-00; Thu, 9 Dec 1999 13:31:52 -0800 Received: from hercules.cs.ucsb.edu [128.111.41.30] by mail1.es.net with esmtp (Exim 1.81 #2) id 11wBAF-00018n-00; Thu, 9 Dec 1999 13:31:51 -0800 Received: from jackson.cs.ucsb.edu (jackson [128.111.52.10]) by hercules.cs.ucsb.edu (8.8.6/8.8.6) with ESMTP id NAA15497; Thu, 9 Dec 1999 13:31:38 -0800 (PST) Received: by jackson.cs.ucsb.edu (8.9.3+Sun/SMI-SVR4) id NAA28580 for ; Thu, 9 Dec 1999 13:31:33 -0800 (PST) Date: Thu, 9 Dec 1999 13:31:33 -0800 (PST) From: almeroth@cs.ucsb.edu (Kevin C. Almeroth) Message-Id: <199912092131.NAA28580@jackson.cs.ucsb.edu> To: almeroth@cs.ucsb.edu, nonnen@research.bell-labs.com Subject: CFP: Integrating Multicast into the Internet (Special Issue of Computer Communications) X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list CALL FOR PAPERS: Special Issue of Computer Communications on Integrating Multicast into the Internet CFP URL: http://www.cs.ucsb.edu/~almeroth/COMCOM:cfp.html Journal URL: http://www.elsevier.com/inca/publications/store/5/2/5/4/4/0/ TOPICS: The amount of bandwidth available in the Internet is increasing dramatically, both in the backbone networks, as well as in the last mile (broadband access). One consequence is that the delivery of high-quality multimedia data will become feasible, and multimedia data, including audio and video, will become the dominant traffic. As more users gain access to broadband services, new applications and services will become possible. The result will be a growing demand for large-scale multimedia applications and services. Multicasting as a pure networking solution to the transport of media is recognized as offering economies-of-scale for large-scale applications. Multicast is also believed to enable applications which provide service to thousands, even millions of customers. While there has been significant research work on multicast, efforts to successfully deploy a production service have lagged. Reasons range from frequently changing protocols, management and engineering problems, legacy hardware limitations, traffic conflicts with unicast, etc.. This special issue focuses on research issues dealing with the challenges of deploying multicast in the network. Specific topics include, but are not limited to: * Multicast Congestion Control * Multicast Overlay Networks * Next-Generation Multicast Routing Algorithms * Multicast Media Transport * Security for Multicast-Based Services * Multicast Traffic Engineering and Management * Multicast Pricing and Quality of Service GUEST EDITORS: Kevin Almeroth Jorg Nonnenmacher Department of Computer Science Network Research Dept, Lucent Technologies University of California 600-700 Mountain Avenue Santa Barbara, CA 93106-5110 Murray Hill, NJ 07974-0636 Phone: +1(805) 893-2777 Phone: +1(908) 582-1707 Fax: +1(805) 893-8553 Fax: +1(908) 582-6632 Email: almeroth@cs.ucsb.edu Email: nonnen@research.bell-labs.com IMPORTANT DATES: Paper Submission Deadline: February 1, 2000 Feedback to Authors: May 1, 2000 Final Manuscripts Due: June 1, 2000 Publication Date: Fall 2000 SUBMISSION INSTRUCTIONS: Authors are requested to send e-mail to one or both of the Guest Editors (almeroth@cs.ucsb.edu, nonnen@research.bell-labs.com) giving a URL from where a postscript or PDF file can be downloaded. Successfully received papers will be acknowledged. AUTHOR INFORMATION: Submissions made to the special issue should not have appeared in, or been submitted to other archival publications. All papers will be subjected to the journal's usual refereeing process. From rem-conf Thu Dec 09 14:28:42 1999 From rem-conf-request@es.net Thu Dec 09 14:28:41 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11wC1a-0002K1-00; Thu, 9 Dec 1999 14:26:58 -0800 Received: from mail.pi.se [195.7.64.8] by mail1.es.net with esmtp (Exim 1.81 #2) id 11wC1Z-0002Jr-00; Thu, 9 Dec 1999 14:26:57 -0800 Received: from pigpen (ap03-083.mp.pi.se [195.7.87.83]) by mail.pi.se (8.8.8/8.8.8) with SMTP id XAA23577; Thu, 9 Dec 1999 23:26:22 +0100 (MET) From: "Gunnar Hellstrom" To: "Bill Foster" , "Henning Schulzrinne" Cc: Subject: RE: Named signaling events - minor request. Date: Thu, 9 Dec 1999 23:26:02 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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.2314.1300 In-Reply-To: <4.2.0.58.19991209081356.01f2bd10@redale.cisco.com> Importance: Normal Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mail.pi.se id XAA23577 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I suggest to keep as close as possible to already established nomenclatur= e. Proposal Caller =3D> Callee: Ring Caller <=3D Callee: Ringing Tone Motivation: "RING" is the standardised message from a modem experiencing an incoming ring. It also matches normal language. I.e. "I heard a ring". "Ringing Tone" is the E.182 name for the tone back to the caller. "Alerting" could be used for the same thing since it is the name of the Q.931 message in that situation. But we are talking about tones from the PSTN here, aren't we? Gunnar Hellstr=F6m -----Original Message----- From: Bill Foster [mailto:bfoster@cisco.com] Sent: Thursday, December 09, 1999 6:22 PM To: Henning Schulzrinne Cc: rem-conf@es.net Subject: Re: Named signaling events - minor request. What about: Caller =3D> Callee: Power Ringing Caller <=3D Callee: Audible Ringing or Ringing Tone At 09:49 PM 12/8/99 -0500, Henning Schulzrinne wrote: >Bill Foster wrote: > > > > Usually alerting is coming from the far end (callee to caller) as in Q.931. > > > > How about: > > > > Caller =3D> Callee: Ringing > > Caller <=3D Callee: Alerting > > >Unfortunately, the ITU specs (E.182, p. 2, item 7) seem to insist on >"ringing tone" as the tone heard by the caller, so I think this would be >rather confusing. Other suggestions are welcome. > >Henning >-- >Henning Schulzrinne http://www.cs.columbia.edu/~hgs ----------------------------- Bill Foster Phone: (408) 527-8791 Page: (800) 365-4578 Fax: (781) 998-6492 From rem-conf Thu Dec 09 15:12:27 1999 From rem-conf-request@es.net Thu Dec 09 15:12:26 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11wChc-0003Jl-00; Thu, 9 Dec 1999 15:10:24 -0800 Received: from redale.cisco.com [171.71.154.68] by mail1.es.net with esmtp (Exim 1.81 #2) id 11wChb-0003HE-00; Thu, 9 Dec 1999 15:10:23 -0800 Received: from bfoster-nt (sj-dial-1-230.cisco.com [171.68.179.231]) by redale.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id PAA09045; Thu, 9 Dec 1999 15:06:20 -0800 (PST) Message-Id: <4.2.0.58.19991209150304.01b14830@redale.cisco.com> X-Sender: bfoster@redale.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 09 Dec 1999 15:03:29 -0800 To: "Gunnar Hellstrom" , "Henning Schulzrinne" From: Bill Foster Subject: RE: Named signaling events - minor request. Cc: In-Reply-To: References: <4.2.0.58.19991209081356.01f2bd10@redale.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Sounds fine. At 11:26 PM 12/9/99 +0100, Gunnar Hellstrom wrote: >I suggest to keep as close as possible to already established nomenclature. >Proposal >Caller =3D> Callee: Ring >Caller <=3D Callee: Ringing Tone >Motivation: >"RING" is the standardised message from a modem experiencing an incoming >ring. It also matches normal language. I.e. "I heard a ring". > >"Ringing Tone" is the E.182 name for the tone back to the caller. >"Alerting" could be used for the same thing since it is the name of the >Q.931 message in that situation. >But we are talking about tones from the PSTN here, aren't we? > >Gunnar Hellstr=F6m > > >-----Original Message----- >From: Bill Foster [mailto:bfoster@cisco.com] >Sent: Thursday, December 09, 1999 6:22 PM >To: Henning Schulzrinne >Cc: rem-conf@es.net >Subject: Re: Named signaling events - minor request. > > >What about: > >Caller =3D> Callee: Power Ringing >Caller <=3D Callee: Audible Ringing or Ringing Tone > > > >At 09:49 PM 12/8/99 -0500, Henning Schulzrinne wrote: > >Bill Foster wrote: > > > > > > Usually alerting is coming from the far end (callee to caller) as in >Q.931. > > > > > > How about: > > > > > > Caller =3D> Callee: Ringing > > > Caller <=3D Callee: Alerting > > > > >Unfortunately, the ITU specs (E.182, p. 2, item 7) seem to insist on > >"ringing tone" as the tone heard by the caller, so I think this would be > >rather confusing. Other suggestions are welcome. > > > >Henning > >-- > >Henning Schulzrinne http://www.cs.columbia.edu/~hgs > >----------------------------- >Bill Foster >Phone: (408) 527-8791 >Page: (800) 365-4578 >Fax: (781) 998-6492 > > ----------------------------- Bill Foster Phone: (408) 527-8791 Page: (800) 365-4578 Fax: (781) 998-6492 From rem-conf Thu Dec 09 20:25:22 1999 From rem-conf-request@es.net Thu Dec 09 20:25:20 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11wHUa-0006QP-00; Thu, 9 Dec 1999 20:17:16 -0800 Received: from sgi.sgi.com (sgi.com) [192.48.153.1] by mail1.es.net with esmtp (Exim 1.81 #2) id 11wHUV-0006Q9-00; Thu, 9 Dec 1999 20:17:12 -0800 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id UAA09307 for <@external-mail-relay.sgi.com:rem-conf@es.net>; Thu, 9 Dec 1999 20:17:02 -0800 (PST) mail_from (kordale@relic.engr.sgi.com) Received: from relic.engr.sgi.com (relic.engr.sgi.com [198.29.115.71]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via SMTP id UAA18740 for <@cthulhu.engr.sgi.com:rem-conf@es.net>; Thu, 9 Dec 1999 20:17:02 -0800 (PST) mail_from (kordale@relic.engr.sgi.com) Received: (from kordale@localhost) by relic.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id UAA15430 for rem-conf@es.net; Thu, 9 Dec 1999 20:17:01 -0800 From: "Ram Kordale" Message-Id: <9912092017.ZM15428@relic.engr.sgi.com> Date: Thu, 9 Dec 1999 20:17:01 -0800 X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: rem-conf@es.net Subject: (Fwd) MPEG-1 over RTP (RFC 2250) conflict? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I am surprised at the silence on this list regarding this question. Is my question way off or does this point to an obvious limitation of the RFC? I forwarded my message to one of the authors of RFC 2250. He suggested that the solution to my example scenario is that P13 and P23 would have different timestamps. I disagreed because 1) they need not have different timestamps and 2) even if they are different there is no mechanism in RTP headers to distinguish them. I have not heard from him since! Suggestions? Thanks Ram --- Forwarded mail from ("Ram Kordale") From: "Ram Kordale" Date: Fri, 3 Dec 1999 15:26:06 -0800 To: rem-conf@es.net Subject: MPEG-1 over RTP (RFC 2250) conflict? Could someone please clarify the following "conflict" I see in the spec? In the event of data loss, RFC 2250 has mechanisms to recover at the slice level(basically by discarding RTP packets until you find one with the BeginningOfSlice bit set to 1). However, if you lose a few RTP packets, one is **really forced** to skip until the beginning of the next GOP! This is an incredible amount of loss or I have misunderstood the spec. Could someone please clarify? Details: ------- Consider the following segment of MPEG-1 system stream. ...GOP_H P11 P12 P13 ... P1n GOP_H P21 P22 P23 ... GOP_H refers to GOP Headers. Pij refers to picture j of the ith GOP. For simplicity, assume that the stream and display order are the same. Thus, Pij will have a "Temporal Reference" of j. For simplicity, assume each picture is split into 5 RTP packets. Suppose I receive RTP packets containing all of the first GOP header and P11 and I receive 1 RTP packet containing the first "piece" of P12. Suppose the next RTP packet I received contains the "Temporal Reference" of 3, how do I know which GOP this picture belongs to. In other words, how do I know it belongs to P13 or P23 or in general Pi3. If I cannot know, I will have to insert a broken GOP thus essentially losing data until the next GOP header is received. Thanks for your help. Ram -- Ram Kordale Advanced Media Products ---End of forwarded mail from ("Ram Kordale") -- Ram Kordale Advanced Media Products From rem-conf Fri Dec 10 01:20:15 1999 From rem-conf-request@es.net Fri Dec 10 01:20:15 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11wM9U-0002dB-00; Fri, 10 Dec 1999 01:15:48 -0800 Received: from razor.arnes.si [193.2.1.80] by mail1.es.net with esmtp (Exim 1.81 #2) id 11wM95-0002az-00; Fri, 10 Dec 1999 01:15:46 -0800 Received: from wilfred (unknown [193.2.1.243]) by razor.arnes.si (Postfix) with SMTP id A7C88BEC94 for ; Fri, 10 Dec 1999 10:14:15 +0100 (MET) Received: by localhost with Microsoft MAPI; Fri, 10 Dec 1999 10:11:39 +0100 Message-ID: <01BF42F6.F3115290.chris@arnes.si> From: Chris van der Merwe Reply-To: "chris@arnes.si" To: "'rem-conf@es.net'" Subject: AGAIN: Creating Simultaneous Mbone and RealMedia Streams... Date: Fri, 10 Dec 1999 10:11:38 +0100 Organization: Arnes X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 Encoding: 35 TEXT X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Sorry, I just checked my original message (reprinted below just to show what a pig's ear I made of my explaination). I meant to say that we'd like to broadcast to Mbone and REALSERVER at the same time - I guess we could just split the original source to two servers, but I'm wandering if there is a software solution. Also: We're considering taking existing Mbone sessions and feeding them to RealServer to be transmitted as RealMedia broadcasts - has anyone had any experience doing this? Basically looking at using RealServer with the Mbone. Sorry for my lack of detail yesterday. Regards Chris -----Original Message----- From: Chris van der Merwe [SMTP:chris@arnes.si] Sent: Thursday, December 09, 1999 10:22 AM To: rem-conf@es.net Subject: Creating Simultaneous Mbone and RealMedia Streams... Hi; We're interested in creating presentations broadcast to the Mbone and to RealPlayers. Has anyone had any experience doing this and maybe have some advice or cautionary warnings to share? Also is there a way to convert incoming mbone streams to RealMedia streams on the fly? Regards Chris From rem-conf Fri Dec 10 07:09:43 1999 From rem-conf-request@es.net Fri Dec 10 07:09:42 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11wRVy-0007Dz-00; Fri, 10 Dec 1999 06:59:22 -0800 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 11wRVu-0007Do-00; Fri, 10 Dec 1999 06:59:19 -0800 Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 10 Dec 1999 14:58:54 +0000 To: minutes@ietf.org, rem-conf@es.net Subject: AVT minutes cc: casner@cisco.com Date: Fri, 10 Dec 1999 14:58:52 +0000 Message-ID: <4251.944837932@cs.ucl.ac.uk> From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Folks, Attached are the AVT minutes from the Washington DC meeting, our apologies for the late submission of these. In addition, copies of the slides from the meeting may be found at http://www-mice.cs.ucl.ac.uk/multimedia/misc/avt/IETF46/slides/ Colin & Steve ------------------------------------------------------------------------------- Audio/Video Transport Working Group Minutes Reported by Colin Perkins and Steve Casner The audio/video transport working group held two full sessions in Washington DC. The first session discussed the ongoing revision to the RTP specification and audio/video profile, together with a number of payload formats. The second session dealt with transport of MPEG-4 and multiplexing. In addition, a design team met to discuss the transport of MPEG-4. The meeting started with a review of work in progress and the status of the working group's documents. The RTP payload format for generic FEC (draft-ietf- avt-fec-08.txt) has been approved for publication as a proposed standard, and the guidelines for writers of RTP payload format specifications (draft-ietf- avt-rtp-format-guidelines-04.txt) has been approved for publication as a BCP. At the time of writing, neither of these RFCs have been issued yet. The RTP MIB (draft-ietf-avt-rtp-mib-07.txt) has been sent to the IESG for consideration as a proposed standard. The draft on sampling group membership in RTP (draft-ietf-avt-rtpsample-05.txt) was published as an Experimental RFC after the meeting. In addition, the payload format for DTMF and related tones (draft-ietf-avt-tones-02.txt) was noted as having completed working group last call and will be submitted for publication after a final revision is posted. An update on the the RTP specification and audio/video profile was presented by Steve Casner. The recent changes to the RTP specification include: - Collision/loop detection algorithm nesting syntax changed to pseudo-C - Added SHOULD keep packets from new address on third-party collision for apps that may change addresses (e.g., where some endpoints are mobile) - Reverse reconsideration algorithm SHOULD be performed to possibly reduce the delay before sending first SR packet after starting to send data - Timing out a participant is based on inactivity for a number of RTCP report intervals calculated using the receiver RTCP bw fraction even for active senders There are three open issues with this specification: - It currently says that sources which change their source transport address MUST change SSRC - is this inconsistent with "SHOULD follow new address"? It was agreed to change MUST to MAY. - Should the length of compound RTCP packets with information about N sources be divided by N for average? Analysis since the meeting indicates this is not a problem. - It is necessary to clarify that a mixer mixing N sources may use N times the single-source RTCP bandwidth. The recent changes to the audio/video profile include: - CN (comfort noise) static payload type changed back from 19 to 13 for consistency with ITU H.225.0 and VoIP Forum documents - RTP clock rate G722 changed back to 8000 even though sampling rate is 16000 (a note of explanation was added) - Note that MPEG audio RTP clock rate is always 90000 regardless of sampling rate Once again, there are a number of minor open issues: - Should the profile recommend the use of the H263-1998 payload format over the old payload format for H263? It was decided yes. - Did AIFF-C list of channels change from what is in RFC 1890? No, but the set used for DAT and DV video are different and so may require separate specification in a payload format. - Change title of Section 3 to "IANA Considerations". - Fix bungled edit of CN from 13 to 19 in Table 5. The question of how to deal with proposed enhancements to the comfort noise payload format to include spectral shape parameters was raised. This work is ongoing in the ITU-T SG16, but will take time to complete - we don't want to wait for this, before we advance RTP. There are a number of options: - Leave the current comfort noise payload format as is, and define a new payload format for the extension - Enhance this format, so if it is longer than 1 byte it includes extra spectral information - Remove this payload format from the profile, so as not to hold the profile up, but leave the payload type assigned (with a note being added to the profile that payload type 13 is reserved for a comfort noise payload format which will be specified later). The chairs proposed taking this latter option, but this raised a number of questions about the status of the revised comfort noise draft (which is in use in a number of products) and the ability of the profile to reference it. After some discussion, a hybrid of these options was chosen: the comfort noise payload format will be extracted from the audio/video profile and submitted as a proposed standard RFC, referenced by the profile. Steve Casner will do this as part of editing the profile. The ITU-T will extend this, in the same manner as any other payload format is extended, with the expectation that it will cycle at proposed standard. The MIME registration for the payload types defined in the audio/video profile has been updated (draft-ietf-avt-rtp-mime-01.txt). The changes include clarification of the mapping from MIME parameters to SDP "a=fmtp" attributes and the addition of the RED (redundant audio) payload and "type" parameter for MPEG. It was noted that the payload format for generic FEC, which is already in the hands of the RFC editor, did not include a MIME registration for the name "parityfec"; Jonathan Rosenberg volunteered to write a separate draft for this. This meeting marked the completion of working group last call on the set of drafts that have been prepared for advancement of RTP specification and A/V profile to Draft Standard status. The working group accepted the changes that had been made in the drafts posted for last call as well as the few changes proposed in response to comments received during the last call. With those changes, the working group agreed that the following drafts should be submitted for IESG Last Call: draft-ietf-avt-rtp-new-05.txt (Draft standard) draft-ietf-avt-profile-new-06.txt (Draft standard) draft-ietf-avt-rtp-mime-00.txt (Proposed standard) draft-ietf-avt-rtcp-bw-00.txt (Proposed standard) This will be done immediately. The need for interoperability statements from implementors was noted. Implementors, both academic and vendors, are strongly encouraged to study draft-ietf-avt-rtp-interop-02.txt and draft-ietf-avt-profile-interop-00.txt, and to submit a statement of interoperability to the group. Scott Bradner (the transport area co-director) noted that it is okay for a neutral third party to present the results, hiding the identity of the vendors if they do not wish to make this information available. The chairs will set up a web page, summarizing the results of interoperability tests conducted. The next topic was a potential new task for AVT: a unicast RTCP-based retransmission scheme, presented by Matthew Podolsky. The motivation for this work (draft-podolsky-avt-rtprx-00.txt) is that there are a number of proprietry retransmission schemes in use, hindering interoperability, and no standard currently exists. Why unicast? Because unicast retransmission schemes are widely used, and because they are well understood, unlike multicast retransmission schemes which are difficult to make work in a scalable and timely manner. Further, reliable multicast is outside the scope of this working group. The proposal is for a new RTCP packet type, the "multipurpose ACK", which can be used to ACK or NACK a packet with a particular sequence number and up to 16 surrounding packets. This is flexible, specifying a basic framework for requests which can be modified or extended by a protocol subtype field. A number of items were raised for discussion: - Is it necessary to include the SSRC in retransmission requests? This is good for compatibility with the other RTCP packet types and allows us to groups NACKs for multiple sessions in one request. Anders Klemets noted that this allows one to send multiple NACKs in a single packet, allowing one to NACK multiple unicast RTP sessions. This may be of use when working with an RTSP server, since the server can ensure that the SSRCs used in each session are unique. It is unclear how useful this is, in practise. - Is it best to include a protocol subtype field, or to rely on the RTCP packet type field and out-of-band signalling? The feeling of the group was that the RTCP packet type was the appropriate place to demultiplex, and there was no need to include an additional subtype. Future versions of this draft should specify behaviour profiles, for example ACK or NACK based retransmission. - Should the bit mask of other packets which are being ACKed/NACKed cover preceeding or succeeding packets? It was suggested to do as in the FEC format, with an offset from the first sequence number. - How does this work with silence suppression? How long must one wait for the next packet before deciding it is loss, rather than silence? It was noted that, in order to make this work, it is necessary to eliminate the current limitations on minimum time between RTCP feedback. This may have adverse effects of the scalability and congestion control of the protocol and probably requires the definition of a new RTP profile, to specify these timers and other changes that may be required. Mark Handley noted that there is an urgent need to deploy congestion controlled RTP to prevent problems in the wide area network. If the group is going to work on a new unicast RTP profile including retransmission, it would be advisable if we could also include congestion control. In a discussion after the AVT session, the transport area directors agreed that it was appropriate for AVT to undertake this work, but that congestion management must be included. Since the ECM working group won't have output right away, Mark Handley and Sally Floyd agreed to write an informational document that the work on retransmission can refer to. The remainder of the first day was spent in a discussion of various RTP payload formats. The first was an update on the payload format for Real Time Pointers was presented by Reha Civanlar. The new draft resolves the issues raised at the previous meeting, and also adds the ability to convey an indication of the pointer icon (the mapping from code-points to icons is to be specified out of band). This is now ready for working group last call. The RTP payload formats for DV audio (draft-ietf-avt-dv-audio-00.txt) and video (draft-ietf-avt-dv-video-01.txt) were presented by Katsushi Kobayashi. Changes relating to the audio format include: - addition of 20 and 24 bit linear sampling modes, in addition to 12 bit non-linear - change MIME encoding from audio/NL12 to audio/DAT12 and add a MIME registration template - remove pseudo-code, since it was obvious - define SDP fmtp parameter for analogue pre-emphasis; this may be required for L16 audio within DV as well, and the working group generally agreed that adding an fmtp parameter to the existing L16 payload format was acceptable The DV video payload has seen the addition of support for D-7 and D-9 "professional" formats, a simplification of the SDP description and the removal of IEEE1394 specific timestamp issues to an appendix, since the D-7 and D-9 formats suppose a different interface. The MIME registration has yet to be done. Two interoperable implementations exist (from the WIDE project and KTH). These drafts are believed ready for working group last call. The payload format for MPEG2 AAC was presented by Jim Snyder (standing in for Mathias Kretschmer who was ill). Changes have been made relating to - priority vectors - fragmentation/grouping - a type field for the repair information This payload format has not yet been implemented, but this is in progress (probably not be done by next meeting, but by the one after). The draft is not yet ready for last call, since the authors need to do more development and testing, and desire feedback from the group (especially relating to MPEG-4). Ross Finlayson presented an update to the more loss-tolerant payload format for MP3 audio (draft-ietf-avt-rtp-mp3-01.txt). This payload format is more robust to packet loss than RFC2250, but implies more knowledge of MP3. Recent additions to the draft include a specification of how to handle streams containing a mix of layer I or II frames with layer III (this is an uncommon situation) and pseudo-code to convert between "MP3 frames" and "ADU frames" as required by this format. A plea was made for the group to check the pseudo- code, since it's somewhat complex. More information, including a performance comparison with RFC2250, is available from http://www.live.com/rtp-mp3/. Dave Singer noted that this is a great idea, but doesn't go far enough: maybe it should include support for interleaving too? His group has demonstrated improved performance with interleaving, reusing the MPEG sync byte so no overhead is added (though doing this precludes mixing in layer I or II frames). The addition of interleaving will be considered before the draft is progressed. An extension to the payload format for MPEG-2 transport streams (draft-ietf- avt-rtp-mp2t-00.txt) was presented by Humphrey Liu. The issue here is that MP2T is a packet- based transport format which can contain multiple programs with an aggregate bandwidth which can be as high as 50-60Mbps (=40Kpps). The 90KHz RTP timestamp clock defined in RFC2250 does not have sufficient resolution (about two ticks per packet), so this draft recommends a 27MHz clock, as defined by MPEG-2. In fact, RTP with MP2T does not provide much value compared to UDP for single-program transport streams (at lower data rates for which 90kHz is appropriate), but the RTP timestamp does add value for multiple-program transport streams given sufficient resolution. Why is so much resolution needed? For faster clock recovery, for calculation of piece-wise CBR bitrate interpolating the timestamp for every MPEG packet multiplexed into the RTP-encapsulation transport stream, and in order to regenerate the exact timing for re-insertion of each packet into a native MPEG-2 transport stream. No change to the actual payload format in RFC2250 is required, just a change in the RTP timestamp clock rate. For applications which use SDP, this can be accomplished by specifying a clock rate of 27000000 in the a=rtpmap attribute. The payload for text conversation (draft-ietf-avt-rtp-text-02.txt) was presented by Ian Rytina. The issues resolved since Oslo include: - What type of redundancy should be used (FEC or RED)? Agreed to leave it open, but recommend RED. - Why do we need this format when IRC and telnet chat are available? Compatibility with existing products, better fit with SIP and H.323. - MIME registration? Done - Clock frequency? Irrelevant for text, but 1kHz now specified. - Order of redundant data? Must be inserted in age order with one redundant block from each transmitted packet, in order to correctly decode all cases. - Avoid double specification of fill character for missing data - Transmission during silence periods - send empty primary in the redundancy format for the last packet before silence. This payload is now ready for working group last call: the main issue is the ordering of redundant data, which is somewhat subtle and should be verified to be correct. Jonathan Rosenberg noticed that the MIME type is text/t140, but SDP doesn't have a text media (on the m= line). It may be necessary to include a section on SDP usage? Steve Casner noted that this should not be necessary because the RTP MIME registration specifies a mapping to SDP. Allison Mankin presented some new work on an RTP payload format for HDTV, motivated by the start of commercial HTDV broadcasts in the US and the proliferation of formats. The bandwidth of HDTV streams ranges from 176Mbps to 1.49Gbps uncompressed, and compresses down to around 20-40Mbps for broadcast. These media formats are under standardisation by the ATSC (http://www.atsc.org) and DVB (http://www.dvb.org) but with major differences in transmission technology (COFDM vs 8VSB) and payload (eg: DVB uses MPEG audio, ATSC uses AC-3 Dolby). The payload for compressed HDTV is mostly covered by RFC2250. The uncompressed format is related to BT.656 with the addition of 4.2.0 colour sub- sampling and a 1080 line mode (versus 525/625 lines for BT.656). One question is whether the BT.656 payload format can just be extended for HDTV, but here again the RTP timestamp resolution may be an issue. A payload is also needed for AC3 audio. This is an early "heads up" on the work, which is ongoing, and further drafts are expected in future. The major issue discussed on the second day was the transport of MPEG-4 media. Colin Perkins started this by summarising the design team meeting held earlier in the week. There are three proposals for discussion: - draft-ietf-avt-rtp-mpeg4-02.txt - draft-guillemot-genrtp-01.txt - draft-jnb-mpeg4av-rtp-00.txt It is also expected that there will be a fourth proposal for a packetization based on MPEG FlexMux. A number of open issues were identified with these proposals: - Use of MPEG-4 systems vs elementary streams. - MPEG-4 has a complete system model, but some applications just desire to use the codecs. We accept that we need to generate payload formats for both cases, even though this has the potential for interoperability problems later (compare issues with MPEG-2). - We also noted that MPEG-4 encompasses codecs which may have an existing RTP payload format, but we can't preclude the use of MPEG-4 specific packetization if the system model is to be maintained. In addition, for error resilience, it is desirable to packetize in a media aware manner - this does not imply a choice between systems or elementary streams. - Multiplexing multiple streams. - Five multiplexing options were identified: GeRM, FlexMux, "PPP Mux" with CRTP (see later), don't multiplex, and don't multiplex, but compress headers. We noted that we may need a FlexMux format, but nothing else requires special consideration. - Grouping within a stream. - Why group? to amortize header overhead and to aid error resilience (for example duplicate and group picture headers with each packet, or group FEC with media data). - There is disagreement over the importance of grouping, and the mechanism to be used: draft-guillemot-genrtp-01.txt has support for grouping access units (ie: ADUs) and for sub-access units (eg: unequal FEC), the other proposals perform no additional grouping assuming anything needed will be done in the encoder. - Further experimental testing is needed to determine whether additional error resilience is worth the extra complexity. - Fragmentation - It is necessary to fragment a codec bit-stream in a media aware manner to achieve error resilience - We believe that the choice of fragmentation is a matter for the encoder, and that MPEG-4 should be able to fragment accordingly (a payload format should be able to transport oversize fragments, but this need not be efficient). - Error protection - We considered two forms of error protection: within the payload and across packets. - draft-guillemot-genrtp-01.txt uses unequal FEC within the payload (using a "typed segment" abstraction to be generic - this abstraction doesn't exist in MPEG, although the information is available in an ES specific manner). The other proposals assume the MPEG bitstream is robust enough "as is". Further experimental testing is needed. - We may also apply any of the existing error protection mechanisms across packets (parity FEC, for example). Draft-guillemot-genrtp- 01.txt also duplicates these functions as part of its unequal FEC scheme. - Some MPEG-4 elementary streams MUST be reliably delivered (eg: control streams and streaming media such as Java class files). We reached no conclusion on how we do this - have focused on audio and video to date. - Timing model. - MPEG-4 and RTP have different timing models. If it is desired to synchronize MPEG-4 data with data using a native RTP packetization we must align the models (capture time vs composition time). We believe the text in draft-ietf-avt-rtp-mpeg4-02.txt describing this alignment is correct, but needs edits for clarity. This is an issue for all the proposals. - Byte alignment. - MPEG-4 systems has the potential to handle not byte aligned bit- streams (audio and video codecs do not but others may?), but the streams it produces are byte aligned. The ES packetizations may have to similarly include the capability to add padding bits. Following this summary, brief presentations were made on the individual proposals. - Andrea Basso presented draft-ietf-avt-rtp-mpeg4-02.txt, noting that text has been added describing the correspondance between the RTP and MPEG-4 timing models (this actually affects all the proposals). Implementations of this payload format exist by AT&T and Nokia, and interoperability results were presented to the recent MPEG meeting in Melbourne. - Paul Christ presented an overview of draft-guillemot-genrtp-01.txt and the motivations for this approach. The draft has not been changed since the Oslo meeting, but there is a plan to clean up the format and resubmit before Adelaide. An implmentation is underway - the mapping and de-mapping is done and under test, the unequal error protection is under development (see http://www-ks.rus.uni-stuttgart.de/PROJ/GP) for details. - Yoshihiro Kikuchi presented draft-jnb-mpeg4av-rtp-00.txt. This is a new draft, which comprises a direct mapping of elementary streams to RTP, for applications like IP phone, mobile, and H.323. The MPEG-4 systems model is not used, session/stream management is done via H.245 or SIP. A standards track payload format is needed, for ITU interaction, since an H.323 audio codepoint will be specified in February 2000. MPEG-4 video is mapped directly, audio is mapped via the LATM encapsulation. The draft also specifies back-channel signaling using RTCP. The discussion of MPEG-4 was concluded by Colin Perkins, who outlined the chairs' view on future activity in this area. - It was noted that the MPEG-4 audio and video codec elementary streams can be packetized in RTP in a manner similar to other codecs. This path is well understood and makes sense to standardize. Standardization is also required for these payload formats to be referenced by the ITU. Hence we propose to adopt draft-jnb-mpeg4av-rtp-00.txt as an AVT work item, for eventual submission on the standards track. - Multiplexed MPEG-4 media is to be treated in a similar manner to earlier bundled MPEG transport. We will therefore consider a FlexMux payload format, if one is submitted. - We do not believe we fully understand the issues involved in the transport of the complete MPEG-4 system over RTP. Such payload formats should therefore be submitted for publication as experimental RFCs, whilst we gain implementation experience. Accordingly, draft- ietf-avt-rtp-mpeg4-02.txt and draft-guillemot-genrtp-01.txt will be progressed to experimental RFC status. The chairs asked for - and received - consensus that this is a viable approach. An a postscript to the MPEG-4 discussion, Dave Singer provided an overview of draft-singer-rtp-qtfile-01.txt, the QuickTime file format and hint track specification. This was presented for information and comments, it is not intended to be published on the standards track. The next subject was RTP multiplexing. The first presentation in this area was by Bruce Thompson on extensions to CRTP and RTP multiplexing using tunnels. The original work has was draft-wing-avt-tcrtp-00 which was submitted to the Oslo meeting. This was been broken into three parts: IP tunneling, PPP multiplexing, and enhancements to CRTP. Three independent enhancements to CRTP are described in draft-koren-avt-crtp- enhance-00.txt. The first is the ability to include a delta-timestamp in COMPRESSED_UDP packets to restore the state at the decompressor in the event of packet loss. This makes CRTP more robust to packet loss and also lets you refresh state and send it multiple times efficiently without the delay of error feedback. Concern was expressed about the need to send the absolute value of IPv4 ID, which could be addressed by using the COMPRESSED_NON_TCP packet instead except that doesn't include the delta-T. The second extension is to add a NonRTP stream flag to the FULL_HEADER packet to notify the decompressor that the compressor will never send COMPRESSED_RTP packets for a particular context so that the decompressor does not have to maintain context for the RTP header. The third extension is to define a reject packet to allow a decompressor to reject the use of a new compression context when it is out of resources. An overview of how this enhanced CRTP can be used for tunneling to provide a transparent and efficient multiplexing solution was also provided. RTP packets are encapsulated end-to-end for multiplexing, consisting of - compression (CRTP, with enhancements for robustness to loss) - multiplexing (PPP multiplexing, draft-ietf-pppext-pppmux-00.txt, which is ongoing in the PPPEXT working group). - IP tunneling for PPP (L2TP, draft-ietf-pppext-l2tphc-03.txt, not posted) which removes session ID, tunnel ID from L2TP, and the UDP header for efficiency, using a negotiated IP protocol ID. - CRTP negotiation (RFC2509) The application runs RTP with no knowledge of the tunnel/compression: CRTP and muxing take place at layer 2, independent of the application. It was noted that it is also possible to compress away the IP header on a per link basis, if desired. An informational document is to be produced, describing how these pieces fit together to provide the complete solution. Steve Casner noted that this approach to the entire muxing problem is clean and moves the multiplexing down to the IP layer where it is more appropriate, keeping the RTP semantics tidy. Input from the group was solicited on the changes for CRTP. The final presentation was by Colin Perkins, for Alexander Tulai who was unable to attend, on a dynamic Nx64 payload format (draft-tulai-avt-dynamic-nx64-00.txt), for multiplexing PCM coded audio streams (eg: transport of a T1 line). The consensus of the group was that this draft is too narrowly focused, but a payload format for general circuit emulation may make sense. The meeting concluded with a discussion of the working group charter. The main goal of the group has been the development of RTP; once this is done we have concluded most of our work. We also have steps in the charter for MPEG-4 and multiplexing, but we expect to complete these and our other remaining actions over the course of the next couple of meeting. This will leave only the continuing evolution of payload formats - these don't necessarily need AVT to meet everytime, since much of this work can be done on the mailing list. There are a number of options for the future of the group: one possibility is that we may go into hibernation, meeting occasionally when there is sufficient work. It was suggested that we could separate the RTP protocol itself from the payload question: payloads don't necessarily have to be done in the RTP working group (although AVT - or its successor - may review such payload formats), and we could recharter AVT to do extensions of the core RTP protocol/profile only. Another option would be to recharter to study new profiles for unicast RTP retransmission and/or congestion control. Input from the working group is solicited. From rem-conf Sat Dec 11 17:19:22 1999 From rem-conf-request@es.net Sat Dec 11 17:19:21 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11wxBt-0007Sm-00; Sat, 11 Dec 1999 16:48:45 -0800 Received: from banshee.sasknet.sk.ca (banshee.) [142.165.5.86] by mail1.es.net with smtp (Exim 1.81 #2) id 11wxBp-0007S8-00; Sat, 11 Dec 1999 16:48:41 -0800 Received: from 142.165.5.86 by banshee. (SMI-8.6/SMI-SVR4) id SAA14036; Sat, 11 Dec 1999 18:46:19 -0600 From: HomeLoans@maxa.fsnet.co.uk Date: Sat, 11 Dec 99 16:44:21 EST To: Home_Loans@excite.com Subject: Home Loans & Refinancing Available Message-ID: <> X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list You can now comparison shop thousands of loan programs through hundreds of lenders by filling in a single short form. Let lenders compete for your business! Cash back refinances No Equity 2nd Trust Deeds Debt Consolidation No Income Verification The most competitive interest rates. Fill in our quick pre-qualification form and find out how much of a loan you would qualify for. Visit this website: http://3499894548/%7ez99 (If link doesn't come right up, try refresh) -Save Time -Save Money -Save Aggravation There is NEVER any fee to consumers for using this service. _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ If you have received this message in error and would like to be removed from future mailings, please reply with the word remove in the subject. _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ From rem-conf Mon Dec 13 00:54:45 1999 From rem-conf-request@es.net Mon Dec 13 00:54:44 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11xQyg-0005yG-00; Mon, 13 Dec 1999 00:37:06 -0800 Received: from ursamajor.cisco.com [171.69.63.56] by mail1.es.net with esmtp (Exim 1.81 #2) id 11xQye-0005wT-00; Mon, 13 Dec 1999 00:37:05 -0800 Received: from casner-dsl3.cisco.com (casner-dsl3.cisco.com [10.19.3.100]) by ursamajor.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id AAA01675; Mon, 13 Dec 1999 00:35:44 -0800 (PST) Date: Mon, 13 Dec 1999 00:35:08 -0800 (Pacific Standard Time) From: Stephen Casner To: Ram Kordale cc: rem-conf@es.net Subject: Re: (Fwd) MPEG-1 over RTP (RFC 2250) conflict? In-Reply-To: <9912092017.ZM15428@relic.engr.sgi.com> Message-ID: Sender: casner@cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list On Thu, 9 Dec 1999, Ram Kordale wrote: > I forwarded my message to one of the authors of RFC 2250. He suggested that the > solution to my example scenario is that P13 and P23 would have different > timestamps. I disagreed because 1) they need not have different timestamps and > 2) even if they are different there is no mechanism in RTP headers to > distinguish them. I have not heard from him since! Your 1) is not correct. P13 and P23 must have different timestamps. Even P12 and P13 must have different timestamps. That is how the multiple packets of one picture are distinguished from the multiple packets of another picture. This is a characteristic of most video payload formats for RTP. Your 2) I don't understand. The timestamps are in the RTP header and they are the mechanism to distinguish the two GOPs. Granted, one must be able to tell from the delta between timestamp values whether the lost packets constitute a gap of one frame or a whole GOP. If the frame rate is constant and known, as it usually is for MPEG, then this is easy. If the frame rate is variable, you might not be able to tell. -- Steve > --- Forwarded mail from ("Ram Kordale") > > From: "Ram Kordale" > Date: Fri, 3 Dec 1999 15:26:06 -0800 > To: rem-conf@es.net > Subject: MPEG-1 over RTP (RFC 2250) conflict? > > Could someone please clarify the following "conflict" I see in the spec? > > In the event of data loss, RFC 2250 has mechanisms to recover at the slice > level(basically by discarding RTP packets until you find one with the > BeginningOfSlice bit set to 1). > > However, if you lose a few RTP packets, one is **really forced** to skip > until the beginning of the next GOP! > > This is an incredible amount of loss or I have misunderstood the spec. Could > someone please clarify? > > > Details: > ------- > > Consider the following segment of MPEG-1 system stream. > ...GOP_H P11 P12 P13 ... P1n GOP_H P21 P22 P23 ... > > GOP_H refers to GOP Headers. Pij refers to picture j of the ith GOP. > > For simplicity, assume that the stream and display order are the same. Thus, > Pij will have a "Temporal Reference" of j. For simplicity, assume each > picture is split into 5 RTP packets. > > Suppose I receive RTP packets containing all of the first GOP header and > P11 and I receive 1 RTP packet containing the first "piece" of P12. > > Suppose the next RTP packet I received contains the "Temporal Reference" > of 3, how do I know which GOP this picture belongs to. In other words, how > do I know it belongs to P13 or P23 or in general Pi3. > > If I cannot know, I will have to insert a broken GOP thus essentially > losing data until the next GOP header is received. > > Thanks for your help. > Ram > > -- > Ram Kordale > Advanced Media Products > > > ---End of forwarded mail from ("Ram Kordale") From rem-conf Mon Dec 13 04:04:54 1999 From rem-conf-request@es.net Mon Dec 13 04:04:52 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11xU89-00008q-00; Mon, 13 Dec 1999 03:59:05 -0800 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 11xU86-00008g-00; Mon, 13 Dec 1999 03:59:02 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00770; Mon, 13 Dec 1999 06:59:00 -0500 (EST) Message-Id: <199912131159.GAA00770@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rem-conf@es.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-tones-04.txt,.ps Date: Mon, 13 Dec 1999 06:59:00 -0500 Sender: nsyracus@cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals Author(s) : H. Schulzrinne, S. Petrack Filename : draft-ietf-avt-tones-04.txt,.ps Pages : 29 Date : 10-Dec-99 This memo describes how to carry dual-tone multifrequency (DTMF) signaling, other tone signals and telephony events in RTP packets. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-tones-04.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-avt-tones-04.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-avt-tones-04.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: <19991210114900.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-tones-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-tones-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991210114900.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Mon Dec 13 07:53:57 1999 From rem-conf-request@es.net Mon Dec 13 07:53:56 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11xXjz-0003I5-00; Mon, 13 Dec 1999 07:50:23 -0800 Received: from deliverator.sgi.com [204.94.214.10] by mail1.es.net with esmtp (Exim 1.81 #2) id 11xXjy-0003Hu-00; Mon, 13 Dec 1999 07:50:22 -0800 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id HAA05422; Mon, 13 Dec 1999 07:45:59 -0800 (PST) mail_from (kordale@relic.engr.sgi.com) Received: from relic.engr.sgi.com (relic.engr.sgi.com [198.29.115.71]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via SMTP id HAA03595; Mon, 13 Dec 1999 07:50:14 -0800 (PST) mail_from (kordale@relic.engr.sgi.com) Received: (from kordale@localhost) by relic.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id HAA19081; Mon, 13 Dec 1999 07:50:13 -0800 From: kordale@relic.engr.sgi.com (Ram Kordale) Message-Id: <199912131550.HAA19081@relic.engr.sgi.com> Subject: Re: (Fwd) MPEG-1 over RTP (RFC 2250) conflict? To: casner@cisco.com (Stephen Casner) Date: Mon, 13 Dec 1999 07:50:13 -0800 (PST) Cc: rem-conf@es.net In-Reply-To: from "Stephen Casner" at Dec 13, 99 00:35:08 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > > On Thu, 9 Dec 1999, Ram Kordale wrote: > > > I forwarded my message to one of the authors of RFC 2250. He suggested that the > > solution to my example scenario is that P13 and P23 would have different > > timestamps. I disagreed because 1) they need not have different timestamps and > > 2) even if they are different there is no mechanism in RTP headers to > > distinguish them. I have not heard from him since! > > Your 1) is not correct. P13 and P23 must have different timestamps. > Even P12 and P13 must have different timestamps. That is how the > multiple packets of one picture are distinguished from the multiple > packets of another picture. This is a characteristic of most video > payload formats for RTP. > Thank you very much for the response. I was interpreting the RTP timestamps for MPEG ES encapsulation to be the PTS from the MPEG system stream and so I was asserting (1). > Your 2) I don't understand. The timestamps are in the RTP header and > they are the mechanism to distinguish the two GOPs. Granted, one must > be able to tell from the delta between timestamp values whether the > lost packets constitute a gap of one frame or a whole GOP. If the > frame rate is constant and known, as it usually is for MPEG, then this > is easy. If the frame rate is variable, you might not be able to > tell. This is exactly the case I am talking about. I am thinking of the following solution to the problem. However, it breaks your assertion that P12 and P13 must have different RTP timestamps. I would really appreciate the group's input on the pros and cons. Posssible solution: Let all pictures between two I-pictures (including the first I-picture) be called a "mini-GOP"; then, the following apply: 1) All RTP packets for pictures in a mini-GOP must have the same RTP timestamp. 2) RTP packets for pictures from different mini-GOPs must have different RTP timestamps. This gives the mechanism to recover from (2) and the ability to reconstruct valid and useful GOP headers. Ram > -- Steve > > > --- Forwarded mail from ("Ram Kordale") > > > > From: "Ram Kordale" > > Date: Fri, 3 Dec 1999 15:26:06 -0800 > > To: rem-conf@es.net > > Subject: MPEG-1 over RTP (RFC 2250) conflict? > > > > Could someone please clarify the following "conflict" I see in the spec? > > > > In the event of data loss, RFC 2250 has mechanisms to recover at the slice > > level(basically by discarding RTP packets until you find one with the > > BeginningOfSlice bit set to 1). > > > > However, if you lose a few RTP packets, one is **really forced** to skip > > until the beginning of the next GOP! > > > > This is an incredible amount of loss or I have misunderstood the spec. Could > > someone please clarify? > > > > > > Details: > > ------- > > > > Consider the following segment of MPEG-1 system stream. > > ...GOP_H P11 P12 P13 ... P1n GOP_H P21 P22 P23 ... > > > > GOP_H refers to GOP Headers. Pij refers to picture j of the ith GOP. > > > > For simplicity, assume that the stream and display order are the same. Thus, > > Pij will have a "Temporal Reference" of j. For simplicity, assume each > > picture is split into 5 RTP packets. > > > > Suppose I receive RTP packets containing all of the first GOP header and > > P11 and I receive 1 RTP packet containing the first "piece" of P12. > > > > Suppose the next RTP packet I received contains the "Temporal Reference" > > of 3, how do I know which GOP this picture belongs to. In other words, how > > do I know it belongs to P13 or P23 or in general Pi3. > > > > If I cannot know, I will have to insert a broken GOP thus essentially > > losing data until the next GOP header is received. > > > > Thanks for your help. > > Ram > > > > -- > > Ram Kordale > > Advanced Media Products > > > > > > ---End of forwarded mail from ("Ram Kordale") > -- Ram Kordale Advanced Media Products From rem-conf Mon Dec 13 08:27:16 1999 From rem-conf-request@es.net Mon Dec 13 08:27:15 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11xYHx-0004KH-00; Mon, 13 Dec 1999 08:25:29 -0800 Received: from mail-blue.research.att.com [135.207.30.102] by mail1.es.net with esmtp (Exim 1.81 #2) id 11xYHv-0004K7-00; Mon, 13 Dec 1999 08:25:27 -0800 Received: from surfcity.research.att.com (surfcity.research.att.com [135.207.128.5]) by mail-blue.research.att.com (Postfix) with ESMTP id BD4F34CE09; Mon, 13 Dec 1999 11:25:26 -0500 (EST) Received: from pcmrcfast (pcmrcfast [135.207.131.70]) by surfcity.research.att.com (8.8.7/8.8.7) with SMTP id LAA04468; Mon, 13 Dec 1999 11:24:44 -0500 (EST) Message-ID: <013801bf4586$9d3d07a0$4683cf87@research.att.com> Reply-To: "M. Reha Civanlar" From: "M. Reha Civanlar" To: "Ram Kordale" , "Stephen Casner" Cc: References: <199912131550.HAA19081@relic.engr.sgi.com> Subject: Re: (Fwd) MPEG-1 over RTP (RFC 2250) conflict? Date: Mon, 13 Dec 1999 11:25:05 -0500 Organization: AT&T Labs - Research 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.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list ----- Original Message ----- > I was interpreting the RTP timestamps for MPEG ES encapsulation to be the > PTS from the MPEG system stream and so I was asserting (1). > > > > Your 2) I don't understand. The timestamps are in the RTP header and > > they are the mechanism to distinguish the two GOPs. Granted, one must > > be able to tell from the delta between timestamp values whether the > > lost packets constitute a gap of one frame or a whole GOP. If the > > frame rate is constant and known, as it usually is for MPEG, then this > > is easy. If the frame rate is variable, you might not be able to > > tell. The temporal reference field, TR, in the header, which counts pictures and resets at each GOP header, is to be used for this purpose. Please, READ the appendix of RFC 2250. ------------------------------------------------------------ ----------- M. Reha Civanlar Division Manager, AT&T Labs - Research 100 Schultz Drive, Red Bank, NJ 07701, U.S.A civanlar@research.att.com Phone: +1 732 345 3305 Fax:+1 732 345 3033 http://www.research.att.com/info/mrc From rem-conf Mon Dec 13 10:21:38 1999 From rem-conf-request@es.net Mon Dec 13 10:21:37 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11xa45-0006vC-00; Mon, 13 Dec 1999 10:19:17 -0800 Received: from sgi.sgi.com (sgi.com) [192.48.153.1] by mail1.es.net with esmtp (Exim 1.81 #2) id 11xa43-0006v0-00; Mon, 13 Dec 1999 10:19:16 -0800 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id KAA05528; Mon, 13 Dec 1999 10:18:22 -0800 (PST) mail_from (kordale@relic.engr.sgi.com) Received: from relic.engr.sgi.com (relic.engr.sgi.com [198.29.115.71]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via SMTP id KAA85822; Mon, 13 Dec 1999 10:18:18 -0800 (PST) mail_from (kordale@relic.engr.sgi.com) Received: (from kordale@localhost) by relic.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id KAA19289; Mon, 13 Dec 1999 10:18:17 -0800 From: "Ram Kordale" Message-Id: <9912131018.ZM19287@relic.engr.sgi.com> Date: Mon, 13 Dec 1999 10:18:17 -0800 In-Reply-To: "M. Reha Civanlar" "Re: (Fwd) MPEG-1 over RTP (RFC 2250) conflict?" (Dec 13, 11:25am) References: <199912131550.HAA19081@relic.engr.sgi.com> <013801bf4586$9d3d07a0$4683cf87@research.att.com> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: "M. Reha Civanlar" , "Stephen Casner" Subject: Re: MPEG-1 over RTP (RFC 2250) conflict? Cc: kordale@relic.engr.sgi.com, Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I have read the appendix. Let me make my example simpler. Consider the following stream: GOPHdr1 P11 P12 GOPHdr2 P21 P22 GOPHdr3... For simplicity, I am not distinguishing picture types and maintaining only one temporal reference counter. Suppose: 1) Each of the pictures is fragmented into 3 RTP packets. 2) Client receives the first RTP packet of the first GOP and loses the next two. 3) Client then receives first RTP packet corresponding to P22. The scheme in your appendix will not help the client recognize that a GOP hdr was lost because the client TR counter is at 2 and the TR field in the RTP packet is also 2. Have I assumed something wrongly here? Thanks. Ram On Dec 13, 11:25am, M. Reha Civanlar wrote: > Subject: Re: (Fwd) MPEG-1 over RTP (RFC 2250) conflict? > > > > Your 2) I don't understand. The timestamps are in the > RTP header and > > > they are the mechanism to distinguish the two GOPs. > Granted, one must > > > be able to tell from the delta between timestamp values > whether the > > > lost packets constitute a gap of one frame or a whole > GOP. If the > > > frame rate is constant and known, as it usually is for > MPEG, then this > > > is easy. If the frame rate is variable, you might not > be able to > > > tell. > > The temporal reference field, TR, in the header, which > counts pictures and > resets at each GOP header, is to be used for this purpose. > Please, READ the appendix of RFC 2250. > -- Ram Kordale Advanced Media Products From rem-conf Mon Dec 13 12:19:17 1999 From rem-conf-request@es.net Mon Dec 13 12:19:16 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11xbsn-0001mo-00; Mon, 13 Dec 1999 12:15:45 -0800 Received: from h-135-207-30-103.research.att.com (mail-green.research.att.com) [135.207.30.103] by mail1.es.net with esmtp (Exim 1.81 #2) id 11xbsm-0001md-00; Mon, 13 Dec 1999 12:15:44 -0800 Received: from surfcity.research.att.com (surfcity.research.att.com [135.207.128.5]) by mail-green.research.att.com (Postfix) with ESMTP id 1E7631E03E; Mon, 13 Dec 1999 15:15:43 -0500 (EST) Received: from pcmrcfast (pcmrcfast [135.207.131.70]) by surfcity.research.att.com (8.8.7/8.8.7) with SMTP id PAA16787; Mon, 13 Dec 1999 15:15:01 -0500 (EST) Message-ID: <020e01bf45a6$c82dddc0$4683cf87@research.att.com> Reply-To: "M. Reha Civanlar" From: "M. Reha Civanlar" To: "Ram Kordale" Cc: References: <199912131550.HAA19081@relic.engr.sgi.com> <013801bf4586$9d3d07a0$4683cf87@research.att.com> <9912131018.ZM19287@relic.engr.sgi.com> Subject: Re: MPEG-1 over RTP (RFC 2250) conflict? Date: Mon, 13 Dec 1999 15:15:21 -0500 Organization: AT&T Labs - Research 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.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Yes, if you allow for variable framerates AND large variations in the bitrates AND you loose a large number of packets (covering one or more GOP's entirely), you may not be able to tell whether you lost a GOP header or not using the existing mechanisms. However, under these circumstances, I don't think that you will be able to do much even if you do detect a GOP header loss. -Reha ----- Original Message ----- From: Ram Kordale To: M. Reha Civanlar ; Stephen Casner Cc: ; Sent: Monday, December 13, 1999 1:18 PM Subject: Re: MPEG-1 over RTP (RFC 2250) conflict? > I have read the appendix. Let me make my example simpler. Consider the > following stream: GOPHdr1 P11 P12 GOPHdr2 P21 P22 GOPHdr3... > > For simplicity, I am not distinguishing picture types and maintaining only one > temporal reference counter. Suppose: > > 1) Each of the pictures is fragmented into 3 RTP packets. > 2) Client receives the first RTP packet of the first GOP and loses the next > two. > 3) Client then receives first RTP packet corresponding to P22. > > The scheme in your appendix will not help the client recognize that a GOP hdr > was lost because the client TR counter is at 2 and the TR field in the RTP > packet is also 2. > > Have I assumed something wrongly here? > > Thanks. > Ram > > On Dec 13, 11:25am, M. Reha Civanlar wrote: > > Subject: Re: (Fwd) MPEG-1 over RTP (RFC 2250) conflict? > > > > > > Your 2) I don't understand. The timestamps are in the > > RTP header and > > > > they are the mechanism to distinguish the two GOPs. > > Granted, one must > > > > be able to tell from the delta between timestamp values > > whether the > > > > lost packets constitute a gap of one frame or a whole > > GOP. If the > > > > frame rate is constant and known, as it usually is for > > MPEG, then this > > > > is easy. If the frame rate is variable, you might not > > be able to > > > > tell. > > > > The temporal reference field, TR, in the header, which > > counts pictures and > > resets at each GOP header, is to be used for this purpose. > > Please, READ the appendix of RFC 2250. > > > > > -- > Ram Kordale > Advanced Media Products > From rem-conf Mon Dec 13 13:48:00 1999 From rem-conf-request@es.net Mon Dec 13 13:47:58 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11xdHa-0003pY-00; Mon, 13 Dec 1999 13:45:26 -0800 Received: from pneumatic-tube.sgi.com [204.94.214.22] by mail1.es.net with esmtp (Exim 1.81 #2) id 11xdHY-0003pI-00; Mon, 13 Dec 1999 13:45:24 -0800 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id NAA02663; Mon, 13 Dec 1999 13:46:57 -0800 (PST) mail_from (kordale@relic.engr.sgi.com) Received: from relic.engr.sgi.com (relic.engr.sgi.com [198.29.115.71]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via SMTP id NAA98380; Mon, 13 Dec 1999 13:45:11 -0800 (PST) mail_from (kordale@relic.engr.sgi.com) Received: (from kordale@localhost) by relic.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id NAA19537; Mon, 13 Dec 1999 13:45:04 -0800 From: "Ram Kordale" Message-Id: <9912131345.ZM19535@relic.engr.sgi.com> Date: Mon, 13 Dec 1999 13:45:04 -0800 In-Reply-To: "M. Reha Civanlar" "Re: MPEG-1 over RTP (RFC 2250) conflict?" (Dec 13, 3:15pm) References: <199912131550.HAA19081@relic.engr.sgi.com> <013801bf4586$9d3d07a0$4683cf87@research.att.com> <9912131018.ZM19287@relic.engr.sgi.com> <020e01bf45a6$c82dddc0$4683cf87@research.att.com> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: "M. Reha Civanlar" Subject: Re: MPEG-1 over RTP (RFC 2250) conflict? Cc: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I do not see what frame rate and bit rate have to do with this given that they have no relationship to the number of pictures in a GOP. Given this, losing a GOP is not abnormal. However, you may be right in that we should *NOT* be looking for a GOP header loss after all. We could either (i) Just recover at the slice level and not care which GOP a picture belongs to and possibly deteriorate viewing quality. (ii) OR add provisions in the spec to determine an I picture loss (which is more significant anyway). My "mini-GOP" proposal addresses (ii). I would appreciate comments on (i) vs (ii) and on the proposal for (ii). Thanks. Ram On Dec 13, 3:15pm, M. Reha Civanlar wrote: > Subject: Re: MPEG-1 over RTP (RFC 2250) conflict? > Yes, if you allow for variable framerates AND large variations in the bitrates > AND you loose a large number of packets (covering one or more GOP's > entirely), you may not be able to tell whether you lost a GOP header or not > using the existing mechanisms. However, under these circumstances, I don't think > that you will be able to do much even if you do detect a GOP header loss. > > -Reha > > ----- Original Message ----- > From: Ram Kordale > To: M. Reha Civanlar ; Stephen Casner > > Cc: ; > Sent: Monday, December 13, 1999 1:18 PM > Subject: Re: MPEG-1 over RTP (RFC 2250) conflict? > > > > I have read the appendix. Let me make my example simpler. Consider the > > following stream: GOPHdr1 P11 P12 GOPHdr2 P21 P22 GOPHdr3... > > > > For simplicity, I am not distinguishing picture types and maintaining only one > > temporal reference counter. Suppose: > > > > 1) Each of the pictures is fragmented into 3 RTP packets. > > 2) Client receives the first RTP packet of the first GOP and loses the next > > two. > > 3) Client then receives first RTP packet corresponding to P22. > > > > The scheme in your appendix will not help the client recognize that a GOP hdr > > was lost because the client TR counter is at 2 and the TR field in the RTP > > packet is also 2. > > > > Have I assumed something wrongly here? > > > > Thanks. > > Ram > > > > On Dec 13, 11:25am, M. Reha Civanlar wrote: > > > Subject: Re: (Fwd) MPEG-1 over RTP (RFC 2250) conflict? > > > > > > > > Your 2) I don't understand. The timestamps are in the > > > RTP header and > > > > > they are the mechanism to distinguish the two GOPs. > > > Granted, one must > > > > > be able to tell from the delta between timestamp values > > > whether the > > > > > lost packets constitute a gap of one frame or a whole > > > GOP. If the > > > > > frame rate is constant and known, as it usually is for > > > MPEG, then this > > > > > is easy. If the frame rate is variable, you might not > > > be able to > > > > > tell. > > > > > > The temporal reference field, TR, in the header, which > > > counts pictures and > > > resets at each GOP header, is to be used for this purpose. > > > Please, READ the appendix of RFC 2250. > > > > > > > > > -- > > Ram Kordale > > Advanced Media Products > > >-- End of excerpt from M. Reha Civanlar -- Ram Kordale Advanced Media Products From rem-conf Mon Dec 13 14:49:52 1999 From rem-conf-request@es.net Mon Dec 13 14:49:50 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11xeFk-0005Sm-00; Mon, 13 Dec 1999 14:47:36 -0800 Received: from h-135-207-30-103.research.att.com (mail-green.research.att.com) [135.207.30.103] by mail1.es.net with esmtp (Exim 1.81 #2) id 11xeFh-0005SY-00; Mon, 13 Dec 1999 14:47:33 -0800 Received: from surfcity.research.att.com (surfcity.research.att.com [135.207.128.5]) by mail-green.research.att.com (Postfix) with ESMTP id 78C681E029; Mon, 13 Dec 1999 17:47:28 -0500 (EST) Received: from pcmrcfast (pcmrcfast [135.207.131.70]) by surfcity.research.att.com (8.8.7/8.8.7) with SMTP id RAA24346; Mon, 13 Dec 1999 17:46:46 -0500 (EST) Message-ID: <022801bf45bb$fb41af10$4683cf87@research.att.com> Reply-To: "M. Reha Civanlar" From: "M. Reha Civanlar" To: "Ram Kordale" Cc: References: <199912131550.HAA19081@relic.engr.sgi.com> <013801bf4586$9d3d07a0$4683cf87@research.att.com> <9912131018.ZM19287@relic.engr.sgi.com> <020e01bf45a6$c82dddc0$4683cf87@research.att.com> <9912131345.ZM19535@relic.engr.sgi.com> Subject: Re: MPEG-1 over RTP (RFC 2250) conflict? Date: Mon, 13 Dec 1999 17:47:05 -0500 Organization: AT&T Labs - Research 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.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list The bitrate and the framerate get into the picture because, for conventional rates and applications, you can use the sequence number and the timestamp to determine the possibility of a GOP header loss most of the time even under large packet losses that cover one or more GOPs. The problem with your proposal is that it decreases the accuracy of the timestamps which are used for many important functions including jitter computation and media synchronization. As I mentioned before, if the extent of the packet loss is such that an entire GOP is lost, knowing that a GOP header is lost may not be useful for any practical purpose. -Reha ----- Original Message ----- From: Ram Kordale To: M. Reha Civanlar Cc: Sent: Monday, December 13, 1999 4:45 PM Subject: Re: MPEG-1 over RTP (RFC 2250) conflict? > I do not see what frame rate and bit rate have to do with this given that they > have no relationship to the number of pictures in a GOP. Given this, losing a > GOP is not abnormal. > > However, you may be right in that we should *NOT* be looking for a GOP header > loss after all. We could either > (i) Just recover at the slice level and not care which GOP a picture belongs to > and possibly deteriorate viewing quality. > (ii) OR add provisions in the spec to determine an I picture loss (which is > more significant anyway). > > My "mini-GOP" proposal addresses (ii). > > I would appreciate comments on (i) vs (ii) and on the proposal for (ii). > > Thanks. > Ram From rem-conf Tue Dec 14 04:06:54 1999 From rem-conf-request@es.net Tue Dec 14 04:06:53 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11xqYd-0005qS-00; Tue, 14 Dec 1999 03:55:55 -0800 Received: from gwsmtp.thomson-csf.com [195.101.39.226] by mail1.es.net with esmtp (Exim 1.81 #2) id 11xqYb-0005qG-00; Tue, 14 Dec 1999 03:55:54 -0800 X-Internal-ID: 3854E48D0000E341 Received: from thomplex.thomson-csf.com (200.3.2.2) by gwsmtp.thomson-csf.com (NPlex 2.0.123) for rem-conf@es.net; Tue, 14 Dec 1999 12:57:11 +0100 X-Internal-ID: 384E98310003B268 Received: from thomplex.thomson-csf.com (200.3.2.2) by thomplex.thomson-csf.com (NPlex 2.0.124) for rem-conf@es.net; Tue, 14 Dec 1999 12:54:25 +0100 Received: from 178.1.4.1 by thomplex.thomson-csf.com (InterScan E-Mail VirusWall NT); Tue, 14 Dec 1999 12:54:25 +0100 (Paris, Madrid) X-Internal-ID: 3831099E0000B291 Received: from zeus.SNMRennes.thomcast.thomson-csf.com (178.3.1.130) by cnfplex.thomcast.thomson-csf.com (NPlex 2.0.124) for rem-conf@es.net; Tue, 14 Dec 1999 12:57:05 +0100 Received: from thomcast.thomson-csf.com ([178.3.1.150]) by zeus.SNMRennes.thomcast.thomson-csf.com (Netscape Messaging Server 3.5) with ESMTP id 503 for ; Tue, 14 Dec 1999 12:53:58 +0100 Message-ID: <385630B4.F2E95FEC@thomcast.thomson-csf.com> Date: Tue, 14 Dec 1999 12:57:40 +0100 From: "Tony Berthaud" X-Mailer: Mozilla 4.5 [fr] (WinNT; I) X-Accept-Language: fr MIME-Version: 1.0 To: "rem-conf@es.net" Subject: MPEG-2 Transport Stream over IP Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hello, Is anybody has information about the MPEG-2 TS over IP ? Is there a RFC or a DVB/ATSC application notes about this subject ? Best regards. Tony From rem-conf Tue Dec 14 07:22:56 1999 From rem-conf-request@es.net Tue Dec 14 07:22:55 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11xtIp-0000J6-00; Tue, 14 Dec 1999 06:51:47 -0800 Received: from basil.cdt.luth.se [130.240.64.67] by mail1.es.net with esmtp (Exim 1.81 #2) id 11xtIo-0000Il-00; Tue, 14 Dec 1999 06:51:46 -0800 Received: from tua.cdt.luth.se (tua.cdt.luth.se [130.240.64.43]) by basil.cdt.luth.se (8.9.3/8.7.3) with SMTP id PAA10911; Tue, 14 Dec 1999 15:50:43 +0100 (MET) Message-Id: <3.0.6.32.19991214155247.00a05a50@basil.cdt.luth.se> X-Sender: micke@basil.cdt.luth.se X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Tue, 14 Dec 1999 15:52:47 +0100 To: PILC Mailing List , AVT Mailing List , IPNG Mailing List From: Mikael Degermark Subject: ROBHC mailing list Cc: micke@cdt.luth.se Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Folks, This is an announcement of the mailing list to be used for issues concerning robust header compression as outlined by the robhc BOF held in Washington. Please take a look at the tentative WG charter http://www.cdt.luth.se/~micke/robhc-charter.txt The mailing list is robhc@cdt.luth.se Subscribe by sending an email to: majordomo@cdt.luth.se where the body of the email contains the single line subscribe robhc@cdt.luth.se Let's talk about whether additional TCP header compression is needed and specifically what TCP headers we should aim to compress. Seems to me that as a first approximation, compression of SACK options, TIMESTAMP options, and T/TCP headers might be worthwhile over low-bandwidth and high-latency links. Cheers, Mikael Degermark From rem-conf Tue Dec 14 08:26:08 1999 From rem-conf-request@es.net Tue Dec 14 08:26:08 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11xuj2-0001se-00; Tue, 14 Dec 1999 08:22:56 -0800 Received: from wodc7mr3.ffx.ops.us.uu.net [192.48.96.19] by mail1.es.net with esmtp (Exim 1.81 #2) id 11xuj0-0001sU-00; Tue, 14 Dec 1999 08:22:54 -0800 Received: from dynamic.dynamicsoft.com by wodc7mr3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [63.72.186.2]) id QQhtor03355 for ; Tue, 14 Dec 1999 16:20:53 GMT Received: from dynamicsoft.com (1Cust250.tnt1.freehold.nj.da.uu.net [63.17.113.250]) by dynamic.dynamicsoft.com (8.9.3/8.9.3) with ESMTP id LAA09065 for ; Tue, 14 Dec 1999 11:22:51 -0500 (EST) Message-ID: <38567024.DCE11007@dynamicsoft.com> Date: Tue, 14 Dec 1999 11:28:20 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: rem-conf@es.net Subject: [Fwd: Query on RTP] Content-Type: multipart/mixed; boundary="------------11EB22D9D9624E15E42B3ECB" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. --------------11EB22D9D9624E15E42B3ECB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit this belongs on rem-conf, which handles RTP questions. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com --------------11EB22D9D9624E15E42B3ECB Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Received: from wodc7mr3.ffx.ops.us.uu.net by wodc7ps1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7mr3.ffx.ops.us.uu.net [192.48.96.19]) id QQhtor05070; Tue, 14 Dec 1999 16:19:44 GMT Received: from zephyr.isi.edu by wodc7mr3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: zephyr.isi.edu [128.9.160.160]) id QQhtor25886; Tue, 14 Dec 1999 16:17:17 GMT Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id GAA12718 for confctrl-outgoing; Tue, 14 Dec 1999 06:35:21 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id GAA12712 for ; Tue, 14 Dec 1999 06:35:19 -0800 (PST) Received: from samar.sasi.com (sasi.com [164.164.56.2]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id GAA18432 for ; Tue, 14 Dec 1999 06:35:18 -0800 (PST) Received: from samar (samar.sasi.com [164.164.56.2]) by samar.sasi.com (8.9.3/8.9.3) with SMTP id UAA15296 for ; Tue, 14 Dec 1999 20:06:06 +0530 (IST) Received: from sung17.sasi.com ([10.0.64.17]) by samar.sasi.com; Tue, 14 Dec 1999 20:06:05 +0000 (IST) Received: from sasi.com (pcg127.sasi.com [10.0.64.127]) by sung17.sasi.com (8.9.3/8.9.3) with ESMTP id UAA02436 for ; Tue, 14 Dec 1999 20:06:02 +0530 (IST) Message-ID: <385655D2.CBF6C379@sasi.com> Date: Tue, 14 Dec 1999 20:06:02 +0530 From: "Anil . H" Reply-To: anilh@sasi.com X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: "confctrl@ISI.EDU" Subject: Query on RTP Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-confctrl@ISI.EDU Precedence: bulk X-Mozilla-Status2: 00000000 Hi, I would like to know if it is mandatory to implement Mixers ans Translators at the terminal. Regards Anil --------------11EB22D9D9624E15E42B3ECB-- From rem-conf Tue Dec 14 15:50:21 1999 From rem-conf-request@es.net Tue Dec 14 15:50:20 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11y1dz-0001bE-00; Tue, 14 Dec 1999 15:46:11 -0800 Received: from (sdnu.edu.cn) [210.44.8.88] by mail1.es.net with smtp (Exim 1.81 #2) id 11y1dv-0001b3-00; Tue, 14 Dec 1999 15:46:09 -0800 Received: from computer by sdnu.edu.cn (SMI-8.6/SMI-SVR4) id DAA21571; Mon, 13 Dec 1999 03:43:40 +0800 Date: Mon, 13 Dec 1999 03:43:40 +0800 From: mike599@youpy.com Message-Id: <199912121943.DAA21571@sdnu.edu.cn> To: Subject: Search Engine Registration adv MIME-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I saw you listing on the internet. I work for a company that specializes in getting clients web sites listed as close to the top of major search engines as possible. Our fee is only $29.95 per month to submit your site at least twice a month to over 350 search engines and directories. To get started and put your web site in the fast lane, call our toll-free number below. Mike Bender 888-532-8842 *To be removed call: 888-800-6339 X1377 Sincerely, Mike Bender 888-532-8842 From rem-conf Thu Dec 16 08:33:35 1999 From rem-conf-request@es.net Thu Dec 16 08:33:34 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11ydL8-0007Uk-00; Thu, 16 Dec 1999 08:01:14 -0800 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 11ydL6-0007UY-00; Thu, 16 Dec 1999 08:01:12 -0800 Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 16 Dec 1999 16:00:19 +0000 To: rem-conf@es.net Subject: Reminder: WG last call in progess Date: Thu, 16 Dec 1999 16:00:18 +0000 Message-ID: <1481.945360018@cs.ucl.ac.uk> From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list A quick reminder that we are in the midst of a working group last call for the following drafts: Civanlar and Cash, "RTP Payload Format for Real-Time Pointers", draft-ietf-avt-pointer-00.txt Hellstrom, "RTP Payload for Text Conversation", draft-ietf-avt-rtp-text-02.txt If no comments requiring substantive changes are received by 22nd December, these drafts will be submitted for publication as standards track RFCs. Colin From rem-conf Thu Dec 16 09:43:02 1999 From rem-conf-request@es.net Thu Dec 16 09:43:01 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11yefi-00016l-00; Thu, 16 Dec 1999 09:26:34 -0800 Received: from huginn.cs.berkeley.edu [169.229.60.60] by mail1.es.net with esmtp (Exim 1.81 #2) id 11yefg-00016b-00; Thu, 16 Dec 1999 09:26:32 -0800 Received: from fielder (1Cust137.tnt9.sfo3.da.uu.net [63.23.26.137]) by huginn.CS.Berkeley.EDU with SMTP (8.7.1/8.7.1) id JAA12607 for ; Thu, 16 Dec 1999 09:26:31 -0800 (PST) Date: Thu, 16 Dec 1999 09:26:02 -0800 From: Koichi Yano To: rem-conf@es.net Subject: RTCP Retransmission Message-Id: <385920AA14.04F5YANO@pop.cs.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver 1.25.06 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list We are working on refining the RTCP retransmission draft. I have questions about how to negotiate the type of retransmission--whether or not retransmissions will be used, and if so what kind of retransmission algorithms/behavior will you use. In the IETF meeting, it was suggested that a new payload type should be defined in case of deployment of RTCP retransmission. Is there another possible mechanism for negotiation about RTCP deployment? Is it necessary to define a new payload type for each existing type? In other words, do we need to define new dynamic payload types like H261-rx, H263-rx, DAT12-rx, etc? When we want to add retransmission on exisiting static payload type, could it (a new payload type) become a problem for being deployed on original implementation? Koichi Yano From rem-conf Fri Dec 17 01:30:50 1999 From rem-conf-request@es.net Fri Dec 17 01:30:50 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11ytbU-0000cF-00; Fri, 17 Dec 1999 01:23:12 -0800 Received: from khumbu.eeng.dcu.ie [136.206.35.10] by mail1.es.net with smtp (Exim 1.81 #2) id 11ytbT-0000c5-00; Fri, 17 Dec 1999 01:23:11 -0800 Received: from (eeng.dcu.ie) [136.206.35.77] by khumbu.eeng.dcu.ie with esmtp (Exim 1.82 #1) id 11ytbK-0001kO-00; Fri, 17 Dec 1999 09:23:02 +0000 Message-ID: <385A00D4.CD5CEEAE@eeng.dcu.ie> Date: Fri, 17 Dec 1999 09:22:28 +0000 From: Nikki Cranley <94426082@eeng.dcu.ie> Reply-To: 94426082@eeng.dcu.ie X-Mailer: Mozilla 4.06 [en] (WinNT; I) MIME-Version: 1.0 To: Koichi Yano CC: rem-conf@es.net Subject: Re: RTCP Retransmission References: <385920AA14.04F5YANO@pop.cs.berkeley.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, I am looking at RTCP-Rx also with respect to MPEG-4. In MPEG-4 the BIFS and IOD are very important for establishing the transmission and replay of the MPEG-4 file. I am thinking of using ways to implement the RTCP-Rx to ensure that these files are received. I think that there should be new payload types defined to reflect different media types etc. The intended purpose of RTCP-Rx is selective retransmisison and so there need to be selection criteria otherwise its like TCP. Regards, Nikki Koichi Yano wrote: > We are working on refining the RTCP retransmission draft. > I have questions about how to negotiate the type of > retransmission--whether or not retransmissions will be > used, and if so what kind of retransmission > algorithms/behavior will you use. > > In the IETF meeting, it was suggested that a new payload type should be > defined in case of deployment of RTCP retransmission. > Is there another possible mechanism for negotiation about > RTCP deployment? > > Is it necessary to define a new payload type for each > existing type? In other words, do we need to > define new dynamic payload types like H261-rx, > H263-rx, DAT12-rx, etc? When we want to add > retransmission on exisiting static payload type, could > it (a new payload type) become a problem for being > deployed on original implementation? > > Koichi Yano From rem-conf Fri Dec 17 08:35:49 1999 From rem-conf-request@es.net Fri Dec 17 08:35:49 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11z0H4-000473-00; Fri, 17 Dec 1999 08:30:34 -0800 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 11z0H4-00046t-00; Fri, 17 Dec 1999 08:30:34 -0800 Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 17 Dec 1999 16:30:25 +0000 To: 94426082@eeng.dcu.ie cc: Koichi Yano , rem-conf@es.net Subject: Re: RTCP Retransmission In-reply-to: Your message of "Fri, 17 Dec 1999 09:22:28 GMT." <385A00D4.CD5CEEAE@eeng.dcu.ie> Date: Fri, 17 Dec 1999 16:30:22 +0000 Message-ID: <1201.945448222@cs.ucl.ac.uk> From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> Nikki Cranley writes: >I am looking at RTCP-Rx also with respect to MPEG-4. In MPEG-4 the BIFS and >IOD are very important for establishing the transmission and replay of the >MPEG-4 file. I am thinking of using ways to implement the RTCP-Rx to ensure >that these files are received. >I think that there should be new payload types defined to reflect different >media types etc. The intended purpose of RTCP-Rx is selective >retransmisison and so there need to be selection criteria otherwise its >like TCP. For unicast, I wonder if TCP is not the correct means of transporting this information, and would be interested in arguments why not. For multicast, I remind you of RFC2357 and the work in RMT, which might be appropriate. Cheers, Colin From rem-conf Fri Dec 17 08:35:52 1999 From rem-conf-request@es.net Fri Dec 17 08:35:52 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11z0Cs-00044W-00; Fri, 17 Dec 1999 08:26:14 -0800 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 11z0Cr-00044M-00; Fri, 17 Dec 1999 08:26:13 -0800 Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 17 Dec 1999 16:26:04 +0000 To: Koichi Yano cc: rem-conf@es.net Subject: Re: RTCP Retransmission In-reply-to: Your message of "Thu, 16 Dec 1999 09:26:02 PST." <385920AA14.04F5YANO@pop.cs.berkeley.edu> Date: Fri, 17 Dec 1999 16:26:02 +0000 Message-ID: <1162.945447962@cs.ucl.ac.uk> From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> Koichi Yano writes: >We are working on refining the RTCP retransmission draft. >I have questions about how to negotiate the type of >retransmission--whether or not retransmissions will be >used, and if so what kind of retransmission >algorithms/behavior will you use. > >In the IETF meeting, it was suggested that a new payload type should be >defined in case of deployment of RTCP retransmission. >Is there another possible mechanism for negotiation about >RTCP deployment? You could define a new RTP profile, which uses the existing set of payload formats but adds the retransmission scheme in RTCP (and, perhaps, also adds congestion control). That would be signalled in SDP, much like: m=audio 49000 RTP/rx-profile 0 with the "0" representing the payload type (PCMU audio, in this case), and the "RTP/rx-profile" indicating the new profile. Colin From rem-conf Fri Dec 17 08:44:11 1999 From rem-conf-request@es.net Fri Dec 17 08:44:11 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11z0So-0004sB-00; Fri, 17 Dec 1999 08:42:42 -0800 Received: from khumbu.eeng.dcu.ie [136.206.35.10] by mail1.es.net with smtp (Exim 1.81 #2) id 11z0Sm-0004rB-00; Fri, 17 Dec 1999 08:42:40 -0800 Received: from (eeng.dcu.ie) [136.206.35.77] by khumbu.eeng.dcu.ie with esmtp (Exim 1.82 #1) id 11z0SX-0000sV-00; Fri, 17 Dec 1999 16:42:25 +0000 Message-ID: <385A67D1.9FBCAE69@eeng.dcu.ie> Date: Fri, 17 Dec 1999 16:41:53 +0000 From: Nikki Cranley <94426082@eeng.dcu.ie> Reply-To: 94426082@eeng.dcu.ie X-Mailer: Mozilla 4.06 [en] (WinNT; I) MIME-Version: 1.0 To: Colin Perkins CC: Koichi Yano , rem-conf@es.net Subject: Re: RTCP Retransmission References: <1201.945448222@cs.ucl.ac.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi Colin - The problem with TCP is that for real-time or near real time transmission its not feasible to use TCP as there may be lost packets/delays etc.and retransmission of these will hinder the real-time ability - so RTP/UDP/IP is used. But in the case of MPEG-4 - there are some important packets that probably shouldn't be lost - imagine if the packet with all the decoding information got lost - well that would render everything else useless. I am looking at this only >from the perspective of unicast anyway - plus if we were to extend this to VR - then RTCP-Rx could be used to dictate user interaction as there is no scope for this in RTP/RTCP as far as I know. It would only be needed from client to server. I'm only new to this but thats what came to mind. I was thinking along the lines of say incorporating media specific functionality into the RTCP-Rx. Rgds, Nikki Colin Perkins wrote: > --> Nikki Cranley writes: > >I am looking at RTCP-Rx also with respect to MPEG-4. In MPEG-4 the BIFS and > >IOD are very important for establishing the transmission and replay of the > >MPEG-4 file. I am thinking of using ways to implement the RTCP-Rx to ensure > >that these files are received. > >I think that there should be new payload types defined to reflect different > >media types etc. The intended purpose of RTCP-Rx is selective > >retransmisison and so there need to be selection criteria otherwise its > >like TCP. > > For unicast, I wonder if TCP is not the correct means of transporting this > information, and would be interested in arguments why not. For multicast, > I remind you of RFC2357 and the work in RMT, which might be appropriate. > > Cheers, > Colin From rem-conf Fri Dec 17 08:53:05 1999 From rem-conf-request@es.net Fri Dec 17 08:53:05 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11z0c3-00068E-00; Fri, 17 Dec 1999 08:52:15 -0800 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 11z0c2-000682-00; Fri, 17 Dec 1999 08:52:14 -0800 Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 17 Dec 1999 16:52:07 +0000 To: 94426082@eeng.dcu.ie cc: Koichi Yano , rem-conf@es.net Subject: Re: RTCP Retransmission In-reply-to: Your message of "Fri, 17 Dec 1999 16:41:53 GMT." <385A67D1.9FBCAE69@eeng.dcu.ie> Date: Fri, 17 Dec 1999 16:52:05 +0000 Message-ID: <1307.945449525@cs.ucl.ac.uk> From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, --> Nikki Cranley writes: >The problem with TCP is that for real-time or near real time transmission its >not feasible to use TCP as there may be lost packets/delays etc.and >retransmission of these will hinder the real-time ability - so RTP/UDP/IP is >used. >But in the case of MPEG-4 - there are some important packets that probably >shouldn't be lost - imagine if the packet with all the decoding information got >lost - well that would render everything else useless. I am looking at this only >from the perspective of unicast anyway - plus if we were to extend this to VR - >then RTCP-Rx could be used to dictate user interaction as there is no scope for >this in RTP/RTCP as far as I know. It would only be needed from client to >server. >I'm only new to this but thats what came to mind. I was thinking along the lines >of say incorporating media specific functionality into the RTCP-Rx. I was envisaging that RTCP-Rx would be used for streams which need to be resilient to loss, but real-time and not 100% reliable. That fits for some types of MPEG-4 content, but other types MUST be delivered with 100% reliability, and I believe TCP is a better fit for these. Colin From rem-conf Fri Dec 17 10:34:05 1999 From rem-conf-request@es.net Fri Dec 17 10:34:05 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11z29o-0000Tz-00; Fri, 17 Dec 1999 10:31:12 -0800 Received: from mail-out2.apple.com [17.254.0.51] by mail1.es.net with esmtp (Exim 1.81 #2) id 11z29n-0000Tp-00; Fri, 17 Dec 1999 10:31:11 -0800 Received: from mailgate2.apple.com ([17.129.100.225]) by mail-out2.apple.com (8.9.3/8.9.3) with ESMTP id KAA21993 for ; Fri, 17 Dec 1999 10:31:02 -0800 (PST) Received: from scv1.apple.com (scv1.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Fri, 17 Dec 1999 10:30:59 -0800 Received: from [17.202.35.52] (singda.apple.com [17.202.35.52]) by scv1.apple.com (8.9.3/8.9.3) with ESMTP id KAA22560 for ; Fri, 17 Dec 1999 10:30:58 -0800 (PST) MIME-Version: 1.0 X-Sender: singer@mail.apple.com Message-Id: In-Reply-To: <1201.945448222@cs.ucl.ac.uk> References: <1201.945448222@cs.ucl.ac.uk> Date: Fri, 17 Dec 1999 10:28:32 -0800 To: rem-conf@es.net From: Dave Singer Subject: Re: RTCP Retransmission Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > >For unicast, I wonder if TCP is not the correct means of transporting this >information, and would be interested in arguments why not. My (personal) interest in using RTCP-based re-transmission is to cover the case where you want the receiver clock to run, even if data never arrives, but you want the greatly improved (but not perfect) reliability. You can't get both guaranteed delivery and on-time behavior. If you are willing to wait indefinitely, I can promise to deliver everything (or at least you cannot prove that I won't). For that case, TCP is mostly fine; the only wrinkle is knowing when you are starving because the sender sent nothing, and when you are starving because the network is denying you data. If you are not willing to wait indefinitely, TCP attempting for ever to re-transmit packets you no longer care about, and refusing to give you later packets that have already arrived, is unhelpful. This is the space I'd like to see a RTCP-based algorithm fit into. So I don't see it as a multicast/unicast thing, though of course an RTCP-based approach might lend itself to multicast. However, you then have to assess questions like "should every recipient on a multicast signal loss of a packet, or should they watch each other?", "should I re-multicast this packet to everyone or re-unicast it to the complainers?", and so on. Step 2, in my opinion. David Singer Apple Computer/QuickTime From rem-conf Fri Dec 17 11:29:48 1999 From rem-conf-request@es.net Fri Dec 17 11:29:48 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11z32T-0001lx-00; Fri, 17 Dec 1999 11:27:41 -0800 Received: from huginn.cs.berkeley.edu [169.229.60.60] by mail1.es.net with esmtp (Exim 1.81 #2) id 11z32S-0001ln-00; Fri, 17 Dec 1999 11:27:40 -0800 Received: from cs.berkeley.edu (scooby.CS.Berkeley.EDU [128.32.34.137]) by huginn.CS.Berkeley.EDU with ESMTP (8.7.1/8.7.1) id LAA11115; Fri, 17 Dec 1999 11:27:35 -0800 (PST) Sender: yano@huginn.CS.Berkeley.EDU Message-ID: <385A8EA6.4F0B46D0@cs.berkeley.edu> Date: Fri, 17 Dec 1999 11:27:34 -0800 From: Koichi Yano Reply-To: yano@cs.berkeley.edu Organization: University of California, Berkeley X-Mailer: Mozilla 4.06 [en] (X11; I; FreeBSD 2.2.7-STABLE i386) MIME-Version: 1.0 To: Colin Perkins CC: rem-conf@es.net Subject: Re: RTCP Retransmission References: <1307.945449525@cs.ucl.ac.uk> Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Colin Perkins wrote: > > Hi, > > --> Nikki Cranley writes: > >The problem with TCP is that for real-time or near real time transmission its > >not feasible to use TCP as there may be lost packets/delays etc.and > >retransmission of these will hinder the real-time ability - so RTP/UDP/IP is > >used. > >But in the case of MPEG-4 - there are some important packets that probably > >shouldn't be lost - imagine if the packet with all the decoding Hi, Colin Perkins wrote: > I was envisaging that RTCP-Rx would be used for streams which need to be > resilient to loss, but real-time and not 100% reliable. Basically, I agree with you. But we can prepare the flag for strong request, which means "send retransmission surely" wihtout thinking playout time or something. I think it is a good idea. By using a receiver's timer and tuning the frequency of re-request of retransmission, reliability could be tuned. Because the framework for retransmission request could be extensible to ACK (not NACK), TCP-like 100% relible protocol could be implemented on RTCP-rx. I think just deployment of TCP is the easiest way for 100% reliability, though. Koichi From rem-conf Fri Dec 17 12:22:08 1999 From rem-conf-request@es.net Fri Dec 17 12:22:07 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11z3pE-000338-00; Fri, 17 Dec 1999 12:18:04 -0800 Received: from mail-blue.research.att.com [135.207.30.102] by mail1.es.net with esmtp (Exim 1.81 #2) id 11z3pB-00032y-00; Fri, 17 Dec 1999 12:18:01 -0800 Received: from surfcity.research.att.com (surfcity.research.att.com [135.207.128.5]) by mail-blue.research.att.com (Postfix) with ESMTP id 9D6EB4CE43 for ; Fri, 17 Dec 1999 15:17:50 -0500 (EST) Received: from pcmrcfast (pcmrcfast [135.207.131.70]) by surfcity.research.att.com (8.8.7/8.8.7) with SMTP id PAA20071 for ; Fri, 17 Dec 1999 15:17:04 -0500 (EST) Message-ID: <009401bf48cb$b9fd7620$4683cf87@research.att.com> Reply-To: "M. Reha Civanlar" From: "M. Reha Civanlar" To: References: <1307.945449525@cs.ucl.ac.uk> Subject: Re: RTCP Retransmission Date: Fri, 17 Dec 1999 15:17:22 -0500 Organization: AT&T Labs - Research 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.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I agree that TCP is usable and sufficent for transferring the "vital" part of the data in a real-time streaming application. We actually used TCP successfully in transmitting high priority information with MPEG2 ES transport. RFC2448 outlines our general approach and observations. I believe, RTCP-Rx needs to be used when there is time for retransmission, but the data to be retransmitted is loss resilient (i.e. would be useful if received on-time but, not vital). ----------------------------------------------------------------------- M. Reha Civanlar ----- Original Message ----- From: Colin Perkins To: <94426082@eeng.dcu.ie> Cc: Koichi Yano ; Sent: Friday, December 17, 1999 11:52 AM Subject: Re: RTCP Retransmission > Hi, > > --> Nikki Cranley writes: > >The problem with TCP is that for real-time or near real time transmission its > >not feasible to use TCP as there may be lost packets/delays etc.and > >retransmission of these will hinder the real-time ability - so RTP/UDP/IP is > >used. > >But in the case of MPEG-4 - there are some important packets that probably > >shouldn't be lost - imagine if the packet with all the decoding information got > >lost - well that would render everything else useless. I am looking at this only > >from the perspective of unicast anyway - plus if we were to extend this to VR - > >then RTCP-Rx could be used to dictate user interaction as there is no scope for > >this in RTP/RTCP as far as I know. It would only be needed from client to > >server. > >I'm only new to this but thats what came to mind. I was thinking along the lines > >of say incorporating media specific functionality into the RTCP-Rx. > > I was envisaging that RTCP-Rx would be used for streams which need to be > resilient to loss, but real-time and not 100% reliable. That fits for some > types of MPEG-4 content, but other types MUST be delivered with 100% > reliability, and I believe TCP is a better fit for these. > > Colin > > From rem-conf Fri Dec 17 12:37:33 1999 From rem-conf-request@es.net Fri Dec 17 12:37:33 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11z42m-0003os-00; Fri, 17 Dec 1999 12:32:04 -0800 Received: from crufty.bell-labs.com (crufty.research.bell-labs.com) [204.178.16.49] by mail1.es.net with smtp (Exim 1.81 #2) id 11z42l-0003oc-00; Fri, 17 Dec 1999 12:32:03 -0800 Received: from grubby.research.bell-labs.com ([135.104.2.9]) by crufty; Fri Dec 17 15:31:56 EST 1999 To: rem-conf@es.net Received: from starling.research.bell-labs.com ([135.104.26.187]) by grubby; Fri Dec 17 15:31:51 EST 1999 Received: from starling.research.bell-labs.com (localhost [127.0.0.1]) by starling.research.bell-labs.com (8.9.1/8.9.1) with ESMTP id PAA06929; Fri, 17 Dec 1999 15:31:43 -0500 (EST) Message-Id: <199912172031.PAA06929@starling.research.bell-labs.com> Date: Fri, 17 Dec 1999 15:31:10 -0500 From: Jorg Nonnenmacher Subject: Hot Topic - Call for Paper X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list ------- Blind-Carbon-Copy X-Mailer: exmh version 2.0.2 2/24/98 To: nonnen@research.bell-labs.com Subject: Hot Topic - Call for Paper Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 17 Dec 1999 15:31:10 -0500 From: Jorg Nonnenmacher CALL FOR PAPERS: Special Issue of Computer Communications on Integrating Multicast into the Internet --------------------------------------- CFP URL: http://www.cs.ucsb.edu/~almeroth/COMCOM:cfp.html Journal URL: http://www.elsevier.com/inca/publications/store/5/2/5/4/4/0/ TOPICS: The amount of bandwidth available in the Internet is increasing dramatically, both in the backbone networks, as well as in the last mile (broadband access). One consequence is that the delivery of high-quality multimedia data will become feasible, and multimedia data, including audio and video, will become the dominant traffic. As more users gain access to broadband services, new applications and services will become possible. The result will be a growing demand for large-scale multimedia applications and services. Multicasting as a pure networking solution to the transport of media is recognized as offering economies-of-scale for large-scale applications. Multicast is also believed to enable applications which provide service to thousands, even millions of customers. While there has been significant research work on multicast, efforts to successfully deploy a production service have lagged. Reasons range from frequently changing protocols, management and engineering problems, legacy hardware limitations, traffic conflicts with unicast, etc.. This special issue focuses on research issues dealing with the challenges of deploying multicast in the network. Specific topics include, but are not limited to: * Multicast Congestion Control * Multicast Overlay Networks * Next-Generation Multicast Routing Algorithms * Multicast Media Transport * Security for Multicast-Based Services * Multicast Traffic Engineering and Management * Multicast Pricing and Quality of Service GUEST EDITORS: Kevin Almeroth Jorg Nonnenmacher Department of Computer Science Network Research Dept, Lucent Technologies University of California 600-700 Mountain Avenue Santa Barbara, CA 93106-5110 Murray Hill, NJ 07974-0636 Phone: +1(805) 893-2777 Phone: +1(908) 582-1707 Fax: +1(805) 893-8553 Fax: +1(908) 582-6632 Email: almeroth@cs.ucsb.edu Email: nonnen@research.bell-labs.com IMPORTANT DATES: Paper Submission Deadline: February 1, 2000 Feedback to Authors: May 1, 2000 Final Manuscripts Due: June 1, 2000 Publication Date: Fall 2000 SUBMISSION INSTRUCTIONS: Authors are requested to send e-mail to one or both of the Guest Editors (almeroth@cs.ucsb.edu, nonnen@research.bell-labs.com) giving a URL from where a postscript or PDF file can be downloaded. Successfully received papers will be acknowledged. AUTHOR INFORMATION: Submissions made to the special issue should not have appeared in, or been submitted to other archival publications. All papers will be subjected to the journal's usual refereeing process. ------- End of Blind-Carbon-Copy From rem-conf Fri Dec 17 14:23:42 1999 From rem-conf-request@es.net Fri Dec 17 14:23:42 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11z5jQ-0005ZT-00; Fri, 17 Dec 1999 14:20:12 -0800 Received: from havoc.entera.com [206.165.109.130] by mail1.es.net with esmtp (Exim 1.81 #2) id 11z5jO-0005Yf-00; Fri, 17 Dec 1999 14:20:10 -0800 Received: from tornado ([206.165.109.185]) by havoc.entera.com (Post.Office MTA v3.5.3 release 223 ID# 0-61971U200L100S0V35) with SMTP id com; Fri, 17 Dec 1999 14:33:58 -0800 Message-Id: <3.0.6.32.19991217142818.01530650@mailserver.entera.com> X-Sender: alagu@mailserver.entera.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Fri, 17 Dec 1999 14:28:18 -0800 To: rem-conf@es.net From: alagu@entera.com (Alagu Periyannan) Subject: Re: RTCP Retransmission Cc: yano@cs.berkeley.edu,Colin Perkins In-Reply-To: <385A8EA6.4F0B46D0@cs.berkeley.edu> References: <1307.945449525@cs.ucl.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list At 11:27 AM 12/17/99 -0800, Koichi Yano wrote: >Colin Perkins wrote: >> I was envisaging that RTCP-Rx would be used for streams which need to be >> resilient to loss, but real-time and not 100% reliable. > >Basically, I agree with you. > I think there is some merit in introducing the notion that certain RTP packets are indispensible, i.e. 100% reliable. When such packets are lost the receiver stops the clock and waits. This RTP feature should be used only in non-interactive (i.e. streaming) applications. It should not be used for video key frames and other such error resilient packets. We can keep saying use TCP for that, why bother enhancing RTP? If I use TCP, I have to build a hybrid protocol that uses RTP/UDP and TCP to achieve my goal. Why not make it simpler and offer the functionality in RTP? This issue has been the cause of the growth of proprietary streaming protocols by a number of vendors. Most of them have invented their own protocol and do not use RTP because of this missing functionality. Even some vendors such as Apple who are using RTP are implementing "repeat" packets to get around this which is very inefficient. Let's not preclude a "100% reliability" feature in RTP-Rx. -- Alagu Periyannan alagu@entera.com Entera, Inc. +1 510 770 5225 From rem-conf Fri Dec 17 14:45:42 1999 From rem-conf-request@es.net Fri Dec 17 14:45:41 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11z64S-0006KZ-00; Fri, 17 Dec 1999 14:41:56 -0800 Received: from mail-blue.research.att.com [135.207.30.102] by mail1.es.net with esmtp (Exim 1.81 #2) id 11z64Q-0006KP-00; Fri, 17 Dec 1999 14:41:54 -0800 Received: from surfcity.research.att.com (surfcity.research.att.com [135.207.128.5]) by mail-blue.research.att.com (Postfix) with ESMTP id 28D9F4CE0E for ; Fri, 17 Dec 1999 17:41:50 -0500 (EST) Received: from pcmrcfast (pcmrcfast [135.207.131.70]) by surfcity.research.att.com (8.8.7/8.8.7) with SMTP id RAA24480 for ; Fri, 17 Dec 1999 17:41:04 -0500 (EST) Message-ID: <016201bf48df$d7626540$4683cf87@research.att.com> Reply-To: "M. Reha Civanlar" From: "M. Reha Civanlar" To: References: <1307.945449525@cs.ucl.ac.uk> <3.0.6.32.19991217142818.01530650@mailserver.entera.com> Subject: Re: RTCP Retransmission Date: Fri, 17 Dec 1999 17:41:21 -0500 Organization: AT&T Labs - Research 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.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list ----- Original Message ----- From: Alagu Periyannan > I think there is some merit in introducing the notion that certain RTP > packets are indispensible, i.e. 100% reliable. When such packets are lost > the receiver stops the clock and waits. > > This RTP feature should be used only in non-interactive (i.e. streaming) > applications. It should not be used for video key frames and other such > error resilient packets. > I think, what the end point will do when a vital packet is lost is an implementation issue. Sending a packet with 100% reliability, on the other hand, is a protocol design issue. TCP does this for unicast and there is a WG for reliable multicast. > We can keep saying use TCP for that, why bother enhancing RTP? If I use > TCP, I have to build a hybrid protocol that uses RTP/UDP and TCP to achieve > my goal. Why not make it simpler and offer the functionality in RTP? The problem is that this won't make RTP simpler. > > This issue has been the cause of the growth of proprietary streaming > protocols by a number of vendors. Most of them have invented their own > protocol and do not use RTP because of this missing functionality. Even > some vendors such as Apple who are using RTP are implementing "repeat" > packets to get around this which is very inefficient. How can they achieve 100% reliability with "repeat" packets anyway? ----------------------------------------------------------------------- M. Reha Civanlar From rem-conf Fri Dec 17 16:29:19 1999 From rem-conf-request@es.net Fri Dec 17 16:29:18 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11z7h7-0007n2-00; Fri, 17 Dec 1999 16:25:57 -0800 Received: from shattuck.cs.berkeley.edu [128.32.130.16] by mail1.es.net with esmtp (Exim 1.81 #2) id 11z7h5-0007ms-00; Fri, 17 Dec 1999 16:25:55 -0800 Received: (from podolsky@localhost) by shattuck.CS.Berkeley.EDU (8.9.3/8.9.1) id QAA16966; Fri, 17 Dec 1999 16:25:52 -0800 (PST) Date: Fri, 17 Dec 1999 16:25:52 -0800 (PST) Message-Id: <199912180025.QAA16966@shattuck.CS.Berkeley.EDU> From: Matt Podolsky To: 94426082@eeng.dcu.ie CC: C.Perkins@cs.ucl.ac.uk, yano@cs.berkeley.edu, rem-conf@es.net, singer@apple.com In-reply-to: <385A67D1.9FBCAE69@eeng.dcu.ie> (message from Nikki Cranley on Fri, 17 Dec 1999 16:41:53 +0000) Subject: Re: RTCP Retransmission Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > > --> Nikki Cranley writes: > > >The problem with TCP is that for real-time or near real time > transmission its > > >not feasible to use TCP as there may be lost packets/delays etc.and > > >retransmission of these will hinder the real-time ability - so > RTP/UDP/IP is > > >used. > > >But in the case of MPEG-4 - there are some important packets that probably > > >shouldn't be lost - imagine if the packet with all the decoding Hi, > >Colin Perkins wrote: > > I was envisaging that RTCP-Rx would be used for streams which need to be > > resilient to loss, but real-time and not 100% reliable. At 11:27 AM 12/17/99 -0800, Koichi Yano wrote: >Basically, I agree with you. At 10:28 AM 12/17/99 -0800, Dave Singer wrote: >My (personal) interest in using RTCP-based re-transmission is to cover the >case where you want the receiver clock to run, even if data never arrives, >but you want the greatly improved (but not perfect) reliability. You >can't get both guaranteed delivery and on-time behavior. I too agree with Colin and Dave's statements. Our original vision of RTCP-Rx was a protocol that was generic enough that it could be applied to any RTP stream to improve its reliability, without making any guarantees. We didn't want to have to write (or require others to write) a new specification or subtype for every payload out there. However, as Koichi points out, we could add hooks to better enable a higher degree of reliability, such as something like a "retransmit this now, i don't care if you've sent it already or you think it won't arrive in time to be useful" flag on the receiver requests. If one chose to one could then either write an MPEG-4-specific retransmission algorithm (as specified by the RXP subtype) or just write a receiver RTCP-Rx implementation that implements slightly different behavior if the payload is MPEG-4. The MPEG-4 algorithm could then require critical information to be re-transmitted an unlimited number of times (with proper RTT spacing, of course) until it got to the receiver; if it wants to delay playback until it gets the critical decoding info perhaps it could couple this with a RTSP signal to pause the stream at the sender so the receiver's playback buffer doesn't get overrun. In any case we wanted to avoid going into the specifics of implementing variable levels of reliability in the draft. However, I'm not against providing hooks to enable these features, provided they don't cause things to become overly complex. And I think a "definitely retransmit" flag like the one I've described above would have additional value, specifically in distinguishing duplicate retransmission requests. A receiver might repeat a retransmission request multiple times to protect against NACK loss, without wanting the sender to send more than one retransmission for the whole block of requests (this would be natural if it sent one NACK for each lost packet, since the BLP field allows up to 16 neighboring packets to be reported as lost). At other times, the receiver might also repeat a retransmission request because the first retransmission was lost (or at least it thinks it was) and it has enough time before playout for a second attempt. One way to distinguish between these two cases is to have the sender keep track of the time between a retransmission of a packet and a new request; if it's more than RTT+delta, it assumes the first retransmission failed and retransmits. But as an alternative the receiver could instead simply set a timer when it makes the very first request (possibly repeating it in subsequent NACKs); if the timer expires it sends a new request marked as "retransmit this now." The sender in this case would just only send additional retransmissions after the first one if the "retransmit now" flag was set (note that this means the re-requests can't themselves be repeated for NACK-loss resilience, but that might be overkill anyway). Still another idea would be to have a payload-specific algorithm (like for MPEG-4) in which the sender and receiver both know which pieces parts of the stream need full reliability; these would be ACKed instead of NACKed (by defining an ACK RXP subtype) and the sender would be responsible for reliability, a la TCP. Matt -- Dad always thought laughter was the best medicine, which I guess is why several of us died of tuberculosis. -- "Deep Thoughts" by Jack Handey From rem-conf Fri Dec 17 17:33:32 1999 From rem-conf-request@es.net Fri Dec 17 17:33:31 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11z8il-0001JV-00; Fri, 17 Dec 1999 17:31:43 -0800 Received: from mail-out2.apple.com [17.254.0.51] by mail1.es.net with esmtp (Exim 1.81 #2) id 11z8ik-0001JL-00; Fri, 17 Dec 1999 17:31:42 -0800 Received: from mailgate2.apple.com ([17.129.100.225]) by mail-out2.apple.com (8.9.3/8.9.3) with ESMTP id RAA27598 for ; Fri, 17 Dec 1999 17:31:40 -0800 (PST) Received: from scv3.apple.com (scv3.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Fri, 17 Dec 1999 17:31:31 -0800 Received: from [17.202.35.52] (singda.apple.com [17.202.35.52]) by scv3.apple.com (8.9.3/8.9.3) with ESMTP id RAA27265 for ; Fri, 17 Dec 1999 17:31:30 -0800 (PST) MIME-Version: 1.0 X-Sender: singer@mail.apple.com Message-Id: In-Reply-To: <199912180025.QAA16966@shattuck.CS.Berkeley.EDU> References: <199912180025.QAA16966@shattuck.CS.Berkeley.EDU> Date: Fri, 17 Dec 1999 17:30:11 -0800 To: rem-conf@es.net From: Dave Singer Subject: Re: RTCP Retransmission Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list The only reason I might want to define a 100%-reliable mode in RTP is to get around the starvation puzzle I mentioned in a previous message: I'm not sure if there is any way to tell if a TCP end-point is not giving you data because (a) it is waiting for a re-transmission which doesn't seem to be able to get through or (b) it can't get any response out of the source or (c) it is perfectly happy and the source isn't sending anything. The problem with the clock-stop algorithm is that it basically says "stop the clock at the time for which you didn't get a packet that was sent"; of course, the time to stop the clock is in the packet you didn't get. You can fix this, I guess, by stopping at the previous packet's time, or by indicating the next packet time in each packet (which also helps solve the starvation problem). David Singer Apple Computer/QuickTime From rem-conf Sun Dec 19 08:16:20 1999 From rem-conf-request@es.net Sun Dec 19 08:16:18 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 11zibL-0007c5-00; Sun, 19 Dec 1999 07:50:27 -0800 Received: from chila.pquim.unam.mx (chila) [132.248.56.14] by mail1.es.net with smtp (Exim 1.81 #2) id 11zibG-0007bR-00; Sun, 19 Dec 1999 07:50:22 -0800 Received: from houseplants-net by chila via SMTP (940816.SGI.8.6.9/940406.SGI) id IAA07726; Sun, 19 Dec 1999 08:08:45 -0800 Date: Sun, 19 Dec 1999 08:08:45 -0800 From: request6@joinme.com Message-Id: <199912191608.IAA07726@chila> Reply-To: request6@joinme.com To: request6@joinme.com Subject: Grow Lush, Healthy Houseplants Effortlessly! X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Do your potted plants suffer from overwatering or underwatering? Do you love having plants but don't have a lot of spare time? Let PLANTMATE automatically and precisely water and feed your potted plants for up to TWO WEEKS! Visit to learn about PLANTMATE's patented Micropore Technology watering system, guaranteed to help your indoor and outdoor potted plants grow up to 50% faster and stay healthy. ALL FOR LESS THAN $5.00 EACH! With our MONEY BACK GUARANTEE, you can't lose! You'll also receive a FREE BONUS GIFT with your order! Visit today to order your PLANTMATE: "The SIMPLE, EASY and INEXPENSIVE way to grow healthy, beautiful potted plants! CHRISTMAS DELIVERY: An excellent gift item for the Plant-Lover in the family! Order by 12/20/99 for prompt delivery, in time for Christmas. _______________________________________________________ REMOVAL - You may be removed automatically from future mailing >from the sender, at no cost to you, by simply clicking on the following link, to send a blank return email with the word "REMOVE" on the  subject line. Your request WILL be honored. _______________________________________________________ From rem-conf Mon Dec 20 10:59:34 1999 From rem-conf-request@es.net Mon Dec 20 10:59:33 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 1207nv-0000OT-00; Mon, 20 Dec 1999 10:45:07 -0800 Received: from blv-smtpout-01.boeing.com [192.161.36.5] by mail1.es.net with esmtp (Exim 1.81 #2) id 1207nu-0000OJ-00; Mon, 20 Dec 1999 10:45:06 -0800 Received: from blv-av-01.boeing.com ([192.54.3.60]) by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id KAA11385 for ; Mon, 20 Dec 1999 10:45:04 -0800 (PST) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.9.2/8.9.2) with ESMTP id KAA14913 for ; Mon, 20 Dec 1999 10:45:03 -0800 (PST) Received: from xch-pssbh-03.ca.boeing.com by blv-hub-01.boeing.com with ESMTP; Mon, 20 Dec 1999 10:44:46 -0800 Received: by xch-pssbh-03.ca.boeing.com with Internet Mail Service (5.5.2448.0) id ; Mon, 20 Dec 1999 10:44:44 -0800 Message-Id: From: "Fleischman, Eric W" To: Colin Perkins , "'94426082@eeng.dcu.ie'" <94426082@eeng.dcu.ie> Cc: Koichi Yano , rem-conf@es.net Subject: RE: RTCP Retransmission Date: Mon, 20 Dec 1999 10:44:41 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Early experiments using TCP for streaming at Microsoft several years back seemed to indicate that TCP was an acceptable streaming transport over the Internet if (and only if) the TCP's sliding window was kept very small (e.g., 2 or 3 or 4). > ---------- > From: Nikki Cranley[SMTP:94426082@eeng.dcu.ie] > Reply To: 94426082@eeng.dcu.ie > Sent: Friday, December 17, 1999 8:41 AM > To: Colin Perkins > Cc: Koichi Yano; rem-conf@es.net > Subject: Re: RTCP Retransmission > > Hi Colin - > > The problem with TCP is that for real-time or near real time transmission its > not feasible to use TCP as there may be lost packets/delays etc.and > retransmission of these will hinder the real-time ability - so RTP/UDP/IP is > used. > But in the case of MPEG-4 - there are some important packets that probably > shouldn't be lost - imagine if the packet with all the decoding information got > lost - well that would render everything else useless. I am looking at this only > from the perspective of unicast anyway - plus if we were to extend this to VR - > then RTCP-Rx could be used to dictate user interaction as there is no scope for > this in RTP/RTCP as far as I know. It would only be needed from client to > server. > I'm only new to this but thats what came to mind. I was thinking along the lines > of say incorporating media specific functionality into the RTCP-Rx. > > Rgds, > Nikki > > Colin Perkins wrote: > > > --> Nikki Cranley writes: > > >I am looking at RTCP-Rx also with respect to MPEG-4. In MPEG-4 the BIFS and > > >IOD are very important for establishing the transmission and replay of the > > >MPEG-4 file. I am thinking of using ways to implement the RTCP-Rx to ensure > > >that these files are received. > > >I think that there should be new payload types defined to reflect different > > >media types etc. The intended purpose of RTCP-Rx is selective > > >retransmisison and so there need to be selection criteria otherwise its > > >like TCP. > > > > For unicast, I wonder if TCP is not the correct means of transporting this > > information, and would be interested in arguments why not. For multicast, > > I remind you of RFC2357 and the work in RMT, which might be appropriate. > > > > Cheers, > > Colin > > From rem-conf Wed Dec 22 04:10:55 1999 From rem-conf-request@es.net Wed Dec 22 04:10:53 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 120kMR-0002XY-00; Wed, 22 Dec 1999 03:55:19 -0800 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 120kMP-0002XO-00; Wed, 22 Dec 1999 03:55:17 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05730; Wed, 22 Dec 1999 06:55:14 -0500 (EST) Message-Id: <199912221155.GAA05730@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rem-conf@es.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-tones-05.txt,.ps Date: Wed, 22 Dec 1999 06:55:14 -0500 Sender: nsyracus@cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals Author(s) : H. Schulzrinne, S. Petrack Filename : draft-ietf-avt-tones-05.txt,.ps Pages : 29 Date : 21-Dec-99 This memo describes how to carry dual-tone multifrequency (DTMF) signaling, other tone signals and telephony events in RTP packets. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-tones-05.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-avt-tones-05.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-avt-tones-05.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: <19991221121153.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-tones-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-tones-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991221121153.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Thu Dec 23 06:28:56 1999 From rem-conf-request@es.net Thu Dec 23 06:28:54 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 1218zn-0005fE-00; Thu, 23 Dec 1999 06:13:35 -0800 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 1218zl-0005ex-00; Thu, 23 Dec 1999 06:13:33 -0800 Received: from cperkins-d.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 23 Dec 1999 14:13:10 +0000 Received: from cperkins-d.cs.ucl.ac.uk (localhost [127.0.0.1]) by cperkins-d.cs.ucl.ac.uk (8.9.3/8.8.7) with ESMTP id OAA12208; Thu, 23 Dec 1999 14:11:56 GMT Message-Id: <199912231411.OAA12208@cperkins-d.cs.ucl.ac.uk> To: yano@cs.berkeley.edu cc: rem-conf@es.net Subject: Re: RTCP Retransmission In-Reply-To: Message from Koichi Yano of "Fri, 17 Dec 1999 11:27:34 PST." <385A8EA6.4F0B46D0@cs.berkeley.edu> Date: Thu, 23 Dec 1999 14:11:56 +0000 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> Koichi Yano writes: >But we can prepare the flag for strong request, which means "send >retransmission surely" wihtout thinking playout time or something. >I think it is a good idea. But not forgetting congestion control, right? Colin From rem-conf Thu Dec 23 06:28:56 1999 From rem-conf-request@es.net Thu Dec 23 06:28:54 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 1218zo-0005fR-00; Thu, 23 Dec 1999 06:13:36 -0800 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 1218zn-0005ex-00; Thu, 23 Dec 1999 06:13:35 -0800 Received: from cperkins-d.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 23 Dec 1999 14:13:27 +0000 Received: from cperkins-d.cs.ucl.ac.uk (localhost [127.0.0.1]) by cperkins-d.cs.ucl.ac.uk (8.9.3/8.8.7) with ESMTP id NAA12171; Thu, 23 Dec 1999 13:53:05 GMT Message-Id: <199912231353.NAA12171@cperkins-d.cs.ucl.ac.uk> To: alagu@entera.com (Alagu Periyannan) cc: rem-conf@es.net, yano@cs.berkeley.edu Subject: Re: RTCP Retransmission In-Reply-To: Message from alagu@entera.com (Alagu Periyannan) of "Fri, 17 Dec 1999 14:28:18 PST." <3.0.6.32.19991217142818.01530650@mailserver.entera.com> Date: Thu, 23 Dec 1999 13:53:05 +0000 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> Alagu Periyannan writes: >At 11:27 AM 12/17/99 -0800, Koichi Yano wrote: >>Colin Perkins wrote: >>> I was envisaging that RTCP-Rx would be used for streams which need to be >>> resilient to loss, but real-time and not 100% reliable. >> >>Basically, I agree with you. > >I think there is some merit in introducing the notion that certain RTP >packets are indispensible, i.e. 100% reliable. When such packets are lost >the receiver stops the clock and waits. > >This RTP feature should be used only in non-interactive (i.e. streaming) >applications. It should not be used for video key frames and other such >error resilient packets. > >We can keep saying use TCP for that, why bother enhancing RTP? If I use >TCP, I have to build a hybrid protocol that uses RTP/UDP and TCP to achieve >my goal. Why not make it simpler and offer the functionality in RTP? > >This issue has been the cause of the growth of proprietary streaming >protocols by a number of vendors. Most of them have invented their own >protocol and do not use RTP because of this missing functionality. Even >some vendors such as Apple who are using RTP are implementing "repeat" >packets to get around this which is very inefficient. > >Let's not preclude a "100% reliability" feature in RTP-Rx. I think "100% reliable" is a very loaded phrase. I accept that we may need to allow for streaming media, where some packets have to be delivered with very high probability, but with some time bound. This is where I believe RTCP-Rx fits in. However, I don't believe we want to use RTCP-Rx for streams where the entire stream is to be delivered 100% reliably. That's not streaming anymore, and is the case where TCP is used. I think this means I agree with you - but we should be careful when we say we want 100% reliable transmission using RTCP-Rx. Colin From rem-conf Thu Dec 23 06:28:56 1999 From rem-conf-request@es.net Thu Dec 23 06:28:54 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 1218zv-0005fT-00; Thu, 23 Dec 1999 06:13:43 -0800 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 1218zm-0005ex-00; Thu, 23 Dec 1999 06:13:34 -0800 Received: from cperkins-d.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 23 Dec 1999 14:13:22 +0000 Received: from cperkins-d.cs.ucl.ac.uk (localhost [127.0.0.1]) by cperkins-d.cs.ucl.ac.uk (8.9.3/8.8.7) with ESMTP id OAA12194; Thu, 23 Dec 1999 14:10:30 GMT Message-Id: <199912231410.OAA12194@cperkins-d.cs.ucl.ac.uk> To: 94426082@eeng.dcu.ie cc: Koichi Yano , rem-conf@es.net Subject: Re: RTCP Retransmission In-Reply-To: Message from Nikki Cranley <94426082@eeng.dcu.ie> of "Fri, 17 Dec 1999 16:41:53 GMT." <385A67D1.9FBCAE69@eeng.dcu.ie> Date: Thu, 23 Dec 1999 14:10:30 +0000 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> Nikki Cranley writes: >The problem with TCP is that for real-time or near real time transmission its >not feasible to use TCP as there may be lost packets/delays etc.and >retransmission of these will hinder the real-time ability - so RTP/UDP/IP is >used. Of course - I think we all agree that TCP is not appropriate for streaming. >But in the case of MPEG-4 - there are some important packets that probably >shouldn't be lost - imagine if the packet with all the decoding information got >lost - well that would render everything else useless. I am looking at this only >from the perspective of unicast anyway - plus if we were to extend this to VR - >then RTCP-Rx could be used to dictate user interaction as there is no scope for >this in RTP/RTCP as far as I know. It would only be needed from client to >server. This is where the problem gets interesting - how to transport a mixed media presentation? MPEG-4 is one example of this - but there are others - where some parts of the presentation must be delivered reliably (there might be some HTML and a Java applet, for example) and other parts can be streamed. My opinion is that this requires several protocols: it's not appropriate to try to extend RTP so it can be used for all case. There's a spectrum of reliability: reliable unreliable not-timely real-time +------------------------------------------------+ TCP ~~~~~~~~~~~~~~~~~~ RTP I envisage RTCP-Rx to be useful in the region labelled '~', for media which is mostly real-time, but with a need for enhanced reliability subject to some time bounds. I don't see it as appropriate for fully reliable streams. Sorry for keeping on about this - but I think it's important to scope the problem we're trying to solve with RTCP-Rx, before we get into the details of the protocol. Colin From rem-conf Thu Dec 23 10:49:03 1999 From rem-conf-request@es.net Thu Dec 23 10:49:02 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 121DEB-0001ok-00; Thu, 23 Dec 1999 10:44:43 -0800 Received: from ids2.idsonline.com [205.177.236.32] by mail1.es.net with esmtp (Exim 1.81 #2) id 121DE9-0001oa-00; Thu, 23 Dec 1999 10:44:41 -0800 Received: from 21rst-century.com (dc-hiper77.idsonline.com [205.177.251.77]) by ids2.idsonline.com (8.9.1/8.6.9) with ESMTP id OAA22002; Thu, 23 Dec 1999 14:54:46 -0500 Message-ID: <38626E07.5D84B2E@21rst-century.com> Date: Thu, 23 Dec 1999 13:46:58 -0500 From: Thomas Marshall Eubanks Reply-To: tme@21rst-century.com Organization: Multicast Technologies LLC X-Mailer: Mozilla 4.7 (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: Colin Perkins CC: 94426082@eeng.dcu.ie, Koichi Yano , rem-conf@es.net Subject: Re: RTCP Retransmission References: <199912231410.OAA12194@cperkins-d.cs.ucl.ac.uk> Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Colin Perkins wrote: > --> Nikki Cranley writes: > >The problem with TCP is that for real-time or near real time transmission its > >not feasible to use TCP as there may be lost packets/delays etc.and > >retransmission of these will hinder the real-time ability - so RTP/UDP/IP is > >used. > > Of course - I think we all agree that TCP is not appropriate for streaming. > > >But in the case of MPEG-4 - there are some important packets that probably > >shouldn't be lost - imagine if the packet with all the decoding information got > >lost - well that would render everything else useless. I am looking at this only > >from the perspective of unicast anyway - plus if we were to extend this to VR - > >then RTCP-Rx could be used to dictate user interaction as there is no scope for > >this in RTP/RTCP as far as I know. It would only be needed from client to > >server. > > This is where the problem gets interesting - how to transport a mixed media > presentation? MPEG-4 is one example of this - but there are others - where > some parts of the presentation must be delivered reliably (there might be > some HTML and a Java applet, for example) and other parts can be streamed. > My opinion is that this requires several protocols: it's not appropriate to > try to extend RTP so it can be used for all case. > Hello; Any real time system has to acknowledge the possibility of drop-outs and data loss. The goal has to be to set specs on what is acceptable and to engineer things to meet that. If you are saying that certain data cannot, no matter what, be lost, then you are not talking about real time transport, because at some times preventing that will require retransmission. This is really a function of reliable multicast transport (RMT - rmt@lbl.gov). Otherwise this is coming close to re-inventing a (not yet fully invented) wheel. If you are really operating in real-time, and you say that some bits are more important than others, then what you are really saying is that some bits need more redundancy than others. For example, if there was low rate text (say html, which does not gracefully suffer dropouts) combined with some high rate audio or video stream (which does), the low rate text could be sent in some highly redundant fashion, so that it could be reconstructed if pieces were lost. The question I would have is, should this be allowed for at the protocol level, or should this be viewed as an application level problem that the protocol should avoid ? I would argue that the most sensible way of doing this in a protocol would be to allow for sub-streams, which could have different levels of redundancy. Regards Marshall Eubanks T.M. Eubanks Multicast Technologies, LLC e-mail : tme@21rst-century.com > > There's a spectrum of reliability: > > reliable unreliable > not-timely real-time > +------------------------------------------------+ > TCP ~~~~~~~~~~~~~~~~~~ RTP > > I envisage RTCP-Rx to be useful in the region labelled '~', for media which > is mostly real-time, but with a need for enhanced reliability subject to > some time bounds. I don't see it as appropriate for fully reliable streams. > > Sorry for keeping on about this - but I think it's important to scope the > problem we're trying to solve with RTCP-Rx, before we get into the details > of the protocol. > > Colin From rem-conf Thu Dec 23 12:39:22 1999 From rem-conf-request@es.net Thu Dec 23 12:39:21 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 121Exw-0003UH-00; Thu, 23 Dec 1999 12:36:04 -0800 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 121Exu-0003U7-00; Thu, 23 Dec 1999 12:36:02 -0800 Received: from cperkins-d.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 23 Dec 1999 20:25:13 +0000 Received: from cperkins-d.cs.ucl.ac.uk (localhost [127.0.0.1]) by cperkins-d.cs.ucl.ac.uk (8.9.3/8.8.7) with ESMTP id UAA13881; Thu, 23 Dec 1999 20:21:14 GMT Message-Id: <199912232021.UAA13881@cperkins-d.cs.ucl.ac.uk> To: tme@21rst-century.com cc: 94426082@eeng.dcu.ie, Koichi Yano , rem-conf@es.net Subject: Re: RTCP Retransmission In-Reply-To: Message from Thomas Marshall Eubanks of "Thu, 23 Dec 1999 13:46:58 EST." <38626E07.5D84B2E@21rst-century.com> Date: Thu, 23 Dec 1999 20:21:14 +0000 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> Thomas Marshall Eubanks writes: > Any real time system has to acknowledge the possibility of >drop-outs and data loss. The goal has to be to set specs on what is >acceptable and to engineer things to meet that. If you are saying that >certain data cannot, no matter what, be lost, then you are not talking >about real time transport, because at some times preventing that will >require retransmission. This is really a function of reliable multicast >transport (RMT - rmt@lbl.gov). Otherwise this is coming close to >re-inventing a (not yet fully invented) wheel. > >If you are really operating in real-time, and you say that some bits are >more important than others, then what you are really saying is that some >bits need more redundancy than others. For example, if there was low rate >text (say html, which does not gracefully suffer dropouts) combined with >some high rate audio or video stream (which does), the low rate text could >be sent in some highly redundant fashion, so that it could be >reconstructed if pieces were lost. > >The question I would have is, should this be allowed for at the protocol >level, or should this be viewed as an application level problem that the >protocol should avoid ? I would argue that the most sensible way of doing >this in a protocol would be to allow for sub-streams, which could have >different levels of redundancy. We have traditionally sent each media type as a separate RTP stream, so it is simple to provide different levels of protection for each. This is one of the main reasons why multiplexing media streams together in RTP is not always a good idea. Colin From rem-conf Thu Dec 23 17:53:49 1999 From rem-conf-request@es.net Thu Dec 23 17:53:47 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 121Jqg-0006AO-00; Thu, 23 Dec 1999 17:48:54 -0800 Received: from havoc.entera.com [206.165.109.130] by mail1.es.net with esmtp (Exim 1.81 #2) id 121Jqe-00069j-00; Thu, 23 Dec 1999 17:48:52 -0800 Received: from tornado ([206.165.109.185]) by havoc.entera.com (Post.Office MTA v3.5.3 release 223 ID# 0-61971U200L100S0V35) with SMTP id com; Thu, 23 Dec 1999 18:02:59 -0800 Message-Id: <3.0.6.32.19991223175711.009ba1f0@mailserver.entera.com> X-Sender: alagu@mailserver.entera.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Thu, 23 Dec 1999 17:57:11 -0800 To: "M. Reha Civanlar" , From: alagu@entera.com (Alagu Periyannan) Subject: Re: RTCP Retransmission In-Reply-To: <016201bf48df$d7626540$4683cf87@research.att.com> References: <1307.945449525@cs.ucl.ac.uk> <3.0.6.32.19991217142818.01530650@mailserver.entera.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list At 05:41 PM 12/17/99 -0500, M. Reha Civanlar wrote: >From: Alagu Periyannan >> We can keep saying use TCP for that, why bother enhancing RTP? If I use >> TCP, I have to build a hybrid protocol that uses RTP/UDP and TCP to achieve >> my goal. Why not make it simpler and offer the functionality in RTP? > >The problem is that this won't make RTP simpler. Correct. But if we take the pain and introduce this functionality in RTP-Rx it will provide a standards-based way to deliver streams in which a few of the packets require 100% reliability. Currently the only way to do this is inventing my own protocol. > >> >> This issue has been the cause of the growth of proprietary streaming >> protocols by a number of vendors. Most of them have invented their own >> protocol and do not use RTP because of this missing functionality. Even >> some vendors such as Apple who are using RTP are implementing "repeat" >> packets to get around this which is very inefficient. > >How can they achieve 100% reliability with "repeat" packets anyway? > That's right you can't achieve 100% reliability with this method. I was trying to illustrate how vendors are trying solve the reliability issue within the current RTP framework. -- Alagu Periyannan alagu@entera.com Entera, Inc. +1 510 770 5225 From rem-conf Thu Dec 23 18:13:07 1999 From rem-conf-request@es.net Thu Dec 23 18:13:06 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 121KAd-0006u1-00; Thu, 23 Dec 1999 18:09:31 -0800 Received: from havoc.entera.com [206.165.109.130] by mail1.es.net with esmtp (Exim 1.81 #2) id 121KAc-0006ql-00; Thu, 23 Dec 1999 18:09:30 -0800 Received: from tornado ([206.165.109.185]) by havoc.entera.com (Post.Office MTA v3.5.3 release 223 ID# 0-61971U200L100S0V35) with SMTP id com; Thu, 23 Dec 1999 18:23:37 -0800 Message-Id: <3.0.6.32.19991223181749.00c81590@mailserver.entera.com> X-Sender: alagu@mailserver.entera.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Thu, 23 Dec 1999 18:17:49 -0800 To: Colin Perkins From: alagu@entera.com (Alagu Periyannan) Subject: Re: RTCP Retransmission Cc: rem-conf@es.net,yano@cs.berkeley.edu In-Reply-To: <199912231353.NAA12171@cperkins-d.cs.ucl.ac.uk> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list At 01:53 PM 12/23/99 +0000, Colin Perkins wrote: >--> Alagu Periyannan writes: >>Let's not preclude a "100% reliability" feature in RTP-Rx. > >I think "100% reliable" is a very loaded phrase. I accept that we may need >to allow for streaming media, where some packets have to be delivered with >very high probability, but with some time bound. This is where I believe >RTCP-Rx fits in. > >However, I don't believe we want to use RTCP-Rx for streams where the >entire stream is to be delivered 100% reliably. That's not streaming >anymore, and is the case where TCP is used. > >I think this means I agree with you - but we should be careful when we say >we want 100% reliable transmission using RTCP-Rx. > Actually the fundamental debate here is whether RTP is solely a "realtime" protocol or is it a "time-based streaming" protocol. A "realtime" protocol in my definition is a protocol that delivers timestamped packets in a time bounded fashion. Since it needs to deliver packets in a time bounded fashion it can theoretically never achieve 100% reliability. A "time-based streaming" protocol in my definition is a protocol that delivers timestamped packets period. It must cover the case of time bounded delivery with no reliability guarantees and the case of 100% reliability with no time bound. A time-based streaming protocol's functionality is a superset of a realtime protocol's functionality. I would like to see an IETF standard for a time-based streaming protocol. The question is do we build that off RTP (and its popularity and success) or do we just invent yet another RTXYZP protocol? -- Alagu Periyannan alagu@entera.com Entera, Inc. +1 510 770 5225 From rem-conf Sat Dec 25 05:50:10 1999 From rem-conf-request@es.net Sat Dec 25 05:50:08 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 121rPw-00041R-00; Sat, 25 Dec 1999 05:39:32 -0800 Received: from (mlm.jobsonline.com) [216.33.105.44] by mail1.es.net with esmtp (Exim 1.81 #2) id 121rPu-0003op-00; Sat, 25 Dec 1999 05:39:30 -0800 Received: from mlm (216.33.105.44:3845) by mlm.jobsonline.com (LSMTP for Windows NT v1.1b) with SMTP id <0.000DFFB2@mlm.jobsonline.com>; Fri, 24 Dec 1999 22:00:03 -0500 Date: Fri, 24 Dec 1999 21:36:54 -0500 From: WEBFORTYFIVE Subject: Want 30 minutes of long distance at no cost..... register with JobsOnline To: rem-conf@ES.NET Message-Id: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list JobsOnline is the Internet's leading employment and career resources site. Job Seekers can post resumes to a database that contains over 200,000 current job postings, review salary information and take a job aptitude test. JobsOnline provides these services absolutely FREE. Register now with JobsOnline and receive 30 FREE minutes of long distance!! Click here to register. www.jobsonline.com/sales/sales_web45.asp ************************* You are currently subscribed as: rem-conf@ES.NET To unsubscribe select the link below. mailto:WEBFORTYFIVE-signoff-request@mlm.jobsonline.com?subject=signoff From rem-conf Sat Dec 25 05:50:10 1999 From rem-conf-request@es.net Sat Dec 25 05:50:08 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 121rQ4-000444-00; Sat, 25 Dec 1999 05:39:40 -0800 Received: from (mlm.jobsonline.com) [216.33.105.44] by mail1.es.net with esmtp (Exim 1.81 #2) id 121rQ3-0003op-00; Sat, 25 Dec 1999 05:39:39 -0800 Received: from mlm (216.33.105.44:3845) by mlm.jobsonline.com (LSMTP for Windows NT v1.1b) with SMTP id <0.000DFFB2@mlm.jobsonline.com>; Fri, 24 Dec 1999 22:00:03 -0500 Date: Fri, 24 Dec 1999 21:36:54 -0500 From: WEBFORTYFIVE Subject: Want 30 minutes of long distance at no cost..... register with JobsOnline To: rem-conf@ES.NET Message-Id: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list JobsOnline is the Internet's leading employment and career resources site. Job Seekers can post resumes to a database that contains over 200,000 current job postings, review salary information and take a job aptitude test. JobsOnline provides these services absolutely FREE. Register now with JobsOnline and receive 30 FREE minutes of long distance!! Click here to register. www.jobsonline.com/sales/sales_web45.asp ************************* You are currently subscribed as: rem-conf@ES.NET To unsubscribe select the link below. mailto:WEBFORTYFIVE-signoff-request@mlm.jobsonline.com?subject=signoff From rem-conf Sat Dec 25 05:50:10 1999 From rem-conf-request@es.net Sat Dec 25 05:50:08 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 121rNu-0003rp-00; Sat, 25 Dec 1999 05:37:26 -0800 Received: from (mlm.jobsonline.com) [216.33.105.44] by mail1.es.net with esmtp (Exim 1.81 #2) id 121rNt-0003op-00; Sat, 25 Dec 1999 05:37:25 -0800 Received: from mlm (216.33.105.44:3845) by mlm.jobsonline.com (LSMTP for Windows NT v1.1b) with SMTP id <0.000DFFB2@mlm.jobsonline.com>; Fri, 24 Dec 1999 22:00:03 -0500 Date: Fri, 24 Dec 1999 21:36:54 -0500 From: WEBFORTYFIVE Subject: Want 30 minutes of long distance at no cost..... register with JobsOnline To: rem-conf@ES.NET Message-Id: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list JobsOnline is the Internet's leading employment and career resources site. Job Seekers can post resumes to a database that contains over 200,000 current job postings, review salary information and take a job aptitude test. JobsOnline provides these services absolutely FREE. Register now with JobsOnline and receive 30 FREE minutes of long distance!! Click here to register. www.jobsonline.com/sales/sales_web45.asp ************************* You are currently subscribed as: rem-conf@ES.NET To unsubscribe select the link below. mailto:WEBFORTYFIVE-signoff-request@mlm.jobsonline.com?subject=signoff From rem-conf Mon Dec 27 00:35:18 1999 From rem-conf-request@es.net Mon Dec 27 00:35:16 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 122VRJ-0006WJ-00; Mon, 27 Dec 1999 00:23:37 -0800 Received: from www.sicily.infcom.it [194.91.6.30] by mail1.es.net with smtp (Exim 1.81 #2) id 122VRH-0006W9-00; Mon, 27 Dec 1999 00:23:36 -0800 Received: from mail45.rastamandedsf.com by www.sicily.infcom.it via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id JAA11775; Mon, 27 Dec 1999 09:07:10 +0100 From: To: Date: Mon, 27 Dec 1999 00:14:19 Message-Id: <167.634888.742301@mail45.rastamandedsf.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Unidentified subject! X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list 877 205 9117 877 205 9117 BULK EMAIL EXPERTS PUTS MONEY INTO YOUR POCKET!! OUR COMPANY HAS OVER 4 YEARS PROVEN E MAIL BLASTING EXPERIENCE! WORK SMARTER BY HAVING QUALIFIED PEOPLE PHONE YOU, ALREADY PREPARED TO BUY. PUT YOUR COLD CALLING DAYS TO AN END. CHECK OUT OUR INTRODUCTORY OFFER FOR 150,000 E MAILS TODAY! FOR ONLY $295.00 WE WILL EMAIL YOUR AD TO LOTS OF DIFFERENT PLACES ON THE NET! FOR THOSE OF YOU WHO WOULD LIKE A BIGGER JOB DONE, WHY NOT E MAIL OUT YOUR AD TO OVER 550,000 DIFFERENT ADDRESSES FOR ONLY $525.00. GET YOUR PHONE RINGING TODAY! CALL THE BULK EMAIL EXPERTS! We accept PAYMENT BY Cheque by Fax. TO CONTACT US PLEASE CALL 877 205 9117. _________________________________________________________________ BULK EMAIL EXPERTS EDMONTON ALB From rem-conf Mon Dec 27 06:11:54 1999 From rem-conf-request@es.net Mon Dec 27 06:11:52 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 122ahG-0001jj-00; Mon, 27 Dec 1999 06:00:26 -0800 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 122ahF-0001jZ-00; Mon, 27 Dec 1999 06:00:25 -0800 Received: from cperkins-d.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 27 Dec 1999 13:59:27 +0000 Received: from cperkins-d.cs.ucl.ac.uk (localhost [127.0.0.1]) by cperkins-d.cs.ucl.ac.uk (8.9.3/8.8.7) with ESMTP id NAA05568; Mon, 27 Dec 1999 13:56:36 GMT Message-Id: <199912271356.NAA05568@cperkins-d.cs.ucl.ac.uk> To: alagu@entera.com (Alagu Periyannan) cc: rem-conf@es.net, yano@cs.berkeley.edu Subject: Re: RTCP Retransmission In-Reply-To: Message from alagu@entera.com (Alagu Periyannan) of "Thu, 23 Dec 1999 18:17:49 PST." <3.0.6.32.19991223181749.00c81590@mailserver.entera.com> Date: Mon, 27 Dec 1999 13:56:36 +0000 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> Alagu Periyannan writes: >Actually the fundamental debate here is whether RTP is solely a "realtime" >protocol or is it a "time-based streaming" protocol. > >A "realtime" protocol in my definition is a protocol that delivers >timestamped packets in a time bounded fashion. Since it needs to deliver >packets in a time bounded fashion it can theoretically never achieve 100% >reliability. > >A "time-based streaming" protocol in my definition is a protocol that >delivers timestamped packets period. It must cover the case of time bounded >delivery with no reliability guarantees and the case of 100% reliability >with no time bound. We have RTP over UDP for the first case, and the new profile draft specifies a TCP encapsulation for RTP which should deal with the case of "100% reliability with no time bound"? This leaves the case where we have a time bound, but desire enhanced reliability compared to UDP. We have some options here already (eg: redundant audio and parity FEC), and the RTCP retransmission draft offers another alternative. Colin From rem-conf Tue Dec 28 04:13:10 1999 From rem-conf-request@es.net Tue Dec 28 04:13:08 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 122vF9-0002wm-00; Tue, 28 Dec 1999 03:56:47 -0800 Received: from xxx.vorton.com (tune.eatsleepmusic.com) [209.217.80.22] by mail1.es.net with esmtp (Exim 1.81 #2) id 122vF8-0002wQ-00; Tue, 28 Dec 1999 03:56:46 -0800 Received: from LocalHost [209.164.106.1] by tune.eatsleepmusic.com (SMTPD32-5.05) id A88345F00142; Tue, 28 Dec 1999 07:09:39 -0500 MessageID: X-Accept-Language: en From: Subject: Re: Adv: Find things out about anybody - Right now To: Date: Tue, 28 Dec 1999 05:57:31 Content-Type: text/plain Message-Id: <199912280709663.SM00145@LocalHost> X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list FIND OUT ANYTHING ABOUT ANYBODY !!! SECRETLY SNOOP ON ANYONE USING THE INTERNET FIND OUT WHAT PEOPLE CAN FIND OUT ABOUT YOU! ENTER THE UNFORBIDDEN ZONE TODAY http://thezone.financialsources.net/ FIND LOST LOVES, FRIENDS, YOUR REAL PARENTS... WHO ARE YOU REALLY CHATTING WITH ONLINE?...CHECK THEM OUT! ON LINE SNOOP TEST - FIND OUT WHAT CAN BE KNOWN ABOUT YOUR COMPUTER. GET YOUR FILE FROM THE FBI FOR FREE! CHILD MOLESTORS ARE RELOCATED TO OUR TOWNS EVERY DAY. IS THERE ONE IN YOUR NEIGHBORHOOD? ****************** Remove Requests ******************* To be removed from all future mailings just reply to this email with "Remove" as the subject or visit our website and fill out the simple online form: http://thezone.financialsources.net/cleanlist.html you will be permanently removed from future mailings. ******************************************************** From rem-conf Tue Dec 28 11:32:50 1999 From rem-conf-request@es.net Tue Dec 28 11:32:49 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 1232D2-0006Ze-00; Tue, 28 Dec 1999 11:23:04 -0800 Received: from havoc.entera.com [206.165.109.130] by mail1.es.net with esmtp (Exim 1.81 #2) id 1232D1-0006ZG-00; Tue, 28 Dec 1999 11:23:03 -0800 Received: from tornado ([206.165.109.185]) by havoc.entera.com (Post.Office MTA v3.5.3 release 223 ID# 0-61971U200L100S0V35) with SMTP id com; Tue, 28 Dec 1999 11:37:18 -0800 Message-Id: <3.0.6.32.19991228113131.012c93a0@mailserver.entera.com> X-Sender: alagu@mailserver.entera.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Tue, 28 Dec 1999 11:31:31 -0800 To: Colin Perkins From: alagu@entera.com (Alagu Periyannan) Subject: Re: RTCP Retransmission Cc: rem-conf@es.net,yano@cs.berkeley.edu In-Reply-To: <199912271356.NAA05568@cperkins-d.cs.ucl.ac.uk> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list At 01:56 PM 12/27/99 +0000, Colin Perkins wrote: >--> Alagu Periyannan writes: >> >>A "time-based streaming" protocol in my definition is a protocol that >>delivers timestamped packets period. It must cover the case of time bounded >>delivery with no reliability guarantees and the case of 100% reliability >>with no time bound. > >We have RTP over UDP for the first case, and the new profile draft specifies a >TCP encapsulation for RTP which should deal with the case of "100% reliability >with no time bound"? > >This leaves the case where we have a time bound, but desire enhanced reliability >compared to UDP. We have some options here already (eg: redundant audio and >parity FEC), and the RTCP retransmission draft offers another alternative. > I was not aware of the RTP over TCP draft. (A pointer is appreciated.) Nevertheless, in many cases one may need to mix the various cases I mentioned in one RTP session. For example if we are streaming an animation over RTP, we may want to send the "actor" information in a reliable fashion and the motion vectors in a non-reliable fashion. This is not possible if the "100% reliability with no time bound" case is covered in a separate profile that does not include features of the standard A/V profile. -- Alagu Periyannan alagu@entera.com Entera, Inc. +1 510 770 5225 From rem-conf Wed Dec 29 16:45:47 1999 From rem-conf-request@es.net Wed Dec 29 16:45:45 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 123TVH-0002AO-00; Wed, 29 Dec 1999 16:31:43 -0800 Received: from gumby.cs.berkeley.edu [128.32.32.38] by mail1.es.net with esmtp (Exim 1.81 #2) id 123TVG-0002AE-00; Wed, 29 Dec 1999 16:31:42 -0800 Received: from BMRC.Berkeley.EDU (opus.CS.Berkeley.EDU [128.32.131.116]) by gumby.CS.Berkeley.EDU (8.8.4/8.6.9) with ESMTP id QAA16094; Wed, 29 Dec 1999 16:30:34 -0800 (PST) Message-ID: <386AA7AA.60C4BD21@BMRC.Berkeley.EDU> Date: Wed, 29 Dec 1999 16:30:34 -0800 From: "Lawrence A. Rowe" Reply-To: Rowe@bmrc.berkeley.edu Organization: U.C. Berkeley X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: rem-conf , bmrc-list@gumby.CS.Berkeley.EDU, 298-list@gumby.CS.Berkeley.EDU, mm-group@gumby.CS.Berkeley.EDU, eecs-instructors@eecs.Berkeley.EDU Subject: Distance Learning Experiment in Spring 2000 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi - UC Berkeley now has in place the technology required to allow us to accept remote students into select classes. We want to do an experiment during the spring 2000 semester in which we admit a limited number of remote students into our classes using concurrent enrollment through University Extension and Real Networks webcasting technology for distance/asynchronous learning. The purpose of this message is to solicit your participation in this experiment by enrolling in one of the following courses: EECS 152 "Computer Architecture and Engineering" (5 units) Instructor: Professor Robert Broderson Meeting time: M/W/F 9:00-10:00 AM EECS 240 "Analog Integrated Circuit Design and Analysis" (3 units) Instructor: Professor Bernhard E. Boser Meeting time: T/Th 11:00-12:30 PM EECS 152 is an undergraduate class and EECS 240 is a graduate class. Detailed descriptions of these courses are given below. Qualified students will be admitted through concurrent enrollment at UC Berkeley Extension. Lectures will be webcast live and stored for on-demand replay using Real Networks technology. See the following web pages for examples: http://media2.bmrc.berkeley.edu/bibs/schedule.cfm http://media2.bmrc.berkeley.edu/projects/alps/classes/cs298-5/19990825/ Although this technology operates at lower bit-rates, it is strongly suggested that you have access to a broadband Internet connection with speeds higher than 250 Kbs. As a student, you can view the live broadcast or watch lectures at a later time on-demand. You will be expected to do all the assignments and take the same examinations as students enrolled on campus. You will have a discussion section and TA assigned. Course assignments will be distributed and turned in through the web. You will have contact with the instructors and other students using email, a class newsgroup, and using traditional phone conferencing. We will also be experimenting with a remote question link during the lectures and a chat tool which will allow real time questions and answers. Special arrangements will be made for taking the examinations at or near your work location. A limited number of students will be admitted to these classes. Individuals interested in taking this courses and participating in this experiment should fill-in and submit the application form given below. Students selected for the experiment will enroll through concurrent enrollment, which will cost $4,000 for EECS 152 and $2,400 for EECS 240 (i.e., $800/unit), and will be given the appropriate access information required to take the course. If you have further questions please contact us. Larry Rowe --- Professor Lawrence A. Rowe Internet: Rowe@BMRC.Berkeley.EDU Computer Science Division - EECS Phone: 510-642-5117 University of California, Berkeley Fax: 510-642-5615 Berkeley, CA 94720-1776 URL: http://bmrc.berkeley.edu/~larry == Course Descriptions ======================= EECS 152 "Computer Architecture and Engineering" (5 Units) Instructor: Professor Robert Broderson Course Format: Three hours of lecture and two hours of discussion per week and one large design project. Prerequisites: EECS 150 or equivalent. Description: Instruction set design, Register Transfer. Computer design project requiring about 100 hours. Data-path design. Controller design. Memory system. Addressing. Microprogramming. Computer arithmetic. Survey of real computers and microprocessors. ---------------------------------------------- EECS 240 "Analog Integrated Circuit Design and Analysis" (3 units) Instructor: Professor Bernhard E. Boser Course Format: Three hours of lecture per week. Prerequisites: EECS 140 or equivalent. Description: Analysis and optimized design of monolithic operational amplifiers and wide-band amplifiers; methods of achieving wide-band amplification, gain-bandwidth considerations; analysis of noise in integrated circuits and low noise design. Precision passive elements, analog switches, amplifiers and comparators, voltage reference in NMOS and CMOS circuits. Serial successive-approximation, and parallel analog-to-digital converters. Switched-capacitor and CCD filters. Applications to codecs and modems. ============================================== == Application Form ========================== Name: Email Address: Postal Address: Educational Background: Course Enrolling In: EECS 152 or EECS 240 Desktop Computer and OS: Internet Connection/Speed: Why do you want to take this course? Please include a copy of your resume. Send form to Rowe@CS.Berkeley.EDU =============================================== From rem-conf Thu Dec 30 16:57:05 1999 From rem-conf-request@es.net Thu Dec 30 16:57:03 1999 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 123q2v-0003gv-00; Thu, 30 Dec 1999 16:35:57 -0800 Received: from lumumba.luc.ac.be [193.190.9.252] (qmailr) by mail1.es.net with smtp (Exim 1.81 #2) id 123q2t-0003gl-00; Thu, 30 Dec 1999 16:35:55 -0800 Received: (qmail 28589 invoked from network); 31 Dec 1999 01:39:10 -0000 Received: from lumumba.luc.ac.be (jori@193.190.9.252) by lumumba.luc.ac.be with SMTP; 31 Dec 1999 01:39:10 -0000 Date: Fri, 31 Dec 1999 02:39:09 +0100 (CET) From: Jori To: rem-conf@es.net Subject: RTP library Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi there ! Just to say that I've written a RTP library. If anyone is interested, you can download it from http://lumumba.luc.ac.be/jori/rtp/rtp.html The library is written in C++ and should work on pretty much any unix-like platform and a ms-windows platform. Bye, Jori