[asterisk-dev] Testers wanted - PRACK for 1.8

Wed Jul 4 03:09:56 CDT 2012

4 jul 2012 kl. 05:50 skrev Pavel Troller:

> Hi!
>  Is it possible to get a patch based on 1.8 branch instead of the full tree? I would like to test it on the SIP trunk against Nortel's CallServer 2000, which prefers 100rel support, but my source tree is highly customized and I cannot easily adapt another tree without spending too much time on it :-(.
You can just do a diff with 1.8 or any 1.8 release yourself with svn :-)

I just added a patch to the /patches directory in 
http://svnview.digium.com/svn/asterisk/team/oej/darjeeling-prack-1.8/patches/darjeeling-prack-1.8.diff

Looking forward to your feedback.

/Olle

>    Regards, Pavel
> 
>> 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
>> --
>> _____________________________________________________________________
>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>> 
>> asterisk-dev mailing list
>> To UNSUBSCRIBE or update options visit:
>>   http://lists.digium.com/mailman/listinfo/asterisk-dev
> 
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> 
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-dev

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