[asterisk-dev] Testers wanted - PRACK for 1.8

Alec Davis sivad.a at paradise.net.nz
Thu Jul 5 02:58:53 CDT 2012 

<quote>
RFC3262

 7.1 RSeq

   The RSeq header is used in provisional responses in order to transmit
   them reliably.  It contains a single numeric value from 1 to 2**32 -
   1.  For details on its usage, see Section 3.
</quote>

Using '%d' would show these numbers as negative numbers, should it be
possible for rseqno get to 1**31.

In other words. Rseqno, their-rseqno and possiblty others need to be defined
as a uint32_t and use '%u' instead of '%d' to print the value.

This is for the same reasons as 'seqno' and it's friends are defined as
uint32.

Alec

> -----Original Message-----
> From: asterisk-dev-bounces at lists.digium.com 
> [mailto:asterisk-dev-bounces at lists.digium.com] On Behalf Of 
> Olle E. Johansson
> Sent: Wednesday, 4 July 2012 8:10 p.m.
> To: Pavel Troller; Asterisk Developers Mailing List
> Subject: Re: [asterisk-dev] Testers wanted - PRACK for 1.8
> 
> 
> 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-pra
ck-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
> 
> 
> 
> 
> --
> _____________________________________________________________________
> -- 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
>

More information about the asterisk-dev mailing list