Subject: [MMUSIC] Signaling FIR/Freeze in SIP

From: Nils Henrik Lorentzen <[email-masked]> (by way of Nils Henrik Lorentzen <[email-masked]>)
Date: Wed, 31 Jul 2002 12:03:33 +0200

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic