Re: [cisco-voip] Question about call activity at the device level?

[Loren Hillukka]

Yes, you can use origdevicename and destdevicename columns, use both with “or” 
to capture to and from.

Loren

On May 18, 2022, at 8:51 AM, Tim Reimers  wrote:


Hi all -

Is there a way to determine call activity by the device in CDR?
I'm trying to evaluate call activity across a variety of VG-224s, and a CDR 
query or SQL query that would just instantly pull all call activity to/from a 
VG port would be very helpful..

Thanks Tim

--

Quis custodiet  
ipsos nexus

Tim Reimers

Network Administrator

I.T Services

City of Asheville

treim...@ashevillenc.gov

(desk) 828-259-5512

(cell)   828-552-1585

"That’s no ordinary rabbit  packet!  That’s the most foul, cruel, and bad 
tempered badly framed packet you ever set eyes on. Listen, that packet’s got a 
vicious streak a mile wide, he’s a killer.He’s got huge sharp MTU…eh, he can 
leap about and cross Vlans…. I warned you, I warned you but did you listen? No… 
ohhh no, it’s just a harmless little packet on the network, isn’t it now"

___
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] Cisco UC on Dell VxRail ?

[Loren Hillukka]

I know of a few places running Cisco UC (and UCCE) on vxRail, working fine. 
Follow the specs-based guidelines.

Loren

On Mar 21, 2022, at 12:45 PM, Lelio Fulgenzi  wrote:


Did you check the specs based listing for the versions? Is it local storage or 
shared storage? Shared storage has specific requirements as well.

From: cisco-voip  On Behalf Of Countryman, 
Edward
Sent: Monday, March 21, 2022 1:20 PM
To: cisco-voip@puck.nether.net
Subject: [cisco-voip] Cisco UC on Dell VxRail ?

CAUTION: This email originated from outside of the University of Guelph. Do not 
click links or open attachments unless you recognize the sender and know the 
content is safe. If in doubt, forward suspicious emails to 
ith...@uoguelph.ca

We’ve the need to move cucm/unity/ER subscriber nodes to a new data center.

The new DC runs all dell VxRail hyperconverged hardware.

Anyone aware of any concerns with cisco UC apps running on this hardware?
CONFIDENTIALITY NOTICE: This email message and any accompanying data or files 
is confidential and may contain privileged information intended only for the 
named recipient(s). If you are not the intended recipient(s), you are hereby 
notified that the dissemination, distribution, and or copying of this message 
is strictly prohibited. If you receive this message in error, or are not the 
named recipient(s), please notify the sender at the email address above, delete 
this email from your computer, and destroy any copies in any form immediately. 
Receipt by anyone other than the named recipient(s) is not a waiver of any 
attorney-client, work product, or other applicable privilege.
___
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] Ported to SIP carrier - some calls still coming in old carrier

[Loren Hillukka]

I’ve seen this with toll free numbers that deliver a local DID in, so you don’t 
know what the toll free being dialed is.
If you don’t have local records you will need to go to your toll free carrier 
(might not be the same one that owned the PRI) and request reports of all TFNs 
owned and what they point at or what they deliver to you when dialed.

Loren

On Jul 8, 2021, at 11:36 AM, Riley, Sean  wrote:


We ported about 700 DID’s yesterday, from our PRI carrier to a new SIP carrier. 
Everything is working great, except I still see some calls coming into the old 
H323 gateways connected to the old carrier.  If I make a test call from my cell 
phone to the called number seen on the old gateway, the call routes through our 
new SIP gateway as expected.  Observing over the past 2 days it does seem that 
some of the calls are from the same “calling ID” and number.

Could it just take time for the port to propagate to other carriers and this 
will eventually work itself out over the coming days?  Or could there be 
something else causing calls from specific callers to still route through our 
old PRI carrier?

Thanks for any advice or knowledge you can share on this.

Sean.
___
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] CUBE Config Dial Peers

[Loren Hillukka]

Getting a little off the “cube config” topic... if there are others with Best 
practices, tried and true config snippets it’d be nice to see.  If you don’t 
like server groups to reduce dial-peers you can resort to dns srv (even local!)

But I have to say the first time I saw Nate’s CUCM/GW design I thought he was 
crazy. Route filters My first experience with them in 2003 wasn’t pleasant. 
 However, the method used to build, insert, and update them is what changed my 
thinking from “you’re crazy” to appreciating the logic behind the final product.
I would never want to build something with that extensive NPA/NXX dialing/TEHO 
out by hand...

Loren

On Jun 16, 2020, at 4:31 PM, Anthony Holloway  
wrote:


I don't know what it is, but COR list people are also @ route filter people.  
Nailed it.

"I think having NPA/NXX route patterns would be just too much to look at."




There's a reason the SRND/PA/CVD isn't based off of the @ macro.

"But I just don’t see the point of completely ignoring the call routing engine 
in CUBE"

So, you must be against matching incoming legs on Via header too, as opposed to 
incoming called number?

Lastly, you should know that you're wrong about these two points you made:

"If you have two destinations in the group, it just round-robins them"
"...and just say if it comes in this dial-peer send it out any random one of 
these"




On Tue, Jun 16, 2020 at 4:05 PM NateCCIE 
mailto:natec...@gmail.com>> wrote:
No more 9.@, I use \+.@ now.  I think having NPA/NXX route patterns would be 
just too much to look at.  I do wish that route filters could be longer than 
1024 characters.

But I just don’t see the point of completely ignoring the call routing engine 
in CUBE and just say if it comes in this dial-peer send it out any random one 
of these.  It doesn’t work with anything but the simplest of configs, and I 
really appreciate a base config that works for everything and can be expanded 
upon.  More and more when I keep things consistent between deployments, I am 
quicker at figuring out what’s broken and can fix it quickly, and customers are 
amazed that I remembered their system.




From: Anthony Holloway 
mailto:avholloway%2bcisco-v...@gmail.com>>
Sent: Tuesday, June 16, 2020 1:56 PM
To: NateCCIE mailto:natec...@gmail.com>>
Cc: Loren Hillukka mailto:lchillu...@hotmail.com>>; 
Cisco VoIP Group mailto:cisco-voip@puck.nether.net>>
Subject: Re: [cisco-voip] CUBE Config Dial Peers

"I cannot stand DPG"
"I use cor-list"

I bet you also are a sadist and use 9.@ too.  You and Lelio should form a posse 
and fight Brian and I.  The losers must convert to the other's design.

On Tue, Jun 16, 2020 at 12:17 PM NateCCIE 
mailto:natec...@gmail.com>> wrote:
Well once Loren speaks up you know it’s an interesting thread.

My two cents, I cannot stand DPG.  Its crazy that it completely ignores 
destination pattern.  If you have two destinations in the group, it just 
round-robins them.  I got burned not understanding that DPG didn’t look at 
destination pattern and I swore I would never use them again.

I use cor-list to restrict the SP inbound dial-peer to the cucm outbound 
dial-peer, and vice versa.  Matching the inbound dial-peer by URI works great, 
I started with matching “FROM” but that fell apart in some cases, so I use VIA 
by default now, and that has been solid.

My numbering is usually 1X for CUCM, with the 0 for inbound in each range, then 
2X for the first SIP provider and 3X for the 2nd, maybe 5X for CVP etc.

I always localize on the CUBE, sending a full +E.164 from CUCM and then use 
translation profiles to format to how the specific country/carrier wants to see 
the calls.  The exception is US 11D/10D determination is done by the CUCM 
because I find it easier to load all of the local NPA-NXX into CUCM route 
filters via AXL, but then sometimes I am doing TEHO and have to control which 
outbound dial-peer it chooses.

I also never let the CUBE choose the carrier, I think mostly because a long 
time ago I had the same carrier spread over multiple gateways along with 
multiple carriers in each gateway, and I wanted CUCM to re-route to the other 
gateway same carrier before CUBE used a less preferred route because it was 
local.  So when there is multiple carriers I usually will prefix 1#* or 2#* on 
up for each carrier.

Anyway, that’s my 2 cents.


From: cisco-voip 
mailto:cisco-voip-boun...@puck.nether.net>> 
On Behalf Of Loren Hillukka
Sent: Tuesday, June 16, 2020 10:26 AM
To: Anthony Holloway 
mailto:avholloway%2bcisco-v...@gmail.com>>
Cc: cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
Subject: Re: [cisco-voip] CUBE Config Dial Peers

Nice to see the examples and explanations - thank you!  I really like the 
naming structure to allow simple a show command to pull everything related to 
one side of the call flow.
URI matching broke down in U

Re: [cisco-voip] CUBE Config Dial Peers

[Loren Hillukka]

I believe you have described Nate to a “T” (no . included) 

Loren

On Jun 16, 2020, at 2:56 PM, Anthony Holloway  
wrote:


"I cannot stand DPG"
"I use cor-list"

I bet you also are a sadist and use 9.@ too.  You and Lelio should form a posse 
and fight Brian and I.  The losers must convert to the other's design.

On Tue, Jun 16, 2020 at 12:17 PM NateCCIE 
mailto:natec...@gmail.com>> wrote:
Well once Loren speaks up you know it’s an interesting thread.

My two cents, I cannot stand DPG.  Its crazy that it completely ignores 
destination pattern.  If you have two destinations in the group, it just 
round-robins them.  I got burned not understanding that DPG didn’t look at 
destination pattern and I swore I would never use them again.

I use cor-list to restrict the SP inbound dial-peer to the cucm outbound 
dial-peer, and vice versa.  Matching the inbound dial-peer by URI works great, 
I started with matching “FROM” but that fell apart in some cases, so I use VIA 
by default now, and that has been solid.

My numbering is usually 1X for CUCM, with the 0 for inbound in each range, then 
2X for the first SIP provider and 3X for the 2nd, maybe 5X for CVP etc.

I always localize on the CUBE, sending a full +E.164 from CUCM and then use 
translation profiles to format to how the specific country/carrier wants to see 
the calls.  The exception is US 11D/10D determination is done by the CUCM 
because I find it easier to load all of the local NPA-NXX into CUCM route 
filters via AXL, but then sometimes I am doing TEHO and have to control which 
outbound dial-peer it chooses.

I also never let the CUBE choose the carrier, I think mostly because a long 
time ago I had the same carrier spread over multiple gateways along with 
multiple carriers in each gateway, and I wanted CUCM to re-route to the other 
gateway same carrier before CUBE used a less preferred route because it was 
local.  So when there is multiple carriers I usually will prefix 1#* or 2#* on 
up for each carrier.

Anyway, that’s my 2 cents.


From: cisco-voip 
mailto:cisco-voip-boun...@puck.nether.net>> 
On Behalf Of Loren Hillukka
Sent: Tuesday, June 16, 2020 10:26 AM
To: Anthony Holloway 
mailto:avholloway%2bcisco-v...@gmail.com>>
Cc: cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
Subject: Re: [cisco-voip] CUBE Config Dial Peers

Nice to see the examples and explanations - thank you!  I really like the 
naming structure to allow simple a show command to pull everything related to 
one side of the call flow.
URI matching broke down in UCCE environments as uri match overrides all other 
matching.  I needed to match some ingress numbers from the ITSP to apply CVP 
.tcl scripts too and wasn’t able to when matching all inbound from ITSP via 
URI.  So the config gets a bit longer in UCCE environments due to this.
I ended up using e164-pattern-maps as another means of collapsing dial-peers, 
with uri match for calls from CUCM, and also server-groups to reduce outbound 
peers.
Based on the configs from Brian and Anthony, you wouldn’t need 
e164-pattern-maps in those environments.  Curious what direction others have 
taken to simplify dial-peers with UCCE in play.

Loren


On Jun 16, 2020, at 10:55 AM, Anthony Holloway 
mailto:avholloway+cisco-v...@gmail.com>> wrote:

Sorry, transmission failed.  Try disabling NSF and re-sending.

Back to the point of ABC123, it would be so nice if we could add comments to 
the show run.  Second best is to keep a commented copy of the config off box in 
your documentation repository.

On Mon, Jun 15, 2020 at 11:31 PM Brian Meade 
mailto:bmead...@vt.edu>> wrote:
Anthony,

I like the config.  Definitely is nice to have some standardization on the 
dial-peer tags.  I've usually done all my inbound dial-peers in the 1XX range 
but have gone outside of that lately with separating inbound ITSP and inbound 
CUCM dial-peers to make them more obvious but I like the idea of having more 
structure like yours.

Using the destination-pattern ABC123 is a great idea to show that's not used as 
mentioned before.

I try to always use voice-class codec for every dial-peer even if I've only got 
1 codec configured there just to make it easier to change if ever needed but 
that was in the past when I had separate local/long 
distance/911/international/10-digit dial-peers.  Simplifying it down to a 
single inbound/outbound dial-peer with the ITSP makes it a toss-up if that 
helps anymore.

I've tried to keep KPML on my ITSP facing dial-peers just in case they happen 
to support it.  I've found some say they don't but actually do use it if you 
advertise it.  No harm in advertising it from our side.

I like the aliases you've got there as well.  I feel like I'm always on some 
random customer's box so not sure I'd remember to always put them in first but 
definitely nice to have when you make the full CUBE config.

Looks like all you're missing is your fax config!  I can fa

Re: [cisco-voip] CUBE Config Dial Peers

[Loren Hillukka]

Nice to see the examples and explanations - thank you!  I really like the 
naming structure to allow simple a show command to pull everything related to 
one side of the call flow.
URI matching broke down in UCCE environments as uri match overrides all other 
matching.  I needed to match some ingress numbers from the ITSP to apply CVP 
.tcl scripts too and wasn’t able to when matching all inbound from ITSP via 
URI.  So the config gets a bit longer in UCCE environments due to this.
I ended up using e164-pattern-maps as another means of collapsing dial-peers, 
with uri match for calls from CUCM, and also server-groups to reduce outbound 
peers.
Based on the configs from Brian and Anthony, you wouldn’t need 
e164-pattern-maps in those environments.  Curious what direction others have 
taken to simplify dial-peers with UCCE in play.

Loren

On Jun 16, 2020, at 10:55 AM, Anthony Holloway 
 wrote:


Sorry, transmission failed.  Try disabling NSF and re-sending.

Back to the point of ABC123, it would be so nice if we could add comments to 
the show run.  Second best is to keep a commented copy of the config off box in 
your documentation repository.

On Mon, Jun 15, 2020 at 11:31 PM Brian Meade 
mailto:bmead...@vt.edu>> wrote:
Anthony,

I like the config.  Definitely is nice to have some standardization on the 
dial-peer tags.  I've usually done all my inbound dial-peers in the 1XX range 
but have gone outside of that lately with separating inbound ITSP and inbound 
CUCM dial-peers to make them more obvious but I like the idea of having more 
structure like yours.

Using the destination-pattern ABC123 is a great idea to show that's not used as 
mentioned before.

I try to always use voice-class codec for every dial-peer even if I've only got 
1 codec configured there just to make it easier to change if ever needed but 
that was in the past when I had separate local/long 
distance/911/international/10-digit dial-peers.  Simplifying it down to a 
single inbound/outbound dial-peer with the ITSP makes it a toss-up if that 
helps anymore.

I've tried to keep KPML on my ITSP facing dial-peers just in case they happen 
to support it.  I've found some say they don't but actually do use it if you 
advertise it.  No harm in advertising it from our side.

I like the aliases you've got there as well.  I feel like I'm always on some 
random customer's box so not sure I'd remember to always put them in first but 
definitely nice to have when you make the full CUBE config.

Looks like all you're missing is your fax config!  I can fax that over to you! 
:)

On Fri, Jun 12, 2020 at 8:53 PM Anthony Holloway 
mailto:avholloway%2bcisco-v...@gmail.com>> 
wrote:
All great points, thanks for taking the time to respond.

The only one I think that I need to reply to is the DPG and destination-pattern 
one.  I was actually troubleshooting a customer CUBE wherein this exact 
scenario was in place and the only negative was getting options to work.  
Otherwise, it was routing the call just fine.  Granted, I couldn't tell you 
what version that was, as it was like a year or so ago, but either way, I 
always put a destination-pattern on because you need one for options to 
function.

I guess I could reply to one more, and that has to do with tweaking retries 
from 6 to 2 AND using options.  Why stick to one, when you can do both?

Here's the one I use which I said was very similar to yours.

The first thing to note is the numeric structure of my tags.

1000 series numbers are the ITSP side
2000 series numbers are the CUCM side

I would expand this to 3000, 4000, etc., for additional integrations like PRIs, 
FXO, second ITSP, second PBX, etc.  Most I ever had was 6 integrations into a 
single CUBE i think.

The second digit is 1 for incoming and 2 for outgoing.

The 4rd and fourth digit are generally not used, unless I need additional 
dial-peers for the same peer and direction, but doing something slightly 
different.  Most I ever used was like 15 i think.  E.g., 2215  But that was not 
using IP addresses in the matching and DPGs, that was using phone number 
matching, and I was using steering codes.

This numbering structure allows me to do something like this:

show run | section 12..

Which would then show me the following all at once: URI, Server Group, Profile 
and Dial Peers all pertaining to the outgoing ITSP leg.

Also, in this example, we pass +E164 through the gateway bi-directionally, so 
no digit manip needed.

voice class uri 1100 sip
 host ipv4:8.8.8.8
 host ipv4:9.9.9.9
!
voice class server-group 1200
 description ITSP Peers
 ipv4 8.8.8.8 preference 1
 ipv4 9.9.9.9 preference 2
!
voice class sip-options-keepalive 1200
 description ITSP Peers (Intentionally Left Blank)
!
voice class uri 2100 sip
 host ipv4:10.1.1.2
 host ipv4:10.1.1.3
!
voice class server-group 2200
 description CUCM Nodes
 ipv4 10.1.1.2 preference 1
 ipv4 10.1.1.3 preference 2
!
voice class sip-options-keepalive 2200
 description CUCM Nodes (Intentionally 

Re: [cisco-voip] CUCM Interop with MS Teams

[Loren Hillukka]

Terry, the voice part of MS teams is still being worked through to determine 
suitable sites/use cases for initial piloting and getting feet wet but we will 
have a similar mix of endpoints, and it will remain mixed for a long time I’d 
guess (we have UCCE in place). I won’t have many updates for the calling part 
til summer most likely with some of this work delayed due to current events. 
There are other companies out there with this kind of mix, not sure how many 
are on this list and want to give their experience.

Loren

On Mar 24, 2020, at 9:29 PM, Gr ccie  wrote:

 I am looking at something similar. Have a whole mix of deskphones, jabber, 
cisco team, m/s teams, in the client’s environment. Just wondering how your 
landscape looks like and how well it works for calling between cisco-Microsoft 
and PSTN.

Do you have a mix of teams + Desk-phones + jabber at user end or purely MS 
Teams client and backend Cisco ?

Thanks



Thanks,
Terry
On 25 Mar 2020, at 11:18 am, Loren Hillukka  wrote:

 Yes. We are embarking on this adventure soon, using CUBE.

Loren

On Mar 24, 2020, at 6:28 PM, Brian Meade  wrote:


Cisco CUBE can be used for this as well.

Official documentation should be coming in the near future but you can do it 
now with the right configuration.

On Tue, Mar 24, 2020 at 6:07 PM UC Penguin 
mailto:gen...@ucpenguin.com>> wrote:
Does anyone have an experience with setting up interop between CUCM/Microsoft 
Teams with Direct Routing?

If so what (supported) SBC did you use and what if any issues did you encounter?

Thanks!
___
cisco-voip mailing list
cisco-voip@puck.nether.net<mailto: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] FAX into a Cisco shop

[Loren Hillukka]

Currently using Rightfax for much of the globe and it works well, have worked 
with Imagicle in the past and had a good experience.

Loren

On Apr 6, 2020, at 11:24 AM, Mark H. Turpin  wrote:


+1 on Imagicle's fax server.  Xmedius and RightFax are more money, however, all 
three work great.




From: cisco-voip  on behalf of Anthony 
Holloway 
Sent: Monday, April 6, 2020 10:55 AM
To: Terry Oakley 
Cc: voyp list, cisco-voip (cisco-voip@puck.nether.net) 

Subject: Re: [cisco-voip] FAX into a Cisco shop

*** EXTERNAL EMAIL - DO NOT CLICK LINKS ***

RightFax is an OpenText product:
https://en.wikipedia.org/wiki/OpenText#OpenText_RightFax_[40]

I'll add in:
https://www.imagicle.com/en-us/Products/IP-Fax-Server

No affiliation, nor have I even ever used it, but I did do a call recording 
project with them and had a good experience.

On Mon, Apr 6, 2020 at 10:48 AM Terry Oakley via cisco-voip 
mailto:cisco-voip@puck.nether.net>> wrote:

Sheepishly yes.



From: cisco-voip 
mailto:cisco-voip-boun...@puck.nether.net>> 
On Behalf Of Lelio Fulgenzi
Sent: Monday, April 6, 2020 9:45 AM
To: voyp list, cisco-voip 
(cisco-voip@puck.nether.net) 
mailto:cisco-voip@puck.nether.net>>
Subject: Re: [cisco-voip] FAX into a Cisco shop



CAUTION: This email is from an external source. Do not click links or open 
attachments unless you recognize the sender and know the content is safe.

Did you just try to use the word “fax” and “seamless” in the same sentence?



From: cisco-voip 
mailto:cisco-voip-boun...@puck.nether.net>> 
On Behalf Of Terry Oakley via cisco-voip
Sent: Monday, April 6, 2020 11:42 AM
To: cisco-voip@puck.nether.net
Subject: [cisco-voip] FAX into a Cisco shop



Any suggestions for a software based FAX service/application that works 
seamlessly with CUCM and O365We are hoping to move our legacy FAX devices 
into the 20th century during this 21st century pandemic and push to have our 
FAX services virtual or FAX to email.

I have heard of RightFax, XmediusFax, OpenText but not sure which would be the 
best fit and best to integrate with.



Thanks



Terry

___
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] CUCM Interop with MS Teams

[Loren Hillukka]

Yes. We are embarking on this adventure soon, using CUBE.

Loren

On Mar 24, 2020, at 6:28 PM, Brian Meade  wrote:


Cisco CUBE can be used for this as well.

Official documentation should be coming in the near future but you can do it 
now with the right configuration.

On Tue, Mar 24, 2020 at 6:07 PM UC Penguin 
mailto:gen...@ucpenguin.com>> wrote:
Does anyone have an experience with setting up interop between CUCM/Microsoft 
Teams with Direct Routing?

If so what (supported) SBC did you use and what if any issues did you encounter?

Thanks!
___
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] unityconnection db replication issue

[Loren Hillukka]

Ditto on the NTP stratum. Higher values worked fine in 9.x for us, but caused 
problems in 11.5 in our upgrade. Going to stratum 3 or lower fixed some very 
strange issues.

Loren

On Nov 25, 2019, at 8:25 PM, Ryan Huff  wrote:


I would do a few things things;

- utils NTP status (replace any NTP server higher than stratum 3). Cisco says 
stratum 3 or lower is where you need to be; while stratum 5 isn’t incredibly 
high, it may be just a little too high.

I’m not a fan of using fqdns for NTP servers, try to use IP addresses and while 
I’d prefer you use an internal NTP server (to your network) that references 
external NTP sources, directly specifying external NTP servers on a UC server 
is better than having an unreliably high stratum. Use “utils NTP server”... 
list, add and delete to manipulate.

- Next, on both CUC servers, after you get NTP straightened out, from the CLI 
(primary then HA), issue “utils service restart Cisco Tomcat”. Wait about 20 
after the primary, then do the HA.

After about 20 minutes from when you restarted the tomcat service on the HA, do 
“utils dbreplication runtimestate” from the CLI of the primary. If you still 
don’t have “(2) setup complete” for both nodes, you’ll probably need to 
manually reset cluster replication.

To do that, perform the following in order specified (all from the respective 
CLIs;


1.) “utils dbreplication stop all”  (only on the primary server)

2.) “utils dbreplication dropadmindb” (first on the HA server, then the primary 
server)

3.) “utils dbreplication reset all” (only on the primary server)


This process overall could take an hour or more, so be patient.


Afterwards, try “utils dbreplication runtimestate” from the CLI of the primary 
server and see what you get, you should see “(2) Setup Complete” on both nodes.


If you do, then run “show CUC cluster status” on the CLI of the primary server, 
and verify the primary server is the Unity Connection DB primary. 
Alternatively, go to “Tools > Cluster” under Unity Connection Servicability in 
the Web Admin GUI and make sure the primary server, is the Unity Connection DB 
primary.


If you still don’t have “(2) Setup Complete” for both nodes, I’d call Cisco TAC 
and get a case going.

Thanks,

Ryan

On Nov 25, 2019, at 20:43, Jinto Alakkal Kunjumon  wrote:


Hi Naray,

In addition you may also verify below


1. “Cisco DB, A Cisco DB Replicator, Cisco  Database layer Monitor” these 
services should be running.

2. Informix database also rely heavily on DNS, if you have DNS configured both 
forward and reverse DNS lookup should work.


Thanks!
Jinto.



Get Outlook for 
iOS

From: cisco-voip  on behalf of naresh 
rathore 
Sent: Monday, November 25, 2019 8:29:56 PM
To: Ryan Huff 
Cc: cisco-voip@puck.nether.net 
Subject: Re: [cisco-voip] unityconnection db replication issue

hi Ryan



following is the output


admin:utils diagnose test

Log file: platform/log/diag1.log

Starting diagnostic test(s)
===
test - disk_space  : Passed (available: 17668 MB, used: 10920 MB)
skip - disk_files  : This module must be run directly and off hours
test - service_manager : Passed
test - tomcat  : Passed
test - tomcat_deadlocks: Passed
test - tomcat_keystore : Passed
test - tomcat_connectors   : Passed
test - tomcat_threads  : Passed
test - tomcat_memory   : Passed
test - tomcat_sessions : Failed - The following web applications have an 
unusually large number of active sessions: vmrest.  Please collect all of the 
Tomcat logs for root cause analysis: file get activelog tomcat/logs/*
skip - tomcat_heapdump : This module must be run directly and off hours
test - validate_network: Passed
test - raid: Passed
test - system_info : Passed (Collected system information in diagnostic 
log)
test - ntp_reachability: Passed
test - ntp_clock_drift : Passed
test - ntp_stratum : Failed
The reference NTP server is a stratum 5 clock.
NTP servers with stratum 5 or worse clocks are deemed unreliable.
Please consider using an NTP server with better stratum level.

Please use OS Admin GUI to add/delete NTP servers.

skip - sdl_fragmentation   : This module must be run directly and off hours
skip - sdi_fragmentation   : This module must be run directly and off hours

Diagnostics Completed


 The final output will be in Log file: platform/log/diag1.log


 Please use 'file view activelog platform/log/diag1.log' command to see the 
output

admin:


Regards


Naray


From: Ryan Huff 
Sent: Tuesday, November 26, 2019 6:27 AM
To: naresh rathore 
Cc: cisco-voip@puck.nether.net 
Subject: Re: [cisco-voip] 

Re: [cisco-voip] UCCx and Jabber - compatible or not?

[Loren Hillukka]

That’s an interesting way to use the EM feature.
But I have come to hate that logged out EM profile setting.
One region was done a while back by a vendor that set that up on every phone. 
Whether the people used EM or not.  Causes lots of problems when new support 
folks don’t remember that setting and always annoying with the extra steps 
to find what device a particular extension is living on. And if someone moved 
phones, logged in to EM once to get their profile, then EM blips and they get 
logged out, they complain the phone looks different because they forgot they 
logged in weeks or months ago (that cluster does not enforce a max logged in 
time for EM for many various business wants).   And when cluster reboot happens 
the same story is repeated, as other users have come and gone or swapped phones.

It’s late. I’ll be done now.
Just be careful how you use EM logged out profile.

Loren

On Oct 18, 2019, at 11:18 PM, Lelio Fulgenzi  wrote:

 So basically, you can’t “log in” via extension mobility, but the logged out 
profile is the one you end up using when you sign in?

Interesting.

-sent from mobile device-

Lelio Fulgenzi, B.A. | Senior Analyst
Computing and Communications Services | University of Guelph
Room 037 Animal Science & Nutrition Bldg | 50 Stone Rd E | Guelph, ON | N1G 
2W1
519-824-4120 Ext. 56354 | 
le...@uoguelph.ca

www.uoguelph.ca/ccs | @UofGCCS on Instagram, 
Twitter and Facebook

[University of Guelph Cornerstone with Improve Life tagline]

On Oct 18, 2019, at 6:20 PM, Scott Voll 
mailto:svoll.v...@gmail.com>> wrote:

OK, my counter part had an open ticket with TAC on using Jabber in an extension 
mobility environment, and gave us this work around.  Seems to be working for us:
* Response *
As we discussed, for Jabber side possibly the requirement is that the phone 
device is not assigned with an extension, which makes the issue with the UCC.

As tested in lab, I was able to assign an extension mobility profile the same 
way we can for a deskphone. Here below are the steps I took. Please let me know 
if you have any questions!

1. Created a new EM profile:
CUCM >> Device >> Device Settings >> Device Profile >> Add New 
>> Device Profile Type: Cisco Unified Client Services Framework >> I used all 
default settings with the exception of the Login User ID – my test user ID 
“kivanov5”

2. Created a new CSF using default settings. Did not assign a line. I only 
assigned the test user for it as owner and selected the EM profile:
[cid:]

[cid:]

[cid:]

3. In the End User page I just selected the EM Profile

[cid:]

Using these settings above I was able to sign in Jabber with my test user and 
the softphone was just working. From End User perspective, I don’t think there 
would be a noticeable difference. When dialing another test user the caller ID 
was showing the extension of the Extension Mobility profile.

Try it and let me know if that may be working for you!
Kind regards,

On Fri, Oct 18, 2019 at 3:09 PM Lelio Fulgenzi 
mailto:le...@uoguelph.ca>> wrote:
We’ve been using multi-line on Jabber for a bit. Actually, multi-shared-line 
(as a secondary dn). Works great as far as I can tell. Still no experience with 
UCCx though.

I suspect, agent DN as primary, personal as secondary, vm configured for 
personal mailbox, would work great.

Of course, we’re using shred agent logins. Not sure how well that will work.

Lelio

P. S. One thing with shared multi line on Jabber... if someone puts a call on 
hold on the shared line, it appears on Jabber. On everyone’s Jabber. As far as 
I can tell. Need to do more investigation.

-sent from mobile device-

Lelio Fulgenzi, B.A. | Senior Analyst
Computing and Communications Services | University of Guelph
Room 037 Animal Science & Nutrition Bldg | 50 Stone Rd E | Guelph, ON | N1G 2W1
519-824-4120 Ext. 56354 | 
le...@uoguelph.ca

www.uoguelph.ca/ccs | @UofGCCS on Instagram, 
Twitter and Facebook

[University of Guelph Cornerstone with Improve Life tagline]

On Oct 18, 2019, at 5:56 PM, Tim Smith 
mailto:tim.sm...@enject.com.au>> wrote:

Is anyone doing multi line on Jabber yet?

I’ve always thought dedicated UCCX line is best?
Just have one on phone, different one on Jabber
Login to wherever you want to answer calls
It’s unlikely to be desk and softphone at same time (and if it is then use CTI 
instead)

Dedicated line then gets rid of all the other UCCX line restrictions, and it 
doesn’t matter what this DN number is.

Give them a personal DN if required.
If it’s just a dedicated contact centre they may not even need a personal DN

Get Outlook for iOS

From: cisco-voip 
mailto:cisco-voip-boun...@puck.nether.net>> 
on behalf of Matthew Loraditch 
mailto:mloradi...@heliontechnologies.com>>
Sent: Saturday, October 19, 2019 6:49:42 AM
To: Lelio Fulgenzi 

Re: [cisco-voip] Jabber Softphone over WiFi

[Loren Hillukka]

We use that method today Lelio. Our default is IM only, so default jabber 
config file disables telephony features so users don’t ask about the red X. We 
use custom config files in that support field when building the CSFs depending 
on what feature set the soft phone user requires.

Loren

On Oct 11, 2019, at 6:43 AM, Lelio Fulgenzi  wrote:

 Cucm 11.5(1)SU6

Using the support field.

-sent from mobile device-

Lelio Fulgenzi, B.A. | Senior Analyst
Computing and Communications Services | University of Guelph
Room 037 Animal Science & Nutrition Bldg | 50 Stone Rd E | Guelph, ON | N1G 
2W1
519-824-4120 Ext. 56354 | 
le...@uoguelph.ca<mailto:le...@uoguelph.ca>

www.uoguelph.ca/ccs<http://www.uoguelph.ca/ccs> | @UofGCCS on Instagram, 
Twitter and Facebook

[University of Guelph Cornerstone with Improve Life tagline]

On Oct 10, 2019, at 11:01 PM, NateCCIE 
mailto:natec...@gmail.com>> wrote:

Cucm 12.5 jabber config xml per user?

Sent from my iPhone

On Oct 10, 2019, at 8:32 PM, Lelio Fulgenzi 
mailto:le...@uoguelph.ca>> wrote:



Thanks for that info. I had read about custom tabs for speed dials.

I was hoping for the same set of speed dials but at least it’s an option.

Thing is, I’d have to enable that custom tab for those who wanted it.

I’m thinking of an advanced.feature.config.xml and configure only the handful 
of clients that need the feature set like hunt group, speed dial, etc.

-sent from mobile device-

Lelio Fulgenzi, B.A. | Senior Analyst
Computing and Communications Services | University of Guelph
Room 037 Animal Science & Nutrition Bldg | 50 Stone Rd E | Guelph, ON | N1G 
2W1
519-824-4120 Ext. 56354 | 
le...@uoguelph.ca<mailto:le...@uoguelph.ca>

www.uoguelph.ca/ccs<http://www.uoguelph.ca/ccs> | @UofGCCS on Instagram, 
Twitter and Facebook

[University of Guelph Cornerstone with Improve Life tagline]

On Oct 10, 2019, at 9:45 PM, Loren Hillukka 
mailto:lchillu...@hotmail.com>> wrote:

Lots to plan out carefully if going that way indeed. Regarding speed dials one 
customer settled on using Jabber with a custom tab that loaded a file on their 
computer with speed dials in it. The user controlled the file and updated it as 
they needed.

Loren

On Oct 10, 2019, at 6:19 PM, Tim Smith 
mailto:tim.sm...@enject.com.au>> wrote:


Actually good reminder to get some of the new Cisco headsets and give those a 
good run

I’ve had issues with support on the other big vendors of headsets
That was only on a few headsets, it would have been a problem on a bigger 
deployment

I like the idea of end to end Cisco here

From: Lelio Fulgenzi mailto:le...@uoguelph.ca>>
Sent: Friday, 11 October 2019 10:15 AM
To: Tim Smith mailto:tim.sm...@enject.com.au>>
Cc: Scott Voll mailto:svoll.v...@gmail.com>>; voyp list, 
cisco-voip (cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>) 
mailto:cisco-voip@puck.nether.net>>
Subject: Re: [cisco-voip] Jabber Softphone over WiFi


And speaking to that... test them out. And ask people around you.

A headset with audio leak is fine for an office, but not for cubicle land.
-sent from mobile device-


Lelio Fulgenzi, B.A. | Senior Analyst
Computing and Communications Services | University of Guelph
Room 037 Animal Science & Nutrition Bldg | 50 Stone Rd E | Guelph, ON | N1G 
2W1
519-824-4120 Ext. 56354 | 
le...@uoguelph.ca<mailto:le...@uoguelph.ca>

www.uoguelph.ca/ccs<http://www.uoguelph.ca/ccs> | @UofGCCS on Instagram, 
Twitter and Facebook

[University of Guelph Cornerstone with Improve Life tagline]

On Oct 10, 2019, at 6:59 PM, Tim Smith 
mailto:tim.sm...@enject.com.au>> wrote:
Picking good headsets is important too…
Much more hassle troubleshooting some rubbish USB headset
Or even an expensive USB headset with rubbish support

From: cisco-voip 
mailto:cisco-voip-boun...@puck.nether.net>> 
On Behalf Of Scott Voll
Sent: Friday, 11 October 2019 9:55 AM
To: Lelio Fulgenzi mailto:le...@uoguelph.ca>>
Cc: voyp list, cisco-voip 
(cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>) 
mailto:cisco-voip@puck.nether.net>>
Subject: Re: [cisco-voip] Jabber Softphone over WiFi

We have started migrating our Telecommuters over to Jabber from the old IP 
communicator.  So we are getting the "can I use this in the office"  "do you 
have to leave the phone on the desk?"  I think eventually we will have a lot of 
people over on Jabber.  The question is, does everyone move...   I think we 
will have some people that really want physical phones.   and for emergencies 
you will still want a physical phone available.  then lets start the 
conversation about E911.  Then what happens if they are not in the office?  or 
they are running jabber for iphone / Droid???  how does that work?  Lots of 
things to work through.  Can it be done?  yes, but plan ahead.

Scott

On Thu, Oct 10, 2019 at 11:04 AM Lelio Fulgenzi 
mailto:le..

Re: [cisco-voip] Jabber Softphone over WiFi

[Loren Hillukka]

Lots to plan out carefully if going that way indeed. Regarding speed dials one 
customer settled on using Jabber with a custom tab that loaded a file on their 
computer with speed dials in it. The user controlled the file and updated it as 
they needed.

Loren

On Oct 10, 2019, at 6:19 PM, Tim Smith  wrote:


Actually good reminder to get some of the new Cisco headsets and give those a 
good run

I’ve had issues with support on the other big vendors of headsets
That was only on a few headsets, it would have been a problem on a bigger 
deployment

I like the idea of end to end Cisco here

From: Lelio Fulgenzi 
Sent: Friday, 11 October 2019 10:15 AM
To: Tim Smith 
Cc: Scott Voll ; voyp list, cisco-voip 
(cisco-voip@puck.nether.net) 
Subject: Re: [cisco-voip] Jabber Softphone over WiFi


And speaking to that... test them out. And ask people around you.

A headset with audio leak is fine for an office, but not for cubicle land.
-sent from mobile device-


Lelio Fulgenzi, B.A. | Senior Analyst
Computing and Communications Services | University of Guelph
Room 037 Animal Science & Nutrition Bldg | 50 Stone Rd E | Guelph, ON | N1G 
2W1
519-824-4120 Ext. 56354 | 
le...@uoguelph.ca

www.uoguelph.ca/ccs | @UofGCCS on Instagram, 
Twitter and Facebook

[University of Guelph Cornerstone with Improve Life tagline]

On Oct 10, 2019, at 6:59 PM, Tim Smith 
mailto:tim.sm...@enject.com.au>> wrote:
Picking good headsets is important too…
Much more hassle troubleshooting some rubbish USB headset
Or even an expensive USB headset with rubbish support

From: cisco-voip 
mailto:cisco-voip-boun...@puck.nether.net>> 
On Behalf Of Scott Voll
Sent: Friday, 11 October 2019 9:55 AM
To: Lelio Fulgenzi mailto:le...@uoguelph.ca>>
Cc: voyp list, cisco-voip 
(cisco-voip@puck.nether.net) 
mailto:cisco-voip@puck.nether.net>>
Subject: Re: [cisco-voip] Jabber Softphone over WiFi

We have started migrating our Telecommuters over to Jabber from the old IP 
communicator.  So we are getting the "can I use this in the office"  "do you 
have to leave the phone on the desk?"  I think eventually we will have a lot of 
people over on Jabber.  The question is, does everyone move...   I think we 
will have some people that really want physical phones.   and for emergencies 
you will still want a physical phone available.  then lets start the 
conversation about E911.  Then what happens if they are not in the office?  or 
they are running jabber for iphone / Droid???  how does that work?  Lots of 
things to work through.  Can it be done?  yes, but plan ahead.

Scott

On Thu, Oct 10, 2019 at 11:04 AM Lelio Fulgenzi 
mailto:le...@uoguelph.ca>> wrote:
I get contacts…. But for me (and many others I imagine) a speed dial is a 
button. One click.

But again… its just different ways of doing things.


---
Lelio Fulgenzi, B.A. | Senior Analyst
Computing and Communications Services | University of Guelph
Room 037 Animal Science & Nutrition Bldg | 50 Stone Rd E | Guelph, ON | N1G 2W1
519-824-4120 Ext. 56354 | le...@uoguelph.ca

www.uoguelph.ca/ccs | @UofGCCS on Instagram, 
Twitter and Facebook



From: Pawlowski, Adam mailto:aj...@buffalo.edu>>
Sent: Thursday, October 10, 2019 2:03 PM
To: Lelio Fulgenzi mailto:le...@uoguelph.ca>>; Casper, 
Steven mailto:scas...@mtb.com>>
Cc: voyp list, cisco-voip 
(cisco-voip@puck.nether.net) 
mailto:cisco-voip@puck.nether.net>>
Subject: RE: Jabber Softphone over WiFi

Call Park should hopefully be there pretty eventually. It is there on mobile 
today. Speed dials sure those would be your contacts, or “pizza guys”.

I would not deploy an office on it as the only/primary phone without knowing if 
my wireless network was bulletproof. Jabber works fairly well and it is not a 
huge hog on the medium but wireless being what it is, ymmv.

Adam

From: cisco-voip 
mailto:cisco-voip-boun...@puck.nether.net>> 
On Behalf Of Lelio Fulgenzi
Sent: Thursday, October 10, 2019 1:55 PM
To: Casper, Steven mailto:scas...@mtb.com>>
Cc: voyp list, cisco-voip 
(cisco-voip@puck.nether.net) 
mailto:cisco-voip@puck.nether.net>>
Subject: Re: [cisco-voip] Jabber Softphone over WiFi


As long as you have all the components in place, Jabber as a desktop 
replacement is doable. The issue comes down to … do you have all the components 
in place and/or are you ready to live without the feature a missing component 
gives you?

Some components are not an option, say, split view DNS and Expressway for 
on-prem and off-prem delivery. There’s no way I’ve found to do that without 
split view DNS. We ended up having to deploy a set of delegated DNS servers for 
a specific discovery domain in order to deliver the off-premise and on-premise 
functionality.

Some components are ok to put aside… i.e. quality of service.

The other issue is features and 

Re: [cisco-voip] UCCE Patching via SCCM

[Loren Hillukka]

We do patching monthly (mandatory), but manually one side at a time during the 
maintenance window. We do have a powershell script to allow all servers on a 
side to get patches installed at once, and use the script to control clean 
service shutdown, set to manual, and also service start order.  There are 24x7 
sites that have agents working, but they are aware of the patching window 
required by our security policies - once we spoke through the “outage” (minutes 
per side, really - more blips than outages) they were fine with it.  In event 
of longer outages they did work up more survivability configurations to 
implement if necessary.  
When security rules all these “downtime required” discussions are a lot easier. 
I think an SCCM push would be fine as long as you had procedures to do testing 
after the push and reboot.  I am aware of other companies doing it.  

Sent from my iPhone

> On Sep 18, 2019, at 12:06 PM, Ryan Burtch  wrote:
> 
> All,
> 
> I have a customer who wants to do windows patching via SCCM on all their 
> UCCE/CVP Servers - PGs, RTRs, LGRs, CVP CSs, etc.
> 
> Problem, they have 24x7 environments w/ active agents. Does anyone have any 
> best practices on how to go about this?
> 
> 
> 
> Sincerely,
> 
> Ryan Burtch
> ___
> 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] SPAN Port on ISR4451

[Loren Hillukka]

Port-channels aren’t supported with embedded pcap until newer code release, so 
check for that too if going that route.


On Aug 23, 2019, at 4:52 PM, Brian Meade 
mailto:bmead...@vt.edu>> wrote:

I don't think SPAN is actually supported on ISR's.  You could probably do an 
embedded packet capture.

On Fri, Aug 23, 2019 at 8:34 AM Reto Gassmann 
mailto:v...@mrga.ch>> wrote:
Hello Group

I try to set up a SPAN Port on a ISR 4451 
(isr4400-universalk9.16.06.06.SPA.bin).
The interface config are configured like this:

interface Port-channel13
description *** LAN PO 13 Gig0/0/0 + Gig0/0/1 ***
IP address x.y.z.z 255.255.252.0
no negotiation auto
!
interface GigabitEthernet0/0/0
description *** LAN Gig0/0/0 ***
no ip address
negotiation auto
channel-group 13 mode active
!
interface GigabitEthernet0/0/1
description *** LAN Gig0/0/1 ***
no ip address
negotiation auto
channel-group 13 mode active

Now I try to mirror Port-channel13 to GigabitEthernet0/0/2 with this command:
gw# conf t
gw (config)#monitor session 1 source interface port-channel 13
But it fails:
Only NGIO switch is supported for Local SPAN.
SPAN Session Validation failed.

Has anyone an idea how I can setup a SPAN Port on the ISR?

Thanks a lot
Regards Reto
___
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] COBRAS Import fail...

[Loren Hillukka]

Have also had similar issues, switched to using Message Shuttle. Much faster 
for moving messages than COBRAS.

Loren

On Sep 5, 2018, at 11:41 AM, Schlotterer, Tommy 
mailto:tschlotte...@presidio.com>> wrote:

I have had problems importing messages in COBRAS on windows 10 in the past, 
used it on a windows 7 VM and it worked like a charm.

Thanks

Tommy

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of 
Jonathan Charles
Sent: Wednesday, September 5, 2018 12:39 PM
To: cisco-voip@puck.nether.net
Subject: [cisco-voip] COBRAS Import fail...

EXTERNAL EMAIL




[Thread 001], [18/09/05 09:22:55], Starting restore process - pre restore checks
[Thread 001], [18/09/05 09:22:55], Checking for stream file connectivity 
for WAV file restores.
[Thread 001], [18/09/05 09:22:57], (error) in UploadWAVFile on 
ConnectionWAVFiles:The underlying connection was closed: An unexpected error 
occurred on a receive.
[Thread 001], [18/09/05 09:22:57], Unable to upload test WAV file to target 
Connection server. Make sure that you turn off web proxies and ensure that HTTP 
traffic on port 80 and 443 to the Connection server is not being blocked by a 
virus scanner or a firewall.  Error=(error) in UploadWAVFile on 
ConnectionWAVFiles:The underlying connection was closed: An unexpected error 
occurred on a receive.

And then it terminates the import.


I have verified there is no proxy server between the COBRAS and CUC (11.5); 
they are on the same VLAN.

I even tried removing the default gateway so they could only communicate 
directly.

No change in errors.

This is a clean install of CUC 11.5

I tried and there does not appear to be a /SkipWavUploadTest

The windows firewall is disabled.

there is no AV running on the COBRAS server



Any ideas?



Jonathan





Tommy Schlotterer | Systems Engineer - Collaboration
Presidio (NASDAQ: PSDO) | presidio.com
20 N Saint Clair 3rd Floor, Toledo, OH 43604
D: 419.214.1415 | C: 419.706.0259 | 
tschlotte...@presidio.com




This message w/attachments (message) is intended solely for the use of the 
intended recipient(s) and may contain information that is privileged, 
confidential or proprietary. If you are not an intended recipient, please 
notify the sender, and then please delete and destroy all copies and 
attachments. Please be advised that any review or dissemination of, or the 
taking of any action in reliance on, the information contained in or attached 
to this message is prohibited.

___
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] PCD 12.1.1 for CUCM 6.5 PCD Migration

[Loren Hillukka]

No pcd 12.1 does not need to talk to plm or smartlicensing.
Let us know how that upgrade goes, that’s a long way!

Loren

On Aug 20, 2018, at 5:05 PM, NateCCIE 
mailto:natec...@gmail.com>> wrote:

I don’t think PCD touches licensing.

-Nate
From: cisco-voip 
mailto:cisco-voip-boun...@puck.nether.net>> 
On Behalf Of Jason Aarons (Americas)
Sent: Monday, August 20, 2018 3:45 PM
To: cisco-voip (cisco-voip@puck.nether.net) 
mailto:cisco-voip@puck.nether.net>>
Subject: [cisco-voip] PCD 12.1.1 for CUCM 6.5 PCD Migration


I have a customer with CUCM  6.1.5.11900-1 that I plan to upgrade to CUCM 
11.5.1SU5 (Matrix says it is supported, all 7925 phones/loads are good).  I 
plan to use PCD 12.1.1 with PCD Migration.

Does PCD 12.1.1 need to talk to a PLM/Smart Licensing?  The PLM servers are 
still 11.5

-jason



This email and all contents are subject to the following disclaimer:
"http://www.dimensiondata.com/emaildisclaimer;
___
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] CUBE ignoring SDP responses from ITSP

[Loren Hillukka]

Make sure access-group 101 on gig0/0/0 is not blocking it.

Sent from my iPhone

On Aug 10, 2018, at 9:15 PM, Benjamin Turner 
mailto:benmtur...@hotmail.com>> wrote:

Very basic:



version 15.5

voice service voip
ip address trusted list
  ipv4 67.231.8.75
  ipv4 67.231.12.12
  ipv4 192.168.1.20
  ipv4 162.245.36.90
address-hiding
mode border-element license capacity 100
allow-connections sip to sip
no supplementary-service sip moved-temporarily
no supplementary-service sip refer
fax protocol pass-through g711ulaw
sip
  bind control source-interface GigabitEthernet0/0/0
  bind media source-interface GigabitEthernet0/0/0
  registrar server
  no update-callerid
  early-offer forced
  midcall-signaling passthru
  pass-thru content sdp
!
voice class codec 1
codec preference 1 g711ulaw
codec preference 2 g729r8
!
!
voice class sip-profiles 30
request ANY sdp-header Audio-Attribute modify "a=ptime:20" "a=ptime:30"
!
!
!
!
!
voice translation-rule 2
rule 1 /\+1\([2-9].\)/ /\1/
!
voice translation-rule 11
rule 1 /\([2-9]..[2-9]..$\)/ /+1\1/
rule 2 /\(.*\)/ /+\1/
!
voice translation-rule 22
rule 1 /9\(1[2-9]..[2-9]..\)$/ /\1/
rule 2 /9\(911\)$/ /\1/
rule 3 /9\([2-8]11\)$/ /\1/
!
!
voice translation-profile 10DigitTo+1
translate calling 11
translate called 11
!
voice translation-profile LOCALIZE
translate calling 2
!
voice translation-profile OutgoingToBandwidthSIP
translate calling 2
translate called 11
!
!
!
!
voice-card 0/4
dsp services dspfarm
no watchdog
!
!
interface GigabitEthernet0/0/0
description WAN SIP TRUNK TO BANDWIDTH
ip address 162.245.36.90 255.255.255.248
ip nat outside
ip access-group 101 in
ip access-group 101 out
negotiation auto
no cdp enable
!
interface GigabitEthernet0/0/1
description LAN
ip address 192.168.1.1 255.255.255.0
ip nat inside
negotiation auto
!
interface GigabitEthernet0/0/2
no ip address
negotiation auto
!
interface Service-Engine0/4/0
!
interface GigabitEthernet0
vrf forwarding Mgmt-intf
no ip address
negotiation auto
!
!
ip nat inside source list 100 interface GigabitEthernet0/0/0 overload
!
!
!
dial-peer voice 1000 voip
description BANDWIDTH Incoming SIP and VOIP calls
 session protocol sipv2
session target sip-server
incoming called-number .
voice-class codec 1
  dtmf-relay rtp-nte sip-notify
no vad
!
dial-peer voice 4000 voip
description Local Dialing (10-Digit) to Bandwidth SIP Trunk
translation-profile outgoing OutgoingToBandwidthSIP
destination-pattern [2-9]..[2-9]..$
session protocol sipv2
session target ipv4:67.231.8.75
voice-class codec 1
 dtmf-relay rtp-nte
no vad
!
dial-peer voice 4001 voip
description LD Dialing (11-Digit) to Bandwidth SIP Trunk
translation-profile outgoing OutgoingToBandwidthSIP
destination-pattern 1[2-9]..[2-9]..$
session protocol sipv2
session target ipv4:67.231.8.75
voice-class codec 1
 dtmf-relay rtp-nte
no vad
!
dial-peer voice 2001 voip
description Incoming SIP Calls to CUCM Sub
translation-profile incoming LOCALIZE
destination-pattern [2-9]..[2-9]..$
session protocol sipv2
session target ipv4:192.168.1.20
voice-class codec 1
 no voice-class sip outbound-proxy
 dtmf-relay rtp-nte sip-notify
no vad
!
!
sip-ua
!


Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10


From: Ryan Huff mailto:ryanh...@outlook.com>>
Sent: Friday, August 10, 2018 10:04:54 PM
To: Benjamin Turner
Cc: Loren Hillukka; cisco-voip voyp list
Subject: Re: [cisco-voip] CUBE ignoring SDP responses from ITSP

Can I get a show tech or at least a show run?

Sent from my iPhone

On Aug 10, 2018, at 22:03, Benjamin Turner 
mailto:benmtur...@hotmail.com>> wrote:

Its an edge device no fw in place between cube and provider

Get Outlook for Android<https://aka.ms/ghei36>


From: Ryan Huff mailto:ryanh...@outlook.com>>
Sent: Friday, August 10, 2018 10:02:42 PM
To: Benjamin Turner
Cc: Loren Hillukka; cisco-voip voyp list
Subject: Re: [cisco-voip] CUBE ignoring SDP responses from ITSP

Is it a PA, ASA? Do you have inspection and ALG disabled on the firewall?

Sent from my iPhone

On Aug 10, 2018, at 22:00, Benjamin Turner 
mailto:benmtur...@hotmail.com>> wrote:

Sit in front of the fw

Get Outlook for Android<https://aka.ms/ghei36>


From: Loren Hillukka mailto:lchillu...@hotmail.com>>
Sent: Friday, August 10, 2018 9:58:49 PM
To: Benjamin Turner
Cc: Ryan Huff; cisco-voip voyp list
Subject: Re: [cisco-voip] CUBE ignoring SDP responses from ITSP

Any firewall in place there? I have seen firewalls modify/drop just enough to 
make the gateway not recognize a response.

Sent from my iPhone

On Aug 10, 2018, at 8:35 PM, Benjamin Turner 
mailto:benmtur...@hotmail.com>> wrote:

Yes, and my LAN side too



Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10


From: Ryan Huff mailto:ryanh...@outlook.com

Re: [cisco-voip] CUBE ignoring SDP responses from ITSP

[Loren Hillukka]

Any firewall in place there? I have seen firewalls modify/drop just enough to 
make the gateway not recognize a response.

Sent from my iPhone

On Aug 10, 2018, at 8:35 PM, Benjamin Turner 
mailto:benmtur...@hotmail.com>> wrote:

Yes, and my LAN side too



Sent from Mail for Windows 10


From: Ryan Huff mailto:ryanh...@outlook.com>>
Sent: Friday, August 10, 2018 9:33:49 PM
To: Benjamin Turner
Cc: Brian Meade; cisco-voip voyp list
Subject: Re: [cisco-voip] CUBE ignoring SDP responses from ITSP

So do you have all the correct signaling addresses from the provider included 
in the ipv4 trusted list (SIP ACL)?

Sent from my iPhone

On Aug 10, 2018, at 21:31, Benjamin Turner 
mailto:benmtur...@hotmail.com>> wrote:

A debug ccsip messages never sees these responses. Here is the monitor capture 
from the cube:



-
#   size   timestamp source destination   protocol
-
   0  9270.00   162.245.36.90->  67.231.8.75  UDP
  :  70E42202 57CB00B6 70707740 08004568   p.".w..@..eh
  0010:  0391 FF11 A472A2F5 245A43E7   .r..$ZC.
  0020:  084BF7D6 13C4037D C3C2494E 56495445   .K.}..INVITE
  0030:  20736970 3A313935 34363338 39303635sip:19546389065

   1  3630.043989   67.231.8.75  ->  162.245.36.90UDP
  :  00B67070 7740046C 9D59F3D0 08004548   ..p...@.l.yeh
  0010:  015DBFAA 40003311 731C43E7 084BA2F5   .]..@.3.s.C..K..
  0020:  245A13C4 13C40149 21EA5349 502F322E   $Z.I!.SIP/2.
  0030:  30203130 30205472 79696E67 0D0A5669   0 100 Trying..Vi

   2  9270.500026   162.245.36.90->  67.231.8.75  UDP
  :  70E42202 57CB00B6 70707740 08004568   p.".w..@..eh
  0010:  03910001 FF11 A471A2F5 245A43E7   .q..$ZC.
  0020:  084BF7D6 13C4037D C1C2494E 56495445   .K.}..INVITE
  0030:  20736970 3A313935 34363338 39303635sip:19546389065

   3  3630.544015   67.231.8.75  ->  162.245.36.90UDP
  :  00B67070 7740046C 9D59F3D0 08004548   ..p...@.l.yeh
  0010:  015DBFB1 40003311 731543E7 084BA2F5   .]..@.3.s.C..K..
  0020:  245A13C4 13C40149 21EA5349 502F322E   $Z.I!.SIP/2.
  0030:  30203130 30205472 79696E67 0D0A5669   0 100 Trying..Vi

   4  9271.500026   162.245.36.90->  67.231.8.75  UDP
  :  70E42202 57CB00B6 70707740 08004568   p.".w..@..eh
  0010:  03910002 FF11 A470A2F5 245A43E7   .p..$ZC.
  0020:  084BF7D6 13C4037D BFC2494E 56495445   .K.}..INVITE
  0030:  20736970 3A313935 34363338 39303635sip:19546389065

   5  3631.544015   67.231.8.75  ->  162.245.36.90UDP
  :  00B67070 7740046C 9D59F3D0 08004548   ..p...@.l.yeh
  0010:  015DC013 40003311 72B343E7 084BA2F5   .]..@.3.r.C..K..
  0020:  245A13C4 13C40149 21EA5349 502F322E   $Z.I!.SIP/2.
  0030:  30203130 30205472 79696E67 0D0A5669   0 100 Trying..Vi

   6  4392.289039   67.231.8.75  ->  162.245.36.90UDP
  :  00B67070 7740046C 9D59F3D0 08004548   ..p...@.l.yeh
  0010:  01A9C09D 40003311 71DD43E7 084BA2F5   @.3.q.C..K..
  0020:  245A13C4 13C40195 CADC5349 502F322E   $ZSIP/2.
  0030:  30203138 33205365 7373696F 6E205072   0 183 Session Pr

   7  9273.500026   162.245.36.90->  67.231.8.75  UDP
  :  70E42202 57CB00B6 70707740 08004568   p.".w..@..eh
  0010:  03910003 FF11 A46FA2F5 245A43E7   .o..$ZC.
  0020:  084BF7D6 13C4037D CECA494E 56495445   .K.}..INVITE
  0030:  20736970 3A313935 34363338 39303635sip:19546389065

   8  4393.544015   67.231.8.75  ->  162.245.36.90UDP
  :  00B67070 7740046C 9D59F3D0 08004548   ..p...@.l.yeh
  0010:  01A9C0D7 40003311 71A343E7 084BA2F5   @.3.q.C..K..
  0020:  245A13C4 13C40195 CADC5349 502F322E   $ZSIP/2.
  0030:  30203138 33205365 7373696F 6E205072   0 183 Session Pr

   9  9277.500026   162.245.36.90->  67.231.8.75  UDP
  :  70E42202 57CB00B6 70707740 08004568   p.".w..@..eh
  0010:  03910004 FF11 A46EA2F5 245A43E7   .n..$ZC.
  0020:  084BF7D6 13C4037D C6CA494E 56495445   .K.}..INVITE
  0030:  20736970 3A313935 34363338 39303635sip:19546389065

  10  4397.544015   67.231.8.75  ->  162.245.36.90UDP
  :  00B67070 7740046C 9D59F3D0 08004548   ..p...@.l.yeh
  0010:  01A9C17A 40003311 710043E7 084BA2F5   ...z@.3.q.C..K..
  0020:  245A13C4 13C40195 CADC5349 502F322E   $ZSIP/2.
  0030:  30203138 33205365 7373696F 6E205072   0 183 Session Pr

  11  789   10.953998   67.231.8.75  ->  162.245.36.90UDP
  :  00B67070 7740046C 9D59F3D0 08004548   ..p...@.l.yeh
  0010:  0307C459 40003311 6CC343E7 084BA2F5   ...Y@.3.l.C..K..
  0020:  245A13C4 13C402F3 36525349 502F322E   $Z..6RSIP/2.
  0030:  30203230 30204F4B 0D0A5669 613A2053   0 200 OK..Via: S

  12  789   11.454023   

Re: [cisco-voip] 7832 Real-time Device Status

[Loren Hillukka]

Sorry for the late response on this, but I have observed that in CUCM 9.1 at 
least, just cycling RIS DC service wasn’t enough.  
Cisco TAC gave us the following services to cycle on pub and all subs (one 
server at a time) which cleared up the issue:
Cisco CallManager Serviceability RTMT
Cisco RTMT Reporter Servlet
Cisco RIS Data Collector
Cisco AMC Service

Can be done during hours, no service impact that we observed. 

Loren

> On Jul 12, 2018, at 3:08 AM, Gary Parker  wrote:
> 
> 
> 
>> On 11 Jul 2018, at 23:20, Anthony Holloway  
>> wrote:
>> 
>> Put a piece of black tape on your monitor where the IP should be; that's 
>> what my dad did to fix the check engine light.
> 
> Well, we happened to have a complete shutdown of our datacenter last night, 
> which meant the whole cluster was rebooted, and it’s working properly today.
> 
> ¯\_(ツ)_/¯
> 
> Gary
> ___
> 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] anyone ever try SIP integration with these Crestron conference stations?

[Loren Hillukka]

Yes, 3rd party sip devices. Config the digest user correctly and they seem to 
work fairly well.

Sent from my iPhone

On Apr 11, 2018, at 6:16 PM, Lelio Fulgenzi 
> wrote:

From the image, it looks like they’re sip endpoints, not sip trunks.

Sent from my iPhone

On Apr 11, 2018, at 4:44 PM, Jonatan Quezada 
> wrote:


the guide is there too, What im curious about is , since i have functioning sip 
trunk with profile and all, can i provision another one like it seems to 
suggest. or is it rather a seperate trunk altogether for the creston device?



--
For immediate assistance please reach out to Chemeketa IT Help Desk at 
5033997899
-or-
Visit the help center from your employee dashboard found here:
https://dashboard.chemeketa.edu/helpcenter/default.aspx


Johnny Q
Voice Technology Analyst - TelNet
Chemeketa Community College
johnn...@chemeketa.edu
Building 22 Room 131
Work 5033995294
Mobile 9712182110
SIP 5035406686

___
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] Automated PSTN ingress call regression testing?

[Loren Hillukka]

Startrinity is a pretty awesome tool. Not free but has pretty amazing 
capabilities.

Loren

On Mar 8, 2018, at 2:17 PM, Wes Sisk (wsisk) 
> wrote:

I have seen Hammer used for inbound call verification before:

http://www.empirix.com/products/hammer/

-Wes

On Mar 8, 2018, at 3:13 PM, Nick Barnett 
> wrote:

Thanks. I am aware of the multiple carriers... but I think being able to cover 
the edge services would be a huge help in this situation. I'm just anticipating 
what they will ask for. I kind of cast a wide net with this email because I was 
not sure what kind of services were out there. If some provider offered a 
prepackaged, automated testing service that featured multiple carrier numbers, 
I'd buy it in an instant. I just need to remember baby steps :)

By "prone to issues", I just mean that it will test connected calls, but 
getting that next layer of "it connected, but is it working" would be 
difficult. Not necessarily "issues". I suppose "obstacles" would have been a 
better word.  The issues I see with the freePBX would be similar, but also 
includes perimeter security and things of that nature.

I don't have UCCX, but I'm fairly ok at cobbling together AXL and JTAPI to do 
some stuff... maybe I'll just start there since it's basically free.

On Wed, Mar 7, 2018 at 9:33 PM, Anthony Holloway 
> wrote:
Even if you do the Free IP PBX or Twilio API, you're only calling from one 
carrier.  In the scenario you described, you mentioned:

"Verizon wireless customers cannot call Sprint toll free numbers from area code 
555"

Which is very specific.  Would you imagine that you would have owned a 555 
number on Verizon to have caught that scenario faster?  What if the area code 
was 666?  Or the originating carrier was AT?  The different combinations you 
would have to account for are very high.

If you only care about your edge service and inward, and not far end carriers, 
then a Twilio API app sounds like a good plan.  Heck, you could even just write 
a UCCX script to call out and back in via tromboning off the PSTN.

I'm curious, what did you mean by "prone to issues," when referring to the API?

On Wed, Mar 7, 2018 at 1:57 PM Nick Barnett 
> wrote:
A client has a need for an off site solution that will make test calls to their 
numbers and report when there are issues. I understand that this is very vague, 
but they are interested in hearing about any and all solutions.

They have several SIP carriers and a nationwide presence, but the SIP trunking 
is centralized. They've had enough issues with one DID service failing and 
their customers having to report the issue. Ideally, the SIP providers would be 
able to automatically do "something" when they stop receiving options pings, or 
when a certain sip response is received... but it doesn't work that way with 
the behemoth phone companies.

The way it works now is that MOST issues are able to be caught successfully 
with internal monitoring... but others such certain NPA-NXX can't call another 
NPA-NXX, or carrier interconnects such as "Verizon wireless customers cannot 
call Sprint toll free numbers from area code 555"  These odd scenarios are what 
we are looking to solve. I understand this is potentially huge, but I think if 
we could automate calls to about 10 different numbers, that would cover enough 
of the ingress and carrier combinations that it would make a HUGE difference.

I've thought of spinning up an Asterisk and somehow automating the echo test 
feature. I've also thought about using the Twilio API to test if calls are 
successful. Both of these are complicated and prone to issues... so if there is 
a hosted or cloud solution that is already available, please let me know.

Any suggestions or more than welcome.

Thanks,
Nick
___
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] cisco-voip Digest, Vol 173, Issue 3

[Loren Hillukka]

Nice tips Adam. The failovers to active endpoints was a pain.  That retry 
invites 2 was a must - the default was 6. 

Loren 

> On Mar 5, 2018, at 1:14 PM, Pawlowski, Adam  wrote:
> 
> Ed,
> 
> Caveat on all this that I set this up a year or two ago so I could be wrong 
> on some parts:
> 
> This does DNS SRV lookup I believe first, then A. As long as you're in an IOS 
> version that supports SRV as that appeared somewhere in 15 I believe. We are 
> running 15.(4)3 M2.
> 
> I set up a number of SRV records to point at my UCM cluster, for example, and 
> then have the dial-peer set to:
> 
> session target dns:prod-all.cmgroup.subzone.zone.internal
> 
> I don't see that I have specified "session transport tcp" in this router but 
> this is a _SIP._TCP SRV record and it is up and running.
> 
> I will say that you want to be careful with using this with the 
> busyout/options ping. In my experience when it pulls the various SRV hosts, 
> with respect to preference and weight, it will pick the one it should be 
> using at any given point in time but it will not test all UCM nodes. It could 
> be possible to busyout the group if multiple failures were to occur for some 
> reason, even if other hosts are up, based on how IOS handles the responses to 
> this. I sort of recall watching it, and test #1 may go to subA which fails, 
> but then test #2 goes to subB so you're good. If you'd set the weighting 
> different you could knock the peer offline.
> 
> I think.
> 
> I know that in response to this behavior I did add this configuration to my 
> sip user agent configuration:
> 
> sip-ua
> retry invite 2
> timers trying 100
> !
> 
> This was to cause the router to try again (perhaps to a different peer) if it 
> failed to get anywhere with one. The defaults were too long for the call to 
> fail out to a particular peer before exceeding network timers and losing the 
> call. 
> 
> Best,
> 
> Adam Pawlowski
> SUNYAB NCS
> 
> ___
> 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] session target dns

[Loren Hillukka]

Local dns srv allowed priority and weight, whereas server-group only allowed 
priority, that I recall. Granted, you don't usually need weight, but some 
customers desired that option.
Either can be used, and server-groups do add some benefits (can see better 
up/down status, etc). Lately I have moved to using server-groups and it does 
cover most needs as well.
Don't remember any issues With TTL but then again I only recall one customer 
that pointed the DNS lookup to a central DNS server, and it broke when they had 
some AD activity going on that impacted DNS lookups and thus the call center. 
After that we decided to help customers protect themselves and we always 
implemented local dns srv on the gw.  Combining that with options ping (and use 
ping group if you have multiple dial-peers pointed to the same SIP endpoint!) 
really made failover/redundancy nice and quick.

Loren

On Mar 5, 2018, at 1:31 PM, Anthony Holloway 
<avholloway+cisco-v...@gmail.com<mailto:avholloway+cisco-v...@gmail.com>> wrote:

Loren,

Just out of curiosity, why didn't you just use session server groups?  Based on 
the config you shared, it looks like it would achieve the same thing, but with 
less config, and not adding in the DNS stack within IOS.

Ed,

*Note, you cannot use DNS in server groups, so it's one or the other.

I also think it's important to know that the IOS code is written such that it 
will look for SRV records first, and then fallback to looking for an A (host) 
record once the DNS timeouts.

E.g.,

You enter "session target dns:collab.domain.com<http://collab.domain.com>"

IOS looks for _sip._udp.collab.domain.com<http://udp.collab.domain.com> SRV 
record first, timesout, then looks for 
collab.domain.com<http://collab.domain.com> host record second.

*Note that the outgoing session transport on IOS is UDP by default, unless you 
change it to TCP with the command "session transport tcp" at the "voice service 
voip" level, or at the dial-peer level.  So, having a _sip._tcp SRV record on 
your CUBE would create a confusing scenario.  Contrast this with the incoming 
connection, which can be either.  However, SRV records, like Loren is showing, 
are for outbound connection establishments.

I have not done an extensive amount of testing here, but I would be curious to 
know if IOS handles the TTL for the DNS record correctly, or if it queries DNS 
for every setup like how that one defect was hitting CUCM SIP trunks for a 
while there.  I looked for "TTL" in the CVP Config guide, but it didn't say.

On Mon, Mar 5, 2018 at 11:19 AM Loren Hillukka 
<lchillu...@hotmail.com<mailto:lchillu...@hotmail.com>> wrote:
You can have your gw query your DNS server, and you have to add SRV records to 
your central DNS server (like with the jabber entries required to get jabber 
sign-in to work).
Here’s the example of doing local DNS to static entries on the gateway itself, 
from the CVP 10 config guide.  CVP is where I first started doing dns srv on 
the local gateway, as I preferred breaking the call center myself instead of 
having the AD/DNS teams do it for me without me knowing ;-)
===
You can also configure the Gateway statically instead of using DNS. The 
following example shows how both the A and SRV type records could be configured:
ip host cvp4cc2.cisco.com<http://cvp4cc2.cisco.com/> 10.4.33.132
ip host cvp4cc3.cisco.com<http://cvp4cc3.cisco.com/> 10.4.33.133
ip host cvp4cc1.cisco.com<http://cvp4cc1.cisco.com/> 10.4.33.131
For SIP/TCP:
ip host _sip._tcp.cvp.cisco.com<http://tcp.cvp.cisco.com/> srv 50 50 
5060<tel:50%2050%205060>cvp4cc3.cisco.com<http://cvp4cc3.cisco.com/>
ip host _sip._tcp.cvp.cisco.com<http://tcp.cvp.cisco.com/> srv 50 50 
5060<tel:50%2050%205060>cvp4cc2.cisco.com<http://cvp4cc2.cisco.com/>
ip host _sip._tcp.cvp.cisco.com<http://tcp.cvp.cisco.com/> srv 50 50 
5060<tel:50%2050%205060>cvp4cc1.cisco.com<http://cvp4cc1.cisco.com/>
For SIP/UDP:
ip host _sip._udp.cvp.cisco.com<http://udp.cvp.cisco.com/> srv 50 50 
5060<tel:50%2050%205060>cvp4cc3.cisco.com<http://cvp4cc3.cisco.com/>
ip host _sip._udp.cvp.cisco.com<http://udp.cvp.cisco.com/> srv 50 50 
5060<tel:50%2050%205060>cvp4cc2.cisco.com<http://cvp4cc2.cisco.com/>
ip host _sip._udp.cvp.cisco.com<http://udp.cvp.cisco.com/> srv 50 50 
5060<tel:50%2050%205060>cvp4cc1.cisco.com<http://cvp4cc1.cisco.com/>
 
Then your dial-peer would have session target 
dns:cvp.cisco.com<http://cvp.cisco.com/> which would point to the SRV record, 
which would use the weight/priority values to choose the final host, and 
resolve the selected host to an IP using the normal "ip host name x.x.x.x" entry


Loren

On Mar 5, 2018, at 10:15 AM, Ed Leatherman 
<ealeather...@gmail.com<mailto:ealeather...@gmail.com>> wrote:

Hi everyo

Re: [cisco-voip] session target dns

[Loren Hillukka]

You can have your gw query your DNS server, and you have to add SRV records to 
your central DNS server (like with the jabber entries required to get jabber 
sign-in to work).
Here’s the example of doing local DNS to static entries on the gateway itself, 
from the CVP 10 config guide.  CVP is where I first started doing dns srv on 
the local gateway, as I preferred breaking the call center myself instead of 
having the AD/DNS teams do it for me without me knowing ;-)
===
You can also configure the Gateway statically instead of using DNS. The 
following example shows how both the A and SRV type records could be configured:
ip host cvp4cc2.cisco.com 10.4.33.132
ip host cvp4cc3.cisco.com 10.4.33.133
ip host cvp4cc1.cisco.com 10.4.33.131
For SIP/TCP:
ip host _sip._tcp.cvp.cisco.com srv 50 50 
5060cvp4cc3.cisco.com
ip host _sip._tcp.cvp.cisco.com srv 50 50 
5060cvp4cc2.cisco.com
ip host _sip._tcp.cvp.cisco.com srv 50 50 
5060cvp4cc1.cisco.com
For SIP/UDP:
ip host _sip._udp.cvp.cisco.com srv 50 50 
5060cvp4cc3.cisco.com
ip host _sip._udp.cvp.cisco.com srv 50 50 
5060cvp4cc2.cisco.com
ip host _sip._udp.cvp.cisco.com srv 50 50 
5060cvp4cc1.cisco.com
 
Then your dial-peer would have session target 
dns:cvp.cisco.com which would point to the SRV record, 
which would use the weight/priority values to choose the final host, and 
resolve the selected host to an IP using the normal "ip host name x.x.x.x" entry


Loren

On Mar 5, 2018, at 10:15 AM, Ed Leatherman 
> wrote:

Hi everyone,

Hopefully a quick question - in a dial-peer on CUBE (16.3.5) how does session 
target dns: resolve to an IP? I've never used DNS as target before for this.

Does CUBE just do a query for the A record by default, or does it do a SRV 
query by default? I have a SIP provider that wants to start using SRV for their 
SBC(s) and I'm researching how to setup my end in IOS. If it doesn't query SRV 
default, where do I toggle that behavior?

The command reference just says  "Configures the host device housing the domain 
name system (DNS) server that resolves the name of the dial peer to receive 
calls."

I've found the knob to tell it what SRV format to use in the sip-ua section.

Thanks!



--
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] Cisco MediaSense get old recording calls

[Loren Hillukka]

Check the disk space used on the recording partition. If it is at 90%, 
Mediasense will prune regardless of your retention setting.

On Oct 30, 2017, at 4:52 PM, Claiton Campos 
> wrote:

Hi Chris,
The setting is for 365 days, as shown in the image below.



Best Regards,

2017-10-30 14:35 GMT-02:00 Chris Ward (chrward) 
>:
Hi Claiton,

MediaSense comes with default pruning settings that deletes older recordings 
based on age or available disk space. Are your settings set to 30 days? If so, 
those recordings have been deleted. Cisco doesn’t have any way to recover 
deleted recordings.





Chris Ward
ENGINEER.TECHNICAL MARKETING
chrw...@cisco.com
Tel: +1 408 894 3751

Cisco Systems, Inc.
500 Beaver Brook 
Road
BOXBOROUGH
01719
United States
cisco.com


Think before you print.

This email may contain confidential and privileged material for the sole use of 
the intended recipient. Any review, use, distribution or disclosure by others 
is strictly prohibited. If you are not the intended recipient (or authorized to 
receive for the recipient), please contact the sender by reply email and delete 
all copies of this message.
Please click 
here
 for Company Registration Information.


From: cisco-voip 
[mailto:cisco-voip-boun...@puck.nether.net]
 On Behalf Of Claiton Campos
Sent: Friday, October 27, 2017 1:52 PM
To: cisco-voip@puck.nether.net
Subject: [cisco-voip] Cisco MediaSense get old recording calls

Hello everyone,
I have a call recording environment being performed by MediaSense, but I can not
search for calls that have been recorded for more than 30 days. All calls are 
recorded in
local disk of MediaSense. Does anyone know how to rescue these files?

Best Regards,

___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-voip=02%7C01%7Casim_323%40hotmail.com%7C2edd564460d7474b379608d51fe0aa73%7C84df9e7fe9f640afb435%7C1%7C0%7C636449972159502553=fpvNJWcRT14HLZri%2BMggl6CmtJy51HT3g%2F1503WIoI0%3D=0
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

[cisco-voip] Call length on paging ports

[Loren Hillukka]

I have a plant building with a 4351 connected to a paging system via an FXO 
port.  Site has phones connected to CUCM, gw is not MGCP.  Users at the plant 
are notorious for paging, then pressing "hold" instead of "end call" on the 
Cisco phones they page from. The plant floor then gets MOH playing and nobody 
else can page until I shut/no shut the port or they unplug the cable from the 
fxo port. 

Any idea if a max length of call timer can be applied only to that one fxo 
port, to disconnect any call to it after 15 seconds or so? 

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