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

[Magnus Westerlund <[e-mail]>]

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



> Following up on this, for the 2nd question: Tying the token to the rtcp-fb line does not seem much right, either. For example, rtcp-fb line in the multicast media block has nothing to do with RAMS-T.

I said that the design of the attribute on which RTCP messages requires
token could be done along the lines of the rtcp-fb attribute. Not that
it should be tied to the SDP Attribute. I would say that the portmapping
attribute is related to the RTCP sent for a particular RTP session.
Independent of how that RTCP destination is indicated.

> 
> We tried to be as explicit as possible in section 4.3 and left the door open for future possible additions to the list of messages that require or might require a Token. If that does not look good, we are open to suggestions.
> 

That is why an explicit indication of what RTCP messages this server
expects to have included a token seems reasonable. Although we need to
have an extensible mechanism that can support any future RTCP messages.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------