| < Previous by Date | Date Index | Next by Date > |
| Thread Index | Next in Thread > |
|
Hi, I've created a branch with some significant
changes and contributions to recon. You can find it at: https://svn.resiprocate.org/rep/resiprocate/branches/cp-recon-contrib-20100125
What's
changed, and what's been added: 1) Support for multiple m= lines Currently this means one audio m= line,
plus one (optional) video m= line. 2) Support for http://tools.ietf.org/html/draft-ietf-mmusic-ice-19
ICE is so far implemented in a limited way:
·
ICE candidates are added to SDP
offers/answers, and ICE connectivity checks happen. ·
The "ice-ufrag" and
"ice-pwd" attributes are missing. ·
Currently only a single host
candidate and a single server reflexive candidate (if available) are included. ·
The ICE connectivity checks
include the mandatory attributes (e.g. IceControlled/IceControlling), but the
attributes are ignored. ·
There are many, many corner
cases from the ICE draft that are still not handled at this point in time. ·
No attempt has been made to
interop with other ICE implementations as of yet (though hopefully this will
happen before/during the next SIPit). 3) Media interfaces We've added media interfaces, and
refactored recon to use these interfaces, thus removing the direct dependency
on sipXmedia; however we haven't contributed back any implementation of these
media interfaces (any volunteers? :-) So as it stands, the recon testUA
on this branch is NOT in a working state because there is no media stack
implementation at this time. The new media interfaces support almost all
of the original media operations used with sipX, with some notable exceptions:
weights for locally mixed media, and playout of media resource types other than
DTMF. 4) ConversationManager interface changes A diff should give you a good idea of
what's changed here; some of the changes made are breaking changes, so I've
updated testUA (but not the unitTests). 5) Support for QoS An interface has been added so that applications
can hook up QoS support for the sockets managed by reflow. Future Work Here are some areas that I think are good
candidates for the focus of future work, by us and/or others: 1) Threading model Currently DialogUsageManager::post(..) is
used throughout the code in recon; in our application, DUM and recon, and our
layer above recon, are all running in the same thread, so it would be nice if
we could use a dispatch(..) type of call instead, wherein the executing thread
is checked against the current DUM thread, and the command/action is executed
immediately if the thread is the same. Similarly in reTurn there are
spots where asio::io_service::post(..) is called, when
asio::io_service::dispatch(..) could be used instead to avoid an unnecessary
queue-up of an action. 2) Possible use of memory pool in
reTurn::DataBuffer Maybe there would be some performance
benefit? (In truth it would be the reTurn server that would probably
realize some benefit here more than our softphone UA). 3) Fixes to support IPv6 Unfortunately we've added code which does
contain assumptions about everything operating over IPv4 only... So it'll
need to be fixed. 4) Testing with PRACK We haven't done much testing with the UAC
PRACK support -- so there are likely some broken cases. 5) Testing with forking and early media Additional testing required; this is a good
item for a SIPit. 6) Changes to/fixes for the
ConversationManager's notion of a ConversationProfile The ConversationProfile construct caused us
great amounts of grief initially, since we were attempting to use it to specify
things like the media direction. However it was soon apparent that most attributes
of a call had to be handled on a per-RemoteParticipant-basis. There are
still other items (like anonymous calling) that are currently tied to the
ConversationProfile which probably should not be. Building The build steps for the branch are
essentially as documented
on the wiki. I removed asio from the repository, since you can easily
download the latest asio and stick it in
place. I tested with Boost 1.41 from www.boostpro.com. Everything compiles, but as noted above,
because there is no media stack implementation, you won't get very far trying
to use the testUA at this time. Where to go
from here? I'm expecting that there will be some
period of time for others to digest what's here now, and to ask questions and
give feedback. I'll attempt to make myself as available as possible for
this. Hopefully this work won't linger on a branch for too long, and we
can get it on trunk and as part of future releases. Thanks! Jeremy -------------------------------- Jeremy Geras CounterPath Corporation |