Subject: [MMUSIC] Mixing aggregate and non-aggregate control (long)

From: Jonathan Sergent <[email-masked]>
Date: Fri, 25 Jan 2002 14:40:11 -0800

We began to identify some issues with mixing various combinations of
aggregate control, non-aggregate control, queued play and "muting" in
the same session during the last RTSP conference call.  I wrote this up
to try to explain some of the conflicts between the way these features
are defined in the RFC.  The initial connection setup is the same for
all of the scenarios.  There are 13 scenarios, which seems fitting.

If this is too much for you to digest, you can skip to the end, where I
have outlined some proposed resolutions to the problems as I see them.

Please let me know where my mistakes are...

Thanks in advance,

-- 
Jonathan Sergent / [email-masked]

Initial connection setup is as follows:

--------------------------------------------------------------------
C->S
DESCRIBE rtsp://host/a RTSP/1.0
Cseq: 1
Accept: application/sdp

--------------------------------------------------------------------
S->C
RTSP/1.0 200 OK
Cseq: 1
Content-Type: application/sdp
Content-Base: rtsp://host/a/
Content-Length: 190

v=0
o=jsergent 1 8750 IN IP4 129.146.81.112
s=Example
c=IN IP4 0/32
t=3162748440 0
a=control:*
a=range:npt=0-60
m=audio 0 RTP/AVP 5
a=control:b
a=ptime:40
m=video 0 RTP/AVP 26
a=control:c
--------------------------------------------------------------------
C->S
SETUP rtsp://host/a/b RTSP/1.0
Cseq: 2
Transport: RTP/AVP/UDP;unicast;client_port=5004-5005

--------------------------------------------------------------------
S->C
RTSP/1.0 200 OK
Cseq: 2
Session: ZZEfpZ0zxK5
Transport: RTP/AVP/UDP;unicast;client_port=5004-5005;server_port=65118-65119

--------------------------------------------------------------------
C->S
SETUP rtsp://host/a/c RTSP/1.0
Cseq: 3
Session: ZZEfpZ0zxK5
Transport: RTP/AVP/UDP;unicast;client_port=5006-5007

--------------------------------------------------------------------
S->C
RTSP/1.0 200 OK
Cseq: 3
Session: ZZEfpZ0zxK5
Transport: RTP/AVP/UDP;unicast;client_port=5006-5007;server_port=65118-65119

--------------------------------------------------------------------


Scenario #1: Normal aggregate control
Initial connection setup, followed by:
--------------------------------------------------------------------
C->S
PLAY rtsp://host/a/ RTSP/1.0
Cseq: 4
Session: ZZEfpZ0zxK5
Range: npt=0-

--------------------------------------------------------------------
S->C (time = t)
RTSP/1.0 200 OK
Cseq: 4
Session: ZZEfpZ0zxK5
RTP-Info: url=rtsp://host/a/b;seq=15914;rtptime=420914,
          url=rtsp://host/a/c;seq=16778;rtptime=1946900992

--------------------------------------------------------------------

This is the normal aggregate control scenario.  Both streams are sent,
in sync, to the client.


Scenario #2: Mixed non-aggregate control on "aggregate presentation"
Initial connection setup, followed by:
--------------------------------------------------------------------
C->S
PLAY rtsp://host/a/b RTSP/1.0
Cseq: 4
Session: ZZEfpZ0zxK5
Range: npt=0-10

--------------------------------------------------------------------
S->C (at time t)
RTSP/1.0 200 OK
Cseq: 4
Session: ZZEfpZ0zxK5
RTP-Info: url=rtsp://host/a/b;seq=15914;rtptime=420914

--------------------------------------------------------------------
C->S (before time t+10)
PLAY rtsp://host/a/c RTSP/1.0
Cseq: 5
Session: ZZEfpZ0zxK5
Range: npt=0-10

--------------------------------------------------------------------
S->C (before time t+10)
RTSP/1.0 200 OK
Cseq: 5
Session: ZZEfpZ0zxK5
RTP-Info: url=rtsp://host/a/c;seq=16778;rtptime=1946900992

--------------------------------------------------------------------

This is the scenario that bug #? mentions.  The question is what the
second PLAY request should do.  My interpretation of the RFC, as
currently written, is that this play should be queued, so that the
result is that the server streams the first ten seconds of the audio,
immediately transitions, and then streams the first ten seconds of the
video.

There is nothing in the RFC to suggest that you cannot start playing
using PLAY of a single stream even if you have done SETUP for multiple
streams.  (Perhaps I am missing something...)

Assuming that queued play is reasonable (which it might not be, but
that is another discussion), this scenario actually seems somewhat
reasonable.  (For example, it's feasible that a more advanced
description format than SDP might be able to indicate to the client
that two streams are meant for sequential rather than simultaneous
viewing.)

Issues:
(1) Does queued play make sense?  Should we remove it entirely?
(2) If multiple streams have been setup, should PLAY with a range
    header be permitted for an individual stream URL rather than the
    entire presentation URL?  Pure non-aggregate control would still be
    permitted, but each stream would need to be in its own
    presentation.
(3) Should there be a queue for each URL used with PLAY, or one
    queue for each RTSP session?  If the queue is per-URL instead of
    per-session, then it is unclear what do do if the client PAUSEs
    a different URL than it PLAYed.


Scenario #3: Mixed non-aggregate control without range headers
Initial connection setup, followed by:
--------------------------------------------------------------------
C->S
PLAY rtsp://host/a/b RTSP/1.0
Cseq: 4
Session: ZZEfpZ0zxK5
Range: npt=0-10

--------------------------------------------------------------------
S->C (at time t)
RTSP/1.0 200 OK
Cseq: 4
Session: ZZEfpZ0zxK5
RTP-Info: url=rtsp://host/a/b;seq=15914;rtptime=420914

--------------------------------------------------------------------
C->S (before time t+10)
PLAY rtsp://host/a/c RTSP/1.0
Cseq: 5
Session: ZZEfpZ0zxK5

--------------------------------------------------------------------

I do not know what the server should do in this case.

I see a few options.
i.   Play the first ten seconds of the audio, then immediately transition
     to the video.  The video plays for the range "npt=10-".
ii.  Play the first ten seconds of the audio, then immediately transition
     to the video.  The video plays for the range "npt=0-".
iii. This is a liveness ping (as in section 10.5).  The language at the
     bottom of page 34 says "a stream" but does not say that the stream
     you send the PLAY request for must be the one that is playing.
iv.  Add the video stream in sync with the audio stream when the PLAY
     arrives.  (This might be useful, but the spec doesn't seem to endorse
     it.)
v.   Error.

Issues:
(4)  Does a liveness ping (as in section 10.5) require the specified URL
     to be the same as the one that is currently playing?
(5)  Is it possible to queue a PLAY with no time range?  (probably.)
(6)  Is there one pause point for each URL used with PLAY or one for
     each RTSP session, in the case where different URLs are used with PLAY?


Scenario #4:
Initial connection setup, followed by:
--------------------------------------------------------------------
C->S
PLAY rtsp://host/a/b RTSP/1.0
Cseq: 4
Session: ZZEfpZ0zxK5
Range: npt=0-10

--------------------------------------------------------------------
S->C (at time t)
RTSP/1.0 200 OK
Cseq: 4
Session: ZZEfpZ0zxK5
RTP-Info: url=rtsp://host/a/b;seq=15914;rtptime=420914

--------------------------------------------------------------------
C->S (after time t+10)
PLAY rtsp://host/a/c RTSP/1.0
Cseq: 5
Session: ZZEfpZ0zxK5

--------------------------------------------------------------------

I do not know what the server should do in this case.

I see similar options to scenario #3.
i.   Play the first ten seconds of the audio, then immediately transition
     to the video.  The video plays for the range "npt=10-".
ii.  Play the first ten seconds of the audio, then immediately transition
     to the video.  The video plays for the range "npt=0-".

Issues:
(7)  Is the answer to #6 any different when the PLAY request is not
     queued?  Hopefully not.


Scenario #5:
Initial connection setup, followed by:
--------------------------------------------------------------------
C->S
PLAY rtsp://host/a/ RTSP/1.0
Cseq: 4
Session: ZZEfpZ0zxK5
Range: npt=0-

--------------------------------------------------------------------
S->C (time = t)
RTSP/1.0 200 OK
Cseq: 4
Session: ZZEfpZ0zxK5
RTP-Info: url=rtsp://host/a/b;seq=15914;rtptime=420914,
          url=rtsp://host/a/c;seq=16778;rtptime=1946900992

--------------------------------------------------------------------
C->S (time = t + 5)
PAUSE rtsp://host/a/b RTSP/1.0
Cseq: 5
Session: ZZEfpZ0zxK5

--------------------------------------------------------------------
S->C
RTSP/1.0 200 OK
Cseq: 5
Session: ZZEfpZ0zxK5

--------------------------------------------------------------------
C->S (time = t + 30)
PLAY rtsp://host/a/b RTSP/1.0
Cseq: 6
Session: ZZEfpZ0zxK5

--------------------------------------------------------------------
S->C
RTSP/1.0 200 OK
Cseq: 6
Session: ZZEfpZ0zxK5

--------------------------------------------------------------------

See second sentence of section 10.6.  The server plays the entire
presentation except that the audio is "muted" from time 5 until time
30.


Scenario #6:
Initial connection setup, followed by:
--------------------------------------------------------------------
C->S
PLAY rtsp://host/a/ RTSP/1.0
Cseq: 4
Session: ZZEfpZ0zxK5
Range: npt=0-30

--------------------------------------------------------------------
S->C (time = t)
RTSP/1.0 200 OK
Cseq: 4
Session: ZZEfpZ0zxK5
RTP-Info: url=rtsp://host/a/b;seq=15914;rtptime=420914,
          url=rtsp://host/a/c;seq=16778;rtptime=1946900992

--------------------------------------------------------------------
C->S (time = t + 1)
PLAY rtsp://host/a/ RTSP/1.0
Cseq: 5
Session: ZZEfpZ0zxK5
Range: npt=45-60

--------------------------------------------------------------------
S->C
RTSP/1.0 200 OK
Cseq: 5
Session: ZZEfpZ0zxK5
RTP-Info: url=rtsp://host/a/b;seq=16664;rtptime=660914,
          url=rtsp://host/a/c;seq=18578;rtptime=1949600992

--------------------------------------------------------------------

This is normal queued play.  The server plays the presentation for the
first thirty seconds, then immediately jumps 15 seconds ahead and plays
the last fifteen seconds, then pauses.


Scenario #7:
Initial connection setup, followed by:
--------------------------------------------------------------------
C->S
PLAY rtsp://host/a/ RTSP/1.0
Cseq: 4
Session: ZZEfpZ0zxK5
Range: npt=0-30

--------------------------------------------------------------------
S->C (time = t)
RTSP/1.0 200 OK
Cseq: 4
Session: ZZEfpZ0zxK5
RTP-Info: url=rtsp://host/a/b;seq=15914;rtptime=420914,
          url=rtsp://host/a/c;seq=16778;rtptime=1946900992

--------------------------------------------------------------------
C->S (time = t + 1)
PLAY rtsp://host/a/ RTSP/1.0
Cseq: 5
Session: ZZEfpZ0zxK5
Range: npt=45-60

--------------------------------------------------------------------
S->C
RTSP/1.0 200 OK
Cseq: 5
Session: ZZEfpZ0zxK5
RTP-Info: url=rtsp://host/a/b;seq=16664;rtptime=660914,
          url=rtsp://host/a/c;seq=18578;rtptime=1949600992

--------------------------------------------------------------------
C->S (time = t + 10)
PAUSE rtsp://host/a/ RTSP/1.0
Cseq: 6
Session: ZZEfpZ0zxK5

--------------------------------------------------------------------
S->C
RTSP/1.0 200 OK
Cseq: 6
Session: ZZEfpZ0zxK5

--------------------------------------------------------------------

This is like #6, except that the PAUSE request stops the streaming
immediately and cancels the PLAY request with Cseq 5.


Scenario #8:
Initial connection setup, followed by:
--------------------------------------------------------------------
C->S
PLAY rtsp://host/a/ RTSP/1.0
Cseq: 4
Session: ZZEfpZ0zxK5
Range: npt=0-30

--------------------------------------------------------------------
S->C (time = t)
RTSP/1.0 200 OK
Cseq: 4
Session: ZZEfpZ0zxK5
RTP-Info: url=rtsp://host/a/b;seq=15914;rtptime=420914,
          url=rtsp://host/a/c;seq=16778;rtptime=1946900992

--------------------------------------------------------------------
C->S (time = t + 1)
PLAY rtsp://host/a/ RTSP/1.0
Cseq: 5
Session: ZZEfpZ0zxK5
Range: npt=45-60

--------------------------------------------------------------------
S->C
RTSP/1.0 200 OK
Cseq: 5
Session: ZZEfpZ0zxK5
RTP-Info: url=rtsp://host/a/b;seq=16664;rtptime=660914,
          url=rtsp://host/a/c;seq=18578;rtptime=1949600992

--------------------------------------------------------------------
C->S (time = t + 10)
PAUSE rtsp://host/a/b RTSP/1.0
Cseq: 6
Session: ZZEfpZ0zxK5

--------------------------------------------------------------------
S->C
RTSP/1.0 200 OK
Cseq: 6
Session: ZZEfpZ0zxK5

--------------------------------------------------------------------

This should mute the audio at t+10.  But should it cancel the queued
play request from Cseq 5?  "A PAUSE request discards all queued PLAY
requests."

Issues:
(8) Does PAUSE discard all queued PLAY requests, or does it only do so
    if the URL specified is the one that is currently playing?


Scenario #9
Initial connection setup, followed by:
--------------------------------------------------------------------
C->S
PLAY rtsp://host/a/b RTSP/1.0
Cseq: 4
Session: ZZEfpZ0zxK5
Range: npt=0-10

--------------------------------------------------------------------
S->C (at time t)
RTSP/1.0 200 OK
Cseq: 4
Session: ZZEfpZ0zxK5
RTP-Info: url=rtsp://host/a/b;seq=15914;rtptime=420914

--------------------------------------------------------------------
C->S (before time t+10)
PLAY rtsp://host/a/c RTSP/1.0
Cseq: 5
Session: ZZEfpZ0zxK5
Range: npt=0-10

--------------------------------------------------------------------
S->C (before time t+10)
RTSP/1.0 200 OK
Cseq: 5
Session: ZZEfpZ0zxK5
RTP-Info: url=rtsp://host/a/c;seq=16778;rtptime=1946900992

--------------------------------------------------------------------
C->S (before time t+10)
PAUSE rtsp://host/a/c RTSP/1.0
Cseq: 6
Session: ZZEfpZ0zxK5

--------------------------------------------------------------------
S->C (before time t+10)
RTSP/1.0 200 OK
Cseq: 6
Session: ZZEfpZ0zxK5

--------------------------------------------------------------------

Isn't this getting tiresome by now?  Good for you if you read this
far.

This is scenario #2 with a PAUSE appended.

This PAUSE should clearly cancel the queued PLAY from Cseq 5.  But
should it PAUSE the currently executing PLAY from Cseq 4?  This is
another facet of issue #8.


Scenario #10
Initial connection setup, followed by:
--------------------------------------------------------------------
C->S
PLAY rtsp://host/a/b RTSP/1.0
Cseq: 4
Session: ZZEfpZ0zxK5
Range: npt=0-10

--------------------------------------------------------------------
S->C (at time t)
RTSP/1.0 200 OK
Cseq: 4
Session: ZZEfpZ0zxK5
RTP-Info: url=rtsp://host/a/b;seq=15914;rtptime=420914

--------------------------------------------------------------------
C->S (before time t+10)
PLAY rtsp://host/a/c RTSP/1.0
Cseq: 5
Session: ZZEfpZ0zxK5
Range: npt=0-10

--------------------------------------------------------------------
S->C (before time t+10)
RTSP/1.0 200 OK
Cseq: 5
Session: ZZEfpZ0zxK5
RTP-Info: url=rtsp://host/a/c;seq=16778;rtptime=1946900992

--------------------------------------------------------------------
C->S (before time t+10)
PAUSE rtsp://host/a/b RTSP/1.0
Cseq: 6
Session: ZZEfpZ0zxK5

--------------------------------------------------------------------
S->C (before time t+10)
RTSP/1.0 200 OK
Cseq: 6
Session: ZZEfpZ0zxK5

--------------------------------------------------------------------

The PAUSE with Cseq 6 should mute the audio from Cseq 4.  Should it
also cancel the PLAY from Cseq 5?  This is another permutation of issue
#8.  The URL that is queued might be different from the one that is
playing, and it is unclear if that changes the answer.


Scenario #11:
Initial connection setup, followed by:
--------------------------------------------------------------------
C->S
PLAY rtsp://host/a/ RTSP/1.0
Cseq: 4
Session: ZZEfpZ0zxK5
Range: npt=0-10

--------------------------------------------------------------------
S->C (time = t)
RTSP/1.0 200 OK
Cseq: 4
Session: ZZEfpZ0zxK5
RTP-Info: url=rtsp://host/a/b;seq=15914;rtptime=420914,
          url=rtsp://host/a/c;seq=16778;rtptime=1946900992

--------------------------------------------------------------------
C->S (time = t + 5)
PAUSE rtsp://host/a/b RTSP/1.0
Cseq: 5
Session: ZZEfpZ0zxK5

--------------------------------------------------------------------
S->C
RTSP/1.0 200 OK
Cseq: 5
Session: ZZEfpZ0zxK5

--------------------------------------------------------------------
C->S (time = t + 15)
PLAY rtsp://host/a/ RTSP/1.0
Cseq: 6
Range: npt=0-10
Session: ZZEfpZ0zxK5

--------------------------------------------------------------------
S->C
RTSP/1.0 200 OK
Cseq: 6
Session: ZZEfpZ0zxK5
RTP-Info: url=rtsp://host/a/b;seq=15914;rtptime=420914,
          url=rtsp://host/a/c;seq=16778;rtptime=1946900992

--------------------------------------------------------------------

The PAUSE just mutes the audio.  At time 10, the video stops too
because of the closed range from the first PLAY.

The server will start playing both streams after the second PLAY.  If
the PAUSE really was a mute, it would make sense for it to stay
muted... there is no indication that this should happen, though.


Scenario #12:
Initial connection setup, followed by:
--------------------------------------------------------------------
C->S
PLAY rtsp://host/a/ RTSP/1.0
Cseq: 4
Session: ZZEfpZ0zxK5
Range: npt=0-10

--------------------------------------------------------------------
S->C (time = t)
RTSP/1.0 200 OK
Cseq: 4
Session: ZZEfpZ0zxK5
RTP-Info: url=rtsp://host/a/b;seq=15914;rtptime=420914,
          url=rtsp://host/a/c;seq=16778;rtptime=1946900992

--------------------------------------------------------------------
C->S (time = t + 9.99)
PLAY rtsp://host/a/ RTSP/1.0
Cseq: 5
Session: ZZEfpZ0zxK5

--------------------------------------------------------------------
S->C
???
--------------------------------------------------------------------

The interpretation of the request with Cseq 5 will be different
depending on how fast the network is.  If the PLAY request is processed
by the server before time 10, it is a liveness ping.  Otherwise, it
starts the stream playing again from npt=10.

Issues:
(9) There is a race condition possible between sending a liveness ping
    and the end of the currently playing range that can cause liveness
    pings to be interpreted as requests to start playing from the
    pause point.

Scenario #13:
Initial connection setup, followed by:
--------------------------------------------------------------------
C->S
PLAY rtsp://host/a/ RTSP/1.0
Cseq: 4
Session: ZZEfpZ0zxK5
Range: npt=0-30

--------------------------------------------------------------------
S->C (time = t)
RTSP/1.0 200 OK
Cseq: 4
Session: ZZEfpZ0zxK5
RTP-Info: url=rtsp://host/a/b;seq=15914;rtptime=420914,
          url=rtsp://host/a/c;seq=16778;rtptime=1946900992

--------------------------------------------------------------------
C->S (time = t + 5)
PAUSE rtsp://host/a/b RTSP/1.0
Cseq: 5
Session: ZZEfpZ0zxK5

--------------------------------------------------------------------
S->C
RTSP/1.0 200 OK
Cseq: 5
Session: ZZEfpZ0zxK5

--------------------------------------------------------------------
C->S (time = t + 10)
PAUSE rtsp://host/a/c RTSP/1.0
Cseq: 6
Session: ZZEfpZ0zxK5

--------------------------------------------------------------------
S->C
RTSP/1.0 200 OK
Cseq: 6
Session: ZZEfpZ0zxK5

--------------------------------------------------------------------
C->S (time = t + 15)
PLAY rtsp://host/a/ RTSP/1.0
Cseq: 7
Session: ZZEfpZ0zxK5

--------------------------------------------------------------------
S->C
???
--------------------------------------------------------------------

What does the PLAY with Cseq 7 do?

In this case, the presentation is started and *both* streams are
muted.  Does muting all of the streams pause the session, or is
the session alive but with all streams muted?  The wording about
muting in 10.6 is unclear.

Possibilities for the PLAY:
i.   Start playing both streams immediately from npt 10.
ii.  Queue the PLAY until Cseq 4 is complete.
     At time t+30, unmute both streams and keep playing.
iii. Liveness ping.  Nothing happens.  A future PLAY on
     one of the stream URLs will unmute it.

There are probably more scenarios than I have gone through.

--------------------------------------------------------------------

I think these changes are warranted to clean this up:

(a) PLAY should only be allowed for playing everything that was SETUP.
    It should be an error to PLAY a stream URL on a session where multiple
    stream URLs have been SETUP.
(b) PAUSE should then be modified so that only PAUSE of the URL that was
    PLAYed is legal, to remove the other half of the "mute" functionality.
(b) New methods: MUTE and UNMUTE, to reintroduce mute functionality
    -- Can be done as an extension rather than part of 2326
    -- Either way, it should be optional
    -- Can be detected via OPTIONS (or by trying and letting it fail;
       but the server shouldn't close the connection or session for an
       unknown method) since they are new methods
    -- This could also be done with a pre-defined parameter instead of
       a new method.
    -- Can only be used on a stream URL which has been SETUP for the
       same session.  Error to use it on an aggregate URL.
    -- "Mutedness" of a stream is not reset by doing PAUSE or PLAY
    -- MUTE can be sent before PLAY and will persist
    -- Range header can be used to schedule MUTE and UNMUTE operations.
       If queueing is to be performed, MUTE and UNMUTE requests are
       queued the same way that PLAY requests are.
(c) Deprecate the usage of PLAY with no range header on a playing stream
    as a liveness ping.  Allow it to remain a no-op for a playing stream,
    but suggest that clients use a SET_PARAMETER or an OPTIONS
    which mentions the session identifier as a keep-alive.  Could introduce
    a PING method, but I think this is unnecessary.
(d) Queued play should either be removed or be made optional.
    If the server does not do queued play, then PLAY requests with
    range headers are invalid while the server is playing and should
    generate "method not valid in this state".

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

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 28 Jan 2002 10:38:28 +0100

Jonathan,
other RTSP interested,

I have some comments inline.

Jonathan Sergent wrote:

> This is the scenario that bug #? mentions.

No, it is not the scenario my bug report mention. If the second play had been
made on url:"rtsp://host/a" then it would be my bug report.

> The question is what the

I don't agree on that interpretation. If you compare this with true
non-aggregated, i.e. separate rtsp sessions, the second play would be done
immediately and not queued as it is on another media.

> Initial connection setup, followed by:

I would argue for case ii without the words immediately transition. As the
second play happens when no other play is active the media should start playing
when the request is received by the server. And as it is rangeless and no pause
was the command prior it starts playing npt=0-.

> Initial connection setup, followed by:

This usage seems to be in some contradiction with normal behavior regarding
queued plays. Your suggested introduction of MUTE and UNMUTE is good. They
remove some of the overloading on the commands that has created the ambiguous
behavior.

> Initial connection setup, followed by:

I would like us to consider the language we are using. I would not call it
pauses after it has played the last 15 seconds. Rather I would call it halt or
stops. The reason is the use of the word pause implies that the client sent a
pause, which obviously not is the case. And the difference is rather obvious if
you would send another play without range after the stream has halted. If it has
halted the play starts from the beginning of stream (npt=0-). If it was paused
it would continue where it has paused.

>     generate "method not valid in this state".

This behavior with the mute functionality looks fine. To my understanding the
functionality which is removed is the possibility to change the synchronization
between media, as this is possible with multiple single media sessions, i.e.
non-aggregated control, I don't see a problem.

I would argue for a mandatory to implement method PING in both servers and
clients. This prevents overloading of functionality which created this mess in
the first place. Of course we should clarify that options/set_parameter  with
session id also shall keep the time-out counter updated. I don't know if people
is aware that 3GPP standard for packet base streaming TS 26.234 (from v.4.20)
which uses RTSP recommends that options with session id is used for keep alive.

Regards

Magnus Westerlund

Audio Technology, Ericsson Research
----------------------------------------------------------------------
Ericsson Radio Systems AB  | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

---

From: Jonathan Sergent <[email-masked]>
Date: Mon, 28 Jan 2002 10:22:21 -0800

On Monday, January 28, 2002, at 01:38 AM, Magnus Westerlund wrote:

(scenario #2)
> immediately and not queued as it is on another media.

However, these requests are all in the same RTSP session.  I don't think 
the RFC actually answers my question #3.  Can you point me to a section 
in the RFC to back up your interpretation?  Or can we agree that it is 
not specified?

[...]
>>     a different URL than it PLAYed.
[...]

(Scenario #4)
> was the command prior it starts playing npt=0-.

"immediately transition" was an editing error in this case.  Why should 
it start from time 0?  Does playing with a closed range not reset the 
pause point?  If so, I was not aware of that.  We assumed that after a 
play with a closed range, the pause point was set to the end of said 
closed range.

[...]
> pause, which obviously not is the case.

Agreed.

> And the difference is rather obvious if

I never read the RFC that way, but you may be correct.  We should 
clarify it.

Does it make sense for PLAY halting to not sent the pause point?  Are 
other implementations interpreting the RFC this way too?

We need to consider the state machine implications of all of this as 
well.  Another scenario I left off is the case where the client sends 
PLAY request with an open ended range, and then sends a PAUSE request 
just before the end of the stream, and the network delays it such that 
the server receives the PAUSE request after the stream has ended.  If we 
considered "PLAY halted" as the same state as "PAUSE succeeded" then 
this PAUSE request would result in "method not valid in this state".  We 
may need to either allow PAUSE while in the ready state, or actually 
distinguish the two states.  I was leaning towards saying that we should 
explicitly allow PAUSE while in the ready state, but what you are saying 
makes it sound like maybe we should differentiate the two states 
completely.

--
Jonathan Sergent / [email-masked] / (650)352-6495

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 29 Jan 2002 14:50:01 +0100

Jonathan,

see comments inline.

> in the RFC to back up your interpretation?  Or can we agree that it is

I can agree that is not specified. I just made the interpretation that the
queue should be for each media and one for the session. Which of course makes
thing very complicated and unclear.

> play with a closed range, the pause point was set to the end of said

10.5 in RFC 2326

   A PLAY request without a Range header is legal. It starts playing a
   stream from the beginning unless the stream has been paused. If a
   stream has been paused via PAUSE, stream delivery resumes at the
   pause point. If a stream is playing, such a PLAY request causes no
   further action and can be used by the client to test server liveness.

My interpretation of the above text is that a play without range is only
resuming if there has been a PAUSE request as the last play or pause request.
Otherwise there exist no pause point to resume from. And if there exist no
pause point a play without range starts from the beginning.

Agreed.

> other implementations interpreting the RFC this way too?

I guess you mean set. And I believe both have some functionality
justification. But also I would like to hear others interpretation of the RFC
in this respect.

> makes it sound like maybe we should differentiate the two states

As I have pointed out in another bug report the state machine in the appendix
is rather incomplete. I think that we need to draw the state machine and all
transitions that are possible and be sure that we understand the implications
of every on of them. It is very bad that a state machine is so hard to draw
in ascii.

Cheers

Magnus Westerlund