491 Request pending response from Asterisk on Re-Invite

[Gadi Srebnik]

Hi, 

We found the following problem: 

User A tries to call user B, sending INVITE to asterisk on a low speed internet connection. Before User A receives "SIP/2.0 100 Trying" he sends additional INVITE

because he has timed out. Asterisk checks the second request and returns "SIP/2.0 491 Request Pending" because an open dialog already exists in the server.

Checking the INVITE requests from client shows that CSeq number has increased in 1, which cause Asterisk to define it as not-the-same request.

In the client, response 941 cause change of status to terminated, which handled as end of call, meanwhile there is the original call handled by server.

There are 2 ways to handle this: client and server, which is the preferred way?

Thanks, 

Gadi 

[Mamadou]

could you please attach network trace?
I'm using iDoubs with latest Doubango code but the the CSeq is the same.
This is strange because a request is always created one time by the
dialog and the retransmission is up to the transaction layer which never
update the CSeq.

> --
>
>

[Gadi Srebnik]

We are currently using doubango version 747, could it be in a fix from then on?

Attached traffic from server for 2 sequential invites from user, note that the cseq number is accumulated.  

Thanks, 

Gadi

--

Best Regards,

Gadi Srebnik, 

VP R&D Rounds

m: +972545929261
p  :+97236878752
e : ga...@rounds.com
w : http://www.rounds.com

[Muhammad Shahzad]

Well, what i can see in logs is that you are doing proxy authorization for INVITE, so first request is responded with 401, client ACK the response and then sends a NEW request with proxy authorization header. This new request should have CSeq incremented (since last INVITE has been completed).

The real problem seems to be with your sever which is not absorbing retransmission for CSeq 1260665680 and treating it as new INVITE and thus returning 491 Request Pending, (this typically happens when for example you are using OpenSIPs or Kamailio and do not call t_check_trans function for any request that does not have TO tag).

Thank you.

--
 
 

[Gadi Srebnik]

Thank you, we added t_check_trans and it works great.