Re: [AVT] Comments on draft-johansson-avt-mcast-based-rams-01

["Ingemar Johansson S" <ingemar.s.johansson at ericsson.com>]

Hi

And thanks for the comments, answers inline below.
Regards
Ingemar

> 
> Hi Ingemar,
> 
> I read the draft, I am not sure how simple this option is but 
> first I have some general comments
> 
>  
> 
> In the last paragraph of section 2.1 you discuss timing 
> between the main multicast session and the rapid stream. I am 
> not sure how good it will work since the join request is not 
> precise in term of timing.
Do you mean that the time between the leave and the join request is not
to be regarded as precise?. I can agree with this, however I don't know
if this is a big issue as one can always let the multicast based RAMS
stream run a little bit ahead to cope for the possible glitch.
Retransmission of missing packets is also an option if the glitch is
small.

> 
> The same goes for the suggestion to delay the multicast 
> stream, I assume that this is an RS application decision but 
> I think that there should be a warning that if the delay is 
> too big it may cause the RR to send a retransmission request 
> since it will think it lost a packet.
Do you mean a retransmitted RAMS-R ?, if this is the case then I beliee
the RS can simply ignore it. 
If it is retransmission requests for missing packets then I am not sure
why this would happen. 

> 
>  
> 
> In 2.2.1 you have an Ed note about using SDP but RAMS-R is 
> from the RR which does not send an SDP. The RAMS work using 
> declarative SDP from the RS
Understood. The point I was trying to make is that it may be sufficient
that the RR sticks to what is specified in the declarative SDP from the
RS. Still I see the possibility that the RR may implement e.g dual IP
stacks and can then indicate support for IPv6 even though the SDP only
indicates support for IPv4, this may be far-fetched though..

> 
>  
> 
> In 2.2.2 the RS sends the multicast address in the RTCP 
> message. I think we discussed this in port mapping and there 
> was some consensus that RTCP should not be used to convey 
> addresses. Maybe the RS can allocate the addresses in the SDP 
> and in the RTCP just provide a label to the group
If I recall this correctly (sorry, have not been able to follow this
dicussion in detail) this is related to NAT traversal issues. The
multicast based RAMS differs in the aspect that the RR actively joins
the said address. On the other hand the SDP alternative you describe
above may also be an option esp. as I believe that this schema is most
attractive for the most popular channels. 

> 
>  
> 
> Regards
> 
> Roni Even 
> 
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: 
> <http://www.ietf.org/mail-archive/web/avt/attachments/20091101
/e1c983b5/attachment.htm>
> 
> ------------------------------
> 
> _______________________________________________
> Audio/Video Transport Working Group
> avt at ietf.org
> https://www.ietf.org/mailman/listinfo/avt
> 
> 
> End of avt Digest, Vol 67, Issue 1
> **********************************
>