Subject: Re: [MMUSIC] WGLC: draft-ietf-mmusic-rfc2326bis-22

From: "Y.J. Gu" <[email-masked]>
Date: Wed, 09 Dec 2009 09:39:16 +0800

Hi Magnus,
How about adding a sub-section 17.2 in proxy chapter. 
Here is an example text I made. Does it make sense to you?

17.2 pipelining

The proxy may receive multiple RTSP requests, e.g. SETUP requests, from
different client and may forward them to the Server. The requests and
response will use the same TCP connection and the proxy will need to
correlate the requests to the responses. Section 10 suggest that the CSeq
may be used for such mapping but that may require the proxy to change the
CSeq numbers from the clients requests before forwarding them to the server.

A different approach is to use a solution similar to the Pipelined- Request
header by defining a Proxy-Pipeline header field that will include a unique
tag created by the proxy, and the same value will be part of both the
request and the response. The relationship between the particular tag and
client session ID is maintained by proxy so that proxy can corelate the
response from server to correct client session ID by matching tag and
transfer the response to the client.

Regards

Yingjie Gu

> -----Original Message-----
> From: Magnus Westerlund [mailto:[email-masked]] 
> Sent: Monday, November 02, 2009 12:06 AM
> To: Y.J. Gu
> Cc: 'Joerg Ott'; [email-masked]; 'Jean-Francois Mule'; 
> 'Martin Stiemerling'
> Subject: Re: [MMUSIC] WGLC: draft-ietf-mmusic-rfc2326bis-22
> 
> Hi,
> 
> I agree about expanding the proxy chapter. How the proxy 
> really keep tracks of stuff is implementation specific as 
> long as what is sent out in both directions are following the 
> spec and consistent. But we can clearly hint at some solutions.
> 
> /Magnus
> 
> Y.J. Gu skrev:
> > Hi all,
> > According to the discussion in the mailing list, there exist some 
> > confusions on proxy and CSeq. I conclude the confusions as 
> below. Pls 
> > feel free to correct my understanding.
> > 
> > 1.  How Cseq series should be organized on proxy when the proxy 
> > aggregates several RTSP sessions. Magnus has answered this question 
> > and I suggest to make the text in Section 16.19 clearer.
> > 
> > 2.  Is Cseq a good way to matching responses to requests if the 
> > requests are pipelined? I have gave an implementation and explains 
> > that Cseq could work but relies on the TCP connection in some case. 
> > Pls refer to my post in 2009-9-10. I think, as a protocol, 
> RTSP should 
> > not bind tightly to any transport protocol.
> > 
> > 
> > So I suggest that we expand on the proxies charter. How 
> about adding a 
> > subsection 17.2 to discuss Proxy aggregating multiple RTSP sessions 
> > and give another optional solution other than Cseq. Cseq is 
> useful in 
> > some cases, but might there be an easier and clearer one 
> that can also 
> > achieve the goal? My gut feeling is that a local 
> identifier, generated 
> > by proxy and included without change in both request and 
> response, may 
> > help proxy match requests&responses. Proxies assign a local 
> identifier to each new session.
> > Cseq can be used as well for any intention rather than 
> matching R/r. 
> > 
> 
> -- 
> 
> Magnus Westerlund
> 
> IETF Transport Area Director
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  +46 10 7148287
> Färögatan 6                | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden| mailto: [email-masked]
> --------------------------------------------------------------
> --------

---

From: "Y.J. Gu" <[email-masked]>
Date: Wed, 09 Dec 2009 11:30:23 +0800

Seems that my post was missing. So post again :)

Hi Magnus,

17.2 pipelining

Regards

Yingjie Gu