[asterisk-commits] oej: branch oej/darjeeling-prack-1.8 r369040 - in /team/oej/darjeeling-prack-...
SVN commits to the Asterisk project
asterisk-commits at lists.digium.com
Sun Jun 17 15:28:23 CDT 2012
Author: oej
Date: Sun Jun 17 15:28:18 2012
New Revision: 369040
URL: http://svnview.digium.com/svn/asterisk?view=rev&rev=369040
Log:
Just preparing stuff
Added:
team/oej/darjeeling-prack-1.8/README.darjeeling (with props)
Modified:
team/oej/darjeeling-prack-1.8/ (props changed)
team/oej/darjeeling-prack-1.8/channels/sip/include/sip.h
Propchange: team/oej/darjeeling-prack-1.8/
------------------------------------------------------------------------------
automerge = Is-there-life-off-net?
Added: team/oej/darjeeling-prack-1.8/README.darjeeling
URL: http://svnview.digium.com/svn/asterisk/team/oej/darjeeling-prack-1.8/README.darjeeling?view=auto&rev=369040
==============================================================================
--- team/oej/darjeeling-prack-1.8/README.darjeeling (added)
+++ team/oej/darjeeling-prack-1.8/README.darjeeling Sun Jun 17 15:28:18 2012
@@ -1,0 +1,102 @@
+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 he's 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).
+
+If the INVITE contains
+ Supported: 100rel
+
+then the 1xx answer can add
+ Required: 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
+* Should we be able to REQUIRE prack? Based on what? _SIPREQUIREPRACK ?
+* PRACK enabled globally and per device - user and peer
+* PRACK enabled per call - SIPCHANINFO?
+
+---------------------
+The patch is (C) Copyright by Edvina AB, Sollentuna, Sweden.
+Developed by Olle E. Johansson, oej at edvina.net
Propchange: team/oej/darjeeling-prack-1.8/README.darjeeling
------------------------------------------------------------------------------
svn:eol-style = native
Propchange: team/oej/darjeeling-prack-1.8/README.darjeeling
------------------------------------------------------------------------------
svn:keywords = Author Date Id Revision
Propchange: team/oej/darjeeling-prack-1.8/README.darjeeling
------------------------------------------------------------------------------
svn:mime-type = text/plain
Modified: team/oej/darjeeling-prack-1.8/channels/sip/include/sip.h
URL: http://svnview.digium.com/svn/asterisk/team/oej/darjeeling-prack-1.8/channels/sip/include/sip.h?view=diff&rev=369040&r1=369039&r2=369040
==============================================================================
--- team/oej/darjeeling-prack-1.8/channels/sip/include/sip.h (original)
+++ team/oej/darjeeling-prack-1.8/channels/sip/include/sip.h Sun Jun 17 15:28:18 2012
@@ -223,6 +223,7 @@
#define DEFAULT_CAPABILITY (AST_FORMAT_ULAW | AST_FORMAT_TESTLAW | AST_FORMAT_ALAW | AST_FORMAT_GSM | AST_FORMAT_H263);
#define DEFAULT_STORE_SIP_CAUSE FALSE /*!< Don't store HASH(SIP_CAUSE,<channel name>) for channels by default */
#endif
+#define DEFAULT_PRACK FALSE /*!< Default: Prack is turned off */
/*@}*/
/*! \name SIPflags
@@ -357,9 +358,10 @@
#define SIP_PAGE3_SNOM_AOC (1 << 0) /*!< DPG: Allow snom aoc messages */
+#define SIP_PAGE3_PRACK (2 << 0) /*!< DPG: Allow snom aoc messages */
#define SIP_PAGE3_FLAGS_TO_COPY \
- (SIP_PAGE3_SNOM_AOC)
+ (SIP_PAGE3_SNOM_AOC | SIP_PAGE3_PRACK)
/*@}*/
@@ -403,6 +405,7 @@
* where the original response would be sent RELIABLE in an INVITE transaction
*/
enum xmittype {
+ XMIT_PRACK = 3, /*!< Transmit response the PRACK way: reliably, with re-transmits. */
XMIT_CRITICAL = 2, /*!< Transmit critical SIP message reliably, with re-transmits.
* If it fails, it's critical and will cause a teardown of the session */
XMIT_RELIABLE = 1, /*!< Transmit SIP message reliably, with re-transmits */
@@ -560,7 +563,7 @@
SIP_NOTIFY, /*!< Status update, Part of the event package standard, result of a SUBSCRIBE or a REFER */
SIP_INVITE, /*!< Set up a session */
SIP_ACK, /*!< End of a three-way handshake started with INVITE. */
- SIP_PRACK, /*!< Reliable pre-call signalling. Not supported in Asterisk. */
+ SIP_PRACK, /*!< Reliable pre-call signalling. */
SIP_BYE, /*!< End of a session */
SIP_REFER, /*!< Refer to another URI (transfer) */
SIP_SUBSCRIBE, /*!< Subscribe for updates (voicemail, session status, device status, presence) */
@@ -696,6 +699,7 @@
unsigned int disallowed_methods; /*!< methods that we should never try to use */
int notifyringing; /*!< Send notifications on ringing */
int notifyhold; /*!< Send notifications on hold */
+ int prack; /*!< 0 offer prack, 1 use prack in responses */
enum notifycid_setting notifycid; /*!< Send CID with ringing notifications */
enum transfermodes allowtransfer; /*!< SIP Refer restriction scheme */
int allowsubscribe; /*!< Flag for disabling ALL subscriptions, this is FALSE only if all peers are FALSE
@@ -984,6 +988,8 @@
uint32_t ocseq; /*!< Current outgoing seqno */
uint32_t icseq; /*!< Current incoming seqno */
uint32_t init_icseq; /*!< Initial incoming seqno from first request */
+ uint32_t rseq; /*!< Current outgoing PRACK rseq */
+ uint32_t irseq; /*!< Current incoming PRACK rseq */
ast_group_t callgroup; /*!< Call group */
ast_group_t pickupgroup; /*!< Pickup group */
uint32_t lastinvite; /*!< Last seqno of invite */
@@ -1140,6 +1146,7 @@
int retrans; /*!< Retransmission number */
int method; /*!< SIP method for this packet */
uint32_t seqno; /*!< Sequence number */
+ uint32_t rseqno; /*!< PRACK Sequence number */
char is_resp; /*!< 1 if this is a response packet (e.g. 200 OK), 0 if it is a request */
char is_fatal; /*!< non-zero if there is a fatal error */
int response_code; /*!< If this is a response, the response code */
@@ -1749,7 +1756,7 @@
char * const text; /*!< Text id, as in standard */
} sip_options[] = { /* XXX used in 3 places */
/* RFC3262: PRACK 100% reliability */
- { SIP_OPT_100REL, NOT_SUPPORTED, "100rel" },
+ { SIP_OPT_100REL, SUPPORTED, "100rel" },
/* RFC3959: SIP Early session support */
{ SIP_OPT_EARLY_SESSION, NOT_SUPPORTED, "early-session" },
/* SIMPLE events: RFC4662 */
More information about the asterisk-commits
mailing list