Subject: [MMUSIC] Review of draft-lindquist-sip-rtsp-01.txt

From: "Martin Stiemerling" <[email-masked]>
Date: Wed, 26 May 2010 11:54:24 +0200

Hi all,

In the past, there were some discussions about how to couple SIP and RTSP. This was discussed in the drafts:
- draft-whitehead-mmusic-SIP-for-streaming-media-03.txt (presented at IETF-71)
- draft-lindquist-sip-rtsp-00.txt (presented at IETF-75)

A new revision of draft-lindquist-sip-rtsp-00.txt is now in the RFC editor's queue in the Independent Submission Review (ISR), i.e., without going through a WG review process. 
(http://www.rfc-editor.org/internet-drafts/draft-lindquist-sip-rtsp-01.txt)

Both drafts have not received consensus to be moved forward in the MMUISC WG, this is at least my understanding by reading the meeting minutes of the MMUSIC sessions at IETF-71 and IETF-75. This is also acknowledged by the authors in Section 1:
   The conclusion of the
   discussions triggered by the drafts has been that there is no
   consensus that SIP/RTSP interaction is something that should be
   specified in the MMUSIC working group or any other working group of
   the IETF.  Hence, the authors decided to prepare an independent
   submission (i.e., the present document) to describe the solution
   specified by ETSI TISPAN.

Anyhow, here is brief and unsolicited review of draft-lindquist-sip-rtsp-01.txt:

- Title: This should reflect that this is a specific ETSI/3GPP mechanism of how to couple SIP and RTSP. The current title suggests that this is an IETF agreed way of doing this. 
Suggestion:
"Controlling Session Initiation Protocol (SIP)-Established Content Delivery Channels Using the Real-Time Streaming Protocol (RTSP) in ETSI and 3GPP deployments". 

- The draft proposes to add a new SDP 'proto' field with values "TCP/ETSI_RTSP (used when RTSP runs directly on top of TCP) and TCP/TLS/ETSI_RTSP". 
How does this mechanism ensure a proper versioning for future RTSP versions? RTSP 2.0 seems not to be too far away anymore...

- general: how is the content identified in SIP, e.g., how do I tell what content I want to watch? 

- general: you're ripping off SETUP and TEARDOWN from RTSP, which is by the way not RTSP anymore. However, what are the changes to the RTSP state machine? 

- general: the term "lightweight RTSP" suggests that this makes RTSP easier and that this is still RTSP. However, this may be you personal perception, but is for sure not true in general, as RTSP is not RTSP anymore (you're changing the base protocol). This would call for another RTSP version and or a new protocol! 

- Section 8.1.1 step 6 of the session setup: if RTSP's SETUP is not used, how does the client figure out what features the server supports and what features for a particular media he is supporting? (you could use OPTIONS, but this adds more to the startup delay...)

- Section 8.1.3 "Session Termination": Step 1 is not RTSP 1.0. Closing the RTSP TCP connection to the media server is NEVER closing a RTSP session. See RFC 2326, , Section 1.1, 3rd paragraph:
"An RTSP session is in no way tied to a transport-level connection
such as a TCP connection. During an RTSP session, an RTSP client
may open and close many reliable transport connections to the server
to issue RTSP requests."

- 8.1.4.2.1.  DNS Lookup for RTSP URL: requires a change to the RTSP client, as DNS names are not allowed to be resolved. 
Why you are not just delivering IP addresses back to the UE within the rtsp/rtspu URLs? This will not required changes to the protocol or protocol semantics, but is solely a policy/configuration issue.

- 8.2.4.2.2.  Redirection: I do not understand the issue you're describing:
" If an RTSP
   REDIRECT request or Redirection status code is later issued on the
   RTSP control channel, the SIP ALG may never learn the address of the
   new server.  This is because the SIP ALG may not inspect RTSP
   messages.  The result is that new pinholes will not be opened for the
   RTSP control channel and the media delivery stream(s) coming from the
   new server.
"
Are you not in full control of the RTSP server and thus in full control of the server's behavior?

- Section 8.2.4.3: Session Termination  and coupling of SIP BYE and RTSP TEARDOWN. 
Can you elaborate a bit more on why this is an issue? Given that the client cannot send a TEARDOWN, it should be still sufficient to send a BYE. The SIP AS can still instruct the RTSP server via the media server control interface to release the RTSP session for that particular client.

- Section 11 "Examples": All your SDP examples are only with one video media. But how do you transfer multiple medias and their relationship to each other and to the RTSP URLs (e.g., aggregated vs. non-aggregated medias)?

This draft would need IMHO a good technical explanation why the full RTSP method is not sufficient to fit ETSI's needs of coupling SIP and RTSP. The "lightweight RTSP" is not using RTSP anymore, but a derivate of the original RTSP 1.0 protocol. 

With best regards,

  Martin Stiemerling

[email-masked]

NEC Laboratories Europe - Network Research Division
NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014

---

From: Jan Lindquist <[email-masked]>
Date: Wed, 26 May 2010 16:05:49 +0200

Hello Martin,

Thank you for your comments.

I would like to respond your last comment first since it questions the purpose of the draft.

The intention with this draft is not to say which of the two methods have greater merit. This draft simply reflects what is standardized in other forums and is currently deployed. Additionally there have been several plug-fests using these solution. In order to avoid future issues the new protocol type has to be registered with IANA. Following the registrations rules an informative rfc has to be written reflecting the use.

Regards,
JanL

> -----Original Message-----
> From: Martin Stiemerling [mailto:[email-masked]] 
> Sent: Wednesday, May 26, 2010 11:54 AM
> To: Jan Lindquist; Jouni Mäenpää; 
> [email-masked]; 
> [email-masked]; mmusic (E-mail)
> Subject: Review of draft-lindquist-sip-rtsp-01.txt
> 
> Hi all,
> 
> In the past, there were some discussions about how to couple 
> SIP and RTSP. This was discussed in the drafts:
> A new revision of draft-lindquist-sip-rtsp-00.txt is now in 
> the RFC editor's queue in the Independent Submission Review 
> (ISR), i.e., without going through a WG review process. 
> Both drafts have not received consensus to be moved forward 
> in the MMUISC WG, this is at least my understanding by 
> reading the meeting minutes of the MMUSIC sessions at IETF-71 
> and IETF-75. This is also acknowledged by the authors in Section 1:
>    The conclusion of the
> - Title: This should reflect that this is a specific 
> ETSI/3GPP mechanism of how to couple SIP and RTSP. The 
> current title suggests that this is an IETF agreed way of doing this. 
> Suggestion:
> "Controlling Session Initiation Protocol (SIP)-Established 
> Content Delivery Channels Using the Real-Time Streaming 
> Protocol (RTSP) in ETSI and 3GPP deployments". 

It was not our intention to suggest this is the ietf agreed way. The abstract and introduction gives a very clear explanation of the deployments using this mechanism. We can consider renaming to make it clearer if that is the response from IESG.

> 
> - The draft proposes to add a new SDP 'proto' field with 
> values "TCP/ETSI_RTSP (used when RTSP runs directly on top of 
> TCP) and TCP/TLS/ETSI_RTSP". 
> How does this mechanism ensure a proper versioning for future 
> RTSP versions? RTSP 2.0 seems not to be too far away anymore...

The version aspect is something that was discussed in TISPAN. When we introduce version 2 then we will definitely add a mechanism so the current proto assumes version 1. You are welcome to liaison to TISPAN and ask when version 2 is planned to be introduced.

> I tell what content I want to watch? 

How content is idenfieid is within the architecture and standards used by the different deployments. TISPAN, 3GPP and OIPF may have slightly different approaches. I can forward links to the respective specifications if you need more details.

> 
> - general: you're ripping off SETUP and TEARDOWN from RTSP, 
> which is by the way not RTSP anymore. However, what are the 
> changes to the RTSP state machine? 

We are simply using parts of the RTSP signalling and do not claim to follow the RTSP state machine.

> 
> - general: the term "lightweight RTSP" suggests that this 
> makes RTSP easier and that this is still RTSP. However, this 
> may be you personal perception, but is for sure not true in 
> general, as RTSP is not RTSP anymore (you're changing the 
> base protocol). This would call for another RTSP version and 
> or a new protocol! 

The term lightweight simply tried to differentiate itself. We are not trying to create a new protocol but simply extend it with different behaviour. Both method described extend the behaviour of the base RTSP as you point out in later points.

> 
> - Section 8.1.1 step 6 of the session setup: if RTSP's SETUP 
> is not used, how does the client figure out what features the 
> server supports and what features for a particular media he 
> is supporting? (you could use OPTIONS, but this adds more to 
> the startup delay...)

The SIP OPTIONS provides the additional information that may be needed. It can easily be compared to the RTSP DESCRIBE and how it provides the features for a particular media.

> 
> - Section 8.1.3 "Session Termination": Step 1 is not RTSP 
> 1.0. Closing the RTSP TCP connection to the media server is 
> NEVER closing a RTSP session. See RFC 2326, , Section 1.1, 
> 3rd paragraph:
> "An RTSP session is in no way tied to a transport-level 
> connection such as a TCP connection. During an RTSP session, 
> an RTSP client may open and close many reliable transport 
> connections to the server to issue RTSP requests."

I may need to take a closer look at this aspect and come back to you.

> 
> - 8.1.4.2.1.  DNS Lookup for RTSP URL: requires a change to 
> the RTSP client, as DNS names are not allowed to be resolved. 
> Why you are not just delivering IP addresses back to the UE 
> within the rtsp/rtspu URLs? This will not required changes to 
> the protocol or protocol semantics, but is solely a 
> policy/configuration issue.

We support both approaches but some companies felt in TISPAN that they wanted to use a domain address. This is the reason we had to add this requirement which applies to both methods.

> full control of the server's behavior?

This is an architecture aspect and depends on the deployment. In some cases the content provider is seperate from the service provider and such full control is not possible. I would say that if there is full control then there wouldn't be a redirection.

> Can you elaborate a bit more on why this is an issue? Given 
> that the client cannot send a TEARDOWN, it should be still 
> sufficient to send a BYE. The SIP AS can still instruct the 
> RTSP server via the media server control interface to release 
> the RTSP session for that particular client.

I agree that the SIP AS can instruct the media server to release the session. A note can be added to reflect this aspect.

> 
> - Section 11 "Examples": All your SDP examples are only with 
> one video media. But how do you transfer multiple medias and 
> their relationship to each other and to the RTSP URLs (e.g., 
> aggregated vs. non-aggregated medias)?

We can look into adding an example with multiple media lines.

> 
> 
> This draft would need IMHO a good technical explanation why 
> the full RTSP method is not sufficient to fit ETSI's needs of 
> coupling SIP and RTSP. The "lightweight RTSP" is not using 
> RTSP anymore, but a derivate of the original RTSP 1.0 protocol. 

Responded in the beginning of the e-mail.

> NEC Laboratories Europe - Network Research Division NEC 
> Europe Limited | Registered Office: NEC House, 1 Victoria 
> Road, London W3 6BL | Registered in England 2832014 
> 
> 
>

---

From: "Rajagopal Priya-W00138" <[email-masked]>
Date: Thu, 27 May 2010 08:01:29 -0400

Hi Martin

Some additional thoughts on the following points. 

> 
> > - Section 8.1.1 step 6 of the session setup: if RTSP's SETUP is not 
> > used, how does the client figure out what features the
> server supports
> > and what features for a particular media he is supporting? 
> (you could
> > use OPTIONS, but this adds more to the startup delay...)
> 
JAN> The SIP OPTIONS provides the additional information that may be 
> needed. It can easily be compared to the RTSP DESCRIBE and how it 
> provides the features for a particular media.
> 
PRIYA> In addition, other methods such as service discovery &
selection (SD&S)/ service access procedures for delivering such 
information  is also possible. 

> 1.0. Closing
> > the RTSP TCP connection to the media server is NEVER closing a RTSP 
> > session. See RFC 2326, , Section 1.1, 3rd paragraph:
> > such as a TCP connection. During an RTSP session, an RTSP
> client may
> > open and close many reliable transport connections to the server to 
> > issue RTSP requests."
> 
JAN> I may need to take a closer look at this aspect and come back to you.
PRIYA> I agree that the text "The UE closes the RTSP session that was  established during
        session initiation by closing the underlying TCP connection.'is bit
 misleading and we can rephrase that. The session is closed in STEP2 when SIP 
 BYE is initiated. SIP BYE releases RTSP and SIP resources.

> that the
> > client cannot send a TEARDOWN, it should be still
> sufficient to send a
> > BYE. The SIP AS can still instruct the RTSP server via the media 
> > server control interface to release the RTSP session for that 
> > particular client.
> 
JAN> I agree that the SIP AS can instruct the media server to release the 
> session. A note can be added to reflect this aspect.
> 
PRIYA: I think we ae missing the point here. The main point discussed is 
that if the RTSP TEARDOWN and SIP BYE are not co-ordinated such that
TEARDOWN always precedes SIP BYE, it can lead to unexpected system behavior.
As suggested above, if RTSP session teardown were to take place when RTSP server receives 
 a SIP BYE instead of a TEARDOWN , then the behavior of RTSP server is no
 different than that of the lightweight RTSP server . And that's exactly what 
we were getting that  when we stated "Teardown of the streaming session will
not always be possible   according to the procedures defined 
in [RFC2326]." . If you have suggestions for rewording, let us know.

Regards
-Priya

Priya Rajagopal
Mobile Devices & Home Technology Office, Motorola Inc. USA

Contact: 
1800 Meadowside Drive
Ann Arbor, MI 48104,USA

Cell: (508)250-7446
Fax: (734)369-8034

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jan Lindquist
Sent: Wednesday, May 26, 2010 10:06 AM
To: Martin Stiemerling; Jouni Mäenpää; [email-masked]; [email-masked]; mmusic (E-mail)
Cc: [email-masked]
Subject: Re: [MMUSIC] Review of draft-lindquist-sip-rtsp-01.txt

Hello Martin,

Regards,
JanL

> A new revision of draft-lindquist-sip-rtsp-00.txt is now in the RFC 
> editor's queue in the Independent Submission Review (ISR), i.e., 
> without going through a WG review process.
> Both drafts have not received consensus to be moved forward in the 
> MMUISC WG, this is at least my understanding by reading the meeting 
> minutes of the MMUSIC sessions at IETF-71 and IETF-75. This is also 
> acknowledged by the authors in Section 1:
>    The conclusion of the
> - Title: This should reflect that this is a specific ETSI/3GPP 
> mechanism of how to couple SIP and RTSP. The current title suggests 
> that this is an IETF agreed way of doing this.
> Suggestion:
> "Controlling Session Initiation Protocol (SIP)-Established Content 
> Delivery Channels Using the Real-Time Streaming Protocol (RTSP) in 
> ETSI and 3GPP deployments".

> 
> - The draft proposes to add a new SDP 'proto' field with values 
> "TCP/ETSI_RTSP (used when RTSP runs directly on top of
> How does this mechanism ensure a proper versioning for future RTSP 
> versions? RTSP 2.0 seems not to be too far away anymore...

> 
> - general: you're ripping off SETUP and TEARDOWN from RTSP, which is 
> by the way not RTSP anymore. However, what are the changes to the RTSP 
> state machine?

> 
> - general: the term "lightweight RTSP" suggests that this makes RTSP 
> easier and that this is still RTSP. However, this may be you personal 
> perception, but is for sure not true in general, as RTSP is not RTSP 
> anymore (you're changing the base protocol). This would call for 
> another RTSP version and or a new protocol!

> 
> - Section 8.1.1 step 6 of the session setup: if RTSP's SETUP is not 
> used, how does the client figure out what features the server supports 
> and what features for a particular media he is supporting? (you could 
> use OPTIONS, but this adds more to the startup delay...)

> 
> - Section 8.1.3 "Session Termination": Step 1 is not RTSP 1.0. Closing 
> the RTSP TCP connection to the media server is NEVER closing a RTSP 
> session. See RFC 2326, , Section 1.1, 3rd paragraph:
> such as a TCP connection. During an RTSP session, an RTSP client may 
> open and close many reliable transport connections to the server to 
> issue RTSP requests."

> 
> - 8.1.4.2.1.  DNS Lookup for RTSP URL: requires a change to the RTSP 
> client, as DNS names are not allowed to be resolved.
> Why you are not just delivering IP addresses back to the UE within the 
> rtsp/rtspu URLs? This will not required changes to the protocol or 
> protocol semantics, but is solely a policy/configuration issue.

> Can you elaborate a bit more on why this is an issue? Given that the 
> client cannot send a TEARDOWN, it should be still sufficient to send a 
> BYE. The SIP AS can still instruct the RTSP server via the media 
> server control interface to release the RTSP session for that 
> particular client.

> 
> - Section 11 "Examples": All your SDP examples are only with one video 
> media. But how do you transfer multiple medias and their relationship 
> to each other and to the RTSP URLs (e.g., aggregated vs. 
> non-aggregated medias)?

> 
> 
> This draft would need IMHO a good technical explanation why the full 
> RTSP method is not sufficient to fit ETSI's needs of coupling SIP and 
> RTSP. The "lightweight RTSP" is not using RTSP anymore, but a derivate 
> of the original RTSP 1.0 protocol.

> NEC Laboratories Europe - Network Research Division NEC Europe Limited 
> | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | 
> Registered in England 2832014
> 
> 
> 
_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Jouni Mäenpää <[email-masked]>
Date: Thu, 27 May 2010 17:25:35 +0300

Hi Martin,

> - draft-lindquist-sip-rtsp-00.txt (presented at IETF-75)

Correct. We are also explaining this and referring to the earlier
documents in the present draft.

> minutes of the MMUSIC sessions at IETF-71 and IETF-75.

We are using the independent submission stream precisely because there
was no consensus to move the draft forward in MMUSIC. The purpose of
this draft is to simply describe the SIP/RTSP solution specified by ETSI
TISPAN. This is why the intended status of the draft is informational.
Another purpose of the draft is to register with IANA the new SDP
'proto' field values "TCP/ETSI_RTSP" and "TCP/TLS/ETSI_RTSP" and a few
new SDP attributes. As far as I know, an informational RFC submitted to
the independent submission stream is sufficient for these registrations.

Cheers,
Jouni

---

From: "Martin Stiemerling" <[email-masked]>
Date: Fri, 28 May 2010 15:00:08 +0200

Hi Jan, all,

> From: Jan Lindquist [mailto:[email-masked]]
> Sent: Wednesday, May 26, 2010 4:06 PM
> To: Martin Stiemerling; Jouni Mäenpää; [email-masked];
> Subject: RE: Review of draft-lindquist-sip-rtsp-01.txt
> 
> Hello Martin,
> 
> The intention with this draft is not to say which of the two methods
> have greater merit. This draft simply reflects what is standardized in
> other forums and is currently deployed. Additionally there have been
> several plug-fests using these solution. In order to avoid future
> issues the new protocol type has to be registered with IANA. Following
> the registrations rules an informative rfc has to be written reflecting
> the use.

The real intention wasn't clear to me, as especially the part about "MMUSIC does not see this as a way forward" sounds a bit such "we're now taking a diversion to avoid MMUSIC". Furthermore, there is a lot about ETSI and 3GPP but for a pure IETF person like me, the real intention and relationship to SIP and RTSP are not fully clear to me. 

I would propose to add a statement more along the lines, that this was brought to the attention of the  MMUSIC WG as two ways of combining SIP and solely reflects the ETSI TISPAN outcome. Second, that the intention of this memo is to allocated SDP codepoints for the proposed methods. Third, there is no intention to change the RTSP protocol defined in RFC 2326. 

> It was not our intention to suggest this is the ietf agreed way. The
> abstract and introduction gives a very clear explanation of the
> deployments using this mechanism. We can consider renaming to make it
> clearer if that is the response from IESG.

I would be happy to have this included, as it just reflects the status of the draft. However, let the IESG decide.

> The version aspect is something that was discussed in TISPAN. When we
> introduce version 2 then we will definitely add a mechanism so the
> current proto assumes version 1. You are welcome to liaison to TISPAN
> and ask when version 2 is planned to be introduced.

This is a no good way IMHO. ETSI will run into issues once somebody comes up with  either a new RTSP, SIP, or your SIP/RTSP-combination version and you need to differentiate deployed versions. Better do it now. 

> How content is idenfieid is within the architecture and standards used
> by the different deployments. TISPAN, 3GPP and OIPF may have slightly
> different approaches. I can forward links to the respective
> specifications if you need more details.

This would be great! 

> follow the RTSP state machine.

Indeed there is no text stating that you claim compliance with the RFC 2326 state machine (which is informational anyhow, but at least gives a rough way of how this works).  

However, you still say that you are using RTSP, which isn't true for the "lightweight RTSP" version. Anyhow, I might be too picky about this. 

> The term lightweight simply tried to differentiate itself. We are not
> trying to create a new protocol but simply extend it with different
> behaviour. Both method described extend the behaviour of the base RTSP
> as you point out in later points.

Extending existing protocols can turn them in new protocols, especially if extending means omitting protocol methods and state transitions. 

[...]
> We support both approaches but some companies felt in TISPAN that they
> wanted to use a domain address. This is the reason we had to add this
> requirement which applies to both methods.

Ok, I see. 

> This is an architecture aspect and depends on the deployment. In some
> cases the content provider is seperate from the service provider and
> such full control is not possible. I would say that if there is full
> control then there wouldn't be a redirection.

Ok, having separate entities might really result in redirects.

> 
> >
> > - Section 8.2.4.3: Session Termination  and coupling of SIP
> > BYE andRTSP TEARDOWN.
> I agree that the SIP AS can instruct the media server to release the

thanks.

Kind regards,

  Martin

---

From: "Martin Stiemerling" <[email-masked]>
Date: Fri, 28 May 2010 15:06:20 +0200

Hi Priya, 

> From: Rajagopal Priya-W00138 [mailto:[email-masked]]
> Sent: Thursday, May 27, 2010 2:01 PM
> To: Jan Lindquist; Martin Stiemerling; Jouni Mäenpää; Rajagopal Priya-
> W00138; [email-masked]; mmusic (E-mail)
> Subject: RE: [MMUSIC] Review of draft-lindquist-sip-rtsp-01.txt
> 
> Hi Martin
> 

I don't see this, as the media description delivers necessarily information for the RTSP clients and the RTP subsystem. 

>  BYE is initiated. SIP BYE releases RTSP and SIP resources.

It is not misleading, it is just wrong. I'm fine if this is fixed.

> in [RFC2326]." . If you have suggestions for rewording, let us know.

I see the point, but the "unexpected system behavior" in this case is that the RTSP server sends a " 454  Session Not Found" to the UE. This doesn't look like as "unexpected system behavior" to me.

 Martin

---

From: "Martin Stiemerling" <[email-masked]>
Date: Fri, 28 May 2010 15:08:51 +0200

Hi Jouni,

> From: Jouni Mäenpää [mailto:[email-masked]]
> Sent: Thursday, May 27, 2010 4:26 PM
> To: Martin Stiemerling
> Cc: Rajagopal Priya-W00138; Jan Lindquist; xavier.marjou@orange-
> ftgroup.com; mmusic (E-mail); [email-masked]

Yes indeed, this part was more meant for the MMUSIC WG as a refresher and not as this was missing in the draft. 

> the independent submission stream is sufficient for these

This wasn't that obvious for me just by reading the draft and is still not that obvious for a random IETF participating in the draft. 

If this could be fixed in the draft, that would be great.

Thanks,

  M
aArtin

---

From: "Rajagopal Priya-W00138" <[email-masked]>
Date: Fri, 28 May 2010 10:13:11 -0400

Hi Martin

Some additional clarifications-

Priya: Its possible.Mapping of information carried by DVB SD&S , OMA BCAST records to SDP information is an example. This is described by ETSI TISPAN TS 183 063. 

> PRIYA: I think we ae missing the point here. The main point discussed 
> is that if the RTSP TEARDOWN and SIP BYE are not co-ordinated such 
> that TEARDOWN always precedes SIP BYE, it can lead to unexpected 
> system behavior.
> As suggested above, if RTSP session teardown were to take place when 
> RTSP server receives  a SIP BYE instead of a TEARDOWN , then the 
> behavior of RTSP server is no  different than that of the lightweight 
> RTSP server . And that's exactly what we were getting that  when we 
> stated "Teardown of the streaming session will

Priya: The RTSP messages will not even go through. When SIP session tears down , the network resources allocated for RTSP session will go away (for instance, the pinholes opened for the RTSP flows will be closed). 

regards
-Priya

-----Original Message-----
From: Martin Stiemerling [mailto:[email-masked]] 
Sent: Friday, May 28, 2010 9:06 AM
To: Rajagopal Priya-W00138; Jan Lindquist; Jouni Mäenpää; [email-masked]; mmusic (E-mail)
Cc: [email-masked]
Subject: RE: [MMUSIC] Review of draft-lindquist-sip-rtsp-01.txt

Hi Priya, 

> > > - Section 8.1.1 step 6 of the session setup: if RTSP's SETUP is 
> > > not used, how does the client figure out what features the
> > server supports

> > > the RTSP TCP connection to the media server is NEVER closing a 
> > > RTSP session. See RFC 2326, , Section 1.1, 3rd paragraph:
> > > open and close many reliable transport connections to the server 
> > > to issue RTSP requests."
> >
>         session initiation by closing the underlying TCP 
> connection.'is bit  misleading and we can rephrase that. The session 
> is closed in STEP2 when SIP  BYE is initiated. SIP BYE releases RTSP 
> and SIP resources.

> PRIYA: I think we ae missing the point here. The main point discussed 
> is that if the RTSP TEARDOWN and SIP BYE are not co-ordinated such 
> that TEARDOWN always precedes SIP BYE, it can lead to unexpected 
> system behavior.
> As suggested above, if RTSP session teardown were to take place when 
> RTSP server receives  a SIP BYE instead of a TEARDOWN , then the 
> behavior of RTSP server is no  different than that of the lightweight 
> RTSP server . And that's exactly what we were getting that  when we 
> stated "Teardown of the streaming session will

 Martin