<?xml version="1.0" encoding="UTF-8"?>
<feed xmlns="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <title>CUCM sends INVITE after 900 sec</title>
  <link rel="alternate" href="http://developer.cisco.com/c/message_boards/find_thread?p_l_id=&amp;threadId=5029144" />
  <subtitle>CUCM sends INVITE after 900 sec</subtitle>
  <id>http://developer.cisco.com/c/message_boards/find_thread?p_l_id=&amp;threadId=5029144</id>
  <updated>2013-05-20T05:06:02Z</updated>
  <dc:date>2013-05-20T05:06:02Z</dc:date>
  <entry>
    <title>RE: CUCM sends INVITE after 900 sec</title>
    <link rel="alternate" href="http://developer.cisco.com/c/message_boards/find_message?p_l_id=&amp;messageId=5039132" />
    <author>
      <name>David Staudt</name>
    </author>
    <id>http://developer.cisco.com/c/message_boards/find_message?p_l_id=&amp;messageId=5039132</id>
    <updated>2012-01-21T00:20:48Z</updated>
    <published>2012-01-21T00:20:48Z</published>
    <summary type="html">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.)</summary>
    <dc:creator>David Staudt</dc:creator>
    <dc:date>2012-01-21T00:20:48Z</dc:date>
  </entry>
  <entry>
    <title>RE: CUCM sends INVITE after 900 sec</title>
    <link rel="alternate" href="http://developer.cisco.com/c/message_boards/find_message?p_l_id=&amp;messageId=5035265" />
    <author>
      <name>Sascha Monteiro</name>
    </author>
    <id>http://developer.cisco.com/c/message_boards/find_message?p_l_id=&amp;messageId=5035265</id>
    <updated>2012-01-20T01:34:26Z</updated>
    <published>2012-01-20T01:34:26Z</published>
    <summary type="html">cucm7.1

this is from wireshark;
BYE sip:9.1.1.222:5060;transport=tcp SIP/2.0
Route: &lt;sip:9.1.1.222:5060;transport=tcp;appname=CiscoStreamingRecorder;final_response=true;lr&gt;
Reason: Q.850;cause=86
Date: Wed, 18 Jan 2012 21:23:04 GMT
From: "TK" &lt;sip:45@9.1.1.71;x-nearend;x-refci=17435925;x-nearenddevice=SEP002584179241&gt;;tag=ea21c2f9-ce2a-413c-a933-cb6751cb8e6c-17435930
Content-Length: 0
User-Agent: Cisco-CUCM7.1
To: &lt;sip:911222@9.1.1.222&gt;;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" &lt;sip:45@9.1.1.71&gt;
CSeq: 103 BYE
Max-Forwards: 70</summary>
    <dc:creator>Sascha Monteiro</dc:creator>
    <dc:date>2012-01-20T01:34:26Z</dc:date>
  </entry>
  <entry>
    <title>RE: CUCM sends INVITE after 900 sec</title>
    <link rel="alternate" href="http://developer.cisco.com/c/message_boards/find_message?p_l_id=&amp;messageId=5027854" />
    <author>
      <name>Dan-Anders Hook</name>
    </author>
    <id>http://developer.cisco.com/c/message_boards/find_message?p_l_id=&amp;messageId=5027854</id>
    <updated>2012-01-19T14:23:14Z</updated>
    <published>2012-01-19T14:23:14Z</published>
    <summary type="html">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</summary>
    <dc:creator>Dan-Anders Hook</dc:creator>
    <dc:date>2012-01-19T14:23:14Z</dc:date>
  </entry>
  <entry>
    <title>RE: CUCM sends INVITE after 900 sec</title>
    <link rel="alternate" href="http://developer.cisco.com/c/message_boards/find_message?p_l_id=&amp;messageId=5029260" />
    <author>
      <name>Abdul Rasheed</name>
    </author>
    <id>http://developer.cisco.com/c/message_boards/find_message?p_l_id=&amp;messageId=5029260</id>
    <updated>2012-01-19T06:38:44Z</updated>
    <published>2012-01-19T06:38:44Z</published>
    <summary type="html">Hello,
               which is the version of your call manager?  what is the reason of BYE in wireshark?


Best regards
Rasheed</summary>
    <dc:creator>Abdul Rasheed</dc:creator>
    <dc:date>2012-01-19T06:38:44Z</dc:date>
  </entry>
  <entry>
    <title>CUCM sends INVITE after 900 sec</title>
    <link rel="alternate" href="http://developer.cisco.com/c/message_boards/find_message?p_l_id=&amp;messageId=5029143" />
    <author>
      <name>Sascha Monteiro</name>
    </author>
    <id>http://developer.cisco.com/c/message_boards/find_message?p_l_id=&amp;messageId=5029143</id>
    <updated>2012-01-19T05:29:49Z</updated>
    <published>2012-01-19T05:27:03Z</published>
    <summary type="html">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!</summary>
    <dc:creator>Sascha Monteiro</dc:creator>
    <dc:date>2012-01-19T05:27:03Z</dc:date>
  </entry>
</feed>

