Subject: RE: SIP & RTSP interworking?

From: Linden deCarmo <[email-masked]>
Date: Wed, 15 Mar 2000 16:38:02 -0500

Anup,

Sorry for my poor explanation.  From a global perspective, there will be one
logical session.  This logical session will consist of a SIP session and a
RTSP session which need to be united.

Given this info, your option a) would not be appropriate.

option b) is what we'd like to do.

	>If you go with the model that the RTSP server understands SIP, then
RTSP
	>provides a means to pass the conference ID to the RTSP server so
that it can
	>join the SIP session and link subsequent RTSP operations to the SIP
session.

Wow, thanks for pointing this out.  Should've noticed this before.

The text is the RFC is quite clear:

   Separation of stream control and conference initiation:
          Stream control is divorced from inviting a media server to a
          conference. The only requirement is that the conference
          initiation protocol either provides or can be used to create a
          unique conference identifier. In particular, SIP [12] or H.323
          [13] may be used to invite a server to a conference.

====

I believe my problem is solved.  Thanks!

Linden deCarmo
Netspeak Corporation
902 Clint Moore Road
Suite 104
Boca Raton, FL 33487

> -----Original Message-----
> From:	Anup Rao [SMTP:[email-masked]]
> Sent:	Wednesday, March 15, 2000 4:23 PM
> To:	Linden deCarmo
> Cc:	'Kundan Singh'; 'Dean Willis'; [email-masked]
> Subject:	Re: SIP & RTSP interworking?
> 
> 
> 
> Linden deCarmo wrote:
> 
> > I like this a lot better, but the problem I have is this, we'd like for
> BOTH
> > sessions to be active at the same time and both of your proposals
> require a
> > teardown of the SIP session.
> >
> 
> Linden,
> 
> I still dont understand what the application is. Your first note said :
> 
> *************
> What I'd like to do is setup a session with SIP (via an INVITE), then
> control streaming aspects via RTSP (i.e. play, pause, stop etc.).
> *************
> 
> Implying to me that there was only one session.
> 
> Your second note says:
> 
> **************
> I like this a lot better, but the problem I have is this, we'd
> like for BOTH
> sessions to be active at the same time and both of your proposals
> require a
> teardown of the SIP session.
> **************
> 
> Implying that there were two. (which I think makes sense).
> 
> I think there are broadly two scenarios:
> 
> a)  Sending an RTSP URL to a SIP UA as part of redirection or call
> termination
> or transfer. The SIP session in question would be terminated.  From the
> SIP
> point of view, it seems to make sense to put the RTSP URL in a Contact: or
> Also:, exact callflows and details to be worked out.
> 
> b) Have a RTSP controlled stream as part of a conference ie an addon to an
> existing or about-to-exist SIP session.
> There could be a number of interesting variants to this.
> 
> One of them that follows the "SIP-UA knows RTSP" model:
> You can have one SIP UA be the RTSP client (ie the owner/controller of the
> stream if you will), and direct the stream to each SIP UA in the
> session(could
> be via multicast as well). Other UAs dont need to know anything about
> RTSP. In
> which case SIP needs a way to inform UAs that  this new RTP stream will be
> added
> to the session which I guess it should be able to do using re-INVITEs.
> If you go with the model that the RTSP server understands SIP, then RTSP
> provides a means to pass the conference ID to the RTSP server so that it
> can
> join the SIP session and link subsequent RTSP operations to the SIP
> session.
> Such IDs are opaque to RTSP protocol , so the usage would depend on the
> server
> and application in question.
> 
> -Anup.
> 
> > Linden deCarmo
> > Netspeak Corporation
> > 902 Clint Moore Road
> > Suite 104
> > Boca Raton, FL 33487
> >
> > > -----Original Message-----
> > > From: Kundan Singh [SMTP:[email-masked]]
> > > Sent: Wednesday, March 15, 2000 3:10 PM
> > > To:   Linden deCarmo
> > > Cc:   'Dean Willis'; [email-masked]
> > > Subject:      RE: SIP & RTSP interworking?
> > >
> > > --
> > > Kundan Singh     http://www.cs.columbia.edu/~kns10
> > >
> > > > This is an interesting suggestion, but the scenario I'm operating
> under
> > > is
> > > > this:
> > > >
> > > > UAC<->UAC (in this case the UAC really is an RTSP server), both must
> > > > understand SIP and RTSP.  I need a way to tie the sessions between
> two
> > > > distinct protocols.  Is a viable alternative to embed the RTSP SETUP
> > > message
> > > > as a SIP body for the INVITE?  This would clearly associate the
> > > sessions,
> > > > but I hate to have a proprietary solution that wouldn't work with
> other
> > > > products that understood SIP & RTSP.
> > >
> > > In that case, the UA may return the RTSP Contact: URI in (say) 3xx
> > > response.
> > >
> > >  UA1          UA2
> > >      INVITE
> > >  -------------->
> > >
> > >    3xx Moved
> > >    Contact:rtsp://server/resource
> > >  <-------------
> > >
> > >    SETUP rtsp://server/resource
> > >  -------------->
> > >  . . .
> > >
> > > Since UA here understand both SIP and RTSP it should not be
> > > a problem.
> > >
> > > If the SIP call is already established, and UA2 wants to
> > > switch to RTSP,  then (IMO) it may use blind call transfer
> > > (BYE,Also:rtsp://...) to ask UA1 to connect to RTSP
> > > server of UA2. Comments ??
> > >