Subject: RE: [MMUSIC] RTSP: Minutes telecon 14th of October 2003

From: Thomas Zeng <[email-masked]>
Date: Tue, 14 Oct 2003 16:54:22 -0700

On item g:

    - Look into SIP to see how they have resolved the discrepancies
      between media and signaling channel.

Could someone fammiliar with SIP help me out here: I need to know what
method of SIP to look, is it SIP BYE method by any chance?

(I saw that SIP has a BYE method to terminate the call in the signalling
channel. )

thanks,
thomas

-----Original Message-----
From: Magnus Westerlund [mailto:[email-masked]]
Sent: Tuesday, October 14, 2003 11:04 AM
To: IETF MMUSIC WG
Subject: [MMUSIC] RTSP: Minutes telecon 14th of October 2003

Hi,

Here is the preliminary minutes for todays telecon. Please comment.

RTSP Telecon the 14th of October

Participants:
Magnus Westerlund, Colin Perkins, Aravind Narasimhan, and Tom Marshall.

Agenda:

1. Opening of meeting.

2. Administrative
    - Scribe
    - IETF in Minneapolis
      * Off-line Meeting?
      * What to present.

3. Since last meeting (1st of October).
a. http://rtsp.org/bug507882 - RTP timestamp and pause
     - Aravind to write up text

b. http://rtsp.org/bug742328 - How to handle PLAY request when at the
end of a media clip
     - Text sent to mailing list, please review.

c. http://rtsp.org/bug742348 - Usage of implicit REDIRECT.
     - Needs text

d. http://rtsp.org/bug640272 - Default way of deriving aggregate URL
    - Text sent to the mailing list

e. http://rtsp.org/bug771638 - a=range in SDP to indicate live media
    - Text sent to the mailing list.

f. http://rtsp.org/bug531189 - How does REDIRECT method work
    - Needs somebody to write up.

g. http://rtsp.org/bug810678 - How to indicate end of media stream
    - Strawman proposal available from Thomas. For discussion.

h. http://rtsp.org/bug770522 - Request to response time is not limited.
    - Some discussion on mailing list. Sean to write up text.

i. http://rtsp.org/bug810681 -     The updated specification version number
    - Awaiting investigation results regarding changes by Aravind.

j. http://rtsp.org/bug795295 - TEARDOWN using * and the Ready-nm state
    - Posted to the mailing list, no comments. Unless comments are
      received it will be edited in.

k. http://rtsp.org/bug804219 - How to handle sync in re-SETUP
    - Text posted to the list. No comments received so far.

l. http://rtsp.org/bug806404 - Re-SETUP of transport parameters
    - Awaiting proposal text from Geetha.

m. http://rtsp.org/bug810666 - Removal of SETUP in play state
    - Proposed to be removed. Message sent to the list.

4. New Issues

a. http://rtsp.org/bug811815 - Use of c= in SDP to know possible address 
classes

b. http://rtsp.org/bug795314 - Caching of OPTIONS request

5. Any other business

6. Next Telecon: Proposal Wednesday, 3rd of December.

7. End of meeting

Minutes
-------

1. Meeting was opened.

2. - Magnus volunteered to write the minutes.

    - IETF meeting in Minneapolis:
      * Colin will request a conference room for a out-side of normal
        agenda meeting. A guess of on the number of participants are
        around 15.

      * The authors will perform a status update on the specification in
        the WG session. The current resolutions and open issues will be
        presented.

3.

a. Nothing has happened.

b. Await review from the WG.

c. Status not changed.

d. Await review from the WG.

e. Was not sent yet, but will be available directly after meeting.
Review comments needed.

f. The remaining issue is with implicit closing of the session. The
    previous meeting has agreement on the functionality but some minor
    issues around use of "connection" needs resolving. Best way of
    resolving this is probably to present a specification text proposal.
    Aravind will take this as a second priority issue.

g. Send comments on the document to list. The discussion resolved that
    this can be divided into several pieces:

    - We need to document in the RTSP specification regarding RTP what
      happens when a source times out a SSRC or receives a RTCP BYE for a
      source.

    - Using BYE is not suitable way to indicate the end of the stream.
      The motivation for this can be seen in Thomas proposal.

    - Look into SIP to see how they have resolved the discrepancies
      between media and signaling channel.

h. Awaits text from Sean.

i. This is a later decision when we have received a list of changes that
    are accurate.

j. Unless comments are received by Monday the 20th of October, this
    resolution will be edited in. Magnus will post a reply to the initial
    mail pointing out the deadline.

k. Will be kept in the text unless comments are review by Wednesday the
    22th of October.

l. Awaits text.

m. Will be edited in unless comments are received by Monday the 20th of
    October.

4.
a. Question raised is: Are there need for a server to announce through
    SDP or other pre SETUP mechanism which address classes it supports to
    the client?

    There was discussion on this topic and the resolution was the
    following:

    It should be assumed that a server being possible to find in DNS with
    a certain address class will support both signaling and media
    delivery for that address. Thus a RTSP request over TCP/IPv6 will
    send media using that source IPv6 address.

b. The OPTIONS request has some dependency on server state and what
content that are addressed. Therefore it seems doubtful that caching of
OPTIONS request are possible. In general it seems that the only
really cachable RTSP request/response pair is for DESCRIBE.

5. No other business.

6. Preliminary date is the 3rd of December, which is three weeks after
the IETF meeting.

7. Meeting was closed.

-- 

Magnus Westerlund

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

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 15 Oct 2003 00:52:53 -0400

Yes, SIP BYE is used to terminate the call, which also results in the 
termination of the media sessions.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 15 Oct 2003 09:00:14 +0200

Thanks Jonathan,

However this is more regarding the other way around. How does SIP handle 
if it receives RTCP BYE or times out a SSRC in an RTP session part of 
the currnet media session?

Cheers

Magnus

Jonathan Rosenberg wrote:

>> a. http://rtsp.org/bug811815 - Use of c= in SDP to know possible 
>> address classes
>>

-- 

Magnus Westerlund