Re: [AVT] draft-ietf-avt-ports-for-ucast-mcast-rtp-06: SDP attribute usage of port-mapping-req

["Ali C. Begen (abegen)" <[e-mail]>]

> -----Original Message-----
> From: Magnus Westerlund [mailto:[e-mail]]
> Sent: Thursday, December 09, 2010 8:48 AM
> To: Ali C. Begen (abegen)
> Cc: IETF AVT WG
> Subject: Re: [AVT] draft-ietf-avt-ports-for-ucast-mcast-rtp-06: SDP attribute usage of port-mapping-req
> 
> Ali C. Begen (abegen) skrev 2010-12-09 14:26:
> > On the 1st issue: I remember this coming up at some point (maybe it was you or somebody else). And you are right, the
> current text in section 7.1 and the example in 7.3 indicate that the 'portmapping-req' goes into the unicast media block (if
> used at media level).
> >
> > The reasoning was:
> > - There could be multiple associated unicast sessions for each SSM session, and in that case specifying this separately made
> more sense
> > - The messages we bundle with the Token (such as RAMS-R, RAMS-T, BYE, CCM, etc.) are actually related to the unicast
> stream not the multicast stream. Well, you could argue that RAMS-R starts the burst for a multicast stream but I could argue
> that it starts *the* unicast stream. OTOH, RAMS-T directly controls the unicast stream has nothing to do with the multicast,
> so does the BYE for the unicast session.
> >
> 
> I would argue that RAMS should actually include the portmapping-req in
> both the unicast and the multicast session as you require it in both
> RTCP usages. That I think would be the best way of handling rams. That
> would mean an example like this:
> 
>         v=0
>         o=ali 1122334455 1122334466 IN IP4 rams.example.com
>         s=Rapid Acquisition Example
>         t=0 0
>         a=group:FID 1 2
>         a=rtcp-unicast:rsi
>         m=video 41000 RTP/AVPF 98
>         i=Primary Multicast Stream
>         c=IN IP4 233.252.0.2/255
>         a=source-filter:incl IN IP4 233.252.0.2 198.51.100.1
>         a=rtpmap:98 MP2T/90000
>         a=multicast-rtcp:42000
>         a=rtcp:43000 IN IP4 192.0.2.1
>         a=rtcp-fb:98 nack
>         a=rtcp-fb:98 nack rai
> 	a=portmapping-req:30000 IN IP4 192.0.2.1
>         a=ssrc:123321 cname:[e-mail]
>         a=rams-updates
>         a=mid:1
>         m=video 51000 RTP/AVPF 99
>         i=Unicast Retransmission Stream (Ret. and Rapid Acq. Support)
>         c=IN IP4 192.0.2.1
>         a=sendonly
>         a=rtpmap:99 rtx/90000
>         a=rtcp-mux
> 	a=portmapping-req:30000 IN IP4 192.0.2.1
>         a=fmtp:99 apt=98;rtx-time=5000
>         a=mid:2
> 

I see what you are trying to do here but as I said not all RTCP messages relating to the multicast stream or session need to have a Token. So, having the portmapping-req line in the multicast media block is probably more confusing. 

I am aware that using it only in the unicast media block is not perfect, either, but at least it is more correct and less confusing. Every RTCP message that requires a Token has something to do with the unicast session but not necessarily with the multicast session.

So, I am still inclined to keep the text and example as they are.

Cheers, acbegen.