Re: [cisco-voip] List of SIP Internet Providers

[Ankur Srivastava via cisco-voip]

Hi Lelio,

It is always preferable to have a dedicated layer 3 connection with your
sip provider. This ensures you have proper QOS values propogated throughout
the network. Internet is a black hole, and sip calls can sound worse than
PRI.

Regards,
Ankur

On Sep 13, 2016 08:13, "Lelio Fulgenzi"  wrote:

>
> One question I have is whether people use SIP providers over their regular
> internet connection or do the get a SIP provider who provides layer 3 to
> the site?
>
>
>
> Sent from my iPhone
>
> On Sep 12, 2016, at 2:51 PM, Matt Slaga (AM) 
> wrote:
>
> Intelepeer
>
> Nextiva
>
> Sip.us 
>
> Etherspeak
>
> Megapath
>
> GoTrunk
>
> Broadvox
>
>
>
> Many others
>
>
>
> http://www.whichvoip.com/lp/top-business-sip-providers.
> htm?utm_source=bing_medium=cpc_term=sip%20trunk%20provider_
> content=STP_campaign=WhichVoIP%20SIP:SIP%20Trunking
>
>
>
>
>
>
>
> *From:* cisco-voip [mailto:cisco-voip-boun...@puck.nether.net
> ] *On Behalf Of *Clifford McGlamry
> *Sent:* Monday, September 12, 2016 11:07 AM
> *To:* John Huston 
> *Cc:* Cisco VoIP Group 
> *Subject:* Re: [cisco-voip] List of SIP Internet Providers
>
>
>
>
>
> I’ve been using voip.ms for some time.  They do a pretty good
> job.
>
>
>
> *Cliff*
>
>
>
>
>
>
>
> *From:* cisco-voip [mailto:cisco-voip-boun...@puck.nether.net
> ] *On Behalf Of *John Huston via
> cisco-voip
> *Sent:* Monday, September 12, 2016 10:55 AM
> *To:* Cisco Voip
> *Subject:* [cisco-voip] List of SIP Internet Providers
>
>
>
> I have been asked to look at moving our SIP trunks so they over the
> Internet.  An example of a company that does this in the US is
> bandwidth.com
>
>
>
> I am writing to find out if there is a list of other companies such as
> Bandwidth and if so where I could find it.  I have googled this and I am
> unable to find one.
>
>
>
> Thank you in advance for your help.
>
>
>
> John
>
>
>
> NOTICE OF CONFIDENTIALITY:
> The information contained in this email transmission is confidential
> information which may contain information that is legally privileged and
> prohibited from disclosure under applicable law or by contractual
> agreement. The information is intended solely for the use of the individual
> or entity named above.
> If you are not the intended recipient, you are hereby notified that any
> disclosure, copying, distribution or taking of any action in reliance on
> the contents of this email transmission is strictly prohibited.
> If you have received this email transmission in error, please notify us
> immediately by telephone to arrange for the return of the original
> transmission to us.
>
>
>
> itevomcid
>
> ___
> 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] List of SIP Internet Providers

[Lelio Fulgenzi]

One question I have is whether people use SIP providers over their regular 
internet connection or do the get a SIP provider who provides layer 3 to the 
site?



Sent from my iPhone

On Sep 12, 2016, at 2:51 PM, Matt Slaga (AM) 
> wrote:

Intelepeer
Nextiva
Sip.us
Etherspeak
Megapath
GoTrunk
Broadvox

Many others

http://www.whichvoip.com/lp/top-business-sip-providers.htm?utm_source=bing_medium=cpc_term=sip%20trunk%20provider_content=STP_campaign=WhichVoIP%20SIP:SIP%20Trunking



From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of 
Clifford McGlamry
Sent: Monday, September 12, 2016 11:07 AM
To: John Huston >
Cc: Cisco VoIP Group 
>
Subject: Re: [cisco-voip] List of SIP Internet Providers


I've been using voip.ms for some time.  They do a pretty good job.

Cliff



From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of John 
Huston via cisco-voip
Sent: Monday, September 12, 2016 10:55 AM
To: Cisco Voip
Subject: [cisco-voip] List of SIP Internet Providers

I have been asked to look at moving our SIP trunks so they over the Internet.  
An example of a company that does this in the US is 
bandwidth.com

I am writing to find out if there is a list of other companies such as 
Bandwidth and if so where I could find it.  I have googled this and I am unable 
to find one.

Thank you in advance for your help.

John


NOTICE OF CONFIDENTIALITY:
The information contained in this email transmission is confidential 
information which may contain information that is legally privileged and 
prohibited from disclosure under applicable law or by contractual agreement. 
The information is intended solely for the use of the individual or entity 
named above.
If you are not the intended recipient, you are hereby notified that any 
disclosure, copying, distribution or taking of any action in reliance on the 
contents of this email transmission is strictly prohibited.
If you have received this email transmission in error, please notify us 
immediately by telephone to arrange for the return of the original transmission 
to us.


itevomcid
___
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] Phone Fraud H.323

[Lelio Fulgenzi]

Oh, we definitely have dial-peers. Both inbound and outbound.

I'm concerned because of the earlier comment about not all DIDs being accounted 
for.

I'm pretty sure I have an "inward dial" config on each PRI. But not sure I have 
a num-exp for each.

I'll double check my configs and share.

Sent from my iPhone

On Sep 12, 2016, at 10:11 PM, Nick Britt 
> wrote:

Do a

Sh run all | sec dial-p

If you don't have any DP's in the config I would imagine you are OK.

On Monday, 12 September 2016, Lelio Fulgenzi 
> wrote:

Here's a question:

We're using PRIs w/ MGCP so I'm assuming we're not affected. However, we have 
SRST configured, which I believe uses H323.

Could this affect us as well?

Lelio

Sent from my iPhone

On Sep 11, 2016, at 8:46 PM, Lelio Fulgenzi 
> wrote:

+1 here. By default with (the older?) IOS if someone dialled a number 
associated with the line plugged into your router, you'd get dial tone and from 
there you could dial an number the dial plan allowed.



Sent from my iPhone

On Sep 11, 2016, at 11:49 AM, Nick Britt 
>
 wrote:

Hi David,

Can I ask Which version of IOS you are using?

Also could you post your incoming dial peer configuration or are you just using 
the default DP 0?

Ive experienced a similar issue before (luckily I didn't configure this 
particular deployment)

Before IOS 15 (I believe) direct in ward dial was not applied to the default 
dial peer. This allows people to call in on an unnnallocated number with in the 
DID range and receive a dial tone. (Check it out quite scary)

The resolution was to apply the command direct in wars dial to all incoming 
dial peers.

I will try and dig out the link from Cisco.



On Sunday, 11 September 2016, David Zhars 
> wrote:
So yesterday I was alerted by our landline company that some of our phone 
numbers that come in POTS on an H323 router, we being used for phone fraud.  I 
am wondering how this happens with an H323 router (I am familiar with someone 
hacking Unity and setting up actions to route to Jamaica once someone leaves a 
voicemail or similar).

The odd part is that these numbers are almost NEVER used for calling out, 
unless the user presses a 7 for an outbound line (versus an 8 which puts the 
call out on ISDN).

I found a link on how to disable OffNet calling in UCM, but should I instead 
look at securing the H323 router?  Or does the call blocking rule need to be 
done in UCM?

Thanks for any enlightenment you can provide.

PS- Client is in USA, call fraud to Jamaica which does not require a country 
code, so harder to block.


--
- 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


--
- Nick

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

Re: [cisco-voip] UCCX CUIC Reports Stopped Working After Certain Date

[Erick Bergquist]

Also, if you have any scheduled reports those may be stuck or failed (red
x).  If you rerun the scheduled reports after the fix that are stuck it
fixes them.

Wallboard servers or dashboards using the report functions effected will
also be impacted.


On Monday, September 12, 2016, Abhiram Kramadhati (akramadh) <
akram...@cisco.com> wrote:

> This impacts agent based reports and not just CUIC (can attempt 8.x as
> well). Reports we know:
> Agent Sumary
> Agent Not Ready State
> CAD email reports
>
> Best way to confirm if the report error is due to this issue is by running
> the corresponding SQL query on the UCCX CLI and verifying the error:
> *admin:run uccx sql db_cra {call sp_agent_summary('2016-09-10
> 07:00:00','2016-09-11 06:59:59','0',null,'John Doe,Dan
> Marino','Support',null,null,null,null,null,null,null,null,null,null,null)}*
>
> *Internal CLI Error: java.sql.SQLException: Overflow occurred on a
> datetime or interval operation.*
>
> The issue is triggered when the date is 8th September and later.
>
> Regards,
> Abhiram Kramadhati
> Technical Solutions Manager, CCBU
> CCIE Collaboration # 40065
>
> From:  > on behalf of Brian
> Meade >
> Date: Tuesday, 13 September 2016 at 11:50 AM
> To: Anthony Holloway  >
> Cc: akramadh  >, "
> cisco-voip@puck.nether.net
> " <
> cisco-voip@puck.nether.net
> >
> Subject: Re: [cisco-voip] UCCX CUIC Reports Stopped Working After Certain
> Date
>
> Agent Not Ready State report was the big one that hit our clients.  It's
> any report/stored procedure that utilizes the datediff function.
>
> Anything including a date after September 8th seemed to be an issue.
>
> On Mon, Sep 12, 2016 at 9:44 PM, Anthony Holloway <
> avholloway+cisco-v...@gmail.com
> >
> wrote:
>
>> So, should this be impacting every CUIC install in the world?  Does this
>> impact all reports or just some?  For the reports which are impacted, is
>> only when certain date filters are applied, or any filters?  Are there any
>> instances where a system wouldn't be impacted by reportgate?  I just ran
>> one random report on a 10.6(1)SU1 system, and I don't see a problem.
>>
>> On Mon, Sep 12, 2016 at 7:57 PM, Abhiram Kramadhati (akramadh) <
>> akram...@cisco.com >
>> wrote:
>>
>>> Hi all,
>>>
>>> There is a cop already available which has been provided to TAC. Only
>>> the CAD email reports are yet to be fixed, so we have a fix already there
>>> but just formalising it as a cop. We will have one cop released externally
>>> which will fix all the reports – the cop currently available fixes
>>> everything apart from CAD email reports. For that, please ask TAC for a
>>> manual workaround (there will be one cop very soon with all the fixes).
>>>
>>> A bit of context:
>>> There is a *datediff *function which calculates the time difference
>>> between today’s date and reference date. The reference date hardcoded
>>> is 1985-01-01 00:00:00 and starting from 8th September 2016, this
>>> difference is coming out to be a length that cannot be handled by the
>>> variable supposed to be storing it.
>>>
>>> This will be fixed and cop will be available. This cop should be
>>> installed on both the nodes via CLI and requires no restarts.
>>>
>>> Apologies, I am on travel – was meaning to send a heads-up when this got
>>> highlighted. Please feel free to reach out in case you are having
>>> challenges. Thank you.
>>>
>>> Regards,
>>> Abhiram Kramadhati
>>> Technical Solutions Manager, CCBU
>>> CCIE Collaboration # 40065
>>>
>>> From: cisco-voip >> >
>>> on behalf of Erick Bergquist >> >
>>> Date: Tuesday, 13 September 2016 at 7:30 AM
>>> To: Lelio Fulgenzi >> >
>>> Cc: "cisco-voip@puck.nether.net
>>> " <
>>> cisco-voip@puck.nether.net
>>> >
>>> Subject: Re: [cisco-voip] UCCX CUIC Reports Stopped Working After
>>> Certain Date
>>>
>>> Ran into this Friday. One client reported it then a few others and knew
>>> something weird was going on. Called it the 9/9 bug and worked with TAC and
>>> they had workaround ready to apply.
>>>
>>>
>>> On Monday, September 12, 2016, Lelio Fulgenzi >> 

Re: [cisco-voip] Phone Fraud H.323

[Nick Britt]

Do a

Sh run all | sec dial-p

If you don't have any DP's in the config I would imagine you are OK.

On Monday, 12 September 2016, Lelio Fulgenzi  wrote:

>
> Here's a question:
>
> We're using PRIs w/ MGCP so I'm assuming we're not affected. However, we
> have SRST configured, which I believe uses H323.
>
> Could this affect us as well?
>
> Lelio
>
> Sent from my iPhone
>
> On Sep 11, 2016, at 8:46 PM, Lelio Fulgenzi  > wrote:
>
> +1 here. By default with (the older?) IOS if someone dialled a number
> associated with the line plugged into your router, you'd get dial tone and
> from there you could dial an number the dial plan allowed.
>
>
>
> Sent from my iPhone
>
> On Sep 11, 2016, at 11:49 AM, Nick Britt  > wrote:
>
> Hi David,
>
> Can I ask Which version of IOS you are using?
>
> Also could you post your incoming dial peer configuration or are you just
> using the default DP 0?
>
> Ive experienced a similar issue before (luckily I didn't configure this
> particular deployment)
>
> Before IOS 15 (I believe) direct in ward dial was not applied to the
> default dial peer. This allows people to call in on an unnnallocated number
> with in the DID range and receive a dial tone. (Check it out quite scary)
>
> The resolution was to apply the command direct in wars dial to all
> incoming dial peers.
>
> I will try and dig out the link from Cisco.
>
>
>
> On Sunday, 11 September 2016, David Zhars  > wrote:
>
>> So yesterday I was alerted by our landline company that some of our phone
>> numbers that come in POTS on an H323 router, we being used for phone
>> fraud.  I am wondering how this happens with an H323 router (I am familiar
>> with someone hacking Unity and setting up actions to route to Jamaica once
>> someone leaves a voicemail or similar).
>>
>> The odd part is that these numbers are almost NEVER used for calling out,
>> unless the user presses a 7 for an outbound line (versus an 8 which puts
>> the call out on ISDN).
>>
>> I found a link on how to disable OffNet calling in UCM, but should I
>> instead look at securing the H323 router?  Or does the call blocking rule
>> need to be done in UCM?
>>
>> Thanks for any enlightenment you can provide.
>>
>> PS- Client is in USA, call fraud to Jamaica which does not require a
>> country code, so harder to block.
>>
>
>
> --
> - 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
>
>

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

Re: [cisco-voip] UCCX CUIC Reports Stopped Working After Certain Date

[Abhiram Kramadhati (akramadh)]

This impacts agent based reports and not just CUIC (can attempt 8.x as well). 
Reports we know:
Agent Sumary
Agent Not Ready State
CAD email reports

Best way to confirm if the report error is due to this issue is by running the 
corresponding SQL query on the UCCX CLI and verifying the error:
admin:run uccx sql db_cra {call sp_agent_summary('2016-09-10 
07:00:00','2016-09-11 06:59:59','0',null,'John Doe,Dan 
Marino','Support',null,null,null,null,null,null,null,null,null,null,null)}

Internal CLI Error: java.sql.SQLException: Overflow occurred on a datetime or 
interval operation.

The issue is triggered when the date is 8th September and later.

Regards,
Abhiram Kramadhati
Technical Solutions Manager, CCBU
CCIE Collaboration # 40065

From: > on behalf of Brian Meade 
>
Date: Tuesday, 13 September 2016 at 11:50 AM
To: Anthony Holloway 
>
Cc: akramadh >, 
"cisco-voip@puck.nether.net" 
>
Subject: Re: [cisco-voip] UCCX CUIC Reports Stopped Working After Certain Date

Agent Not Ready State report was the big one that hit our clients.  It's any 
report/stored procedure that utilizes the datediff function.

Anything including a date after September 8th seemed to be an issue.

On Mon, Sep 12, 2016 at 9:44 PM, Anthony Holloway 
> wrote:
So, should this be impacting every CUIC install in the world?  Does this impact 
all reports or just some?  For the reports which are impacted, is only when 
certain date filters are applied, or any filters?  Are there any instances 
where a system wouldn't be impacted by reportgate?  I just ran one random 
report on a 10.6(1)SU1 system, and I don't see a problem.

On Mon, Sep 12, 2016 at 7:57 PM, Abhiram Kramadhati (akramadh) 
> wrote:
Hi all,

There is a cop already available which has been provided to TAC. Only the CAD 
email reports are yet to be fixed, so we have a fix already there but just 
formalising it as a cop. We will have one cop released externally which will 
fix all the reports – the cop currently available fixes everything apart from 
CAD email reports. For that, please ask TAC for a manual workaround (there will 
be one cop very soon with all the fixes).

A bit of context:
There is a datediff function which calculates the time difference between 
today’s date and reference date. The reference date hardcoded is 1985-01-01 
00:00:00 and starting from 8th September 2016, this difference is coming out to 
be a length that cannot be handled by the variable supposed to be storing it.

This will be fixed and cop will be available. This cop should be installed on 
both the nodes via CLI and requires no restarts.

Apologies, I am on travel – was meaning to send a heads-up when this got 
highlighted. Please feel free to reach out in case you are having challenges. 
Thank you.

Regards,
Abhiram Kramadhati
Technical Solutions Manager, CCBU
CCIE Collaboration # 40065

From: cisco-voip 
> 
on behalf of Erick Bergquist >
Date: Tuesday, 13 September 2016 at 7:30 AM
To: Lelio Fulgenzi >
Cc: "cisco-voip@puck.nether.net" 
>
Subject: Re: [cisco-voip] UCCX CUIC Reports Stopped Working After Certain Date

Ran into this Friday. One client reported it then a few others and knew 
something weird was going on. Called it the 9/9 bug and worked with TAC and 
they had workaround ready to apply.


On Monday, September 12, 2016, Lelio Fulgenzi 
> wrote:
Yup. Affecting our installation of historical reporting. Not just cuic.

Sent from my iPhone

On Sep 12, 2016, at 3:25 PM, Brian Meade  wrote:

This issue seems to be affecting everyone.

Bug ID is CSCvb27878 but not publicly visible yet.

There is a COP file fix available from TAC that doesn't require a reboot or 
anything.

I'm sure there's a field notice coming soon.  I'm guessing the COP file will be 
on cisco.com soon as well if you don't mind waiting.

More discussion- 
https://supportforums.cisco.com/discussion/13118806/cuic-uccx-dataset-status-failed-database-error
___
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

Re: [cisco-voip] UCCX CUIC Reports Stopped Working After Certain Date

[Brian Meade]

Agent Not Ready State report was the big one that hit our clients.  It's
any report/stored procedure that utilizes the datediff function.

Anything including a date after September 8th seemed to be an issue.

On Mon, Sep 12, 2016 at 9:44 PM, Anthony Holloway <
avholloway+cisco-v...@gmail.com> wrote:

> So, should this be impacting every CUIC install in the world?  Does this
> impact all reports or just some?  For the reports which are impacted, is
> only when certain date filters are applied, or any filters?  Are there any
> instances where a system wouldn't be impacted by reportgate?  I just ran
> one random report on a 10.6(1)SU1 system, and I don't see a problem.
>
> On Mon, Sep 12, 2016 at 7:57 PM, Abhiram Kramadhati (akramadh) <
> akram...@cisco.com> wrote:
>
>> Hi all,
>>
>> There is a cop already available which has been provided to TAC. Only the
>> CAD email reports are yet to be fixed, so we have a fix already there but
>> just formalising it as a cop. We will have one cop released externally
>> which will fix all the reports – the cop currently available fixes
>> everything apart from CAD email reports. For that, please ask TAC for a
>> manual workaround (there will be one cop very soon with all the fixes).
>>
>> A bit of context:
>> There is a *datediff *function which calculates the time difference
>> between today’s date and reference date. The reference date hardcoded
>> is 1985-01-01 00:00:00 and starting from 8th September 2016, this
>> difference is coming out to be a length that cannot be handled by the
>> variable supposed to be storing it.
>>
>> This will be fixed and cop will be available. This cop should be
>> installed on both the nodes via CLI and requires no restarts.
>>
>> Apologies, I am on travel – was meaning to send a heads-up when this got
>> highlighted. Please feel free to reach out in case you are having
>> challenges. Thank you.
>>
>> Regards,
>> Abhiram Kramadhati
>> Technical Solutions Manager, CCBU
>> CCIE Collaboration # 40065
>>
>> From: cisco-voip  on behalf of Erick
>> Bergquist 
>> Date: Tuesday, 13 September 2016 at 7:30 AM
>> To: Lelio Fulgenzi 
>> Cc: "cisco-voip@puck.nether.net" 
>> Subject: Re: [cisco-voip] UCCX CUIC Reports Stopped Working After
>> Certain Date
>>
>> Ran into this Friday. One client reported it then a few others and knew
>> something weird was going on. Called it the 9/9 bug and worked with TAC and
>> they had workaround ready to apply.
>>
>>
>> On Monday, September 12, 2016, Lelio Fulgenzi  wrote:
>>
>>> Yup. Affecting our installation of historical reporting. Not just cuic.
>>>
>>> Sent from my iPhone
>>>
>>> On Sep 12, 2016, at 3:25 PM, Brian Meade  wrote:
>>>
>>> This issue seems to be affecting everyone.
>>>
>>> Bug ID is CSCvb27878 but not publicly visible yet.
>>>
>>> There is a COP file fix available from TAC that doesn't require a reboot
>>> or anything.
>>>
>>> I'm sure there's a field notice coming soon.  I'm guessing the COP file
>>> will be on cisco.com soon as well if you don't mind waiting.
>>>
>>> More discussion- https://supportforums.cisco.com/discussion/13118
>>> 806/cuic-uccx-dataset-status-failed-database-error
>>>
>>> ___
>>> 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] UCCX CUIC Reports Stopped Working After Certain Date

[Anthony Holloway]

So, should this be impacting every CUIC install in the world?  Does this
impact all reports or just some?  For the reports which are impacted, is
only when certain date filters are applied, or any filters?  Are there any
instances where a system wouldn't be impacted by reportgate?  I just ran
one random report on a 10.6(1)SU1 system, and I don't see a problem.

On Mon, Sep 12, 2016 at 7:57 PM, Abhiram Kramadhati (akramadh) <
akram...@cisco.com> wrote:

> Hi all,
>
> There is a cop already available which has been provided to TAC. Only the
> CAD email reports are yet to be fixed, so we have a fix already there but
> just formalising it as a cop. We will have one cop released externally
> which will fix all the reports – the cop currently available fixes
> everything apart from CAD email reports. For that, please ask TAC for a
> manual workaround (there will be one cop very soon with all the fixes).
>
> A bit of context:
> There is a *datediff *function which calculates the time difference
> between today’s date and reference date. The reference date hardcoded
> is 1985-01-01 00:00:00 and starting from 8th September 2016, this
> difference is coming out to be a length that cannot be handled by the
> variable supposed to be storing it.
>
> This will be fixed and cop will be available. This cop should be installed
> on both the nodes via CLI and requires no restarts.
>
> Apologies, I am on travel – was meaning to send a heads-up when this got
> highlighted. Please feel free to reach out in case you are having
> challenges. Thank you.
>
> Regards,
> Abhiram Kramadhati
> Technical Solutions Manager, CCBU
> CCIE Collaboration # 40065
>
> From: cisco-voip  on behalf of Erick
> Bergquist 
> Date: Tuesday, 13 September 2016 at 7:30 AM
> To: Lelio Fulgenzi 
> Cc: "cisco-voip@puck.nether.net" 
> Subject: Re: [cisco-voip] UCCX CUIC Reports Stopped Working After Certain
> Date
>
> Ran into this Friday. One client reported it then a few others and knew
> something weird was going on. Called it the 9/9 bug and worked with TAC and
> they had workaround ready to apply.
>
>
> On Monday, September 12, 2016, Lelio Fulgenzi  wrote:
>
>> Yup. Affecting our installation of historical reporting. Not just cuic.
>>
>> Sent from my iPhone
>>
>> On Sep 12, 2016, at 3:25 PM, Brian Meade  wrote:
>>
>> This issue seems to be affecting everyone.
>>
>> Bug ID is CSCvb27878 but not publicly visible yet.
>>
>> There is a COP file fix available from TAC that doesn't require a reboot
>> or anything.
>>
>> I'm sure there's a field notice coming soon.  I'm guessing the COP file
>> will be on cisco.com soon as well if you don't mind waiting.
>>
>> More discussion- https://supportforums.cisco.com/discussion/
>> 13118806/cuic-uccx-dataset-status-failed-database-error
>>
>> ___
>> 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] UCCX CUIC Reports Stopped Working After Certain Date

[Abhiram Kramadhati (akramadh)]

Hi all,

There is a cop already available which has been provided to TAC. Only the CAD 
email reports are yet to be fixed, so we have a fix already there but just 
formalising it as a cop. We will have one cop released externally which will 
fix all the reports - the cop currently available fixes everything apart from 
CAD email reports. For that, please ask TAC for a manual workaround (there will 
be one cop very soon with all the fixes).

A bit of context:
There is a datediff function which calculates the time difference between 
today's date and reference date. The reference date hardcoded is 1985-01-01 
00:00:00 and starting from 8th September 2016, this difference is coming out to 
be a length that cannot be handled by the variable supposed to be storing it.

This will be fixed and cop will be available. This cop should be installed on 
both the nodes via CLI and requires no restarts.

Apologies, I am on travel - was meaning to send a heads-up when this got 
highlighted. Please feel free to reach out in case you are having challenges. 
Thank you.

Regards,
Abhiram Kramadhati
Technical Solutions Manager, CCBU
CCIE Collaboration # 40065

From: cisco-voip 
> 
on behalf of Erick Bergquist >
Date: Tuesday, 13 September 2016 at 7:30 AM
To: Lelio Fulgenzi >
Cc: "cisco-voip@puck.nether.net" 
>
Subject: Re: [cisco-voip] UCCX CUIC Reports Stopped Working After Certain Date

Ran into this Friday. One client reported it then a few others and knew 
something weird was going on. Called it the 9/9 bug and worked with TAC and 
they had workaround ready to apply.


On Monday, September 12, 2016, Lelio Fulgenzi 
> wrote:
Yup. Affecting our installation of historical reporting. Not just cuic.

Sent from my iPhone

On Sep 12, 2016, at 3:25 PM, Brian Meade 
> wrote:

This issue seems to be affecting everyone.

Bug ID is CSCvb27878 but not publicly visible yet.

There is a COP file fix available from TAC that doesn't require a reboot or 
anything.

I'm sure there's a field notice coming soon.  I'm guessing the COP file will be 
on cisco.com soon as well if you don't mind waiting.

More discussion- 
https://supportforums.cisco.com/discussion/13118806/cuic-uccx-dataset-status-failed-database-error
___
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] Phone Fraud H.323

[Lelio Fulgenzi]

Here's a question:

We're using PRIs w/ MGCP so I'm assuming we're not affected. However, we have 
SRST configured, which I believe uses H323.

Could this affect us as well?

Lelio

Sent from my iPhone

On Sep 11, 2016, at 8:46 PM, Lelio Fulgenzi 
> wrote:

+1 here. By default with (the older?) IOS if someone dialled a number 
associated with the line plugged into your router, you'd get dial tone and from 
there you could dial an number the dial plan allowed.



Sent from my iPhone

On Sep 11, 2016, at 11:49 AM, Nick Britt 
> wrote:

Hi David,

Can I ask Which version of IOS you are using?

Also could you post your incoming dial peer configuration or are you just using 
the default DP 0?

Ive experienced a similar issue before (luckily I didn't configure this 
particular deployment)

Before IOS 15 (I believe) direct in ward dial was not applied to the default 
dial peer. This allows people to call in on an unnnallocated number with in the 
DID range and receive a dial tone. (Check it out quite scary)

The resolution was to apply the command direct in wars dial to all incoming 
dial peers.

I will try and dig out the link from Cisco.



On Sunday, 11 September 2016, David Zhars 
> wrote:
So yesterday I was alerted by our landline company that some of our phone 
numbers that come in POTS on an H323 router, we being used for phone fraud.  I 
am wondering how this happens with an H323 router (I am familiar with someone 
hacking Unity and setting up actions to route to Jamaica once someone leaves a 
voicemail or similar).

The odd part is that these numbers are almost NEVER used for calling out, 
unless the user presses a 7 for an outbound line (versus an 8 which puts the 
call out on ISDN).

I found a link on how to disable OffNet calling in UCM, but should I instead 
look at securing the H323 router?  Or does the call blocking rule need to be 
done in UCM?

Thanks for any enlightenment you can provide.

PS- Client is in USA, call fraud to Jamaica which does not require a country 
code, so harder to block.


--
- 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

Re: [cisco-voip] UCCX CUIC Reports Stopped Working After Certain Date

[Erick Bergquist]

Ran into this Friday. One client reported it then a few others and knew
something weird was going on. Called it the 9/9 bug and worked with TAC and
they had workaround ready to apply.


On Monday, September 12, 2016, Lelio Fulgenzi  wrote:

> Yup. Affecting our installation of historical reporting. Not just cuic.
>
> Sent from my iPhone
>
> On Sep 12, 2016, at 3:25 PM, Brian Meade  > wrote:
>
> This issue seems to be affecting everyone.
>
> Bug ID is CSCvb27878 but not publicly visible yet.
>
> There is a COP file fix available from TAC that doesn't require a reboot
> or anything.
>
> I'm sure there's a field notice coming soon.  I'm guessing the COP file
> will be on cisco.com soon as well if you don't mind waiting.
>
> More discussion- https://supportforums.cisco.com/
> discussion/13118806/cuic-uccx-dataset-status-failed-database-error
>
> ___
> 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] UCCX CUIC Reports Stopped Working After Certain Date

[Lelio Fulgenzi]

Yup. Affecting our installation of historical reporting. Not just cuic.

Sent from my iPhone

On Sep 12, 2016, at 3:25 PM, Brian Meade 
> wrote:

This issue seems to be affecting everyone.

Bug ID is CSCvb27878 but not publicly visible yet.

There is a COP file fix available from TAC that doesn't require a reboot or 
anything.

I'm sure there's a field notice coming soon.  I'm guessing the COP file will be 
on cisco.com soon as well if you don't mind waiting.

More discussion- 
https://supportforums.cisco.com/discussion/13118806/cuic-uccx-dataset-status-failed-database-error
___
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] UCCX CUIC Reports Stopped Working After Certain Date

[Damisch, Kevin]

I applied the cop file to 3 customers over the weekend and can confirm that it 
is a quick fix.  There are no service restarts, reboots, or anything, so there 
is absolutely no reason to wait until afterhours.  If you are a partner or work 
with multiple customers, you better grab the cop file and keep it handy for a 
while as you'll likely need it as customers are going to call you when they try 
to run the CUIC reports that contains dates beyond 9/9 and run into that error. 
 It affects all releases of UCCX 8/9/10/11.

Thanks,
Kevin

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of 
Stephen Welsh
Sent: Monday, September 12, 2016 2:36 PM
To: Brian Meade 
Cc: cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] UCCX CUIC Reports Stopped Working After Certain Date

Brian,

Thank you for this, we had an customer install our WallboardFX product and 
co-incdently hit this issue and thought our product may have been to blame (not 
technically possibly anyway), however not only could we clarify that it was a 
co-incidence this helps the customer to get to the bottom of the issue a lot 
quicker.

Your Cisco TAC Bug search skills are truly legendary, if we get the chance to 
cross paths at Cisco Live you get our best swag ;)

Kind Regards

Stephen Welsh
CTO
UnifiedFX

On 12 Sep 2016, at 20:24, Brian Meade > 
wrote:

This issue seems to be affecting everyone.

Bug ID is CSCvb27878 but not publicly visible yet.

There is a COP file fix available from TAC that doesn't require a reboot or 
anything.

I'm sure there's a field notice coming soon.  I'm guessing the COP file will be 
on cisco.com soon as well if you don't mind waiting.

More discussion- 
https://supportforums.cisco.com/discussion/13118806/cuic-uccx-dataset-status-failed-database-error
___
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] UCCX CUIC Reports Stopped Working After Certain Date

[Stephen Welsh]

Brian,

Thank you for this, we had an customer install our WallboardFX product and 
co-incdently hit this issue and thought our product may have been to blame (not 
technically possibly anyway), however not only could we clarify that it was a 
co-incidence this helps the customer to get to the bottom of the issue a lot 
quicker.

Your Cisco TAC Bug search skills are truly legendary, if we get the chance to 
cross paths at Cisco Live you get our best swag ;)

Kind Regards

Stephen Welsh
CTO
UnifiedFX

On 12 Sep 2016, at 20:24, Brian Meade > 
wrote:

This issue seems to be affecting everyone.

Bug ID is CSCvb27878 but not publicly visible yet.

There is a COP file fix available from TAC that doesn't require a reboot or 
anything.

I'm sure there's a field notice coming soon.  I'm guessing the COP file will be 
on cisco.com soon as well if you don't mind waiting.

More discussion- 
https://supportforums.cisco.com/discussion/13118806/cuic-uccx-dataset-status-failed-database-error
___
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] UCCX CUIC Reports Stopped Working After Certain Date

[Jose Colon II]

I hit this issue on Friday and TAC got back to me today with that COP file
as a fix with no reboot required. I will however wait until after hours of
course.

Certain reports were not able to be run with the "TODAY" parameter selected
as the time frame. It would give the error.

On Sep 12, 2016 2:27 PM, "Brian Meade"  wrote:

> Looks like the COP file is now posted on the supportforums post.
>
> On Mon, Sep 12, 2016 at 3:24 PM, Brian Meade  wrote:
>
>> This issue seems to be affecting everyone.
>>
>> Bug ID is CSCvb27878 but not publicly visible yet.
>>
>> There is a COP file fix available from TAC that doesn't require a reboot
>> or anything.
>>
>> I'm sure there's a field notice coming soon.  I'm guessing the COP file
>> will be on cisco.com soon as well if you don't mind waiting.
>>
>> More discussion- https://supportforums.cisco.com/discussion/
>> 13118806/cuic-uccx-dataset-status-failed-database-error
>>
>
>
> ___
> 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 CUIC Reports Stopped Working After Certain Date

[Brian Meade]

This issue seems to be affecting everyone.

Bug ID is CSCvb27878 but not publicly visible yet.

There is a COP file fix available from TAC that doesn't require a reboot or
anything.

I'm sure there's a field notice coming soon.  I'm guessing the COP file
will be on cisco.com soon as well if you don't mind waiting.

More discussion-
https://supportforums.cisco.com/discussion/13118806/cuic-uccx-dataset-status-failed-database-error
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

[cisco-voip] CUCM 11 BAT String index out of range: -13

[Jonathan Charles]

Any time I select phones to bulk change, I get the following error:

SEP003131798793 String index out of range: -13

For all of them.

These are Cisco 8811s

CUCM verrsion is 11.0.1.21900-11


There are other bugs with this error, but related to super copy.


Any ideas or a workaround?



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

Re: [cisco-voip] List of SIP Internet Providers

[Matt Slaga (AM)]

Intelepeer
Nextiva
Sip.us
Etherspeak
Megapath
GoTrunk
Broadvox

Many others

http://www.whichvoip.com/lp/top-business-sip-providers.htm?utm_source=bing_medium=cpc_term=sip%20trunk%20provider_content=STP_campaign=WhichVoIP%20SIP:SIP%20Trunking



From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of 
Clifford McGlamry
Sent: Monday, September 12, 2016 11:07 AM
To: John Huston 
Cc: Cisco VoIP Group 
Subject: Re: [cisco-voip] List of SIP Internet Providers


I’ve been using voip.ms for some time.  They do a pretty good job.

Cliff



From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of John 
Huston via cisco-voip
Sent: Monday, September 12, 2016 10:55 AM
To: Cisco Voip
Subject: [cisco-voip] List of SIP Internet Providers

I have been asked to look at moving our SIP trunks so they over the Internet.  
An example of a company that does this in the US is bandwidth.com

I am writing to find out if there is a list of other companies such as 
Bandwidth and if so where I could find it.  I have googled this and I am unable 
to find one.

Thank you in advance for your help.

John


NOTICE OF CONFIDENTIALITY:
The information contained in this email transmission is confidential 
information which may contain information that is legally privileged and 
prohibited from disclosure under applicable law or by contractual agreement. 
The information is intended solely for the use of the individual or entity 
named above.
If you are not the intended recipient, you are hereby notified that any 
disclosure, copying, distribution or taking of any action in reliance on the 
contents of this email transmission is strictly prohibited.
If you have received this email transmission in error, please notify us 
immediately by telephone to arrange for the return of the original transmission 
to us.


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

Re: [cisco-voip] Phone Fraud H.323

[Ryan Ratliff (rratliff)]

Have you checked your UCM CDR records to see where calls to those numbers are 
coming from?

With an internal IP and only FXO ports the most likely source is a Unity 
Connection mailbox with a forwarding rule or something similarly shady.

Tracking the calls inside your network is going to be key to finding out how 
they are getting triggered.

Unless you have a business need to call Jamaica I’d also start by outright 
blocking calls to area code 876 at that router.

-Ryan

On Sep 12, 2016, at 8:57 AM, David Zhars 
> wrote:

Hey Ryan,

The telco said these POTS lines (four of them) were being used to dial Jamaica. 
 The router has 4 FXO ports.  For some reason, they were leaving the fourth 
line alone, though the telco felt that wouldn't last long.
The router only has an internal non-routable IP addy.
Only processes H.323 (but does allow telnet and SNMP)
I don't know what PSTN egress means.  Sorry!

On Sun, Sep 11, 2016 at 11:49 AM, Ryan Huff 
> wrote:

Hi David,


  *   Did the telco say that the calls were originated from your POTS trunks or 
were they responding to customer complaints that one of your numbers had been 
reported to them for fraud ... etc?
  *   Does this router have a public Internet facing interface?
  *   Does this router process any other signaling protocols besides H.323?
  *   You mentioned having Unity / Unity Connections ... are you allowing PSTN 
egress from Unity Connections / have you verified the restriction tables are 
correct?

There are a number of things you could do on either side (UCM / Gateway). To 
cover the gap for the interim, I would at least deal with the specific called 
numbers that the telco gave you. In UCM, you could create specific route 
patterns in the egress path that do not route the match. On the gateway, you 
could use voice translation rules to try and reject the call attempt or 
translate the number to something the carrier won't route. You could also 
create specific dial-peers for the called numbers that do not route to anything.


This reminds me of a time I had this issue (and I was a bit less mature); I 
created dial-peers on the CUBE that matched the 'bad' called numbers and I 
routed them back into CCM->CTIRp->CUC and had a small sample of Rick Astley's, 
"Never Gonna Give You Up" playing as the opening greeting to a System Call 
Handler  ahhh the younger days 


ANYWAYS 


I would say, in my experience, this sort of thing typically comes from the 
outside in. In cases where CUBE has a public Internet facing interface, usually 
someone finds something open on CUBE, sends some signaling that matches a 
dial-peer and off it goes. In this case you'd want to look at some outside ACLs 
or putting a firewall between the public Internet and the CUBE. If your CUBE 
does not face the Internet or is on a private network like MPLS ... that is 
much less likely to be the case and you want to start looking elsewhere on the 
network.


I have seen bot dialers/Probers like 'SIPVicious' 
(Cisco even has an advisory about 
it) be able 
to access CUBE from the inside while installed on an infected PC. Granted, this 
tool is for SIP, but similar tools exist for h.323.


Thanks,

Ryan


From: cisco-voip 
> 
on behalf of David Zhars >
Sent: Sunday, September 11, 2016 9:37 AM
To: cisco-voip@puck.nether.net
Subject: [cisco-voip] Phone Fraud H.323

So yesterday I was alerted by our landline company that some of our phone 
numbers that come in POTS on an H323 router, we being used for phone fraud.  I 
am wondering how this happens with an H323 router (I am familiar with someone 
hacking Unity and setting up actions to route to Jamaica once someone leaves a 
voicemail or similar).

The odd part is that these numbers are almost NEVER used for calling out, 
unless the user presses a 7 for an outbound line (versus an 8 which puts the 
call out on ISDN).

I found a link on how to disable OffNet calling in UCM, but should I instead 
look at securing the H323 router?  Or does the call blocking rule need to be 
done in UCM?

Thanks for any enlightenment you can provide.

PS- Client is in USA, call fraud to Jamaica which does not require a country 
code, so harder to block.

___
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 10.5 version

[Ryan Huff]

That's what I get for not reading more closely ;)

Sent from my iPhone

On Sep 12, 2016, at 11:45 AM, Ovidiu Popa 
> wrote:

For it to be an SU it should have the last three digits in the range 900-999.
It's an ES :
(zzz) FCS:000, ES: 001-899, SU: 900-999

On Mon, Sep 12, 2016 at 5:39 PM, Ryan Huff 
> wrote:
So I imagine it is SU4 ... I was just wondering why it is not listed on CCO. 
There have been times, where a new release is listed but then removed due to 
deferment.

On Sep 12, 2016, at 11:18 AM, Ovidiu Popa 
> wrote:

Hello

I found this in an old Cisco live presentation. HTH

Numbering Convention Example
(A.B.C.XYzzz-x)
(A) Major version (License)
8.6.2.2-2
(B) Minor version (Long Life Release)
8.6.2.2-2
(C) Maintenance release(Patch and/or Features)
8.6.2.2-2
(X) Build (Patch)
8.6.2.1-2
8.6.2.2-2
(Y) FCS:0, ESor SU: 1-9
8.6.2.1-30 (FCS)
8.6.2.22900-1 (ESor SU look at last three digits)
(zzz) FCS:000, ES: 001-899, SU: 900-999
8.6.2.2-2 (FCS)
8.6.2.21001-1 (ES)
8.6.2.22900-1 (SU)


Best regards,
Ovidiu

On Mon, Sep 12, 2016 at 5:08 PM, Ryan Huff 
> wrote:

Just spotted 10.5.2.14060-1 on a cluster ... CCO only shows up to 
10.5.2.13901-2 ( 10.5(2)SU3a ). Anyone know if 10.5.2.14060-1 is a deferment or 
an engineering special ... etc?


Thanks,


Ryan

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



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

Re: [cisco-voip] cucm 10.5 version

[Ryan Huff]

So I imagine it is SU4 ... I was just wondering why it is not listed on CCO. 
There have been times, where a new release is listed but then removed due to 
deferment.

On Sep 12, 2016, at 11:18 AM, Ovidiu Popa 
> wrote:

Hello

I found this in an old Cisco live presentation. HTH

Numbering Convention Example
(A.B.C.XYzzz-x)
(A) Major version (License)
8.6.2.2-2
(B) Minor version (Long Life Release)
8.6.2.2-2
(C) Maintenance release(Patch and/or Features)
8.6.2.2-2
(X) Build (Patch)
8.6.2.1-2
8.6.2.2-2
(Y) FCS:0, ESor SU: 1-9
8.6.2.1-30 (FCS)
8.6.2.22900-1 (ESor SU look at last three digits)
(zzz) FCS:000, ES: 001-899, SU: 900-999
8.6.2.2-2 (FCS)
8.6.2.21001-1 (ES)
8.6.2.22900-1 (SU)


Best regards,
Ovidiu

On Mon, Sep 12, 2016 at 5:08 PM, Ryan Huff 
> wrote:

Just spotted 10.5.2.14060-1 on a cluster ... CCO only shows up to 
10.5.2.13901-2 ( 10.5(2)SU3a ). Anyone know if 10.5.2.14060-1 is a deferment or 
an engineering special ... etc?


Thanks,


Ryan

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


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

Re: [cisco-voip] Phone Fraud H.323

[David Zhars]

Hey Ryan,

The telco said these POTS lines (four of them) were being used to dial
Jamaica.  The router has 4 FXO ports.  For some reason, they were leaving
the fourth line alone, though the telco felt that wouldn't last long.
The router only has an internal non-routable IP addy.
Only processes H.323 (but does allow telnet and SNMP)
I don't know what PSTN egress means.  Sorry!

On Sun, Sep 11, 2016 at 11:49 AM, Ryan Huff  wrote:

> Hi David,
>
>
>
>- Did the telco say that the calls were originated from your POTS
>trunks or were they responding to customer complaints that one of your
>numbers had been reported to them for fraud ... etc?
>- Does this router have a public Internet facing interface?
>- Does this router process any other signaling protocols besides H.323?
>- You mentioned having Unity / Unity Connections ... are you allowing
>PSTN egress from Unity Connections / have you verified the restriction
>tables are correct?
>
> There are a number of things you could do on either side (UCM / Gateway).
> To cover the gap for the interim, I would at least deal with the specific
> called numbers that the telco gave you. In UCM, you could create specific
> route patterns in the egress path that do not route the match. On the
> gateway, you could use voice translation rules to try and reject the call
> attempt or translate the number to something the carrier won't route. You
> could also create specific dial-peers for the called numbers that do not
> route to anything.
>
>
> This reminds me of a time I had this issue (and I was a bit less mature);
> I created dial-peers on the CUBE that matched the 'bad' called numbers and
> I routed them back into CCM->CTIRp->CUC and had a small sample of Rick
> Astley's, "Never Gonna Give You Up" playing as the opening greeting to a
> System Call Handler  ahhh the younger days 
>
>
> ANYWAYS 
>
>
> I would say, in my experience, this sort of thing typically comes from the
> outside in. In cases where CUBE has a public Internet facing interface,
> usually someone finds something open on CUBE, sends some signaling that
> matches a dial-peer and off it goes. In this case you'd want to look at
> some outside ACLs or putting a firewall between the public Internet and the
> CUBE. If your CUBE does not face the Internet or is on a private network
> like MPLS ... that is much less likely to be the case and you want to start
> looking elsewhere on the network.
>
>
> I have seen bot dialers/Probers like 'SIPVicious
> ' (Cisco even has an advisory about it
> ) be
> able to access CUBE from the inside while installed on an infected PC.
> Granted, this tool is for SIP, but similar tools exist for h.323.
>
>
> Thanks,
>
> Ryan
>
> --
> *From:* cisco-voip  on behalf of
> David Zhars 
> *Sent:* Sunday, September 11, 2016 9:37 AM
> *To:* cisco-voip@puck.nether.net
> *Subject:* [cisco-voip] Phone Fraud H.323
>
> So yesterday I was alerted by our landline company that some of our phone
> numbers that come in POTS on an H323 router, we being used for phone
> fraud.  I am wondering how this happens with an H323 router (I am familiar
> with someone hacking Unity and setting up actions to route to Jamaica once
> someone leaves a voicemail or similar).
>
> The odd part is that these numbers are almost NEVER used for calling out,
> unless the user presses a 7 for an outbound line (versus an 8 which puts
> the call out on ISDN).
>
> I found a link on how to disable OffNet calling in UCM, but should I
> instead look at securing the H323 router?  Or does the call blocking rule
> need to be done in UCM?
>
> Thanks for any enlightenment you can provide.
>
> PS- Client is in USA, call fraud to Jamaica which does not require a
> country code, so harder to block.
>
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] FXO Disconnect Detection

[Esmaeel Saberi]

This link is usefull 
https://supportforums.cisco.com/discussion/11127921/fxo-4-voice-ports-always-busy
On Mon, Sep 12, 2016 at 10:34 AM Esmaeel Saberi  wrote:

> Hello
> You must record the sound of busy or congestion tone and define the
> frequency in
> router
>
> On Mon, Sep 12, 2016 at 5:21 AM Sreekanth  wrote:
>
>> Hi Scott,
>>
>> When reaching out to the telco, ask them what kind of disconnect they're
>> doing. Is it:
>> 1. Battery reversal
>> 2. Power denial
>> 3. Supervisory disconnect - tone played by the telco to indicate a
>> disconnect
>>
>> You've mentioned that when the remote party disconnects, the VoIP phone
>> stays off hook. Do you hear a disconnect tone during this period? If so,
>> the telco is using supervisory disconnect.
>> In that case, your DSPs on the router may need a tweak. You can do 2
>> things:
>>
>> 1. Take pcm captures on the router to capture the disconnect tone. Then
>> open a case with TAC who can decode this and give you the settings for the
>> supervisory disconnect.
>> 2. Do the ds0-dump on the router and capture the tones, decode them
>> yourself using Audacity and put in the settings.
>>
>> DS0-dump:
>> http://www.cisco.com/c/en/us/support/docs/voice-unified-communications/unified-communications-system/115749-analyze-pcm-data.html
>>
>> Video for setting up pcm captures and Ds0-dump.
>> https://www.youtube.com/watch?v=HkPjTBvx_YA
>>
>> Cheers!
>>
>> On 12 September 2016 at 05:30, Ryan Huff  wrote:
>>
>>> Scott,
>>>
>>>
>>> You are correct, it is the default. Oddly, what I meant to suggest is
>>> that you try disabling (*no battery-reversal*) but it seems that I
>>> suggested you to enable it (in which it has always been enabled). Try
>>> disabling the support and see what happens.
>>>
>>>
>>> Apologies!
>>>
>>>
>>> Thanks,
>>>
>>>
>>> Ryan
>>>
>>> --
>>> *From:* Hughes, Scott GRE-MG 
>>> *Sent:* Sunday, September 11, 2016 7:13 PM
>>> *To:* Ryan Huff
>>> *Cc:* cisco-voip@puck.nether.net
>>> *Subject:* Re: [cisco-voip] FXO Disconnect Detection
>>>
>>>
>>> :-/ unfortunately, that command must already be a default is IOS 15.5M
>>> because it doesn't show up in the running config after I put it in.
>>>
>>> Thanks for the suggestion though!
>>>
>>>
>>> On Sep 9, 2016, at 6:21 PM, Ryan Huff > ryanh...@outlook.com>> wrote:
>>>
>>> EXTERNAL
>>>
>>> You may try enabling support for battery reversal detection on the voice
>>> port;
>>>
>>> voice-port x/x/x
>>> battery-reversal
>>> !
>>>
>>> -Ryan
>>>
>>> On Sep 9, 2016, at 6:57 PM, Hughes, Scott GRE-MG >> > wrote:
>>>
>>> Hi,
>>>
>>> I have a Cisco 2921 H.323 gateway tied to CUCM 11 with 4 FXO (loop
>>> start) ports in a trunk group. Unanswered calls get forwarded to an offsite
>>> answering service (hairpinning out of the same set of FXO ports). Ports are
>>> setup with "connection plar opx 1000"
>>>
>>> My issue is that ports don't detect when the other end hangs up. When a
>>> remote party hangs up, the VoIP phone stays off hook and eventually plays a
>>> dial tone, followed by an operator message.
>>>
>>> I suspect that the forwarded calls terminate but both FXO ports in the
>>> hairpin stay off hook indefinitely.
>>>
>>> How can I combat this problem? I can reach out to the telco but need to
>>> know what to ask for.
>>>
>>> I am located in the US, if that makes a difference. I've read many
>>> articles about supervisory disconnection but none really help with
>>> troubleshooting steps or timers to tweak.
>>>
>>> -Scott
>>>
>>>
>>> NOTICE TO RECIPIENT: The information contained in this message from
>>> Great River Energy and any attachments are confidential and intended
>>> only for the named recipient(s). If you have received this message in
>>> error, you are prohibited from copying, distributing or using the
>>> information. Please contact the sender immediately by return email and
>>> delete the original message.
>>>
>>>
>>>
>>> ___
>>> cisco-voip mailing list
>>> cisco-voip@puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>
>>>
>>>
>>> NOTICE TO RECIPIENT: The information contained in this message from
>>> Great River Energy and any attachments are confidential and intended
>>> only for the named recipient(s). If you have received this message in
>>> error, you are prohibited from copying, distributing or using the
>>> information. Please contact the sender immediately by return email and
>>> delete the original message.
>>>
>>>
>>>
>>>
>>> ___
>>> 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
>> 

Re: [cisco-voip] FXO Disconnect Detection

[Esmaeel Saberi]

Hello
You must record the sound of busy or congestion tone and define the
frequency in
router

On Mon, Sep 12, 2016 at 5:21 AM Sreekanth  wrote:

> Hi Scott,
>
> When reaching out to the telco, ask them what kind of disconnect they're
> doing. Is it:
> 1. Battery reversal
> 2. Power denial
> 3. Supervisory disconnect - tone played by the telco to indicate a
> disconnect
>
> You've mentioned that when the remote party disconnects, the VoIP phone
> stays off hook. Do you hear a disconnect tone during this period? If so,
> the telco is using supervisory disconnect.
> In that case, your DSPs on the router may need a tweak. You can do 2
> things:
>
> 1. Take pcm captures on the router to capture the disconnect tone. Then
> open a case with TAC who can decode this and give you the settings for the
> supervisory disconnect.
> 2. Do the ds0-dump on the router and capture the tones, decode them
> yourself using Audacity and put in the settings.
>
> DS0-dump:
> http://www.cisco.com/c/en/us/support/docs/voice-unified-communications/unified-communications-system/115749-analyze-pcm-data.html
>
> Video for setting up pcm captures and Ds0-dump.
> https://www.youtube.com/watch?v=HkPjTBvx_YA
>
> Cheers!
>
> On 12 September 2016 at 05:30, Ryan Huff  wrote:
>
>> Scott,
>>
>>
>> You are correct, it is the default. Oddly, what I meant to suggest is
>> that you try disabling (*no battery-reversal*) but it seems that I
>> suggested you to enable it (in which it has always been enabled). Try
>> disabling the support and see what happens.
>>
>>
>> Apologies!
>>
>>
>> Thanks,
>>
>>
>> Ryan
>>
>> --
>> *From:* Hughes, Scott GRE-MG 
>> *Sent:* Sunday, September 11, 2016 7:13 PM
>> *To:* Ryan Huff
>> *Cc:* cisco-voip@puck.nether.net
>> *Subject:* Re: [cisco-voip] FXO Disconnect Detection
>>
>>
>> :-/ unfortunately, that command must already be a default is IOS 15.5M
>> because it doesn't show up in the running config after I put it in.
>>
>> Thanks for the suggestion though!
>>
>>
>> On Sep 9, 2016, at 6:21 PM, Ryan Huff  ryanh...@outlook.com>> wrote:
>>
>> EXTERNAL
>>
>> You may try enabling support for battery reversal detection on the voice
>> port;
>>
>> voice-port x/x/x
>> battery-reversal
>> !
>>
>> -Ryan
>>
>> On Sep 9, 2016, at 6:57 PM, Hughes, Scott GRE-MG > > wrote:
>>
>> Hi,
>>
>> I have a Cisco 2921 H.323 gateway tied to CUCM 11 with 4 FXO (loop start)
>> ports in a trunk group. Unanswered calls get forwarded to an offsite
>> answering service (hairpinning out of the same set of FXO ports). Ports are
>> setup with "connection plar opx 1000"
>>
>> My issue is that ports don't detect when the other end hangs up. When a
>> remote party hangs up, the VoIP phone stays off hook and eventually plays a
>> dial tone, followed by an operator message.
>>
>> I suspect that the forwarded calls terminate but both FXO ports in the
>> hairpin stay off hook indefinitely.
>>
>> How can I combat this problem? I can reach out to the telco but need to
>> know what to ask for.
>>
>> I am located in the US, if that makes a difference. I've read many
>> articles about supervisory disconnection but none really help with
>> troubleshooting steps or timers to tweak.
>>
>> -Scott
>>
>>
>> NOTICE TO RECIPIENT: The information contained in this message from
>> Great River Energy and any attachments are confidential and intended
>> only for the named recipient(s). If you have received this message in
>> error, you are prohibited from copying, distributing or using the
>> information. Please contact the sender immediately by return email and
>> delete the original message.
>>
>>
>>
>> ___
>> cisco-voip mailing list
>> cisco-voip@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
>>
>> NOTICE TO RECIPIENT: The information contained in this message from
>> Great River Energy and any attachments are confidential and intended
>> only for the named recipient(s). If you have received this message in
>> error, you are prohibited from copying, distributing or using the
>> information. Please contact the sender immediately by return email and
>> delete the original message.
>>
>>
>>
>>
>> ___
>> 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