Hi, Andrea Basso has started some work about requirements in the AVT group, see attached document Roni Even
-----Original Message----- From: Punj, Arun [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 01, 2004 7:02 PM To: 'Even, Roni'; Joerg Ott Cc: Joerg Ott; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: [Sip-implementors] Video Fast Update IntraFrame Request Folks, Is there a [in]formal group to discuss issues like Fast Video Update? I think the problem domain and network context in which the problem needs to be solved is probably different for different folks and hence we may have to have more than flavor of solution. Personally I really like that most H323 devices interwork nicely in terms of supporting fast video update. And [de]merits of signaling channel for media requests aside, it is good to have a universally supported solution. While implementing H to SIP interoperable solution we had to invent *hacks* like reINVITE/INFO methods to do the *right* thing on the SIP side. IMHO if we could capture the requirements and problem domain in some document and then set about finding solutions it would be useful. Maybe someone has already done this legwork, in which case I would sure appreciate a pointer. >From my side i would suggest following requirements: * fast updates support on even unidirectional streams [For example, surviellance cameras] * Firewall/NAT traversal * In time delivery. [ less than 1-2seconds] * Scales for multicast streams. Arun Punj ViPr Software Engineer Broadband Routing & Switching Marconi 3000 Marconi Drive Warrendale, PA 15086 Phone: 724-742-7583 [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of > Even, Roni > Sent: Wednesday, September 01, 2004 10:06 AM > To: Joerg Ott; Even, Roni > Cc: Joerg Ott; [EMAIL PROTECTED]; > [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: RE: [Sip-implementors] Video Fast Update IntraFrame Request > > > 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 >
_______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
