Dead route information stored in e164.org

evilbunny · 30 Dez 2006

While it's nice having lots of routes listed in our zone, there are numerous routes weren't setup correctly or are no longer valid. This can be because of VSPs no longer allowing anonymous calls, incorrectly configured servers, configuration changes and so on and so forth.

All these problems can lead to a lag in call setup times and other kinds of surprises that shouldn't happen in a real time environment demanded by VoIP calls.

So with that in mind we (e164.org) have started working on methods to probe a every SIP URI in the database to see if "calls" will be accepted or not. At this stage we are monitoring the results from running a probe over SIP routes stored in our database.

We haven't come to a conclusion in terms of a policy for failed routes, but we feel that sending people a warning email should be done at the very minimum. We are still debating about when and what circumstances dead routes should be removed.

While we'd like to have probes for all protocols at this stage it isn't feasible (both coding and maintaining) so we encourage everyone to use SIP at the minimum for inter-connections as SIP routes will soon have a level of vetting. SIP is also the most widely supported open protocol on the internet so it makes sense to get everyone to use a common method of communication (even if people list additional protocols as well).

evilbunny · 30 Dez 2006

New/Edited SIP enum entries under the "Phone Numbers" tab now are checked to see if you can accept a call before allowing you to add the number into the system. Please let me know if there is a problem with our SIP probe functionality that adversely effects anyone where it shouldn't.

At present we seem to be compliant with relevant SIP RFCs, however there is always going to be a manufacturer somewhere that has a implementation that isn't 100% SIP compliant that we will need to work around.

kombjuder · 30 Dez 2006

evilbunny schrieb:
Please let me know if there is a problem with our SIP probe functionality that adversely effects anyone where it shouldn't.

Yes, there is a real problem! There was a "e164.org route test"

Seems like e164.org has checked one of my +88299 ranges. It is not yet a good idea if there are about 100 calls in les then a minute.

The only way to stop was shut down my server.

evilbunny · 31 Dez 2006

kombjuder schrieb:
Yes, there is a real problem! There was a "e164.org route test"

Seems like e164.org has checked one of my +88299 ranges. It is not yet a good idea if there are about 100 calls in les then a minute.

The only way to stop was shut down my server.

We only checked the first number in the range, not all 100, can you tell me in private any CDR information you have on calls.

evilbunny · 1 Jan 2007

I've setup a wiki page to cover most/all information I posted in this thread, however as things change etc the page will contain the updates.

http://www.e164.org/wiki/SIPProbe

Moonbase · 2 Jan 2007

A better solution for Fritz!Boxes?

Hi, EvilBunny.

I feel the idea behind all this testing is valid but unfortunately I encounter a little problem here:

My system uses a Fritz!Box 7050 (FW 14.04.25) and your test calls actually ring the phones. This is why I tried to set my Fritz!Box to simply reject calls with CallerID "0123456789". The FB does a "reject" by replying with status 486 ("Busy here") which in turn your test call won't accept:

Wasn't able to test your route, your system returned the following information: -1|486 (Busy Here)

Any good ideas on how to overcome this (or maybe what status to generate for a reject - we might ask AVM to implement that instead...)?

In the meantime, I'll route your test calls to a "silent" (software) answering machine but unfortunately this requires a PC to be on at all times.

Thanks for letting us know and for any further efforts you might want to put into this matter.

evilbunny · 2 Jan 2007

Moonbase schrieb:
I feel the idea behind all this testing is valid but unfortunately I encounter a little problem here:

My system uses a Fritz!Box 7050 (FW 14.04.25) and your test calls actually ring the phones. This is why I tried to set my Fritz!Box to simply reject calls with CallerID "0123456789". The FB does a "reject" by replying with status 486 ("Busy here") which in turn your test call won't accept:

Wasn't able to test your route, your system returned the following information: -1|486 (Busy Here)

There is about 6 return codes that are temporary failures:

408, 415, 480, 486, 503, 504 & 603 and I hadn't decided if they should be considered acceptible or not.

Moonbase schrieb:
Any good ideas on how to overcome this (or maybe what status to generate for a reject - we might ask AVM to implement that instead...)?

In the meantime, I'll route your test calls to a "silent" (software) answering machine but unfortunately this requires a PC to be on at all times.

Thanks for letting us know and for any further efforts you might want to put into this matter.

Currently the test calls only occur when you add/edit a SIP route, there is no automated checking, although with the time zone and preferred hours code in place all I need to do is email everyone to update their details and wait a few weeks.

The other thing you might want to check, does your fritz have a delayed ring feature, where is sends ringing to the remote computer but doesn't actually ringing for 1 to 2 seconds later? This would prevent any ringing, but allow the probe to check.

Moonbase · 2 Jan 2007

Thanks for the fast answer

The Fritz!Boxes don't have a "delayed ring" feature (and if they had, I guess many users wouldn't like it).

Seems it's partly a question of "philosophy":

a) You (e164.org) might wish to somehow check if a number is valid. Question: Would it be enough to get something like a "486" back from the client? It might be enough, just to show that it's actually responding. Same applies to "480" (Temporarily unavailable) and "488" (Not acceptable here), of course. What do you think?

b) I should like to see something like a "488" (Not acceptable here) in case of a SIP call reject. It is quite okay to signal a "busy" in the analogue PSTN but for SIP this should be more specific... I feel. But that's off-topic here, something for AVM to implement. (AVM: Are you listening? *g*)

No solution, but just my thoughts worth about 2 cents at 4:33 a.m. ;-)

---

Here's part of a syslog of one of the calls. You seem to send a CANCEL before the call session can be initiated which in turn leads to odd behaviour in case the recipient actually picks up the phone. And my side actually trying to send you a QoS report for a non-existant session, and failing the BYE whenever the user puts down the receiver... As far as I can remember, strictly speaking, there cannot be a CANCEL before the session has actually been initiated, right?

It might not pose a problem with most TEs, though. I hope the log can give some more insight.

Code:

Tue Jan 02 01:49:31 2007: 192.168.170.1: <14>voipd[437]: <<<UDP Request: INVITE sip:[email protected]
Tue Jan 02 01:49:31 2007: 192.168.170.1: <14>voipd[437]: <unknown>: session timer disabled
Tue Jan 02 01:49:31 2007: 192.168.170.1: <14>voipd[437]: [email protected]: bandwidth left 4294967295
Tue Jan 02 01:49:31 2007: 192.168.170.1: <14>voipd[437]: audio: 18 (18 G729/8000)
Tue Jan 02 01:49:31 2007: 192.168.170.1: <14>voipd[437]: audio: 18 (18 G729/8000) => NOT CONFIGURED
Tue Jan 02 01:49:31 2007: 192.168.170.1: <14>voipd[437]: audio: 3 (3 GSM/8000)
Tue Jan 02 01:49:31 2007: 192.168.170.1: <14>voipd[437]: audio: 3 (3 GSM/8000) => NOT SUPPORTED
Tue Jan 02 01:49:31 2007: 192.168.170.1: <14>voipd[437]: audio: 4 (4 G723/8000)
Tue Jan 02 01:49:31 2007: 192.168.170.1: <14>voipd[437]: audio: 4 (4 G723/8000) => NOT SUPPORTED
Tue Jan 02 01:49:31 2007: 192.168.170.1: <14>voipd[437]: audio: 0 (0 PCMU/8000)
Tue Jan 02 01:49:31 2007: 192.168.170.1: <14>voipd[437]: audio: 0 (0 PCMU/8000) => (0 (0 PCMU/8000))
Tue Jan 02 01:49:31 2007: 192.168.170.1: <14>voipd[437]: audio: 8 (8 PCMA/8000)
Tue Jan 02 01:49:31 2007: 192.168.170.1: <14>voipd[437]: audio: 8 (8 PCMA/8000) => (8 (8 PCMA/8000))
Tue Jan 02 01:49:31 2007: 192.168.170.1: <14>voipd[437]: audio: 101 (101 telephone-event/8000)
Tue Jan 02 01:49:31 2007: 192.168.170.1: <14>voipd[437]: audio: 101 (101 telephone-event/8000) => (101 (101 telephone-event/8000))
Tue Jan 02 01:49:31 2007: 192.168.170.1: <14>voipd[437]: call from sip:[email protected] to 0 (sip0:0123456789)
Tue Jan 02 01:49:31 2007: 192.168.170.1: <14>voipd[437]: VoIP led value = 18
Tue Jan 02 01:49:31 2007: 192.168.170.1: <14>voipd[437]: >>>UDP Status: 100 Trying
Tue Jan 02 01:49:31 2007: 192.168.170.1: <14>voipd[437]: alerting(appl=5 plci=0xf05 ncci=0x0 outgoing)
Tue Jan 02 01:49:31 2007: 192.168.170.1: <14>voipd[437]: >>>UDP Status: 180 Ringing
Tue Jan 02 01:49:31 2007: 192.168.170.1: <14>mailer[2386]: csock: using poll
Tue Jan 02 01:49:31 2007: 192.168.170.1: <11>mailer[2386]: Couldn't load shared library  libavmssl.so - File not found - Success (0)
Tue Jan 02 01:49:31 2007: 192.168.170.1: <14>mailer[2386]: startup (Jul  6 2006 14:52:39) Mail: Subject: 02.01.07 01:52 - Anruf von 0123456789 auf Leitung xxxxxxx (SIP0#xxxxxxx) , From: "Fritz!Box" <[email protected]>, To: [email protected], Attachment: Null
Tue Jan 02 01:49:31 2007: 192.168.170.1: <14>mailer[2386]: dns: smtp.1und1.de: query
Tue Jan 02 01:49:31 2007: 192.168.170.1: <14>mailer[2386]: dns: smtp.1und1.de: 212.227.15.183 ttl=1318 from 127.0.0.1.
Tue Jan 02 01:49:31 2007: 192.168.170.1: <14>voipd[437]: <<<UDP Request: CANCEL sip:[email protected]
Tue Jan 02 01:49:31 2007: 192.168.170.1: <14>voipd[437]: >>>UDP Status: 481 Call Leg/Transaction Does Not Exist
Tue Jan 02 01:49:32 2007: 192.168.170.1: <14>voipd[437]: <<<UDP Request: ACK sip:[email protected]
Tue Jan 02 01:49:32 2007: 192.168.170.1: <14>voipd[437]: call from sip:[email protected] established
Tue Jan 02 01:49:32 2007: 192.168.170.1: <14>voipd[437]: DTMF filter off
Tue Jan 02 01:49:32 2007: 192.168.170.1: <14>mailer[2386]: Testmail sent
Tue Jan 02 01:49:32 2007: 192.168.170.1: <14>mailer[2386]: mailer finished with 0, Mailer-Response=250 Message 0ML21M-1H1Xt62jEM-0003tT accepted by mrelayeu4.kundenserver.de
Tue Jan 02 01:49:36 2007: 192.168.170.1: <14>voipd[437]: plci_connected(appl=5 plci=0xf05 ncci=0x0 outgoing)
Tue Jan 02 01:49:36 2007: 192.168.170.1: <14>voipd[437]: connected(appl=5 plci=0xf05 ncci=0x10f05 outgoing) NCPIlen=0
Tue Jan 02 01:49:36 2007: 192.168.170.1: <14>voipd[437]: allowed bandwidth 432000 for sip:[email protected]
Tue Jan 02 01:49:36 2007: 192.168.170.1: <14>voipd[437]: [email protected]: bandwidth left 432000
Tue Jan 02 01:49:36 2007: 192.168.170.1: <14>voipd[437]: audio: 18 (18 G729/8000)
Tue Jan 02 01:49:36 2007: 192.168.170.1: <14>voipd[437]: audio: 18 (18 G729/8000) => NOT CONFIGURED
Tue Jan 02 01:49:36 2007: 192.168.170.1: <14>voipd[437]: audio: 3 (3 GSM/8000)
Tue Jan 02 01:49:36 2007: 192.168.170.1: <14>voipd[437]: audio: 3 (3 GSM/8000) => NOT SUPPORTED
Tue Jan 02 01:49:36 2007: 192.168.170.1: <14>voipd[437]: audio: 4 (4 G723/8000)
Tue Jan 02 01:49:36 2007: 192.168.170.1: <14>voipd[437]: audio: 4 (4 G723/8000) => NOT SUPPORTED
Tue Jan 02 01:49:36 2007: 192.168.170.1: <14>voipd[437]: audio: 0 (0 PCMU/8000)
Tue Jan 02 01:49:36 2007: 192.168.170.1: <14>voipd[437]: audio: 0 (0 PCMU/8000) => (0 (0 PCMU/8000))
Tue Jan 02 01:49:36 2007: 192.168.170.1: <14>voipd[437]: audio: 8 (8 PCMA/8000)
Tue Jan 02 01:49:36 2007: 192.168.170.1: <14>voipd[437]: audio: 8 (8 PCMA/8000) => (8 (8 PCMA/8000))
Tue Jan 02 01:49:36 2007: 192.168.170.1: <14>voipd[437]: audio: 101 (101 telephone-event/8000)
Tue Jan 02 01:49:36 2007: 192.168.170.1: <14>voipd[437]: audio: 101 (101 telephone-event/8000) => (101 (101 telephone-event/8000))
Tue Jan 02 01:49:36 2007: 192.168.170.1: <14>voipd[437]: 127.0.0.2 10000 - 7078 audio 0(PCMU)
Tue Jan 02 01:49:36 2007: 192.168.170.1: <14>voipd[437]: Codec PCMU (0) - audio 98933 hold=none (none) (by remote)
Tue Jan 02 01:49:36 2007: 192.168.170.1: <14>voipd[437]: rtp_start_session(image): no session definition
Tue Jan 02 01:49:36 2007: 192.168.170.1: <14>voipd[437]: rtp_start_session(video): no session definition
Tue Jan 02 01:49:36 2007: 192.168.170.1: <14>voipd[437]: bridgelimit: nConnections=1
Tue Jan 02 01:49:36 2007: 192.168.170.1: <14>voipd[437]: bridge lan set to max 30 packets/100ms
Tue Jan 02 01:49:36 2007: 192.168.170.1: <14>voipd[437]: >>>UDP Status: 200 OK
Tue Jan 02 01:49:37 2007: 192.168.170.1: <14>voipd[437]: >>>UDP Status: 200 OK
Tue Jan 02 01:49:38 2007: 192.168.170.1: <14>voipd[437]: >>>UDP Status: 200 OK
Tue Jan 02 01:49:39 2007: 192.168.170.1: <14>voipd[437]: disconnected(appl=5 plci=0xf05 ncci=0x10f05 outgoing): remote: 0x3490 (0x3301) - 
Tue Jan 02 01:49:39 2007: 192.168.170.1: <14>voipd[437]: ocfree: fail 0 normal 0 small 0 large 0
Tue Jan 02 01:49:39 2007: 192.168.170.1: <14>voipd[437]:         underrun 0 max_ackqueuelen 0
Tue Jan 02 01:49:39 2007: 192.168.170.1: <14>voipd[437]:         small packets merged 0, output 0 and consumed from CNG 0
Tue Jan 02 01:49:39 2007: 192.168.170.1: <14>voipd[437]: ocmode: normal 0 merged 0 delayed 0
Tue Jan 02 01:49:39 2007: 192.168.170.1: <14>voipd[437]: dropped 0 packets with 0 samples and one sample in 0 packets
Tue Jan 02 01:49:39 2007: 192.168.170.1: <14>voipd[437]: generated noise: oben 0/unten <=0
Tue Jan 02 01:49:39 2007: 192.168.170.1: <14>voipd[437]: QoS-Report(> 0123456789 via 204.50.80.13): PS=74;OS=17760;SP=0/0;SO=0;PR=0;OR=0;CR=0;SR=0;PL=0;BL=0;EN=PCMU;DE=;JI=0
Tue Jan 02 01:49:39 2007: 192.168.170.1: <14>voipd[437]: Codec - (-) - audio 0
Tue Jan 02 01:49:39 2007: 192.168.170.1: <14>voipd[437]: bridgelimit: nConnections=0
Tue Jan 02 01:49:39 2007: 192.168.170.1: <14>voipd[437]: bridge lan set to full speed
Tue Jan 02 01:49:39 2007: 192.168.170.1: <14>voipd[437]: >>>UDP Request: BYE sip:[email protected]
Tue Jan 02 01:49:39 2007: 192.168.170.1: <14>voipd[437]: sent: 74 (17760) voice, 0 (0) CN, 0 silence
Tue Jan 02 01:49:39 2007: 192.168.170.1: <14>voipd[437]: jitter packets 0 bytes 0 drop_toolate 0 drop_duplicates 0
Tue Jan 02 01:49:39 2007: 192.168.170.1: <14>voipd[437]:        wrong_seq 0 packets lost 0 (max burst 0)
Tue Jan 02 01:49:39 2007: 192.168.170.1: <14>voipd[437]: rtpsession drop_nobuffer 0 drop_tooshort 0 decoder failed 0
Tue Jan 02 01:49:39 2007: 192.168.170.1: <14>voipd[437]: >>>UDP Request: BYE sip:[email protected]
Tue Jan 02 01:49:40 2007: 192.168.170.1: <14>voipd[437]: >>>UDP Status: 200 OK
Tue Jan 02 01:49:40 2007: 192.168.170.1: <14>voipd[437]: >>>UDP Request: BYE sip:[email protected]
Tue Jan 02 01:49:42 2007: 192.168.170.1: <14>voipd[437]: >>>UDP Request: BYE sip:[email protected]
Tue Jan 02 01:49:44 2007: 192.168.170.1: <14>voipd[437]: >>>UDP Status: 200 OK
Tue Jan 02 01:49:46 2007: 192.168.170.1: <14>voipd[437]: >>>UDP Request: BYE sip:[email protected]
Tue Jan 02 01:49:48 2007: 192.168.170.1: <14>voipd[437]: >>>UDP Status: 200 OK
Tue Jan 02 01:49:50 2007: 192.168.170.1: <14>voipd[437]: >>>UDP Request: BYE sip:[email protected]
Tue Jan 02 01:49:52 2007: 192.168.170.1: <14>voipd[437]: >>>UDP Status: 200 OK
Tue Jan 02 01:49:54 2007: 192.168.170.1: <14>voipd[437]: >>>UDP Request: BYE sip:[email protected]
Tue Jan 02 01:49:56 2007: 192.168.170.1: <14>voipd[437]: >>>UDP Status: 200 OK
Tue Jan 02 01:49:58 2007: 192.168.170.1: <14>voipd[437]: >>>UDP Request: BYE sip:[email protected]
Tue Jan 02 01:50:00 2007: 192.168.170.1: <14>voipd[437]: >>>UDP Status: 200 OK
Tue Jan 02 01:50:02 2007: 192.168.170.1: <14>voipd[437]: >>>UDP Request: BYE sip:[email protected]
Tue Jan 02 01:50:04 2007: 192.168.170.1: <14>voipd[437]: >>>UDP Status: 200 OK
Tue Jan 02 01:50:06 2007: 192.168.170.1: <14>voipd[437]: >>>UDP Request: BYE sip:[email protected]
Tue Jan 02 01:50:08 2007: 192.168.170.1: <14>voipd[437]: >>>UDP Status: 200 OK
Tue Jan 02 01:50:10 2007: 192.168.170.1: <14>voipd[437]: >>>UDP Request: BYE sip:[email protected]
Tue Jan 02 01:50:11 2007: 192.168.170.1: <11>voipd[437]: 498341xxxxxxx: BYE failed 5
Tue Jan 02 01:50:11 2007: 192.168.170.1: <14>voipd[437]: VoIP led value = 1
Tue Jan 02 01:50:11 2007: 192.168.170.1: <14>voipd[437]: call from sip:[email protected] terminated (200)

evilbunny · 2 Jan 2007

Moonbase schrieb:
The Fritz!Boxes don't have a "delayed ring" feature (and if they had, I guess many users wouldn't like it).

Only has to delay 500 to 1000 ms, which is enough time for the device to get a cancel packet to say don't bother with the call

Moonbase schrieb:
Seems it's partly a question of "philosophy":

Well unfortunately technology can't deal with all circumstances, it's a shame there isn't some other way to check that a SIP URI is valid without, so it's a matter for policy/philosphy...

Moonbase schrieb:
a) You (e164.org) might wish to somehow check if a number is valid. Question: Would it be enough to get something like a "486" back from the client? It might be enough, just to show that it's actually responding. Same applies to "480" (Temporarily unavailable) and "488" (Not acceptable here), of course. What do you think?

I am inclined to agree with you that 486 and 480 should be accepted, since if the remote end is following RFCs the SIP URI is valid but just not there at the moment.

408, 503, 504, 603 is a little more tricky, it attempted to make the call, it's possibly being diverted from somewhere else, but it would make call setup times lag until a timeout and another route is tried.

415, like 486/480 should also be accepted, it's just a handshake failed due to codec negoiations (hopefully this will never happen as I've tried to list all possible codecs in the INVITE packet).

Moonbase schrieb:
b) I should like to see something like a "488" (Not acceptable here) in case of a SIP call reject. It is quite okay to signal a "busy" in the analogue PSTN but for SIP this should be more specific... I feel. But that's off-topic here, something for AVM to implement. (AVM: Are you listening? *g*)

I didn't think this was off topic, since this effects ENUM+VoIP, however they might include a different option to signal 488 and keep the 486 in place, reject and perminent reject perhaps?

Moonbase schrieb:
No solution, but just my thoughts worth about 2 cents at 4:33 a.m. ;-)

You have given a possible solution, all we care about is that others can call the number, the probe just needs to work that much out, so I think if we see a return of 480/486 it should be considered the same as a 18x/200, the other return codes I'm not so sure how to handle them.

Moonbase · 2 Jan 2007

Thanks again for brainstorming...

As far as I understand the protocol, I'd probably let a "probe" decide as follows:

POSITIVE (i.e., client reachable/existant)

on all class 1 and 2 responses, except for 202
class 4 responses 415, 480, 485, 486, 487, 488, 491 (since all of these are actually TE responses that somehow say "we are here but cannot respond just now")

NEGATIVE (i.e., somehow invalid)

202 (referral, might mean a delay/lagging)
all class 3 responses (moved, alt. service, etc.)
class 4 responses 400..414, 416, 42x, 482..484 (all problems that mean there'll be no one who can actually answer)
all class 5 responses (server problems)
all class 6 responses (global failures)

I'd also suggest to re-probe after some hours/days before finally deciding that a number is invalid since some of the "Negatives" might be temporary.

Now, what do you think?

evilbunny · 2 Jan 2007

Moonbase schrieb:
POSITIVE (i.e., client reachable/existant)

on all class 1 and 2 responses, except for 202

In the SIP specifications (RFC 3261), the only 2xx response is 200, 100 Trying only indicates the remote end received the packet, not that the request is valid.

Moonbase schrieb:
class 4 responses 415, 480, 485, 486, 487, 488, 491 (since all of these are actually TE responses that somehow say "we are here but cannot respond just now")

I don't agree with 485, since this can't be automated to find the correct contact to send a call to.

487 is a request terminated, so this will happen after the call is sent a cancel or by packet, not after the invite packet

488 I'm not so sure about, it's a bit ambigous in this situation.

491 is almost the same as 486, except the first call hasn't been answered yet, so yes this should also be acceptible.

Moonbase schrieb:
NEGATIVE (i.e., somehow invalid)

202 (referral, might mean a delay/lagging)

all class 3 responses (moved, alt. service, etc.)

class 4 responses 400..414, 416, 42x, 482..484 (all problems that mean there'll be no one who can actually answer)

all class 5 responses (server problems)

all class 6 responses (global failures)

We are storing a couple of 400's, 500's and 600's as temp failures, rather then hard failures.

Moonbase schrieb:
I'd also suggest to re-probe after some hours/days before finally deciding that a number is invalid since some of the "Negatives" might be temporary.

Well we were thinking about to retry a couple of times within 5 minutes of failures, and then email the person and disable the route, and re-try every half hour or so and re-enable active routes, we haven't really thought this far ahead, the primary concern was actually find dead routes, and prevent routes from being added to the database that can't be contacted by anyone.

Moonbase · 2 Jan 2007

You're correct on 485 - I overlooked that... Sorry.
Response Code 202 has been defined in RFC 3265.

Well, anything feasible that we can come up with is worth it - ENUM via e164.org is definitely worth some efforts! To the mutual benefit of user community and providers alike...

But I really have to get a nap now... Let us know about proceedings... G'nite... Yawn...

evilbunny · 2 Jan 2007

Moonbase schrieb:
Well, anything feasible that we can come up with is worth it - ENUM via e164.org is definitely worth some efforts! To the mutual benefit of user community and providers alike...

I think anything that can improve the quality of results is a good thing, but we have to make sure people aren't annoyed too much as well.

Maybe we can encourage to get manufacturers to include a CID blocking feature that acts as if it would normally, but without ringing the phone.

kombjuder · 2 Jan 2007

Hello,

for my asterisk calls with CallerID "0123456789" are not a problem. I can handle them with a quiet answer, if I know that they will occour sometimes.

But what's with the lots of sip to phone adapters? The most of them aren't able to handle a call in this way.
Maybe the ideas of moonbase will help to find a solution.

Also think in the localtime.

evilbunny · 2 Jan 2007

kombjuder schrieb:
But what's with the lots of sip to phone adapters? The most of them aren't able to handle a call in this way.

Well in terms of options I've been speaking to the voxalot.com guys about our options in terms of verifying the number (via these sip probes), but at the same time not ringing the handset, we're going to talk about it more tomorrow but it sounds promising and something simple other providers could also do.

kombjuder schrieb:
Maybe the ideas of moonbase will help to find a solution.

This might be useful for companies making hardware/software, but providers could implement solutions much sooner.

kombjuder schrieb:
Also think in the localtime.

Yes that has been covered with the code changes I made yesterday, now everyone needs to update their settings

Moonbase · 2 Jan 2007

CID blocking, CallerID for probe calls

evilbunny schrieb:
Maybe we can encourage to get manufacturers to include a CID blocking feature that acts as if it would normally, but without ringing the phone.

Personally, I don't believe you can make each and every SIP phone and/or PBX manufacturer in the world change whatever they have... To my findings, most of them apparently use 486 for "call reject" and 480 for "Do Not Disturb".

---

Regarding the CallerID you use for the probe calls:

To most PBXes in the world, the number "0123456789" looks like a valid national long-range number (and might actually be registered!) - i guess this is not a good idea.

Couldn't you use a number out of the +88299 or +878 blocks (and maybe even set up a "E2U+ADDRESS" record for it so it can be verified)?

This should make a world-unique ENUM CallerId that can be verified to be a probe call from e164.org (instead of the unreliable construct "arbitrary number sequence").

Also, it should help keeping things standardized and help people who set up routing and/or dialling plans.

Your opinion? (And thanks for all your input)

---

N.B.: Thanks for the hint to update the account's "probe call prefs" - done ;-). And thanks for the great idea to have everyone enter their preferred times even!

evilbunny · 2 Jan 2007

Moonbase schrieb:
Couldn't you use a number out of the +88299 or +878 blocks (and maybe even set up a "E2U+ADDRESS" record for it so it can be verified)?

Technically 88299 is a valid range, there is no "private" space like there exists for IP addresses, I'm not sure what to do here, alternately they could just filter on the caller ID name, instead of the number.

Moonbase schrieb:
N.B.: Thanks for the hint to update the account's "probe call prefs" - done ;-). And thanks for the great idea to have everyone enter their preferred times even!

It was kind of needed to reduce the amount people are annoyed

Moonbase · 2 Jan 2007

evilbunny schrieb:
... I'm not sure what to do here, alternately they could just filter on the caller ID name, instead of the number. ...

Well, just get yourself a "valid" ENUM international SIP number and use it as the CallerID. Problem is, many TEs/UAs won't be able to check the Caller ID Name (and probably cannot display it, like on a phone with caller history and only a seven-segment LCD display).

It's easier to see something like "0088299123456789" in a call history and just know it's a verification call from e164.org - for both humans and (dumb) machinery... since, technically, a national long-distance "phone number" like "0123456789" would mean extension 56789 in Bedford, U.K., for example (which might even be registered).

evilbunny · 2 Jan 2007

Moonbase schrieb:
Well, just get yourself a "valid" ENUM international SIP number and use it as the CallerID. Problem is, many TEs/UAs won't be able to check the Caller ID Name (and probably cannot display it, like on a phone with caller history and only a seven-segment LCD display).

This is what we will most likely do.

Moonbase schrieb:
since, technically, a national long-distance "phone number" like "0123456789" would mean extension 56789 in Bedford, U.K., for example (which might even be registered).

Actually no, UK numbers are 11 digits usually. That doesn't mean it might not be valid else where.

Moonbase · 2 Jan 2007

Well, I guess we dug up enough to think about together... Now let's see what comes out of it ;-)

Thanks for sharing thoughts - And please let us know about any changes.

Dead route information stored in e164.org

Neuer User

Neuer User

IPPF-Promi

Neuer User

Neuer User

Mitglied

Neuer User

Mitglied

Neuer User

Mitglied

Neuer User

Mitglied

Neuer User

IPPF-Promi

Neuer User

Mitglied

Neuer User

Mitglied

Neuer User

Mitglied

Statistik des Forums