Re: [MMUSIC] Signaling FIR/Freeze in SIP

[Joerg Ott <[e-mail]>]

Orit and all,

I have gone through a number of scenarios and, apparently, one particular
case of H.323-SIP interworking (namely if an H.323 endpoint is connected
via a piece of SIP in the middle to a SIP- or H.323-based MCU) is not
workable at all with just RTCP.  So, what we are doing right now is
solely for the purpose of interworking.

Your proposal to provide a description of the actual event information
to be conveyed has merit -- particularly as it can be discussed 
independently of the transport used later on to carry it.  In addition,
we obviously need to define a MIME type for this data format.

I would like to encourage you to think a bit beyond the pure video
conferencing applications as it would be perfect if we could keep
whatever we come up with right now and build on this for the future
rather than having two or more mechanisms to deal with eventually.

As for the transport: you know that I am very much opposed to tunneling
in SIP INFO, so I'd still like to research other ways -- even within
SIP -- to carry this contents.  Basically, what you want to do is
have the MCU provide an endpoint with an indication/command that a
new intra frame is needed.  Can this information be derived from a
(slightly extended) conference event package or modeled as a different
application-specific event package?  After all, the intra frame is
triggered by a change in the "viewer status" (who sees the video of
the endpoint) which should be watchable in some way.

From what Roni and myself have discussed, the conference package is
insufficient insofar as the send-status types defined so far
("received-by-all", "muted", "unknown") do not allow to reflect the
transition you are interested in.  Adding "received-by-one" would
solve only part of the problem.  But a meaningful addition may make
sense to be explored here (and obtain all you need from a mechanism
already under development).  A SIP MCU is likely to support the
conference package anyway.

Of course, any SIP-H.323 gateway would need to be aware that the
user is connected to a conference and subscribe to the respective
state.  But, on the other hand, it would need to translate SIP INFO
into some H.323 stuff, too.  So while being potentially cleaner,
using SUBSCRIBE/NOTIFY is not worse from the backwards compatibility
point of view.

Thoughts?

Joerg

> Since, there is no agreement to standardize the required primitives within
> the old SDP and taking into account all the drawbacks of such a solution,
> there is no point pursuing this direction.
> 
> Instead, we need two things:
> 1. Working on a new point-to-point media control protocol
> 2. Agree on a doable way (such as INFO) to convey the required primitives in
> the call signaling path. It doesn't have to be a standard.
> 
> For all the practical reasons, multimedia vendors will need to support both.
> 
> We (as RADVISION together with its partners) already have a simple
> extensible XML scheme to be conveyed in the INFO messages for exactly this
> purpose. I plan to publish it as an IETF draft shortly.
> 
> BR,
> Orit Levin
> Chief Architect
> RADVISION Inc.
> Tel:  [phone]
> 
>  -----Original Message-----
> From:   Nils Henrik Lorentzen [mailto:[e-mail]]
> Sent:   Wednesday, July 31, 2002 6:04 AM
> To:     [e-mail]
> Subject:        [MMUSIC] Signaling FIR/Freeze in SIP
> 
> Hi,
> 
> We at TANDBERG would like to voice our opinion on the full intra/freeze
> request issue, as the decision made may affect us in the future.
> 
> There are as far as we can see three proposed solutions to the problem of
> signaling these requests within the SIP framework:
> 
> 1. Use RTCP
> 2. Use SDP
> 3. Some kind of new protocol tunneled in INFO or a similar SIP method.
> 
> Our opinion so far:
> 
> 1. This is in our opinion the best solution from a design perspective. We
> see
> it this way: Keeping a good quality video stream and output is an issue
> between the encoder and decoder, thus information for that purpose should be
> 
> sent directly between them. Ideally it should not be sent along the
> signaling
> path, but along the media path.
> 
> There seems to be two main arguments against the RTCP solution:
> 
> - RTCP is not reliable.
> We agree with Colin, in that this is a non-issue. The FIR message could be
> retransmitted until a full intra is received. As for freeze requests, these
> could be retransmitted a predefined number of times with a predefined
> interval. If any of them arrive at the decoder all is fine. In the rare case
> 
> where none do, the user will see some ugly video output for a relatively
> small amount of time, until it receives a full intra, but it will not
> otherwise affect the call.
> There may be issues here we have not thought of, though.
> 
> - H.323 EPs do not support these new RTCP packets. We think this is more of
> an issue. As Roni pointed out, a SIP/H.323 signaling GW would not be able to
> 
> gather the FIR requests from the SIP side and pass it on to the H.323 side,
> unless it is also acts as GW for the RTP/RTCP traffic. The latter is of
> course not ideal, but could do as a temporary solution. One would probably
> need to add a new option flag to H.323 call setup messages telling whether
> the endpoint supports FIR/freeze in RTCP.
> 
> 2. Using a media attribute in SDP for signaling a FIR is wrong in our
> opinion. SDPs are for telling what kind of streams you want from the time
> you
> send it until the next time you send an SDP.  A full intra is a request that
> 
> is executed only once when received.
> 
> We believe the following can be used as a "litmus test" for determining what
> 
> information is OK to send in SDP and what is not:
> 
> If an endpoint sends the exact same SDP to another endpoint several times in
> 
> sequence, only the first SDP arriving at remote should trigger any
> change/sideeffects.
> 
> This holds true in for example hold/resume but not for full intra req.
> 
> 3. This is in our opinion not the ideal solution from a design POV, but it
> will interoperate better with existing H.323 EPs when SIP/H323 GWs are
> implemented. It would require a new protocol to be defined., but could be a
> very simple and limited protocol though, as it would just be a temporary
> solution.
> We would possibly need a new such protocol when SDPng arrives, since we have
> 
> to refer to a SDPng media channel in a different manner than refering to an
> SDP channel.
> 
> To conclude, we support solutions 1 and 3, while 2 is definitely the worst
> alternative. While using RTCP (or similar protocol directly between
> encoder/decoder) is in our opinion the cleanest solution, 3 might be used if
> 
> the SIP/H.323 switching problem is deemed important enough and no other
> problems with using RTCP are found.
> 
> Nils Henrik Lorentzen
> 
> Software Developer
> TANDBERG
> http://www.tandberg.net
> 
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/mmusic
> 
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/mmusic

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