IP Telephony and PhonesのトピックThanks Leszek,

PSTN user of Conference call disconnect

Humza Khan — Sun, 17 Mar 2019 14:10:59 GMT

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,

Please run the debug isdn

Deepak Mehta — Thu, 09 Jun 2016 17:41:19 GMT

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

Thanks

We are using sip trunk, so i

Humza Khan — Fri, 10 Jun 2016 09:56:20 GMT

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

Attaching logs as well, kindly check

Regards,

Hi Humza,

Leszek Wojnarski — Fri, 10 Jun 2016 10:10:50 GMT

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

Thanks Leszek,

Humza Khan — Fri, 10 Jun 2016 11:12:56 GMT

Thanks Leszek,

Provider traces are here, kindly check.

Regards,

Hi Humza,

Leszek Wojnarski — Tue, 14 Jun 2016 09:34:12 GMT

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

Hi,

Humza Khan — Tue, 14 Jun 2016 09:34:13 GMT

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,

Hi Humza,

Leszek Wojnarski — Tue, 14 Jun 2016 10:04:32 GMT

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

Humza,

Leszek Wojnarski — Thu, 16 Jun 2016 07:41:33 GMT

Humza,

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

Leszek