[AVT] Question on SDP combining unicast and multicast addresses

Hello,

we are currently developing a solution for retransmission in DVB IPTV deployments. We have encountered an issue, on which we kindly ask for feedback.

The issue is the following: SDP currently says that it is not expected to combine unicast and multicast addresses. See S. 5.7:

   When the <addrtype> is IP4 and IP6, the connection address is defined
   as follows:

   o  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.

For the use case described in the quoted email below, IPTV SSM with unicast RTCP feedback and retransmission proxies co-located with the Feedback Targets, we do need to specify the unicast retransmission source in the multicast session SDP. Additionally, it is also interesting (though not mandatory) to use the same port for SSM RTCP unicast feedback and for retransmissions (for NAT traversal mainly). Taking all this into account: SSM session + RTCP unicast feedback + retransmission proxies + RTP/RTCP muxing... would the following be a valid pseudo-SDP?

    <session-description> 
    v=0
    o=The King <Elvis@example.com>
    s=Elvis Impersonation
    i=All Elvis, all the time
    u=http://www.example.com/ElvisLive/
    t=0 0
    c=IN IP4 <ssm-mc-address>/<TTL>

    <SSM mcast media-description> 
    m=video <media-sender-port> RTP/AVPF <media-sender-fmt>
    a=source-filter:incl IN IP4 <ssm-mc-addres> <media-sender-uc-address>  //IP SSMcast session
    a=ssrc:<media-sender-ssrc> cname:iptv-sender@example.com      //Media Sender info
    a=rtcp:<ft-port> IN IP4 <ft-unicast-address>            // Feedback Target IP,Port definition

    <RET repair-description> 
    m=video <ft-port> RTP/AVPF <rtx-fmt>
    c=IN IP4 <ft-unicast-address>                          //Unicast RET session
    a=fmtp:<rtx-fmt> apt=<media-sender-fmt>;rtx-time=<ms>  // RET config
    a=rtcp-mux                              //Muxing of RTP/RTCP

We also welcome any comments on the email below, of course.

Cheers,

José

> -----Original Message-----
> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On 
> Behalf Of Jose Rey
> Sent: Thursday, February 21, 2008 4:28 PM
> To: Colin Perkins; IETF AVT WG
> Cc: VAN CAENEGEM Tom; Jeff Goldberg
> Subject: Re: [AVT] Fwd: Retransmission and fast channel 
> change with usageofRTP/RTCP
> 
> Hi Colin, hi all,
> 
> regarding retransmission: DVB is currently developing a 
> solution for retransmission in VoD and live multicast IPTV 
> services. The unicast VoD scenario is rather simple. The 
> multicast one isn't, thus we would like to ask the community 
> for feedback.
> 
> The multicast solution is based on the draft specifying 
> unicast feedback for SSM. We intend to use up to two SSM 
> sessions (one for media, one optional for repair) plus one 
> unicast repair session per receiver. The Distribution Source 
> of the media session would be the network provider's head 
> end. The Distribution Source of the repair session is the 
> "retransmission proxy", typically located very near to the 
> customer, usually at the (IP)-DSLAM. The repair session is 
> used to mitigate correlated packet losses, affecting one or 
> several hundreds of users. Finally, the Feedback Target is 
> also co-located with the retransmission proxy. 
> 
> In the typical scenario as above, the correlated losses 
> happen upstream of the retransmission proxy, e.g., due to L2 
> protection switching. These losses are critical, as they can 
> cause NACK storms. In order to avoid these, an RTP client is 
> placed halfway down the of the media SSM tree, thus detecting 
> and reporting packet losses. "Halfway" means, in practice, at 
> the retransmission proxy. So, in the end, we have a 
> retransmission proxy that detects and reports upstream packet 
> loss, hosts the feedback target, and serves retransmissions 
> (both unicast and multicast). Each being a different logical 
> entity with a different SSRC. 
> 
> Now, since the RTP client at the retransmission proxy cannot 
> send its NACK in the media SSM group, it is proposed to send 
> these in the *repair* SSM through its Distribution Source, 
> i.e. the retransmission server, either as RFC-4585-NACKs or 
> in summarized RSI form. However, by doing this, we are mixing 
> the SSRC spaces of two different (but associated) sessions. 
> Also the retransmission client doesn't know what to do with 
> this feedback as it would just think the NACK is from another 
> *repair* client. 
> 
> A proposed solution for indicating the repair client what to 
> do with this forwarded NACK would be to use an additional SDP 
> attribute listing the SSRC of the RTP client (we would 
> indicate the SSRCs of the retransmission proxy and feedback 
> target as well). The repair clients would then know, by 
> looking at the SSRCs that it is a forwarded NACK from the 
> media SSM and that they must forward it to the media client 
> for NACK damping. The appropriate semantics would probably 
> have to be writen down in an I-D.
> 
> Now, that's one scenario. Another one, though less common, is 
> where losses happen dowstream of the retransmission proxy, 
> where it cannot detect them. We are still thinking about a 
> solution for that.
> 
> We would welcome feedback on this proposal or similar work 
> being done elsewhere. If anyone has a better idea, we would 
> of course consider it. 
> 
> Thanks,
> 
> José for Tom, Jeff and myself
> 
> > -----Original Message-----
> > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On 
> Behalf Of 
> > Colin Perkins
> > Sent: Saturday, February 16, 2008 7:23 PM
> > To: IETF AVT WG
> > Subject: [AVT] Fwd: Retransmission and fast channel change 
> with usage 
> > ofRTP/RTCP
> > 
> > The AVT working group has received the following liaison statement 
> > from TISPAN WG3 IPTV on Retransmission and fast channel change with 
> > usage of RTP/RTCP. The TISPAN working group asks for our 
> feedback on a 
> > number of issues. Please send any comments on this to the chairs by
> > 25 February, so we can draft a response.
> > 
> > Colin (as chair)
> > 
> > 
> > 
> > Begin forwarded message:
> > > From: "TISPANsupport" <TISPANsupport@etsi.org>
> > > Date: 12 February 2008 15:15:02 GMT
> > > To: <murield@microsoft.com>, <ralf.schaefer@thomson.net>, 
> > > <csp@csperkins.org>, <roni.even@polycom.co.il>, 
> > > <tom.taylor@rogers.com>, "Chantal Bonardi"
> > <chantal.bonardi@etsi.org>
> > > Cc: "TISPANsupport" <TISPANsupport@etsi.org>
> > > Subject: Retransmission and fast channel change with usage
> > of RTP/RTCP
> > >
> > > Good afternoon,
> > >
> > > Please find enclosed a liaison statement from TISPAN WG3 IPTV on 
> > > Retransmission and fast channel change with usage of RTP/RTCP.
> > >
> > > Thank you for your prompt feed-back on this LS.
> > >
> > > Date of Next WG3 IPTV Meeting 03-07 March 2008.
> > >
> > >
> > > Best regards,
> > > Helene Schmidt
> > > Technical Body Support
> > > ETSI Standardization Projects (ESP)
> > > 650, Route des Lucioles,
> > > FR - 06921 Sophia Antipolis
> > > Tel: +33 4 92 94 43 41
> > > http://portal.etsi.org
> > 
> > 
> 
> 
> Panasonic R&D Center Germany GmbH
> 63225 Langen, Hessen, Germany
> Reg: AG Offenbach (Hessen) HRB 33974
> Managing Director: Thomas Micke
> 
> 
> _______________________________________________
> Audio/Video Transport Working Group
> avt@ietf.org
> http://www.ietf.org/mailman/listinfo/avt
> 
> 

Panasonic R&D Center Germany GmbH
63225 Langen, Hessen, Germany
Reg: AG Offenbach (Hessen) HRB 33974
Managing Director: Thomas Micke

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