[asterisk-dev] Testers wanted - PRACK for 1.8
Olle E. Johansson
oej at edvina.net
Thu Jul 5 05:06:36 CDT 2012
5 jul 2012 kl. 11:31 skrev Alec Davis:
> Looking forward to see this on review board.
>
> I should have also quoted this, regarding 'initial' rseq and 'subsequent'
> rseqno:
>
>> From RFC3262 page 4
> <quote>
> The value of the RSeq in each subsequent reliable provisional
> response for the same request MUST be greater by exactly one. RSeq
> numbers MUST NOT wrap around. Because the initial one is chosen to
> be less than 2**31 - 1, but the maximum is 2**32 - 1, there can be up
> to 2**31 reliable provisional responses per request, which is more
> than sufficient.
> </quote>
Yes. I don't see the risc of wrapping around happening, but never say never.
Remember IPv4... :-)
>
> Have I tested it? No sorry.
Still time.
>
> You hit one of my pet hates :) If a number is always positive, then use '%u'
> and declare it as uint_32_t
I love having people like you checking commits, it is one of the good sides of
Open Source. Thanks!
I fixed the code already.
/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: Thursday, 5 July 2012 8:15 p.m.
>> To: Asterisk Developers Mailing List
>> Subject: Re: [asterisk-dev] Testers wanted - PRACK for 1.8
>>
>>
>> 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
>>
>>
>>
>>
>> --
>> _____________________________________________________________________
>> -- 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