It's all in RFC2543 (I lerned this from Acme Packet, their SBC's "smooth" all INVITE's etc according to the RFC timers): 10.4.1 UDP
A SIP client using UDP SHOULD retransmit a BYE, CANCEL, OPTIONS, or REGISTER request with an exponential backoff, starting at a T1 second interval, doubling the interval for each packet, and capping off at a T2 second interval. This means that after the first packet is sent, the second is sent T1 seconds later, the next 2*T1 seconds after that, the next 4*T1 seconds after that, and so on, until the interval hits T2. Subsequent retransmissions are spaced by T2 seconds. If the client receives a provisional response, it continues to retransmit the request, but with an interval of T2 seconds. Retransmissions cease when the client has sent a total of eleven packets, or receives a definitive response. Default values for T1 and T2 are 500 ms and 4 s, respectively. Clients MAY use larger values, but SHOULD NOT use smaller ones. Servers retransmit the response upon receipt of a request retransmission. After the server sends a final response, it cannot be sure the client has received the response, and thus SHOULD cache the results for at least 10*T2 seconds to avoid having to, for example, contact the user or location server again upon receiving a request retransmission. Special case is the INVITE, an INVITE needs to be retransmitted 6 times: 10.5.1 UDP For UDP, A SIP client SHOULD retransmit a SIP INVITE request with an interval that starts at T1 seconds, and doubles after each packet transmission. The client ceases retransmissions if it receives a provisional or definitive response, or once it has sent a total of 7 request packets. Best regards / Mit freundlichen Grüßen / Sincères salutations Paul Scheepens Administrator Network Engineering | Dir. 2.7.3.2 European Patent Office Patentlaan 3-9 | 2288 EE Rijswijk | The Netherlands Tel. +31 (0)70 340 3331 Mobile +31 (0)642724894 [email protected] http://www.epo.org [email protected] wrote on 08-11-2011 12:41:21: > From: > > Tony Graziano <[email protected]> > > To: > > Discussion list for users of sipXecs software <[email protected]> > > Date: > > 08-11-2011 13:24 > > Subject: > > Re: [sipx-users] Please Help....Timeout of INVITE too short. > > Sent by: > > [email protected] > > On Mon, Nov 7, 2011 at 7:28 PM, Ari Sonesh <[email protected]> wrote: > > > > Content-Type: text/plain; > > charset="utf-8" > > Content-Transfer-Encoding: 8bit > > Organization: SipXecs Forum > > In-Reply-To: <[email protected]> > > X-FUDforum: 08063afcdd00a6e76393c5b9527381e8 <64373> > > Message-ID: <[email protected]> > > > > > > > > I believe that the issue is inherent to mobile data networks > > that are buffering initial (after standby) data traffic > > until it can allocate a channel to transmit the data to a > > receiver. Once channel is allocated the traffic is flowing > > well. > > > > This initial buffering creates an issue with SipX which is > > using lower than standard timeout between an Invite and a > > corresponding Ack. What happens is that the Sipx sends > > Invite and there is no response (as it's still buffered by > > the mobile network), so after 100msec it sends another > > invite, and another after 200msec, and yet another after > > invite after 400msec, and then after a timeout it gives up. > > Now, once a channel becomes available all 4 invites are > > immediately sent and acknowledged by the remote endpoint, > > but by then SIPx already gave up, but the called extension > > is ringing. > > > > When the channel is allocated fast the call setup and the > > conversation are flawless. > > > > This behavior (initial buffering)is characteristically for > > all mobile networks. > > > > We really need to find a solution to this issue through A) > > work around B) design change. > > > > It's acceptable for the caller to wait for some time > > (probably as much as 10 seconds) before there is a "ring" > > response from the called side. > > I probably would not agree with 10 seconds... > > > > Any suggestions for a work around? > > I think it is important to understand first whether the trunk provider > or gateway uses a precall service before jumping to this conclusion. > > At the same time, the question is a good one, "how long should the > system wait before retrying". > _______________________________________________ > sipx-users mailing list > [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-users/
_______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users/
