Re: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions (RAMS)" available
"Roni Even" <ron.even.tlv@gmail.com> Sun, 26 April 2009 08:14 UTC
Return-Path: <ron.even.tlv@gmail.com>
X-Original-To: avt@core3.amsl.com
Delivered-To: avt@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A72F3A68E0 for <avt@core3.amsl.com>; Sun, 26 Apr 2009 01:14:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.085
X-Spam-Level:
X-Spam-Status: No, score=-1.085 tagged_above=-999 required=5 tests=[AWL=-0.886, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_18=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c1oaMq5PLWEe for <avt@core3.amsl.com>; Sun, 26 Apr 2009 01:14:25 -0700 (PDT)
Received: from mail-fx0-f158.google.com (mail-fx0-f158.google.com [209.85.220.158]) by core3.amsl.com (Postfix) with ESMTP id 1A59A3A67B7 for <avt@ietf.org>; Sun, 26 Apr 2009 01:14:24 -0700 (PDT)
Received: by fxm2 with SMTP id 2so1765968fxm.37 for <avt@ietf.org>; Sun, 26 Apr 2009 01:15:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=fhgeOqDajhdMbwDsl7UA1bdRq9ZWqL3T+RUnlmhxHsY=; b=sS0AuhR03PP/mekft4a20mJwY5J61kwnGq8MOiiEGZLbX2u3285rVyJP7LopCXo/Ov kQIXJv4SBBdos19QnVYugNboKcrxpbeXuOxfQUEP8xBszFNrzVOoH9X02z1M5fgv/ck4 q3M/Llt2jg0x4B4K+CzDb8t4LzZV/v4GV6Jns=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; b=u260jOLDktTMs6t8ZuWPSAbn61Em7vMTWZRF9cCdZt0eu6vvD3lMzrg2MjCsOL5t63 tHJwZMZQZnrknWEddb6aO0r/rxiLPOBgLcTAlx2dS+PaWfL0GOxraPsbORDQI62AUULu XldZMStWqHM7zIh5/A2cjx3Y4rToVNelqwTrU=
Received: by 10.103.160.3 with SMTP id m3mr2450109muo.25.1240733743994; Sun, 26 Apr 2009 01:15:43 -0700 (PDT)
Received: from windows8d787f9 (bzq-79-179-121-32.red.bezeqint.net [79.179.121.32]) by mx.google.com with ESMTPS id n7sm8790622mue.42.2009.04.26.01.15.41 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 26 Apr 2009 01:15:43 -0700 (PDT)
From: Roni Even <ron.even.tlv@gmail.com>
To: "'Ali C. Begen (abegen)'" <abegen@cisco.com>, avt@ietf.org
References: <81B9B88E2F9D574AA5328A85547CDE9101071D80@xmb-rtp-21d.amer.cisco.com> <49f1a1d6.190c660a.58fe.ffffa90e@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C80DA@xmb-sjc-215.amer.cisco.com> <49f208e8.05a0660a.5bd2.6764@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C81C9@xmb-sjc-215.amer.cisco.com> <49f211fc.07a5660a.3f7f.ffff8f4a@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C8202@xmb-sjc-215.amer.cisco.com> <49f2efa2.1c215e0a.4454.ffffaf91@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C8403@xmb-sjc-215.amer.cisco.com> <49f36ee2.0437560a.11df.1eef@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C8405@xmb-sjc-215.amer.cisco.com> <49f37fde.09a1660a.2b46.ffffb694@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C8408@xmb-sjc-215.amer.cisco.com>
In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D54092C8408@xmb-sjc-215.amer.cisco.com>
Date: Sun, 26 Apr 2009 11:14:07 +0300
Message-ID: <49f4182f.07a5660a.3f7f.ffffe36a@mx.google.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Acm+sdXPh1GGTWXYSFG97HplRMX73QGHOeBQAAroqxAABGe0AAAAUgbQAAEZLVAAAGk5sAAgqbUwABJxCtAAAIRzIAAAQcKgAADfs5AAAik1MAAVaJ8A
Content-Language: en-us
Cc: "'Bill Ver Steeg (versteb)'" <versteb@cisco.com>
Subject: Re: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions (RAMS)" available
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/avt>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 26 Apr 2009 08:14:27 -0000
Ali, I looked at RTSP http://tools.ietf.org/html/draft-ietf-mmusic-rfc2326bis-20#appendix-D D.1.2. Media Streams The "m=" field is used to enumerate the streams. It is expected that all the specified streams will be rendered with appropriate synchronization. If the session is over multicast, the port number indicated SHOULD be used for reception. The client MAY try to override the destination port, through the Transport header. The servers MAY allow this, the response will indicate if allowed or not. If the session is unicast, the port numbers are the ones RECOMMENDED by the server to the client, about which receiver ports to use; the client MUST still include its receiver ports in its SETUP request. The client MAY ignore this recommendation. If the server has no preference, it SHOULD set the port number value to zero. Note that the client has the choice on which port to receive the unicast stream, this is why there should be such a parameter in RAMS-R Also " D.1.8. Connection Information In SDP, the "c=" field contains the destination address for the media stream. For on-demand unicast streams and some multicast streams, the destination address MAY be specified by the client via the SETUP request, thus overriding any specified address. To identify streams without a fixed destination address, where the client is required to specify a destination address, the "c=" field SHOULD be set to a null value. For addresses of type "IP4", this value MUST be "0.0.0.0", and for type "IP6", this value MUST be "0:0:0:0:0:0:0:0" (can also be written as "::"), i.e. the unspecified address according to RFC 4291 [RFC4291]." As for the c-line in the unicast stream the whole section you quoted " If the session is multicast, the connection address will be an IP multicast group address. If the session is not multicast, then the connection address contains the unicast IP address of the expected data source or data relay or data sink as determined by additional attribute fields. It is not expected that unicast addresses will be given in a session description that is communicated by a multicast announcement, though this is not prohibited." Now the expectation here is for the address of the stream described by the port in the m-line, I do not see any other attribute. Also look at the above text from RTSP. The RS does not know the IP address on the RR to where to send the RTP unicast repair stream. If you assume it is to the IP address from where the RTCP RAMS-R came from this is not mandated that the client will have such implementation. Furthermore the address that the RS will see in the received RTCP RAMS-R packet may have been change by a NAT or SBC. Roni -----Original Message----- From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] Sent: Sunday, April 26, 2009 1:23 AM To: Roni Even; avt@ietf.org Cc: Bill Ver Steeg (versteb) Subject: RE: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions (RAMS)" available Inline. > m=video 41000 RTP/AVPF 98 > i=Primary Multicast Stream #2 > c=IN IP4 224.1.1.2/255 > a=source-filter: incl IN IP4 224.1.1.2 192.0.2.2 > > Source (192.0.2.2) sends the rtp packets to the multicast > group (224.1.1.2) > with a dest port 41000. > > a=rtpmap:98 MP2T/90000 > a=rtcp:41001 IN IP4 192.0.2.1 > > The feedback target (RS) address for this SSM session is > 192.0.2.1 and its > port is 41001. This is the address/port where RR sends the RAMS-R, or > receiver reports for the SSM session. > > a=rtcp-fb:98 nack > a=rtcp-fb:98 nack ssli > a=ssrc:123321 cname:iptv-ch32@rams.example.com > a=mid:3 > m=video 41002 RTP/AVPF 99 > > The retransmission packets go to port 41002. This is the port > RRs listen to > for retransmission and RAMS. > > Roni E: This implies that the multicast source defines the > port that all > clients MUST use to receive the unicast information from the > Burst source. Yes, that is what it implies (One nit is that I would call it unicast RTP packets rather than information since we may use another port for RTCP packets). > i=Unicast Retransmission Stream #2 (Ret. and Rapid > Acq. Support) > c=IN IP4 192.0.2.1 > > This is where the retransmission packets come from, same as > the feedback > target (in this example). > > Roni E: If this is the address of the feedback target it > belongs to the > above m-line (m=video 41002 RTP/AVPF 99) that according to > you gives the > port on the RR and not on the RS. The problem is that This line actually specifies the sender for the unicast retransmission session. In our case, it just happens to be the feedback target for the primary SSM session, too. I recall some discussion about using a retransmission source which is different than the feedback target for the SSM. In that case, the address would be different, I guess. > according to SDP the > combination of the c= and port on the m-line provides the > transport address > to where a stream will be sent so according to SDP this The port on the m line is the port where the retranmission packets are sent. However, c line denotes the source for these packets. RFC 4566 page 13 says that "... If the session is not multicast, then the connection address contains the unicast IP address of the expected data source or data relay or data sink as determined by additional attribute fields..." Am I missing something? > m-line specify an > address and port on the Feedback Target and not on the RR and > only to this > address RTP payload type 99 will be sent. I am positive that > this is not > what you want. There can be other payload types we might need to send on this retransmission session in the future. In that case, we will add them. > a=rtpmap:99 rtx/90000 > a=rtcp:41003 > > This is where the RTCP packets for the retransmission session go. For > example, RAMS-I goes to this port on RRs. RAMS-T goes to this > port on RS. > > Roni E: So now you assume that the RR must use the same port > as the FT for > this communication. I could not find any place that one > m-line gives the Not the m line, but the "a=rtcp" line. Is this wrong? > address for both sides. This RTCP port is on 192.0.2.1 so it > will be used > for RAMS-R but not for RAMS-I. RAMS-R should go to the feedback target address and port for the primary SSM session since it is a feedback message for the SSM session. But, RAMS-T is a feedback message for the retransmission session, thus, it should go to the RTCP port of the retransmission session (41003). I hope this also clarifies your question in the next email. If you think I got the ports wrong, let me know. -acbegen > a=fmtp:99 apt=98; rtx-time=5000 > a=mid:4 > > > -acbegen > > > > -----Original Message----- > > From: Roni Even [mailto:ron.even.tlv@gmail.com] > > Sent: Saturday, April 25, 2009 1:11 PM > > To: Ali C. Begen (abegen); avt@ietf.org > > Cc: Bill Ver Steeg (versteb) > > Subject: RE: [AVT] New draft of "Rapid Acquisition of > > Multicast RTPSessions (RAMS)" available > > > > Ali, > > Can you please write three addresses from this strange SDP. > > > > 1. The address and port of multicast > > > > 2. The address and port of the RS where the RTCP FB should go to > > > > 3. The address and port on the RR where the unicast stream > > should be sent to > > > > Roni > > > > -----Original Message----- > > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > > Sent: Saturday, April 25, 2009 11:02 PM > > To: Roni Even; avt@ietf.org > > Cc: Bill Ver Steeg (versteb) > > Subject: RE: [AVT] New draft of "Rapid Acquisition of > > Multicast RTPSessions > > (RAMS)" available > > > > > Ali, > > > The example SDP is syntactically correct but it does not > > say that the > > > rtp/rtcp mux will be used and it does not give the > > > information to where the > > > unicast stream will be sent when the RR sends a RAMS-R. > > > > To my knowledge, the first line in the following SDP tells > > the RRs on which > > port they will receive the retransmission/burst packets. > > > > m=video 41002 RTP/AVPF 99 > > i=Unicast Retransmission Stream #2 (Ret. and Rapid > > Acq. Support) > > c=IN IP4 192.0.2.1 > > a=rtpmap:99 rtx/90000 > > a=rtcp:41003 > > a=fmtp:99 apt=98; rtx-time=5000 > > a=mid:4 > > > > There is a typo, you are right. That "a=recvonly" line should > > only exist in > > the SDP sent to RRs. In the SDP sent to RS, we should rather have > > "a=sendonly". I will make this correction in the next version. > > > > The feedback target for the SSM session and the RTCP port for the > > retransmission session are also defined in the SDP. > > > > Hope this clarifies. > > > > BR, > > -acbegen > > > > > > > > I am not sure why the unicast stream m-line has a port > > number with an > > > attribute of recvonly. What is the use case for that. The > > > only information > > > that the RR will need is the RTCP port on the RS to where to > > > send the RAMS-R > > > message. > > > Roni > > > -----Original Message----- > > > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > > > Sent: Friday, April 24, 2009 10:37 PM > > > To: Roni Even; avt@ietf.org > > > Cc: Bill Ver Steeg (versteb) > > > Subject: RE: [AVT] New draft of "Rapid Acquisition of > > > Multicast RTPSessions > > > (RAMS)" available > > > > > > This is a part of an example SDP sent to RS and RR in a SAP > > > announcement, > > > for example. So, the SDP describes what both parties should > > > do (RR cannot > > > say that he wants to receive this multicast on its favorite > > port). The > > > individual SDPs sent to RR or RS may include other portions > > > of descriptions > > > that will contain specific information. > > > > > > -acbegen > > > > > > > -----Original Message----- > > > > From: Roni Even [mailto:ron.even.tlv@gmail.com] > > > > Sent: Friday, April 24, 2009 12:23 PM > > > > To: Ali C. Begen (abegen); avt@ietf.org > > > > Cc: Bill Ver Steeg (versteb) > > > > Subject: RE: [AVT] New draft of "Rapid Acquisition of > > > > Multicast RTPSessions (RAMS)" available > > > > > > > > Ali, > > > > I think you get it wrong, this SDP is from the RS and not the > > > > RR so the RS > > > > cannot specify to which address it will send it can only > > > > specify to which > > > > address it can receive RTP stream. In this SDP the relevant > > > > information is > > > > that the request for retransmission will be sent by the RR to > > > > port 41003 > > > > Roni > > > > > > > > -----Original Message----- > > > > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > > > > Sent: Friday, April 24, 2009 10:01 PM > > > > To: Roni Even; avt@ietf.org > > > > Cc: Bill Ver Steeg (versteb) > > > > Subject: RE: [AVT] New draft of "Rapid Acquisition of > > > > Multicast RTPSessions > > > > (RAMS)" available > > > > > > > > Oh, I see. The burst goes to the port that we would > > > normally send the > > > > retransmissions. For example, consider the SDP from the draft: > > > > > > > > m=video 41000 RTP/AVPF 98 > > > > i=Primary Multicast Stream #2 > > > > c=IN IP4 224.1.1.2/255 > > > > a=source-filter: incl IN IP4 224.1.1.2 192.0.2.2 > > > > a=rtpmap:98 MP2T/90000 > > > > a=rtcp:41001 IN IP4 192.0.2.1 > > > > a=rtcp-fb:98 nack > > > > a=rtcp-fb:98 nack ssli > > > > a=ssrc:123321 cname:iptv-ch32@rams.example.com > > > > a=mid:3 > > > > m=video 41002 RTP/AVPF 99 > > > > i=Unicast Retransmission Stream #2 (Ret. and Rapid > > > > Acq. Support) > > > > c=IN IP4 192.0.2.1 > > > > a=recvonly > > > > a=rtpmap:99 rtx/90000 > > > > a=rtcp:41003 > > > > a=fmtp:99 apt=98; rtx-time=5000 > > > > a=mid:4 > > > > > > > > In this case, the burst will go to port 41002 on the RR. > > The RAMS-I > > > > message(s), which is an RTCP feedback message, will go to > > > port 41003. > > > > > > > > HTH, > > > > -acbegen > > > > > > > > > -----Original Message----- > > > > > From: Roni Even [mailto:ron.even.tlv@gmail.com] > > > > > Sent: Friday, April 24, 2009 11:44 AM > > > > > To: Ali C. Begen (abegen); avt@ietf.org > > > > > Cc: Bill Ver Steeg (versteb) > > > > > Subject: RE: [AVT] New draft of "Rapid Acquisition of > > > > > Multicast RTPSessions (RAMS)" available > > > > > > > > > > Ali, > > > > > I will try to explain in simple way > > > > > > > > > > When the RS receives the RAMS-R it need to start sending an > > > > > RTP stream to > > > > > the RR. > > > > > In order to send a unicast packet, the RS needs to know a > > > > > transport address > > > > > on the RR to where the RTP stream will be sent. The current > > > > > draft does not > > > > > say how the RS knows this address. There is no SDP from RR to > > > > > RS like you > > > > > mention in your response. > > > > > This is why I say that the current draft does not specify a > > > > > solution that > > > > > can be implemented as a working solution > > > > > Roni > > > > > > > > > > -----Original Message----- > > > > > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > > > > > Sent: Friday, April 24, 2009 7:38 PM > > > > > To: Roni Even; avt@ietf.org > > > > > Cc: Bill Ver Steeg (versteb) > > > > > Subject: RE: [AVT] New draft of "Rapid Acquisition of > > > > > Multicast RTPSessions > > > > > (RAMS)" available > > > > > > > > > > Hi Roni, > > > > > > > > > > > -----Original Message----- > > > > > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On > > > > > > Behalf Of Roni Even > > > > > > Sent: Friday, April 24, 2009 4:24 AM > > > > > > To: avt@ietf.org > > > > > > Cc: Bill Ver Steeg (versteb) > > > > > > Subject: Re: [AVT] New draft of "Rapid Acquisition of > > > > > > Multicast RTPSessions (RAMS)" available > > > > > > > > > > > > Hi, > > > > > > > > > > > > I think that the current draft does not give a > description of > > > > > > a system that works since there is no text > explaining how the > > > > > > > > > > What do you mean by "a system that works"? > > > > > > > > > > > RS knows the unicast transport address on the RR to > where to > > > > > > send the stream. > > > > > > > > > > Once RS receives the request packet from an RR, RS knows its > > > > > address. Ports > > > > > are defined in the SDP. If you are asking about "NAT" issues, > > > > > we have a > > > > > section for it, and we plan to complete it as we move > > > > > forward. It is not as > > > > > critical as the other parts for now. > > > > > > > > > > > If you mandate the use of RTP/RTCP mux it should say so > > > > > > otherwise the RAMS-R should have an optional parameter that > > > > > > supplies this information and a flag for using RTP/RTCP mux. > > > > > > > > > > IMO, we cannot mandate muxing as it is not required to make > > > > > RAMS work. If > > > > > muxing is supported, the SDP should reflect it. > > > > > > > > > > BR, > > > > > -acbegen > > > > > > > > > > > Thanks > > > > > > > > > > > > Roni Even > > > > > > > > > > > > > > > > > > > > > > > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On > > > > > > Behalf Of Bill Ver Steeg (versteb) > > > > > > Sent: Thursday, April 16, 2009 7:39 PM > > > > > > To: avt@ietf.org > > > > > > Subject: [AVT] New draft of "Rapid Acquisition of Multicast > > > > > > RTP Sessions (RAMS)" available > > > > > > > > > > > > > > > > > > > > > > > > There is a new draft of the "Rapid Acquisition of Multicast > > > > > > RTP Sessions (RAMS)" draft available at > > > > > > > http://www.ietf.org/internet-drafts/draft-versteeg-avt-rapid-s > > > > > ynchronization-for-rtp-03.txt <http://www.ietf.org/internet-> > > > > > > drafts/draft-versteeg-avt-rapid-synchronization-for-rtp-03.txt> > > > > > > > > > > > > > > > > > > > > > > > > We have incorporated the changes from the technical > breakout > > > > > > session in San Francisco. The major changes in this version > > > > > > of the draft include > > > > > > > > > > > > 1- Changing the document title to avoid confusion > with other > > > > > > ongoing "synchronization" drafts > > > > > > > > > > > > 2- changing the message names to reflect the title change > > > > > > > > > > > > 3- clarification of the RTCP message semantics, including > > > > > > changes to the "Request" and "Inform" messages > > > > > > > > > > > > 4- additional description/motivation for the > various message > > > > > > flows has been added > > > > > > > > > > > > 5- RTP/RTCP muxing has been added > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > We hope to make this a Working Group item, and will change > > > > > > the name of the draft to avoid conflicts with other > > > > > > "synchronization" drafts at that time. > > > > > > > > > > > > > > > > > > > > > > > > Bill VerSteeg > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
- [AVT] New draft of "Rapid Acquisition of Multicas… Bill Ver Steeg (versteb)
- Re: [AVT] New draft of "Rapid Acquisition of Mult… Ingemar Johansson S
- Re: [AVT] New draft of "Rapid Acquisition of Mult… Ali C. Begen (abegen)
- Re: [AVT] New draft of "Rapid Acquisition of Mult… Zou ZiXuan
- Re: [AVT] New draft of "Rapid Acquisition of Mult… Roni Even
- Re: [AVT] New draft of "Rapid Acquisition of Mult… Ali C. Begen (abegen)
- Re: [AVT] New draft of "Rapid Acquisition of Mult… Ali C. Begen (abegen)
- Re: [AVT] New draft of "Rapid Acquisition of Mult… Roni Even
- Re: [AVT] New draft of "Rapid Acquisition of Mult… Bill Ver Steeg (versteb)
- Re: [AVT] New draft of "Rapid Acquisition of Mult… Ali C. Begen (abegen)
- Re: [AVT] New draft of "Rapid Acquisition of Mult… Roni Even
- Re: [AVT] New draft of "Rapid Acquisition of Mult… Roni Even
- Re: [AVT] New draft of "Rapid Acquisition of Mult… Ali C. Begen (abegen)
- Re: [AVT] New draft of "Rapid Acquisition of Mult… Bill Ver Steeg (versteb)
- Re: [AVT] New draft of "Rapid Acquisition of Mult… Zou ZiXuan
- Re: [AVT] New draft of "Rapid Acquisition of Mult… Roni Even
- Re: [AVT] New draft of "Rapid Acquisition of Mult… Ingemar Johansson S
- Re: [AVT] New draft of "Rapid Acquisition of Mult… Ali C. Begen (abegen)
- Re: [AVT] New draft of "Rapid Acquisition of Mult… Roni Even
- Re: [AVT] New draft of "Rapid Acquisition of Mult… Ali C. Begen (abegen)
- Re: [AVT] New draft of "Rapid Acquisition of Mult… Ali C. Begen (abegen)
- Re: [AVT] New draft of "Rapid Acquisition of Mult… Roni Even
- Re: [AVT] New draft of "Rapid Acquisition of Mult… Roni Even
- Re: [AVT] New draft of "Rapid Acquisition of Mult… Roni Even
- Re: [AVT] New draft of "Rapid Acquisition of Mult… Ali C. Begen (abegen)
- Re: [AVT] New draft of "Rapid Acquisition of Mult… Ali C. Begen (abegen)
- Re: [AVT] New draft of "Rapid Acquisition of Mult… Roni Even
- Re: [AVT] New draft of "Rapid Acquisition of Mult… Ali C. Begen (abegen)
- Re: [AVT] New draft of "Rapid Acquisition of Mult… Roni Even
- Re: [AVT] New draft of "Rapid Acquisition of Mult… Ali C. Begen (abegen)
- Re: [AVT] New draft of "Rapid Acquisition of Mult… Ingemar Johansson S
- Re: [AVT] New draft of "Rapid Acquisition of Mult… José Rey
- Re: [AVT] New draft of "Rapid Acquisition of Mult… Ali C. Begen (abegen)
- Re: [AVT] New draft of "Rapid Acquisition of Mult… Jose Rey
- Re: [AVT] New draft of "Rapid Acquisition of Mult… Ali C. Begen (abegen)
- Re: [AVT] New draft of "Rapid Acquisition of Mult… Roni Even
- Re: [AVT] New draft of "Rapid Acquisition of Mult… Bill Ver Steeg (versteb)
- Re: [AVT] New draft of "Rapid Acquisition of Mult… Roni Even
- Re: [AVT] New draft of "Rapid Acquisition of Mult… David R Oran
- Re: [AVT] New draft of "Rapid Acquisition of Mult… Roni Even
- Re: [AVT] New draft of "Rapid Acquisition of Mult… David R Oran
- Re: [AVT] New draft of "Rapid Acquisition of Mult… Roni Even