[asterisk-dev] Testers wanted - PRACK for 1.8
Alec Davis
sivad.a at paradise.net.nz
Thu Jul 5 04:52:36 CDT 2012
Missed one instance. Not that it matters it's only debug.
Index: chan_sip.c
===================================================================
--- chan_sip.c (revision 369619)
+++ chan_sip.c (working copy)
@@ -4035,7 +4035,7 @@
break;
}
}
- ast_debug(1, "Stopping retransmission on '%s' of %s %u: Match %s
Rseq %d\n",
+ ast_debug(1, "Stopping retransmission on '%s' of %s %u: Match %s
Rseq %u\n",
p->callid, resp ? "Response" : "Request", seqno, msg,
rseqno);
return res;
}
> -----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