The free lookups may be cached, as I understand it.  Here’s a screen snap from 
the lookup program I wrote for our internal use:

https://www.evernote.com/shard/s2/sh/eb9c60d1-a80d-429e-8444-f9b73f0aa5d5/2332ab7bd6af54beddaabf0294f5587f

On Mar 19, 2014, at 9:34 PM, Nathan Anderson <[email protected]> wrote:

> ???  That's...wrong.
> 
> I'm not a customer, but given that they have a "free" option, I decided to 
> try an OpenCNAM query for that number and got this:
> 
> 'CNAM for phone "+16617480240" is currently unavailable for Hobbyist Tier 
> users.'
> 
> What?  Their site says nothing about lookups for certain numbers only being 
> avaiable on the "pro" tier.  What is up with this particular phone number??
> 
> -- Nathan
> 
> On Wednesday, March 19, 2014 8:15 PM, Carlos Alvarez 
> <mailto:[email protected]> wrote:
> 
>> I get Neilsen Paul from OpenCNAM.
>> 
>> ________________________________________
>> From: VoiceOps <[email protected]> on behalf of Nathan
>> Anderson <[email protected]> 
>> Sent: Wednesday, March 19, 2014 6:12 PM
>> To: '[email protected]'
>> Subject: [VoiceOps] Linefeed in CNAM data?
>> 
>> Our CNAM lookup provider is sending us name data for one particular
>> number that includes a linefeed in it.  It's possible that it's their
>> mistake and that this particular number's CNAM data doesn't actually have
>> this character in it, but it raises the question: is this a legal
>> character?    
>> 
>> The number in question is a SkypeOut gateway: 661-748-0240 -- I'd be
>> curious to know what other people are seeing on a CNAM lookup for this. 
>> What we are getting is "SKYPE USER\nSKYPE USER".  And, actually, now that
>> I think about it, this can't possibly be the actual value since I believe
>> CNAM is limited to 15 characters.  So I'll talk to our provider about
>> this.  (This is the only number that we have seen anything like this
>> with.)      
>> 
>> BTW, it turns out that when Asterisk sends an INVITE and the
>> CALLERID(name) value has been stuffed with a string that contains a
>> newline, it decides to send this in the headers:  
>> 
>> From: "SKYPE USER\
>> SKYPE USER" <sip:[email protected]>
>> 
>> ...so it includes the linefeed (ASCII 10) in the string, but tries to
>> escape it with a '\' (which is not entirely unprecedented).  An Asterisk
>> box on the receiving end of that INVITE, however, will completely ignore
>> the INVITE...it won't log an error and doesn't bother dignifying it with
>> a response, probably because it sees that as two separate lines (it
>> doesn't concatenate two lines that are separated by a '\') and the second
>> line all by itself looks like garbage/wouldn't make sense to a SIP dialog
>> parser.       
> 
> _______________________________________________
> VoiceOps mailing list
> [email protected]
> https://puck.nether.net/mailman/listinfo/voiceops


_______________________________________________
VoiceOps mailing list
[email protected]
https://puck.nether.net/mailman/listinfo/voiceops

Reply via email to