[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [AVT] avt Digest, Vol 62, Issue 59

To: avt at ietf.org
Subject: Re: [AVT] avt Digest, Vol 62, Issue 59
From: lillianlee62 at yahoo.com
Date: Tue, 30 Jun 2009 13:35:38 +0000
Delivered-to: avt at core3.amsl.com
Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:X-rim-org-msg-ref-id:Return-Receipt-To:Message-ID:Content-Transfer-Encoding:Reply-To:X-Priority:References:In-Reply-To:Sensitivity:Importance:To:Subject:From:Date:Content-Type:MIME-Version; b=IKzg0jf3upBRpunNry0S9mnpUasXQ3CW1oSNbu1eRoDZ0K+BItLuLfDXIlXbl9ZaQNNBVt360HyeG43Eu5y2zFltHk58bZXPDcdm66pmkVPY70LZ+dd8TJ8vydpMk69p/RQ44qbWmE5FFMFe130WnbekRUSexd0EP8ygkA59Sp0= ;
Importance: Normal
In-reply-to: <mailman.11847.1246367564.4936.avt at ietf.org>
List-archive: <http://www.ietf.org/mail-archive/web/avt>
List-help: <mailto:avt-request@ietf.org?subject=help>
List-id: Audio/Video Transport Working Group <avt.ietf.org>
List-post: <mailto:avt@ietf.org>
List-subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
List-unsubscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
References: <mailman.11847.1246367564.4936.avt at ietf.org>
Reply-to: lillianlee62 at yahoo.com
Sensitivity: Normal
Sent via BlackBerry from T-Mobile

-----Original Message-----
From: avt-request at ietf.org

Date: Tue, 30 Jun 2009 06:12:44 
To: <avt at ietf.org>
Subject: avt Digest, Vol 62, Issue 59


If you have received this digest without all the individual message
attachments you will need to update your digest options in your list
subscription.  To do so, go to 

https://www.ietf.org/mailman/listinfo/avt

Click the 'Unsubscribe or edit options' button, log in, and set "Get
MIME or Plain Text Digests?" to MIME.  You can set this option
globally for all the list digests you receive at this point.



Send avt mailing list submissions to
	avt at ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
	https://www.ietf.org/mailman/listinfo/avt
or, via email, send a message with subject or body 'help' to
	avt-request at ietf.org

You can reach the person managing the list at
	avt-owner at ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of avt digest..."


Today's Topics:

   1. Re: Port mappings, NAT, and RAMS (Ali C. Begen (abegen))
   2. Re: Port mappings, NAT, and RAMS (Roni Even)
   3. Re: Port mappings, NAT, and RAMS (David R Oran)


----------------------------------------------------------------------

Message: 1
Date: Tue, 30 Jun 2009 00:18:31 -0700
From: "Ali C. Begen (abegen)" <abegen at cisco.com>
Subject: Re: [AVT] Port mappings, NAT, and RAMS
To: "VAN CAENEGEM Tom" <Tom.Van_Caenegem at alcatel-lucent.be>,	"Bill Ver
	Steeg (versteb)" <versteb at cisco.com>,	"Zeev Vax"
	<zeevvax at microsoft.com>, "Roni Even" <Even.roni at huawei.com>,
	<avt at ietf.org>
Message-ID:
	<04CAD96D4C5A3D48B1919248A8FE0D5409A71F22 at xmb-sjc-215.amer.cisco.com>
Content-Type: text/plain;	charset="Windows-1252"

Hi Tom,

Let's get the input from the WG on these points. I believe going for a more general solution that will be applicable to both RAMS and NACK is more desirable.

BR,
-acbegen



> -----Original Message-----
> From: VAN CAENEGEM Tom [mailto:Tom.Van_Caenegem at alcatel-lucent.be]
> Sent: Monday, June 29, 2009 9:17 AM
> To: Ali C. Begen (abegen); Bill Ver Steeg (versteb); Zeev Vax; Roni Even; avt at ietf.org
> Subject: RE: Port mappings, NAT, and RAMS
> 
> 
>  Ali,
> 
> See some comments below (TOM).
> 
> -----Original Message-----
> From: Ali C. Begen (abegen) [mailto:abegen at cisco.com]
> Sent: vrijdag 26 juni 2009 17:41
> To: VAN CAENEGEM Tom; Bill Ver Steeg (versteb); Zeev Vax; Roni Even;
> avt at ietf.org
> Subject: RE: Port mappings, NAT, and RAMS
> 
> Hi Tom,
> 
> [snip]
> > The reason why we need pubports is that it indicates "explicitly" the
> > port the client wants to use to receive the burst is the port it used
> > to send the RAMS-R/pubports message. I believe we need this explicit
> > indication, ow, we will be making an implicit assumption. Note that
> > the rams-r/pubports is in the primary session and burst/ret packets
> > are in the retransmission session, which is different than the
> primary.
> >
> > As far as I can see, not everybody agrees on this point, but we need
> > to make a decision here before we mandate anything.
> >
> > TOM: I agree with your last line, but I do not completely agree when
> > you mention "implicit" assumption, especially for option 3, where
> > RAMS-R (or
> > NACK) and the Pub-port message are in the same compound message. If we
> 
> > "define" that if no pub-report message is sent by the RR, the
> > information towards the Retransmission server is exactly the same as
> > when an RTP receiver sends an RTCP compound message made up of an RTCP
> 
> > NACK/RAMS-R together with a pub-port message where the ports are
> "zero"
> 
> We "may" be able to say it from RAMS-R but not for NACK since we are not
> defining it, we will be overloading its meaning, IMO. And as you/Bill
> pointed out in other emails, I also believe that this is more general
> problem than just RAMS. We need something like pubports for NACKs as
> well.
> 
> 
> TOM: indeed, that is why IMO we should define this problem and solution
> in a separate draft which applies to any system architecture where a
> unicast session from a FT is coupled to a ssm session with that same FT.
> 
> 
> > -as currently proposed in the RAMS draft now.  I agree that this is
> > not true for option 4, where pub-port and RAMS-R or NACK are separate
> > messages, but I do not favour the solution of option 4 for the same
> > reason you mention in your reply (a new failure mode). So, if option 4
> 
> > is -for that reason- no longer considered, I do not see a problem with
> 
> > defining this rule/clause as expressed above. In other words, there is
> 
> > no need for a pub-report message in this scenario and this results NOT
> 
> > in an "assumption" what-so-ever.
> >
> >
> > > supports RTP/RTCP muxing itself, and if it knows the RS supports
> > > RTP/RTCP muxing too (as indicated in the declarative sdp received by
> 
> > > the
> > > RR)
> > >
> > > -Don't we also allow that for option 3, the port P2 actually equals
> > > port P4? This is a kind of hybrid of session and SSRC multiplexing
> > > of the primary multicast RTP stream and the
> > > retransmission/acceleration session
> > > :  on the unidirectional RTP layer, the primary MC packets and the
> > > unicast retransmission packets are clearly session muxed, but the
> > > RTCP
> >
> > > "return" channel for both streams have exactly the same transport
> > > addresses, but are distinguished by means of a different SSRC.  In
> > > that
> >
> > How? Since SSM and retransmission sessions are session muxed, they
> > have the same SSRC. When a client is sending a receiver report, how do
> 
> > we identify which session it belongs to? So, I believe P2 should be
> > different than P4.
> >
> > TOM: you are right. But notice this: RFC 4588 mandates that when
> > session muxing is used for retransmission, than the SSRC should be the
> same.
> > However the RFC 4588 does not give arguments why it needs to be like
> > that. So I ask you: what would or can happen if there is a different
> > SSRC used?  If there are no convincing arguments why we must stick to
> 
> Good question. If we don't use the same SSRC in session-muxed RTP
> sessions, it will introduce correlation problems. Receiver/XR reports
> coming from a larger number of receivers will be difficult to identify
> and match at the server side. There will be SSRC collisions, which will
> complicate things further.
> 
> TOM: the big difference with when the RFC 4588 was being discussed and
> developed, is that now we are capable of advertising in SDP the SSRC of
> the media server, that is in this case the retransmission server SSRC
> used in the retransmission session. In fact for RAMS, we need to define
> the SSRC of the ssm RTP session, so we can as well do it for the
> retransmission session. Perhaps we should consider this different SSRC
> possibility (hence violating RFC 4588) as part of a new draft, the one I
> mentioned above.
> 
> 
> > the same SSRC, then, if we have a good use case to depart from that
> > "rule" -and the use case we are discussing here is IMO indeed a valid
> > use case- I do not see why we should be limited by such a "rule". The
> > "valid" use case is here that RAMS and Retransmission for SSM sessions
> 
> > operates fine through any NAPT and without any dedicated RTCP message.
> 
> -acbegen


------------------------------

Message: 2
Date: Tue, 30 Jun 2009 13:55:56 +0300
From: Roni Even <Even.roni at huawei.com>
Subject: Re: [AVT] Port mappings, NAT, and RAMS
To: "'Ali C. Begen (abegen)'" <abegen at cisco.com>,	'VAN CAENEGEM Tom'
	<Tom.Van_Caenegem at alcatel-lucent.be>,	"'Bill Ver Steeg (versteb)'"
	<versteb at cisco.com>,	'Zeev Vax' <zeevvax at microsoft.com>, avt at ietf.org
Message-ID: <00e601c9f971$6a7b0e80$3f712b80$%roni at huawei.com>
Content-Type: text/plain; charset=us-ascii

Hi guys,
My view is that this is not a general NACK problem but only for the case of
SSM and retransmission with similar box architecture to the RAMS solution.
If you have another case please explain
Roni

> -----Original Message-----
> From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On Behalf Of
> Ali C. Begen (abegen)
> Sent: Tuesday, June 30, 2009 10:19 AM
> To: VAN CAENEGEM Tom; Bill Ver Steeg (versteb); Zeev Vax; Roni Even;
> avt at ietf.org
> Subject: Re: [AVT] Port mappings, NAT, and RAMS
> 
> Hi Tom,
> 
> Let's get the input from the WG on these points. I believe going for a
> more general solution that will be applicable to both RAMS and NACK is
> more desirable.
> 
> BR,
> -acbegen
> 
> 
> 
> > -----Original Message-----
> > From: VAN CAENEGEM Tom [mailto:Tom.Van_Caenegem at alcatel-lucent.be]
> > Sent: Monday, June 29, 2009 9:17 AM
> > To: Ali C. Begen (abegen); Bill Ver Steeg (versteb); Zeev Vax; Roni
> Even; avt at ietf.org
> > Subject: RE: Port mappings, NAT, and RAMS
> >
> >
> >  Ali,
> >
> > See some comments below (TOM).
> >
> > -----Original Message-----
> > From: Ali C. Begen (abegen) [mailto:abegen at cisco.com]
> > Sent: vrijdag 26 juni 2009 17:41
> > To: VAN CAENEGEM Tom; Bill Ver Steeg (versteb); Zeev Vax; Roni Even;
> > avt at ietf.org
> > Subject: RE: Port mappings, NAT, and RAMS
> >
> > Hi Tom,
> >
> > [snip]
> > > The reason why we need pubports is that it indicates "explicitly"
> the
> > > port the client wants to use to receive the burst is the port it
> used
> > > to send the RAMS-R/pubports message. I believe we need this
> explicit
> > > indication, ow, we will be making an implicit assumption. Note that
> > > the rams-r/pubports is in the primary session and burst/ret packets
> > > are in the retransmission session, which is different than the
> > primary.
> > >
> > > As far as I can see, not everybody agrees on this point, but we
> need
> > > to make a decision here before we mandate anything.
> > >
> > > TOM: I agree with your last line, but I do not completely agree
> when
> > > you mention "implicit" assumption, especially for option 3, where
> > > RAMS-R (or
> > > NACK) and the Pub-port message are in the same compound message. If
> we
> >
> > > "define" that if no pub-report message is sent by the RR, the
> > > information towards the Retransmission server is exactly the same
> as
> > > when an RTP receiver sends an RTCP compound message made up of an
> RTCP
> >
> > > NACK/RAMS-R together with a pub-port message where the ports are
> > "zero"
> >
> > We "may" be able to say it from RAMS-R but not for NACK since we are
> not
> > defining it, we will be overloading its meaning, IMO. And as you/Bill
> > pointed out in other emails, I also believe that this is more general
> > problem than just RAMS. We need something like pubports for NACKs as
> > well.
> >
> >
> > TOM: indeed, that is why IMO we should define this problem and
> solution
> > in a separate draft which applies to any system architecture where a
> > unicast session from a FT is coupled to a ssm session with that same
> FT.
> >
> >
> > > -as currently proposed in the RAMS draft now.  I agree that this is
> > > not true for option 4, where pub-port and RAMS-R or NACK are
> separate
> > > messages, but I do not favour the solution of option 4 for the same
> > > reason you mention in your reply (a new failure mode). So, if
> option 4
> >
> > > is -for that reason- no longer considered, I do not see a problem
> with
> >
> > > defining this rule/clause as expressed above. In other words, there
> is
> >
> > > no need for a pub-report message in this scenario and this results
> NOT
> >
> > > in an "assumption" what-so-ever.
> > >
> > >
> > > > supports RTP/RTCP muxing itself, and if it knows the RS supports
> > > > RTP/RTCP muxing too (as indicated in the declarative sdp received
> by
> >
> > > > the
> > > > RR)
> > > >
> > > > -Don't we also allow that for option 3, the port P2 actually
> equals
> > > > port P4? This is a kind of hybrid of session and SSRC
> multiplexing
> > > > of the primary multicast RTP stream and the
> > > > retransmission/acceleration session
> > > > :  on the unidirectional RTP layer, the primary MC packets and
> the
> > > > unicast retransmission packets are clearly session muxed, but the
> > > > RTCP
> > >
> > > > "return" channel for both streams have exactly the same transport
> > > > addresses, but are distinguished by means of a different SSRC.
> In
> > > > that
> > >
> > > How? Since SSM and retransmission sessions are session muxed, they
> > > have the same SSRC. When a client is sending a receiver report, how
> do
> >
> > > we identify which session it belongs to? So, I believe P2 should be
> > > different than P4.
> > >
> > > TOM: you are right. But notice this: RFC 4588 mandates that when
> > > session muxing is used for retransmission, than the SSRC should be
> the
> > same.
> > > However the RFC 4588 does not give arguments why it needs to be
> like
> > > that. So I ask you: what would or can happen if there is a
> different
> > > SSRC used?  If there are no convincing arguments why we must stick
> to
> >
> > Good question. If we don't use the same SSRC in session-muxed RTP
> > sessions, it will introduce correlation problems. Receiver/XR reports
> > coming from a larger number of receivers will be difficult to
> identify
> > and match at the server side. There will be SSRC collisions, which
> will
> > complicate things further.
> >
> > TOM: the big difference with when the RFC 4588 was being discussed
> and
> > developed, is that now we are capable of advertising in SDP the SSRC
> of
> > the media server, that is in this case the retransmission server SSRC
> > used in the retransmission session. In fact for RAMS, we need to
> define
> > the SSRC of the ssm RTP session, so we can as well do it for the
> > retransmission session. Perhaps we should consider this different
> SSRC
> > possibility (hence violating RFC 4588) as part of a new draft, the
> one I
> > mentioned above.
> >
> >
> > > the same SSRC, then, if we have a good use case to depart from that
> > > "rule" -and the use case we are discussing here is IMO indeed a
> valid
> > > use case- I do not see why we should be limited by such a "rule".
> The
> > > "valid" use case is here that RAMS and Retransmission for SSM
> sessions
> >
> > > operates fine through any NAPT and without any dedicated RTCP
> message.
> >
> > -acbegen
> _______________________________________________
> Audio/Video Transport Working Group
> avt at ietf.org
> https://www.ietf.org/mailman/listinfo/avt



------------------------------

Message: 3
Date: Tue, 30 Jun 2009 09:10:26 -0400
From: David R Oran <oran at cisco.com>
Subject: Re: [AVT] Port mappings, NAT, and RAMS
To: Roni Even <Even.roni at huawei.com>
Cc: 'VAN CAENEGEM Tom' <Tom.Van_Caenegem at alcatel-lucent.be>,
	avt at ietf.org,	"'Bill Ver Steeg \(versteb\)'" <versteb at cisco.com>,
	'Zeev Vax' <zeevvax at microsoft.com>
Message-ID: <83D31F7D-8D4C-44D1-9AD3-814C4776922F at cisco.com>
Content-Type: text/plain; charset="us-ascii"; Format="flowed";
	DelSp="yes"


On Jun 30, 2009, at 6:55 AM, Roni Even wrote:

> Hi guys,
> My view is that this is not a general NACK problem but only for the  
> case of
> SSM and retransmission with similar box architecture to the RAMS  
> solution.
> If you have another case please explain
I believe it is actually a MORE general problem than NACK or RAMS. I  
arises from mixing SSM sessions and unicast sessions for the same RTP- 
based application. That's because multicast enforces port symmetry  
among all the receivers while unicast needs per-receiver port selection.

So far we have two uses for mixing multicast and unicast:  
retransmission-based repair, and RAMS. I suspect more uses will arise  
in the future. I can think of a few off the top of my head:
- customized per-user overlays (e.g. to be alpha-blended with the  
video) or object-level replacement
- network-coded error recovery streams
- extra media info for re-integration when switching back from unicast  
to multicast in a fast-forward-to-realtime capability when doing  
"pause-live-content" style services
- adaptive switching between multicast and unicast based on number of  
simultaneous receivers.

I have a strong intuition that doing a generic mechanism to atomically  
signal ports for unicast sessions using the RTCP feedback machinery of  
the SSM session would be highly advisable.

So, I think:
a) we need to solve this problem
b) it exists even in the absence of NATs
c) we need a generic mechanism
d) it should be documented in a separate draft, and not part of RAMs  
or AVPF.

If we can agree to these points, then we can have a more detailed  
discussion of the appropriate machinery. I have opinions on that  
subject too.

DaveO.



> Roni
>
>> -----Original Message-----
>> From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On Behalf Of
>> Ali C. Begen (abegen)
>> Sent: Tuesday, June 30, 2009 10:19 AM
>> To: VAN CAENEGEM Tom; Bill Ver Steeg (versteb); Zeev Vax; Roni Even;
>> avt at ietf.org
>> Subject: Re: [AVT] Port mappings, NAT, and RAMS
>>
>> Hi Tom,
>>
>> Let's get the input from the WG on these points. I believe going  
>> for a
>> more general solution that will be applicable to both RAMS and NACK  
>> is
>> more desirable.
>>
>> BR,
>> -acbegen
>>
>>
>>
>>> -----Original Message-----
>>> From: VAN CAENEGEM Tom [mailto:Tom.Van_Caenegem at alcatel-lucent.be]
>>> Sent: Monday, June 29, 2009 9:17 AM
>>> To: Ali C. Begen (abegen); Bill Ver Steeg (versteb); Zeev Vax; Roni
>> Even; avt at ietf.org
>>> Subject: RE: Port mappings, NAT, and RAMS
>>>
>>>
>>> Ali,
>>>
>>> See some comments below (TOM).
>>>
>>> -----Original Message-----
>>> From: Ali C. Begen (abegen) [mailto:abegen at cisco.com]
>>> Sent: vrijdag 26 juni 2009 17:41
>>> To: VAN CAENEGEM Tom; Bill Ver Steeg (versteb); Zeev Vax; Roni Even;
>>> avt at ietf.org
>>> Subject: RE: Port mappings, NAT, and RAMS
>>>
>>> Hi Tom,
>>>
>>> [snip]
>>>> The reason why we need pubports is that it indicates "explicitly"
>> the
>>>> port the client wants to use to receive the burst is the port it
>> used
>>>> to send the RAMS-R/pubports message. I believe we need this
>> explicit
>>>> indication, ow, we will be making an implicit assumption. Note that
>>>> the rams-r/pubports is in the primary session and burst/ret packets
>>>> are in the retransmission session, which is different than the
>>> primary.
>>>>
>>>> As far as I can see, not everybody agrees on this point, but we
>> need
>>>> to make a decision here before we mandate anything.
>>>>
>>>> TOM: I agree with your last line, but I do not completely agree
>> when
>>>> you mention "implicit" assumption, especially for option 3, where
>>>> RAMS-R (or
>>>> NACK) and the Pub-port message are in the same compound message. If
>> we
>>>
>>>> "define" that if no pub-report message is sent by the RR, the
>>>> information towards the Retransmission server is exactly the same
>> as
>>>> when an RTP receiver sends an RTCP compound message made up of an
>> RTCP
>>>
>>>> NACK/RAMS-R together with a pub-port message where the ports are
>>> "zero"
>>>
>>> We "may" be able to say it from RAMS-R but not for NACK since we are
>> not
>>> defining it, we will be overloading its meaning, IMO. And as you/ 
>>> Bill
>>> pointed out in other emails, I also believe that this is more  
>>> general
>>> problem than just RAMS. We need something like pubports for NACKs as
>>> well.
>>>
>>>
>>> TOM: indeed, that is why IMO we should define this problem and
>> solution
>>> in a separate draft which applies to any system architecture where a
>>> unicast session from a FT is coupled to a ssm session with that same
>> FT.
>>>
>>>
>>>> -as currently proposed in the RAMS draft now.  I agree that this is
>>>> not true for option 4, where pub-port and RAMS-R or NACK are
>> separate
>>>> messages, but I do not favour the solution of option 4 for the same
>>>> reason you mention in your reply (a new failure mode). So, if
>> option 4
>>>
>>>> is -for that reason- no longer considered, I do not see a problem
>> with
>>>
>>>> defining this rule/clause as expressed above. In other words, there
>> is
>>>
>>>> no need for a pub-report message in this scenario and this results
>> NOT
>>>
>>>> in an "assumption" what-so-ever.
>>>>
>>>>
>>>>> supports RTP/RTCP muxing itself, and if it knows the RS supports
>>>>> RTP/RTCP muxing too (as indicated in the declarative sdp received
>> by
>>>
>>>>> the
>>>>> RR)
>>>>>
>>>>> -Don't we also allow that for option 3, the port P2 actually
>> equals
>>>>> port P4? This is a kind of hybrid of session and SSRC
>> multiplexing
>>>>> of the primary multicast RTP stream and the
>>>>> retransmission/acceleration session
>>>>> :  on the unidirectional RTP layer, the primary MC packets and
>> the
>>>>> unicast retransmission packets are clearly session muxed, but the
>>>>> RTCP
>>>>
>>>>> "return" channel for both streams have exactly the same transport
>>>>> addresses, but are distinguished by means of a different SSRC.
>> In
>>>>> that
>>>>
>>>> How? Since SSM and retransmission sessions are session muxed, they
>>>> have the same SSRC. When a client is sending a receiver report, how
>> do
>>>
>>>> we identify which session it belongs to? So, I believe P2 should be
>>>> different than P4.
>>>>
>>>> TOM: you are right. But notice this: RFC 4588 mandates that when
>>>> session muxing is used for retransmission, than the SSRC should be
>> the
>>> same.
>>>> However the RFC 4588 does not give arguments why it needs to be
>> like
>>>> that. So I ask you: what would or can happen if there is a
>> different
>>>> SSRC used?  If there are no convincing arguments why we must stick
>> to
>>>
>>> Good question. If we don't use the same SSRC in session-muxed RTP
>>> sessions, it will introduce correlation problems. Receiver/XR  
>>> reports
>>> coming from a larger number of receivers will be difficult to
>> identify
>>> and match at the server side. There will be SSRC collisions, which
>> will
>>> complicate things further.
>>>
>>> TOM: the big difference with when the RFC 4588 was being discussed
>> and
>>> developed, is that now we are capable of advertising in SDP the SSRC
>> of
>>> the media server, that is in this case the retransmission server  
>>> SSRC
>>> used in the retransmission session. In fact for RAMS, we need to
>> define
>>> the SSRC of the ssm RTP session, so we can as well do it for the
>>> retransmission session. Perhaps we should consider this different
>> SSRC
>>> possibility (hence violating RFC 4588) as part of a new draft, the
>> one I
>>> mentioned above.
>>>
>>>
>>>> the same SSRC, then, if we have a good use case to depart from that
>>>> "rule" -and the use case we are discussing here is IMO indeed a
>> valid
>>>> use case- I do not see why we should be limited by such a "rule".
>> The
>>>> "valid" use case is here that RAMS and Retransmission for SSM
>> sessions
>>>
>>>> operates fine through any NAPT and without any dedicated RTCP
>> message.
>>>
>>> -acbegen
>> _______________________________________________
>> Audio/Video Transport Working Group
>> avt at ietf.org
>> https://www.ietf.org/mailman/listinfo/avt
>
> _______________________________________________
> Audio/Video Transport Working Group
> avt at ietf.org
> https://www.ietf.org/mailman/listinfo/avt

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : <http://www.ietf.org/mail-archive/web/avt/attachments/20090630/9802b306/attachment.sig>

------------------------------

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


End of avt Digest, Vol 62, Issue 59
***********************************
Prev by Date: Re: [AVT] Port mappings, NAT, and RAMS
Next by Date: Re: [AVT] Port mappings, NAT, and RAMS
Previous by thread: [AVT] conclusion of WGLC on draft-ietf-avt-rtp-ipmr-04
Next by thread: [AVT] I-D Action:draft-ietf-avt-rapid-rtp-sync-03.txt
Index(es):
- Date
- Thread