Joerg, I respect your reasons. Taking your suggestion I could suggest opening a TCP connection and using it for H.245 messages and I have a solution. BTW this was Christer (from Ericsson) suggestion. We had this in H.323 as a separate connection but we found out that it is a problem for FW/NATs and for call managers who needed more ports so we ended up tunneling H.245 in the H.225 call signaling channel. What I am saying that no solution is the best solution and each has it draw backs. Roni
-----Original Message----- From: Joerg Ott [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 01, 2004 1:34 AM To: Even, Roni Cc: Joerg Ott; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [Sip-implementors] Video Fast Update IntraFrame Request Roni, I agree that the feedback draft does not solve the request issue -- it is not meant to. I would like to point out though that, just because an I-D of something exists and so does an implementation which works for some scenario, this does not imply that this is a suffciently general solution and that it is, should, or will be blessed in the IETF. Specifying some XML format to convey a command is trivial. Getting the protocol framework right to make this applicable throughout the Internet is the tricky part. SIP INFO _does_not_ solve this problem. Yes, it allows you to get information from A to B. But you may pass a number of SIP proxies on the way that are supposed to do call routing rather than forwarding video commands leading to (at least) the two -- repeatedly discussed -- effects that your packets may take longer than when sent directly because proxies form an overlay network and may be further delayed because of "queuing" in proxies (to which they contribute by uncessarily loading them). This may work well today in your target environment but may not necessarity do tomorrow. A better approach would be setting up a suitable transport connection directly between the endpoints using e.g. comedia (if you get RTP through, you should get others through, too). Then you can define some meaningful (minimum) framing and carry your XML payload. If you parse XML and speak e.g. TCP anyway, adding another transport is not going to be an issue. And this would be independent of SIP! Whether you use another transport, I do not care. So, please let address the real problems rather than repeating discussions of some semi-workable hack. (BTW: SIP INFO is not even an interim solution until we got the other part sorted out because then you ultimately have to support both.) Joerg Even, Roni wrote: > Hi, > The current state is that the feedback draft does not solve a request for an > Intra frame from the receiver but just serves as an indication. The draft > that Joerg points to also mentions that in H.323 the solution is in the > signaling path and very sadly could not reference any such solution for SIP. > I do no want to start the argument but the current state is there > implementation of the draft-levin-mmusic-xml-schema-media-control-03 while > for SIP video conferencing products while there are no implementations of > the feedback based solution. > Roni Even > _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
