< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index Next in Thread >

Re: [recon-devel] recon contribution


I found these two functions in the QosManagerSocket.cxx, seems it not be implemented, currently the setsocketopt is not effect for windows XP and Vista, 2003, windows 7 etc. And the traffic control api is marked deprecated, so I think the QOS2 is the better choice for windows platform.


 // these methods may be called to set the QOS values on a socket
   virtual bool SocketSetDSCP(resip::Socket s, int DSCPValue, bool bUDP)
   { 
      return false;
   }

   virtual bool SocketSetServiceType(
      resip::Socket s,
      const asio::ip::udp::endpoint &tInDestinationIPAddress,
      EQOSServiceTypes eInServiceType,
      ULONG ulInBandwidthInBitsPerSecond,
      bool bUDP)
   {
      return false;
   }


On Sat, Jan 30, 2010 at 11:13 AM, Karlsson <boost.regex@xxxxxxxxx> wrote:
Hi Jeremy, thanks for your work, I've checked the branch, but I don't found the implementation of setDSCP function, just found two pure virtual in 
AsyncSokcetBase.hxx,

   virtual bool setDSCP(ULONG ulInDSCPValue) = 0;
   virtual bool setServiceType(
      const asio::ip::udp::endpoint &tInDestinationIPAddress,
      EQOSServiceTypes eInServiceType,
      ULONG ulInBandwidthInBitsPerSecond) = 0;


So means current still don't support QoS, just added the interface, right ?

Thanks



On Sat, Jan 30, 2010 at 9:56 AM, Jeremy Geras <jgeras@xxxxxxxxxxxxxxx> wrote:

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

 

 

 

 

 


_______________________________________________
recon-devel mailing list
recon-devel@xxxxxxxxxxxxxxx
List Archive: http://list.resiprocate.org/archive/recon-devel/