Subject: RE: [MMUSIC] video media control draft

From: "MONFORT Patrick FTRD/DMI/ISS" <[email-masked]>
Date: Mon, 5 Aug 2002 10:20:31 +0200

Hello,

Th draft I mentioned in a previous mail
"draft-koskelainen-sdp263-02.txt" deals with SIZE and OPTIONS of video
codec. How do you propose the manage them during a call.

All thoses things are in the stream itself, but, a Video UA need a way
to express them during the initiation of the call and to control them
during the call.

Thanks,

Patrick,

-----Original Message-----
From: Colin Perkins [mailto:[email-masked]]
Sent: vendredi 26 juillet 2002 19:46
To: MONFORT Patrick FTRD/DMI/ISS
Cc: [email-masked]
Subject: Re: [MMUSIC] video media control draft 

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

--> "MONFORT Patrick FTRD/DMI/ISS" writes:
>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: Mon, 05 Aug 2002 16:08:58 -0400

That would seem to be something for the signalling protocol, since it
changes the media format. It's not clear to me that this information
can cleanly be siganlled in SDP though, it may be better suited to an
SDPng expression?

Colin

---

From: Joerg Ott <[email-masked]>
Date: Mon, 5 Aug 2002 22:20:35 +0200 (MEST)

> can cleanly be siganlled in SDP though, it may be better suited to an

That's the idea.  And as discussed at the last IETF, we start looking
into a video profile right now.  Depending on the video conferencing
requirements, you may need a few (trivial) parameters in SDP though.

Joerg