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

[wdoekes]

> On 2011-03-31 16:07:49, leurk wrote:
> > Asterisk isn't a proxy, while Section 16.11 describes proxying. Quote:
> > 
> > "16.11 Stateless Proxy
> > ...
> > A stateless proxy does not have any notion of a transaction, or of
> >    the response context used to describe stateful proxy behavior.
> >    Instead, the stateless proxy takes messages, both requests and
> >    responses, directly from the transport layer..."

Yes, I'm perfectly aware that that section describes proxy behaviour. But I have a hard time finding out what branch= value should be.

I tested my sipp scenario (as found in issue #18633) against asterisk and a phone. And the phone would send the same via branch, while patched asterisk sends a new one. That caused me to scour the RFC for info about that, and the only relevant mention I could find was there.


- wdoekes


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


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
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20110401/a5844438/attachment.htm>