Subject: [MMUSIC] SIP-RTSP Draft Feedback

From: "David Ress" <[email-masked]>
Date: Tue, 11 Apr 2006 16:29:57 -0400

I too am pleased to see work going on to determine how to deal with the
SIP-RTSP relationship and acknowledge the efforts of the authors to
provide multiple options for consideration.   As is evident from my
comments below I do not believe that one of the models presented can
possibly meet the needs of the application. 
 
I think it is very important to create a simple architectural rendering
whereby a session and a stream are viewed as different architectural
objects with different needs.  SIP was created for the puprose of
establishing a session and the session may in turn support some number
of media streams.  The streams however are transitive - they may come
and go while the session persists.  There seems to be an unstated
assumption in some of the discussion points in the document that SIP is
good for stream control.   This is not its purpose and not what it is
good for.   
 
There are many network elements which may be interested in or
participate in establishing or managing a session.  SIP proxies, B2BUAs,
p-CSCF, s-CSCF, ....  For the most part streams are endpoint to endpoint
(yes, there are exceptions but the hierarchy should never approach that
of the session control network). As such, stream control should be
endpoint to endpoint.  This is well accepted for VoIP where RTCP for
example is point to point regardless as to whether SIP, H.323, H.248 or
whatever was used to establish the session.   Can we imagine replacing
RTCP with some SIP extensions? (I'm sure someone has proposed this so
forgive my ignorance)
 
As initially defined, RTSP encompasses both the session establishment as
well as the stream management.  This is as much a violation of the
architectural principles I implied above as trying to use SIP to do
both, but it has succeeded to this point because there has not been much
of a session framework in place in the networks upon which it has been
deployed.  Clearly the industry is moving in a direction whereby a more
complex session control plane is required and SIP has become accepted as
the session control protocol of choice.  
 
While the document does highlight signaling latency as a key issue for
the "all SIP" approach, I don't think it truly conveys the magnitude of
the problem nor does it fully acknowledge the other performance issues
associated with using SIP for streaming control.   Consider an IMS
network scenario whereby the p-CSCF and the s-CSCF are separated by some
1000 miles.  Imagine signaling a trick play command across the access
network - through the p-CSCF - across several more network hops to the
s-CSCF - on to the video AS and finally across a few more network hops
to the video source.   Ok, latency is clearly a problem, but consider
performance also.  If 50K subscribers are viewing material, what is the
hit to the p-CSCF, s-CSCF and video AS to process trick play commands?
Suddenly, the session control plane components must scale to meet the
needs of the media control plane.  The problem can be expressed in
non-IMS terms using SIP proxies, B2BUAs, etc. as well.
 
In summary, the SIP + RTSP coexistence model is the only scalable option
presented and maps very well to a domain architecture model whereby
sessions and media streams are related but separate objects with
different needs.  
 
A few other minor comments:
- The scenarios covered in section 3.4 - Use Cases should be worded more
as simple scenario descriptions rather than positioning a solution
option
- In scenario one, it should be noted that TV and VoIP are two separate
sessions and that the choice of protocols which are used to implement
them is irrelevant in defining an interaction between them.  That is,
there must be an application level entity which is aware of both
sessions and the need for the interaction between. This application
level entity performs the logic of pausing one stream in order to
present another.  There is nothing inherent to SIP which enables the
protocol layer to do this for free or enables the network to do it for
the user. 
- Section 6 - solution options discusses a Channel ID and Opaque token
but does not define what either of these are.  Perhaps one of the
referenced documents discusses this, but I believe SDP can be used to
describe an RTSP session without requiring Opaque data of any kind.
That is, establishment of a video stream using SIP+SDP can include not
only the video stream, but also the RTSP stream.   I think this is kind
of what was intended here but it wasn't obvious.
 
Regards,
David

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