Without looking into the proposed changes: libzrtp does not use IPv4 or IPv6 address elements. It only extends the AVPQueue and uses RTPPacket to access RTP header fields.
The same is true for the SRTP functions: no direct use of IPV4 or IPV6. However, a double check is always good :-) . Regards, Werner David Sugar wrote: > Temporarily we could introduce an internal generic address object in > ccrtp itself, and have wrappers representing the existing API that > accept the existing InetAddress/IPV6Address objects, and then translate > into the internal generic address type before calling the "real" > function. The IPV6 accepting methods that translate could be wrapped in > CCXX_IPV6 defines. This would also make the stack work for both ipv4 > and ipv6 without breaking any existing external code, but we should look > at how that would effect libzrtp. > > Federico Montesino Pouzols wrote: >> >>> I checked in my changes for ipv4/ipv6 outbound packet handling, which >>> went very well, and thought I would wait for you to comment. >> >> I would definitely do whatever requires the less amount of work. I wonder >> if introducing a common base class for v4 and v6 addresses in cc++, and >> using that for addresses lists would make it easier to solve the >> incoming queue issue. >> >> >> >> >> _______________________________________________ >> Ccrtp-devel mailing list >> [email protected] >> http://lists.gnu.org/mailman/listinfo/ccrtp-devel > > ------------------------------------------------------------------------ > > _______________________________________________ > Ccrtp-devel mailing list > [email protected] > http://lists.gnu.org/mailman/listinfo/ccrtp-devel _______________________________________________ Ccrtp-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/ccrtp-devel
