[asterisk-dev] [Code Review] RFC 3261 compliant ACK retransmission for unreliable final responses

[David Vossel]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/692/#review2145
-----------------------------------------------------------

Ship it!


This looks completely sane to me.  If a response is matched to a sip_pvt and does not ack any previous request then it is almost guaranteed to be a retransmit of an already acked request.  Even if it isn't for some weird reason we are still supposed to ACK it rather than ignoring in the case of the sipmethod being an INVITE.

- David


On 2010-06-03 13:40:43, Terry Wilson wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/692/
> -----------------------------------------------------------
> 
> (Updated 2010-06-03 13:40:43)
> 
> 
> Review request for Asterisk Developers and David Vossel.
> 
> 
> Summary
> -------
> 
> RFC 3261 in sections 13.2.24 and 17.1.1.2 state that each 2xx response or final response to an INVITE must result in an ACK being sent (but the retransmitted responses are not to be sent to the transaction user).
> 
> This patch sends that ACK.
> 
> 
> Diffs
> -----
> 
>   /trunk/channels/chan_sip.c 267137 
> 
> Diff: https://reviewboard.asterisk.org/r/692/diff
> 
> 
> Testing
> -------
> 
> I wrote a sipp scenario to re-send 200 OK responses and ensured that the proper ACK was sent back. I also tested calling a soft phone to verify that no behavior change was made when there were no retransmissions.
> 
> 
> Thanks,
> 
> Terry
> 
>