[cisco-voip] Jabber Issues

[naresh rathore]

hi All



i am currently facing two issues with Jabber.



1. jabber is used in Phone only mode on this particular computer. CUCM version 
is 10.5.2. when I use jabber 11.7, i can see my mobile number under my Name but 
when i install jabber 11.8.3 on my windows 7 machine, instead of number, i see 
my email under my name on top.


2. Also on Jabber 11.7, when i hover over the user, it automatically shows the 
user profile. but on Jabber 11.8.3 when i hover over the user, nothing happens 
and i have to do righclick and see the profile.



it works Ok with Jabber 11.7 but doesnt work if i upgrade to Jabber 11.8.3



Regards


Naray.


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

Re: [cisco-voip] Headset Recommendations for 79xx?

[Anthony Holloway]

I didn't see it mentioned but keep in mind that some headsets will pass
through the ringtone from the phone settings (E.g., Chirp 1) and some will
override it with an internal ringtone.

Oh and some headsets have their side tone setting through the roof and
sound like crap until you lower it.

I have had users complain about both of these with the Plantronics C720.

http://www.plantronics.com/us/product/blackwire-700
On Thu, Apr 6, 2017 at 5:12 PM Frank Arrasmith 
wrote:

> +1 on the Plantronics Savi series.  we use them in our Call center for our
> 79XX phones  with APC-42? integration cables.  no complaints
>
> On Tue, Apr 4, 2017 at 6:56 AM, Scott Voll  wrote:
>
> Plantronics Savi 745 have been working well for us, both on 7961 with
> lifters and now with 8861 with HHC cables.  you can get them in one ear or
> dual ear configurations.  Works with Jabber and IPC also.  All around a
> great headset.
>
> Scott
>
>
> On Wed, Mar 29, 2017 at 1:12 PM, chris  wrote:
>
> Hello,
>
> We are looking for headsets for 79xx preferably something with noise
> cancellation that works with 79xx phones.
>
> If anyone has had any experiences that might be helpful feel to reply on
> or off list
>
> Thanks!
> chris
>
>
> ___
> 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 HA and CUIC Historical Data Source

[Anthony Holloway]

 Nope. Abhiram?

On Thu, Apr 6, 2017 at 2:31 PM Nick Britt  wrote:

Hi Anthony,

Sorry to grave dig but just wondered if you ever got an answer for this?

I am about to go down this rabbit hole myself as a customer wants a better
explanation (documentation) as to how this is supposed  to be configured
and how this should behave.

Cheers

Nick

On Wed, Jun 15, 2016 at 10:22 PM, Anthony Holloway <
avholloway+cisco-v...@gmail.com> wrote:

There seems to be zero documentation for UCCX that mentions changing or
adding Data Source configuration in CUIC when running HA; whether HAoL or
HAoW.

However, I have heard from Cisco employees, forums posts, and colleagues,
these two points:

   1. The Data Source should point to the secondary node, and you have to
   manually change it, as the default is pointing to the primary node.

   2. The Data Source's Secondary tab is defaulted to disabled, and not
   populated.  It shouldn't be used, and CUIC takes care of updating the Data
   Source during a failure.

First off, where in the documentation is that explained?  I cannot find a
good explanation, sans ambiguity, to save my life.  Are people just
spreading rumors and old wives tales?

Also, I do know that back in the HRC days, the client would handle the
connection to the secondary server automatically.  So, I can see where this
tale comes from.

Now, with HAoW, I tested failover with the server shutdown.  Not in slave,
but actually powered off.  What I observed was, the Data Source was not
automatically updated, and I could run any reports, despite being logged in
to the secondary CUIC server.  The Data Source connection test failed,
obviously, and reports failed, obviously.

I did consider take a leap of faith and confiure the CUIC Data Source's
Secondary tab, but the user account to connect to the DB instance was not
in my control, and I don't know the password.  I'm sure I could get it, but
it was a show stopper nonetheless.

So, has anyone here actually tested with a failed node or island mode with
their HA setup, or is it all just speculation, like this post:

https://supportforums.cisco.com/discussion/12473981/ha-uccx-cuic-data-only-one-server

___
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] Headset Recommendations for 79xx?

[Frank Arrasmith]

+1 on the Plantronics Savi series.  we use them in our Call center for our
79XX phones  with APC-42? integration cables.  no complaints

On Tue, Apr 4, 2017 at 6:56 AM, Scott Voll  wrote:

> Plantronics Savi 745 have been working well for us, both on 7961 with
> lifters and now with 8861 with HHC cables.  you can get them in one ear or
> dual ear configurations.  Works with Jabber and IPC also.  All around a
> great headset.
>
> Scott
>
>
> On Wed, Mar 29, 2017 at 1:12 PM, chris  wrote:
>
>> Hello,
>>
>> We are looking for headsets for 79xx preferably something with noise
>> cancellation that works with 79xx phones.
>>
>> If anyone has had any experiences that might be helpful feel to reply on
>> or off list
>>
>> Thanks!
>> chris
>>
>>
>> ___
>> 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 HA and CUIC Historical Data Source

[Nick Britt]

Hi Anthony,

Sorry to grave dig but just wondered if you ever got an answer for this?

I am about to go down this rabbit hole myself as a customer wants a better
explanation (documentation) as to how this is supposed  to be configured
and how this should behave.

Cheers

Nick

On Wed, Jun 15, 2016 at 10:22 PM, Anthony Holloway <
avholloway+cisco-v...@gmail.com> wrote:

> There seems to be zero documentation for UCCX that mentions changing or
> adding Data Source configuration in CUIC when running HA; whether HAoL or
> HAoW.
>
> However, I have heard from Cisco employees, forums posts, and colleagues,
> these two points:
>
>1. The Data Source should point to the secondary node, and you have to
>manually change it, as the default is pointing to the primary node.
>
>2. The Data Source's Secondary tab is defaulted to disabled, and not
>populated.  It shouldn't be used, and CUIC takes care of updating the Data
>Source during a failure.
>
> First off, where in the documentation is that explained?  I cannot find a
> good explanation, sans ambiguity, to save my life.  Are people just
> spreading rumors and old wives tales?
>
> Also, I do know that back in the HRC days, the client would handle the
> connection to the secondary server automatically.  So, I can see where this
> tale comes from.
>
> Now, with HAoW, I tested failover with the server shutdown.  Not in slave,
> but actually powered off.  What I observed was, the Data Source was not
> automatically updated, and I could run any reports, despite being logged in
> to the secondary CUIC server.  The Data Source connection test failed,
> obviously, and reports failed, obviously.
>
> I did consider take a leap of faith and confiure the CUIC Data Source's
> Secondary tab, but the user account to connect to the DB instance was not
> in my control, and I don't know the password.  I'm sure I could get it, but
> it was a show stopper nonetheless.
>
> So, has anyone here actually tested with a failed node or island mode with
> their HA setup, or is it all just speculation, like this post:
>
> https://supportforums.cisco.com/discussion/12473981/ha-
> uccx-cuic-data-only-one-server
>
> ___
> 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] Question regarding Rightfax Configuration and "Transmission Error"

[Ben Amick]

We’ve had to call our provider before for destinations with high failure rates, 
and they point the faxes out a different inter-carrier link which usually 
resolves the issue. I think some inter-carrier trunks just don’t play well with 
T38.

Ben Amick
Telecom Analyst

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of Frank 
Arrasmith
Sent: Thursday, April 06, 2017 11:40 AM
To: Scott Voll 
Cc: cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] Question regarding Rightfax Configuration and 
"Transmission Error"

On average or failure rate is below 5%, however there are some senders with 
failure rates as high as 80%. We usually reach out to them and ask them to turn 
off ECM and some transmit speed to 9600.  In response to some of the comments.

We have MGCP and SIP internally with 99.9% success rate.

We have both SIP to PRI  and SIP to SIP for external. Carrier is Level 3. We 
used to have AT but  had the same problem.

Outbound faxing from the Rightfax server is fine. It's only with inbound faxing 
that we have this problem. This is why I'm questioning a server setting. It 
doesn't make sense to me that the server would toss out the fax just because 
there was a single RTN message sent, especially when the packet capture shows 
the sending device complied with the message, slowed it's transmit speed and 
finished the fax without any further issue.

On the positive side, working on this over the past year has really helped me 
to build my FoIP skills, and faxing within the test of our network is rock 
solid 


On Thu, Apr 6, 2017 at 7:04 AM Scott Voll 
> wrote:
Wow Frank, that is a lot of troubleshooting, and a great run down.

Can I ask what your failure rate is?

We have about a 2-4% failure rate and have decided not to troubleshoot those as 
they tend to be a Telco issue between us and the sender.  We use a lot of toll 
bypass so if it doesn't work over a pri then we send it out another one.  
Usually fixes most of our problems ;-)

Scott


On Wed, Apr 5, 2017 at 5:06 PM, Frank Arrasmith 
> wrote:
Calling all Rightfax gurus,
   I have the following question regarding the Rightfax configuration and 
transmission errors.

Background:
My enterprise has CUCM 10.5 with a pretty dialed in Fax/T38 setup over SIP and 
MGCP gateways.  For the most part, faxing is pretty solid inbound and outbound 
to and from PSTN GW's, CUBEs, ,analog VG's, and regular fax machines(we have a 
lot).  We have a SIP trunk connected to Rightfax 10.5 server, which is managed 
by another group where we have limited access/experience with Rightfax 
configuration settings.  It took us awhile to get the Rightfax servers with the 
correct t38 setup because they had only run traditional CAS T1 prior to us, so 
it was new to everyone, but it is up and stable except for the following issue..
Symptom :
The problem we see with Rightfax is with Transmission errors.  It starts with 
our internal customers reporting that they do not receive a fax even when the 
sender receives confirmation.  Upon further review we see that the suspect call 
is listed as a "Transmission Error" in Rightfax, so the fax never gets 
delivered to the customers account/mailbox even though the call completes.
Analysis:
Since we are running T38, we can packet capture at the server, and  we see 
normal fax protocol exchange, except for the suspect calls where we see "RTN" 
Messages.  My understanding of the T.30 protocol is that when a RTN message is 
delivered to the sender, that is an indication for the sender to slow down and 
resend the last page. We actually see in the messages where the RTN message 
gets sent, and the sender complies with the notice, and sends again at 12000, 
then call completes as normal with an EOP message and a DCN message.  In these 
cases,the Rightfax team actually looks at the fax image and may see a bit of 
blurriness, but perfectly legible text ,even tho its still marked as 
transmission failure. We have asked them if there is a setting that can be 
tuned where the RTN does not cause the service to mark the transmission as 
failure. To this they reply, "It was working fine before when we were on CAS, 
so it must be on your end."

I understand where there are cases where the RTN message is sent because the 
call quality is actually terrible, but in those cases, there is usually several 
RTN messages and the sender will drop down to 4800 or below , and then usually 
give up and the call will fail.  This type of failure is rare (unless we have a 
major outage) and in this case the sending fax sees that it failed and will 
proceed with its normal retries.
Question:
Is this RTN to transmission failure hard coded, or is this a configurable 
setting?  If this were a regular fax machine, i think this would be a non issue 
as the receiver would see the crappy page as well as the good copy of 

Re: [cisco-voip] Question regarding Rightfax Configuration and "Transmission Error"

[Frank Arrasmith]

On average or failure rate is below 5%, however there are some senders with
failure rates as high as 80%. We usually reach out to them and ask them to
turn off ECM and some transmit speed to 9600.  In response to some of the
comments.

We have MGCP and SIP internally with 99.9% success rate.

We have both SIP to PRI  and SIP to SIP for external. Carrier is Level 3.
We used to have AT but  had the same problem.

Outbound faxing from the Rightfax server is fine. It's only with inbound
faxing that we have this problem. This is why I'm questioning a server
setting. It doesn't make sense to me that the server would toss out the fax
just because there was a single RTN message sent, especially when the
packet capture shows the sending device complied with the message, slowed
it's transmit speed and finished the fax without any further issue.

On the positive side, working on this over the past year has really helped
me to build my FoIP skills, and faxing within the test of our network is
rock solid 


On Thu, Apr 6, 2017 at 7:04 AM Scott Voll  wrote:

> Wow Frank, that is a lot of troubleshooting, and a great run down.
>
> Can I ask what your failure rate is?
>
> We have about a 2-4% failure rate and have decided not to troubleshoot
> those as they tend to be a Telco issue between us and the sender.  We use a
> lot of toll bypass so if it doesn't work over a pri then we send it out
> another one.  Usually fixes most of our problems ;-)
>
> Scott
>
>
> On Wed, Apr 5, 2017 at 5:06 PM, Frank Arrasmith  > wrote:
>
> Calling all Rightfax gurus,
>I have the following question regarding the Rightfax configuration and
> transmission errors.
>
> Background:
> My enterprise has CUCM 10.5 with a pretty dialed in Fax/T38 setup over SIP
> and MGCP gateways.  For the most part, faxing is pretty solid inbound and
> outbound to and from PSTN GW's, CUBEs, ,analog VG's, and regular fax
> machines(we have a lot).  We have a SIP trunk connected to Rightfax 10.5
> server, which is managed by another group where we have limited
> access/experience with Rightfax configuration settings.  It took us awhile
> to get the Rightfax servers with the correct t38 setup because they had
> only run traditional CAS T1 prior to us, so it was new to everyone, but it
> is up and stable except for the following issue..
>
> Symptom :
> The problem we see with Rightfax is with Transmission errors.  It starts
> with our internal customers reporting that they do not receive a fax even
> when the sender receives confirmation.  Upon further review we see that the
> suspect call is listed as a "Transmission Error" in Rightfax, so the fax
> never gets delivered to the customers account/mailbox even though the call
> completes.
>
> Analysis:
> Since we are running T38, we can packet capture at the server, and  we see
> normal fax protocol exchange, except for the suspect calls where we see
> "RTN" Messages.  My understanding of the T.30 protocol is that when a RTN
> message is delivered to the sender, that is an indication for the sender to
> slow down and resend the last page. We actually see in the messages where
> the RTN message gets sent, and the sender complies with the notice, and
> sends again at 12000, then call completes as normal with an EOP message and
> a DCN message.  In these cases,the Rightfax team actually looks at the fax
> image and may see a bit of blurriness, but perfectly legible text ,even tho
> its still marked as transmission failure. We have asked them if there is a
> setting that can be tuned where the RTN does not cause the service to mark
> the transmission as failure. To this they reply, "It was working fine
> before when we were on CAS, so it must be on your end."
>
> I understand where there are cases where the RTN message is sent because
> the call quality is actually terrible, but in those cases, there is usually
> several RTN messages and the sender will drop down to 4800 or below , and
> then usually give up and the call will fail.  This type of failure is rare
> (unless we have a major outage) and in this case the sending fax sees that
> it failed and will proceed with its normal retries.
>
> Question:
>
> Is this RTN to transmission failure hard coded, or is this a configurable
> setting?  If this were a regular fax machine, i think this would be a non
> issue as the receiver would see the crappy page as well as the good copy of
> that was sent again in their bundle of received pages.
>
> Any insight is greatly appreciated and for anyone just getting into FAX
> over IP with Cisco, I highly recommend the following book and Cisco Live
> presentations from these guys from Cisco TAC.
>
> Fax, Modem, and Text for IP Telephony [Book]
> 
> from Textbooks.com
> by David Hanes, Gonzalo Salgueiro
>
>
>
>
>
>
> Thanks,
>  

Re: [cisco-voip] Jabber Push Notifications for iPhone and iPad

[Brian Meade]

I doubt they'll allow admin access through it.  Probably just for internal
to external connections.  They added the CMS Web Proxy functions for WebRTC
then told everyone not to use it so who knows where they are going on
proxying inbound web.

On Thu, Apr 6, 2017 at 11:06 AM, Ryan Huff  wrote:

> O . vpn-less administration access  snazzy. Seems like that
> would fit within the Free/RTU Expressway model too.
>
> Ryan
>
> On Apr 6, 2017, at 11:01 AM, Brian Meade  wrote:
>
> Yea, they are describing anything in the cloud as that way now even if
> they aren't currently converged like Spark and WebEx.  It's specifically
> fos-a.wbx2.com according to the document.
>
> Word is they are adding an HTTP Proxy function to a future Expressway
> release so you don't have to allow CUCM to have direct internet access.
> Otherwise, you'll need your own web proxy.
>
> On Thu, Apr 6, 2017 at 10:52 AM, Ryan Huff  wrote:
>
>> Anthony, I think it is. When you log into the Spark admin portal it calls
>> itself "Cloud Collaboration Management Interface".
>>
>> I also think it is being used as a fluid moniker to describe all the
>> things that are being added and changed (like how the WebEx and Spark
>> backends are converging).
>>
>> Thanks,
>>
>> Ryan
>>
>> On Apr 6, 2017, at 10:45 AM, Anthony Holloway <
>> avholloway+cisco-v...@gmail.com> wrote:
>>
>> Can someone confirm if "Collaboration Cloud" is in fact the Spark
>> platform as a service?
>>
>> From the docs:
>>
>> *Cisco Communications Manager will need to register and stay connected to
>> Cisco Collaboration Cloud.*
>>
>> On Thu, Apr 6, 2017 at 1:48 AM bertacco.alessan...@alice.it <
>> bertacco.alessan...@alice.it> wrote:
>>
>>> Hi guys,
>>>I would discuss with you about the Apple iOS Phase1 and Phase2 and
>>> how Apple are changing the notification behaviour that impact on Jabber for
>>> iPhone and iPad.
>>>
>>> Here the Link: http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cuc
>>> m/im_presence/pushNotifications/11_5_1_su2/cucm_b_push-
>>> notification-deployment-iPhone-iPad/cucm_b_push-
>>> notification-deployment-for-apple_chapter_010.html
>>>
>>>
>>> Here and Extract on what's is going on.
>>>
>>>
>>> And a question for you, using Push notification at the end of Phase 2,
>>> make jabber fully functional when in Background, or for voice call we need
>>> to configure Single Number Reach? I don't understand that.
>>>
>>>
>>> Regards
>>>
>>> Alessandro
>>>
>>>
>>>
>>> Important Notice
>>>
>>> In alignment with Apple's changes to the iOS notification architecture,
>>> Cisco Jabber is in the process of implementing Apple Push Notification
>>> support for notifications. We highly recommend that customers upgrade Cisco
>>> Unified Communications Manager, IM and Presence Service, Cisco Expressway,
>>> and Cisco Jabber before September 2017. Failure to upgrade in a timely
>>> manner will result in loss of voice, video, and IM notifications for Jabber
>>> iOS users.
>>>
>>> IOS Push Notification support for Cisco Jabber will be delivered in
>>> phases. Phase 1 is for IM only, phase 2 adds push notification support for
>>> voice and video calls.
>>> Phase 1 Version Requirements
>>>
>>>-
>>>
>>>Cisco Unified Communications Manager and IM and Presence Service
>>>11.5(1)SU2, available Jan 23, 2017
>>>
>>>-
>>>
>>>Cisco Jabber 11.8.1, available Feb. 06, 2017
>>>
>>>-
>>>
>>>Cisco Expressway X8.9.1, available Jan. 30, 2017
>>>
>>>-
>>>
>>>Cisco Communications Manager to register and stay connected to Cisco
>>>Collaboration Cloud
>>>
>>>
>>> What to Expect Next
>>>
>>> Phase 2 will complete the updates for Push Notifications for voice and
>>> video calls in Jabber for iOS mid CY 2017. Upgrades to Cisco Unified
>>> Communications Manager, IM and Presence Service, Cisco Jabber, and Cisco
>>> Expressway will be required. Details around Phase 2 software versions will
>>> be published as part of the Phase 2 availability announcement.
>>> ___
>>> 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] Jabber Push Notifications for iPhone and iPad

[Ryan Huff]

O . vpn-less administration access  snazzy. Seems like that would 
fit within the Free/RTU Expressway model too.

Ryan

On Apr 6, 2017, at 11:01 AM, Brian Meade 
> wrote:

Yea, they are describing anything in the cloud as that way now even if they 
aren't currently converged like Spark and WebEx.  It's specifically 
fos-a.wbx2.com according to the document.

Word is they are adding an HTTP Proxy function to a future Expressway release 
so you don't have to allow CUCM to have direct internet access.  Otherwise, 
you'll need your own web proxy.

On Thu, Apr 6, 2017 at 10:52 AM, Ryan Huff 
> wrote:
Anthony, I think it is. When you log into the Spark admin portal it calls 
itself "Cloud Collaboration Management Interface".

I also think it is being used as a fluid moniker to describe all the things 
that are being added and changed (like how the WebEx and Spark backends are 
converging).

Thanks,

Ryan

On Apr 6, 2017, at 10:45 AM, Anthony Holloway 
> wrote:

Can someone confirm if "Collaboration Cloud" is in fact the Spark platform as a 
service?

From the docs:

Cisco Communications Manager will need to register and stay connected to Cisco 
Collaboration Cloud.

On Thu, Apr 6, 2017 at 1:48 AM 
bertacco.alessan...@alice.it 
> wrote:
Hi guys,
   I would discuss with you about the Apple iOS Phase1 and Phase2 and how Apple 
are changing the notification behaviour that impact on Jabber for iPhone and 
iPad.

Here the Link: 
http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/im_presence/pushNotifications/11_5_1_su2/cucm_b_push-notification-deployment-iPhone-iPad/cucm_b_push-notification-deployment-for-apple_chapter_010.html


Here and Extract on what's is going on.


And a question for you, using Push notification at the end of Phase 2, make 
jabber fully functional when in Background, or for voice call we need to 
configure Single Number Reach? I don't understand that.


Regards

Alessandro



Important Notice

In alignment with Apple's changes to the iOS notification architecture, Cisco 
Jabber is in the process of implementing Apple Push Notification support for 
notifications. We highly recommend that customers upgrade Cisco Unified 
Communications Manager, IM and Presence Service, Cisco Expressway, and Cisco 
Jabber before September 2017. Failure to upgrade in a timely manner will result 
in loss of voice, video, and IM notifications for Jabber iOS users.

IOS Push Notification support for Cisco Jabber will be delivered in phases. 
Phase 1 is for IM only, phase 2 adds push notification support for voice and 
video calls.

Phase 1 Version Requirements

  *

Cisco Unified Communications Manager and IM and Presence Service 11.5(1)SU2, 
available Jan 23, 2017

  *

Cisco Jabber 11.8.1, available Feb. 06, 2017

  *

Cisco Expressway X8.9.1, available Jan. 30, 2017

  *

Cisco Communications Manager to register and stay connected to Cisco 
Collaboration Cloud

What to Expect Next

Phase 2 will complete the updates for Push Notifications for voice and video 
calls in Jabber for iOS mid CY 2017. Upgrades to Cisco Unified Communications 
Manager, IM and Presence Service, Cisco Jabber, and Cisco Expressway will be 
required. Details around Phase 2 software versions will be published as part of 
the Phase 2 availability announcement.

___
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] Jabber Push Notifications for iPhone and iPad

[Brian Meade]

Yea, they are describing anything in the cloud as that way now even if they
aren't currently converged like Spark and WebEx.  It's specifically
fos-a.wbx2.com according to the document.

Word is they are adding an HTTP Proxy function to a future Expressway
release so you don't have to allow CUCM to have direct internet access.
Otherwise, you'll need your own web proxy.

On Thu, Apr 6, 2017 at 10:52 AM, Ryan Huff  wrote:

> Anthony, I think it is. When you log into the Spark admin portal it calls
> itself "Cloud Collaboration Management Interface".
>
> I also think it is being used as a fluid moniker to describe all the
> things that are being added and changed (like how the WebEx and Spark
> backends are converging).
>
> Thanks,
>
> Ryan
>
> On Apr 6, 2017, at 10:45 AM, Anthony Holloway <
> avholloway+cisco-v...@gmail.com> wrote:
>
> Can someone confirm if "Collaboration Cloud" is in fact the Spark platform
> as a service?
>
> From the docs:
>
> *Cisco Communications Manager will need to register and stay connected to
> Cisco Collaboration Cloud.*
>
> On Thu, Apr 6, 2017 at 1:48 AM bertacco.alessan...@alice.it <
> bertacco.alessan...@alice.it> wrote:
>
>> Hi guys,
>>I would discuss with you about the Apple iOS Phase1 and Phase2 and how
>> Apple are changing the notification behaviour that impact on Jabber for
>> iPhone and iPad.
>>
>> Here the Link: http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/
>> cucm/im_presence/pushNotifications/11_5_1_su2/cucm_b_push-notification-
>> deployment-iPhone-iPad/cucm_b_push-notification-deployment-
>> for-apple_chapter_010.html
>>
>>
>> Here and Extract on what's is going on.
>>
>>
>> And a question for you, using Push notification at the end of Phase 2,
>> make jabber fully functional when in Background, or for voice call we need
>> to configure Single Number Reach? I don't understand that.
>>
>>
>> Regards
>>
>> Alessandro
>>
>>
>>
>> Important Notice
>>
>> In alignment with Apple's changes to the iOS notification architecture,
>> Cisco Jabber is in the process of implementing Apple Push Notification
>> support for notifications. We highly recommend that customers upgrade Cisco
>> Unified Communications Manager, IM and Presence Service, Cisco Expressway,
>> and Cisco Jabber before September 2017. Failure to upgrade in a timely
>> manner will result in loss of voice, video, and IM notifications for Jabber
>> iOS users.
>>
>> IOS Push Notification support for Cisco Jabber will be delivered in
>> phases. Phase 1 is for IM only, phase 2 adds push notification support for
>> voice and video calls.
>> Phase 1 Version Requirements
>>
>>-
>>
>>Cisco Unified Communications Manager and IM and Presence Service
>>11.5(1)SU2, available Jan 23, 2017
>>
>>-
>>
>>Cisco Jabber 11.8.1, available Feb. 06, 2017
>>
>>-
>>
>>Cisco Expressway X8.9.1, available Jan. 30, 2017
>>
>>-
>>
>>Cisco Communications Manager to register and stay connected to Cisco
>>Collaboration Cloud
>>
>>
>> What to Expect Next
>>
>> Phase 2 will complete the updates for Push Notifications for voice and
>> video calls in Jabber for iOS mid CY 2017. Upgrades to Cisco Unified
>> Communications Manager, IM and Presence Service, Cisco Jabber, and Cisco
>> Expressway will be required. Details around Phase 2 software versions will
>> be published as part of the Phase 2 availability announcement.
>> ___
>> 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] Jabber Push Notifications for iPhone and iPad

[Ryan Huff]

Anthony, I think it is. When you log into the Spark admin portal it calls 
itself "Cloud Collaboration Management Interface".

I also think it is being used as a fluid moniker to describe all the things 
that are being added and changed (like how the WebEx and Spark backends are 
converging).

Thanks,

Ryan

On Apr 6, 2017, at 10:45 AM, Anthony Holloway 
> wrote:

Can someone confirm if "Collaboration Cloud" is in fact the Spark platform as a 
service?

From the docs:

Cisco Communications Manager will need to register and stay connected to Cisco 
Collaboration Cloud.

On Thu, Apr 6, 2017 at 1:48 AM 
bertacco.alessan...@alice.it 
> wrote:
Hi guys,
   I would discuss with you about the Apple iOS Phase1 and Phase2 and how Apple 
are changing the notification behaviour that impact on Jabber for iPhone and 
iPad.

Here the Link: 
http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/im_presence/pushNotifications/11_5_1_su2/cucm_b_push-notification-deployment-iPhone-iPad/cucm_b_push-notification-deployment-for-apple_chapter_010.html


Here and Extract on what's is going on.


And a question for you, using Push notification at the end of Phase 2, make 
jabber fully functional when in Background, or for voice call we need to 
configure Single Number Reach? I don't understand that.


Regards

Alessandro



Important Notice

In alignment with Apple's changes to the iOS notification architecture, Cisco 
Jabber is in the process of implementing Apple Push Notification support for 
notifications. We highly recommend that customers upgrade Cisco Unified 
Communications Manager, IM and Presence Service, Cisco Expressway, and Cisco 
Jabber before September 2017. Failure to upgrade in a timely manner will result 
in loss of voice, video, and IM notifications for Jabber iOS users.

IOS Push Notification support for Cisco Jabber will be delivered in phases. 
Phase 1 is for IM only, phase 2 adds push notification support for voice and 
video calls.

Phase 1 Version Requirements

  *

Cisco Unified Communications Manager and IM and Presence Service 11.5(1)SU2, 
available Jan 23, 2017

  *

Cisco Jabber 11.8.1, available Feb. 06, 2017

  *

Cisco Expressway X8.9.1, available Jan. 30, 2017

  *

Cisco Communications Manager to register and stay connected to Cisco 
Collaboration Cloud

What to Expect Next

Phase 2 will complete the updates for Push Notifications for voice and video 
calls in Jabber for iOS mid CY 2017. Upgrades to Cisco Unified Communications 
Manager, IM and Presence Service, Cisco Jabber, and Cisco Expressway will be 
required. Details around Phase 2 software versions will be published as part of 
the Phase 2 availability announcement.

___
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] Question regarding Rightfax Configuration and "Transmission Error"

[Justin Steinberg]

I use t38 over AT just fine

On Thu, Apr 6, 2017 at 10:37 AM, Brian Meade  wrote:

> I've got SIP with T.38 as well as PRI in different environments that are
> all working pretty well with that setup.
>
> On Thu, Apr 6, 2017 at 10:24 AM, Haas, Neal  wrote:
>
>> Do you use SIP or PRI, we use PRI 99.9% of the time, ATT does not allow
>> T.38 over SIP.
>>
>>
>>
>> I will likely get a SIP trunk from Comcast or Time Warner in the future,
>> they both do T.38 over SIP. Both say they can do Faxes without issue.
>>
>>
>>
>> Thank You,
>>
>>
>>
>> Neal Haas
>>
>>
>>
>> *From:* cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] *On
>> Behalf Of *Brian Meade
>> *Sent:* Thursday, April 6, 2017 7:09 AM
>> *To:* Frank Arrasmith 
>> *Cc:* cisco-voip@puck.nether.net
>> *Subject:* Re: [cisco-voip] Question regarding Rightfax Configuration
>> and "Transmission Error"
>>
>>
>>
>> I've had the most luck turning ECM off and running RightFax at only
>> 9600.  Faxes are slower but usually higher quality and less failures.
>>
>>
>>
>> On Wed, Apr 5, 2017 at 8:06 PM, Frank Arrasmith <
>> frank.arrasm...@gmail.com> wrote:
>>
>> Calling all Rightfax gurus,
>>
>>I have the following question regarding the Rightfax configuration and
>> transmission errors.
>>
>> Background:
>> My enterprise has CUCM 10.5 with a pretty dialed in Fax/T38 setup over
>> SIP and MGCP gateways.  For the most part, faxing is pretty solid inbound
>> and outbound to and from PSTN GW's, CUBEs, ,analog VG's, and regular fax
>> machines(we have a lot).  We have a SIP trunk connected to Rightfax 10.5
>> server, which is managed by another group where we have limited
>> access/experience with Rightfax configuration settings.  It took us awhile
>> to get the Rightfax servers with the correct t38 setup because they had
>> only run traditional CAS T1 prior to us, so it was new to everyone, but it
>> is up and stable except for the following issue..
>>
>> Symptom :
>>
>> The problem we see with Rightfax is with Transmission errors.  It starts
>> with our internal customers reporting that they do not receive a fax even
>> when the sender receives confirmation.  Upon further review we see that the
>> suspect call is listed as a "Transmission Error" in Rightfax, so the fax
>> never gets delivered to the customers account/mailbox even though the call
>> completes.
>>
>> Analysis:
>>
>> Since we are running T38, we can packet capture at the server, and  we
>> see normal fax protocol exchange, except for the suspect calls where we see
>> "RTN" Messages.  My understanding of the T.30 protocol is that when a RTN
>> message is delivered to the sender, that is an indication for the sender to
>> slow down and resend the last page. We actually see in the messages where
>> the RTN message gets sent, and the sender complies with the notice, and
>> sends again at 12000, then call completes as normal with an EOP message and
>> a DCN message.  In these cases,the Rightfax team actually looks at the fax
>> image and may see a bit of blurriness, but perfectly legible text ,even tho
>> its still marked as transmission failure. We have asked them if there is a
>> setting that can be tuned where the RTN does not cause the service to mark
>> the transmission as failure. To this they reply, "It was working fine
>> before when we were on CAS, so it must be on your end."
>>
>> I understand where there are cases where the RTN message is sent because
>> the call quality is actually terrible, but in those cases, there is usually
>> several RTN messages and the sender will drop down to 4800 or below , and
>> then usually give up and the call will fail.  This type of failure is rare
>> (unless we have a major outage) and in this case the sending fax sees that
>> it failed and will proceed with its normal retries.
>>
>> Question:
>>
>> Is this RTN to transmission failure hard coded, or is this a configurable
>> setting?  If this were a regular fax machine, i think this would be a non
>> issue as the receiver would see the crappy page as well as the good copy of
>> that was sent again in their bundle of received pages.
>>
>> Any insight is greatly appreciated and for anyone just getting into FAX
>> over IP with Cisco, I highly recommend the following book and Cisco Live
>> presentations from these guys from Cisco TAC.
>>
>> Fax, Modem, and Text for IP Telephony [Book]
>> 
>>
>> from Textbooks.com
>>
>> by David Hanes, Gonzalo Salgueiro
>>
>>
>>
>>
>>
>> Thanks,
>>
>>  Frank
>>
>>
>> ___
>> 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] Jabber Push Notifications for iPhone and iPad

[Matthew Loraditch]

Well I can say it doesn’t require a spark account or anything of the sort. I 
can’t say whether it’s the same server farm or something of that nature. I 
wouldn’t be surprised if it wasn’t somehow.

Matthew G. Loraditch – CCNP-Voice, CCNA-R, CCDA
Network Engineer
Direct Voice: 443.541.1518

Facebook | 
Twitter | 
LinkedIn 
| G+

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of 
Anthony Holloway
Sent: Thursday, April 6, 2017 10:44 AM
To: bertacco.alessan...@alice.it; cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] Jabber Push Notifications for iPhone and iPad

Can someone confirm if "Collaboration Cloud" is in fact the Spark platform as a 
service?

From the docs:

Cisco Communications Manager will need to register and stay connected to Cisco 
Collaboration Cloud.

On Thu, Apr 6, 2017 at 1:48 AM 
bertacco.alessan...@alice.it 
> wrote:
Hi guys,
   I would discuss with you about the Apple iOS Phase1 and Phase2 and how Apple 
are changing the notification behaviour that impact on Jabber for iPhone and 
iPad.

Here the Link: 
http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/im_presence/pushNotifications/11_5_1_su2/cucm_b_push-notification-deployment-iPhone-iPad/cucm_b_push-notification-deployment-for-apple_chapter_010.html


Here and Extract on what's is going on.


And a question for you, using Push notification at the end of Phase 2, make 
jabber fully functional when in Background, or for voice call we need to 
configure Single Number Reach? I don't understand that.


Regards

Alessandro



Important Notice

In alignment with Apple's changes to the iOS notification architecture, Cisco 
Jabber is in the process of implementing Apple Push Notification support for 
notifications. We highly recommend that customers upgrade Cisco Unified 
Communications Manager, IM and Presence Service, Cisco Expressway, and Cisco 
Jabber before September 2017. Failure to upgrade in a timely manner will result 
in loss of voice, video, and IM notifications for Jabber iOS users.

IOS Push Notification support for Cisco Jabber will be delivered in phases. 
Phase 1 is for IM only, phase 2 adds push notification support for voice and 
video calls.

Phase 1 Version Requirements

· Cisco Unified Communications Manager and IM and Presence Service 
11.5(1)SU2, available Jan 23, 2017

· Cisco Jabber 11.8.1, available Feb. 06, 2017

· Cisco Expressway X8.9.1, available Jan. 30, 2017

· Cisco Communications Manager to register and stay connected to Cisco 
Collaboration Cloud

What to Expect Next

Phase 2 will complete the updates for Push Notifications for voice and video 
calls in Jabber for iOS mid CY 2017. Upgrades to Cisco Unified Communications 
Manager, IM and Presence Service, Cisco Jabber, and Cisco Expressway will be 
required. Details around Phase 2 software versions will be published as part of 
the Phase 2 availability announcement.
___
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] Jabber Push Notifications for iPhone and iPad

[Anthony Holloway]

Can someone confirm if "Collaboration Cloud" is in fact the Spark platform
as a service?

>From the docs:

*Cisco Communications Manager will need to register and stay connected to
Cisco Collaboration Cloud.*

On Thu, Apr 6, 2017 at 1:48 AM bertacco.alessan...@alice.it <
bertacco.alessan...@alice.it> wrote:

> Hi guys,
>I would discuss with you about the Apple iOS Phase1 and Phase2 and how
> Apple are changing the notification behaviour that impact on Jabber for
> iPhone and iPad.
>
> Here the Link:
> http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/im_presence/pushNotifications/11_5_1_su2/cucm_b_push-notification-deployment-iPhone-iPad/cucm_b_push-notification-deployment-for-apple_chapter_010.html
>
>
> Here and Extract on what's is going on.
>
>
> And a question for you, using Push notification at the end of Phase 2,
> make jabber fully functional when in Background, or for voice call we need
> to configure Single Number Reach? I don't understand that.
>
>
> Regards
>
> Alessandro
>
>
>
> Important Notice
>
> In alignment with Apple's changes to the iOS notification architecture,
> Cisco Jabber is in the process of implementing Apple Push Notification
> support for notifications. We highly recommend that customers upgrade Cisco
> Unified Communications Manager, IM and Presence Service, Cisco Expressway,
> and Cisco Jabber before September 2017. Failure to upgrade in a timely
> manner will result in loss of voice, video, and IM notifications for Jabber
> iOS users.
>
> IOS Push Notification support for Cisco Jabber will be delivered in
> phases. Phase 1 is for IM only, phase 2 adds push notification support for
> voice and video calls.
> Phase 1 Version Requirements
>
>-
>
>Cisco Unified Communications Manager and IM and Presence Service
>11.5(1)SU2, available Jan 23, 2017
>
>-
>
>Cisco Jabber 11.8.1, available Feb. 06, 2017
>
>-
>
>Cisco Expressway X8.9.1, available Jan. 30, 2017
>
>-
>
>Cisco Communications Manager to register and stay connected to Cisco
>Collaboration Cloud
>
>
> What to Expect Next
>
> Phase 2 will complete the updates for Push Notifications for voice and
> video calls in Jabber for iOS mid CY 2017. Upgrades to Cisco Unified
> Communications Manager, IM and Presence Service, Cisco Jabber, and Cisco
> Expressway will be required. Details around Phase 2 software versions will
> be published as part of the Phase 2 availability announcement.
> ___
> 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] Question regarding Rightfax Configuration and "Transmission Error"

[Brian Meade]

I've got SIP with T.38 as well as PRI in different environments that are
all working pretty well with that setup.

On Thu, Apr 6, 2017 at 10:24 AM, Haas, Neal  wrote:

> Do you use SIP or PRI, we use PRI 99.9% of the time, ATT does not allow
> T.38 over SIP.
>
>
>
> I will likely get a SIP trunk from Comcast or Time Warner in the future,
> they both do T.38 over SIP. Both say they can do Faxes without issue.
>
>
>
> Thank You,
>
>
>
> Neal Haas
>
>
>
> *From:* cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] *On Behalf
> Of *Brian Meade
> *Sent:* Thursday, April 6, 2017 7:09 AM
> *To:* Frank Arrasmith 
> *Cc:* cisco-voip@puck.nether.net
> *Subject:* Re: [cisco-voip] Question regarding Rightfax Configuration and
> "Transmission Error"
>
>
>
> I've had the most luck turning ECM off and running RightFax at only 9600.
> Faxes are slower but usually higher quality and less failures.
>
>
>
> On Wed, Apr 5, 2017 at 8:06 PM, Frank Arrasmith 
> wrote:
>
> Calling all Rightfax gurus,
>
>I have the following question regarding the Rightfax configuration and
> transmission errors.
>
> Background:
> My enterprise has CUCM 10.5 with a pretty dialed in Fax/T38 setup over SIP
> and MGCP gateways.  For the most part, faxing is pretty solid inbound and
> outbound to and from PSTN GW's, CUBEs, ,analog VG's, and regular fax
> machines(we have a lot).  We have a SIP trunk connected to Rightfax 10.5
> server, which is managed by another group where we have limited
> access/experience with Rightfax configuration settings.  It took us awhile
> to get the Rightfax servers with the correct t38 setup because they had
> only run traditional CAS T1 prior to us, so it was new to everyone, but it
> is up and stable except for the following issue..
>
> Symptom :
>
> The problem we see with Rightfax is with Transmission errors.  It starts
> with our internal customers reporting that they do not receive a fax even
> when the sender receives confirmation.  Upon further review we see that the
> suspect call is listed as a "Transmission Error" in Rightfax, so the fax
> never gets delivered to the customers account/mailbox even though the call
> completes.
>
> Analysis:
>
> Since we are running T38, we can packet capture at the server, and  we see
> normal fax protocol exchange, except for the suspect calls where we see
> "RTN" Messages.  My understanding of the T.30 protocol is that when a RTN
> message is delivered to the sender, that is an indication for the sender to
> slow down and resend the last page. We actually see in the messages where
> the RTN message gets sent, and the sender complies with the notice, and
> sends again at 12000, then call completes as normal with an EOP message and
> a DCN message.  In these cases,the Rightfax team actually looks at the fax
> image and may see a bit of blurriness, but perfectly legible text ,even tho
> its still marked as transmission failure. We have asked them if there is a
> setting that can be tuned where the RTN does not cause the service to mark
> the transmission as failure. To this they reply, "It was working fine
> before when we were on CAS, so it must be on your end."
>
> I understand where there are cases where the RTN message is sent because
> the call quality is actually terrible, but in those cases, there is usually
> several RTN messages and the sender will drop down to 4800 or below , and
> then usually give up and the call will fail.  This type of failure is rare
> (unless we have a major outage) and in this case the sending fax sees that
> it failed and will proceed with its normal retries.
>
> Question:
>
> Is this RTN to transmission failure hard coded, or is this a configurable
> setting?  If this were a regular fax machine, i think this would be a non
> issue as the receiver would see the crappy page as well as the good copy of
> that was sent again in their bundle of received pages.
>
> Any insight is greatly appreciated and for anyone just getting into FAX
> over IP with Cisco, I highly recommend the following book and Cisco Live
> presentations from these guys from Cisco TAC.
>
> Fax, Modem, and Text for IP Telephony [Book]
> 
>
> from Textbooks.com
>
> by David Hanes, Gonzalo Salgueiro
>
>
>
>
>
> Thanks,
>
>  Frank
>
>
> ___
> 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] Question regarding Rightfax Configuration and "Transmission Error"

[Haas, Neal]

Do you use SIP or PRI, we use PRI 99.9% of the time, ATT does not allow T.38 
over SIP.

I will likely get a SIP trunk from Comcast or Time Warner in the future, they 
both do T.38 over SIP. Both say they can do Faxes without issue.

Thank You,

Neal Haas

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of Brian 
Meade
Sent: Thursday, April 6, 2017 7:09 AM
To: Frank Arrasmith 
Cc: cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] Question regarding Rightfax Configuration and 
"Transmission Error"

I've had the most luck turning ECM off and running RightFax at only 9600.  
Faxes are slower but usually higher quality and less failures.

On Wed, Apr 5, 2017 at 8:06 PM, Frank Arrasmith 
> wrote:
Calling all Rightfax gurus,
   I have the following question regarding the Rightfax configuration and 
transmission errors.

Background:
My enterprise has CUCM 10.5 with a pretty dialed in Fax/T38 setup over SIP and 
MGCP gateways.  For the most part, faxing is pretty solid inbound and outbound 
to and from PSTN GW's, CUBEs, ,analog VG's, and regular fax machines(we have a 
lot).  We have a SIP trunk connected to Rightfax 10.5 server, which is managed 
by another group where we have limited access/experience with Rightfax 
configuration settings.  It took us awhile to get the Rightfax servers with the 
correct t38 setup because they had only run traditional CAS T1 prior to us, so 
it was new to everyone, but it is up and stable except for the following issue..
Symptom :
The problem we see with Rightfax is with Transmission errors.  It starts with 
our internal customers reporting that they do not receive a fax even when the 
sender receives confirmation.  Upon further review we see that the suspect call 
is listed as a "Transmission Error" in Rightfax, so the fax never gets 
delivered to the customers account/mailbox even though the call completes.
Analysis:
Since we are running T38, we can packet capture at the server, and  we see 
normal fax protocol exchange, except for the suspect calls where we see "RTN" 
Messages.  My understanding of the T.30 protocol is that when a RTN message is 
delivered to the sender, that is an indication for the sender to slow down and 
resend the last page. We actually see in the messages where the RTN message 
gets sent, and the sender complies with the notice, and sends again at 12000, 
then call completes as normal with an EOP message and a DCN message.  In these 
cases,the Rightfax team actually looks at the fax image and may see a bit of 
blurriness, but perfectly legible text ,even tho its still marked as 
transmission failure. We have asked them if there is a setting that can be 
tuned where the RTN does not cause the service to mark the transmission as 
failure. To this they reply, "It was working fine before when we were on CAS, 
so it must be on your end."

I understand where there are cases where the RTN message is sent because the 
call quality is actually terrible, but in those cases, there is usually several 
RTN messages and the sender will drop down to 4800 or below , and then usually 
give up and the call will fail.  This type of failure is rare (unless we have a 
major outage) and in this case the sending fax sees that it failed and will 
proceed with its normal retries.
Question:
Is this RTN to transmission failure hard coded, or is this a configurable 
setting?  If this were a regular fax machine, i think this would be a non issue 
as the receiver would see the crappy page as well as the good copy of that was 
sent again in their bundle of received pages.
Any insight is greatly appreciated and for anyone just getting into FAX over IP 
with Cisco, I highly recommend the following book and Cisco Live presentations 
from these guys from Cisco TAC.

Fax, Modem, and Text for IP Telephony 
[Book]
from Textbooks.com
by David Hanes, Gonzalo Salgueiro





Thanks,
 Frank


___
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] Question regarding Rightfax Configuration and "Transmission Error"

[Brian Meade]

I've had the most luck turning ECM off and running RightFax at only 9600.
Faxes are slower but usually higher quality and less failures.

On Wed, Apr 5, 2017 at 8:06 PM, Frank Arrasmith 
wrote:

> Calling all Rightfax gurus,
>I have the following question regarding the Rightfax configuration and
> transmission errors.
>
> Background:
> My enterprise has CUCM 10.5 with a pretty dialed in Fax/T38 setup over SIP
> and MGCP gateways.  For the most part, faxing is pretty solid inbound and
> outbound to and from PSTN GW's, CUBEs, ,analog VG's, and regular fax
> machines(we have a lot).  We have a SIP trunk connected to Rightfax 10.5
> server, which is managed by another group where we have limited
> access/experience with Rightfax configuration settings.  It took us awhile
> to get the Rightfax servers with the correct t38 setup because they had
> only run traditional CAS T1 prior to us, so it was new to everyone, but it
> is up and stable except for the following issue..
>
> Symptom :
> The problem we see with Rightfax is with Transmission errors.  It starts
> with our internal customers reporting that they do not receive a fax even
> when the sender receives confirmation.  Upon further review we see that the
> suspect call is listed as a "Transmission Error" in Rightfax, so the fax
> never gets delivered to the customers account/mailbox even though the call
> completes.
>
> Analysis:
> Since we are running T38, we can packet capture at the server, and  we see
> normal fax protocol exchange, except for the suspect calls where we see
> "RTN" Messages.  My understanding of the T.30 protocol is that when a RTN
> message is delivered to the sender, that is an indication for the sender to
> slow down and resend the last page. We actually see in the messages where
> the RTN message gets sent, and the sender complies with the notice, and
> sends again at 12000, then call completes as normal with an EOP message and
> a DCN message.  In these cases,the Rightfax team actually looks at the fax
> image and may see a bit of blurriness, but perfectly legible text ,even tho
> its still marked as transmission failure. We have asked them if there is a
> setting that can be tuned where the RTN does not cause the service to mark
> the transmission as failure. To this they reply, "It was working fine
> before when we were on CAS, so it must be on your end."
>
> I understand where there are cases where the RTN message is sent because
> the call quality is actually terrible, but in those cases, there is usually
> several RTN messages and the sender will drop down to 4800 or below , and
> then usually give up and the call will fail.  This type of failure is rare
> (unless we have a major outage) and in this case the sending fax sees that
> it failed and will proceed with its normal retries.
>
> Question:
>
> Is this RTN to transmission failure hard coded, or is this a configurable
> setting?  If this were a regular fax machine, i think this would be a non
> issue as the receiver would see the crappy page as well as the good copy of
> that was sent again in their bundle of received pages.
>
> Any insight is greatly appreciated and for anyone just getting into FAX
> over IP with Cisco, I highly recommend the following book and Cisco Live
> presentations from these guys from Cisco TAC.
>
> Fax, Modem, and Text for IP Telephony [Book]
> 
> from Textbooks.com
> by David Hanes, Gonzalo Salgueiro
>
>
>
>
>
>
> Thanks,
>  Frank
>
>
>
> ___
> 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] Question regarding Rightfax Configuration and "Transmission Error"

[Scott Voll]

Wow Frank, that is a lot of troubleshooting, and a great run down.

Can I ask what your failure rate is?

We have about a 2-4% failure rate and have decided not to troubleshoot
those as they tend to be a Telco issue between us and the sender.  We use a
lot of toll bypass so if it doesn't work over a pri then we send it out
another one.  Usually fixes most of our problems ;-)

Scott


On Wed, Apr 5, 2017 at 5:06 PM, Frank Arrasmith 
wrote:

> Calling all Rightfax gurus,
>I have the following question regarding the Rightfax configuration and
> transmission errors.
>
> Background:
> My enterprise has CUCM 10.5 with a pretty dialed in Fax/T38 setup over SIP
> and MGCP gateways.  For the most part, faxing is pretty solid inbound and
> outbound to and from PSTN GW's, CUBEs, ,analog VG's, and regular fax
> machines(we have a lot).  We have a SIP trunk connected to Rightfax 10.5
> server, which is managed by another group where we have limited
> access/experience with Rightfax configuration settings.  It took us awhile
> to get the Rightfax servers with the correct t38 setup because they had
> only run traditional CAS T1 prior to us, so it was new to everyone, but it
> is up and stable except for the following issue..
>
> Symptom :
> The problem we see with Rightfax is with Transmission errors.  It starts
> with our internal customers reporting that they do not receive a fax even
> when the sender receives confirmation.  Upon further review we see that the
> suspect call is listed as a "Transmission Error" in Rightfax, so the fax
> never gets delivered to the customers account/mailbox even though the call
> completes.
>
> Analysis:
> Since we are running T38, we can packet capture at the server, and  we see
> normal fax protocol exchange, except for the suspect calls where we see
> "RTN" Messages.  My understanding of the T.30 protocol is that when a RTN
> message is delivered to the sender, that is an indication for the sender to
> slow down and resend the last page. We actually see in the messages where
> the RTN message gets sent, and the sender complies with the notice, and
> sends again at 12000, then call completes as normal with an EOP message and
> a DCN message.  In these cases,the Rightfax team actually looks at the fax
> image and may see a bit of blurriness, but perfectly legible text ,even tho
> its still marked as transmission failure. We have asked them if there is a
> setting that can be tuned where the RTN does not cause the service to mark
> the transmission as failure. To this they reply, "It was working fine
> before when we were on CAS, so it must be on your end."
>
> I understand where there are cases where the RTN message is sent because
> the call quality is actually terrible, but in those cases, there is usually
> several RTN messages and the sender will drop down to 4800 or below , and
> then usually give up and the call will fail.  This type of failure is rare
> (unless we have a major outage) and in this case the sending fax sees that
> it failed and will proceed with its normal retries.
>
> Question:
>
> Is this RTN to transmission failure hard coded, or is this a configurable
> setting?  If this were a regular fax machine, i think this would be a non
> issue as the receiver would see the crappy page as well as the good copy of
> that was sent again in their bundle of received pages.
>
> Any insight is greatly appreciated and for anyone just getting into FAX
> over IP with Cisco, I highly recommend the following book and Cisco Live
> presentations from these guys from Cisco TAC.
>
> Fax, Modem, and Text for IP Telephony [Book]
> 
> from Textbooks.com
> by David Hanes, Gonzalo Salgueiro
>
>
>
>
>
>
> Thanks,
>  Frank
>
>
>
> ___
> 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 10.6.1 SU2 and VMware

[Ed Leatherman]

Jose, are you upgrading just vCenter, or are you upgrading vCenter as well
as your vSphere version on the esxi hosts?

You could likely run vCenter 6.5 and run vSphere 5.5 or 6.0 on your hosts
that have UCCX on them.

On Wed, Apr 5, 2017 at 11:12 PM, Abhiram Kramadhati (akramadh) <
akram...@cisco.com> wrote:

> UCCX 11.6 will support ESXi 6.5
>
>
>
> Regards,
>
> Abhiram Kramadhati
>
> Technical Solutions Manager, CCBU
>
> CCIE Collaboration # 40065
>
>
>
>
>
>
>
> *From: *cisco-voip  on behalf of Jose
> Colon II 
> *Reply-To: *"jcolon...@gmail.com" 
> *Date: *Thursday, 6 April 2017 at 2:19 AM
> *To: *Matthew Loraditch 
> *Cc: *Cisco VOIP 
> *Subject: *Re: [cisco-voip] UCCX 10.6.1 SU2 and VMware
>
>
>
> Thank you for that! Appreciate it.
>
>
>
> On Wed, Apr 5, 2017 at 3:46 PM, Matthew Loraditch  heliontechnologies.com> wrote:
>
> ESXi 6.5 is not yet compatible with any Cisco Voice software.
>
> http://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/uc_
> system/virtualization/cisco-collaboration-virtualization.html
>
>
>
> Matthew G. Loraditch – CCNP-Voice, CCNA-R, CCDA
> Network Engineer
> Direct Voice: 443.541.1518 <(443)%20541-1518>
>
> Facebook  | Twitter
>  | LinkedIn
>  |
> G+ 
>
>
>
> *From:* cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] *On Behalf
> Of *Jose Colon II
> *Sent:* Wednesday, April 5, 2017 4:41 PM
> *To:* Cisco VOIP 
> *Subject:* [cisco-voip] UCCX 10.6.1 SU2 and VMware
>
>
>
> We are going to be upgrading our VMware environment from vCenter 5.5 to
> 6.5 and can not find any specific information on compatibility with UCCX
> 10.6.1 SU2 for this. Is this compatible?
>
>
>
> Any help with this is appreciated.
>
>
>
> Thanks
>
>
>
> ___
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>


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

Re: [cisco-voip] Jabber Push Notifications for iPhone and iPad

[Erick Bergquist]

I believe that part of document is describing phase 1 behavior which
supports only IM notifications via push notification. You would need single
number reach to receive voice calls on iPhone in phase 1.

Looks like the document does not really cover phase 2 configuration as that
version is not available / out yet.


On Thu, Apr 6, 2017 at 12:48 AM bertacco.alessan...@alice.it <
bertacco.alessan...@alice.it> wrote:

> Hi guys,
>I would discuss with you about the Apple iOS Phase1 and Phase2 and how
> Apple are changing the notification behaviour that impact on Jabber for
> iPhone and iPad.
>
> Here the Link:
> http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/im_presence/pushNotifications/11_5_1_su2/cucm_b_push-notification-deployment-iPhone-iPad/cucm_b_push-notification-deployment-for-apple_chapter_010.html
>
>
> Here and Extract on what's is going on.
>
>
> And a question for you, using Push notification at the end of Phase 2,
> make jabber fully functional when in Background, or for voice call we need
> to configure Single Number Reach? I don't understand that.
>
>
> Regards
>
> Alessandro
>
>
>
> Important Notice
>
> In alignment with Apple's changes to the iOS notification architecture,
> Cisco Jabber is in the process of implementing Apple Push Notification
> support for notifications. We highly recommend that customers upgrade Cisco
> Unified Communications Manager, IM and Presence Service, Cisco Expressway,
> and Cisco Jabber before September 2017. Failure to upgrade in a timely
> manner will result in loss of voice, video, and IM notifications for Jabber
> iOS users.
>
> IOS Push Notification support for Cisco Jabber will be delivered in
> phases. Phase 1 is for IM only, phase 2 adds push notification support for
> voice and video calls.
> Phase 1 Version Requirements
>
>-
>
>Cisco Unified Communications Manager and IM and Presence Service
>11.5(1)SU2, available Jan 23, 2017
>
>-
>
>Cisco Jabber 11.8.1, available Feb. 06, 2017
>
>-
>
>Cisco Expressway X8.9.1, available Jan. 30, 2017
>
>-
>
>Cisco Communications Manager to register and stay connected to Cisco
>Collaboration Cloud
>
>
> What to Expect Next
>
> Phase 2 will complete the updates for Push Notifications for voice and
> video calls in Jabber for iOS mid CY 2017. Upgrades to Cisco Unified
> Communications Manager, IM and Presence Service, Cisco Jabber, and Cisco
> Expressway will be required. Details around Phase 2 software versions will
> be published as part of the Phase 2 availability announcement.
> ___
> 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] sip authentication

[samaneh ebrahimi]

Hi.
I want config authentication between 2 routers (config 1) or router and
Free PBX (config 2) .
config 1 is show following :


*router's config*

voice service voip
 allow-connection sip to sip
!
dial-peer voice 1 voip
decryption connection between two routers
destination-pattern 1.+
session target ipv4:y.y.y.y
session protocol sipv2
codec g711alaw
!
sip-ua
registrar ipv4:y.y.y.y
authentication username test password test1

both routers have this config and config2 is :

PBX:

[trunk55]
type=peer
host=X.x.x.x (router ip)
secret=test1
username=test
qualify=yes
context=from-trunk
disallow=all
allow=alaw
directmedia=yes

by this config i have connected calls and by omit authentication from one
site , i have calls too.
i think this is solution for sip trunk authentication (without have ipsec
tunnel for encrypt rtp packets. ).
please help me.
thanks a lot.
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

[cisco-voip] Jabber Push Notifications for iPhone and iPad

[bertacco.alessan...@alice.it]

Hi guys,   I would discuss with you about the Apple iOS Phase1 and Phase2 and 
how Apple are changing the notification behaviour that impact on Jabber for 
iPhone and iPad.
Here the Link: 
http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/im_presence/pushNotifications/11_5_1_su2/cucm_b_push-notification-deployment-iPhone-iPad/cucm_b_push-notification-deployment-for-apple_chapter_010.html

Here and Extract on what's is going on.

And a question for you, using Push notification at the end of Phase 2, make 
jabber fully functional when in Background, or for voice call we need to 
configure Single Number Reach? I don't understand that.

Regards
Alessandro


Important NoticeIn alignment with Apple's changes to the iOS notification 
architecture, Cisco Jabber is in the process of implementing Apple Push 
Notification support for notifications. We highly recommend that customers 
upgrade Cisco Unified Communications Manager, IM and Presence Service, Cisco 
Expressway, and Cisco Jabber before September 2017. Failure to upgrade in a 
timely manner will result in loss of voice, video, and IM notifications for 
Jabber iOS users.IOS Push Notification support for Cisco Jabber will be 
delivered in phases. Phase 1 is for IM only, phase 2 adds push notification 
support for voice and video calls.Phase 1 Version RequirementsCisco Unified 
Communications Manager and IM and Presence Service 11.5(1)SU2, available Jan 
23, 2017Cisco Jabber 11.8.1, available Feb. 06, 2017Cisco Expressway X8.9.1, 
available Jan. 30, 2017Cisco Communications Manager to register and stay 
connected to Cisco Collaboration CloudWhat to Expect NextPhase 2 will complete 
the updates for Push Notifications for voice and video calls in Jabber for iOS 
mid CY 2017. Upgrades to Cisco Unified Communications Manager, IM and Presence 
Service, Cisco Jabber, and Cisco Expressway will be required. Details around 
Phase 2 software versions will be published as part of the Phase 2 availability 
announcement.___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip