Hi all,
for historical reasons and early bugs in our dialplan I made from the beginning,
the first OCTOI users are receiving inbound calls using wrong called-party address.
This [still] affects
* totalizator
* drdeke
* marrold
* tmwawpl
* billy549
* manawyrm
* tom
* gruetzkopf
* roox
Instead of receiving inbound calls as [I've been told it was customary]
type=subscriber with no area code, the inbound calls actually arrive
with potentially undefined/various type-of-number and a 030 prefix.
Sending a leading '0' is always wrong in ISDN, as the valid
representations of for example my ISDN deskphone are either:
ton=subscriber / 12342111
ton=national / 3012342111
ton=international / 493012342111
As you can see, none of those formats have a 0 in front of the area
code.
I would like to migrate the users stated above to the new scheme (which
is already used by a bunch of other users just fine). In the new
scheme, the called party number for normal berlin subscribers would
always be ton=subscriber without 0, 030 or 30 prefix and just the final
8 'local' digits.
I don't want to do this unilaterally and break currently working setups.
So please come forward individually and let me know when I should make
the switch-over for your line. You can just tell me a date and I'll do
it then.
Thanks for your attention,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> https://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Greeting from the engine room!
During RetroNetCall earlier this week, we had a live debug session for
the dialplan on DIVF, the yate based softswithc we use as central switch
within the OCTOI network.
We were able to collaboratively fix a number of bugs (mostly reported by
cquirin), which means we are catching more cases in which we were doing
something wrong in the past.
For those not that familiar with ISDN: In ISDN you not only have a
string of dialled digits (like in analog POTS), but you also have the
numbering plan indication and type-of-number fields together with a
number. So both calling and called party can be in many different
formats, and we need to try to make sense of them in the various
situations, convert them to the most suitable format at the given point
durin processing, etc.
The fixes implemented might cause some existing setups to suddently
fail. This is due to the fact that DIVF was doing something wrong in
the past and has been fixed now. If you previously configured the
equipment on your end to expect/generate the wrong format, you might
need to make the corresponding change at your end. So please do a round
of re-testing and reach out in case anything is not working for you, or
you need clarification.
I apologize for any turbulence this has caused, but I do think we all
agree we need to aim to configure everything as proper as we can, to
resemble the public ISDN service of the past.
Thanks for your attention,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> https://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
