Chuck Harrison | 3 Apr 07:41 2002
Picon

time-lined static media

Hi,

Has anyone been thinking about the draft
http://search.ietf.org/internet-drafts/draft-westerlund-avt-rtp-static-media-01.txt
?

There was quite a discussion last July, then all quiet. This payload
format seems to have a lot of potential.

Cheers,
  Chuck Harrison
  Far Field Associates, LLC

_______________________________________________
Audio/Video Transport Working Group
avt <at> ietf.org
https://www1.ietf.org/mailman/listinfo/avt

Shu Wang | 3 Apr 03:29 2002
Picon

Re: RTP mixers & translators

Dear Roni,

Thank you very much for your answer.
The functionality I would like to use is (from RFC1889 section 2.3)

mixer:

...Instead of forcing
   everyone to use a lower-bandwidth, reduced-quality audio encoding, an
   RTP-level relay called a mixer may be placed near the low-bandwidth
   area....

translator:
                                                                   .....Two
translators
   are installed, one on either side of the firewall, with the outside
   one funneling all multicast packets received through a secure
   connection to the translator inside the firewall.

I have secure, heterogeneous networks (very high and very low bandwidth).
I thought mixer can help to reduce the data rate (seamlessly?) at the boundary.

And translator can be used to across the secure LANs. Is it true?
Or, the H.323 signaling handles this situation? So we don't need mixers and
translators at RTP-level in the real world. Does SIP have the same functions?

Any suggestion is greatly appreciated!!!

Regards,
Oliver
(Continue reading)

Nikki | 3 Apr 12:50 2002
Picon
Picon

IP Network Simulator

Hi all,
I was wondering if anybody would know of a good IP network simulator for Windows OS? Not even a overly compilcated one as in topological designs but rather end-to-end network simulation?
 
Thanks regards,
Nikki
 
philippe.gentric | 3 Apr 15:10 2002
Picon

UXP RTP payload format


All,

I have been reading draft-ietf-avt-uxp-02.txt and have the following comments:


0. About the document structure, I think that the document could benefit from moving the introduction (section 3)
before the very useful but also quite long "conventions used in this document" part :-)

1. Since one of the key features of the payload format is that it distributes errors
using *interleaving* I think that this key word should be found in the abstract
and the introduction.

2. There is a substancial amont of confusion introduced by using several words
to say same/different things, for example in section 2.7 we find "block" to mean "frame"
then "bitstream of certain length" then "elements"  which apparently are pieces thereof (?)
Then in the next paragraph (2.8) "block" is a RS block etc..

I would recommend the usage of "encoded frame" and "encoded frame fragment"

3. section 2.15 defines an "info stream" (and then the term "info byte" is used a lot
in the whole document) which looks to me like a rather extreme short cut
especially if it is meant to lead the reader to assume that this level of abstraction
can serve as some proof that this specification can work with *any* media stream.

Specifically recent audio codecs dont have a "bitstreams" structure (or byte-stream either)
in the traditional sense that if encoded frame boundaries are not transported
explicitely the decoder cannot find them.

Then there is this extremely mysterious parenthesis:
"(e.g.  as specified in the respective RTP profile
for the media codec in use)" which confuses me rather badly.

Is that the "normal" RTP payload format for the media ?

if yes, say so, then explain why and how it would help.

if no, (which I suspect)  the way a receiver can reconstruct the media stream structure i.e.
at least encoded frames boundaries and time line after de-packetization must be specified.

As mentioned (a bit late) in section 9 UXP creates a completely "new packetization"
(by contrast with ULP) of the original media stream, therefore it would be useful to
at least add a few paragraphs about how one is supposed to "replace" the
functionality that RTP packets play when transporting the *same media* in
"normal" RTP i.e. transport of encoded frame boundaries and associated media time....

For example section 6.12 says in another mysterious parenthesis
"(the source decoder may be informed about the missing info stream,
if required)". Informed of what ? And how ?

If -as I suspect- this scheme works only for self-timed self-framed media
streams, this should be clearly indicated preferably much early than in
the discussion comparing it with ULP (section 9), i.e. in the abstract
and introduction (!)

3bis. The document would greatly benefit from a few numerical examples based
on realistic media streams. Examples covering the usage of existing "real life" codecs
would be very useful for both audio and video (create an Appendix ?)

4.The document does not mention anything about the complexity of RS
computations (especially by comparison with XOR ?) and that could be
badly misleading for naive potential implementers (Is not  it so that
the RS processing complexity is several orders of magnitude
higher than XOR ?)

4bis.The document does not clearly explain if RS code computation is
required when no losses occur (I hope not).

Could there be a security consequences that an attacker could, by creating
excess traffic, trigger losses, themselves triggering more RS computations,
which in turn would create significant additional ressource usage in decoders ...
a kind of Degradation Of Ressource Attack :-( ??

****************
More details:

Replace all occurences of "byte" with "octet"

Some acronyms/names  are not fully explained/explicit or localized:
* there is a "forward" declaration of "TB" (point 9)
* CA_i is not expanded (IMHO variable names should either
have a meaning or be based on a well known convention right ?)
* AV is not expanded (while SI is )
 
Section 5 mention scalability in MPEG-4: Can MPEG-4 Video Packet and data Partition be used as example ?

In the references there is a MPEG working document (M4204) which status should be checked (maybe hard to *legally* get it no ?)

***************


Regards,

Philippe Gentric
Software Architect
Philips MP4Net
philippe.gentric <at> philips.com
http://www.mpeg-4.philips.com
Even, Roni | 4 Apr 09:45 2002
Picon

RE: RTP mixers & translators

Hi,
I re-read the definition in draft-ietf-avt-rtp-new-11.txt which is the
latest draft, since AVT is working on RTP layer which can serve different
applications like conversional and streaming then they define an entity that
works on the RTP layer regardless of the application. I am not sure that
there are real products that give this functionality as standalone product
since there is no definition how the mixer or translator interact in a
specific application. for conversional application based on SIP or H.323, I
am not aware of application aware firewalls that are handling the speed or
algorithm of the audio or video streams. Typically gateways will do it as
part of their functionality (for example a voice gateway from SIP to PSTN).
There are some gateways that can do it from IP to IP but again they do it in
the application context.

About your specific question. If you would like the mixer to change the rate
of audio between the external and internal network (seamlessly) I assume
that you want a box that will do it, how do you expect to tell the box what
rate and what audio algorithm to use on each side.

Roni Even

> -----Original Message-----
> From: Shu Wang [mailto:Shu.Wang <at> trw.com]
> Sent: Wednesday, April 03, 2002 4:30 AM
> To: Even, Roni
> Cc: avt <at> ietf.org
> Subject: Re: [AVT] RTP mixers & translators
> 
> 
> Dear Roni,
> 
> Thank you very much for your answer.
> The functionality I would like to use is (from RFC1889 section 2.3)
> 
> mixer:
> 
> ...Instead of forcing
>    everyone to use a lower-bandwidth, reduced-quality audio 
> encoding, an
>    RTP-level relay called a mixer may be placed near the low-bandwidth
>    area....
> 
> translator:
>                                                               
>      .....Two
> translators
>    are installed, one on either side of the firewall, with the outside
>    one funneling all multicast packets received through a secure
>    connection to the translator inside the firewall.
> 
> 
> I have secure, heterogeneous networks (very high and very low 
> bandwidth).
> I thought mixer can help to reduce the data rate 
> (seamlessly?) at the boundary.
> 
> And translator can be used to across the secure LANs. Is it true?
> Or, the H.323 signaling handles this situation? So we don't 
> need mixers and
> translators at RTP-level in the real world. Does SIP have the 
> same functions?
> 
> Any suggestion is greatly appreciated!!!
> 
> Regards,
> Oliver
> 
> "Even, Roni" wrote:
> 
> > Hi,
> >
> > Mixers and translator define functionality for mixing and 
> translating RTP
> > streams. For conversational services they are part of the 
> conference bridge
> > that handles also the call setup and call control 
> signalling. In H.323 it
> > states that an MCU (Multipoint control unit) is not a mixer 
> as defined in
> > RTP, it uses the H.323 signalling.
> >
> > Regards
> > Roni Even
> > Polycom
> > > -----Original Message-----
> > > From: Shu Wang [mailto:Shu.Wang <at> trw.com]
> > > Sent: Saturday, March 30, 2002 4:09 AM
> > > To: avt <at> ietf.org
> > > Subject: [AVT] RTP mixers & translators
> > >
> > >
> > > Hi,
> > >
> > > Based on RFC1889, I am really interested in RTP mixers and
> > > translators.
> > > The functionality is needed in my network design/implementation.
> > > However,
> > > I could not find if there is any vendor who really put them into
> > > products, or
> > > they are usually come with RTP.
> > >
> > > Could anyone please tell me if there is any vendor 
> implementing mixers
> > > and
> > > translators?
> > >
> > > Thank you.
> > >
> > > Regards,
> > > Oliver
> > >
> 

_______________________________________________
Audio/Video Transport Working Group
avt <at> ietf.org
https://www1.ietf.org/mailman/listinfo/avt

Stephen Casner | 4 Apr 10:06 2002

RE: RTP mixers & translators

Roni,

> Mixers and translator define functionality for mixing and translating RTP
> streams. For conversational services they are part of the conference bridge
> that handles also the call setup and call control signalling. In H.323 it
> states that an MCU (Multipoint control unit) is not a mixer as defined in
> RTP, it uses the H.323 signalling.

That statement in H.323 has always surprised me, because the MCU
really _is_ a particular case of a mixer.  The RTP specification tries
to convey the idea that the description of mixers and translators
covers a diverse space of devices.  The fact that an MCU also uses
H.323 signaling does not mean that the part handling RTP is not a
mixer.

> About your specific question. If you would like the mixer to change the rate
> of audio between the external and internal network (seamlessly) I assume
> that you want a box that will do it, how do you expect to tell the box what
> rate and what audio algorithm to use on each side.

The box has to be told in some way.  The initial RTP mixer devices
used experimentally on the MBone may have been manually configured.
Other devices may use signaling of some form.

							-- Steve

_______________________________________________
Audio/Video Transport Working Group
avt <at> ietf.org
https://www1.ietf.org/mailman/listinfo/avt

Mats Näslund | 4 Apr 10:32 2002
Picon
Picon

ROC update


Hi all,

As indicated by Mark, we are preparing the final version of SRTP. 
Before doing so, we the authors, would like to prepare you for one 
or two details that will not totally comply with comments received
during WG last call, provide rationale for why, and hope that you
will see our point. We are of course welcoming feedback.

The issue we would like to take up here is the update of the
roll-over counter, ROC, i.e. SRTP's own, not the corresponding
quantity maintained by RTP (the latter will here be denoted RTP-ROC).

We had a comment during WG last call that we should mandate a robust 
update strategy, and an example was given to us with a reference to 
Appendix A of the RTP spec.

Right now, we have a clear definition of what the ROC *is*, and give 
an example on how to maintain and update it on the receiving side. 
Sender behavior is specified exactly. Note that all potential 
robustness problems occurs when SRTP data integrity is not enabled, 
otherwise the suggestion given is robust, so we will in the sequel
assume that authentication is "off". Also, note that the (potential)
problems are on the receiver side only. 

We will not change the text concerning ROC and ROC update for the
following reasons:

* We do not think it is even possible to give a method that is robust
  when data integrity is not present. Besides random errors introduced
  by the channel, there could be adversarial behavior somewhere along
  the path.

* In particular, the RTP-ROC as in Appendix A of the RTP spec does not
seem 
  to withstand such adversarial attacks, it can loose synch. (Though it
  is probably quite good at handling randomly occurring re-orders etc.)

* Mandating a single update strategy in some sense makes it easier 
  for an attacker to perform DoS: he knows how the receiver maintains
  his ROC and can act "counter-accordingly".

* There are no interop problems with allowing receivers to do what they 
  see fit, since the sender behavior is still clearly specified.

* Leaving it open makes it flexible, even application feedback could
  be allowed to detect out-of-synch problems.

An alternative might be to give a small number of different strategies,
but it will complicate the spec and someone will be sure to complain
that
we missed one approach. 

Best,

/Mats

_______________________________________________
Audio/Video Transport Working Group
avt <at> ietf.org
https://www1.ietf.org/mailman/listinfo/avt

Even, Roni | 4 Apr 10:24 2002
Picon

RE: RTP mixers & translators

Steve
The text in 2.3 looks to me more like it is related to multicast conferences
and not to H.323 MCU  The example is not about the mixing but about what I
may call transcoding

2.3 Mixers and Translators

   So far, we have assumed that all sites want to receive media data in
   the same format. However, this may not always be appropriate.
   Consider the case where participants in one area are connected
   through a low-speed link to the majority of the conference
   participants who enjoy high-speed network access. Instead of forcing
   everyone to use a lower-bandwidth, reduced-quality audio encoding, an
   RTP-level relay called a mixer may be placed near the low-bandwidth
   area. This mixer resynchronizes incoming audio packets to reconstruct
   the constant 20 ms spacing generated by the sender, mixes these
   reconstructed audio streams into a single stream, translates the
   audio encoding to a lower-bandwidth one and forwards the lower-
   bandwidth packet stream across the low-speed link. These packets
   might be unicast to a single recipient or multicast on a different
   address to multiple recipients. The RTP header includes a means for
   mixers to identify the sources that contributed to a mixed packet so
   that correct talker indication can be provided at the receivers.

As for H.323 in H.225 the text is (annex A and B are the RTP/RTCP and the
profile RFCs that are part of H.225 due to problem with referencing them at
the time)

RTP translators and mixers are not elements of the H.323 system, and any
information about them in Annexes A and B shall be regarded as informative.
Note that both gateways and MCUs have some aspects of both mixers and
translators, and the information in Annexes A and B may be helpful in the
implementation of gateways and MCUs. However, MCUs are not mixers, and
mixers are not MCUs. Note that gateways, for example, on a packet-based
network-to-packet-based network call via the gateway may act as translators.

As for the second issue I was trying to point out that you can not expect to
buy a mixer or translator and control it in a standard mode

Roni

> -----Original Message-----
> From: Stephen Casner [mailto:casner <at> packetdesign.com]
> Sent: Thursday, April 04, 2002 11:06 AM
> To: Even, Roni
> Cc: AVT WG
> Subject: RE: [AVT] RTP mixers & translators
> 
> 
> Roni,
> 
> > Mixers and translator define functionality for mixing and 
> translating RTP
> > streams. For conversational services they are part of the 
> conference bridge
> > that handles also the call setup and call control 
> signalling. In H.323 it
> > states that an MCU (Multipoint control unit) is not a mixer 
> as defined in
> > RTP, it uses the H.323 signalling.
> 
> That statement in H.323 has always surprised me, because the MCU
> really _is_ a particular case of a mixer.  The RTP specification tries
> to convey the idea that the description of mixers and translators
> covers a diverse space of devices.  The fact that an MCU also uses
> H.323 signaling does not mean that the part handling RTP is not a
> mixer.
> 
> > About your specific question. If you would like the mixer 
> to change the rate
> > of audio between the external and internal network 
> (seamlessly) I assume
> > that you want a box that will do it, how do you expect to 
> tell the box what
> > rate and what audio algorithm to use on each side.
> 
> The box has to be told in some way.  The initial RTP mixer devices
> used experimentally on the MBone may have been manually configured.
> Other devices may use signaling of some form.
> 
> 							-- Steve
> 

_______________________________________________
Audio/Video Transport Working Group
avt <at> ietf.org
https://www1.ietf.org/mailman/listinfo/avt

Internet-Drafts | 4 Apr 14:01 2002
Picon

I-D ACTION:draft-ietf-avt-rtp-cn-06.txt

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 Comfort Noise
	Author(s)	: R. Zopf
	Filename	: draft-ietf-avt-rtp-cn-06.txt
	Pages		: 8
	Date		: 03-Apr-02
	
This document describes an RTP [2] payload format for transporting
comfort noise (CN).  The CN payload type is primarily for use with
audio codecs that do not support comfort noise as part of the codec
itself such as ITU-T Recommendations G.711 [3], G.726 [4], G.727
[5], G.728 [6], and G.722 [7].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-cn-06.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-rtp-cn-06.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 <at> ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-avt-rtp-cn-06.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.
Attachment: message/external-body, 133 bytes
Attachment (draft-ietf-avt-rtp-cn-06.txt): message/external-body, 67 bytes
Zvi Lifshitz | 4 Apr 15:50 2002

RE: Re: MPEG-4 BIFS in the packet loss environment

Young,

 

Indeed the current payload format supports the scene carousel, because it is a full mapping of the SL.

 

Regards,

z

 

-----Original Message-----
From: young <at> netntv.co.kr [mailto:young <at> netntv.co.kr]
Sent: Tuesday, April 02, 2002 8:34 AM
To: Zvi Lifshitz; philippe.gentric <at> philips.com
Cc: 4on2andIP-sys <at> advent.ee.columbia.edu; avt <at> ietf.org; avt-admin <at> ietf.org; 'Colin Perkins'; 'Vishy Swaminathan'
Subject: Re: [AVT] Re: MPEG-4 BIFS in the packet loss environment

 

Hi Zvi,

 

What you are saying is there are some potential problems if we loose BIFS packets, but it can be handled by using "scene carousel" mechanism. Right? Then, what is the implications to the payload format? I don't see any changes to current payload format specification? Maybe we can add another CLARIFICATION about using scene carousel to overcome expected problems.

 

Sincerely,

Young.

 

 

----- Original Message -----

To: philippe.gentric <at> philips.com

Cc: 4on2andIP-sys <at> advent.ee.columbia.edu ; avt <at> ietf.org ; avt-admin <at> ietf.org ; 'Colin Perkins' ; 'Vishy Swaminathan' ; 'Lim, Young-Kwon'

Sent: Sunday, March 31, 2002 7:07 AM

Subject: RE: [AVT] Re: MPEG-4 BIFS in the packet loss environment

 

Philippe,

 

I basically agree with your description of the issue. I just want to add few words for further clarification.

 

Essentially BIFS (and OD) stream _are_ like video in the sense that they are made up of Intra (or Key) frames (scenes) and delta frames (BIFS updates). They are, however, two differences:

 

1.    Users may interact with BIFS scenes locally. This means that reverting to an I frame after losing delta frames might incur the penalty of the user losing his/her local manipulation of the scene. For instance, you have a movie with translation sub-titles at the bottom, and you drag the titles to the top. If you loose one title and wait to refresh your screen at the next “replace scene” command, the titles will go down again.

 

2.    In video the deltas are usually accumulative. I.e. each delta refers to the immediately preceding frame. This is not always the case with BIFS. Using again the sub-titles example, the position, size and font of the titles will be set at the initial scene description, while the content of each title is a BIFS-update frame. Loosing one update has no effect on subsequent updates.

 

The “scene carousel” mechanism introduced in MPEG-4 Systems addresses those points, by featuring the following:

 

1.    The I-frames are interspersed in the stream as _optional alternatives_ to the sequence of updates. They come to rescue only when loss of indispensable data occurs.

 

2.    There is a mechanism to differentiate between “indispensable” update commands and commands whose loss may be ignored without severely affecting the presentation.

 

Regards,

 

z

soon the whole world will STREAM

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

Zvi Lifshitz                      Phone +972-2-679-4788

zvil <at> optibase.com         Fax +972-9-958-6099

Optibase Ltd.                 GSM: +972-54-461-787  (+972-LI-IM1-RTP)

http://www.optibase.com   US voice mail/fax  +1(206)888-4149

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

Come see us at:

NAB 2002 (National Association of Broadcasters), The Sands Expo Center, Las Vegas, Nevada USA,  April 8 - 11, 2002

 

 

-----Original Message-----
From: philippe.gentric <at> philips.com [mailto:philippe.gentric <at> philips.com]
Sent: Thursday, March 28, 2002 7:13 PM
To: Zvi Lifshitz
Cc: 4on2andIP-sys <at> advent.ee.columbia.edu; avt <at> ietf.org; avt-admin <at> ietf.org; 'Colin Perkins'; 'Vishy Swaminathan'; 'Lim, Young-Kwon'
Subject: RE: [AVT] Re: MPEG-4 BIFS in the packet loss environment

 


Zvi,

I understand the need for non-MPEG experts to get some additional explanation:

MPEG invested a lot of work in the past 10 years
to make sure that scene description could be "broadcasted",
including resistance to network losses.

The results of this is a set of techniques that make BIFS unique
in the scene description landscape.

specifically BIFS has been described as a binary (compressed) version
(actually superset) of VRML for 3D scenes. And it is.

BIFS has also been described as a binary (compressed) version of W3C SMIL
for 2D scenes. And it is.

But BIFS is more and the key competitive advantage of BIFS over
either VRML or SMIL *IS* this ability to be "broadcasted"
i.e. sent over a possibly uni-directional and probably lossy links....

And the way this was implemented is similar to I frames in video.

However some people out there (hello stephan)
have been expressing concerns about that statement.

My understanding for the basis of this concern is that they would say:
"scene description is not like video, either you get it or you dont"

Well the truth is that the "threshold" is not binary ,as I shall demonstrate now:

Take for example a scene describing a room with several objects in it.

If you loose the big arm chair in the corner
(but get it ok a few seconds latter i.e. at the next "I" frame)
the scene is still "usable", it is *inexact*, but usable.

If you loose the texture on the wall the wall is still a wall
(and a texture-less wall is so cheap that you can triplicate or heavily FEC the packet transporting it).

Of course if you loose the "I buy it" button of your E commerce interactive application
you would be in trouble with the guy paying for it.

I believe that judging if you would be in more trouble than if you loose
the split second part of the movie where the hero gets shot is not for us to decide.

And to conclude I think the point is to document the fact that :

- yes loosing piece of scene description CAN be bad
- and therefore that users of this payload format should take
the required steps to make sure:
* either that it does not happen
* or that their application is carefully designed to handle those losses


regards,


Philippe Gentric
Software Architect
Philips MP4Net
philippe.gentric <at> philips.com
http://www.mpeg-4.philips.com


 

"Zvi Lifshitz" <zvil <at> csi.com>

03/26/2002 21:30

       
        To:        Philippe Gentric/LIM/CE/PHILIPS <at> EMEA1
"'Vishy Swaminathan'" <viswanathan.swaminathan <at> sun.com>

        cc:        <4on2andIP-sys <at> advent.ee.columbia.edu>
<avt <at> ietf.org>
<avt-admin <at> ietf.org>
"'Colin Perkins'" <csp <at> isi.edu>
"'Lim, Young-Kwon'" <young <at> netntv.co.kr>

        Subject:        RE: [AVT] Re: MPEG-4 BIFS in the packet loss environment

        Classification:        




[philippe.gentric <at> philips.com:]

> * BIF scene and MPEG-J are more sensitive i.e. the usual
>
techniques (including RTP/RTSP/TCP, but this is
>
acutzally out of scope for a RTP payload format, right ?)
>
should be used to make sure the content actually arrived.

[Reply:]

 

BIFS scenes are like video I-frames.

 

z

soon the whole world will STREAM

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

Zvi Lifshitz                      Phone +972-2-679-4788

zvil <at> optibase.com         Fax +972-9-958-6099

Optibase Ltd.                 GSM: +972-54-461-787  (+972-LI-IM1-RTP)

http://www.optibase.com   US voice mail/fax  +1(206)888-4149

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

Come see us at:

NAB 2002 (National Association of Broadcasters), The Sands Expo Center, Las Vegas, Nevada USA,  April 8 - 11, 2002

 


Gmane