Orchid V4, V4+ and Ranger 400 phone users - Discussion

BritBrat

Opppp's wrong thread.

neilgooduk

Hello,

I have got some DECT phones which have 1899 already programmed infront of the number. Is there a routing which would route them over the CPS in the evenings and weekends please? This would save the painful exercise of taking off all the 1899's......these DECT phones do not seem to allow you to scroll back through the number deleting only the digits you want, you seem to have to delete all the numbers all the way back to the start and then re-enter the number.....

Also, a further thing would be to strip off the 1899 and route the calls over 18185 instead......

Many thanks,

Neil Good

Heinz

neilgooduk wrote: »

Hello,

I have got some DECT phones which have 1899 already programmed infront of the number. Is there a routing which would route them over the CPS in the evenings and weekends please? This would save the painful exercise of taking off all the 1899's......these DECT phones do not seem to allow you to scroll back through the number deleting only the digits you want, you seem to have to delete all the numbers all the way back to the start and then re-enter the number.....

Also, a further thing would be to strip off the 1899 and route the calls over 18185 instead......

Many thanks,

Neil Good

I used to have that 'problem' before I got my Orchid (I had a BT line, a CPS and 1899/18185 accounts).

Assuming you are not using an Orchid but just the DECT phones, the workaround is to double-program phonebook entries (e.g. JOHN - DAY 189901234567890 and JOHN -E&W 01234567890).

OTOH, if you have an Orchid already, at least you'll only have to re-program the DECT handsets once.

keefrto

Hello, cheers for all the backgoround work Heinz
:beer:

TwoLenses

Neil, I'm no expert, but if you have an Orchid dialler this might fix your 1899 prefix problem without needing to reprogram your phone:

Add a new route to your Orchid routing table, with the routing code set to "1899 - 1899 Translation", with its Day Carrier set to "Call 1899" (or to "18185" if you want to route the calls over 18185 instead) and its Night and Weekend Carriers set to "0 - Not Routed" (which should send the call over your CPS carrier).

I find the Orchid dialler documentation a little lacking in detail, but I think routes with the T attribute strip off the code which caused the call to match that route (so it would strip off the 1899 prefix in this case), then route the remaining digits according to the translations set up in the routing table entry. Perhaps Heinz can confirm that, or put me straight?

The downside is that if you have any other phones going through the same dialler, then using the 1899 prefix on those phones would trigger the same routing.

Heinz

Unfortunately, that's not how Routing rules with the 'T' attribute work (they don't strip digits out, they merely point at a Carrier).

So, the problem is not the Routing rule (it would be easy to add one - 1899*1*9 - with a 'T' attribute to 'catch' all the numbers programmed with a 1899 prefix in Neil's DECT handset), it's the Carrier. A Carrier code would have to be created for each number in the DECT's memory.

wygde3

I wonder if someone can help ...

I recently bought a Gotalk DT868 from Orchid to replace my Ranger 400. I got it a couple of weeks ago and today tried setting it up.

All went well and I tried dialling home. I then went to CWclient to check that it had got through. With the Ranger 400 I had a BT routing table and a Primus table (which reflected when I first had BT and then changed to Primus). It seems that Orchid set me up a new table with 42 (instead of 25 which is the Ranger 400) as the product but based on teh BT routing table. I noticed that the phone had got through and updated fine.

I wanted the DT868 to use the Primus settings so I copied the old Primus for the 25 to create a routing table called Primus for 42 (and renamed the old one Primus for 25 to distinguish it). I then amended Primus for 42 to have 42 as the product and happily went off to force an update. Didn't work. The New Routing Table was Primus for 42 but the Active Routing table was BT and the Last Contact Date and time hadn't changed.

I then changed the routing table back to BT and forced home. It contacted fine (evidenced by a change in the Date/Time of teh Last Contact Date).

Tried several times making Primus for 42 the Active Table, including going through the full reset Heinz has suggested elsewhere, but couldn't get it to take.

Anyone know what's going on? Help gratefully received!

Heinz

I assume you mean your Ranger program(s) appeared in CW Client with a Product code (first column) of 25 and the DT868 is a Product code 42.

I think what you're saying is that Orchid allocated the contents of your Ranger 400 'BT' program instead of your 'Primus' program to your new DT868 and you're trying to correct that.

I think you've tried to do that by changing the Product code in your old 'Primus' program from 25 to 42. I don't think you can do that.

I think what you need to do (but at least you will only have to do it once) is make a copy of the DT868's program which Orchid allocated, amend it to conform with your current (Primus) requirements, save it with a new name (I recommend the name includes the date) and then allocate it as the New Routing Table before forcing a call home again.

I think that made sense.

wygde3

Yep, Heinz. I was hoping to avoid doing that ... I suppose there's something 'under the bonnet' which I can't get to. I'll try your suggestion. Thanks.

P.S. I think the Orchid folk do a wonderful job but I think we could do with an update of CWClient! I've a raft of suggestions which I think could make it really easy to use and update (e.g. in teh area of allocating new cheap providers (why do we have to email them?) through to having as many routings within a table as you want instead of just 9 (which are too few for me!). Anyway, I don't want to complain as it's so useful even as it is ...

Heinz

wygde3 wrote: »

Yep, Heinz. I was hoping to avoid doing that ... I suppose there's something 'under the bonnet' which I can't get to. I'll try your suggestion. Thanks.

P.S. I think the Orchid folk do a wonderful job but I think we could do with an update of CWClient! I've a raft of suggestions which I think could make it really easy to use and update (e.g. in teh area of allocating new cheap providers (why do we have to email them?) through to having as many routings within a table as you want instead of just 9 (which are too few for me!). Anyway, I don't want to complain as it's so useful even as it is ...

Don't use Carrier No.9 - it may appear to be there, but it isn't.

The retail price of the products probably has quite an impact on whether 10+ year old software will be updated!