No subject
Fri Sep 2 03:59:05 CDT 2011
<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>
Have I tested it? No sorry.
You hit one of my pet hates :) If a number is always positive, then use '%u'
and declare it as uint_32_t
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
More information about the asterisk-dev
mailing list