Subject: [MMUSIC] Rtspspec-bugs digest, Vol 1 #115 - 10 msgs

From: [email-masked]
Date: Tue, 03 Feb 2004 07:14:33 -0800

This is an automatic digest of bugs submitted and changed on the RTSP bug tracker.  To see a list of bugs, visit:

http://sf.net/projects/rtspspec

When replying, please make your Subject line more specific than "Re: Rtspspec-bugs digest"

Today's Topics:

   1. [ rtspspec-Bugs-563153 ] Appendix C: agg/non-agg mixup (SourceForge.net)
   2. [ rtspspec-Bugs-585865 ] Use of Date, and Host in RTSP (SourceForge.net)
   3. [ rtspspec-Bugs-608365 ] 3xx codes overhaul and clarification (SourceForge.net)
   4. [ rtspspec-Bugs-619421 ] Range header in PLAY response (SourceForge.net)
   5. [ rtspspec-Bugs-625339 ] need clarification for stand alone SDP (SourceForge.net)
   6. [ rtspspec-Bugs-625342 ] DESCRIBE Res needed in C.2 and C.3 (SourceForge.net)
   7. [ rtspspec-Bugs-625352 ] Synchronising multiple SSRCs (SourceForge.net)
   8. [ rtspspec-Bugs-630920 ] RTP-Info does not support multiple SSRC (SourceForge.net)
   9. [ rtspspec-Bugs-633148 ] Use of TCP and UDP (SourceForge.net)
  10. [ rtspspec-Bugs-633779 ] SET_PARAMETER responses (SourceForge.net)

--__--__--

Message: 1
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Tue, 03 Feb 2004 06:39:02 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-563153 ] Appendix C: agg/non-agg mixup

Bugs item #563153, was opened at 2002-06-01 03:42
Message generated for change (Comment added) made by magwes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=563153&group_id=23194

Category: General
Group: Fixed in CVS/Need WG Approval
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Rob Lanphier (robla)
Assigned to: Magnus Westerlund (magwes)
Summary: Appendix C: agg/non-agg mixup

Initial Comment:
The initial descriptions of aggregate and non-aggregate
contol are reversed, and poorly written.

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

>Comment By: Magnus Westerlund (magwes)
Date: 2004-02-03 15:39

Message:
Logged In: YES 
user_id=302620

No comments received.

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

Comment By: Magnus Westerlund (magwes)
Date: 2003-10-24 13:37

Message:
Logged In: YES 
user_id=302620

I have went over the SDP appendix once more and found some
more strangeness regarding aggregated and non-aggregated.
This is now fixed. 

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

Comment By: Rob Lanphier (robla)
Date: 2002-06-06 22:24

Message:
Logged In: YES 
user_id=3796

It turns out this had already been fixed in the draft-00
version.  However, the wording was still very confusing. 
This has been fixed in the version checked into CVS.

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/rtspspec/sdp.tex.diff?r1=1.3&r2=1.4

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=563153&group_id=23194

--__--__--

Message: 2
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Tue, 03 Feb 2004 06:40:04 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-585865 ] Use of Date, and Host in RTSP

Bugs item #585865, was opened at 2002-07-24 13:22
Message generated for change (Comment added) made by magwes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=585865&group_id=23194

Category: General
Group: Resolved - Added to text
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Magnus Westerlund (magwes)
Summary: Use of Date, and Host in RTSP

Initial Comment:
There exist a number of HTTP headers that are just
referenced into the specification. Several is hard to
interpret on how they relate to RTSP and what
requirement level that is needed. 

Date:
The date header MUST be sent by origin server in
responses. What is an origin server and what exceptions
exist for RTSP? For RTSP does that include requests also?

Host:
The comment is that this should not be used in RTSP.
This should be reflected in the heade table. 

Other headers that are simply referenced needs most
probably some specification on applicability and
exceptions.

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

>Comment By: Magnus Westerlund (magwes)
Date: 2004-02-03 15:40

Message:
Logged In: YES 
user_id=302620

No comments, closing bug.

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

Comment By: Magnus Westerlund (magwes)
Date: 2003-10-22 18:43

Message:
Logged In: YES 
user_id=302620

The Host and Date header has both been clarified on there
usage. Edits are checked in for both. The Date has been
there for some versions, while the host text is new. 

If some other headers also needs edit, has not been
evaluated at this time. 

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=585865&group_id=23194

--__--__--

Message: 3
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Tue, 03 Feb 2004 06:40:44 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-608365 ] 3xx codes overhaul and clarification

Bugs item #608365, was opened at 2002-09-12 15:23
Message generated for change (Comment added) made by magwes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=608365&group_id=23194

Category: General
Group: Fixed in CVS/Need WG Approval
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Magnus Westerlund (magwes)
Summary: 3xx codes overhaul and clarification

Initial Comment:
The 3xx codes are all directly taken from HTTP. There
seem that not all are suitable for RTSP. A review of
the codes and the needs should be perforemed. 

Also the usage of 3xx responses needs some work. What
headers to include, etc.

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

>Comment By: Magnus Westerlund (magwes)
Date: 2004-02-03 15:40

Message:
Logged In: YES 
user_id=302620

No comments closing bug.

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

Comment By: Magnus Westerlund (magwes)
Date: 2003-06-25 20:43

Message:
Logged In: YES 
user_id=302620

Tom marshall wrote up a proposal for new text regarding the
3xx codes that seperate 304 from the rest. This has been
edited in since the 03 version of the draft. 

No new codes has been specified. The use of 303 is still
deprecatied. 

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

Comment By: Magnus Westerlund (magwes)
Date: 2002-10-30 19:27

Message:
Logged In: YES 
user_id=302620

I have written up a proposal for fixing this within the
spec. Two new codes are defiend 350, and 351. 303 is
suggested to be decapitated. 304 needs further discussion.
Also user comments has been added to the status chapter. 

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=608365&group_id=23194

--__--__--

Message: 4
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Tue, 03 Feb 2004 06:41:38 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-619421 ] Range header in PLAY response

Bugs item #619421, was opened at 2002-10-07 01:14
Message generated for change (Comment added) made by magwes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=619421&group_id=23194

Category: General
Group: Fixed in CVS/Need WG Approval
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Magnus Westerlund (magwes)
Summary: Range header in PLAY response

Initial Comment:
Current RTSP RFC makes Range header in PLAY response
from server optional.

If the PLAY request includes a Range header indicating
a possible seek, then it is probably necessary to
include Range in the response since it is possible that
the requested seek position could not be honored and
playback will resume at the nearest seekable point
which is not known to the client.

Note:  To fix this issue in 3GPP, Range in a PLAY
response was made mandatory for all PLAY responses.

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

>Comment By: Magnus Westerlund (magwes)
Date: 2004-02-03 15:41

Message:
Logged In: YES 
user_id=302620

No comments, closing bug.

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

Comment By: Magnus Westerlund (magwes)
Date: 2003-10-24 14:27

Message:
Logged In: YES 
user_id=302620

The inclusion of the Range header in PLAY responses is now a
MUST. We haven't found any problem with this. If anybody
finds this, please raise it. 

I have also put in Maureen into the acknowledgement section. 

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

Comment By: Magnus Westerlund (magwes)
Date: 2003-01-31 13:49

Message:
Logged In: YES 
user_id=302620

As discussed in the teleconf the 22 jan 2003:
We should look at strengting the requirement on having the
Range header also for live streams when using RTP. A
solution based on Range:npt=now- with optional time or using
Range:clock=x can work. But careful wording is required.

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

Comment By: Rob Lanphier (robla)
Date: 2002-11-20 21:06

Message:
Logged In: YES 
user_id=3796

One other thing...put Maureen Chesire in the acknowlegements
for raising this....

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

Comment By: Rob Lanphier (robla)
Date: 2002-11-20 21:02

Message:
Logged In: YES 
user_id=3796

Per a conversation with Magnus and I, we think we should
soften the language somewhat (strong SHOULD instead of MUST).  

One case to consider is a live stream, which one would think
would obviate the need for this header.  However, the
rationale for having it in live is when dealing with RTP. 
Since RTP audio and video streams can have a completely
different timestamp base, there needs to be an out-of-band
technique for synchronization.  The two techniques used in
RTSP are:

1.  RTSP "Range:"<->RTSP "RTP-Info:"<->RTP timestamp synch
2.  RTCP timestamp<->NTP mapping

Eventually, a well-behaved RTSP client will synch the
streams based on
the RTCP timestamps (when received).  However, there's a
period before the first RTCP packet arrives that there's no
sync, unless a Range header is known.

So, that also points to what the Range header should look
like.  The
Range header should include an open-ended wallclock range,
like so:
   Range: clock=20021120T133205Z- 
   RTP-Info:url=rtsp://example.com/fizzle/audiotrack;
            seq=5712;rtptime=934207921,
            url=rtsp://example.com/fizzle/videotrack;
            seq=57654;rtptime=2792482193

The spec should make this clear.

An interesting consideration to make here is a restriction
on Range response. The current rtsp spec states that "The
unit of the range in the reply is the same as that in the
request".  Perhaps an alternate syntax, if the PLAY request
has a Range: header in npt is as follows:

   Range: npt=now;time=20021120T133205Z

The "time" allows for mapping to occur.

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

Comment By: Magnus Westerlund (magwes)
Date: 2002-10-30 19:36

Message:
Logged In: YES 
user_id=302620

Yes, the range header is need for RTP synchonization. The
draft specification has been updated to require this when
using RTP to make synchonization possible. 

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=619421&group_id=23194

--__--__--

Message: 5
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Tue, 03 Feb 2004 06:47:27 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-625339 ] need clarification for stand alone SDP

Bugs item #625339, was opened at 2002-10-18 19:57
Message generated for change (Comment added) made by magwes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=625339&group_id=23194

Category: General
Group: Fixed in CVS/Need WG Approval
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Go Hori (ghori)
Assigned to: Magnus Westerlund (magwes)
Summary: need clarification for stand alone SDP 

Initial Comment:
When a SDP file is download other than via RTSP (e.g. 
HTTP, FTP), control strings need to be all absolute.  
Should probably put clarification or give an example for 
this case to avoid confusion.

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

>Comment By: Magnus Westerlund (magwes)
Date: 2004-02-03 15:47

Message:
Logged In: YES 
user_id=302620

No comments, closing bug.

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

Comment By: Magnus Westerlund (magwes)
Date: 2003-10-24 15:39

Message:
Logged In: YES 
user_id=302620

There has been added a new section in the SDP appendix which
writes some clarifying notes on the topic. Text will become
available in v5.

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

Comment By: Magnus Westerlund (magwes)
Date: 2002-10-30 19:38

Message:
Logged In: YES 
user_id=302620

Yes, this is another pice of information that belong to
appendix C.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=625339&group_id=23194

--__--__--

Message: 6
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Tue, 03 Feb 2004 06:48:55 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-625342 ] DESCRIBE Res needed in C.2 and C.3

Bugs item #625342, was opened at 2002-10-18 20:00
Message generated for change (Comment added) made by magwes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=625342&group_id=23194

Category: General
Group: Fixed in CVS/Need WG Approval
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Go Hori (ghori)
Assigned to: Magnus Westerlund (magwes)
Summary: DESCRIBE Res needed in C.2 and C.3

Initial Comment:
In the examples for aggregate control SDP and 
subsequent SETUP request, it is confusing how a URL 
for SETUP is created.  It is missing a DESCRIBE 
response and gives an impression that a sesseion level 
control string was used as a base URL.

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

>Comment By: Magnus Westerlund (magwes)
Date: 2004-02-03 15:48

Message:
Logged In: YES 
user_id=302620

No comments, closing bug.

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

Comment By: Magnus Westerlund (magwes)
Date: 2003-10-24 16:32

Message:
Logged In: YES 
user_id=302620

I agree that the example was not clear. This has now been
corrected by including a DESCRIBE response for the
aggregated example which has defines a Content-Base, which
is the most  reasonable solution to this problem. 

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

Comment By: Magnus Westerlund (magwes)
Date: 2002-10-31 13:24

Message:
Logged In: YES 
user_id=302620

We may also want to define a dedault rule to create control
URLs based on the first media setup so that sessions missing
session level control URLs are still possible to set up in
aggregates.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=625342&group_id=23194

--__--__--

Message: 7
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Tue, 03 Feb 2004 06:49:52 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-625352 ] Synchronising multiple SSRCs

Bugs item #625352, was opened at 2002-10-18 20:41
Message generated for change (Comment added) made by magwes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=625352&group_id=23194

Category: General
Group: Fixed in CVS/Need WG Approval
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Go Hori (ghori)
Assigned to: Magnus Westerlund (magwes)
Summary: Synchronising multiple SSRCs

Initial Comment:
taken from a thread in mmusic

We have a problem in RTSP when a media stream 
needs to contain multiple
RTP SSRCs. This can't be expressed today clearly.

When one is only interested in controlling the media and 
not each
individual source the following scenarios should be 
supported:
A SINGLE SETUP request can result in one of the 
following:
1. A media stream with a single SSRC.
2. A media stream with retransmission with SSRC 
multiplexing. This
requires a SSRC for the original and one for the 
retransmission packets.
It is an advantage if both can be explicitly signalled, but 
is no
requirement.
3. Live session with any number of participants and 
unlimited use of
dynamic chosen SSRCs.

Due to clients capability the different scenarios need to 
be explicitly
signaled. Scenario 2 will be that from an SDP 
description and support of
retransmission will be signaled by requesting AVPF in 
the transport
header. However today there exist no way to signal if it 
is scenario 1
or 3. So this needs to be resolved in a nice backwards 
compatible way. I
think that support for 3 can require support for any extra 
signaling
while scenario 1 must work without any extra parts.

By doing all these scenarios with a single SETUP per 
media stream we
keep the signaling to a minimum and avoid further 
requirements on SDP.
It might be advantageous in the future to create a SDP 
attribute
declaring the streams type.

If one desires to control the individual source one either 
declare
individual media streams for each source. This will 
require use of
ANNOUNCE in dynamic settings. The alternative would 
be to create a new
media resource control protocol which is suited for this. 
However I
don't see real need to solve this problem in standard 
RTSP better than
by using ANNOUNCE.

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

>Comment By: Magnus Westerlund (magwes)
Date: 2004-02-03 15:49

Message:
Logged In: YES 
user_id=302620

No comments, closing bug.

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

Comment By: Magnus Westerlund (magwes)
Date: 2003-10-24 14:07

Message:
Logged In: YES 
user_id=302620

This was discussed in the telecon the 28th April 2003.

The resolution was to clarify in RTSP that only a single
SSRC one can be given in RTSP. Any furhter SSRC may be
present in the stream, however they must be synchronised
using RTCP. 

This has been clarified in the specification. 

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=625352&group_id=23194

--__--__--

Message: 8
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Tue, 03 Feb 2004 06:50:44 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-630920 ] RTP-Info does not support multiple SSRC

Bugs item #630920, was opened at 2002-10-30 08:44
Message generated for change (Comment added) made by magwes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=630920&group_id=23194

Category: General
Group: Fixed in CVS/Need WG Approval
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Aravind Narasimhan (arvy_n)
Summary: RTP-Info does not support multiple SSRC

Initial Comment:
The RTP-Info header can't be used to synchronize
multiple RTP flows using different SSRC as a single
media stream. As each SSRC has its own RTP sequence and
timestamp space to allow synchronization it needs to be
possible to give these values for each SSRC in the
media stream. 

This bug has connection with bug# 625352.

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

>Comment By: Magnus Westerlund (magwes)
Date: 2004-02-03 15:50

Message:
Logged In: YES 
user_id=302620

No comments, closing bug.

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

Comment By: Aravind Narasimhan (arvy_n)
Date: 2003-10-01 18:00

Message:
Logged In: YES 
user_id=437699

The following text has been added to 13.33 of bis04 to
address this bug:

The RTP-Info response-header field is used to set
RTP-specific parameters in the PLAY response. These
parameters correspond to the synchronization source
identified by the ssrc parameter of the Transport response
header in the SETUP reponse. For streams using RTP as
transport protocol the RTP-Info header SHALL be part of a
200 response to PLAY.

. . .

Additionally, the RTP-Info header parameter fields only
apply to a single SSRC within a stream (the SSRC reported in
the transport response header; see section  13.40). If there
are multiple synchronization sources present within a RTP
session, RTCP must be used to map RTP and NTP timestamps for
those sources, for both synchronization and drift-checking.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=630920&group_id=23194

--__--__--

Message: 9
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Tue, 03 Feb 2004 06:55:39 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-633148 ] Use of TCP and UDP

Bugs item #633148, was opened at 2002-11-04 08:53
Message generated for change (Comment added) made by magwes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=633148&group_id=23194

Category: General
>Group: Fix - Discussed/Resolved
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Nobody/Anonymous (nobody)
Summary: Use of TCP and UDP

Initial Comment:
A clarification one how each protocol shall be used to
transport RTSP messages seems beneficial. 

For example one should clarify that TCP are bytes
streams and any fragmenetation are valid, but that for
efficieny one should send the a message in as few
packets as possible. 

UDP needs rules if fragementation is allowed or not. 

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

>Comment By: Magnus Westerlund (magwes)
Date: 2004-02-03 15:55

Message:
Logged In: YES 
user_id=302620

The connection chapter has been a long time ago been updated
to clarify these issues. UDP has been deprecatied due to
lack of implementations providing feedback. 

Closing bug. 

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=633148&group_id=23194

--__--__--

Message: 10
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Tue, 03 Feb 2004 07:13:50 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-633779 ] SET_PARAMETER responses

Bugs item #633779, was opened at 2002-11-05 13:19
Message generated for change (Comment added) made by magwes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=633779&group_id=23194

Category: General
>Group: Fixed in CVS/Need WG Approval
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Nobody/Anonymous (nobody)
Summary: SET_PARAMETER responses

Initial Comment:
Clarify on the usage of SET_PARAMETER when no body is
present. A correct syntax with unknown headers will
result in a 200 response but also the understanding of
a propreitary or new header will result in 200. Clarify
that a requester should use the Require header with an
option tag to ensure that the responder of the request
really understands the propreitary or new header. 

Also write text recommending on the usage of parameters
in the body with the motivation that they are simpler
than using require and headers. But both case should be
possible to use. 

How to handle a empty parameter list in the body should
also be explained. 

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

>Comment By: Magnus Westerlund (magwes)
Date: 2004-02-03 16:13

Message:
Logged In: YES 
user_id=302620

Added text trying to clarify that it is allowed to use for
keep alive. Also clarified the possible pit-falls with using
headers in such a method. 

Please review!

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

Comment By: Rob Lanphier (robla)
Date: 2003-05-28 18:28

Message:
Logged In: YES 
user_id=3796

From 14 May 2003 telecon
(http://rtsp.org/2003/telecon/minutes14May.html):
#  Magnus: how to respond if server doesn't understand parameter
# Anders: maybe a require header to be used if necessary
# Magnus: I can agree with just a clarification
# Anders: for proprietary client request, it can expect
proprietary response
# Magnus: easier if just use body
# Anders: don't need to specify more than that
# Rob: I agree
# Magnus: spec says that SET_PARAMETER can be used for keep
alive
# Magnus: it's possible to have SET_PARAMETER without body
# RESOLUTION: Short explanation of SET_PARAMETER without
body being allowed. No other changes

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=633779&group_id=23194

End of Rtspspec-bugs Digest

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