How to identify which spX an incoming call is received on

[ianobi]

The question came up recently of how to identify which spX an incoming call is on from the phone attached to an OBi. sp1 may be a business line and sp2 might be a home line, so each would need answering differently.

An unrelated suggestion by user "colic" in another thread made me consider how to manipulate CallerIDs using digit maps. This example takes the incoming CallerID and transforms it before passing it on to the Phone Port:

Voice Services > SP1 Service > X_InboundCallRoute:
{(<**1>(@@.|?)):ph}

This allows any alphanumeric CallerID or anonymous (no CallerID) and prepends **1 to it. If the CallerID is 12345678912, then the phone will display **112345678912. The **1 showing the call has come in on sp1.

If we are using the "oleg method" to defeat scanners and assuming that my AuthUserName is 1212121, then the rule would be:

{(<**1>(@@.|?))>(1212121):ph}

You could prepend **1 for sp1, **2 for sp2 etc.


There may be other uses for this. Any valid digit map can be used. Something like this:

{(<(@@.|?):45454545>)>(Msp2):sp2} would change the incoming CallerID to 45454545 before sending the incoming digits out on sp2 (another form of spoofing). I've not tested that one! I'm not sure that is very useful, but someone might like to think about it and do some tests.

[Encino_Stan]

The question came up recently of how to identify which spX an incoming call is on from the phone attached to an OBi. sp1 may be a business line and sp2 might be a home line, so each would need answering differently.

X_RingProfile should be set different from sp1 and sp2.
sp1 = A, sp2 = B. You can tell by the ring which like is incoming.

[ianobi]

Encino_Stan,

You are quite right that in most cases using different ring patterns is all that's needed by most users. However, there are some exceptions:

Users with an OBi202 may find four ring patterns a bit confusing.

Some dect phones and many softphones cannot cope with different ring patterns, so a visual aid is helpful.

This transforming of CallerID can be forwarded to trunks as well as to the phone port. This may be helpful to some users – I'm not sure why just yet! This is not just CallerID spoofing, but you can change ranges or individual CallerIDs in any way a digit map can accommodate.

Let's all keep throwing ideas into the mix, who knows who they might help   

[CoalMinerRetired]

There's no reason you can't do both, caller ID Prefix and a distinctive ring pattern.  Maybe even make them match somehow.

On ring patterns, I experimented quite a lot with them when I first got an Obi.  A few observations and rules of thumb:

- They do not always act as granular as you expect. For example with a 0.1 second off (or on) cycle, you might not hear it at that small a slice of time. This was true even though ringers are all electronic and not mechanical, at first I thought there was some mechanical inertial at play, but that is not so.

- My observation is the Obi software driving the timing cycles might not always be consistent. The example here is a three ring pattern I tried. It was (.2 sec ring, .1 sec off) repeated three times, i.e., three .2 sec rings with three .1 second off, then wait four seconds, 60;(.2+.1,.2+.1,.2+4). However the initial ring(s) before the first 4 second wait only did two rings, and sometimes the second ring would only have two of the three rings.  Experimenting with three or four different handsets let me to conclude it was the Obi not the handsets that was the cause of the inconsistency. 

- The delivery of Caller ID in inter-related to Ring Patterns. With certain ring patterns you can prevent the Caller ID from ever being sent from the Obi to a handset.

Caller ID used in North America is defined as being delivered between the "first and second ring bursts." What is not ever stated in that is the rings are assumed to be the usual 2.0 sec ring and 4.0 seconds off cadence/pattern, the traditional US Baby Bell ring pattern (there's a more specific name for it somewhere). An Obi does not 'analyze' you custom ring pattern and determine when the first and second ring burst is, it assumes the standard 2 sec on/4 sec off and sends the Caller ID accordingly (betweeen 2.0 and 4.0 seconds into the ringing). I don't think this is unique to an Obi, I suspect all handsets are designed to receive the modulated tones that are the caller ID signals in the pre-defined slice of time.  The point is you can make all the custom rings you want, so long as they allow for the Caller ID delivery.  Experimenting is the best way to figure this out. 

There's a suggestion in the feature request section related to this, to make a ring pattern simulator to test your custom ring patterns. I should update it to ask to include Caller ID delivery as part of the test also.

I forgot some of this, and I'm regurgitating some ideas from an old but interesting post, here.

[langchen]

thanks that is what I am looking for.