[asterisk-dev] Testers wanted - PRACK for 1.8

[Olle E. Johansson]

The Darjeeling PRACK code has been updated and has successfully passed the interoperability tests it was designed for. It will be put in production soon.

Feel free to test and give me feedback if it works or not works for you. 

If anyone wants to spend time and effort on upgrading it to trunk and getting it integrated with Digium's Asterisk-distributions, please contact me and I'll assist you.

Thanks for all the feedback so far!

/O


3 jul 2012 kl. 15:01 skrev Olle E. Johansson:

> http://svn.digium.com/svn/asterisk/team/oej/darjeeling-prack-1.8
> 
> As far as I can see from tests with various phones this implementation of SIP PRACK - or "100rel" seems to work now. All you have to do is to add prack=yes to sip.conf (general or per-device) and Asterisk will start playing the PRACK game.
> 
> Feedback from tests is always welcome!
> 
> Regards,
> /Olle
> 
> ========== README.darjeeling ===============================
> 
> Edvina AB
> Olle E. Johansson
> 
> 
> Project started: 2012-06-15
> 
> 
> 
> 
> 
> Darjeeling-prack-1.8
> --------------------
> 
> This branch will implement PRACK in the SIP stack of Asterisk.
> 
> PRACK stands for reliable unreliable provisional responses.
> 
> In SIP, the provisional responses are often sent over UDP, which means that they can
> get lost. Some of them are retransmitted every minute (to get at least one through
> once during a three minute period following RFC 3261). For some messages, it's 
> important that they get through immediately. Like if you want to play a message to
> the customer that his call will be cancelled due to lack of funds in his account.
> 
> PRACK adds a retransmit and ACK mechanism to the 1xx messages excluding 100 (since
> it's transmitted hop-by-hop).
> 
> Configuration
> =============
> Add prack=yes in the [general] section of sip.conf or in device configurations. 
> Asterisk will now add 100rel to the list of supported options. If the other device
> supports PRACK Asterisk will activate it or support it if the other side
> requires it.
> There's currently no support for requiring PRACK in a call.
> 
> 
> Technichal details
> ==================
> 
> If the INVITE contains
> 	Supported: 100rel
> 
> then the 1xx answer can add 
> 	Require: 100rel
> 	Rseq: 	42
> 
> The Rseq is the PRACK sequence number
> The caller then needs to confirm the message with a new request, during the INVITE transaction
> 	PRACK
> 	RAck: 	42	<cseq #> <cseq method>
> 
> And the callee confirms this (and close the PRACK transaction) with a 200 OK.
> 
> If the PRACK is not received in time, the 1xx response will be retransmitted.
> There can only be ONE outstanding PRACK, which makes it easier to integrate in the
> Asterisk SIP stack that unfortunately lacks a transaction layer.
> 
> PRACK is documented in RFC 3262.
> 
> Retransmission works like the retransmission of responses to INVITE (like the 200 OK).
> It starts with T1 and doubles for each retransmission. Unlike INVITE responses,
> the retransmission timer does not cap at T2.
> 
> If retransmission times out, a 5xx message should terminate the INVITE transaction.
> 
> 
> A PRACK received that does not match existing SIP_PVT is responded to with 481.
> 
> * When to stop?
> ---------------
> From the RFC: 
> "The UAS MAY send a final response to the initial request before having received PRACKs for all unacknowledged
> reliable provisional responses, unless the final response is 2xx and any of the unacknowledged
> reliable provisional responses contained a session description. In that case, it MUST NOT send a final response
> until those provisional responses are acknowledged. If the UAS does send a final response when
> reliable responses are still unacknowledged, it SHOULD NOT continue to retransmit the unacknowledged
> reliable provisional responses, but it MUST be prepared to process PRACK requests for those outstanding
> responses. A UAS MUST NOT send new reliable provisional responses (as opposed to retransmissions of
> unacknowledged ones) after sending a final response to a request"
> 
> * Receive in order until final response
> ---------------------------------------
> "Handling of subsequent reliable provisional responses for the same initial request follows the same rules
> as above, with the following difference: reliable provisional responses are guaranteed to be in order. As a
> result, if the UAC receives another reliable provisional response to the same request, and its RSeq value
> is not one higher than the value of the sequence number, that response MUST NOT be acknowledged with a
> PRACK, and MUST NOT be processed further by the UAC. An implementation MAY discard the response,
> or MAY cache the response in the hopes of receiving the missing responses.
> The UAC MAY acknowledge reliable provisional responses received after the final response or MAY discard
> them."
> 
> * When do the call begin?
> -------------------------
> A corner case that I don't know if it's implemented: If we receive and INVITE without SDP, we MUST
> add SDP offer to the reliable answer and the caller must add an SDP answer to the PRACK. This means 
> that the session begins in the middle of the INVITE transaction.
> "Once an answer has been sent or received, the UA SHOULD establish the session based on the parameters of
> the offer and answer, even if the original INVITE itself has not been responded to." (section 5)
> 
> * Security
> ----------
> "The PRACK request can be injected by attackers to force retransmissions of reliable provisional responses to
> cease. As these responses can convey important information, PRACK messages SHOULD be authenticated
> as any other request." (section 9)
> 
> Todo
> ----
> * Add PRACK to the list of supported headers
> 	- done
> * Should we be able to REQUIRE prack? Based on what? _SIPREQUIREPRACK ?
> 	- not now
> * PRACK enabled globally and per device - user and peer
> 	- done
> * PRACK working when Asterisk is the UAS
> 	- done
> * PRACK working when Asterisk is the UAC
> 	- done
> * PRACK with authentication
> 	- not done
> * Requesting auth for PRACK
> 	- not done
> * PRACK in "sip show settings"
> 	- done
> * PRACK in "sip show peer xxx"
> 	- done
> * PRACK in "sip show channel xxx"
> 	- done
> 
> ---------------------
> The patch is (C) Copyright by Edvina AB, Sollentuna, Sweden. 
> Developed by Olle E. Johansson, oej at edvina.net

---
* Olle E Johansson - oej at edvina.net
* Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden