Perhaps it would be better then to make the NetworkInterface class have a EstimateMTU method? I don't know exactly how you are moving media between your media pieces and the transport channels, but in typical libjingle the (Voice)MediaChannel has a NetworkInterface pointer that it uses to configure the transport.
On Nov 12, 7:50 am, JTM <[EMAIL PROTECTED]> wrote: > below... > > On Nov 11, 11:41 pm, Justin <[EMAIL PROTECTED]> wrote: > > > Jeff, > > > Can you give an example of what would you do with the MTU information? > > Adding what you say is probably just a matter of adding a method onto > > TransportChannel to allow you to call down from the Call layer into > > the network layer, but it's not clear that that information is needed > > up at the application layer. > > Justin, > > From our perspective, the media engine subsystem didn't belong in the > LibJingle stack, and all aspects shouldn't necessarily be managed by > channelmanager. For multiple platforms, we wanted a single LibJingle > stack -- without a slew of conditionally compiled media engines -- > which had a platform-dependent management layer above it that managed > all of the connection and call-related policy, and all platform- > dependent multimedia subsystems. This layer can make more intelligent > decisions about video sizes and framerates and bit-rates based on > specific application requirements. So this layer has full control over > the codec management, which is why it needs to know the MTU as > connections change, so we can configure the codec/RTP packetization > appropriately. > > Does that make sense? > > Thanks, > Jeff --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "google-talk-open" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/google-talk-open?hl=en -~----------~----~----~----~------~----~------~--~---
