« Back to SIP Trunk Questions

CUCM sends INVITE after 900 sec

Combination View Flat View Tree View
Threads [ Previous | Next ]
CUCM sends INVITE after 900 sec
cucm sip sip trunk recording
Answer
1/19/12 5:29 AM
Hi,
 
We have built a Recorder that receives calls via a SIP trunk (recording profile) through the IPPhone's built in bridge
 
It works fine until the call gets to 900 seconds, we receive another INVITE and it looks like our app sends a Trying,
then CUCM sends BYE
 
I could not find this behaviour in SIP docs, is it a keep-alive? Should CUCM send this? What should happen?
 
This is a wireshark trace from our server, appreciate any feedback!
Attachments:
Flag

RE: CUCM sends INVITE after 900 sec
Answer
1/19/12 6:38 AM as a reply to Sascha Monteiro.
Hello,
which is the version of your call manager? what is the reason of BYE in wireshark?


Best regards
Rasheed
Flag

RE: CUCM sends INVITE after 900 sec
Answer
1/19/12 2:23 PM as a reply to Sascha Monteiro.
Hi,

Sounds like interop problems with session refresh. Try changing the CUCM Service parameter "SIP Session Expires Timer". A refresh is sent after half this time, and the default is 1800 sec. I have changed this to 86400 (max) for some customers due to the same reason.

Kind regards,

//Dan
Flag

RE: CUCM sends INVITE after 900 sec
Answer
1/20/12 1:34 AM as a reply to Abdul Rasheed.
cucm7.1

this is from wireshark;
BYE sip:9.1.1.222:5060;transport=tcp SIP/2.0
Route: <sip:9.1.1.222:5060;transport=tcp;appname=CiscoStreamingRecorder;final_response=true;lr>
Reason: Q.850;cause=86
Date: Wed, 18 Jan 2012 21:23:04 GMT
From: "TK" <sip:45@9.1.1.71;x-nearend;x-refci=17435925;x-nearenddevice=SEP002584179241>;tag=ea21c2f9-ce2a-413c-a933-cb6751cb8e6c-17435930
Content-Length: 0
User-Agent: Cisco-CUCM7.1
To: <sip:911222@9.1.1.222>;tag=3585576
Call-ID: 810c8100-f17134b3-9bf3-47010109@9.1.1.71
Via: SIP/2.0/TCP 9.1.1.71:5060;branch=z9hG4bK9c6c5c46eb4d
P-Preferred-Identity: "TK" <sip:45@9.1.1.71>
CSeq: 103 BYE
Max-Forwards: 70
Flag

RE: CUCM sends INVITE after 900 sec
Answer
1/21/12 12:20 AM as a reply to Sascha Monteiro.
cause=86 looks to be Network Timeout, so I agree the SIP session refresh mechanim mentioned above is likely the root cause.  I guess you can either modify the recorder side to interop with the way UCM does this refresh, or modify the timer so that in practice it never occurs (as above.)
Flag