Subject: [SIP] SIP & RTSP interworking?

From: S_S_Dinesh/India/[email-masked]
Date: Mon, 8 May 2000 14:10:34 +0530

What would be the proper (or suggested) procedure to tie a SIP session to
an
RTSP session?

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.).  However,
its not clear to me how I tie the RTSP session id to the previously
established SIP session.

Thanks.

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

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: S_S_Dinesh/India/[email-masked]
Date: Mon, 8 May 2000 14:10:29 +0530

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 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 ??
>

---

From: S_S_Dinesh/India/[email-masked]
Date: Mon, 8 May 2000 14:10:27 +0530

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

> 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:
>
> Linden,
> I still dont understand what the application is. Your first note said :
>
> *************
> 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
> **************
> 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
> >

---

From: S_S_Dinesh/India/[email-masked]
Date: Mon, 8 May 2000 14:10:12 +0530

is
message
> as a SIP body for the INVITE?  This would clearly associate the sessions,

 UA1          UA2
     INVITE
 -------------->

   3xx Moved

---

From: S_S_Dinesh/India/[email-masked]
Date: Mon, 8 May 2000 14:10:14 +0530

Dean,

This is an interesting suggestion, but the scenario I'm operating under is
this:

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

> From:   Dean Willis [SMTP:[email-masked]]
> Sent:   Wednesday, March 15, 2000 2:10 PM
> To:     Linden deCarmo; [email-masked]
> Here's what I would suggest:
>
> Build a SIP UAS that understands the RTSP end and contains stream
> management
> logic. This UAS either reinvites to establish the link to RTSP streams,
or
> copies the RTP from each stream back into the media path for the remote
> UA.
>
> I know of some people(s) who are already using each approach to build a
> voice mail system that can use a standard RTSP server as a media store.
> Makes unified messaging with URL passing MUCH easier.
>
> --
> dean
>
> > From: [email-masked]
> > [mailto:[email-masked]]On Behalf Of Linden
> > deCarmo
> > Sent: Tuesday, March 14, 2000 7:27 AM
> > To: [email-masked]'
> > Subject: SIP & RTSP interworking?
> >
> >
> > What would be the proper (or suggested) procedure to tie a SIP
> > session to an
> > RTSP session?
> >
> >  However,

---

From: S_S_Dinesh/India/[email-masked]
Date: Mon, 8 May 2000 14:10:03 +0530

BOTH

Linden,

*************

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.
**************

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.

---

From: S_S_Dinesh/India/[email-masked]
Date: Mon, 8 May 2000 14:10:02 +0530

Build a SIP UAS that understands the RTSP end and contains stream
management
logic. This UAS either reinvites to establish the link to RTSP streams, or
copies the RTP from each stream back into the media path for the remote UA.

--
dean