Twinned calls dropped after 1:27

[johnnybrian]

Hi All!

I have a IPO 500 with some sip lines configured. These lines work great, but after upgrading to 5.08, all my twinned calls going out of the SIP lines are dropped after 1:27. It works when i call the number directly though??

Example: A user is has ext 500 and is twinned to his mobile, 12345.

When i call 500 and it twins out to his mobile, the call is dropped after 1:27.
However, when i call his mobile 12345 directly (using the SAM SIP LINE!!) it works okay, and the call is not dropped.

Here is what my SIp log on the Avaya tells me just as the call is dropped:

1030476434mS SIP Call Rx: 18
BYE sip:SIPNAME@192.168.16.10:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP 192.168.13.10;branch=z9hG4bKac1899215256
Max-Forwards: 70
From: <sip:004576522002@192.168.13.10>;tag=1c1697475530
To: "SIPNAME" <sip:danosha@192.168.16.10>;tag=74b88bbb6d63b56b
Call-ID: 759dbf6517d5bf38e3c6800107d19778@192.168.16.10
CSeq: 2 BYE
Supported: em,timer,replaces,path,resource-priority
Allow: REGISTER,OPTIONS,INVITE,ACK,CANCEL,BYE,NOTIFY,PRACK,REFER,INFO,SUBSCRIBE,UPDATE
User-Agent: Audiocodes-Sip-Gateway-/v.5.80A.008.007
Reason: SIP ;cause=408 ;text="408 Request Timeout"
Content-Length: 0

1030476435mS SIP Call Tx: 18
SIP/2.0 200 Ok
Via: SIP/2.0/UDP 192.168.13.10;branch=z9hG4bKac1899215256
From: <sip:004576522002@192.168.13.10>;tag=1c1697475530
To: "SIPNAME" <sip:SIPNAME@192.168.16.10>;tag=74b88bbb6d63b56b
Call-ID: 759dbf6517d5bf38e3c6800107d19778@192.168.16.10
CSeq: 2 BYE
Content-Length: 0

Is this a bug?

 

[kwing112000]

Are you going thru a Cisco firewall by chance? I had the same issue with Site to site calls that were going thru a PIX.

Kevin Wing
ACS- Implement IP Office
ACA- Implement IP Office
Carousel Industries

 

[johnnybrian]

Well not technically, just going through a cisco `GRE tunnel, directly connected. So that cant be the issue.

Also, it used to work fine before upgrading to 5.08! Thats the strange part!

 

[TheSmash]

I have seen something similar to this before. The situation is different but the end result is the same, i.e the call cuts off after 90 seconds. Bear with me...

In our case the call was made across an SCN. When the Call Pickup Members feature was invoked to intercept the call, the call would cut off after 90 seconds.

After about 3 month of traces, changing direct media etc it turned out to be an Avaya problem all along (they blamed the customers network the whole time). Upgrading the customer from 4.1.15 to 4.2.14 resolved the issue (I believe the fix was actually in 4.2.4 but by the time Avaya finally admitted it was their problem 4.2.14 was out!).

So although not the same I can see how this might be a problem with the software upgrade. If you look through all the CQ number, have a look and see how many refer to call cut off after 90 seconds.

Don't ask me, I didn't design it.

 

[johnnybrian]

Yeah it sound about the same! Strange thing is though, that i am running the latest software on the IPO?

 

[kwing112000]

Do you by chance have the SIP inspects/Fixups on in your Cisco.

Kevin Wing
ACS- Implement IP Office
ACA- Implement IP Office
Carousel Industries

 

[CarGoSki]

You Rxed a bye and timeout before you TXed. If the traces you posted are in the correct sequence(meaning traces before send a TX bye) then my "guess" is that the far end killed the session.

Table 2 Default SIP Event to PSTN Cause Code Mapping

SIP Event PSTN Cause Code Description
408 Request timeout 102 Recover on Expires timeout

http://www.cisco.com/en/US/docs/ios/12_2t/12_2t11/feature/guide/ftmap.html

 

[johnnybrian]

Hmm its an audiocodes box in the other end, and yes you are right. It seems like the audiocodes RX´es a BYE. But the audiocodes has not been tampered with, the only thing that has happened is an upgrade to 5 on the ipo..

 

[hairlessupportmonkey]

set your global times outs to 0:00 on the cisco then diable it. if you just disable it, it defaults to what ever is in the box.

also you can now no alter the NAT binding refresh times on the IP500 v5 as well.

 

[johnnybrian]

Okay i figured it out! The audiocodes has a setting called "Minimum session expires" set to 90 seconds. I figured this must be the one kicking in. I changed this to 120 seconds, and the twinned calls disconnected after (Obviously) 120 seconds.

So under this setting, there was another setting called "Session Expires Method" set to Re-Invite. I changed it to "Update" instead, and everything works.

So this leaves me with a couple of unresolved questions still;
1: Why did this problem only occur on twinned calls, NOT on regular calls?
2: Why is the RE-invite not working after upgrading to 5.08 ( i checked the SIP line on the Avaya, and re-invite was set to enabled and supported)

This is all very weird, but my problem is gone so i guess im happy.... Thanks for all your suggestions!

 

[Bas1234]

Why use AudioCodes? Now you cannot get the Avaya one-X Mobile Client to work. Just put some SIP lincenses in and let the IP500 do all the work.

___________________________________________
It works! Now if only I could remember what I did...

Dain Bramaged
___________________________________________

 

[Bas1234]

For your second question:

Check the "Binding Refresh Time" set it to 60 or 30 sec, it depens on the AudioCodes but mostly 30 will do but this will cause a bit more traffic on the network.



Binding Refresh Time (seconds): Default = 0 (Never), Range = 0 to 3600 seconds.
Having established which TCP/UDP port number to use, through either automatic or manual configuration, the IP Office can send recurring ‘SIP Options requests’ to the remote proxy terminating the trunk. Those requests will keep the port open through the firewall. Requests are sent every x seconds as configured by this field.

___________________________________________
It works! Now if only I could remember what I did...

Dain Bramaged
___________________________________________

 

[johnnybrian]

Bas1234 >>

Why do i use audiocodes?
1 Because my provider in Ukraine cannot transfer this company´s existing numbers to a SIP operator, and 2; because i use an Iphone and the one-x client is not supported on this as far as i know.