----- Original Message ----- > From: "Dmitry Melekhov" <[email protected]> > To: "Asterisk Users Mailing List - Non-Commercial Discussion" > <[email protected]> > Sent: Sunday, July 29, 2012 10:44:42 PM > Subject: Re: [asterisk-users] Video conferencing? > > 27.07.2012 19:25, Matthew Jordan пишет:
> > As I said in our previous conversation, we don't currently have > > plans > > to implement a re-transmission of a new source's I-Frame, or delay > > switching of the video source until an I-Frame from the new source > > arrives. > > I wouldn't characterize that as a "refusal". I was simply > > informing you of > > the actual state of affairs: we do not have plans at this time to > > implement > > this feature. > > Well, from my point of view this is refusal , just because this is > real > result :-) I don't normally say something this blunt, but your point of view is wrong. Let me illustrate: Feature is Planned: Person A: Do you have plans to implement feature Y? Developer B: Yes, we do, and it will be in Product version Z. Feature is not Planned: Person A: Do you have plans to implement feature Y? Developer B: No, not at this time. We've thought about it, but it currently looks like it will frob a widget. Since people really like their widgets, it isn't in a planned development cycle. Refusal of Feature: Person A: Do you have plans to implement feature Y? Developer B: No, and we never will, because feature Y will cause baby penguins to cry. See the difference? Now lets look at what I actually told you several months ago: "That being said, we do not have plans at this time to perform transcoding on the video streams. There's a number of reasons for this, most notably that to do so is incredibly resource intensive. Is that what you were referring to?" I can't predict everything that is going to be in a future version of Asterisk. We have some amazingly talented developers in the community contributing to the project. They may choose to do the *very* thing you asked for. But since we at Digium haven't planned to do the thing you asked for, telling you we at Digium did have a plan to do it would be disingenuous. Does that mean it will never happen? No, it could very well happen. I outlined some technical reasons why we haven't done some of the things that you're asking for, but those technical reasons could go away. Server performance has certainly changed during the lifetime of Asterisk, so the assumptions we make about the capabilities of the hardware the Asterisk runs on could also change. We could also decide that we're willing to live with some of the performance penalties, or we could decide to re-architect the RTP stack to assist with some minor 'inspection' of the data contained in a packet without fully decoding and manipulating all of the data. But we hadn't planned to do that for Asterisk 11, so I didn't say we were. As I mentioned, AstriCon is where we typically plan out new features. Who knows, it may be something the Asterisk development community looks at in the coming year. Since the planning hasn't happened yet, I don't know the answer to that. > We did tests with jitsi, just because it is mentioned as tested in > asterisk wiki. > ( https://wiki.asterisk.org/wiki/display/AST/ConfBridge+10 ) > I don't know does it support rfc5168 :-( It does. You have to configure it properly. Click on the advanced button, go to H.264, and select "Signaling" in the "Preferred method to request key frames" option. Unfortunately, Asterisk does not have full support for AVPF, and so it will not request intra-frames over RTCP, which is Jitsi's default option. (Note: it is much more likely that someone would be willing to take a look at fully implementing that RFC then doing some manipulation of the intra-frames inside Asterisk itself. Do not construe this message as a promise to do so however) > > 2. If you get a SIP trace or a packet capture, do you see Asterisk > > sending the SIP INFO messages when a video update occurs?" > > Don't know too. Wireshark: http://www.wireshark.org/ Barring that, you can see the SIP messages Asterisk sends out with "sip set debug on". > > Since I never got a concrete answer to those questions, I'll ask > > again: > > > > Do your clients support RFC 5168? If not, do you have significant > > problems > > with clients that do support RFC 5168? > > Could you point me to client with such support? > I see no info about this on link above. Quick googling turned up Ekiga, linphone, LifeSize communicator, Grandstream GXV3140. Visual inspection confirmed it for Jitsi. -- Matthew Jordan Digium, Inc. | Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
