VOIP Tech Chat → iNum down?

sip.inum.net is not responding to anything other than ICMP packets, especially INVITE's:

Reliably Transmitting (NAT) to 81.201.82.25:5060:
INVITE sip:883510000000091@sip.inum.net SIP/2.0
Via: SIP/2.0/UDP caller_ip:5060;branch=z9hG4bK123c657d;rport
Max-Forwards: 70
From: "caller_name" <sip:caller_number@caller_ip>;tag=as0504d299
To: <sip:883510000000091@sip.inum.net>
Contact: <sip:caller_number@caller_ip:5060>
Call-ID: 20f6a5c37e2bfc243543a12b2c480a6f@caller_ip:5060
CSeq: 102 INVITE
User-Agent: FPBX-2.11.0(11.16.0)
Date: Sat, 21 Mar 2015 17:33:27 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces
Remote-Party-ID: "caller_name" <sip:caller_number@caller_ip>;party=calling;privacy=off;screen=no
Content-Type: application/sdp
Content-Length: 240
 
v=0
o=root 314925171 314925171 IN IP4 caller_ip
s=Asterisk PBX 11.16.0
c=IN IP4 caller_ip
t=0 0
m=audio 15916 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv
 
---
    -- Called SIP/inum/883510000000091
Retransmitting #1 (NAT) to 81.201.82.25:5060:
INVITE sip:883510000000091@sip.inum.net SIP/2.0
Via: SIP/2.0/UDP caller_ip:5060;branch=z9hG4bK123c657d;rport
Max-Forwards: 70
From: "caller_name" <sip:caller_number@caller_ip>;tag=as0504d299
To: <sip:883510000000091@sip.inum.net>
Contact: <sip:caller_number@caller_ip:5060>
Call-ID: 20f6a5c37e2bfc243543a12b2c480a6f@caller_ip:5060
CSeq: 102 INVITE
User-Agent: FPBX-2.11.0(11.16.0)
Date: Sat, 21 Mar 2015 17:33:27 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces
Remote-Party-ID: "caller_name" <sip:caller_number@caller_ip>;party=calling;privacy=off;screen=no
Content-Type: application/sdp
Content-Length: 240
 
v=0
o=root 314925171 314925171 IN IP4 caller_ip
s=Asterisk PBX 11.16.0
c=IN IP4 caller_ip
t=0 0
m=audio 15916 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv
 
---
Retransmitting #2 (NAT) to 81.201.82.25:5060:
INVITE sip:883510000000091@sip.inum.net SIP/2.0
Via: SIP/2.0/UDP caller_ip:5060;branch=z9hG4bK123c657d;rport
Max-Forwards: 70
From: "caller_name" <sip:caller_number@caller_ip>;tag=as0504d299
To: <sip:883510000000091@sip.inum.net>
Contact: <sip:caller_number@caller_ip:5060>
Call-ID: 20f6a5c37e2bfc243543a12b2c480a6f@caller_ip:5060
CSeq: 102 INVITE
User-Agent: FPBX-2.11.0(11.16.0)
Date: Sat, 21 Mar 2015 17:33:27 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces
Remote-Party-ID: "caller_name" <sip:caller_number@caller_ip>;party=calling;privacy=off;screen=no
Content-Type: application/sdp
Content-Length: 240
 
v=0
o=root 314925171 314925171 IN IP4 caller_ip
s=Asterisk PBX 11.16.0
c=IN IP4 caller_ip
t=0 0
m=audio 15916 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv
 
---
Retransmitting #3 (NAT) to 81.201.82.25:5060:
INVITE sip:883510000000091@sip.inum.net SIP/2.0
Via: SIP/2.0/UDP caller_ip:5060;branch=z9hG4bK123c657d;rport
Max-Forwards: 70
From: "caller_name" <sip:caller_number@caller_ip>;tag=as0504d299
To: <sip:883510000000091@sip.inum.net>
Contact: <sip:caller_number@caller_ip:5060>
Call-ID: 20f6a5c37e2bfc243543a12b2c480a6f@caller_ip:5060
CSeq: 102 INVITE
User-Agent: FPBX-2.11.0(11.16.0)
Date: Sat, 21 Mar 2015 17:33:27 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces
Remote-Party-ID: "caller_name" <sip:caller_number@caller_ip>;party=calling;privacy=off;screen=no
Content-Type: application/sdp
Content-Length: 240
 
v=0
o=root 314925171 314925171 IN IP4 caller_ip
s=Asterisk PBX 11.16.0
c=IN IP4 caller_ip
t=0 0
m=audio 15916 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv
 
---
Really destroying SIP dialog '519e926f54aed15b47033c515a1e1eef@caller_ip:5060' Method: INVITE
Retransmitting #4 (NAT) to 81.201.82.25:5060:
INVITE sip:883510000000091@sip.inum.net SIP/2.0
Via: SIP/2.0/UDP caller_ip:5060;branch=z9hG4bK123c657d;rport
Max-Forwards: 70
From: "caller_name" <sip:caller_number@caller_ip>;tag=as0504d299
To: <sip:883510000000091@sip.inum.net>
Contact: <sip:caller_number@caller_ip:5060>
Call-ID: 20f6a5c37e2bfc243543a12b2c480a6f@caller_ip:5060
CSeq: 102 INVITE
User-Agent: FPBX-2.11.0(11.16.0)
Date: Sat, 21 Mar 2015 17:33:27 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces
Remote-Party-ID: "caller_name" <sip:caller_number@caller_ip>;party=calling;privacy=off;screen=no
Content-Type: application/sdp
Content-Length: 240
 
v=0
o=root 314925171 314925171 IN IP4 caller_ip
s=Asterisk PBX 11.16.0
c=IN IP4 caller_ip
t=0 0
m=audio 15916 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv
 

I just made some tries and the SIP Forever iNum echo test phone number works fine (883 5100 0902 7750). Nevertheless, it seems that Voxbone does not respond any longer and since SIP Forever relies on the Voxbone iNum framework, this explains why it does not work at all.
But, calling the iNum phone number of a SIP Forever member works because in that scheme, there is no need to transfer the call to Voxbone.
I have noticed that such issues sometimes happens and in such a case, the only thing to do is to open a ticket to Voxbone and to wait...

iNum = Abandonware.

Voxbone clearly does not give a shit about it.

Down for days and days, down more than Monica.

Never any presence here in one of the world's top VoIP forums.

Last news item and last blog post on the iNum page, both from August of 2013.

Only a couple of twats and FB posts in the last several months.

Voxbone does not respond even to major VoIP providers....

What other conclusion should we draw?

Exactly.

Voxbone should just admit that theyre no longer interested in the project - and allow someone else to take over operation of the iNUM country code. I don't see that happening however.Back in september of last year!! there was another iNum thread in which someone representing Voxbone ( iNum Project ) actually responded, and even talked about improving the documentation.. BUT, They never even followed through with the documentation...

Yeah, it is abandonware to put it mildly. I don't understand why they even still put up the facade.And considering that a big part of Voxbone's business is selling DIDs to major VoIP providers, ignoring major VoIP providers might not be the most ideal approach to take..

I'm taking bets: when is iNum coming back up?

I say on Tuesday (they gotta rest a bit from the long weekend, after all).










Notice I didn't say which Tuesday hehehehehe

My gut feeling is that it is not coming back up.. That said, I'm voting for a monday, since monday seems to be their historically preferred day for restoring service.

A little OT, but I don't see the entire +883 domain getting much traction

For Instance, Republic Wireless was allocated the +883-5110 number space (and even had a "land rush" of vanity numbers online) and they have done exactly nothing with it.

Maybe someday someone will be allocated the +883-5120 space and actually do something with it.

Voxbone is based in Belgium.

Belgium, like Canada, is a mashup of two major cultural/linguistic groups.

In Belgium's case, it is the Flemish of Flanders (Dutch) and the Walloons of Wallonia (French).

The Flemish celebrate a special holiday, the Celebration of the Golden Spurs, on July 11.

I think that iNum will be back after that.

-----

PS:

1) None of that is made up.

2) Rather remarkable that after all these days there is no notice from Voxbone of anything said here or elsewhere.

I think voxbone is following the "If we ignore it, it will just go away" philosophy regarding everything iNum.

I think it's perfectly [on] target.

The +883 country code is really a limbo idea, stuck between two worlds.

It has no natural constituency.

It's far too feeble to overtake the massive infrastructure and inertia of provider-based phone numbers, yet not disruptive enough to sidetrack new services such as WhatsApp, Tango, Viber, Telegram, etc.

OK I'm thinking maybe we should psychologically prepare ourselves for a funeral.

Is there any way for me to get free incoming-call IVR without an iNum?
Current method courtesy Taoman54: free Callcentric DID forwarded to the SIP address of a free iNum provided by VoIP.ms, letting VoIP.ms do the heavy lifting (IVR).

Well, it can be still used for customer to customer calling, e.g. a Localphone or Callcentric customer can call via their calling card access numbers another customers on their i-Num DID for free; which is the way I used it 50% of the time anyway.

Maybe these providers should make a strong point and stop providing the i-Num service. Who knows it may wake up somebody at V-bone.

Other dates when the service could come back would be April 01 or possibly Easter Sunday but only for those who find the proper egg.

Belgium is a largely dysfunctional country which should be abandoned faster than i-Num but I do not think it has anything to do with V-bone woes.

Can someone please tell me what's the point of iNum, again? So that you know the call you're about to make is a SIP call?

Why not just keep a voluntary database of all DIDs and their SIP equivalent? And your VoIP provider could just check that list and do the conversion for you whenever you dial a reg 10 dig number? VoIP provider shouldn't charge you when it's in the database, charge you when it isn't. You could just publish your number as you normally would as 212-555-1234 but with some [SIP] or [HD Voice] marker next to it, no?

And even without such a list, how many VoIP providers are there? Couldn't you try "2125551234@sip.provider1.com" and then "2125551234@sip.provider2.com" to see if this # goes to a SIP phone? Wouldn't that also help you in getting HD Voice if other side supports it anyway?

And why is VoIP.ms charging per min for incoming Virtual Number usage but not for incoming iNum usage?

Quite puzzling.

There is one: »www.e164.org/

Unfortunately, it's only marginally better-maintained than iNum.

Since ENUM (e164.org) hasn't worked at all for at least 6 months now, I'm curious has you can rank it marginally better than anything? The web-site may be up, but there's nobody home for ENUM lookups.

My mistake! Apparently I haven't done an ENUM lookup in more than six months!

Yeah, the actual DNS zone has been empty for a while. e164.org is dead as an enum database. Donation link still works though.

I think that the people at Voxbone who were running iNum are extinct (similar to the Krell of Altair IV).

Providers are in a tough spot because many have other relationships with Voxbone.

But this tarnishes the entire reputation of Voxbone, it seems to me. What kind of company is this?

East Side, West Side, all around the town
People want to know, is their phone up or down.
When will the Dev team come up with a stable fork?
We tripped all the breakers on the circuits of New York.

Way back when I signed up with Teleblend
But I wonder, on them can I depend?
When will they reach our place in the queue?
Gosh it surely is an awful big snafu.

Then I started to use the Google Voice.
No money left so it was my only choice.
You can only get service by posting on their forum
They'll sometimes tell you if you're cold or war-um.

Then came iNum from the big Voxbone
A real company so why do I feel alone?
When will the tech crew fix the whole thing pronto?
We seem down in Boston and Toronto.

East Side, West Side, all around the town
People want to know, is their phone up or down.
When will the Dev team come up with a stable fork?
We tripped all the breakers on the circuits of New York.

Or maybe that is exactly what Voxbone wants? (that's my suspicion, but i could be wrong)At least one appears to have moved on to other things. According to Colin Lightfoot's LinkedIn page at least, he's moved on. (He was the iNUM Community Manager, and wrote most of iNUM blog posts.... Now, he's a property manager.)

Voxbone's customer service seems to still think he's running iNUM though.Agreed. It looks really bad.

"Voxbone, Voxbone, give us your answer, do!

Please tell us if iNum is really through.

It was such a bad marriage

You can't afford call carriage.

It would have been sweet, such a treat,

But it never worked out for true."

Methinks thou art the poet laureate of Graustark.

Ron

Did you call I number s from NOT the same provider and got a two way audio?

seems to be back up again. I called a contact via Localphone local number which connects to his iNum, and connected normally.

I just made two direct SIP calls (i.e. to sip.inum.net) from my Obi to iNum echo test and to my Voip.ms iNum DID and got "has not received a response from the service provider" on both.

That's apparently succeeding due to an internal Localphone connection path without any help from iNum.

sip.inum.net is still not responding to anything but ICMP.

It was Inum supplied by Callcentric.

Can you draw us a diagram of the path you're describing?

My contact has a callcentric account. He got an iNum from Callcentric.

I added my contact's iNum as a contact on my Localphone account. They provide me a local Toronto number which connects to his Callcentric account using the provided iNum.