Subject: Re: [MMUSIC] RTSP session renegotiation

From: Magnus Westerlund <[email-masked]>
Date: Mon, 20 Nov 2006 15:39:56 +0100

valeria calcagni skrev:
> Dear all,
> I�m actually doing researches on how it would be possible to renegotiate an 
> already established session when the characteristics of the link radio changes 
> over time.
> In RFC 2326 it�s stated that for fixed networks, a new SETUP request should be 
> issued by the client for this purpose, can you confirm it?  
> It also stated that: �The server generates session identifiers in response to 
> SETUP requests. If a SETUP request to a server includes a session identifier, 
> the server MUST bundle this setup request into the existing session or return 
> error 459 Aggregate Operation Not Allowed�, but this is not against with what is 
> stated in section 12 regarding the usage of Session header:               � 
> Session    Rr     req.      all but SETUP, OPTIONS�?
> Should in the scenario described above the new SETUP contain a new SDP body or 
> only the Transport Header updated accordingly?
> 
> Talking about wireless environment, if the radio link characteristics change 
> over time causing a renegotiation of the an already established session, which 
> is the most appropriate message to use? SETUP or SET_Parameter? Are they two 
> equivalent implementations?
> 
> I�d really appreciate if you can help me to find the correct answers to my 
> questions.
> 

Hi,

One very late comment on this topic. In most cases I don't think there 
exist any need to renegotiate the transport parameters simply because of 
changing link characteristics. Such changes should be detected and 
reacted to based on the used transport protocols feedback. In the case 
of RTP/UDP then RTCP should be monitored to ensure that the sender is 
not substantially trying to overtax the network.

cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

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

---

From: Randell Jesup <[email-masked]>
Date: Mon, 20 Nov 2006 12:11:00 -0500

Magnus Westerlund <[email-masked]> writes:
>changing link characteristics. Such changes should be detected and reacted
>to based on the used transport protocols feedback. In the case of RTP/UDP
>then RTCP should be monitored to ensure that the sender is not
>substantially trying to overtax the network.

If link bandwidth has decreased significantly then renegotiation of the
connection may be in order, to reduce framerate, resolution or increase
compression ratio (such as switching codecs), instead of waiting until the
stream begins to fail and it's reported by RTCP.  And increased bandwidth
won't ever be noticed by RTCP - again renegotiation may be in order.

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
[email-masked]
"The fetters imposed on liberty at home have ever been forged out of the weapons
provided for defence against real, pretended, or imaginary dangers from abroad."
		- James Madison, 4th US president (1751-1836)

---

From: Colin Perkins <[email-masked]>
Date: Mon, 20 Nov 2006 17:23:47 +0000

On 20 Nov 2006, at 17:11, Randell Jesup wrote:
>> reacted

While I agree that renegotiating the connection is possible, and even  
necessary in some cases, it's a very heavy-weight solution compared  
to sending an (early) RTCP packet to report on link characteristics,  
and the sender reacting to that.

Colin

---

From: Randell Jesup <[email-masked]>
Date: Mon, 20 Nov 2006 14:44:26 -0500

Colin Perkins <[email-masked]> writes:
>> compression ratio (such as switching codecs), instead of waiting until
>> the stream begins to fail and it's reported by RTCP.  And increased
>> bandwidth won't ever be noticed by RTCP - again renegotiation may be in
>> order.
>
>necessary in some cases, it's a very heavy-weight solution compared  to
>sending an (early) RTCP packet to report on link characteristics,  and the
>sender reacting to that.

Agreed, if such packets are defined, which they aren't currently that I
know of (some proposals have been heading in that direction, though I think
those were tied to mechanisms that were controversial (header extensions in
one case, and RTCP-without-SR/RR in the other).

Also, for some codecs you may have to re-invite the change the parameters
or codecs (H.264 can only use parameter sets previously defined at setup or
by an out-of-band reliable protocol; you can't change them in-line in RTP).
For H.263, while it's slightly less clear, I think some types of
adjustments would need re-INVITE.  (For example, if the client communicated
their downstream bandwidth had halved, and currently you're sending
CIF@15fps, should the sender go to [email-masked], or QCIF@15fps (or perhaps
higher)?)  Or switch from high-resolution/low-CPU-use H.263 to
lower-resolution/bandwidth (but higher quality per bit and higher CPU) H.264?

I think (as you may be suggesting) that both mechanisms are useful.  The
interactions of RTCP-based bandwidth modification with QoS gets
interesting, since the QoS mechanism may well only be on the signalling
path.

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 21 Nov 2006 09:40:31 +0100

Hi,

I think we have some disconnect about what part of the protocol you are 
suggesting to exercise. I interpret it as having an established RTSP 
session with one or more media streams. Then the receiver detects some 
link change making the current media stream less suitable for delivery. 
Then I interpreted that as you suggested that the client should send a 
SETUP for the same media resource but change the transport parameters to 
address this.

My comment to this is that SETUP does not contain any of the media 
configuration parameters that may be needed to change the media stream 
from one configuration to another. Thus SETUP is pretty useless for 
doing media adaptation. The thing you might do is to change the media 
stream being delivered. However that is really heavy weight operation. 
And to my knowledge non of the used media adaptation schemes are using 
this.

In addition comparing SETUP with SIP Invite is a bad match. Where the 
INVITE + SDP do two things, configure media and transport parameters 
SETUP only configures transport parameters. The media configuration 
happens through the declarative SDP received through a DESCRIBE or other 
out-of-band mechanism. Thus to perform a media re-configuration after 
the initial SDP has been delivered requires some way to deliver it 
during the session. This is currently not standardized even if it has 
been proposed. Therefore if one is interested in the adaptation problem 
then one normally ensures that one media configuration supports all the 
possible variants of a particular content one has available. Thus 
enabling the server to select which stream from multiple (encoding) 
alternatives to deliver. In other word what is called stream switching. 
And as long as done correctly this can be done fully standards compliant.

The only time I think this get some what complicated is if one tries to 
cover from like Full SD TV range down to 20kbps QCIF for a video and are 
not using the right codec. There are some media codec limitations that 
makes things difficult. But then in most cases you will also have the 
distribute new media configuration problem.

Cheers

Magnus Westerlund