Subject: RE: [MMUSIC] video media control draft

From: "Even, Roni" <[email-masked]>
Date: Sun, 28 Jul 2002 10:07:17 +0300

Colin,
I think that you responses are missing the point. The RTP and RTCP can give
INDICATIONS about the status of the call but they were not meant to serve as
requests for changing the stream state and flow. Furthermore the RTP and
RTCP are unreliable channels and that prevent them from being used for the
requests we want. We want to have a way to request state change and stream
flow change in the signalling protocol since this is done by the call
management application and not by the encoder/decoder!!!.
We need a solution that will be available in SIP and that means SDP or INFO
method. Developing a  new control protocols will take too long or maybe you
want to suggest that we will use H.245 which is tunneled today in H.323 in
the call setup channel.
Regards
Roni Even

> -----Original Message-----
> From: Colin Perkins [mailto:[email-masked]]
> Sent: Friday, July 26, 2002 8:46 PM
> 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
> 

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

---

From: Colin Perkins <[email-masked]>
Date: Sun, 28 Jul 2002 12:38:01 -0400

Roni,

>management application and not by the encoder/decoder!!!.

I disagree with your characterisation of RTCP. 

I believe RTCP is more appropriate for your needs, since you are requesting
a change in the encoder operation (to send a full intra frame). Controlling
the state of the encoder based on feedback from the receivers would seem to
fit very well with the RTCP model.

Reliability is a non-issue, since you can resend the message if the codec
hasn't changed its behaviour in a reasonable time. 

>want to suggest that we will use H.245 which is tunneled today in H.323 in

I believe Jonathan Rosenberg described why SIP/SDP are not the appropriate
solutions here. What you are requesting is not a change to the call state,
it's a request to the encoder. As such, it should be sent to the encoder.

Colin