[asterisk-dev] Testers wanted - PRACK for 1.8
Olle E. Johansson
oej at edvina.net
Thu Jul 5 03:14:50 CDT 2012
5 jul 2012 kl. 09:58 skrev Alec Davis:
> <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.
Great feedback, thanks Alec!!!
Have you tested anything, does it work for you?
/Olle
>
> 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
>>
>
>
> --
> _____________________________________________________________________
> -- 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
More information about the asterisk-dev
mailing list