Subject: RE: [MMUSIC] video media control draft

From: "MONFORT Patrick FTRD/DMI/ISS" <[email-masked]>
Date: Fri, 26 Jul 2002 08:15:14 +0200

Yes, that would help.

As other things are needed, would it be possible to have/imagine an
attribute in the SDP (associated to media or the session) that can
manage all the "control" aspect of media. UA could listen on this
"control" port to receive command from other(s) party(ies).

Or else, if we don't want to manage a new port, I think we will have a
new SIP message that will carry a new SDP with constraints on it (like
to update only attribute of the declared media) ?

-----Original Message-----
From: Colin Perkins [mailto:[email-masked]]
Sent: mercredi 24 juillet 2002 22:38
To: MONFORT Patrick FTRD/DMI/ISS
Cc: Joerg Ott; Orit Levin; [email-masked]
Subject: Re: [MMUSIC] video media control draft 

--> "MONFORT Patrick FTRD/DMI/ISS" writes:
...deleted...
>Regarding the control, RFC 2032 (which describes RTCP packet for
>IntraRequest) can't be deployed. The reason is that these RTCP packets
>are not sent to the 'standard' RTCP Port.
>
>Here are the text taken from RFC 2032, that explains this issue
(section
>5.1):
>
>"
>The H.261-specific control packets differ from normal RTCP packets in
>   that they are not transmitted to the normal RTCP destination
>   transport address for the RTP session (which is often a multicast
>   address).  Instead, these control packets are sent directly via
>   unicast from the decoder to the coder.  The destination port for
>   these control packets is the same port that the coder uses as a
>   source port for transmitting RTP (data) packets.  Therefore, these
>   packets may be considered "reverse" control packets.
>
>   As a consequence, these control packets may only be used when no RTP
>   mixers or translators intervene in the path from the coder to the
>   decoder.  If such intermediate systems do intervene, the address of
>   the coder would no longer be present as the network-level source
>   address in packets received by the decoder, and in fact, it might
not
>   be possible for the decoder to send packets directly to the coder.
>"

The proposal is to use the same FIR packet format as in RFC 2032, but to
send the request to the standard RTCP port, using the mechanisms from
draft-ietf-avt-rtcp-feedback-03.txt to ensure timely feedback. Would 
that help?

Colin

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Colin Perkins <[email-masked]>
Date: Fri, 26 Jul 2002 13:45:32 -0400

I'm not sure we agree on the list of other things are needed. Some form of
fast intro request, certainly, but what else? Freeze has been discussed,
but that may not be necessary. Are there others?

Colin