Re: [cisco-voip] PCI DSS compliance for Cisco IPT/UCCX

2019-01-23 Thread Ki Wi
Hi Group,
thanks!
I think TLS 1.2 is pretty tricky and since it is not compulsory now then I
will avoid it. TLS 1.1 seems good enough for now.

The main problem will revolve around enable voice encryption on existing
cluster. This will be quite a major effort. If this is deem necessary, I
will get customer to create a standalone cluster just for UCCX else
potentially it will cost them more $$ to enable end to end encryption on
all existing sites.

The PCI compliance consultant they have hired, recommended them to go
digital phones or analogue phones which is kind of weird.

Regards,
Ki Wi

On Tue, Jan 22, 2019 at 11:56 PM Ryan Ratliff (rratliff) 
wrote:

> BRKCOL-2009 is a good Cisco Live session entirely dedicated to the impact
> of PCI requirements on collab (TLS 1.2 particularly).
>
> Transport Layer Security (TLS) 1.0 is being deprecated and may not provide
> the level of security required by an organization anymore. The Payment Card
> Industry Data Security Standard (PCI DSS) is for example requiring vendors
> to use newer versions of TLS for encrypted communications. This session
> will discuss the support of TLS 1.2 in the Cisco On-Premises Collaboration
> products. It will also cover the ability to disable TLS 1.0 and/or TLS 1.1,
> the interfaces that are affected by this, and the implications on the Cisco
> Collaboration solution. Finally, it will discuss limitations when older
> phones are still used in a environment where TLS 1.0 has been disabled.
>
>
>  - Ryan Ratliff
>
> On Jan 22, 2019, at 8:18 AM, Lamont, Joshua 
> wrote:
>
> The complete guide is located here:
> https://www.pcisecuritystandards.org/documents/Protecting_Telephone_Based_Payment_Card_Data_v3-0_nov_2018.pdf
>
> This was updated in November for the first time in seven years. If you are
> a business accepting credit cards this is definitely something you should
> read through.
>
> Joshua Lamont
> Senior Telecommunications Engineer
> Brown University
> office (401) 863-1003
> cell(401) 749-6913
>
>
> On Tue, Jan 22, 2019 at 7:36 AM Ryan Huff  wrote:
>
>> At a high level I’d think you’ll need to look into SRTP (aka voice
>> encryption) enabled system-wide, no call recording (which you can’t do with
>> SRTP anyway) and possibly no call monitoring too (at least on the PII
>> calls).
>>
>> Then adhere to all the physical access rules for servers that store or
>> transmit PII (personally identifiable information).
>>
>> You may need to research database storage requirements as it relates to
>> PCI. I’m assuming the UCCX environment is what will be dealing with the
>> PII; while UCCX doesn’t have the capacity to outright store CC info, it may
>> be possible that some of that info is captured in logs, depending on how
>> your environment is set up.
>>
>> You’d have to do a lot of dry runs in the UCCX environment and run all
>> the calling scenarios that interact with PII to ensure traces of it do not
>> get logged.
>>
>> Obviously nothing can be done to the UCCX database outside of what Cisco
>> supports, like encrypt table values that aren’t encrypted.. etc
>>
>> Sent from my iPhone
>>
>> > On Jan 22, 2019, at 01:23, Ki Wi  wrote:
>> >
>> > Hi Group,
>> > I have a customer who is querying on how can we make their existing
>> Cisco IPT (with UCCX) PCI DSS compliance since the new upcoming site we are
>> planning to deploy will handle sensitive data such as credit cards
>> information.
>> >
>> > Any folks out there have experience doing this?
>> >
>> > Do we need voice encryption? Turn on TLS v1.1 ? etc?
>> >
>> > --
>> > Regards,
>> > Ki Wi
>> > ___
>> > cisco-voip mailing list
>> > cisco-voip@puck.nether.net
>> >
>> https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-voipdata=02%7C01%7C%7Cb9218ac35b024bba75db08d680321fbe%7C84df9e7fe9f640afb435%7C1%7C0%7C636837350098382558sdata=%2Fb%2BfDpOqy2BHdBZ%2F%2F%2B%2BYB7FyBrE4lznDiRI1dlwChC4%3Dreserved=0
>> ___
>> 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
>
>
>

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


Re: [cisco-voip] Expressway cluster algorithm

2019-01-23 Thread Lelio Fulgenzi
Ah. Yes. That part from the conversation is coming back to me. Geeez.  No real 
way then, I’d there?

-sent from mobile device-

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

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

[University of Guelph Cornerstone with Improve Life tagline]

On Jan 23, 2019, at 4:52 PM, Ryan Huff 
mailto:ryanh...@outlook.com>> wrote:

SRV weights and priorities do influence the selection, but do not guarantee. 
The accepting peer can pass to the other peer if the other peer is less 
utilized.

Sent from my iPhone

On Jan 23, 2019, at 16:35, Lelio Fulgenzi 
mailto:le...@uoguelph.ca>> wrote:

Gotcha. IIRC, you can’t put weight on traversal neighbours.

So you can use dns srv record weights to pick the C out or the E in, but once 
inside the cluster picking the next hop E (or C) is round robin.

Interested to hear comments.

-sent from mobile device-

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

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

[University of Guelph Cornerstone with Improve Life tagline]

On Jan 23, 2019, at 4:17 PM, Ryan Huff 
mailto:ryanh...@outlook.com>> wrote:

I’m trying to guarantee an active/passive use case; so maintenance mode would 
achieve that (or shutting one side down), but would require manual 
intervention, and be as clunky of a work-a-round as it gets for a runtime 
solution.

-Ryan

On Jan 23, 2019, at 16:00, Lelio Fulgenzi 
mailto:le...@uoguelph.ca>> wrote:

I’m going to read the responses, but when I opened a TAC case, the engineer 
explained that there were at least two selection processes in play, which C (or 
E) to pick, then which neighbour to pick for the traversal.

She said, if you want to be 100% sure during troubleshooting, that you are 
testing a particular path, you want to put the nodes you don’t want to use into 
maintenance mode.

Made sense to me at the time.

-sent from mobile device-

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

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

[University of Guelph Cornerstone with Improve Life tagline]

On Jan 23, 2019, at 3:19 PM, Ryan Huff 
mailto:ryanh...@outlook.com>> wrote:

Can anyone explain or cite the documents that define the algorithm used to 
determine which Expressway node in a given cluster is selected to process a 
call.

You can influence the selection with DNS SRV priority and weight, but does not 
appear to guarantee which cluster node is selected each time.

Thanks,

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


Re: [cisco-voip] Expressway cluster algorithm

2019-01-23 Thread Ryan Huff
SRV weights and priorities do influence the selection, but do not guarantee. 
The accepting peer can pass to the other peer if the other peer is less 
utilized.

Sent from my iPhone

On Jan 23, 2019, at 16:35, Lelio Fulgenzi 
mailto:le...@uoguelph.ca>> wrote:

Gotcha. IIRC, you can’t put weight on traversal neighbours.

So you can use dns srv record weights to pick the C out or the E in, but once 
inside the cluster picking the next hop E (or C) is round robin.

Interested to hear comments.

-sent from mobile device-

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

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

[University of Guelph Cornerstone with Improve Life tagline]

On Jan 23, 2019, at 4:17 PM, Ryan Huff 
mailto:ryanh...@outlook.com>> wrote:

I’m trying to guarantee an active/passive use case; so maintenance mode would 
achieve that (or shutting one side down), but would require manual 
intervention, and be as clunky of a work-a-round as it gets for a runtime 
solution.

-Ryan

On Jan 23, 2019, at 16:00, Lelio Fulgenzi 
mailto:le...@uoguelph.ca>> wrote:

I’m going to read the responses, but when I opened a TAC case, the engineer 
explained that there were at least two selection processes in play, which C (or 
E) to pick, then which neighbour to pick for the traversal.

She said, if you want to be 100% sure during troubleshooting, that you are 
testing a particular path, you want to put the nodes you don’t want to use into 
maintenance mode.

Made sense to me at the time.

-sent from mobile device-

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

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

[University of Guelph Cornerstone with Improve Life tagline]

On Jan 23, 2019, at 3:19 PM, Ryan Huff 
mailto:ryanh...@outlook.com>> wrote:

Can anyone explain or cite the documents that define the algorithm used to 
determine which Expressway node in a given cluster is selected to process a 
call.

You can influence the selection with DNS SRV priority and weight, but does not 
appear to guarantee which cluster node is selected each time.

Thanks,

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


Re: [cisco-voip] Expressway cluster algorithm

2019-01-23 Thread Ryan Huff
Well, ideally each inbound caller’s endpoint uses the same implementation of 
DNS SRV as defined in RFC2782 and respects priorities and weights (my SIP SRV 
targets the edge cluster FQDN).

And to your point, I can reliably control the edge that accepts the initial 
inbound INVITE with SRV manipulation, but cannot reliably predict which control 
peer is used (though you can usually make a good guess).

Ideally, I am trying to guarantee an active/passive use case in all scenarios, 
ingress and egress.

Sent from my iPhone

On Jan 23, 2019, at 16:32, Brian Meade 
mailto:bmead...@vt.edu>> wrote:

Is this for inbound B2B or for MRA?

If inbound B2B, it's more up to the caller's implementation of DNS.  If the 
caller is Webex, their may be some documented behavior out there somewhere.

On Wed, Jan 23, 2019 at 4:17 PM Ryan Huff 
mailto:ryanh...@outlook.com>> wrote:
I’m trying to guarantee an active/passive use case; so maintenance mode would 
achieve that (or shutting one side down), but would require manual 
intervention, and be as clunky of a work-a-round as it gets for a runtime 
solution.

-Ryan

On Jan 23, 2019, at 16:00, Lelio Fulgenzi 
mailto:le...@uoguelph.ca>> wrote:

I’m going to read the responses, but when I opened a TAC case, the engineer 
explained that there were at least two selection processes in play, which C (or 
E) to pick, then which neighbour to pick for the traversal.

She said, if you want to be 100% sure during troubleshooting, that you are 
testing a particular path, you want to put the nodes you don’t want to use into 
maintenance mode.

Made sense to me at the time.

-sent from mobile device-

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

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

[University of Guelph Cornerstone with Improve Life tagline]

On Jan 23, 2019, at 3:19 PM, Ryan Huff 
mailto:ryanh...@outlook.com>> wrote:

Can anyone explain or cite the documents that define the algorithm used to 
determine which Expressway node in a given cluster is selected to process a 
call.

You can influence the selection with DNS SRV priority and weight, but does not 
appear to guarantee which cluster node is selected each time.

Thanks,

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


Re: [cisco-voip] Expressway cluster algorithm

2019-01-23 Thread Lelio Fulgenzi
Gotcha. IIRC, you can’t put weight on traversal neighbours.

So you can use dns srv record weights to pick the C out or the E in, but once 
inside the cluster picking the next hop E (or C) is round robin.

Interested to hear comments.

-sent from mobile device-

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

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

[University of Guelph Cornerstone with Improve Life tagline]

On Jan 23, 2019, at 4:17 PM, Ryan Huff 
mailto:ryanh...@outlook.com>> wrote:

I’m trying to guarantee an active/passive use case; so maintenance mode would 
achieve that (or shutting one side down), but would require manual 
intervention, and be as clunky of a work-a-round as it gets for a runtime 
solution.

-Ryan

On Jan 23, 2019, at 16:00, Lelio Fulgenzi 
mailto:le...@uoguelph.ca>> wrote:

I’m going to read the responses, but when I opened a TAC case, the engineer 
explained that there were at least two selection processes in play, which C (or 
E) to pick, then which neighbour to pick for the traversal.

She said, if you want to be 100% sure during troubleshooting, that you are 
testing a particular path, you want to put the nodes you don’t want to use into 
maintenance mode.

Made sense to me at the time.

-sent from mobile device-

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

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

[University of Guelph Cornerstone with Improve Life tagline]

On Jan 23, 2019, at 3:19 PM, Ryan Huff 
mailto:ryanh...@outlook.com>> wrote:

Can anyone explain or cite the documents that define the algorithm used to 
determine which Expressway node in a given cluster is selected to process a 
call.

You can influence the selection with DNS SRV priority and weight, but does not 
appear to guarantee which cluster node is selected each time.

Thanks,

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


Re: [cisco-voip] Expressway cluster algorithm

2019-01-23 Thread Brian Meade
Is this for inbound B2B or for MRA?

If inbound B2B, it's more up to the caller's implementation of DNS.  If the
caller is Webex, their may be some documented behavior out there somewhere.

On Wed, Jan 23, 2019 at 4:17 PM Ryan Huff  wrote:

> I’m trying to guarantee an active/passive use case; so maintenance mode
> would achieve that (or shutting one side down), but would require manual
> intervention, and be as clunky of a work-a-round as it gets for a runtime
> solution.
>
> -Ryan
>
> On Jan 23, 2019, at 16:00, Lelio Fulgenzi  wrote:
>
> I’m going to read the responses, but when I opened a TAC case, the
> engineer explained that there were at least two selection processes in
> play, which C (or E) to pick, then which neighbour to pick for the
> traversal.
>
> She said, if you want to be 100% sure during troubleshooting, that you are
> testing a particular path, you want to put the nodes you don’t want to use
> into maintenance mode.
>
> Made sense to me at the time.
>
> *-sent from mobile device-*
>
>
> *Lelio Fulgenzi, B.A.* | Senior Analyst
>
> Computing and Communications Services | University of Guelph
>
> Room 037 Animal Science & Nutrition Bldg | 50 Stone Rd E | Guelph, ON |
> N1G 2W1
>
> 519-824-4120 Ext. 56354 <519-824-4120;56354> | le...@uoguelph.ca
>
>
>
> www.uoguelph.ca/ccs
> 
>  |
> @UofGCCS on Instagram, Twitter and Facebook
>
>
>
> [image: University of Guelph Cornerstone with Improve Life tagline]
>
> On Jan 23, 2019, at 3:19 PM, Ryan Huff  wrote:
>
> Can anyone explain or cite the documents that define the algorithm used to
> determine which Expressway node in a given cluster is selected to process a
> call.
>
> You can influence the selection with DNS SRV priority and weight, but does
> not appear to guarantee which cluster node is selected each time.
>
> Thanks,
>
> Ryan
> ___
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
> 
>
> ___
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip


Re: [cisco-voip] Expressway cluster algorithm

2019-01-23 Thread Ryan Huff
I’m trying to guarantee an active/passive use case; so maintenance mode would 
achieve that (or shutting one side down), but would require manual 
intervention, and be as clunky of a work-a-round as it gets for a runtime 
solution.

-Ryan

On Jan 23, 2019, at 16:00, Lelio Fulgenzi 
mailto:le...@uoguelph.ca>> wrote:

I’m going to read the responses, but when I opened a TAC case, the engineer 
explained that there were at least two selection processes in play, which C (or 
E) to pick, then which neighbour to pick for the traversal.

She said, if you want to be 100% sure during troubleshooting, that you are 
testing a particular path, you want to put the nodes you don’t want to use into 
maintenance mode.

Made sense to me at the time.

-sent from mobile device-

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

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

[University of Guelph Cornerstone with Improve Life tagline]

On Jan 23, 2019, at 3:19 PM, Ryan Huff 
mailto:ryanh...@outlook.com>> wrote:

Can anyone explain or cite the documents that define the algorithm used to 
determine which Expressway node in a given cluster is selected to process a 
call.

You can influence the selection with DNS SRV priority and weight, but does not 
appear to guarantee which cluster node is selected each time.

Thanks,

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


Re: [cisco-voip] Expressway cluster algorithm

2019-01-23 Thread Lelio Fulgenzi
I’m going to read the responses, but when I opened a TAC case, the engineer 
explained that there were at least two selection processes in play, which C (or 
E) to pick, then which neighbour to pick for the traversal.

She said, if you want to be 100% sure during troubleshooting, that you are 
testing a particular path, you want to put the nodes you don’t want to use into 
maintenance mode.

Made sense to me at the time.

-sent from mobile device-

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

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

[University of Guelph Cornerstone with Improve Life tagline]

On Jan 23, 2019, at 3:19 PM, Ryan Huff 
mailto:ryanh...@outlook.com>> wrote:

Can anyone explain or cite the documents that define the algorithm used to 
determine which Expressway node in a given cluster is selected to process a 
call.

You can influence the selection with DNS SRV priority and weight, but does not 
appear to guarantee which cluster node is selected each time.

Thanks,

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


Re: [cisco-voip] [EXT] Expressway cluster algorithm

2019-01-23 Thread Ryan Huff


Sent from my iPhone

> On Jan 23, 2019, at 15:34, Ryan Huff  wrote:
> 
> Or, rather than fixed machine resources, could it be application resource 
> logic (node with the most recent, least amount of calls.. etc)?
> 
> Sent from my iPhone
> 
>> On Jan 23, 2019, at 15:29, Ryan Huff  wrote:
>> 
>> Thanks for responding!
>> 
>> “Lowest resource usage” is the most specific info I’ve ever found. Is that 
>> just CPU, or Mem or IOPS or any combo? And which of the “resource” metrics 
>> take priority in the decision?
>> 
>> Thanks,
>> 
>> Ryan
>> 
>>> On Jan 23, 2019, at 15:24, Jeffrey McHugh  wrote:
>>> 
>>> From exp clustering guide: 
>>> 
>>> Neighboring Between Expressway Clusters
>>> You can neighbor your local Expressway (or Expressway cluster) to a remote 
>>> Expressway cluster; this remote cluster could be a neighbor, traversal 
>>> client, or traversal server to your local Expressway. In this case, when a 
>>> call is received on your local Expressway and is passed via the relevant 
>>> zone to the remote cluster, it will be routed to whichever peer in that 
>>> neighboring cluster has the lowest resource usage. That peer will then 
>>> forward the call as appropriate to one of its:
>>> ■
>>> locally registered endpoints (if the endpoint is registered to that peer)
>>> ■
>>> peers (if the endpoint is registered to another peer in that cluster)
>>> ■
>>> external zones (if the endpoint has been located elsewhere)
>>> For Expressway: Lowest resource usage is determined by comparing the number 
>>> of available media sessions (maximum - current use) on the peers, and 
>>> choosing the peer with the highest number. Peers that are in maintenance 
>>> mode are not considered
>>> 
>>> 
>>> Jeffrey McHugh | Sr. Collaboration Consulting Engineer 
>>> 
>>> Fidelus Technologies, LLC
>>> Named Best UC Provider in the USA
>>> 240 West 35th Street, 6th Floor, New York, NY 10001
>>> +1-212-616-7801 office | +1-212-616-7850 fax | 
>>> https://nam01.safelinks.protection.outlook.com/?url=www.fidelus.comdata=02%7C01%7C%7Ca2cd61d7048d4afb98d608d68170cfe5%7C84df9e7fe9f640afb435%7C1%7C0%7C636838718849178018sdata=IxL%2FSJK83B2mQG545Le3qssuCOftt83%2F0QQolzc8r4A%3Dreserved=0
>>> 
>>> Disclaimer - This email and any files transmitted with it are confidential 
>>> and intended solely for the person(s) addressed to. If you are not the 
>>> named addressee you should not disseminate, distribute, copy or alter this 
>>> email. Any views or opinions presented in this email are solely those of 
>>> the author and might not represent those of Fidelus Technologies, LLC. 
>>> Warning: Although Fidelus Technologies, LLC has taken reasonable 
>>> precautions to ensure no viruses are present in this email, the company 
>>> cannot accept responsibility for any loss or damage arising from the use of 
>>> this email or attachments.
>>> -Original Message-
>>> From: cisco-voip  On Behalf Of Ryan Huff
>>> Sent: Wednesday, January 23, 2019 3:19 PM
>>> To: cisco-voip@puck.nether.net
>>> Subject: [EXT] [cisco-voip] Expressway cluster algorithm
>>> 
>>> Can anyone explain or cite the documents that define the algorithm used to 
>>> determine which Expressway node in a given cluster is selected to process a 
>>> call.
>>> 
>>> You can influence the selection with DNS SRV priority and weight, but does 
>>> not appear to guarantee which cluster node is selected each time.
>>> 
>>> Thanks,
>>> 
>>> Ryan
>>> ___
>>> cisco-voip mailing list
>>> cisco-voip@puck.nether.net
>>> https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-voipdata=02%7C01%7C%7Ca2cd61d7048d4afb98d608d68170cfe5%7C84df9e7fe9f640afb435%7C1%7C0%7C636838718849178018sdata=8TCE6Oe71Y8smfXAbH8%2B47evW%2BKbM%2B2uYltLn1cuxFM%3Dreserved=0
>>> 
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip


Re: [cisco-voip] [EXT] Expressway cluster algorithm

2019-01-23 Thread Ryan Huff


> On Jan 23, 2019, at 15:29, Ryan Huff  wrote:
> 
> Thanks for responding!
> 
> “Lowest resource usage” is the most specific info I’ve ever found. Is that 
> just CPU, or Mem or IOPS or any combo? And which of the “resource” metrics 
> take priority in the decision?
> 
> Thanks,
> 
> Ryan
> 
>> On Jan 23, 2019, at 15:24, Jeffrey McHugh  wrote:
>> 
>> From exp clustering guide: 
>> 
>> Neighboring Between Expressway Clusters
>> You can neighbor your local Expressway (or Expressway cluster) to a remote 
>> Expressway cluster; this remote cluster could be a neighbor, traversal 
>> client, or traversal server to your local Expressway. In this case, when a 
>> call is received on your local Expressway and is passed via the relevant 
>> zone to the remote cluster, it will be routed to whichever peer in that 
>> neighboring cluster has the lowest resource usage. That peer will then 
>> forward the call as appropriate to one of its:
>> ■
>> locally registered endpoints (if the endpoint is registered to that peer)
>> ■
>> peers (if the endpoint is registered to another peer in that cluster)
>> ■
>> external zones (if the endpoint has been located elsewhere)
>> For Expressway: Lowest resource usage is determined by comparing the number 
>> of available media sessions (maximum - current use) on the peers, and 
>> choosing the peer with the highest number. Peers that are in maintenance 
>> mode are not considered
>> 
>> 
>> Jeffrey McHugh | Sr. Collaboration Consulting Engineer 
>> 
>> Fidelus Technologies, LLC
>> Named Best UC Provider in the USA
>> 240 West 35th Street, 6th Floor, New York, NY 10001
>> +1-212-616-7801 office | +1-212-616-7850 fax | 
>> https://nam01.safelinks.protection.outlook.com/?url=www.fidelus.comdata=02%7C01%7C%7Ca2cd61d7048d4afb98d608d68170cfe5%7C84df9e7fe9f640afb435%7C1%7C0%7C636838718849178018sdata=IxL%2FSJK83B2mQG545Le3qssuCOftt83%2F0QQolzc8r4A%3Dreserved=0
>> 
>> Disclaimer - This email and any files transmitted with it are confidential 
>> and intended solely for the person(s) addressed to. If you are not the named 
>> addressee you should not disseminate, distribute, copy or alter this email. 
>> Any views or opinions presented in this email are solely those of the author 
>> and might not represent those of Fidelus Technologies, LLC. Warning: 
>> Although Fidelus Technologies, LLC has taken reasonable precautions to 
>> ensure no viruses are present in this email, the company cannot accept 
>> responsibility for any loss or damage arising from the use of this email or 
>> attachments.
>> -Original Message-
>> From: cisco-voip  On Behalf Of Ryan Huff
>> Sent: Wednesday, January 23, 2019 3:19 PM
>> To: cisco-voip@puck.nether.net
>> Subject: [EXT] [cisco-voip] Expressway cluster algorithm
>> 
>> Can anyone explain or cite the documents that define the algorithm used to 
>> determine which Expressway node in a given cluster is selected to process a 
>> call.
>> 
>> You can influence the selection with DNS SRV priority and weight, but does 
>> not appear to guarantee which cluster node is selected each time.
>> 
>> Thanks,
>> 
>> Ryan
>> ___
>> cisco-voip mailing list
>> cisco-voip@puck.nether.net
>> https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-voipdata=02%7C01%7C%7Ca2cd61d7048d4afb98d608d68170cfe5%7C84df9e7fe9f640afb435%7C1%7C0%7C636838718849178018sdata=8TCE6Oe71Y8smfXAbH8%2B47evW%2BKbM%2B2uYltLn1cuxFM%3Dreserved=0
>> 
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip


Re: [cisco-voip] Expressway cluster algorithm

2019-01-23 Thread Patrick Robitaille
I am also curious if there is any documentation for this.  When I asked Cisco 
HTTS support recently they said it is round robin.  In my environment though I 
see inbound B2B calls from Webex hitting the same CUCM Sub.


-Original Message-
From: cisco-voip  On Behalf Of Ryan Huff
Sent: Wednesday, January 23, 2019 3:19 PM
To: cisco-voip@puck.nether.net
Subject: [cisco-voip] Expressway cluster algorithm

Can anyone explain or cite the documents that define the algorithm used to 
determine which Expressway node in a given cluster is selected to process a 
call.

You can influence the selection with DNS SRV priority and weight, but does not 
appear to guarantee which cluster node is selected each time.

Thanks,

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



Disclaimer: This e-mail may contain confidential and/or privileged information. 
If you are not the intended recipient or have received this e-mail in error, 
please notify the sender immediately and destroy/delete this e-mail. You are 
hereby notified that any unauthorized copying, disclosure or distribution of 
the material in this e-mail is strictly prohibited.

AQR Capital Management, LLC, along with its affiliates (collectively "AQR") may 
collect certain personal information from you. AQR operates pursuant to a 
Global Privacy Policy which describes the types of personal information we 
obtain, how we use the information, with whom we share it and the choices 
available to you regarding our use of the information. We also describe the 
measures we take to protect the security of the information and how you can 
contact us about our privacy practices. By providing your personal information 
you agree to do so pursuant to the Global Privacy Policy. For a copy of the 
Global Privacy Policy please click here.

This communication is for informational purposes only. It is not intended as an 
offer or solicitation for the purchase or sale of any financial instrument or 
as an official confirmation of any transaction. All information contained in 
this communication is not warranted as to completeness or accuracy and is 
subject to change without notice. Any comments or statements made in this 
communication do not necessarily reflect those of AQR Capital Management, LLC 
and its affiliates.
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip


[cisco-voip] Expressway cluster algorithm

2019-01-23 Thread Ryan Huff
Can anyone explain or cite the documents that define the algorithm used to 
determine which Expressway node in a given cluster is selected to process a 
call.

You can influence the selection with DNS SRV priority and weight, but does not 
appear to guarantee which cluster node is selected each time.

Thanks,

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


Re: [cisco-voip] TMSXE OBTP

2019-01-23 Thread Pawlowski, Adam
I believe you just need a compatible endpoint, but, certain prompts display on 
the touch10. I recall somewhere in the release notes recently that you can 
disable the codec crying about not having a touch panel, and meetings may still 
display on the screen, but the green button speed dial doesn't appear on a non 
existent panel so you would need booking data and a way to drive that through 
external control otherwise.

There's maybe a thought that at some point in the future you wouldn't need the 
touch 10 with a compatible input device but who knows.

Still new at telepresence and it is an interesting animal.

Adam
SUNYAB


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


Re: [cisco-voip] TMSXE OBTP

2019-01-23 Thread Erick Wellnitz
TAC says that the touch 8 should work for OBTP.  I guess if nobody else
says differently we will find out based on trial and error.

On Tue, Jan 22, 2019 at 4:49 PM Lelio Fulgenzi  wrote:

>
> I heard the part about the touch ten.
>
> Here’s a requirement doc. I glanced. Couldn’t find touch ten though.
>
> https://collaborationhelp.cisco.com/article/en-us/nvibg1k
>
> *-sent from mobile device-*
>
>
> *Lelio Fulgenzi, B.A.* | Senior Analyst
>
> Computing and Communications Services | University of Guelph
>
> Room 037 Animal Science & Nutrition Bldg | 50 Stone Rd E | Guelph, ON |
> N1G 2W1
>
> 519-824-4120 Ext. 56354 <519-824-4120;56354> | le...@uoguelph.ca
>
>
>
> www.uoguelph.ca/ccs | @UofGCCS on Instagram, Twitter and Facebook
>
>
>
> [image: University of Guelph Cornerstone with Improve Life tagline]
>
> On Jan 22, 2019, at 5:42 PM, Erick Wellnitz 
> wrote:
>
> I just want confirmation I'm not crazy.
>
> .I thought I read somewhere in documentation not long ago that to do OBTP
> with TMSXE you needed to have either a DX or a touch 10.
>
> Did I imagine the whole thing?
>
> Thanks!
>
> ___
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip