[asterisk-dev] Testers wanted - PRACK for 1.8

[Paul Belanger]

On 12-07-03 09:01 AM, Olle E. Johansson wrote:
> 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
> --
Curious if you ran your branch against SIPp? Might be worth adding it to 
the testsuite too.

-- 
Paul Belanger | PolyBeacon, Inc.
Jabber: paul.belanger at polybeacon.com | IRC: pabelanger (Freenode)
Github: https://github.com/pabelanger | Twitter: 
https://twitter.com/pabelanger