| Summary: | ASTERISK-08761: SIP message retransmission time too short | ||
| Reporter: | Benny Amorsen (amorsen) | Labels: | |
| Date Opened: | 2007-02-09 07:31:14.000-0600 | Date Closed: | 2007-02-18 04:37:02.000-0600 |
| Priority: | Major | Regression? | No |
| Status: | Closed/Complete | Components: | Core/General |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| Environment: | Attachments: | ( 0) t1.diff | |
| Description: | When qualify is on and asterisk is very close to a peer, the SIP retransmission time sometimes gets so short, that the peer has no chance to react to INVITEs. Here is an example tcpdump: 13:15:48.767068 IP host1.sip > host2.sip: SIP, length: 740 13:15:48.768396 IP host1.sip > host2.sip: SIP, length: 740 13:15:48.770422 IP host1.sip > host2.sip: SIP, length: 740 13:15:48.774387 IP host1.sip > host2.sip: SIP, length: 740 13:15:48.782384 IP host1.sip > host2.sip: SIP, length: 740 13:15:48.798380 IP host1.sip > host2.sip: SIP, length: 740 13:15:48.830375 IP host1.sip > host2.sip: SIP, length: 740 13:15:48.975428 IP host2.sip > host1.sip: SIP, length: 418 Notice how the last retry is only 63ms after the first packet, and that host2 replies after 208ms. Not a very quick answer time perhaps, but that could be because host1 is hammering it with retries. ****** ADDITIONAL INFORMATION ****** I tried a stupid patch to keep timer_t1 above 100ms. It didn't work. The patch is attached. | ||
| Comments: | By: Olle Johansson (oej) 2007-02-11 12:21:24.000-0600 In ASterisk 1.4, we have solved this issue with the "t1min" configuration setting. By: Joshua C. Colp (jcolp) 2007-02-15 19:53:29.000-0600 Is this something we should perhaps backport if not too invasive oej? I could certainly see this being an issue. By: Olle Johansson (oej) 2007-02-18 04:36:25.000-0600 Took Josh's advice and backported the minimum setting of 100 ms to 1.2. Implemented in 1.2 svn rev 55249 and will be part of the next 1.2 release. Thanks for reporting this bug. | ||