Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

SIP Outbound Calls Drop After 3 mins

Hi,

 

I have an odd problem that I'm tearing out what little hair I have left over smiley I hope someone can help.

So my scenario is this. CUCM 8.6 through CUBE (running on 2811 IOS 15.1.4(M8)) to multiple SIP providers, sipgate.co.uk for inbound calls, and voip-unlimited.co.uk for outbound. As you have probably guessed I'm in the UK.

 

So, inbound all is well. Calls come in, everything works fine, hold, transfer, park, no problem. Outbound its a different story. Calls connect fine, all funtions work as expected, but regardless of the call type or destination, the call clears at approx 3 mins (usual between 3:15 and 3:26). It doesn't matter if I am speaking, on mute or the remote party has the call on hold, it just drops.

 

I raised a fault with the provider, who tells me that every time, the call cleared normally, and if I take a trace I can see the 'BYE' messages but I have no idea why this is happening. It has to be a missed ACK or something I assume. but that's a guess.

 

I would really appreciate it if one of the kind people amongst you could offer some advice, and if you need to see debugs or packet captures I can provide them.

 

Hope to hear from someone, and thanks

 

Pete

 

 

 

 

17 REPLIES

Hello Pete, Mostly this kind

Hello Pete,

 

Mostly this kind of issues seem to be with Min-SE timer.

 

could you please collect debug ccsip message & debug voice ccapi inout for a test call?

Please include the calling/called numbers & the related sip configurations

 

//Suresh

Please rate all the useful posts

//Suresh Please rate all the useful posts.

if possible , please collect

if possible , please collect "debug ccsip all" when the call volume is low.

//Suresh Please rate all the useful posts.
New Member

Hi Suresh, Thanks for

Hi Suresh,

 

Thanks for replying. Please see attached trace.

 

Call was made from 01162988360 to 07775795761 (desk to mobile) Call was dropped exactly 3mins 26secs - which it is pretty much all the time.

 

Pete

New Member

 Hi pete,We are receving BYE

 

Hi pete,

We are receving BYE message from Service Provider. So, kindly check with SP and if possible get sip traces from SP as well.

Check SIP expries timer from CUCM

Received:
BYE sip:7001@212.159.28.53:52504 SIP/2.0
Max-Forwards: 68
To: "Peter Moore" <sip:01162988360@212.159.28.53>;tag=95D83078-3B8
From: <sip:07775795761@sip.voip-unlimited.net>;tag=3608546273-311804
Call-ID: BF102DFB-D5EF11E3-A6B79511-262FF1E6@212.159.28.53
CSeq: 2 BYE
Allow: CANCEL, ACK, INVITE, BYE, OPTIONS, REGISTER, NOTIFY, INFO, REFER, SUBSCRIBE, PRACK, UPDATE, MESSAGE, PUBLISH
Via: SIP/2.0/UDP 91.151.2.130;branch=z9hG4bK4813.71c12bb.0
Via: SIP/2.0/UDP 91.151.11.20:5060;rport=5060;received=91.151.11.20;branch=z9hG4bK5219f3ad266e8402eeafcf7a8c64c01c
Contact: <sip:07775795761@91.151.11.20:5060>
Content-Length: 0

Hi, I see the Invite message

Hi,

 

I see the Invite message to the provider is missing in the log.

Also the 200 OK message was received twice from the provider.

 

May  8 13:59:12.129: //48077/E79F5C800000/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 200 OK
Session-Expires: 3600;refresher=uas
Require: timer
Via: SIP/2.0/UDP 212.159.28.53:5060;rport=52504;received=212.159.28.53;branch=z9hG4bK74E7519
Record-Route: <sip:91.151.2.130;lr=on;ftag=95D83078-3B8;nat=yes>
To: <sip:07775795761@sip.voip-unlimited.net>;tag=3608546273-311804
From: "Peter Moore" <sip:01162988360@212.159.28.53>;tag=95D83078-3B8
Call-ID: BF102DFB-D5EF11E3-A6B79511-262FF1E6@212.159.28.53
CSeq: 102 INVITE
Allow: CANCEL, ACK, INVITE, BYE, OPTIONS, REGISTER, NOTIFY, INFO, REFER, SUBSCRIBE, PRACK, UPDATE, MESSAGE, PUBLISH
Contact: <sip:07775795761@91.151.11.20:5060>
Content-Type: application/sdp
Accept: application/sdp
Content-Length: 518

 

2nd 200 OK message.

 

May  8 13:59:12.629: //48077/E79F5C800000/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 200 OK
Session-Expires: 3600;refresher=uas
Require: timer
Via: SIP/2.0/UDP 212.159.28.53:5060;rport=52504;received=212.159.28.53;branch=z9hG4bK74E7519
Record-Route: <sip:91.151.2.130;lr=on;ftag=95D83078-3B8;nat=yes>
To: <sip:07775795761@sip.voip-unlimited.net>;tag=3608546273-311804
From: "Peter Moore" <sip:01162988360@212.159.28.53>;tag=95D83078-3B8
Call-ID: BF102DFB-D5EF11E3-A6B79511-262FF1E6@212.159.28.53
CSeq: 102 INVITE
Allow: CANCEL, ACK, INVITE, BYE, OPTIONS, REGISTER, NOTIFY, INFO, REFER, SUBSCRIBE, PRACK, UPDATE, MESSAGE, PUBLISH
Contact: <sip:07775795761@91.151.11.20:5060>
Content-Type: application/sdp
Accept: application/sdp
Content-Length: 518

 

>> but CUBE didn't send ACK and finally Provider disconnects the calls with BYE message.

 

May  8 14:02:40.528: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
BYE sip:7001@212.159.28.53:52504 SIP/2.0
Max-Forwards: 68
To: "Peter Moore" <sip:01162988360@212.159.28.53>;tag=95D83078-3B8
From: <sip:07775795761@sip.voip-unlimited.net>;tag=3608546273-311804
Call-ID: BF102DFB-D5EF11E3-A6B79511-262FF1E6@212.159.28.53
CSeq: 2 BYE
Allow: CANCEL, ACK, INVITE, BYE, OPTIONS, REGISTER, NOTIFY, INFO, REFER, SUBSCRIBE, PRACK, UPDATE, MESSAGE, PUBLISH
Via: SIP/2.0/UDP 91.151.2.130;branch=z9hG4bK4813.71c12bb.0
Via: SIP/2.0/UDP 91.151.11.20:5060;rport=5060;received=91.151.11.20;branch=z9hG4bK5219f3ad266e8402eeafcf7a8c64c01c
Contact: <sip:07775795761@91.151.11.20:5060>
Content-Length: 0

>> also in the 200 OK message received from provider we have "Session-Expires: 3600;refresher=uas" so it is provider who will have to refresh the session before it expires.

 

>> not sure why CUBE don't send ACK to provider. but as Nevin said, could you please check once again with your provider on why they are disconnecting the call?

 

Could you please also share the CUBE configuration? let's check if anything wrong in the configuration part.

 

//Suresh

Please rate all the useful posts

//Suresh Please rate all the useful posts.
New Member

Hi Suresh & Nevin, Thanks

Hi Suresh & Nevin,

 

Thanks once again for your help. I have already raised this as a fault with the provider, who to be honest didn't seem to know what the issue is. They said the calls clear down normally.

 

Anyway, the providers portal allows me to look at the trace info for each call, so I have attached a screen shot of the call flow, plus a decode of each frame in the call flow and also the relevant sections of my voice gateway/CUBE config so you have a complete picture.

 

Once again thank you both for all your help.

 

Pete

From this attached screenshot

From this attached screenshot, we see that CUBE is sending ACK to provider which was not showing up in the collected logs.

 

the other thing to be noticed is that the BYE message comes from 91.151.11.20 has 7001 instead of 01162988360.

 

can we get the packet number below packet number

 - 5 (INVITE sent from 212.159.28.53 to 91.151.2.130)

- 8 (INVITE sent from 91.151.2.130 to 91.151.11.20)

- 14 (200 OK sent from 91.151.11.20 to 91.151.2.130)

- 17 (ACK sent from 91.151.2.130 to 91.151.11.20)

- 18 (BYE sent from 91.151.11.20 to 91.151.2.130)

 

Thanks

Suresh

//Suresh Please rate all the useful posts.
New Member

Hi Suresh, Please see

Hi Suresh,

 

Please see attached trace for all frames.

 

Thanks

 

Pete

 

Hi Pete,

Hi Pete, I couldn't find any relevant errors in the logs, also I doubt it is the issue with timers. I feel it's something we need to take it up with the provider. //Suresh
//Suresh Please rate all the useful posts.
New Member

Thanks Suresh,I will re-open

Thanks Suresh,

I will re-open the ticket with them, it does look like the provider initiates the BYE message.

 

Appreciate you looking .

 

Pete

New Member

Hi, One last ditch attempt to

Hi,

 

One last ditch attempt to troubleshoot this! The SIp provider tells me that "there is no SDP detail in the invite header' which apparently is incorrect.

 

Just to be sure this isnt a provider specific issue, I tested it with another provider, who is able to deliver inbound calls with no issue, and the results were identical. Call dropped after 3mins 26 seconds.

 

Any suggestions ?

 

Thanks again

 

Pete

can you get the "show sip-ua

can you get the "show sip-ua timers" from CUBE?

 

also check the values of below parameters in CUCM, Service parameter configuration page

1) SIP Session Expires Timer
2) SIP Min-SE Value
3) SIP Expires Timer 

 

Thanks

Suresh

//Suresh Please rate all the useful posts.
New Member

Hey Suresh, I  think I have

Hey Suresh,

 

I  think I have fixed it. I just changed a setting in the SIP profile assigned to my CUBE:

"Send send-receive SDP in mid-call INVITE" [Checked]

restarted the trunk, and made and outbound call that carried on beyond the 3.26 - I cleared the call at 5 mins, all was well.

 

I will do more testing and advise in case anyone else has this issue.

 

Pete

 

 

Hi Pete,"The SIP provider

Hi Pete,

"The SIP provider tells me that "there is no SDP detail in the invite header' which apparently is incorrect"

 

- No, we are sending Delayed Offer call to ITSP. If you check the Frame #5, we didn't send out SDP in the INVITE message and the call was negotiated as Delayed Offer Call, but the as per your statement, the ITSP is expecting us to send Early Offer call (SDP in the initial INVITE).

 

 

 

Frame 5 (1129 bytes on wire, 1129 bytes captured)
Arrival Time: May  8, 2014 18:15:03.524327000
Internet Protocol, Src: 212.159.28.53 (212.159.28.53), Dst: 91.151.2.130 (91.151.2.130)
User Datagram Protocol, Src Port: 63825 (63825), Dst Port: sip (5060)
Session Initiation Protocol
    Request-Line: INVITE sip:07775795761@sip.voip-unlimited.net:5060 SIP/2.0
        Method: INVITE
        Request-URI: sip:07775795761@sip.voip-unlimited.net:5060
            Request-URI User Part: 07775795761
            Request-URI Host Part: sip.voip-unlimited.net
            Request-URI Host Port: 5060
        [Resent Packet: False]
    Message Header
        Via: SIP/2.0/UDP 212.159.28.53:5060;branch=z9hG4bK758719F6
            Transport: UDP
            Sent-by Address: 212.159.28.53
            Sent-by port: 5060
            Branch: z9hG4bK758719F6
        From: "Peter Moore" <sip:01162988360@212.159.28.53>;tag=968B9F40-111B
            SIP Display info: "Peter Moore"
            SIP from address: sip:01162988360@212.159.28.53
                SIP from address User Part: 01162988360
                SIP from address Host Part: 212.159.28.53
            SIP tag: 968B9F40-111B
        To: <sip:07775795761@sip.voip-unlimited.net>
            SIP to address: sip:07775795761@sip.voip-unlimited.net
                SIP to address User Part: 07775795761
                SIP to address Host Part: sip.voip-unlimited.net
        Date: Thu, 08 May 2014 17:15:03 GMT
        Call-ID: 20CD4529-D60B11E3-A6DB9511-262FF1E6@212.159.28.53
        Supported: timer,resource-priority,replaces,sdp-anat
        Min-SE:  1800
        Cisco-Guid: 1236896512-0000065536-0000000040-3360377610
            [Expert Info (Note/Undecoded): Unrecognised SIP header (Cisco-Guid)]
                [Message: Unrecognised SIP header (Cisco-Guid)]
                [Severity level: Note]
                [Group: Undecoded]
        User-Agent: Cisco-SIPGateway/IOS-12.x
        Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
        CSeq: 102 INVITE
            Sequence Number: 102
            Method: INVITE
        Timestamp: 1399569303
        Contact: <sip:7001@212.159.28.53:5060>
            Contact Binding: <sip:7001@212.159.28.53:5060>
                URI: <sip:7001@212.159.28.53:5060>
                    SIP contact address: sip:7001@212.159.28.53:5060
        Expires: 300
        Allow-Events: telephone-event
        Proxy-Authorization: Digest username="01162988360",realm="212.159.28.53",uri="sip:07775795761@sip.voip-unlimited.net:5060",response="19edeb311acaab8aa068fd6ad37388f5",nonce="536bbbb50000b8b06612b93b322a722f5909ff6a2cbfd470",algorithm=md5
            Authentication Scheme: Digest
            Username: "01162988360"
            Realm: "212.159.28.53"
            Authentication URI: "sip:07775795761@sip.voip-unlimited.net:5060"
            Digest Authentication Response: "19edeb311acaab8aa068fd6ad37388f5"
            Nonce Value: "536bbbb50000b8b06612b93b322a722f5909ff6a2cbfd470"
            Algorithm: md5
        Max-Forwards: 69
        P-Asserted-Identity: "Peter Moore" <sip:01162988360@212.159.28.53>
            SIP Display info: "Peter Moore"
            SIP PAI Address: sip:01162988360@212.159.28.53
                SIP PAI User Part: 01162988360
                SIP PAI Host Part: 212.159.28.53
        Session-Expires:  86400
        Content-Length: 0

 

 

>> Though we have configured 'early-offer forced' globally, it didn't take affect. so let's try configuring it (voice-class sip early-offer forced) under the outbound dial-peer 200 and check the bahaviour.

>> while testing this configuration, pleas uncheck the Send send-receive SDP in mid-call INVITE and test it.

//Suresh Please rate all the useful posts.
New Member

on the Mitel systems, this

on the Mitel systems, this can be set forcefully.

Is this setting available to you on your system?

 

New Member

kindly check sip parameter in

kindly check sip parameter in service parameter (CUCM) :

SIP Expires Timer

Check from where we are getting BYE message in the traces

New Member

Hi Pete

Hi Pete

How did you solve this?  I am having exactly the same issue.

1767
Views
10
Helpful
17
Replies