Re: [cisco-voip] Old phone models dropped from CUCM 11.5

[NateCCIE]

Yeah, you wonder why it took so long.  I will stop doing Cisco Communications 
Manager when they stop supporting my favorite phone, the 7911.

 

I do wonder what happens to Syn-Apps’ SA-Announce software.  They use VIP30 
virtual phones, which I don’t like anyways because it takes a UCL ENH license 
for each of them.

 

Thanks,

-Nate VanMaren, CCIE #7911

 

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of Lelio 
Fulgenzi
Sent: Thursday, June 09, 2016 6:08 PM
To: Cisco VoIP Group 
Subject: Re: [cisco-voip] Old phone models dropped from CUCM 11.5

 

Whoa. I think this is the first time they've actually said they'll stop 
working. 

Sent from my iPhone


On Jun 9, 2016, at 6:55 PM, Stephen Welsh  > wrote:

Wow, formally dropping phone support from CUCM in 11.5, I assume this means the 
models listed will not register...

 

http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/rel_notes/11_5_1/cucm_b_release-notes-cucm-imp-1151/cucm_b_release-notes-cucm-imp-1151_chapter_01.html

 

Also,

Very grateful for the MigrationFX ‘plug’ in the CUCM release notes ;)

 

FYI: MigrationFX now includes the ability to provision new phones too (similar 
to TAPS but no IVR/UCCX, a simple XML service instead), BAT import the phone 
details with dummy MAC addresses, use the Migration XML phone service on the 
newly plugged in handset (i.e. auto registered with Idle URL via Universal 
Device Template). Using the XML service search for the users extension then 
MigrationFX will rename the matching BAT device to the MAC address of the new 
phone. It will even migrate if the model of the new phone does not match the 
BAT import, so more flexibility on deploy handsets than TAPS.

 

We also have some new MigrationFX functionality due for release at Cisco Live, 
we shall publish the details in due course, but if you are curious drop me a 
line or come and say hello.

 

Kind Regards

 

Stephen Welsh
CTO
UnifiedFX

 

Come along and meet the UnifiedFX team

World of Solutions stand T2

 

 

___
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] Old phone models dropped from CUCM 11.5

[Lelio Fulgenzi]

Whoa. I think this is the first time they've actually said they'll stop 
working. 

Sent from my iPhone

> On Jun 9, 2016, at 6:55 PM, Stephen Welsh  wrote:
> 
> Wow, formally dropping phone support from CUCM in 11.5, I assume this means 
> the models listed will not register...
> 
> http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/rel_notes/11_5_1/cucm_b_release-notes-cucm-imp-1151/cucm_b_release-notes-cucm-imp-1151_chapter_01.html
> 
> Also,
> Very grateful for the MigrationFX ‘plug’ in the CUCM release notes ;)
> 
> FYI: MigrationFX now includes the ability to provision new phones too 
> (similar to TAPS but no IVR/UCCX, a simple XML service instead), BAT import 
> the phone details with dummy MAC addresses, use the Migration XML phone 
> service on the newly plugged in handset (i.e. auto registered with Idle URL 
> via Universal Device Template). Using the XML service search for the users 
> extension then MigrationFX will rename the matching BAT device to the MAC 
> address of the new phone. It will even migrate if the model of the new phone 
> does not match the BAT import, so more flexibility on deploy handsets than 
> TAPS.
> 
> We also have some new MigrationFX functionality due for release at Cisco 
> Live, we shall publish the details in due course, but if you are curious drop 
> me a line or come and say hello.
> 
> Kind Regards
> 
> Stephen Welsh
> CTO
> UnifiedFX
> 
> Come along and meet the UnifiedFX team
> World of Solutions stand T2
> 
> 
> ___
> 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] Old phone models dropped from CUCM 11.5

[Stephen Welsh]

Wow, formally dropping phone support from CUCM in 11.5, I assume this means the 
models listed will not register...

http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/rel_notes/11_5_1/cucm_b_release-notes-cucm-imp-1151/cucm_b_release-notes-cucm-imp-1151_chapter_01.html

Also,
Very grateful for the MigrationFX ‘plug’ in the CUCM release notes ;)

FYI: MigrationFX now includes the ability to provision new phones too (similar 
to TAPS but no IVR/UCCX, a simple XML service instead), BAT import the phone 
details with dummy MAC addresses, use the Migration XML phone service on the 
newly plugged in handset (i.e. auto registered with Idle URL via Universal 
Device Template). Using the XML service search for the users extension then 
MigrationFX will rename the matching BAT device to the MAC address of the new 
phone. It will even migrate if the model of the new phone does not match the 
BAT import, so more flexibility on deploy handsets than TAPS.

We also have some new MigrationFX functionality due for release at Cisco Live, 
we shall publish the details in due course, but if you are curious drop me a 
line or come and say hello.

Kind Regards

Stephen Welsh
CTO
UnifiedFX

Come along and meet the UnifiedFX team
World of Solutions stand T2


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

Re: [cisco-voip] certificates and SANs - what's really needed in there?

[Lelio Fulgenzi]

Just to follow up, we did add our top domain to the SAN, since we own it. Why 
not. 

>From reading the notes below, we _don't_ need the "collab-edge.domain.xxx" 
>included. 

We'll see how that goes. 

Worse part is, right now, we don't have any signed certificates for our collab 
servers, unity or im, so we'll still get warnings. 

We'll see how it goes. 

Lelio 


--- 
Lelio Fulgenzi, B.A. 
Senior Analyst, Network Infrastructure 
Computing and Communications Services (CCS) 
University of Guelph 

519‐824‐4120 Ext 56354 
le...@uoguelph.ca 
www.uoguelph.ca/ccs 
Room 037, Animal Science and Nutrition Building 
Guelph, Ontario, N1G 2W1 

- Original Message -

From: "Anthony Holloway"  
To: "Lelio Fulgenzi"  
Cc: "cisco voip"  
Sent: Thursday, June 9, 2016 3:27:43 PM 
Subject: Re: [cisco-voip] certificates and SANs - what's really needed in 
there? 

This information might be a bit dated, but do note that Jabber will behave 
differently in depending on the version you have. Therefore, what looks like 
it's working today, could break at the next Jabber update. 

I'm sanitizing the below for privacy 

---Begin Original Email--- 

Today I noticed that when I started with a fresh install of Jabber 11.1(2), but 
did have the Root CA cert installed on my machine, Jabber still warned about 
the Expressway -E server cert ( video.company.com ). Have any of you seen that 
also? 

I didn't think anything changed with our cert, so I figured it had to be Jabber 
that changed. So, I uninstalled 11.1(2) and worked my way backwards through the 
versions until the warning went away. Luckily, I only had to go back to 
11.1(0), just two versions back. 

I compared the logs from 11.1(0) with 11.1(2) and here's the difference. I 
removed some of the log data for brevity. Notice the blue lines are different, 
and the entire red section is new in 11.1(2). 

GOOD - Jabber 11.1(0) 
[csf::http::CurlHttpUtils::curlTraceCallback] - Request #34 post connect phase: 
'Connected to video.company.com (A.B.C.D) port 8443 (#0)' 
[csf::cert::BaseCertVerifier::verifyCertificate] - verifyCertificate using ctx. 
Identity: Reference identifiers: [' video.company.com ']; Identifier to 
display: ' video.company.com ' 
[csf::cert::BaseCertVerifier::checkIdentity] - About to verify the Subject Alt 
Name. 
[csf::cert::CertVerifier::checkIdentifier] - Verifying identity ' 
video.company.com ' 
[csf::cert::AltNameParserImpl::verify] - Match for ' video.company.com ' found 
in dnsNames index: 0 
[csf::cert::BaseCertVerifier::checkIdentifiers] - Verification of identity 
succeeded. Matched identifier : ' video.company.com ' 
[csf::cert::PlatformVerificationHandler::handlePlatformVerificationResultSynchronously]
 - Verification result : SUCCESS reason : [VALID] 

BAD - Jabber 11.1(2) 
[csf::http::CurlHttpUtils::curlTraceCallback] - Request #3 post connect phase: 
'Connected to video.company.com (A.B.C.D) port 8443 (#0)' 
[csf::cert::BaseCertVerifier:: verifyCertificate] - verifyCertificate using 
ctx. Identity: Mandatory reference identifier: ' video.company.com '; Reference 
identifiers: [' company.com , ' collab-edge.company.com ']; Identifier to 
display: ' video.company.com ' 
[csf::cert::BaseCertVerifier::checkIdentity] - About to check for an Identity 
Match. 
[csf::cert::CertVerifier::checkIdentifier] - Verifying identity ' 
video.company.com ' 
[csf::cert::AltNameParserImpl::verify] - Match for ' video.company.com ' found 
in dnsNames index: 0 
[csf::cert::BaseCertVerifier::checkIdentifiers] - Verification of identity 
succeeded. Matched identifier : ' video.company.com ' 
[csf::cert::CertVerifier:: checkIdentifier] - Verifying identity ' company.com 
' 
[csf::cert::AltNameParserImpl: :verify] - No Match Found for ' company.com ' 
[csf::cert::CertVerifier:: checkIdentifier] - Verifying identity ' 
collab-edge.company.com ' 
[csf::cert::AltNameParserImpl: :verify] - No Match Found for ' 
collab-edge.company.com ' 
[csf.cert.] [csf::cert::BaseCertVerifier:: checkIdentifiers] - Verification of 
identity: ' company.com ' ' collab-edge.company.com ' failed. 
[csf::common::PolicySet::getPolicy] - Successfully found Policy with nature 
IGNORE_INVALID_CERT_CONDITION [IGNORE_REVOCATION_INFO_UNAVAILABLE_ERRORS] 
[csf::cert::BaseCertVerifier::applyIgnoreInvalidCertConditionPolicy] - About to 
enforce ignore invalid cert condition policy. 
[csf::cert::IgnoreInvalidCertConditionPolicy::removeIgnoredStatuses] - No 
statuses have been removed from the verification status. 
[csf::cert::IgnoreInvalidCertConditionPolicy::enforce] - Policy enforced 
[csf::cert::CertificateDataImpl::parseSubjectCNField] - size of Subject CN 
field : 17 
[csf::cert:: CertificateDataImpl:: parseSubjectCNField] - Subject CN field : 
video.company.com 
[csf::cert::PlatformVerificationHandler::handlePlatformVerificationResultSynchronously]
 - Verification result : FAILURE reason : [CN_NO_MATCH] 

So, 

Re: [cisco-voip] UCCX Script redirect

[Brian Meade]

It uses the CSS of the CTI Ports for these redirects.  I usually put these
type of specific UCCX redirect route patterns in one of my UCCX partitions
to fix these kinds of things.

On Thu, Jun 9, 2016 at 4:52 PM, Aaron Banks 
wrote:

> I'm having a little trouble with a script redirect.  The redirect works
> fine, but the call is being sent to a PRI instead of a SIP trunk.  How it
> works is the call comes in over the SIP trunk to a RP and then is sent to
> UCCX script with a couple of options.  Selecting either option sends the
> call to a DID outside of the enterprise.  I have put in a route pattern
> that is an exact match to one of the options selected in the IVR.  My
> question is - do I have a pattern matching problem or is the CSS of the CTI
> port being used (which, if true, I know exactly what the problem is).  I
> had the redirect CSS on the trigger set to be the route point, but that
> clearly is not working.
>
>
> Any comments, suggestions, mild criticism appreciated.
>
>
> Aaron
>
> ___
> 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] UCCX Script redirect

[Aaron Banks]

I'm having a little trouble with a script redirect.  The redirect works fine, 
but the call is being sent to a PRI instead of a SIP trunk.  How it works is 
the call comes in over the SIP trunk to a RP and then is sent to UCCX script 
with a couple of options.  Selecting either option sends the call to a DID 
outside of the enterprise.  I have put in a route pattern that is an exact 
match to one of the options selected in the IVR.  My question is - do I have a 
pattern matching problem or is the CSS of the CTI port being used (which, if 
true, I know exactly what the problem is).  I had the redirect CSS on the 
trigger set to be the route point, but that clearly is not working.


Any comments, suggestions, mild criticism appreciated.


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

Re: [cisco-voip] certificates and SANs - what's really needed in there?

[Lelio Fulgenzi]

Thanks Anthony. Right now, the problem we have is that the primary Exp-E is 
complaining about the certificate of the secondary Exp-C. 

We created the C certs without the cluster name in the SAN, which might be the 
problem. 

The partner is investigating and will touch base tomorrow. 

We decided to use DNS, not CollabEdge as the setup. Again, under 
recommendations from the partner. 

Once we see both tunnels up with no errors, and the VCS checker is successful, 
then next step is to test Jabber! 

Hopefully we're good to go soon. 


--- 
Lelio Fulgenzi, B.A. 
Senior Analyst, Network Infrastructure 
Computing and Communications Services (CCS) 
University of Guelph 

519‐824‐4120 Ext 56354 
le...@uoguelph.ca 
www.uoguelph.ca/ccs 
Room 037, Animal Science and Nutrition Building 
Guelph, Ontario, N1G 2W1 

- Original Message -

From: "Anthony Holloway"  
To: "Lelio Fulgenzi"  
Cc: "cisco voip"  
Sent: Thursday, June 9, 2016 3:27:43 PM 
Subject: Re: [cisco-voip] certificates and SANs - what's really needed in 
there? 

This information might be a bit dated, but do note that Jabber will behave 
differently in depending on the version you have. Therefore, what looks like 
it's working today, could break at the next Jabber update. 

I'm sanitizing the below for privacy 

---Begin Original Email--- 

Today I noticed that when I started with a fresh install of Jabber 11.1(2), but 
did have the Root CA cert installed on my machine, Jabber still warned about 
the Expressway -E server cert ( video.company.com ). Have any of you seen that 
also? 

I didn't think anything changed with our cert, so I figured it had to be Jabber 
that changed. So, I uninstalled 11.1(2) and worked my way backwards through the 
versions until the warning went away. Luckily, I only had to go back to 
11.1(0), just two versions back. 

I compared the logs from 11.1(0) with 11.1(2) and here's the difference. I 
removed some of the log data for brevity. Notice the blue lines are different, 
and the entire red section is new in 11.1(2). 

GOOD - Jabber 11.1(0) 
[csf::http::CurlHttpUtils::curlTraceCallback] - Request #34 post connect phase: 
'Connected to video.company.com (A.B.C.D) port 8443 (#0)' 
[csf::cert::BaseCertVerifier::verifyCertificate] - verifyCertificate using ctx. 
Identity: Reference identifiers: [' video.company.com ']; Identifier to 
display: ' video.company.com ' 
[csf::cert::BaseCertVerifier::checkIdentity] - About to verify the Subject Alt 
Name. 
[csf::cert::CertVerifier::checkIdentifier] - Verifying identity ' 
video.company.com ' 
[csf::cert::AltNameParserImpl::verify] - Match for ' video.company.com ' found 
in dnsNames index: 0 
[csf::cert::BaseCertVerifier::checkIdentifiers] - Verification of identity 
succeeded. Matched identifier : ' video.company.com ' 
[csf::cert::PlatformVerificationHandler::handlePlatformVerificationResultSynchronously]
 - Verification result : SUCCESS reason : [VALID] 

BAD - Jabber 11.1(2) 
[csf::http::CurlHttpUtils::curlTraceCallback] - Request #3 post connect phase: 
'Connected to video.company.com (A.B.C.D) port 8443 (#0)' 
[csf::cert::BaseCertVerifier:: verifyCertificate] - verifyCertificate using 
ctx. Identity: Mandatory reference identifier: ' video.company.com '; Reference 
identifiers: [' company.com , ' collab-edge.company.com ']; Identifier to 
display: ' video.company.com ' 
[csf::cert::BaseCertVerifier::checkIdentity] - About to check for an Identity 
Match. 
[csf::cert::CertVerifier::checkIdentifier] - Verifying identity ' 
video.company.com ' 
[csf::cert::AltNameParserImpl::verify] - Match for ' video.company.com ' found 
in dnsNames index: 0 
[csf::cert::BaseCertVerifier::checkIdentifiers] - Verification of identity 
succeeded. Matched identifier : ' video.company.com ' 
[csf::cert::CertVerifier:: checkIdentifier] - Verifying identity ' company.com 
' 
[csf::cert::AltNameParserImpl: :verify] - No Match Found for ' company.com ' 
[csf::cert::CertVerifier:: checkIdentifier] - Verifying identity ' 
collab-edge.company.com ' 
[csf::cert::AltNameParserImpl: :verify] - No Match Found for ' 
collab-edge.company.com ' 
[csf.cert.] [csf::cert::BaseCertVerifier:: checkIdentifiers] - Verification of 
identity: ' company.com ' ' collab-edge.company.com ' failed. 
[csf::common::PolicySet::getPolicy] - Successfully found Policy with nature 
IGNORE_INVALID_CERT_CONDITION [IGNORE_REVOCATION_INFO_UNAVAILABLE_ERRORS] 
[csf::cert::BaseCertVerifier::applyIgnoreInvalidCertConditionPolicy] - About to 
enforce ignore invalid cert condition policy. 
[csf::cert::IgnoreInvalidCertConditionPolicy::removeIgnoredStatuses] - No 
statuses have been removed from the verification status. 
[csf::cert::IgnoreInvalidCertConditionPolicy::enforce] - Policy enforced 
[csf::cert::CertificateDataImpl::parseSubjectCNField] - size of Subject CN 
field : 17 
[csf::cert:: CertificateDataImpl:: parseSubjectCNField] - Subject CN field 

Re: [cisco-voip] certificates and SANs - what's really needed in there?

[Anthony Holloway]

This information might be a bit dated, but do note that Jabber will behave
differently in depending on the version you have.  Therefore, what looks
like it's working today, could break at the next Jabber update.

I'm sanitizing the below for privacy

---Begin Original Email---

Today I noticed that when I started with a fresh install of Jabber 11.1(2),
but did have the Root CA cert installed on my machine, Jabber still warned
about the Expressway-E server cert (video.company.com).  Have any of you
seen that also?

I didn't think anything changed with our cert, so I figured it had to be
Jabber that changed.  So, I uninstalled 11.1(2) and worked my way backwards
through the versions until the warning went away.  Luckily, I only had to
go back to 11.1(0), just two versions back.

I compared the logs from 11.1(0) with 11.1(2) and here's the difference.  I
removed some of the log data for brevity.  Notice the blue lines are
different, and the entire red section is new in 11.1(2).

*GOOD - Jabber 11.1(0)*
[csf::http::CurlHttpUtils::curlTraceCallback] - Request #34 post connect
phase: 'Connected to video.company.com (A.B.C.D) port 8443 (#0)'
[csf::cert::BaseCertVerifier::verifyCertificate] - verifyCertificate using
ctx. Identity: Reference identifiers: ['video.company.com']; Identifier to
display: 'video.company.com'
[csf::cert::BaseCertVerifier::checkIdentity] - About to verify the Subject
Alt Name.
[csf::cert::CertVerifier::checkIdentifier] - Verifying identity '
video.company.com'
[csf::cert::AltNameParserImpl::verify] - Match for 'video.company.com'
found in dnsNames index: 0
[csf::cert::BaseCertVerifier::checkIdentifiers] - Verification of identity
succeeded. Matched identifier : 'video.company.com'
[csf::cert::PlatformVerificationHandler::handlePlatformVerificationResultSynchronously]
- Verification result : SUCCESS reason : [VALID]

*BAD - Jabber 11.1(2)*
[csf::http::CurlHttpUtils::curlTraceCallback] - Request #3 post connect
phase: 'Connected to video.company.com (A.B.C.D) port 8443 (#0)'
[csf::cert::BaseCertVerifier::verifyCertificate] - verifyCertificate using
ctx. Identity: Mandatory reference identifier: 'video.company.com'; Reference
identifiers: ['company.com, 'collab-edge.company.com']; Identifier to
display: 'video.company.com'
[csf::cert::BaseCertVerifier::checkIdentity] - About to check for an
Identity Match.
[csf::cert::CertVerifier::checkIdentifier] - Verifying identity '
video.company.com'
[csf::cert::AltNameParserImpl::verify] - Match for 'video.company.com'
found in dnsNames index: 0
[csf::cert::BaseCertVerifier::checkIdentifiers] - Verification of identity
succeeded. Matched identifier : 'video.company.com'
[csf::cert::CertVerifier::checkIdentifier] - Verifying identity 'company.com
'
[csf::cert::AltNameParserImpl::verify] - No Match Found for 'company.com'
[csf::cert::CertVerifier::checkIdentifier] - Verifying identity '
collab-edge.company.com'
[csf::cert::AltNameParserImpl::verify] - No Match Found for '
collab-edge.company.com'
[csf.cert.] [csf::cert::BaseCertVerifier::checkIdentifiers] - Verification
of identity: 'company.com' 'collab-edge.company.com'  failed.
[csf::common::PolicySet::getPolicy] - Successfully found Policy with nature
IGNORE_INVALID_CERT_CONDITION [IGNORE_REVOCATION_INFO_UNAVAILABLE_ERRORS]
[csf::cert::BaseCertVerifier::applyIgnoreInvalidCertConditionPolicy] -
About to enforce ignore invalid cert condition policy.
[csf::cert::IgnoreInvalidCertConditionPolicy::removeIgnoredStatuses] - No
statuses have been removed from the verification status.
[csf::cert::IgnoreInvalidCertConditionPolicy::enforce] - Policy enforced
[csf::cert::CertificateDataImpl::parseSubjectCNField] - size of Subject CN
field : 17
[csf::cert::CertificateDataImpl::parseSubjectCNField] - Subject CN field :
video.company.com
[csf::cert::PlatformVerificationHandler::handlePlatformVerificationResultSynchronously]
- Verification result : FAILURE reason : [CN_NO_MATCH]

So, the problem seems obvious now.  Jabber 11.1(2) is checking for *company.com
 and collab-edge.company.com
* in the cert, whereas Jabber 11.1(0) was
not checking for either.

So, I wanted to know more.  I went to the MRA guides, and Expressway Admin
guide, and I found this passage in the Admin guide:

*Select the DNS format and manually specify the required FQDNs. Separate
the FQDNs by commas if you need multiple domains. You may select
CollabEdgeDNS format instead, which simply adds the prefix collab-edge. to
the domain that you enter. This format is recommended if you do not want to
include your top level domain as a SAN (see example in following
screenshot). *

Link: http://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/expressway
/admin_guide/Cisco-Expressway-Administrator-Guide-X8-5-2.pdf (Page 63 of
403)

I found the following section of the Expressway-E configuration for
certificates, and I modified/added the two red circled values, then
generated a new CSR, followed by signing 

[cisco-voip] certificates and SANs - what's really needed in there?

[Lelio Fulgenzi]

Our lab expressway cluster is on it's way to be completed... only thing missing 
is the certificates. 

I read up a little on the archives, but still not so clear. 

We're going to be getting individual certs for each Exp-C and Exp-E member (a 
cluster of 2xC, 2xE). 

I don't believe I need any SANs for the Exp-C. But I'm not sure if I need the 
cluster name in the certificate. 



* CERT 1: CN=exp-c-a.acme.com, SAN=exp-c-cluster.acme.com 
* CERT 2: CN= exp-c-b.acme.com, SAN=exp-c-cluster.acme.com 

For the Exp-E, I'd like to add the hostname for the outside interface, as well 
as the CNAME for the services domain, and the CNAME/ALIAS I'm using for the 
collab-edge resolution. 


* CERT 1: CN=exp-e-a.acme.com, SAN=exp-e-cluster.acme.com, 
exp-e-a-out.acme.com, myjabber.acme.com, proxy-a.acme.com 
* CERT 2: CN= exp-e-b.acme.com, SAN=exp-e-cluster.acme.com, 
exp-e-b-out.acme.com, myjabber.acme.com, proxy-b.acme.com 

In our use case, _collab-edge SRV records resolve to proxy-a and proxy-b, and 
those resolve to the exp-e-a-out and exp-e-b-out interfaces respectively. 

Anything special to get off-prem hardware devices like the 88/98xx , DX and SX 
to work properly via MRA? 

--- 
Lelio Fulgenzi, B.A. 
Senior Analyst, Network Infrastructure 
Computing and Communications Services (CCS) 
University of Guelph 

519‐824‐4120 Ext 56354 
le...@uoguelph.ca 
www.uoguelph.ca/ccs 
Room 037, Animal Science and Nutrition Building 
Guelph, Ontario, N1G 2W1 

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

Re: [cisco-voip] DS3 voice delivery?

[Nick Barnett]

Thank you everybody. The mux jumped into maintenance mode for some reason.
We were able to find a 20 year old manual that had DB9 ->RJ45 pinouts... I
cut the end off a blue cisco console cable and rewired the end. Then we
could session into the device and set it back into service. We're up for
now, hopefully it doesn't decide it needs to be in maintenance mode for
another 15 years :)

On Wed, Jun 8, 2016 at 8:51 AM, Nick Barnett  wrote:

> So, we have an old MUX that died. We have to either replace the MUX or use
> something else. Is it possible to use a DS3 SM on an ISR to terminate the
> DS3? Right now, we have a DS3 that hits a mux and breaks out to 28 PRIs...
> those PRIs go into a plethora of VWIC interfaces on a SIP router. Would it
> be possible to get another module for this router that lets us plug the
> coax in and skip all of this VWIC/MUX business?
>
> Thanks,
> Nick
>
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] Helios IP Uni intercom units Dual Button.

[Matt Slaga (AM)]

Yes, that’s too bad on the Helios support.  We were actually looking into some 
of their units for a similar scenario.  Looks like we will cross Helios off the 
vendor list.



From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of 
Matthew Collins
Sent: Thursday, June 9, 2016 4:08 AM
To: Norton, Mike ; Cisco VoIP Group 

Subject: Re: [cisco-voip] Helios IP Uni intercom units Dual Button.


Thanks for your reply’s Mike and Neal,

We have hard coded the voice vlan as they were booting in the data vlan. From 
the traces its not looking like a network issues with qos ect.

Yes they register to the a CUCM system as 3rd party sip end points.

With regards to locations they are either side of a pair of 2 way airlock doors 
so there is no chance of getting feedback from each other. I did test two 
devices between different floors to completely rule this out but there was 
still issues.

Mike I think you may be right about the speakerphone logic as calls between a 
intercom and a desk phone are ok. Just annoying Helios point blank refuse any 
support.

Regards

Matthew Collins







From: Norton, Mike [mailto:mikenor...@pwsd76.ab.ca]
Sent: 08 June 2016 17:55
To: Matthew Collins >; Cisco 
VoIP Group >
Subject: RE: Helios IP Uni intercom units Dual Button.

Matthew – “The phones are registered and they can place calls between each 
other.”

Are they actually meant to be used that way?

Sounds to me like the speakerphone logic is getting confused and/or sucks. E.g. 
the speakerphone logic on one side makes adjustments, it confuses the 
speakerphone logic on the other side, causing it to also make adjustments, 
which makes the first side readjust, etc. etc. Could be that they are meant 
more for calling a standard handset and not really meant for calling each 
other. Just a guess.

Furthermore, are they within “earshot” of each other? ‘Cause that would 
definitely cause feedback and weird speakerphone behaviour.

-mn


From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of 
Matthew Collins
Sent: June-08-16 9:18 AM
To: Cisco VoIP Group 
>
Subject: [cisco-voip] Helios IP Uni intercom units Dual Button.

Hi all,

I have been asked to configure some Helios IP Uni intercom units and register 
them to the CUCM, I have been able to compete this, The phones are registered 
and they can place calls between each other but the audio quality is poor, and 
when I say poor I don’t mean packet loss but the Audio volume keeps getting 
higher then lower, There is a lot of feedback. I might get 10 seconds of clear 
audio then its all start to go bad again. I have tested lots of the audio 
settings but not been able to get the right combo. I have also upgraded them to 
their latest firmware. I’m unable to log a call with Helios for support as we 
didn’t purchase them direct. They are telling my to do to the supplier, But we 
are unsure where they were purchased from.

Any thoughts? What was anyone else’s experience, Did they just work out of the 
box without tweaking the audio settings?

Thanks in advance.


Matthew


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

Re: [cisco-voip] Helios IP Uni intercom units Dual Button.

[Matthew Collins]

Thanks for your reply's Mike and Neal,

We have hard coded the voice vlan as they were booting in the data vlan. From 
the traces its not looking like a network issues with qos ect.

Yes they register to the a CUCM system as 3rd party sip end points.

With regards to locations they are either side of a pair of 2 way airlock doors 
so there is no chance of getting feedback from each other. I did test two 
devices between different floors to completely rule this out but there was 
still issues.

Mike I think you may be right about the speakerphone logic as calls between a 
intercom and a desk phone are ok. Just annoying Helios point blank refuse any 
support.

Regards

Matthew Collins







From: Norton, Mike [mailto:mikenor...@pwsd76.ab.ca]
Sent: 08 June 2016 17:55
To: Matthew Collins ; Cisco VoIP Group 

Subject: RE: Helios IP Uni intercom units Dual Button.

Matthew - "The phones are registered and they can place calls between each 
other."

Are they actually meant to be used that way?

Sounds to me like the speakerphone logic is getting confused and/or sucks. E.g. 
the speakerphone logic on one side makes adjustments, it confuses the 
speakerphone logic on the other side, causing it to also make adjustments, 
which makes the first side readjust, etc. etc. Could be that they are meant 
more for calling a standard handset and not really meant for calling each 
other. Just a guess.

Furthermore, are they within "earshot" of each other? 'Cause that would 
definitely cause feedback and weird speakerphone behaviour.

-mn


From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of 
Matthew Collins
Sent: June-08-16 9:18 AM
To: Cisco VoIP Group 
>
Subject: [cisco-voip] Helios IP Uni intercom units Dual Button.

Hi all,

I have been asked to configure some Helios IP Uni intercom units and register 
them to the CUCM, I have been able to compete this, The phones are registered 
and they can place calls between each other but the audio quality is poor, and 
when I say poor I don't mean packet loss but the Audio volume keeps getting 
higher then lower, There is a lot of feedback. I might get 10 seconds of clear 
audio then its all start to go bad again. I have tested lots of the audio 
settings but not been able to get the right combo. I have also upgraded them to 
their latest firmware. I'm unable to log a call with Helios for support as we 
didn't purchase them direct. They are telling my to do to the supplier, But we 
are unsure where they were purchased from.

Any thoughts? What was anyone else's experience, Did they just work out of the 
box without tweaking the audio settings?

Thanks in advance.


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