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

From: Magnus Westerlund <[email-masked]>
Date: Sun, 01 Nov 2009 17:06:17 +0100

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: Tue, 03 Nov 2009 10:50:30 +0800

Hi Magnus,
Thank you.
It'll be helpful to hint at some solutions.

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