Re: [cisco-voip] UDS Searches not sanitizing the Plus Symbol

[Anthony Holloway]

No worries.  Transitioning to app dev will be a bumpy road for a lot of UC
Engineers, we might as well help each other progress forward.

On Wed, Apr 12, 2017 at 9:37 PM Nathan Reeves 
wrote:

> lol, cheers for that, should have picked that up earlier.  Quick test
> shows that works perfectly.
>
> When the docs mention that it ignores the plus symbol, I was working on
> the assumption that it therefore would ignore the plus symbol in the actual
> number.  Wrong assumption.
>
> Thanks again
>
>
> On Wed, Apr 12, 2017 at 11:57 PM, Anthony Holloway <
> avholloway+cisco-v...@gmail.com> wrote:
>
>> Plus signs (+) in URL query parameters (the part after the question mark
>> [?]) are treated as spaces.  E.g., ?name=anthony+holloway == "anthony
>> holloway"  So, you're effectively asking UDS for " 6140011" (note the
>> leading space, and omission of the plus sign [+]).
>>
>> The work around is to use some sort of URL encoding library, which will
>> build your URL with the plus sign (+) encoded with it's percent sign (%)
>> equivelent, which happens to be %2B.
>>
>> So, your submitted UDS request would actually look like:
>>
>> https://172.20.2.21:8443/cucm-uds/users?number=%2B6140011
>>
>> Finally, this is not a function of UDS at all, and something you'll need
>> to know, now that you are explorely RESTful APIs which rely on URL
>> structures to work with data.
>>
>> On Wed, Apr 12, 2017 at 10:46 AM Nathan Reeves 
>> wrote:
>>
>>> Taking a look around at what options we have to drive additional
>>> directories for our IP phones and decided to take a quick look at using UDS
>>> as the data source, accessing it via the published API.
>>>
>>> One thing I'm finding (which I can't see any bug report on), is that
>>> number searches, where the number in UDS contains a plus, does not return
>>> search results based on the query submitted.
>>>
>>> I have a user configured with a mobile number in PlusE164 (+6140011
>>> <+61%20400%20111%20111> for example) which is pulled into the CUCM
>>> directory via LDAP sync.
>>>
>>> The API docs note that brackets, plus symbols etc are all ignored in the
>>> search.  When I access the UDS API and construct a query string in a URL
>>> along the lines of 'https://172.20.2.21:8443/cucm-uds/users?number=61400',
>>> the returned response is 0 results.  If I update the Mobile number to
>>> remove just the plus (and resync LDAP), the same search now returns my user
>>> with the mobile number correctly searched.
>>>
>>> Running 11.5(1)SU1 (haven't yet checked this against SU2), attempted to
>>> use native UDS but also tried searching while UDS Proxy is enabled.  Same
>>> results either way.
>>>
>>> Anyone seen this issue or am I missing something?  I can only assume
>>> that the sanitized query doesn't correctly ignore the plus symbol.
>>>
>>> Cheers
>>>
>>> Nathan
>>> ___
>>> 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

[Abhiram Kramadhati (akramadh)]

Hi Anthony,

Yup, unfortunately we don’t do a very good job of documenting this. Ideally, it 
should configure itself and the reason the secondary tab is not populated is 
that secondary tab is meant for standalone CUIC servers itself where each 
server needs to have a primary/backup, but in UCCX we don’t utilize that 
concept.

I have asked the team to create an external facing technotes covering this 
behavior and how the troubleshooting should be done. I will share the document 
here once it is done for review.

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

From: Matthew Loraditch 
Date: Wednesday, 12 April 2017 at 1:05 AM
To: Anthony Holloway , "Abhiram Kramadhati 
(akramadh)" , Nick Britt 
Cc: Cisco VoIP Group 
Subject: RE: [cisco-voip] UCCX HA and CUIC Historical Data Source

11.5, I installed SU1 after install, but didn’t look at CUIC until after.

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


Facebook | 
Twitter | 
LinkedIn 
| G+

From: Anthony Holloway [mailto:avholloway+cisco-v...@gmail.com]
Sent: Tuesday, April 11, 2017 3:34 PM
To: Matthew Loraditch ; Abhiram Kramadhati 
(akramadh) ; Nick Britt 
Cc: Cisco VoIP Group 
Subject: Re: [cisco-voip] UCCX HA and CUIC Historical Data Source

What version Matt?

On Tue, Apr 11, 2017 at 1:34 PM Matthew Loraditch 
> 
wrote:
Just on#1 and 2 because I happened to just be building 2 CCX servers today, it 
did configure itself.

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: Tuesday, April 11, 2017 2:29 PM
To: Abhiram Kramadhati (akramadh) 
>; Nick Britt 
>

Cc: Cisco VoIP Group 
>
Subject: Re: [cisco-voip] UCCX HA and CUIC Historical Data Source

I do appreciate the follow up, but I have a bone to pick here...actually, a 
few.  First, I was not in a situation where datasources were pointing at each 
other, I did have them pointing to a single node.  And that's where failover 
failed me.  I had both nodes pointing at the default Node 1, which was my 
Master, and when failover happened, reporting was down.

1) Where in the documentation does it say to reconfigure the datasource to 
point to the non-master node when deploying HA?

2) Why doesn't it configure itself?

3) Why doesn't it update itself like LiveData does?

4) Why can't we use the secondary source tab to populate both nodes?

5) What if I don't want all my reporting traffic traversing the WAN in HAoW 
deployments?  I.e., My Mast is located where most of my Agent and Supervisors 
are, and I want reporting to stay local to them.  The HA node is there just in 
case of a datacenter failure.
On Tue, Apr 11, 2017 at 3:03 AM Abhiram Kramadhati (akramadh) 
> wrote:
Hi guys,

So, here is the expected behavior and we are taking 11.5 as reference:

Historical datasource:

The historical datasource on either node should always point to the non-master 
Node. So, assume N1 is the master. CUIC on N1 should be pointing to N2 
datasource host and CUIC on N2 should be pointing to N2 datasource host. Also, 
unlike older versions we don’t redirect users to the secondary UCCX IP to login 
to run reports. You can login to any node CUIC and run the report, but the 
datsource host should be the secondary server.
However, we have seen cases where the nodes point to each other: N1 pointing to 
N2 (expected), N2 pointing to N1 (problem). This is opened as a defect and we 
are investigating why this can happen and I am guessing that’s what has 
happened in Anthony’s case in the original email thread.

CSCvd22513 is the defectID for your reference. I will share more information on 
the outcome of the investigation.

LiveData:

This is always pointing to the local node by default and need not be changed. 
The LD datasource uses REST API to figure out the engine master and will 

Re: [cisco-voip] UDS Searches not sanitizing the Plus Symbol

[Nathan Reeves]

lol, cheers for that, should have picked that up earlier.  Quick test shows
that works perfectly.

When the docs mention that it ignores the plus symbol, I was working on the
assumption that it therefore would ignore the plus symbol in the actual
number.  Wrong assumption.

Thanks again


On Wed, Apr 12, 2017 at 11:57 PM, Anthony Holloway <
avholloway+cisco-v...@gmail.com> wrote:

> Plus signs (+) in URL query parameters (the part after the question mark
> [?]) are treated as spaces.  E.g., ?name=anthony+holloway == "anthony
> holloway"  So, you're effectively asking UDS for " 6140011" (note the
> leading space, and omission of the plus sign [+]).
>
> The work around is to use some sort of URL encoding library, which will
> build your URL with the plus sign (+) encoded with it's percent sign (%)
> equivelent, which happens to be %2B.
>
> So, your submitted UDS request would actually look like:
>
> https://172.20.2.21:8443/cucm-uds/users?number=%2B6140011
>
> Finally, this is not a function of UDS at all, and something you'll need
> to know, now that you are explorely RESTful APIs which rely on URL
> structures to work with data.
>
> On Wed, Apr 12, 2017 at 10:46 AM Nathan Reeves 
> wrote:
>
>> Taking a look around at what options we have to drive additional
>> directories for our IP phones and decided to take a quick look at using UDS
>> as the data source, accessing it via the published API.
>>
>> One thing I'm finding (which I can't see any bug report on), is that
>> number searches, where the number in UDS contains a plus, does not return
>> search results based on the query submitted.
>>
>> I have a user configured with a mobile number in PlusE164 (+6140011
>> <+61%20400%20111%20111> for example) which is pulled into the CUCM
>> directory via LDAP sync.
>>
>> The API docs note that brackets, plus symbols etc are all ignored in the
>> search.  When I access the UDS API and construct a query string in a URL
>> along the lines of 'https://172.20.2.21:8443/cucm-uds/users?number=61400',
>> the returned response is 0 results.  If I update the Mobile number to
>> remove just the plus (and resync LDAP), the same search now returns my user
>> with the mobile number correctly searched.
>>
>> Running 11.5(1)SU1 (haven't yet checked this against SU2), attempted to
>> use native UDS but also tried searching while UDS Proxy is enabled.  Same
>> results either way.
>>
>> Anyone seen this issue or am I missing something?  I can only assume that
>> the sanitized query doesn't correctly ignore the plus symbol.
>>
>> Cheers
>>
>> Nathan
>> ___
>> 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] BAT Phone Insert Issue

[Ruben Trujillo via cisco-voip]

Hello,

I'm attempting to do a BAT phone insert (CUCM 10.5.2)but I'm running into an 
issue where I get an error "(blank) is not a supported field".  Since the log 
isn't telling me what the issue is I'm having a hard time finding what it's 
complaining about.  Has anyone else run into this?  I've tried this with an 
"all details" as well as "specific details" when attempting to insert phones 
via BAT.  My feeling is that something changed between this version and the 
previous version of CM but I'm not having any luck finding what it is.  Also, I 
have done this successfully before but it's been a few years and I believe we 
were on CUCM 9.x at the time.

Thanks,
Ruben Trujillo
IT Telecom

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

Re: [cisco-voip] UDS Searches not sanitizing the Plus Symbol

[Anthony Holloway]

Plus signs (+) in URL query parameters (the part after the question mark
[?]) are treated as spaces.  E.g., ?name=anthony+holloway == "anthony
holloway"  So, you're effectively asking UDS for " 6140011" (note the
leading space, and omission of the plus sign [+]).

The work around is to use some sort of URL encoding library, which will
build your URL with the plus sign (+) encoded with it's percent sign (%)
equivelent, which happens to be %2B.

So, your submitted UDS request would actually look like:

https://172.20.2.21:8443/cucm-uds/users?number=%2B6140011

Finally, this is not a function of UDS at all, and something you'll need to
know, now that you are explorely RESTful APIs which rely on URL structures
to work with data.

On Wed, Apr 12, 2017 at 10:46 AM Nathan Reeves 
wrote:

> Taking a look around at what options we have to drive additional
> directories for our IP phones and decided to take a quick look at using UDS
> as the data source, accessing it via the published API.
>
> One thing I'm finding (which I can't see any bug report on), is that
> number searches, where the number in UDS contains a plus, does not return
> search results based on the query submitted.
>
> I have a user configured with a mobile number in PlusE164 (+6140011
> <+61%20400%20111%20111> for example) which is pulled into the CUCM
> directory via LDAP sync.
>
> The API docs note that brackets, plus symbols etc are all ignored in the
> search.  When I access the UDS API and construct a query string in a URL
> along the lines of 'https://172.20.2.21:8443/cucm-uds/users?number=61400',
> the returned response is 0 results.  If I update the Mobile number to
> remove just the plus (and resync LDAP), the same search now returns my user
> with the mobile number correctly searched.
>
> Running 11.5(1)SU1 (haven't yet checked this against SU2), attempted to
> use native UDS but also tried searching while UDS Proxy is enabled.  Same
> results either way.
>
> Anyone seen this issue or am I missing something?  I can only assume that
> the sanitized query doesn't correctly ignore the plus symbol.
>
> Cheers
>
> Nathan
> ___
> 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] UDS Searches not sanitizing the Plus Symbol

[Nathan Reeves]

Taking a look around at what options we have to drive additional
directories for our IP phones and decided to take a quick look at using UDS
as the data source, accessing it via the published API.

One thing I'm finding (which I can't see any bug report on), is that number
searches, where the number in UDS contains a plus, does not return search
results based on the query submitted.

I have a user configured with a mobile number in PlusE164 (+6140011 for
example) which is pulled into the CUCM directory via LDAP sync.

The API docs note that brackets, plus symbols etc are all ignored in the
search.  When I access the UDS API and construct a query string in a URL
along the lines of 'https://172.20.2.21:8443/cucm-uds/users?number=61400',
the returned response is 0 results.  If I update the Mobile number to
remove just the plus (and resync LDAP), the same search now returns my user
with the mobile number correctly searched.

Running 11.5(1)SU1 (haven't yet checked this against SU2), attempted to use
native UDS but also tried searching while UDS Proxy is enabled.  Same
results either way.

Anyone seen this issue or am I missing something?  I can only assume that
the sanitized query doesn't correctly ignore the plus symbol.

Cheers

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