Issues with CUCM SIP Trunk and Hold

[Danny Hain]

Hi

I am hoping someone can help out with this issue

I am having issues with a SIP trunk on a 2911 CUBE router, the connection is between CUCM9.1 <–> 2911 CUBE <–> 3^RD party SIP Contact Centre.

Some calls work perfectly however other calls suffer an issue where a call drops when it is placed on hold by the 3^RD party SIP Contact Centre.

The logs that I have collected from the 2911 CUBE show that when the call fails the CUBE router receives the re-invite for hold from the 3^rd party SIP Contact centre however it never sends another re-invite to CUCM and it never responds to the contact centre with an OK either.

The logs also show that when the call works the CUBE router receives the re-invite from the 3^rd party SIP Contact centre, it then sends a re-invite to CUCM and when the responses come back from CUCM the OK and ACK messages all proceed as per a normal SIP call.

There is a slight difference in the sequence of events during the initial call setup of both a failed and a successful call.

In a successful call an update message is sent from CUCM, however before the CUBE responds to this update the CUBE re-invites the 3^RD party SIP Contact Centre. All of this happens in the initial call setup which I can see based on the timestamps of the messages, I don't understand what this re-invite is for because as far as I can see it doesn't change anything.

In a failed call an update message is sent from CUCM and the CUBE responds immediately and the re-invite never occurs.

I have attached the logs I collected.

[Nishant Savalia]

Hi Danny,

Please share your 2911 CUBE router configuration.

Also correct me if i am wrong for below:-

10.20.97.131 --- IP address of CUCM

10.20.26.11  ---- CUBE IP address

10.20.95.113 --- 3rd party IP address

Regards,

Nishant Savalia

[Nishant Savalia]

Successful Call:-

Re-Invite message contains Min-SE timer = 180

Failed Call:-

Re-Invite message contains Min-SE timer = 1800

Collect "debug ccsip all" and check if you are hitting with media inactive detection timer.

Regards,

Nishant Savalia

[Danny Hain · Accepted solution]

Hi Nishant

Yeah I had thought of that and I did collect those messages, it wasn't what was happening.

The issue is that there is never an OK sent back to the re-invite when the call is placed on hold.

It seemed to be caused by CUCM using updates and the message exchange never completing, so I forced CUCM to use re-invite instead of update by removing UPDATE from the list of supported headers.

I used the following SIP profile and that has solved the issue, just waiting on a full test to be run by a contact centre agents to be 100% sure:

voice class sip-profiles 100

request ANY sip-header Allow-Header modify "UPDATE, " ""

response ANY sip-header Allow-Header modify "UPDATE, " ""

[Danny Hain]

Full test worked perfectly.

Hope this helps someone else out as well

[Nishant Savalia · Accepted solution]

HI Danny,

Had a thought of it earlier but where i stucked was why it works sometimes even if update message is being sent by CUCM?

Regards.

Nishant Savalia

[Ayodeji Okanlawon]

Danny,

Great Job! and thanks for updating the thread..

Please rate all useful posts

"opportunity is a haughty goddess who waste no time with those who are unprepared"

[Nishant Savalia]

Hi aokan,

Can you please put your insight for my query?

Regards,

Nishant Savalia

[Ayodeji Okanlawon]

HI Nishant,

I am not sure I understand which query you are reffing to. Can you clarify

Please rate all useful posts

"opportunity is a haughty goddess who waste no time with those who are unprepared"

[Nishant Savalia]

In case of successful call CUCM was sending UPDATE message and CUBE sends re-invite message, while in case of Failed call also CUCM was sending UPDATE message CUBE does not send re-invite message.

On what basis CUBE is working randomly ?

Regards,

Nishant Savalia

[Ayodeji Okanlawon]

Nishant the only difference I see in the trace is that in the failed scenario, the 3rd party UAS sends the re-invite 4secs after the UPDATE while in the succesfull call it came 8sec after the UPDATE

++successful+++

Dec  6 19:12:20: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
UPDATE sip:738835305@10.20.26.11:5060 SIP/2.0

Dec  6 19:12:28: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
INVITE sip:00439746061@10.20.26.11:5060 SIP/2.0
Via: SIP/2.0/UDP 10.20.95.113:5060;branch=z9hG4bK-102ED51C7DDE5471141BAF26938AE057F4D-xo
To: <>00439746061@superretailgroup.com>;tag=1261B40C-2472
From: <738835305>;tag=ED51C7DDE5471141BAF26938AE057F4D-xo
Call-ID: 50E6D426-5D8D11E3-8B2AD869-CA0CCF7C@10.20.26.11
User-Agent: SAP BCM SIP Bridge 7.0.4.122
CSeq: 102 INVITE
Max-Forwards: 69
Supported: timer, replaces, 100rel
Contact: <738835305>
Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER, REGISTER, PRACK
Accept: application/sdp
Session-Expires: 1800;refresher=uac
Min-SE: 180
Content-Type: application/sdp
Content-Length: 210

+++Failed+++

Dec  6 19:09:05: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
UPDATE sip:738835305@10.20.26.11:5060 SIP/2.0

Dec  6 19:09:09: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
INVITE sip:00439746061@10.20.26.11:5060 SIP/2.0

Please rate all useful posts

"opportunity is a haughty goddess who waste no time with those who are unprepared"

[Nishant Savalia]

True and that's what the question is. 3rd party can send re-invite message any time (i.e user can put the call on hold any time) irrespective of UPDATE message sent by CUCM.

Regards,

Nishant Savalia

[Ayodeji Okanlawon]

You are correct...

Danny can you post a debug output with the new sip profiles in place...Lets see what the traces look like

Please rate all useful posts

"opportunity is a haughty goddess who waste no time with those who are unprepared"

[Danny Hain]

HI Everyone

The call seems to break during the initial setup, not when the call is actually placed on hold.

A working call followed the following sequence near the end of the inital call setup

- CUCM --> 2911: UPDATE seq 102

- 3RD Party SIP --> 2911: ACK seq 101 (this was the ack to the previous messages where the contact centre transfered the call to an agent)

- 2911 --> 3RD Party SIP: Invite seq 102

- 2911 --> CUCM: OK seq 102 (This is the OK to the UPDATE)

A failed call followed the following sequence near the end of the inital call setup

- CUCM --> 2911: UPDATE seq 102

- 2911 --> CUCM: OK seq 102 (This is the OK to the UPDATE)

- 3RD Party SIP --> 2911: ACK seq 101 (this was the ack to the previous messages where the contact centre transfered the call to an agent)

If you look at the logs the 2911 when the call fails it never sends invite of sequence 102 to the Contact Centre, this behavour was consistant and depended on when the ACK 101 was recieved from the Contact Centre.

So the call would break during the initial call setup which caused the 2911 to not process the hold re-invite correctly.

I now that I have removed update from the list of supported headers on all replies from the 2911, CUCM uses re-invite instead of update which has fixed the issue.

attached are the logs of the call now that I have disabled updates, if you look you will see that in the OK response to the initial invite the list of supported headers doesn't include update