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. Any suggestions for a work around? _______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users/
