Re: [cisco-voip] CUCM 10.5 and OpenText 10.6

[Scott Voll]

Ed-- (Troy too)

Thanks for posting the fix.  That was perfect for our upgrade too!!

Scott


On Fri, May 1, 2015 at 12:48 PM, Countryman, Edward <
edward.country...@presencehealth.org> wrote:

> This turned out to be a setting in Rightfax.  Now working again!
>
> Many thanks to Troy Putnam for emailing me the fix outlined below:
>
>
> In RightFax:
> Log into the Brooktrout Configuration tool
> --> IP Call Control Modules
> --> SIP
> --> T.38 Parameters, and change the Media Renegotiate Delay Outbound,
> msec: from -1 top 500.
>
>
>
>
> -Original Message-
> From: Charles Goldsmith [mailto:wo...@justfamily.org]
> Sent: Thursday, April 30, 2015 5:36 PM
> To: Haas, Neal
> Cc: Countryman, Edward; Cisco VOIP
> Subject: Re: [cisco-voip] CUCM 10.5 and OpenText 10.6
>
> There are no timers in the SIP trunk, but the SIP Profile has several.
>
> Please let us know which timer you find that resolves this?  I have a
> customer that will be going to 10.5 soon and are using RightFax.
>
> Also, RightFax has some good documentation and support, they may have this
> already covered.
>
> On Thu, Apr 30, 2015 at 4:33 PM, Haas, Neal  wrote:
> > We had the same thing with our Accuroute Fax server. We called TAC and
> > it was the time out on the SIP trunk needed to be increased. As soon
> > as we called in the TAC person had us fixed up in minutes.
> >
> >
> >
> > I don’t know the exact thing that had to be changed; the guy that did
> > the work is out this week.
> >
> >
> >
> > If you have 79XX phones, update the COP file for your phones,
> > transfers while on a call with a head set are broken. Calls will just
> > drop with a transfer……
> >
> >
> >
> >
> >
> > Neal Haas
> >
> >
> >
> > From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf
> > Of Countryman, Edward
> > Sent: Thursday, April 30, 2015 3:06 PM
> > To: Cisco VOIP
> > Subject: [cisco-voip] CUCM 10.5 and OpenText 10.6
> >
> >
> >
> > We have had right fax 10.5 up and running with a SIP trunk from our
> > CUCM
> > 8.6.2 environment for a while now.
> >
> >
> >
> > This past weekend we updated to CUCM 10.5.2 and are no longer able to
> > fax out from RF.
> >
> >
> >
> > From the trace, the SIP call appears to fail with the following error
> > after the INVITE
> >
> >
> >
> > 488 Not Acceptable Here
> >
> >
> >
> > Do would anything have changed in 10.5 to possibly be causing this?
>  Weird
> > thing is the inbound faxes are working fine.
> >
> >
> > ___
> > cisco-voip mailing list
> > cisco-voip@puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-voip
> >
> ___
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] UnifiedFX Gurus

[Nick Britt]

Seconded brilliant product. Pity it can't fix the responsiveness of the
8945/9951's

On Wed, Sep 30, 2015 at 12:44 AM, Terry Oakley 
wrote:

> For those of you looking at UnifiedFX I will add my experience.   First it
> is limited experience as we have only been using the product for 6 months.
> So in saying that, the product is sound, is user friendly and so far has
> been a very good addition to our technology tool set.   I do not think any
> of you would question its value after you try it out.
>
>
>
> Terry
>
>
>
>
>
> *Terry Oakley*
>
> Telecommunications Coordinator *| *Information Technology Services
>
> *Red Deer College **|*100 College Blvd. *|* Box 5005 *| *Red Deer *|* Alberta
> *| *T4N 5H5
>
> work (403) 342-*3521   **| * FAX (403) 343-4034
>
>
>
>
>
>
>
> *From:* cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] *On Behalf
> Of *Stephen Welsh
> *Sent:* September 29, 2015 8:13 AM
> *To:* Heim, Dennis 
> *Cc:* cisco-voip@puck.nether.net; Unified FX Sales 
> *Subject:* Re: [cisco-voip] UnifiedFX Gurus
>
>
>
> Hi Dennis,
>
>
>
> What we mean by Phone Estate is the total number of phones within your
> environment across one or more clusters. Here is an example:
>
>
>
> Cluster 1 - 2000 Phones
>
> Cluster 2 - 1000 Phones
>
> Cluster 3 - 3000 Phones
>
>
>
> In order to license all phones across all 3 clusters you would need a
> ‘Phone Estate’ license of 6000 phones, effectively it’s a count of your
> total physical IP Phones.
>
>
>
> Note: If you are upgrading from one cluster to another, we allow the
> addition of the old and new cluster as part of the same Phone Estate count
> so you can have the old and new cluster at the same time during any
> upgrade/migration without double counting the phones that are moving.
>
>
>
> Note we do have other license types we don’t publish on our website, happy
> to discuss off-line if you like.
>
>
>
> Kind Regards.
>
>
>
> Stephen Welsh
>
> CTO
>
> UnifiedFX
>
>
>
> On 29 Sep 2015, at 14:56, Heim, Dennis  wrote:
>
>
>
> Reading the licensing model for unifiedfx and it says “Phone Estate”… what
> is that?
>
>
>
> *Dennis Heim | Emerging Technology Architect (Collaboration)*
>
> World Wide Technology, Inc. | +1 314-212-1814
>
>  
>
>  <+13142121814>
>
> “There is a fine line between Wrong and Visionary. Unfortunately, you have
> to be a visionary to see it." – Sheldon Cooper
>
> “The greatest danger for most of us is not that our aim is too high and we
> miss it, but that it is too low and we reach it.” -- Michelangelo Buonarroti
>
> “We should tansform the way we work” -- RowanTrollope
>
>
>
> *Click here to join me in my Collaboration Meeting Room
> *
>
>
>
> ___
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
>
> ___
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>


-- 
- Nick
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] UnifiedFX Gurus

[Nick Britt]

to clarify the product works fine with 9971's and 8945's the phones are
just slow to respond. like in real life.

On Tue, Oct 6, 2015 at 7:32 AM, Nick Britt  wrote:

> Seconded brilliant product. Pity it can't fix the responsiveness of the
> 8945/9951's
>
> On Wed, Sep 30, 2015 at 12:44 AM, Terry Oakley 
> wrote:
>
>> For those of you looking at UnifiedFX I will add my experience.   First
>> it is limited experience as we have only been using the product for 6
>> months.  So in saying that, the product is sound, is user friendly and so
>> far has been a very good addition to our technology tool set.   I do not
>> think any of you would question its value after you try it out.
>>
>>
>>
>> Terry
>>
>>
>>
>>
>>
>> *Terry Oakley*
>>
>> Telecommunications Coordinator *| *Information Technology Services
>>
>> *Red Deer College **|*100 College Blvd. *|* Box 5005 *| *Red Deer *|* Alberta
>> *| *T4N 5H5
>>
>> work (403) 342-*3521   **| * FAX (403) 343-4034
>>
>>
>>
>>
>>
>>
>>
>> *From:* cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] *On
>> Behalf Of *Stephen Welsh
>> *Sent:* September 29, 2015 8:13 AM
>> *To:* Heim, Dennis 
>> *Cc:* cisco-voip@puck.nether.net; Unified FX Sales 
>> *Subject:* Re: [cisco-voip] UnifiedFX Gurus
>>
>>
>>
>> Hi Dennis,
>>
>>
>>
>> What we mean by Phone Estate is the total number of phones within your
>> environment across one or more clusters. Here is an example:
>>
>>
>>
>> Cluster 1 - 2000 Phones
>>
>> Cluster 2 - 1000 Phones
>>
>> Cluster 3 - 3000 Phones
>>
>>
>>
>> In order to license all phones across all 3 clusters you would need a
>> ‘Phone Estate’ license of 6000 phones, effectively it’s a count of your
>> total physical IP Phones.
>>
>>
>>
>> Note: If you are upgrading from one cluster to another, we allow the
>> addition of the old and new cluster as part of the same Phone Estate count
>> so you can have the old and new cluster at the same time during any
>> upgrade/migration without double counting the phones that are moving.
>>
>>
>>
>> Note we do have other license types we don’t publish on our website,
>> happy to discuss off-line if you like.
>>
>>
>>
>> Kind Regards.
>>
>>
>>
>> Stephen Welsh
>>
>> CTO
>>
>> UnifiedFX
>>
>>
>>
>> On 29 Sep 2015, at 14:56, Heim, Dennis  wrote:
>>
>>
>>
>> Reading the licensing model for unifiedfx and it says “Phone Estate”…
>> what is that?
>>
>>
>>
>> *Dennis Heim | Emerging Technology Architect (Collaboration)*
>>
>> World Wide Technology, Inc. | +1 314-212-1814
>>
>>  
>>
>>  <+13142121814>
>>
>> “There is a fine line between Wrong and Visionary. Unfortunately, you
>> have to be a visionary to see it." – Sheldon Cooper
>>
>> “The greatest danger for most of us is not that our aim is too high and
>> we miss it, but that it is too low and we reach it.” -- Michelangelo
>> Buonarroti
>>
>> “We should tansform the way we work” -- RowanTrollope
>>
>>
>>
>> *Click here to join me in my Collaboration Meeting Room
>> *
>>
>>
>>
>> ___
>> cisco-voip mailing list
>> cisco-voip@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
>>
>> ___
>> cisco-voip mailing list
>> cisco-voip@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
>
>
> --
> - Nick
>



-- 
- Nick
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

[cisco-voip] Odd call behavior CME,CUBE,CUCM

[Ryan Huff]

I have CME that has a SIP phone registered to it and a SCCP phone registered to 
it.
SIP=4002
SCCP=4001
 
I have a call path that looks like:
 
CUCM->SIPTrunk->CUBE->SIPTrunk->CME
 
When I dial the SIP phone (on CME) from call manager the call completes and 
goes fine. When I dial the skinny phone (on CME) from call manager the call 
immediately fails. However, from CME, using the skinny phone, I can dial 
anything in call manager and the call completes.
 
CCSIP on CME (for one of the failed calls) shows the INVITE then TRYING then 
SIP/2.0 500 Internal Server Error. CCAPI INOUT shows a cause code of 16, but 
this was anything but a normal clearing. Just for the hell of it, I also added 
a transcoder in CME and registered it in telephony-service, just to see if 
there was a codec flying around that I wasn't seeing  but alas, no.
 
I've attached the ccsip and ccapi inout; I think I have just been starring at 
it too long ... I can't see it.

Thanks,

Ryan
 
  Syslog logging: enabled (0 messages dropped, 8 messages rate-limited, 0 
flushes, 0 overruns, xml disabled, filtering disabled)

No Active Message Discriminator.



No Inactive Message Discriminator.


Console logging: disabled
Monitor logging: level debugging, 0 messages logged, xml disabled,
 filtering disabled
Buffer logging:  level debugging, 298 messages logged, xml disabled,
filtering disabled
Exception Logging: size (4096 bytes)
Count and timestamp logging messages: disabled
Persistent logging: disabled

No active filter modules.

Trap logging: level informational, 106 message lines logged
Logging Source-Interface:   VRF Name:

Log Buffer (1000 bytes):

Oct  6 02:30:47.397: //-1//SIP/Msg/ccsipDisplayMsg:
Received:
INVITE sip:4001@142.102.66.254:5060 SIP/2.0
Via: SIP/2.0/UDP 142.102.65.254:5060;branch=z9hG4bKBDD75
Remote-Party-ID: "Site B Phone 1" 
;party=calling;screen=yes;privacy=off
From: "Site B Phone 1" ;tag=15CC463C-15AE
To: 
Date: Tue, 06 Oct 2015 02:30:47 GMT
Call-ID: 164EFFA5-6B0911E5-84D6F2F4-6AC111CC@142.102.65.254
Supported: timer,resource-priority,replaces,sdp-anat
Min-SE:  1800
Cisco-Guid: 1057581824-065536-19-0188834958
User-Agent: Cisco-SIPGateway/IOS-12.x
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, 
NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Timestamp: 1444098647
Contact: 
Expires: 180
Allow-Events: kpml, telephone-event
Max-Forwards: 69
Session-Expires:  1800
Content-Length: 0


Oct  6 02:30:47.413: //11/3F096B00/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 142.102.65.254:5060;branch=z9hG4bKBDD75
From: "Site B Phone 1" ;tag=15CC463C-15AE
To: 
Date: Tue, 06 Oct 2015 02:30:47 GMT
Call-ID: 164EFFA5-6B0911E5-84D6F2F4-6AC111CC@142.102.65.254
Timestamp: 1444098647
CSeq: 101 INVITE

Allow-Events: kpml, telephone-event
Server: Cisco-SIPGateway/IOS-12.x
Content-Length: 0


Oct  6 02:30:47.413: //11/3F096B00/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 500 Internal Server Error
Via: SIP/2.0/UDP 142.102.65.254:5060;branch=z9hG4bKBDD75
From: "Site B Phone 1" ;tag=15CC463C-15AE
To: ;tag=11609C-F9E
Call-ID: 164EFFA5-6B0911E5-84D6F2F4-6AC111CC@142.102.65.254
CSeq: 101 INVITE
Timestamp: 1444098647
Content-Length: 0


Oct  6 02:30:47.441: //-1//SIP/Msg/ccsipDisplayMsg:
Received:
ACK sip:4001@142.102.66.254:5060 SIP/2.0
Via: SIP/2.0/UDP 142.102.65.254:5060;branch=z9hG4bKBDD75
From: "Site B Phone 1" ;tag=15CC463C-15AE
To: ;tag=11609C-F9E
Date: Tue, 06 Oct 2015 02:30:47 GMT
Call-ID: 164EFFA5-6B0911E5-84D6F2F4-6AC111CC@142.102.65.254
Max-Forwards: 70
CSeq: 101 ACK
Allow-Events: kpml, telephone-event
Content-Length: 0
Syslog logging: enabled (0 messages dropped, 8 messages rate-limited, 0 
flushes, 0 overruns, xml disabled, filtering disabled)

No Active Message Discriminator.



No Inactive Message Discriminator.


Console logging: disabled
Monitor logging: level debugging, 0 messages logged, xml disabled,
 filtering disabled
Buffer logging:  level debugging, 421 messages logged, xml disabled,
filtering disabled
Exception Logging: size (4096 bytes)
Count and timestamp logging messages: disabled
Persistent logging: disabled

No active filter modules.

Trap logging: level informational, 106 message lines logged
Logging Source-Interface:   VRF Name:

Log Buffer (1000 bytes):

Oct  6 02:32:24.988: //-1/78DA7180/CCAPI/cc_api_display_ie_subfields:
   cc_api_call_setup_ind_common:
   cisco-username=3001
   - ccCallInfo IE subfields -
   cisco-ani=3001
   cisco-anitype=0
   cisco-aniplan=0
   

Re: [cisco-voip] Odd call behavior CME,CUBE,CUCM

[Brian Meade]

Make sure you don't have any of these on the dial-peer:
voice-class sip pass-thru headers unsupp
voice-class sip pass-thru content unsupp
voice-class sip pass-thru content sdp

http://www.dslreports.com/forum/r27144625-Config-CME-8-Help-with-Incoming-calls-on-SIP

On Mon, Oct 5, 2015 at 11:00 PM, Ryan Huff  wrote:

> I have CME that has a SIP phone registered to it and a SCCP phone
> registered to it.
> SIP=4002
> SCCP=4001
>
> I have a call path that looks like:
>
> CUCM->SIPTrunk->CUBE->SIPTrunk->CME
>
> When I dial the SIP phone (on CME) from call manager the call completes
> and goes fine. When I dial the skinny phone (on CME) from call manager the
> call immediately fails. However, from CME, using the skinny phone, I can
> dial anything in call manager and the call completes.
>
> CCSIP on CME (for one of the failed calls) shows the INVITE then TRYING
> then SIP/2.0 500 Internal Server Error. CCAPI INOUT shows a cause code of
> 16, but this was anything but a normal clearing. Just for the hell of it, I
> also added a transcoder in CME and registered it in telephony-service, just
> to see if there was a codec flying around that I wasn't seeing  but
> alas, no.
>
> I've attached the ccsip and ccapi inout; I think I have just been starring
> at it too long ... I can't see it.
>
> Thanks,
>
> Ryan
>
>
> ___
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] Odd call behavior CME,CUBE,CUCM

[Ryan Huff]

HA! Thanks Brian ... orphaned passthru  this was the 28th (seriously) time 
I reviewed the config ... finally spotted it.

Is this because CUBE is presenting DTMF as part of the INVITE?

Thanks,

Ryan

Date: Mon, 5 Oct 2015 23:14:07 -0400
Subject: Re: [cisco-voip] Odd call behavior CME,CUBE,CUCM
From: bmead...@vt.edu
To: ryanh...@outlook.com
CC: cisco-voip@puck.nether.net

Make sure you don't have any of these on the dial-peer:voice-class sip 
pass-thru headers unsuppvoice-class sip pass-thru content unsuppvoice-class sip 
pass-thru content sdp

http://www.dslreports.com/forum/r27144625-Config-CME-8-Help-with-Incoming-calls-on-SIP

On Mon, Oct 5, 2015 at 11:00 PM, Ryan Huff  wrote:



I have CME that has a SIP phone registered to it and a SCCP phone registered to 
it.
SIP=4002
SCCP=4001
 
I have a call path that looks like:
 
CUCM->SIPTrunk->CUBE->SIPTrunk->CME
 
When I dial the SIP phone (on CME) from call manager the call completes and 
goes fine. When I dial the skinny phone (on CME) from call manager the call 
immediately fails. However, from CME, using the skinny phone, I can dial 
anything in call manager and the call completes.
 
CCSIP on CME (for one of the failed calls) shows the INVITE then TRYING then 
SIP/2.0 500 Internal Server Error. CCAPI INOUT shows a cause code of 16, but 
this was anything but a normal clearing. Just for the hell of it, I also added 
a transcoder in CME and registered it in telephony-service, just to see if 
there was a codec flying around that I wasn't seeing  but alas, no.
 
I've attached the ccsip and ccapi inout; I think I have just been starring at 
it too long ... I can't see it.

Thanks,

Ryan
 
  

___

cisco-voip mailing list

cisco-voip@puck.nether.net

https://puck.nether.net/mailman/listinfo/cisco-voip



  ___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] Understanding a Defect's Affected Versions

[Erick Bergquist]

Some bugs, like CSCuu58142 effecting single number reach doesn't seem
to follow higher versions contain the fix methodology.

Bug toolkit says this is fixed in 10.5.2.12028-1 but 10.5.2 SU2, SU2a
(10.5.2.12900 and 10.5.2.12901) don't contain the bug fix per TAC and
going over the release notes for SU2, SU2a.

I need to use the 10.5.2.12028-1 ES or latest ES 10.5.2.13039-1.
Currently debating which route I'm going to go or wait out for SU3 or
until we upgrade to 11.x.  This SNR bug is effecting some users about
every 1-2 months.  Workaround is to disable SNR on their remote
destination profile and re-enable it.



On Tue, Sep 29, 2015 at 2:03 PM, Ryan Ratliff (rratliff)
 wrote:
> it's up to the discretion of the bug author.  <--
>
>
> This means it’s accuracy varies greatly by product and even bug author.  For
> UCM you should always assume you are vulnerable if the fixed-in version is
> higher than what you are currently running unless the bug description
> clearly states otherwise or the feature impacted by the bug doesn’t exist in
> your version.
>
> -Ryan
>
> On Sep 29, 2015, at 2:25 PM, Anthony Holloway
>  wrote:
>
> In reference to this defect:
>
> https://tools.cisco.com/bugsearch/bug/CSCuv45722
>
> Can you help me understand what this means as far as all affected versions?
>
> On the surface, it would appear that it's only affecting 9.1(2).  However,
> with a fixed in version being way out in 11.5, that would also indicate to
> me that an upgrade to 10.5(2)SU2a, as an example, would not fix this issue.
>
> Does Cisco imply all versions affected between the listed affected versions
> and the fixed in version?  Or, should this defect list all affected
> versions?
>
> I cannot recall what I've heard about this in the past.  I'm almost guessing
> there's no exact science to it, and it's up to the discretion of the bug
> author.
>
> Thanks for your help.
> ___
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
> ___
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] Odd call behavior CME,CUBE,CUCM

[Brian Meade]

I think it might just be having the SDP passthrough on at all on a SIP to
non-SIP call will do this. You could try some of the more intensive CCSIP
debugs to see if there's a certain line it has a problem with but I think
it's just the fact that it knows there will be SDP at one point and it
won't be able to pass it through to the other leg due to non-SIP.

On Mon, Oct 5, 2015 at 11:31 PM, Ryan Huff  wrote:

> HA! Thanks Brian ... orphaned passthru  this was the 28th (seriously)
> time I reviewed the config ... finally spotted it.
>
> Is this because CUBE is presenting DTMF as part of the INVITE?
>
> Thanks,
>
> Ryan
>
> --
> Date: Mon, 5 Oct 2015 23:14:07 -0400
> Subject: Re: [cisco-voip] Odd call behavior CME,CUBE,CUCM
> From: bmead...@vt.edu
> To: ryanh...@outlook.com
> CC: cisco-voip@puck.nether.net
>
>
> Make sure you don't have any of these on the dial-peer:
> voice-class sip pass-thru headers unsupp
> voice-class sip pass-thru content unsupp
> voice-class sip pass-thru content sdp
>
>
> http://www.dslreports.com/forum/r27144625-Config-CME-8-Help-with-Incoming-calls-on-SIP
>
> On Mon, Oct 5, 2015 at 11:00 PM, Ryan Huff  wrote:
>
> I have CME that has a SIP phone registered to it and a SCCP phone
> registered to it.
> SIP=4002
> SCCP=4001
>
> I have a call path that looks like:
>
> CUCM->SIPTrunk->CUBE->SIPTrunk->CME
>
> When I dial the SIP phone (on CME) from call manager the call completes
> and goes fine. When I dial the skinny phone (on CME) from call manager the
> call immediately fails. However, from CME, using the skinny phone, I can
> dial anything in call manager and the call completes.
>
> CCSIP on CME (for one of the failed calls) shows the INVITE then TRYING
> then SIP/2.0 500 Internal Server Error. CCAPI INOUT shows a cause code of
> 16, but this was anything but a normal clearing. Just for the hell of it, I
> also added a transcoder in CME and registered it in telephony-service, just
> to see if there was a codec flying around that I wasn't seeing  but
> alas, no.
>
> I've attached the ccsip and ccapi inout; I think I have just been starring
> at it too long ... I can't see it.
>
> Thanks,
>
> Ryan
>
>
> ___
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
>
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] Understanding a Defect's Affected Versions

[Brian Meade]

10.5.2.12028-1 is an Engineering Special which uses a different numbering
scheme.  I thought the ReadMe used to show what ES the SU was built off of
but having trouble finding it.

SU2/SU2a were most likely built off of older engineering specials than
10.5.2.12028-1.

The higher release thing really only works in the case of published
versions on cisco.com.

On Mon, Oct 5, 2015 at 11:34 PM, Erick Bergquist  wrote:

> Some bugs, like CSCuu58142 effecting single number reach doesn't seem
> to follow higher versions contain the fix methodology.
>
> Bug toolkit says this is fixed in 10.5.2.12028-1 but 10.5.2 SU2, SU2a
> (10.5.2.12900 and 10.5.2.12901) don't contain the bug fix per TAC and
> going over the release notes for SU2, SU2a.
>
> I need to use the 10.5.2.12028-1 ES or latest ES 10.5.2.13039-1.
> Currently debating which route I'm going to go or wait out for SU3 or
> until we upgrade to 11.x.  This SNR bug is effecting some users about
> every 1-2 months.  Workaround is to disable SNR on their remote
> destination profile and re-enable it.
>
>
>
> On Tue, Sep 29, 2015 at 2:03 PM, Ryan Ratliff (rratliff)
>  wrote:
> > it's up to the discretion of the bug author.  <--
> >
> >
> > This means it’s accuracy varies greatly by product and even bug author.
> For
> > UCM you should always assume you are vulnerable if the fixed-in version
> is
> > higher than what you are currently running unless the bug description
> > clearly states otherwise or the feature impacted by the bug doesn’t
> exist in
> > your version.
> >
> > -Ryan
> >
> > On Sep 29, 2015, at 2:25 PM, Anthony Holloway
> >  wrote:
> >
> > In reference to this defect:
> >
> > https://tools.cisco.com/bugsearch/bug/CSCuv45722
> >
> > Can you help me understand what this means as far as all affected
> versions?
> >
> > On the surface, it would appear that it's only affecting 9.1(2).
> However,
> > with a fixed in version being way out in 11.5, that would also indicate
> to
> > me that an upgrade to 10.5(2)SU2a, as an example, would not fix this
> issue.
> >
> > Does Cisco imply all versions affected between the listed affected
> versions
> > and the fixed in version?  Or, should this defect list all affected
> > versions?
> >
> > I cannot recall what I've heard about this in the past.  I'm almost
> guessing
> > there's no exact science to it, and it's up to the discretion of the bug
> > author.
> >
> > Thanks for your help.
> > ___
> > cisco-voip mailing list
> > cisco-voip@puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-voip
> >
> >
> > ___
> > cisco-voip mailing list
> > cisco-voip@puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-voip
> >
> ___
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] Understanding a Defect's Affected Versions

[Erick Bergquist]

I'm also not a fan of the newer release notes not including a list of
the Resolved Bugs, but a link to bug search tool...

That leaves it up to us to find what bugs were fixed or hoping bug
search tool returns them all, plus not a nice list/summary to glance
through.

On Mon, Oct 5, 2015 at 10:47 PM, Brian Meade  wrote:
> 10.5.2.12028-1 is an Engineering Special which uses a different numbering
> scheme.  I thought the ReadMe used to show what ES the SU was built off of
> but having trouble finding it.
>
> SU2/SU2a were most likely built off of older engineering specials than
> 10.5.2.12028-1.
>
> The higher release thing really only works in the case of published versions
> on cisco.com.
>
> On Mon, Oct 5, 2015 at 11:34 PM, Erick Bergquist  wrote:
>>
>> Some bugs, like CSCuu58142 effecting single number reach doesn't seem
>> to follow higher versions contain the fix methodology.
>>
>> Bug toolkit says this is fixed in 10.5.2.12028-1 but 10.5.2 SU2, SU2a
>> (10.5.2.12900 and 10.5.2.12901) don't contain the bug fix per TAC and
>> going over the release notes for SU2, SU2a.
>>
>> I need to use the 10.5.2.12028-1 ES or latest ES 10.5.2.13039-1.
>> Currently debating which route I'm going to go or wait out for SU3 or
>> until we upgrade to 11.x.  This SNR bug is effecting some users about
>> every 1-2 months.  Workaround is to disable SNR on their remote
>> destination profile and re-enable it.
>>
>>
>>
>> On Tue, Sep 29, 2015 at 2:03 PM, Ryan Ratliff (rratliff)
>>  wrote:
>> > it's up to the discretion of the bug author.  <--
>> >
>> >
>> > This means it’s accuracy varies greatly by product and even bug author.
>> > For
>> > UCM you should always assume you are vulnerable if the fixed-in version
>> > is
>> > higher than what you are currently running unless the bug description
>> > clearly states otherwise or the feature impacted by the bug doesn’t
>> > exist in
>> > your version.
>> >
>> > -Ryan
>> >
>> > On Sep 29, 2015, at 2:25 PM, Anthony Holloway
>> >  wrote:
>> >
>> > In reference to this defect:
>> >
>> > https://tools.cisco.com/bugsearch/bug/CSCuv45722
>> >
>> > Can you help me understand what this means as far as all affected
>> > versions?
>> >
>> > On the surface, it would appear that it's only affecting 9.1(2).
>> > However,
>> > with a fixed in version being way out in 11.5, that would also indicate
>> > to
>> > me that an upgrade to 10.5(2)SU2a, as an example, would not fix this
>> > issue.
>> >
>> > Does Cisco imply all versions affected between the listed affected
>> > versions
>> > and the fixed in version?  Or, should this defect list all affected
>> > versions?
>> >
>> > I cannot recall what I've heard about this in the past.  I'm almost
>> > guessing
>> > there's no exact science to it, and it's up to the discretion of the bug
>> > author.
>> >
>> > Thanks for your help.
>> > ___
>> > cisco-voip mailing list
>> > cisco-voip@puck.nether.net
>> > https://puck.nether.net/mailman/listinfo/cisco-voip
>> >
>> >
>> > ___
>> > cisco-voip mailing list
>> > cisco-voip@puck.nether.net
>> > https://puck.nether.net/mailman/listinfo/cisco-voip
>> >
>> ___
>> cisco-voip mailing list
>> cisco-voip@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] ldaps authentication

[Ryan Huff]

Ed,

You may need to make sure that the common name of the ldap server also appears 
in the subject alternative name (SAN) of the certificate.

ldap dirsync will come from the cucm publisher node but ldap auth could 
potentially come from any cucm node.

My other thoughts besides a cert issue would be (since you reference an error 
about hostname mismatches) is; are there any stray/orphaned a records in dns, 
forward and reverse zones setup correctly, ALL cucm nodes are using dns servers 
that resolve the same forward and reverse zones. Also verify that every cucm 
node can talk to the directory server (in the case that nodes are in different 
network segments).

If you still have the CSR from the ldap server, take it to a CSR decoder 
(Google shows plenty) and I woul be interested to know if the cn is/is not in 
the san (or decode the ident cert on the server).

Thanks,

Ryan

Sent from my iPad

> On Oct 5, 2015, at 8:22 AM, Ed Leatherman  wrote:
> 
> Hello!
> 
> We turned up directory sync on cucm yesterday, and ran into some issues with 
> authentication; I ran out of maintenance window so we ended up converting the 
> small number of end users that were synced back into local accounts for now.
> 
> Our LDAP is front-ended by a load balancer that uses a wild-card certificate. 
> Yeah, I should have seen this coming.
> 
> What I have is my test cluster, running 10.5.2.1-5, integrated using 
> ldaps and working fine
> 
> My production system is slightly more recent 10.5.2.12901 (unrelated reason 
> as to why they don't match). Directory sync works fine using ldaps , but 
> authentication will not work, error message in the tomcat trace says that the 
> hostname doesn't match the certificate. I can see the wildcard cert CN's in 
> the trace.
> 
> I can't even see any entries in the test system trace file related the SSL 
> socket (nor could Tac), so i'm assuming that extra trace info was added in 
> the SU. I guess it also started enforcing the no wild-card rule on 
> certificates for other things - I was under the (apparently false) impression 
> that that rule was only related to signing CUCM certs. 
> 
> But why does my dir sync work ok, it uses SSL also to the same host? Tac 
> isn't interested in troubleshooting any further as they say it's unsupported. 
> 
> We tried changing LDAP on CUCM to use IP instead of hostname to skip the SSL 
> hostname check, this worked for authenticating Ucmuser webpage but it did not 
> work for Jabber. I wanted to troubleshoot this to see if this issue was not 
> SSL related but we ran out of maintenance window.
> 
> My action plan right now is to move my "beta" users off the test system and 
> get it to the same version as production, and try to reproduce the issue. 
> Also investigating getting a normal cert for our ldap but I'm not sure how 
> feasible this will be.
> 
> Any suggestions or am I SOL with that wildcard cert?
> 
> 
> -- 
> Ed Leatherman
> ___
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] ldaps authentication

[Ed Leatherman]

Thanks Ryan those are good suggestions.

CN is not in the cert, that much I can see from the trace files:
impl.Certificates - getCNs :
impl.LDAPHostnameVerifier - check : cns = [*.wvu.edu]
impl.Certificates - getDNSSubjectAlts :
impl.LDAPHostnameVerifier - check : subjectAlts = [*.wvu.edu, wvu.edu]

We're reaching out to the F5 and ldap teams here to see what impact is on
making some changes to get rid of the wildcard - apparently they have
related issues with other apps around this so I might get more traction on
it than I expected.

Double checking dns on the other cm nodes is good idea - i'm pretty sure
they are all using the DNS but close only counts in horseshoes and hand
grenades as they say. I forgot that the secondary nodes were able to do
auth on their own.


On Mon, Oct 5, 2015 at 8:41 AM, Ryan Huff  wrote:

> Ed,
>
> You may need to make sure that the common name of the ldap server also
> appears in the subject alternative name (SAN) of the certificate.
>
> ldap dirsync will come from the cucm publisher node but ldap auth could
> potentially come from any cucm node.
>
> My other thoughts besides a cert issue would be (since you reference an
> error about hostname mismatches) is; are there any stray/orphaned a records
> in dns, forward and reverse zones setup correctly, ALL cucm nodes are using
> dns servers that resolve the same forward and reverse zones. Also verify
> that every cucm node can talk to the directory server (in the case that
> nodes are in different network segments).
>
> If you still have the CSR from the ldap server, take it to a CSR decoder
> (Google shows plenty) and I woul be interested to know if the cn is/is not
> in the san (or decode the ident cert on the server).
>
> Thanks,
>
> Ryan
>
> Sent from my iPad
>
> > On Oct 5, 2015, at 8:22 AM, Ed Leatherman 
> wrote:
> >
> > Hello!
> >
> > We turned up directory sync on cucm yesterday, and ran into some issues
> with authentication; I ran out of maintenance window so we ended up
> converting the small number of end users that were synced back into local
> accounts for now.
> >
> > Our LDAP is front-ended by a load balancer that uses a wild-card
> certificate. Yeah, I should have seen this coming.
> >
> > What I have is my test cluster, running 10.5.2.1-5, integrated using
> ldaps and working fine
> >
> > My production system is slightly more recent 10.5.2.12901 (unrelated
> reason as to why they don't match). Directory sync works fine using ldaps ,
> but authentication will not work, error message in the tomcat trace says
> that the hostname doesn't match the certificate. I can see the wildcard
> cert CN's in the trace.
> >
> > I can't even see any entries in the test system trace file related the
> SSL socket (nor could Tac), so i'm assuming that extra trace info was added
> in the SU. I guess it also started enforcing the no wild-card rule on
> certificates for other things - I was under the (apparently false)
> impression that that rule was only related to signing CUCM certs.
> >
> > But why does my dir sync work ok, it uses SSL also to the same host? Tac
> isn't interested in troubleshooting any further as they say it's
> unsupported.
> >
> > We tried changing LDAP on CUCM to use IP instead of hostname to skip the
> SSL hostname check, this worked for authenticating Ucmuser webpage but it
> did not work for Jabber. I wanted to troubleshoot this to see if this issue
> was not SSL related but we ran out of maintenance window.
> >
> > My action plan right now is to move my "beta" users off the test system
> and get it to the same version as production, and try to reproduce the
> issue. Also investigating getting a normal cert for our ldap but I'm not
> sure how feasible this will be.
> >
> > Any suggestions or am I SOL with that wildcard cert?
> >
> >
> > --
> > Ed Leatherman
> > ___
> > cisco-voip mailing list
> > cisco-voip@puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-voip
>



-- 
Ed Leatherman
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] ldaps authentication

[Ryan Huff]

When it comes to ssl integrations with CCM, I tend to subscribe to the idea 
that the "integrators" should play by the same safety rules that I use for CCM; 
CN in the SAN, no UPPER case letters or non alphanumeric characters ... etc
 
However, I'd be cautious to call that the smoking gun because you do have A 
node successfully negotiating with the LDAP server; my first peek would be at 
communications between all cucm nodes and the directory server. 
 
The ldap auth is using the tomcat service; I have seen a simple tomcat service 
bounce on all the ccm nodes do the trick. Especially if the cert on the 
directory server has recently changed; would be the equivalent of a "ipconfig 
/flushdns" in the windows world, although a bit more impactful ;).
 
Thanks,
 
-R
Date: Mon, 5 Oct 2015 09:03:08 -0400
Subject: Re: [cisco-voip] ldaps authentication
From: ealeather...@gmail.com
To: ryanh...@outlook.com
CC: cisco-voip@puck.nether.net

Thanks Ryan those are good suggestions.
CN is not in the cert, that much I can see from the trace 
files:impl.Certificates - getCNs : impl.LDAPHostnameVerifier - check : cns = 
[*.wvu.edu]impl.Certificates - getDNSSubjectAlts : impl.LDAPHostnameVerifier - 
check : subjectAlts = [*.wvu.edu, wvu.edu]
We're reaching out to the F5 and ldap teams here to see what impact is on 
making some changes to get rid of the wildcard - apparently they have related 
issues with other apps around this so I might get more traction on it than I 
expected.
Double checking dns on the other cm nodes is good idea - i'm pretty sure they 
are all using the DNS but close only counts in horseshoes and hand grenades as 
they say. I forgot that the secondary nodes were able to do auth on their own.

On Mon, Oct 5, 2015 at 8:41 AM, Ryan Huff  wrote:
Ed,



You may need to make sure that the common name of the ldap server also appears 
in the subject alternative name (SAN) of the certificate.



ldap dirsync will come from the cucm publisher node but ldap auth could 
potentially come from any cucm node.



My other thoughts besides a cert issue would be (since you reference an error 
about hostname mismatches) is; are there any stray/orphaned a records in dns, 
forward and reverse zones setup correctly, ALL cucm nodes are using dns servers 
that resolve the same forward and reverse zones. Also verify that every cucm 
node can talk to the directory server (in the case that nodes are in different 
network segments).



If you still have the CSR from the ldap server, take it to a CSR decoder 
(Google shows plenty) and I woul be interested to know if the cn is/is not in 
the san (or decode the ident cert on the server).



Thanks,



Ryan



Sent from my iPad



> On Oct 5, 2015, at 8:22 AM, Ed Leatherman  wrote:

>

> Hello!

>

> We turned up directory sync on cucm yesterday, and ran into some issues with 
> authentication; I ran out of maintenance window so we ended up converting the 
> small number of end users that were synced back into local accounts for now.

>

> Our LDAP is front-ended by a load balancer that uses a wild-card certificate. 
> Yeah, I should have seen this coming.

>

> What I have is my test cluster, running 10.5.2.1-5, integrated using 
> ldaps and working fine

>

> My production system is slightly more recent 10.5.2.12901 (unrelated reason 
> as to why they don't match). Directory sync works fine using ldaps , but 
> authentication will not work, error message in the tomcat trace says that the 
> hostname doesn't match the certificate. I can see the wildcard cert CN's in 
> the trace.

>

> I can't even see any entries in the test system trace file related the SSL 
> socket (nor could Tac), so i'm assuming that extra trace info was added in 
> the SU. I guess it also started enforcing the no wild-card rule on 
> certificates for other things - I was under the (apparently false) impression 
> that that rule was only related to signing CUCM certs.

>

> But why does my dir sync work ok, it uses SSL also to the same host? Tac 
> isn't interested in troubleshooting any further as they say it's unsupported.

>

> We tried changing LDAP on CUCM to use IP instead of hostname to skip the SSL 
> hostname check, this worked for authenticating Ucmuser webpage but it did not 
> work for Jabber. I wanted to troubleshoot this to see if this issue was not 
> SSL related but we ran out of maintenance window.

>

> My action plan right now is to move my "beta" users off the test system and 
> get it to the same version as production, and try to reproduce the issue. 
> Also investigating getting a normal cert for our ldap but I'm not sure how 
> feasible this will be.

>

> Any suggestions or am I SOL with that wildcard cert?

>

>

> --

> Ed Leatherman

> ___

> cisco-voip mailing list

> cisco-voip@puck.nether.net

> https://puck.nether.net/mailman/listinfo/cisco-voip



-- 
Ed Leatherman

  

[cisco-voip] ldaps authentication

[Ed Leatherman]

Hello!

We turned up directory sync on cucm yesterday, and ran into some issues
with authentication; I ran out of maintenance window so we ended up
converting the small number of end users that were synced back into local
accounts for now.

Our LDAP is front-ended by a load balancer that uses a wild-card
certificate. Yeah, I should have seen this coming.

What I have is my test cluster, running 10.5.2.1-5, integrated using
ldaps and working fine

My production system is slightly more recent 10.5.2.12901 (unrelated reason
as to why they don't match). Directory sync works fine using ldaps , but
authentication will not work, error message in the tomcat trace says that
the hostname doesn't match the certificate. I can see the wildcard cert
CN's in the trace.

I can't even see any entries in the test system trace file related the SSL
socket (nor could Tac), so i'm assuming that extra trace info was added in
the SU. I guess it also started enforcing the no wild-card rule on
certificates for other things - I was under the (apparently false)
impression that that rule was only related to signing CUCM certs.

But why does my dir sync work ok, it uses SSL also to the same host? Tac
isn't interested in troubleshooting any further as they say it's
unsupported.

We tried changing LDAP on CUCM to use IP instead of hostname to skip the
SSL hostname check, this worked for authenticating Ucmuser webpage but it
did not work for Jabber. I wanted to troubleshoot this to see if this issue
was not SSL related but we ran out of maintenance window.

My action plan right now is to move my "beta" users off the test system and
get it to the same version as production, and try to reproduce the issue.
Also investigating getting a normal cert for our ldap but I'm not sure how
feasible this will be.

Any suggestions or am I SOL with that wildcard cert?


-- 
Ed Leatherman
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] ldaps authentication

[Walenta, Philip]

Going beyond putting the CN in the SAN, based on many experiences, wildcards 
(while technically legal in a csr  or signed cert) cause all kinds of havoc 
exactly like this.  If there's any way to remove the wildcard, I'd suggest 
doing that.

Sent from my iPhone

On Oct 5, 2015, at 9:18 AM, Ryan Huff 
> wrote:

When it comes to ssl integrations with CCM, I tend to subscribe to the idea 
that the "integrators" should play by the same safety rules that I use for CCM; 
CN in the SAN, no UPPER case letters or non alphanumeric characters ... etc

However, I'd be cautious to call that the smoking gun because you do have A 
node successfully negotiating with the LDAP server; my first peek would be at 
communications between all cucm nodes and the directory server.

The ldap auth is using the tomcat service; I have seen a simple tomcat service 
bounce on all the ccm nodes do the trick. Especially if the cert on the 
directory server has recently changed; would be the equivalent of a "ipconfig 
/flushdns" in the windows world, although a bit more impactful ;).

Thanks,

-R

Date: Mon, 5 Oct 2015 09:03:08 -0400
Subject: Re: [cisco-voip] ldaps authentication
From: ealeather...@gmail.com
To: ryanh...@outlook.com
CC: cisco-voip@puck.nether.net

Thanks Ryan those are good suggestions.

CN is not in the cert, that much I can see from the trace files:
impl.Certificates - getCNs :
impl.LDAPHostnameVerifier - check : cns = [*.wvu.edu]
impl.Certificates - getDNSSubjectAlts :
impl.LDAPHostnameVerifier - check : subjectAlts = [*.wvu.edu, 
wvu.edu]

We're reaching out to the F5 and ldap teams here to see what impact is on 
making some changes to get rid of the wildcard - apparently they have related 
issues with other apps around this so I might get more traction on it than I 
expected.

Double checking dns on the other cm nodes is good idea - i'm pretty sure they 
are all using the DNS but close only counts in horseshoes and hand grenades as 
they say. I forgot that the secondary nodes were able to do auth on their own.


On Mon, Oct 5, 2015 at 8:41 AM, Ryan Huff 
> wrote:
Ed,

You may need to make sure that the common name of the ldap server also appears 
in the subject alternative name (SAN) of the certificate.

ldap dirsync will come from the cucm publisher node but ldap auth could 
potentially come from any cucm node.

My other thoughts besides a cert issue would be (since you reference an error 
about hostname mismatches) is; are there any stray/orphaned a records in dns, 
forward and reverse zones setup correctly, ALL cucm nodes are using dns servers 
that resolve the same forward and reverse zones. Also verify that every cucm 
node can talk to the directory server (in the case that nodes are in different 
network segments).

If you still have the CSR from the ldap server, take it to a CSR decoder 
(Google shows plenty) and I woul be interested to know if the cn is/is not in 
the san (or decode the ident cert on the server).

Thanks,

Ryan

Sent from my iPad

> On Oct 5, 2015, at 8:22 AM, Ed Leatherman 
> > wrote:
>
> Hello!
>
> We turned up directory sync on cucm yesterday, and ran into some issues with 
> authentication; I ran out of maintenance window so we ended up converting the 
> small number of end users that were synced back into local accounts for now.
>
> Our LDAP is front-ended by a load balancer that uses a wild-card certificate. 
> Yeah, I should have seen this coming.
>
> What I have is my test cluster, running 10.5.2.1-5, integrated using 
> ldaps and working fine
>
> My production system is slightly more recent 10.5.2.12901 (unrelated reason 
> as to why they don't match). Directory sync works fine using ldaps , but 
> authentication will not work, error message in the tomcat trace says that the 
> hostname doesn't match the certificate. I can see the wildcard cert CN's in 
> the trace.
>
> I can't even see any entries in the test system trace file related the SSL 
> socket (nor could Tac), so i'm assuming that extra trace info was added in 
> the SU. I guess it also started enforcing the no wild-card rule on 
> certificates for other things - I was under the (apparently false) impression 
> that that rule was only related to signing CUCM certs.
>
> But why does my dir sync work ok, it uses SSL also to the same host? Tac 
> isn't interested in troubleshooting any further as they say it's unsupported.
>
> We tried changing LDAP on CUCM to use IP instead of hostname to skip the SSL 
> hostname check, this worked for authenticating Ucmuser webpage but it did not 
> work for Jabber. I wanted to troubleshoot this to see if this issue was not 
> SSL related but we ran out of 

Re: [cisco-voip] Phantom tomcat-trust cert

[Brian Meade]

Maybe this? https://tools.cisco.com/bugsearch/bug/CSCun33173

Try manually stopping the Cisco Intercluster Sync Agent Service and
deleting the certificate.

On Sun, Oct 4, 2015 at 10:45 PM, James Andrewartha <
jandrewar...@ccgs.wa.edu.au> wrote:

> On 02/10/15 02:57, Brian Meade wrote:
> > You can try to download the tomcat.pem from the publisher and manually
> > install it on the presence server as a tomcat-trust.  Since the Common
> > Name is the same, it should replace the existing tomcat-trust.
>
> It did replace the existing tomcat-trust, however it still got
> overwritten from the publisher by the cert expiring in 2015. I even
> tried downloading/uploading the cert as .der instead of .pem as that's
> what the expiry email says, but no go.
>
> --
> James Andrewartha
> Network & Projects Engineer
> Christ Church Grammar School
> Claremont, Western Australia
> Ph. (08) 9442 1757
> Mob. 0424 160 877
>
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip