Re: [cisco-voip] 9971 as a Trader phone

[Tim Smith]

Hi guys,

You can make this permanent with “Revert to All Calls” and “Show All Calls on 
Primary Line”
It’s in 9.2(3)
http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cuipph/9971_9951_8961/firmware/9_2_3/release_notes/9900_8900_923.html#wp239395


Cheers,

Tim

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of Adam 
Blomfield
Sent: Tuesday, 10 June 2014 11:56 PM
To: Mike
Cc: Cisco VOIP
Subject: Re: [cisco-voip] 9971 as a Trader phone

If all calls was selected then they could just press the call appearance button 
on the right to answer the call - or pick up the handset, hit the speakerphone 
or headset button etc. It would be just like the had the correct line 
appearance selected, but without having to swap between the directory numbers.
-Adam

On Tue, Jun 10, 2014 at 8:26 AM, Mike mailto:mik...@msn.com>> 
wrote:
Adam,

I did add  “All Calls” to line 3 but really didn’t understand how it would 
work. So the trader needs to keep “All Calls” selected and a call comes in how 
would they answer it without hitting 2 or 3 buttons?

From: Adam Blomfield [mailto:ad...@adman.net]
Sent: Tuesday, June 10, 2014 9:19 AM
To: Mike
Cc: Cisco VOIP
Subject: Re: [cisco-voip] 9971 as a Trader phone

If you add an "All Calls" button to the template and they keep this button 
selected then calls from all lines will show up mixed into the call appearance 
buttons on the right of the phone. The corresponding line on the left will 
flash so they will know if it's a call to their primary line or the shared 
line, but they won't have to press one of the line buttons in order to get to a 
ringing call. Any time I use the 8961/9900 series with multiple directory 
numbers I have to use the All Calls button as the users do no like swapping 
between lines.

-Adam

On Tue, Jun 10, 2014 at 8:13 AM, Mike mailto:mik...@msn.com>> 
wrote:
Hey all I have a group of traders that migrated from 7965’s to 9971’s. They 
aren’t very happy as it takes 2 or 3 button hits to answer a call that’s not on 
the primary line.

Has anyone seen this problem? I changed the setting  always use primary line 
but didn’t make a difference.

Phone config has following attributes:

Button 1: primary line
Button 2: shared line


Button 7 – 22 : PLAR to remote traders





___
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] Two-way SMS services?

[Robert Kulagowski]

I checked the archives, and the last discussion seems to have been
back in 2011 with Ozeki NG. Is anyone doing two-way SMS into something
like Lync 2013 or Jabber?
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] Heartbeat Failure & SNRD

[Brian Meade]

Make sure yo have them attach your service request to CSCup27726.


On Tue, Jun 10, 2014 at 11:40 AM, Daniel Pagan  wrote:

>  Just a quick wrap-up on this one…
>
> Two defects created for this problem are CSCup27726 and CSCup27133.
>
>
>
> - Dan
>
>
>
> *From:* Wes Sisk (wsisk) [mailto:ws...@cisco.com]
> *Sent:* Wednesday, May 21, 2014 2:50 PM
> *To:* Daniel Pagan
> *Cc:* cisco-voip@puck.nether.net
> *Subject:* Re: [cisco-voip] Heartbeat Failure & SNRD
>
>
>
> Hi Daniel,
>
>
>
> Great find!
>
>
>
> For the document:
>
>
> http://www.cisco.com/c/en/us/support/docs/voice-unified-communications/unified-communications-manager-callmanager/46806-cm-crashes-and-shutdowns.html
>
>
>
> The initialization process and timers have changed *significantly* since
> 4.x. Some examples include:
>
> CSCsj76788cp-system request to remove initialization timers
>
> “... remove the initialization timers that are started during CUCM
> initialization.  These timer would previously cause a system restart under
> certain circumstance…”
>
>
>
> Still, there is a global maximum timeout. Individual Daemons must report
> start and successful initiation by that time.
>
>
>
> Historically behavior like you discuss was triggered by service parameters
> being missing or having incorrect values. This may be a problem with
> connection to the database ( CSCsc72748 ) or problem with the contents of
> the database. Other problems include another process grabbing one of the
> TCP or UDP ports required by the ccm process.
>
>
>
> ccm had many issues retrieving initialization information from the
> database in early linux versions. refinements to informix and in memory
> database (IMDB) have helped significantly.
>
>
>
> -Wes
>
>
>
>
>
> On May 21, 2014, at 9:33 AM, Daniel Pagan  wrote:
>
>
>
> Folks:
>
>
>
> CUCM ES 8.6.2.24122-1 appears to be creating an issue where CallManager
> heartbeat fails to increment upon startup and the condition that must be
> met is very specific. On a problematic node, SDL traces show the following
> error exactly one hour after the start of the CCM service:
>
>
>
> *AppError  ||Local send blocked: SignalName: Start,
> DestPID: SNRD[1:100:61:1]*
>
>
>
> This error is followed by the SDL trace printing an error stating
> CallManager exceeded the permitted time for initialization and will restart
> the application. The CCM application restarts and additional SDL traces are
> printed showing the standard creation of critical processes – one hour
> later the same “Local send blocked” error is printed regarding the SNRD
> process.
>
>
>
> I saw the *DestPID: SNRD* error, went to a completely different,
> *non-problematic* lab environment where 8.6.2.24122-1 is installed,
> created a single Remote Destination Profile, and then restarted the
> standalone node in order to force the creation of SNRD. CallManager
> heartbeats are now failing to increment in that environment and found
> another “Local send blocked” error regarding SNRD. Removing the single
> Remote Destination Profile from the standalone environment and rebooting
> the node resolves the problem. Re-inserting it again followed by a reboot
> recreates it, making SNRD the obvious culprit here.
>
>
>
> I currently have a TAC case open where they’re attempting to recreate the
> problem. It seems no public facing defects are created for this. Just
> wanted to give you folks a heads up.
>
>
>
> Related to this, can someone tell me if this document, specifally the
> section describing MMManInit and process creation, is still accurate? If
> so, then what I fail to see in SDL traces is a *InitDone* signal from
> SNRD to MMManInit during the 60 minutes between CCM startup and
> initialization timeout.
>
>
>
> - Daniel
>
>
>
> ___
> 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] Heartbeat Failure & SNRD

[Daniel Pagan]

Just a quick wrap-up on this one...
Two defects created for this problem are CSCup27726 and CSCup27133.

- Dan

From: Wes Sisk (wsisk) [mailto:ws...@cisco.com]
Sent: Wednesday, May 21, 2014 2:50 PM
To: Daniel Pagan
Cc: cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] Heartbeat Failure & SNRD

Hi Daniel,

Great find!

For the document:
http://www.cisco.com/c/en/us/support/docs/voice-unified-communications/unified-communications-manager-callmanager/46806-cm-crashes-and-shutdowns.html

The initialization process and timers have changed *significantly* since 4.x. 
Some examples include:
CSCsj76788cp-system request to remove initialization timers
"... remove the initialization timers that are started during CUCM 
initialization.  These timer would previously cause a system restart under 
certain circumstance..."

Still, there is a global maximum timeout. Individual Daemons must report start 
and successful initiation by that time.

Historically behavior like you discuss was triggered by service parameters 
being missing or having incorrect values. This may be a problem with connection 
to the database ( CSCsc72748 ) or problem with the contents of the database. 
Other problems include another process grabbing one of the TCP or UDP ports 
required by the ccm process.

ccm had many issues retrieving initialization information from the database in 
early linux versions. refinements to informix and in memory database (IMDB) 
have helped significantly.

-Wes


On May 21, 2014, at 9:33 AM, Daniel Pagan 
mailto:dpa...@fidelus.com>> wrote:

Folks:

CUCM ES 8.6.2.24122-1 appears to be creating an issue where CallManager 
heartbeat fails to increment upon startup and the condition that must be met is 
very specific. On a problematic node, SDL traces show the following error 
exactly one hour after the start of the CCM service:

AppError  ||Local send blocked: SignalName: Start, DestPID: SNRD[1:100:61:1]

This error is followed by the SDL trace printing an error stating CallManager 
exceeded the permitted time for initialization and will restart the 
application. The CCM application restarts and additional SDL traces are printed 
showing the standard creation of critical processes - one hour later the same 
"Local send blocked" error is printed regarding the SNRD process.

I saw the DestPID: SNRD error, went to a completely different, non-problematic 
lab environment where 8.6.2.24122-1 is installed, created a single Remote 
Destination Profile, and then restarted the standalone node in order to force 
the creation of SNRD. CallManager heartbeats are now failing to increment in 
that environment and found another "Local send blocked" error regarding SNRD. 
Removing the single Remote Destination Profile from the standalone environment 
and rebooting the node resolves the problem. Re-inserting it again followed by 
a reboot recreates it, making SNRD the obvious culprit here.

I currently have a TAC case open where they're attempting to recreate the 
problem. It seems no public facing defects are created for this. Just wanted to 
give you folks a heads up.

Related to this, can someone tell me if this document, specifally the section 
describing MMManInit and process creation, is still accurate? If so, then what 
I fail to see in SDL traces is a InitDone signal from SNRD to MMManInit during 
the 60 minutes between CCM startup and initialization timeout.

- Daniel

___
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] Finesse Admin error

[Matthew Loraditch]

There were issues rendering this gadget.
Unsupported scheme (must be http or https).
/cfadmin/gadgets/MediaPropertiesLayout.jsp

Every tab in the admin has the same type of error???
10.0.1SU1

Any ideas?


Matthew G. Loraditch - CCNP-Voice, CCNA-R&S, CCDA
1965 Greenspring Drive
Timonium, MD 21093

direct voice. 443.541.1518
fax.  410.252.9284

Twitter  |  
Facebook  | 
Website  |  Email 
Support
Support Phone. 410.252.8830


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

Re: [cisco-voip] 9971 as a Trader phone

[Adam Blomfield]

If all calls was selected then they could just press the call appearance
button on the right to answer the call - or pick up the handset, hit the
speakerphone or headset button etc. It would be just like the had the
correct line appearance selected, but without having to swap between the
directory numbers.

-Adam


On Tue, Jun 10, 2014 at 8:26 AM, Mike  wrote:

> Adam,
>
>
>
> I did add  “All Calls” to line 3 but really didn’t understand how it would
> work. So the trader needs to keep “All Calls” selected and a call comes in
> how would they answer it without hitting 2 or 3 buttons?
>
>
>
> *From:* Adam Blomfield [mailto:ad...@adman.net]
> *Sent:* Tuesday, June 10, 2014 9:19 AM
> *To:* Mike
> *Cc:* Cisco VOIP
> *Subject:* Re: [cisco-voip] 9971 as a Trader phone
>
>
>
> If you add an "All Calls" button to the template and they keep this button
> selected then calls from all lines will show up mixed into the call
> appearance buttons on the right of the phone. The corresponding line on the
> left will flash so they will know if it's a call to their primary line or
> the shared line, but they won't have to press one of the line buttons in
> order to get to a ringing call. Any time I use the 8961/9900 series with
> multiple directory numbers I have to use the All Calls button as the users
> do no like swapping between lines.
>
> -Adam
>
>
>
> On Tue, Jun 10, 2014 at 8:13 AM, Mike  wrote:
>
> Hey all I have a group of traders that migrated from 7965’s to 9971’s.
> They aren’t very happy as it takes 2 or 3 button hits to answer a call
> that’s not on the primary line.
>
>
>
> Has anyone seen this problem? I changed the setting  always use primary
> line but didn’t make a difference.
>
>
>
> Phone config has following attributes:
>
>
>
> Button 1: primary line
>
> Button 2: shared line
>
>
>
>
>
> Button 7 – 22 : PLAR to remote traders
>
>
>
>
>
>
>
>
>
>
> ___
> 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] 9971 as a Trader phone

[Mike]

Adam,

 

I did add  “All Calls” to line 3 but really didn’t understand how it would 
work. So the trader needs to keep “All Calls” selected and a call comes in how 
would they answer it without hitting 2 or 3 buttons?

 

From: Adam Blomfield [mailto:ad...@adman.net] 
Sent: Tuesday, June 10, 2014 9:19 AM
To: Mike
Cc: Cisco VOIP
Subject: Re: [cisco-voip] 9971 as a Trader phone

 

If you add an "All Calls" button to the template and they keep this button 
selected then calls from all lines will show up mixed into the call appearance 
buttons on the right of the phone. The corresponding line on the left will 
flash so they will know if it's a call to their primary line or the shared 
line, but they won't have to press one of the line buttons in order to get to a 
ringing call. Any time I use the 8961/9900 series with multiple directory 
numbers I have to use the All Calls button as the users do no like swapping 
between lines.

-Adam

 

On Tue, Jun 10, 2014 at 8:13 AM, Mike  wrote:

Hey all I have a group of traders that migrated from 7965’s to 9971’s. They 
aren’t very happy as it takes 2 or 3 button hits to answer a call that’s not on 
the primary line.

 

Has anyone seen this problem? I changed the setting  always use primary line 
but didn’t make a difference.

 

Phone config has following attributes:

 

Button 1: primary line

Button 2: shared line

 

 

Button 7 – 22 : PLAR to remote traders

 

 

 

 


___
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] 9971 as a Trader phone

[Adam Blomfield]

If you add an "All Calls" button to the template and they keep this button
selected then calls from all lines will show up mixed into the call
appearance buttons on the right of the phone. The corresponding line on the
left will flash so they will know if it's a call to their primary line or
the shared line, but they won't have to press one of the line buttons in
order to get to a ringing call. Any time I use the 8961/9900 series with
multiple directory numbers I have to use the All Calls button as the users
do no like swapping between lines.

-Adam


On Tue, Jun 10, 2014 at 8:13 AM, Mike  wrote:

> Hey all I have a group of traders that migrated from 7965’s to 9971’s.
> They aren’t very happy as it takes 2 or 3 button hits to answer a call
> that’s not on the primary line.
>
>
>
> Has anyone seen this problem? I changed the setting  always use primary
> line but didn’t make a difference.
>
>
>
> Phone config has following attributes:
>
>
>
> Button 1: primary line
>
> Button 2: shared line
>
>
>
>
>
> Button 7 – 22 : PLAR to remote traders
>
>
>
>
>
>
>
>
>
> ___
> 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] 9971 as a Trader phone

[Mike]

Hey all I have a group of traders that migrated from 7965's to 9971's. They
aren't very happy as it takes 2 or 3 button hits to answer a call that's not
on the primary line.

 

Has anyone seen this problem? I changed the setting  always use primary line
but didn't make a difference.

 

Phone config has following attributes:

 

Button 1: primary line

Button 2: shared line

 

 

Button 7 - 22 : PLAR to remote traders

 

 

 

 

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

[cisco-voip] CUBE dial-peer with b2bua command

[Roger Wiklund]

Hi

I've seen a couple of CUBEs configured with the following:

dial-peer voice x voip
 b2bua

I'm confused by this as the CUBE is per definition a B2BUA without that command.

The only thing I can find in the documentation on b2bua is regarding CME.

b2bua

To configure a dial peer associated with an individual Session
Initiation Protocol (SIP) phone in Cisco Unified CME or a group of
phones in a Cisco Unified SIP Survivable Remote Site Telephony (SRST)
environment to point to Cisco Unity Express, use the b2bua command in
dial-peer configuration mode. To disable B2BUA call flow on the dial
peer, use the no form of this command.

So I'm assuming it's redundant to configure it unless you run CME?

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