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

From: Jouni Mäenpää <[email-masked]>
Date: Wed, 09 Jun 2010 19:22:28 +0300

Hi,

We have just submitted a new version of draft-lindquist-sip-rtsp:

http://www.ietf.org/id/draft-lindquist-sip-rtsp-02.txt

In the new version, we have addressed a number of comments sent
to the list. More responses inline.

Best Regards,
Jouni Maenpaa

Martin Stiemerling wrote:

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

[Jouni] We have now tried to clarify this in the draft.

>>> - 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.
>
> I would be happy to have this included, as it just reflects the status
> of the draft. However, let the IESG decide.

[Jouni] Ok.

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

[Jouni] We have now introduced a new SDP attribute to carry RTSP version
information.

>>> - 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."
>> 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.
>
> It is not misleading, it is just wrong. I'm fine if this is fixed.

[Jouni] It was fixed.

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

[Jouni] This was clarified in the new version.

>>> - 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.
>>
> Ok, I see.

[Jouni] This was clarified as well.

>>> - 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.
>
> Extending existing protocols can turn them in new protocols,
> especially if extending means omitting protocol methods and state
> transitions.

[Jouni] We kept the term "lightweight RTSP" for now.

---

From: "Martin Stiemerling" <[email-masked]>
Date: Tue, 29 Jun 2010 14:16:08 +0200

Hi,

I have read the draft and it looks much better now.

Thanks for the update!

  Martin

[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 

> -----Original Message-----
> From: Jouni Mäenpää [mailto:[email-masked]]
> Sent: Wednesday, June 09, 2010 6:22 PM
> To: Martin Stiemerling
> Cc: Rajagopal Priya-W00138; Jan Lindquist; xavier.marjou@orange-
> ftgroup.com; mmusic (E-mail); [email-masked]
> Subject: Re: [MMUSIC] Review of draft-lindquist-sip-rtsp-01.txt
> 
> Hi,
>