Subject: Re: [MMUSIC] SIP-RSTP Draft

From: "Xiangyang. Wu(Steven. Wu)" <[email-masked]>
Date: Wed, 01 Mar 2006 15:25:46 +0800

Convergence of RTSP with sip is a feasible way for streaming media application, I guess. But it's seemed we need much work to do still. Except it, do people think of using SIP to carry SG (Service Guide), IMG (Internet Media Guides) or other things like it? As a guide for subscribers, it may need to be considered to enable streaming media applicable in some scenarios. Is SIP with IMG support a candidate way?

What people say?

======= 2006-02-27 13:34:00 Original Message：=======

>Attached. We missed the deadline :-( With the Winter Break here I guess
>it was unavoidable. 
> 
>I guess we can start a discussion? Xavier Marjou and I will be at the
>meeting.
> 
>Marie-Jose
> 
>Marie-Jose Montpetit, Eng. Ph.D.
>Motorola Connected Home Solutions
>NEW PHONE: +1-781-372-8115
>[email-masked]
> 
> 
>_______________________________________________
>mmusic mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/mmusic

= = = = = = = = = = = = = = = = = = = =

Best Regards! 				

　　　　　　　　Xiangyang. Wu(Steven. Wu)　　　　　　　　
　　　　　　　　　　2006-03-01

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

---

From: "Xiangyang. Wu(Steven. Wu)" <[email-masked]>
Date: Wed, 01 Mar 2006 16:32:52 +0800

What people say?

Best Regards!

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 16 Mar 2006 14:58:12 +0100

Hi,

I have reviewed 
http://tools.ietf.org/wg/mmusic/draft-whitehead-mmusic-sip-for-streaming-media-00.txt
and have some comments on this.

First of all I think it is good that people are considering and 
discussing how SIP and RTSP interact. Therefore I think we should try to 
create an balanced discussion on this. I think the most important is to 
drive the discussion from the usage side. We will easily end up in a 
turf fight if we aren't careful and ensure that people are on the same 
page and understands the needs by the applications rather than try to 
promote their protocol.

It is unfortunate that the draft does not provide more meat on the bones 
in regards to the use cases and how requirements are derived from those 
use cases. I hope this will be much more well described in the next 
version.

In regards to possible evolution tracks I would like to promote a C 
track: Using RTSP and SIP side by side without protocol integration. 
Instead look at the services and how to realize them with minimal 
protocol work.

However lets go back to the use cases and review the ones that are listed:

Scenario 1 - Converged service:
My main comment on this use case is that I fail to see the need for 
integrating SIP and RTSP at all. If you are in an RTSP session and there 
is a incoming multi-media telephony call. Then there is no reason to use 
RTSP to receive that call. Simply have the TV-box pause the media 
streaming, or for live resources pipe it to a hard drive while the SIP 
part of the application negotiate the call and one uses the media 
encoders and decoders to handle the call. The main point here is that 
even if one is registered to accept SIP calls on ones TV there is two 
different context in play, one of the streaming and one for the call. 
All necessary integration happens within the application within the 
TV-box. I would also like to understand how the network can make 
decision on behalf of the end-point application. Please clarify that 
line of thought.

Scenario 3 - Remote Video Monitoring
Here I fail to understand when and in which cases you want to switch to 
bi-directional media communication within the same context of an ongoing 
uni-directional media service? I think my problem is to see how a 
session to a uni-directional resource suddenly becomes a bi-directional 
one, rather than being a new session for another resource.

Scenario 5 - Multicasting
I think this is an interesting use case that is somewhat discussed in 
the RTSP 2.0 use case section. As it is identified there would be need 
for some extension mechanisms to enable things such as passing the 
control between participant or allowing anyone to control the session. I 
also think there are interesting cases of where one like to have a 
multi-party conference that adds streaming media into the session. 
However I think this can already today be resolved using an combination 
of SIP and RTSP to create the conference session, and then invite the 
server to deliver media to a multicast address or a relay that 
distribute the media to all participants.

Scenario 5 - Video on Demand
I have some hard time understanding what the main points of this 
scenario is. I don't see how the resource reservation is different if 
one is using SIP or RTSP. Please elaborate this use case

When it comes to both SIP and RTSP I think both have the same problem of 
handling the control of an aggregated media resource. With an aggregated 
media resource I mean cases such as channel switching of live channels 
or the creation and manipulation of a server side play list, for which 
media then is streamed to the user. I think these cases have so far 
always been resolved using proprietary solutions over HTTP or other 
protocols.

If one looks on the Required Capabilities. I think the most important 
improvement of this section is to explain which are general requirement 
and which applies to certain use cases. For example the scalability 
requirement is not clearly needed in all deployments. An example would 
be a home media server, which would only serve a limited number of 
users. While a server in a service providers network may need to handle 
a huge amount of simultaneous sessions.

I will not go into any detail comments on the solution space. I think 
there is much need to firm up the understanding on the use cases and 
their requirements before we start discussing what is missing and how 
one like to resolve things.

Cheers

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]

---

From: "Montpetit Marie-Jose-MGIF0300" <[email-masked]>
Date: Thu, 16 Mar 2006 09:06:19 -0500

Thanks for the comments they will be taken into account... Yes the draft
is VERY draft as we decided to submit it quite late in the process ;-)

We all agree that we need to dwell more into use cases. 

Thanks for your inputs.

/mjm

-----Original Message-----
From: Magnus Westerlund [mailto:[email-masked]] 
Sent: Thursday, March 16, 2006 8:58 AM
To: Montpetit Marie-Jose-MGIF0300
Cc: [email-masked]; [email-masked]
Subject: Re: [MMUSIC] SIP-RSTP Draft

Hi,

I have reviewed
http://tools.ietf.org/wg/mmusic/draft-whitehead-mmusic-sip-for-streaming
-media-00.txt
and have some comments on this.

However lets go back to the use cases and review the ones that are
listed:

Cheers

Magnus Westerlund

---

From: [email-masked]
Date: Fri, 17 Mar 2006 11:32:57 -0500

Magnus,

Thanks for taking the time to read and comment on the draft.
Like Marie said, the draft is extremely drafty. We rushed to submit it in
order to get a few minutes at the upcoming IETF meeting. We agree it needs
much more work.

Nevertheless, I appreciate your comments. Our intent is to keep working on
it. I also think the scope will change to focus mostly on the use-cases
and associated requirements.

As for your remarks, I've included a few follow-up replies in the text
below.

-Steve

-----Original Message-----
From: Magnus Westerlund [mailto:[email-masked]] 
Sent: Thursday, March 16, 2006 8:58 AM
To: Montpetit Marie-Jose-MGIF0300
Cc: [email-masked]; Steven D. Whitehead
Subject: Re: [MMUSIC] SIP-RSTP Draft

Hi,

I have reviewed 
http://tools.ietf.org/wg/mmusic/draft-whitehead-mmusic-sip-for-streaming-m
edia-00.txt
and have some comments on this.

[SDW: Agreed!]

[SDW: This option should also be considered. And also for example, how
would/should RTSP need to be extended to support the requirements needed
to achieve the desired use cases]

[SDW: With respect to 'converged services' there are a number of important
issues going on.

1) Service providers that offer multiple services (e.g., streaming service
and real-time communications services) would like to be able to re-use (to
the extent possible) as much infrastructure as possible, rather than
duplicate it. This for example *may* include: subscriber authentication
mechanisms, subscriber service profile databases, accounting and billing
mechanism, QOS signaling mechanism. Of course there are multiple ways to
achieve re-use. Using a common signaling mechanism (e.g., SIP) is one way;
defining and using common APIs at the 'infrastructure-level' is another
way.

2) In cases where a single user participates in multiple services, there
is potential value associated with having one service know state about the
other, so that the behavior of a service can be modified based on
knowledge about the state of the other service. Example: send all incoming
calls to voicemail if I'm watching Monday Night Football. Here too there
are many ways to exchange 'state' information among services. If a common
signaling protocol is used (e.g., SIP) elements in the network can do it
-- without requiring any intelligence on behalf of the endpoints.
Alternatively, the endpoints (server or client) can signal service state
information. But this requires intelligence at the endpoints.
]

[SDW:: Not sure I'm following you here. The example we had in mind is
something like a 'remote' video intercom system, where initially one
end-point might be in a 'monitoring' mode, but upon detecting some
activity (e.g., someone at the door), the session could be upgraded to
bi-directional. 
This could be done via an UPDATE. However the main point of this scenario
isn't so much the ability to go uni-to-bi-directional media. But rather,
as an example of using SIP's rendezvous mechanism to establish sessions to
endpoints that are located on private networks behind NATs/FWs. A similar
use case along these lines would be accessing content stored on a private
media server.

SIP's rendezvous mechanism comes in handy in this case.
]

[SDW: yikes. I agree with you. This use case is quite muddled. However wrt
VOD there are a couple things of interest.

1) That whole converged services story.
2) Support for 3rd party VOD content providers. That is, scenarios where
service is offered to a subscriber through a 'retail provider', but
actually delivered via one of several wholesale (3rd party) provider. In
this case, think of Verizon as a 'retail' VOD provider, but having Time
Warner actually delivering the content via there servers. In this case,
there is a need for the two providers to interoperate and exchange
charging /transaction data. SIP (and associated extensions) have this.
3) In the case of VOD servers that are not local to the end-user, there
may also be scenarios where requesting Transport Resources is more
difficult. This may be changing with evolving models for network resource
management architectures, but current schemes tend to support
'service-based local policy' management. In cases, where the VOD server is
remotely located, it would be difficult for it to know how to contact
'local-client side' resource management entities. SIP/IMS based
architectures do support this via proxies and preconditions. 

]

[SDW: Yep. Agreed about HTTP and content descriptions. There's a need to
establish standards for such things....it seems to me. I see this as
outside the scope of this work.]

Cheers

Magnus Westerlund