[reSIProcate] DUM UAS 1xx response retransmitted more times

[Scott Godin]

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 at sipspectrum.com>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
>
> On Wed, Jun 12, 2013 at 11:42 AM, Tibor Velencei <
> Tibor.Velencei at gamma.co.uk> wrote:
>
>> 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 at resiprocate.org
>> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20130614/5f9d304d/attachment.htm>