PSTN user of Conference call disconnect

[Humza Khan]

Hi,

Conference call is working fine but we add any pstn user in call, only pstn user call disconnects after 23 mins.

Any idea how to resolve the issue.

help required.

Regards,

HK

[Deepak Mehta]

Please run the debug isdn q931 to see what disconnect cause code you are getting when call is getting disconnected.

Thanks

[Humza Khan]

We are using sip trunk, so i don't think isdn q931 output helpful for us.

Attaching logs as well, kindly check 

Regards,

HK

[Leszek Wojnarski]

Hi Humza,

So what we can see in the traces is that BYE message is cumming from SIP SP, with the reason code 16 which translates to "Normal call clearing"

Jun 8 20:29:17.082 BST: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
BYE sip:01912236205@10.34.0.20:5060 SIP/2.0
Via: SIP/2.0/UDP 193.113.149.50:5060;branch=z9hG4bK94rlo4107og06ggqa5k0.1
From: "Anonymous"<sip:anonymous@193.113.149.50>;tag=rHB3dQ
To: "01912236205" <sip:01912236205@10.34.0.20>;tag=F4BB8E04-1620
Date: Wed, 08 Jun 2016 19:23:37 GMT
Call-ID: 37E7D98D-2CE311E6-935FFFC2-C78FA0FB@10.34.0.23
User-Agent: Cisco-SIPGateway/IOS-15.4.3.M3
Timestamp: 1465414157
CSeq: 770233 BYE
Reason: Q.850;cause=16
Session-ID: 5f7dd0fa91aa00738e9e99ba67162392;remote=be694fafa15e41a6e3b009ab11246664
Max-Forwards: 67
P-RTP-Stat: PS=62435,OS=9977432,PR=62370,OR=9979200,PL=0,JI=0,LA=0,DU=1247
Content-Length: 0

So next question would be to ask SIP SP why do they disconnect this call.

Once we have information from them then we can see if there is anything we can do about it.

Another useful thing would be to see all debugs, including beginning of the conversation. Common thing for such disconnects would be session expires timer, or similar, so it's good to see what was initially negotiated.

Leszek

[Humza Khan]

Thanks Leszek,

Provider traces are here, kindly check.

Regards,

HK

[Leszek Wojnarski]

Hi Humza,

Thanks for the traces. So it looks like the call is indeed disconnected because of the Session-Expires timer.

So the reason why you would see the call disconnected after 22min 30 seconds is, that default timer the is advertised for this session is 900 which is 15 minutes.

During first timer negotiation all is good, and CUBE is sending RE-INVITE after half of the session expires timer which is 6:30 seconds.

Then another timer negotiation happens with RE-INVITE  at 

20:13:58:358280, RE-INVITE (To:+441912841012, SDP profile)

And this is 15 minutes and CUCBE is UAC responsible for sending this RE-INVITE.

Because of this CUBe thinks we never agreed on the timer so next time it will never send the RE-INVITE. So CUBE allow this session to expire which is 900 second.

So 900 + 450 seconds is 22:30 minutes where the session expires.

HTH,

Leszek

[Humza Khan]

Hi,

Here is the reply by ITSP, kindly check and suggest.

 {31} 08/06/16 20:06:28:341332  The RE-INVITE comes from 10.34.0.20 , and all is well.

that includes:

Allow-Events: telephone-event
Session-Expires: 900;refresher=uac

And this is 15 minutes and CUBE is UAC responsible for sending this RE-INVITE.

{33} 08/06/16 20:06:28:344027   The response is that the BT SBC forwards the 100 Trying  to the RE-INVITE

{34} 08/06/16 20:06:28:352955      RTP is started By 10.34.0.20 towards BT SBC

{35} 08/06/16 20:06:28:378553      BT SBC forwards 491 Request pending , (this was received from the far end network we are not sure why exactly).

{36} 08/06/16 20:06:28:382588      RTP is started in the Direction BT SBC to 10.34.0.20

{37} 08/06/16 20:06:28:387415     An ACK   (with No SDP) is sent by 10.34.0.20 in response to the 491 .

{38} 08/06/16 20:06:28:568955  Another New Re-INVITE is sent by 10.34.0.20 , again all is well ,

that includes:

Allow-Events: telephone-event
Session-Expires: 900;refresher=uac

And this is 15 minutes and CUBE is UAC responsible for sending this RE-INVITE.

{40} 08/06/16 20:06:28:571593    The response is that the BT SBC forwards the 100 Trying  to the RE-INVITE same as line 33 .

{41} 08/06/16 20:06:28:613776  The BT SBC Forwards the 200 OK with SDP  as per the responses before line 31 , so ‘normality’ has resumed, and 10.34.0.20 has responsibility to                              send the RE-INVITE as before

This includes

Require: timer
Supported: timer
Session-Expires: 900;refresher=uac      (this is 15mins)

{43} 08/06/16 20:06:28:623481  An ACK   (with No SDP) is sent by 10.34.0.20 in response to the 200 OK with SDP .

{44} 08/06/16 20:13:58:358280  At  7 mins 30 secs into the call A RE-INVITE is sent by 10.34.0.24 as expected .However at this point there is no ;

Session-Expires: 900;refresher=uac

{46} 08/06/16 20:13:58:360988  The response is that the BT SBC forwards the 100 Trying to the RE-INVITE   followed by

{47} 08/06/16 20:13:58:419208 The BT SBC Forwards the 200 OK with SDP  in response to the RE-INVITE as per earlier on in the call .

This includes

Require: timer
Supported: timer
Session-Expires: 900;refresher=uac      

{49} 08/06/16 20:13:58:431982  An ACK   (with No SDP) is sent by 10.34.0.20 in response to the 200 OK .

{50} 08/06/16 20:28:58:402762  RTP is  ended by the Originating end as no RE-INVITE has been received with the  

Session-Expires: 900;refresher=uac  from      10.34.0.20   this is 15 mins after the last ‘good’ RE-INVITE at line 41.

I would also comment that there appears to be  unusual behaviour at the beginning of the call with 3 RE-INVITES being send within a second  (after the DTMF) .

A point to note is that the codec agreed is G711ulaw , which is fine, just not ‘normally ‘ used within Europe.

Regards,

HK

[Leszek Wojnarski]

Hi Humza,

Ok, I've missed that last timer negotiation.

Can we get debugs from the CUBE, to see why it's not sending the RE-INVITE.

We'd need debugg ccsip messages and debug voice ccapi inout.

If possible debug ccsip all - but this one would be a lot of information so we can collect that only if the first two will not show the reason for CUBE not sending Re-INVITE.

Leszek

[Leszek Wojnarski]

Humza,

Will you be able to get those additional set of traces from CUBE?

Leszek