Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
- Cisco Community
- :
- About VLT06
08-27-2019
Stats
Member since
04-02-2012
186
Posts
33
Helpful
4
Solutions
Created by
VLT06
in IP Telephony and Phones
in IP Telephony and Phones
02-12-2019
09:50 PM
02-12-2019
09:50 PM
Hello all – as the title indicates, I am after some Opinions on Best Practise regarding “Dummy” phones.
Long story short, I have a couple of hundred that I need to re-administer as we are currently using the device type of “7902”. I believe a coming upgrade (CUCM 11.5) will render these unsupported etc.
So the questions is, what would the best “Device Type” to re-creates these as (keeping in mind longevity or that device type). Or, considering nearly all are for forwarding to Unity (mostly with multiple end users for control), is there any other way around it?
Any ideas/comments much appreciated 😉
... View more
Labels:
Created by
VLT06
in IP Telephony and Phones
in IP Telephony and Phones
01-13-2019
12:16 PM
01-13-2019
12:16 PM
"Why would you take a modern solution with out of hand signaling and clean disconnect supervision and replace it with 100 year old analog connectivity?!" - Pretty much the same thing that drives most in this world...$$$$. In Australia, they are decommissioning traditional POTS PSTN to transition over to NBN. For those who can't afford new interfaces, then unfortunately all we have to work with for now. I do agree though - just wich customers had deeper pockets some times :) Thanks for the links, will check them out!
... View more
Created by
VLT06
in IP Telephony and Phones
in IP Telephony and Phones
01-08-2019
08:41 PM
01-08-2019
08:41 PM
Hi All,
starting to test a carrier service (SIP) which has an NTU that breaks out into traditional POTS services (Carrier SIP -> FXO -> 4331 Router) and am finding that when in SRST, that incoming caller ID is presenting calling number@loopback5 address (example 12345678@10.110.110.1). Does not occur when WAN is up and not in SRST.
Anyway to remove the "@10.110.110.1" leaving just the number "12345678" for example?
... View more
Labels:
11-19-2018
07:14 PM
Just wondering if anyone has any experience with the following issue/observation…
Currently have a ISR4331 (SIP) to CUCM 11. On the 4331, I have a BRI which works all ok in/out, however, I am only getting “MULTIPLE_FRAME_ESTABLISHED” when there is a call in progress;
ISDN BRI1/0/0:0 interface
dsl 0, interface ISDN Switchtype = basic-net3
Layer 1 Status:
ACTIVE
Layer 2 Status:
TEI = 89, Ces = 1, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED
Layer 3 Status:
0 Active Layer 3 Call(s)
CCB:callid=17, sapi=0, ces=1, B-chan=1, calltype=VOICE
Active dsl 0 CCBs = 1
The Free Channel Mask: 0x80000002
When the call ends, after approx. 10 seconds or so, the ISDN returns to deactived state;
ISDN BRI1/0/0:0 interface
dsl 0, interface ISDN Switchtype = basic-net3
Layer 1 Status:
DEACTIVATED
Layer 2 Status:
Layer 2 NOT Activated
Layer 3 Status:
0 Active Layer 3 Call(s)
Active dsl 0 CCBs = 0
The Free Channel Mask: 0x80000003
As I mentioned – not causing an issue for calls however when we are monitoring and from an alert perspective, getting spammed for UP & DOWN alerts.
Current config;
interface BRI1/0/0:0
description VNM AAPT BRI service
no ip address
no snmp trap link-status
isdn switch-type basic-net3
isdn overlap-receiving
isdn point-to-point-setup
isdn sending-complete
trunk-group pstn
!
voice-port 1/0/0
disc_pi_off
compand-type a-law
cptone AU
timeouts interdigit 3
timeouts call-disconnect 3
timeouts wait-release 5
description VNM BRI-ISDN-2
bearer-cap Speech
Anything I can do to keep this established as it would normally do in MGCP?
... View more
- Tags:
- ISDN BRI SIP
Labels:
12-27-2017
03:41 PM
Interesting, we had hit 205 users and cant add another. If we remove an existing user - we can then add a new user so it seems there is some limitation... sure there is no bugs around?
... View more
10-04-2017
12:17 PM
Yeah, still the same. Carrier advised all good from their end (which i suspected as this has no issue with MGCP)...
... View more
09-26-2017
10:16 PM
Thanks, yeah I guess I will give it a go. The only thing is that if I change the protocol to MGCP, it says up fine...???
... View more
09-26-2017
09:48 PM
Hi Mohammed, sure, please see below with an inbound tast call; Sep 27 14:40:52.497 aest: %MARS_NETCLK-3-CLK_TRANS: Network clock source transitioned from priority 10 to priority 1 Sep 27 14:40:52.497 aest: ISDN BR0/2/0 Q921: L2_EstablishDataLink: sending SABME Sep 27 14:40:52.501 aest: ISDN BR0/2/0 Q921: User TX -> SABMEp sapi=0 tei=86 Sep 27 14:40:52.513 aest: ISDN BR0/2/0 Q921: User RX <- UAf sapi=0 tei=86 Sep 27 14:40:52.549 aest: %LINK-3-UPDOWN: Interface BRI0/2/0, changed state to up Sep 27 14:40:52.701 aest: ISDN BR0/2/0 Q921: User RX <- UI sapi=0 tei=127 Sep 27 14:40:52.713 aest: ISDN BR0/2/0 Q921: User TX -> INFO sapi=0 tei=86, ns=0 nr=0 Sep 27 14:40:52.729 aest: ISDN BR0/2/0 Q921: User RX <- RR sapi=0 tei=86 nr=1 Sep 27 14:40:52.857 aest: ISDN BR0/2/0 Q921: User TX -> INFO sapi=0 tei=86, ns=1 nr=0 Sep 27 14:40:52.873 aest: ISDN BR0/2/0 Q921: User RX <- RR sapi=0 tei=86 nr=2 Sep 27 14:40:59.789 aest: ISDN BR0/2/0 Q921: User TX -> INFO sapi=0 tei=86, ns=2 nr=0 Sep 27 14:40:59.805 aest: ISDN BR0/2/0 Q921: User RX <- RR sapi=0 tei=86 nr=3 Sep 27 14:40:59.849 aest: ISDN BR0/2/0 Q921: User RX <- INFO sapi=0 tei=86, ns=0 nr=3-----------------> Call Answered Sep 27 14:40:59.849 aest: ISDN BR0/2/0 Q921: User TX -> RR sapi=0 tei=86 nr=1 Sep 27 14:41:09.849 aest: ISDN BR0/2/0 Q921: User TX -> RRp sapi=0 tei=86 nr=1 Sep 27 14:41:09.861 aest: ISDN BR0/2/0 Q921: User RX <- RRf sapi=0 tei=86 nr=3 Sep 27 14:41:14.269 aest: ISDN BR0/2/0 Q921: User TX -> INFO sapi=0 tei=86, ns=3 nr=1-----------------> Call Hung Up Sep 27 14:41:14.285 aest: ISDN BR0/2/0 Q921: User RX <- RR sapi=0 tei=86 nr=4 Sep 27 14:41:14.369 aest: ISDN BR0/2/0 Q921: User RX <- INFO sapi=0 tei=86, ns=1 nr=4 Sep 27 14:41:14.369 aest: ISDN BR0/2/0 Q921: User TX -> RR sapi=0 tei=86 nr=2 Sep 27 14:41:14.373 aest: ISDN BR0/2/0 Q921: User TX -> INFO sapi=0 tei=86, ns=4 nr=2 Sep 27 14:41:14.389 aest: ISDN BR0/2/0 Q921: User RX <- RR sapi=0 tei=86 nr=5 Sep 27 14:41:24.389 aest: ISDN BR0/2/0 Q921: User TX -> RRp sapi=0 tei=86 nr=2 Sep 27 14:41:24.393 aest: ISDN BR0/2/0 Q921: User RX <- RRp sapi=0 tei=86 nr=5 Sep 27 14:41:24.393 aest: ISDN BR0/2/0 Q921: User TX -> RRf sapi=0 tei=86 nr=2 Sep 27 14:41:24.401 aest: ISDN BR0/2/0 Q921: User RX <- RRf sapi=0 tei=86 nr=5 Sep 27 14:41:29.381 aest: ISDN BR0/2/0 Q921: User RX <- DISCp sapi=0 tei=86---------------------------> MULTIPLE_FRAME_ESTABLISHED Drops Sep 27 14:41:29.381 aest: ISDN BR0/2/0 Q921: User TX -> UAf sapi=0 tei=86 Sep 27 14:41:59.965 aest: %MARS_NETCLK-3-CLK_TRANS: Network clock source transitioned from priority 1 to priority 10 Sep 27 14:42:00.017 aest: %LINK-3-UPDOWN: Interface BRI0/2/0, changed state to down-------------------> Layer 1 change to DEACTIVATED
... View more
09-26-2017
06:51 PM
Ok, the short and sweet of it all…. Converting 2911 with BRI from MGCP to SIP trunk and all works fine (both in/out calls) however I have observed that when in an idle state, Layer 1 is DEACTIVATED??? When a call establishes, layer 1 becomes ACTIVE and I get the normal MULTIPLE_FRAME_ESTABLISHED for layer 2. When the calls disconnects, MULTIPLE_FRAME_ESTABLISHED drops off after about 5 seconds, then Layer 1 goes back to DEACTIVATED about 10 seconds after that. Even though calls work, is this normal behaviour for a BRI behind SIP to CUCM? Current config voice-port 0/2/0 disc_pi_off compand-type a-law cptone AU timeouts interdigit 3 timeouts call-disconnect 3 timeouts wait-release 5 description VNM BRI-ISDN-2 bearer-cap Speech I have also tried adding the following with no change - isdn static-tei 0 - isdn tei-negotiation first-call - isdn tei-negotiation preserve 2911 with IOS Version 15.4(3)M2, RELEASE SOFTWARE (fc2) Any thoughts?
... View more
Labels:
07-05-2017
10:36 PM
Ok, I am starting to see where you are going with this...
So separate CUCM translation patterns to insert code -> existing route group over H.323 -> dial-peer to cater for code in translation pattern yeah?
... View more
07-05-2017
10:24 PM
Thanks for the reply!
Currently matching via "destination-pattern 0T" (where "0" is what they dial for an outside line).
Yeah, I was trying to steer away from having the users to manually prefix their calls as it is just extra steps they have to remember and also to avoid having to set up multiple route patterns in CUCM etc...
... View more
07-05-2017
03:42 PM
Ok, solution mode….
Scenario – I have a small site (2911 -> H.323 -> CUCM) where I have 4 x PSTN on FXO. Now, at the moment all outbound calls decided by dial peers which will hunt (dial-peer hunt) with preferences of 0/0/3, 0/0/2, 0/0/1 & 0/0/0 etc… All works good.
NOW, this site wants to dedicate the last 2 of the PSTN’s to two individual phones (dedicated) and the first two remain for the other phones…. So, apart from creating many, many CUCM rout groups etc… is there a simple way to do this on the router via the dial-peer “answer-address” so that the router sees the extn calling and route to dedicated FXO port and no others?
E.g
Extn 11111 only uses FXO 0/0/2
Extn 22222 only uses FXO 0/0/3
All other Extns remain to use FXO 0/0/1 & 0/0/0
Trying to pull this off without re-inventing the wheel
Unfortunately, this site has gone from a key system where they could manually select their own dedicated line.
Any help/ideas much appreciated!
... View more
Labels:
Created by
VLT06
in IP Telephony and Phones
in IP Telephony and Phones
11-02-2016
01:14 AM
11-02-2016
01:14 AM
Hi Guys,
Seems an odd and peculiar issue where we just upgraded for CUCM 8.X to 11.X and now ATA 190 devices wont ring via internal calls to Hunt Pilot.
External calls ring all members of the line group including ATA 190 devices but internal calls to the exact Hunt Pilot will call all devices BUT the ATA 190's....
Works fine for all ATA 186's but not 190's. Upgrade of CUCM was via data migration.
have tried all the usual things (logged into hunt groups, factory resets etc...)
Only effect internally when calling via the hunt group - direct calls work fine.
Anyone heard of anything of the like?
... View more
Labels:
Created by
VLT06
in Collaboration, Voice and Video Documents
in Collaboration, Voice and Video Documents
10-30-2016
12:27 AM
10-30-2016
12:27 AM
Hey, yeah Jabber 11.6 and CIMP 11.
... View more
10-24-2016
12:18 AM
Hey Minksky!
Yeah, just upgraded CUCM and this caused a MAJOR issue!!! Not a great solution to clear cache from 5.5k users manually I tell ya!!!
... View more
Created by
VLT06
in IP Telephony and Phones
02-12-2019
02-12-2019
Hello all – as the title indicates, I am after some Opinions on Best
Practise regarding “Dummy” phon...
Created by
VLT06
in IP Telephony and Phones
01-13-2019
01-13-2019
"Why would you take a modern solution with out of hand signaling and
clean disconnect supervision an...
01-08-2019
Hi All, starting to test a carrier service (SIP) which has an NTU that
breaks out into traditional P...
11-19-2018
Just wondering if anyone has any experience with the following
issue/observation… Currently have a I...
Created by
VLT06
in Unified Communications Infrastructure
03-06-2018
03-06-2018
Just as FYI - my issue was resolved via an RMA on the card. Apparently a
certain batch had issues et...
Created by
VLT06
in Unified Communications Infrastructure
02-27-2018
02-27-2018
Sorry, mine was with a NIM-BRI4 (sorry typed incorrect card before).
Created by
VLT06
in Unified Communications Infrastructure
02-26-2018
02-26-2018
Got the same happening today as well... what I have found on a NIM-BRI4
is that port 0 & 2 = Loud sc...
12-27-2017
Interesting, we had hit 205 users and cant add another. If we remove an
existing user - we can then ...
10-04-2017
Yeah, still the same. Carrier advised all good from their end (which i
suspected as this has no issu...
09-26-2017
Thanks, yeah I guess I will give it a go. The only thing is that if I
change the protocol to MGCP, i...
09-26-2017
Hi Mohammed, sure, please see below with an inbound tast call; Sep 27
14:40:52.497 aest: %MARS_NETCL...
09-26-2017
Ok, the short and sweet of it all…. Converting 2911 with BRI from MGCP
to SIP trunk and all works fi...
07-05-2017
Ok, I am starting to see where you are going with this... So separate
CUCM translation patterns to i...
07-05-2017
Thanks for the reply! Currently matching via "destination-pattern 0T"
(where "0" is what they dial f...
Public Statistics
| Date Registered | 04-02-2012 08:57 PM |
| Date Last Visited | 08-27-2019 06:58 AM |
| Total Messages Posted | 186 |
| Total Helpful Votes Received | 33 |
Helpful Votes From
| User | Helpful Count |
|---|---|
| 5 | |
| 5 | |
| 3 | |
| 5 | |
| 5 |
