Date: Fri, 14 Sep 2007 11:21:00 +0530 From: "Nabeel Mohamed" <nabeel.ietf@gmail.com> Subject: [users:00372] Re: TAHI SIP Conformance test failing for INVITE retransmission test. To: users@tahi.org Message-Id: <df4cbab00709132251t2a48b41eu6e8435fd7a4c2a88@mail.gmail.com> In-Reply-To: <df4cbab00708300751w17a2fe4ahde7c102c9ffd2faa@mail.gmail.com> References: <df4cbab00708300751w17a2fe4ahde7c102c9ffd2faa@mail.gmail.com> X-Mail-Count: 00372Hi all, I invested some time in going through the transaction implementation of the NIST stack and observed the below. The same retransmission timer logic, which is used for non-Invite client transaction is used for the invite retransmissions too. Hence I was able to observe the pattern, which I have described in my previous mail. I was able to change this behavior by tweaking the code a bit and things worked fine after that . Now, I need one clarification on this, Is it OK for the Invite client transaction to follow the same retransmission timer behavior as the Non-Invite client transaction. That is, instead of T1, 2*T1, 4*T1,.....,64*T1 it follows T1, 2*T1, ... , min( pow(2,n) * T1 , T2). Is it a bug ? Please correct me if i am wrong. Thanks & Regards, Nabeel On 8/30/07, Nabeel Mohamed <nabeel.ietf@gmail.com> wrote: > > Hi All, > > I tested the retransmission of INVITE message by the NIST stack, using the > TAHI SIP Conformance test package. > I got confused after looking at the pattern in which the NIST stack sends > retransmissions. > > <snippet from test logs> > > The call flow is below, > > Sequence > > NUT R PX1 UA1 OT1 OT2 REG DNS > No time | | | | | | | | > [01: 0.00|ICMP] |<----|-----| | | | | | Echo > Request > [02: 0.00|U ] |-----|---->| | | | | | Echo > Reply > [03:19.20|U ] INVIT |-----|---->| | | | | | INVITE > sip:UA1@17.1.1.56:5060 > [04:19.70|U ] INVIT |-----|---->| | | | | | INVITE > sip:UA1@17.1.1.56:5060 > [05:20.76|U ] INVIT |-----|---->| | | | | | INVITE > sip:UA1@17.1.1.56 :5060 > [06:22.88|U ] INVIT |-----|---->| | | | | | INVITE > sip:UA1@17.1.1.56:5060 > [07:27.12|U ] INVIT |-----|---->| | | | | | INVITE > sip:UA1@17.1.1.56:5060 > [08:31.36|U ] INVIT |-----|---->| | | | | | INVITE > sip:UA1@17.1.1.56:5060 > [09:35.60|U ] INVIT |-----|---->| | | | | | INVITE > sip:UA1@17.1.1.56:5060 > [10:39.84|U ] INVIT |-----|---->| | | | | | INVITE > sip:UA1@17.1.1.56:5060 > [11:44.08|U ] INVIT |-----|---->| | | | | | INVITE > sip:UA1@17.1.1.56:5060 > [12:48.32|U ] INVIT |-----|---->| | | | | | INVITE > sip:UA1@17.1.1.56 :5060 > [13:51.20| ] |*****|*****|*****|*****|*****|*****|*****| Fire B > Timer > > The judgement which TAHI performs for testing the RFC rules is below, > > Judgment > Timer: INVITE MUST be retransmitted( No.1) after Timer A fired. Timer A:0 > retransmit time:0.00 > Timer: When Timer B fired, client INVITE retransmit No.1 has valid > interval. Timer B:0 retransmit time:0.00 > Timer: INVITE MUST be retransmitted(No.2) after Timer A fired. Timer A: > 0.5 retransmit time:0.51 > Timer: When Timer B fired, client INVITE retransmit No.2 has valid > interval. Timer B:0.5 retransmit time:0.51 > Timer: INVITE MUST be retransmitted(No.3) after Timer A fired. Timer A:1 > retransmit time: 1.06 > Timer: When Timer B fired, client INVITE retransmit No.3 has valid > interval. Timer B:1 retransmit time:1.06 > Timer: INVITE MUST be retransmitted(No.4) after Timer A fired. Timer A:2 > retransmit time:2.12 > Timer: When Timer B fired, client INVITE retransmit No.4 has valid > interval. Timer B:2 retransmit time:2.12 > Timer: INVITE MUST be retransmitted(No.5) after Timer A fired. Timer A:4 > retransmit time:4.24 > Timer: When Timer B fired, client INVITE retransmit No.5 has valid > interval. Timer B:4 retransmit time: 4.24 > Timer: INVITE MUST be retransmitted(No.6) after Timer A fired. Timer A:8 > retransmit time:4.24 > Timer: When Timer B fired, client INVITE retransmit No.6 has valid > interval. Timer B:8 retransmit time:4.24 > Timer: INVITE MUST be retransmitted( No.7) after Timer A fired. Timer A:16 > retransmit time:4.24 > Timer: When Timer B fired, client INVITE retransmit No.7 has valid > interval. Timer B:16 retransmit time:4.24 > Timer: INVITE MUST be retransmitted(No.8) after Timer A fired. Timer A:32 > retransmit time: 4.24 > Timer: When Timer B fired, client INVITE retransmit No.8 has valid > interval. Timer B:32 retransmit time:4.24 > Timer: INVITE MUST be retransmitted(No.9) after Timer A fired. Timer A:64 > retransmit time:4.24 > Timer: When Timer B fired, client INVITE retransmit No.9 has valid > interval. Timer B:64 retransmit time:4.24 > Timer: INVITE MUST be retransmitted(No.10) after Timer A fired. Timer A: > 0.5 retransmit time:4.24 > Timer: When Timer B fired, client INVITE retransmit No.10 is timer > missing. Timer B: 0.5 retransmit time:4.24 > Timer: Client sent INVITE > Timer: Client INVITE retransmit stopped after Timer B fired. > Timer: Client MUST NOT send ACK after Timer B fired. > > </snippet> > > The pattern of the retransmit time should start with T1 sec(500 ms by > default in NIST stack) and should go > till T2(64 * T1) as per the RFC. The pattern of the retransmit time is > not as per our requirement, i.e. > 0.00, 0.51, 1.06, 2.12, 4.24, after it remains the same. Also I wonder how > there is a possibility for 10 retransmissions > while there can be only 7 retransmissions with the configured value of T1= > 0.5 and T2=64*0.5=32. > > I tested the simplecallsetup example, that comes along with the NIST > stack, for retransmission using the loopback interface. I observed that the > time at which the INVITE's and it's retransmissions were sent, also showed > the same pattern and also > there were 10 retransmissions. > > The time pattern is below, > 1188482985142 > 1188482985649 > 1188482986709 > 1188482988819 > 1188482993059 > 1188482997299 > 1188483001543 > 1188483005783 > 1188483010023 > 1188483014263 > 1188483018503 > > Is it an issue (or) am I missing any configurations to be performed ? > Please correct me and advise me > accordingly. Also let me know if it is a known problem. > > Thanks in advance, > Regards, > Nabeel > > >372_2.html (attatchment)(tag is disabled)