> From: Ari Sonesh [[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.
The problem is inherently difficult. There is a discussion of the change to a shorter timeout in the sipx-dev archives somewhere. The question is how long to keep retrying when sending a request to a destination address that does not respond. IIRC, the RFC 3261 value is 20 seconds. The problem with that is that the caller gives up long before failover to the next destination address or voicemail. We settled on 1.5 seconds or something like that because it was sufficient for all of the networks that we had dealt with at the time, and users did not hang up if they did not hear ringback for 1.5 seconds after finishing dialing. I don't recall where the timeout is set, but it is a variable parameter in the SIP stack and can be adjusted straightforwardly. In regard to sending a CANCEL once the INVITE has been abandoned due to non-response: RFC 3261 forbids sending a CANCEL until the destination has sent a response to the INVITE. So, in the case of a non-responding destination, it is not allowed to send a CANCEL when the destination is abandoned. But, when the destination sends its first 1xx resposne, the SIP stack should send a CANCEL based on the fact that the stack has abandoned that destination. But I don't believe that it does. In practice, I suggest that you take enough measurements that you get decent statistics on how long it takes to get a 1xx response to an INVITE. My guess is that there is a fairly well-defined upper limit. If you adjust the retry time to slightly above that, you will probably fix the problem in practice. Dale _______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users/
