[VoiceOps] Linefeed in CNAM data?
caalvarez at gmail.com
Thu Mar 20 00:40:50 EDT 2014
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:
On Mar 19, 2014, at 9:34 PM, Nathan Anderson <nathana at fsr.com> 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:Carlos at thresholdcommunications.com> wrote:
>> I get Neilsen Paul from OpenCNAM.
>> From: VoiceOps <voiceops-bounces at voiceops.org> on behalf of Nathan
>> Anderson <nathana at fsr.com>
>> Sent: Wednesday, March 19, 2014 6:12 PM
>> To: 'voiceops at voiceops.org'
>> 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
>> 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
>> 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:6617480240 at 192.0.2.1>
>> ...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
> VoiceOps mailing list
> VoiceOps at voiceops.org
More information about the VoiceOps