reSIProcate

Mailing Lists

Source Code

Google Search:



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

Re: [reSIProcate] UAS Prack Support is Finally Arriving!

This work has now been merged with trunk/main and will appear in the 1.9 release of resiprocate.  Check out the following wiki page for more information:

https://www.resiprocate.org/UAS_Prack_Announcement_page

Best Regards,
Scott Godin
SIP Spectrum, Inc.


On Tue, Nov 12, 2013 at 9:29 AM, Scott Godin <sgodin@xxxxxxxxxxxxxxx> wrote:
Hello Fellow reSIPers,

I am happy to announce that resiprocate/dum will fully support RFC3262 PRACK in the next release.  Resiprocate has supported playing the UAC role (PRACK sender) in a PRACK enabled call for some time now, but it did not previously support the UAS role (reliable provisional sender).

The work to add UAS PRACK support is nearly completed in the following SVN branch:

If this is something of interest to you I encourage you to give this branch a test drive.  It is expected to be merged into SVN trunk sometime over the next few weeks.

To enable UAS Prack support use the following MasterProfile setting:

      // UAS PRACK support.  UPDATE must be enabled(currently defaults to on, do
      // not disable w/out disabling UAS PRACK support).
      //
      // All flows and limitations mentioned in UAC Prack comments apply
      //
      // Modes work as follows:
      // SupportedEssential - Only send reliable provisionals if sending a body and far end supports
      // Supported - Always send reliable provisionals if far end supports
      // Required - Always send reliable provisionals
      virtual void setUasReliableProvisionalMode(ReliableProvisionalMode mode);

There is also a new optional InviteSessionHandler callback called onPrack if you would like to inspect the Prack messages that are received.

The resip/dum/doc directory contains a few new documents surrounding PRACK support:
-UASPRACKFlows.png
-3GPP-24.930Rel11Flows.png
-dum-UASPRACK-state.png

All offer/answer scenarios from PRACK RFC3262 and the UPDATE RFC3311 are supported.  Sending of overlapped reliable provisionals are not allowed.  The only odd scenario worth mentioning is the ability to send an Offer in a PRACK request after receiving an answer in a reliable provisional.  In order to be able to do this the caller must call provideOffer from the onAnswer callback.  If provideOffer is called later in time, then the PRACK will go out without the offer and an UPDATE request will carry the offer instead.

The TFM DUM Automated test framework has been extended to support a total of 33 automated PRACK test cases and scenarios.

Please let me know if you have any issues with the code in this branch.

Best Regards,
Scott Godin
SIP Spectrum, Inc.