Re: [reSIProcate] DUM UAS 1xx response retransmitted more times
I have committed a fix for this today, with a slight modification to not both using secondarySeq.
Thanks again,
Scott
On Fri, Jun 14, 2013 at 11:30 AM, Scott Godin
<sgodin@xxxxxxxxxxxxxxx> wrote:
Hi Tibor,
Sounds like a great find. Thanks for contributing this patch and the detailed description!
I'll take a look at it and get it applied to SVN soon.
Thanks again,
Scott
Hi,
DUM's UAS sends provisional retransmits more times. Let's say UAS responses with 100, 183 and 180 to an INVITE. In this case 180 will be repeated 3 times after a minute. The reason is that DUM starts Retransmit1xx timer on every provisional response. When a timer is triggered it is checked by CSeq if it belongs to the last response. But CSeq is always the same as all the responses reply to the same request. Hence all of the 3 timers will cause a 180 retransmission.
In the attached patch ServerInviteSession::mCurrentRetransmit1xx is used as a provisional response sequence counter and checked instead of CSeq. Also it does not start the timer for 100 as RFC3261 13.3.1 says the UAS must send a non-100 provisional response every minute.
It is based on resiprocate-1.7 but as I can see this issue is the same in the latest version as well.
Please check it and feel free to correct me. I am not sure if I understand correctly the purpose of mCurrentRetransmit1xx.
Kind Regards,
Tibor
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxx
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel