SIP Outbound Calls Drop After 3 mins

[pm115redc]

Hi,

I have an odd problem that I'm tearing out what little hair I have left over 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

[Suresh Subramanian]

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 Subramanian]

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

[pm115redc]

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

[V.Naveen Kumar]

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

[Suresh Subramanian]

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

[pm115redc]

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

[Suresh Subramanian]

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

[pm115redc]

Hi Suresh,

Please see attached trace for all frames.

Thanks

Pete

[Suresh Subramanian]

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

[pm115redc]

Thanks Suresh,

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

Appreciate you looking .

Pete

[pm115redc]

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

[Suresh Subramanian]

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

[pm115redc]

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

[Suresh Subramanian]

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.