I found we can easily set the CAller Number Type/Id/Presentation/Screening.
But where the heck do we set the Called Number Type and Id - required by some of our providers now.
Can't seem to find a data structure that would allow us to set that information.
Hello. What Brooktrout product and call control type are you using?
ha ha, ya that would be kinda critical - T1s broken out from a DS3 - T1/PRI card - not sure exactly which model. But for sure T1/PRI, thanks.
OK, it sounds then that you'd be using the TR1034 digital board if you use PRI T1. Presentation and screening are parameters for the calling party number anyway.
I'm not sure what you mean by the Called Number Type and ID though. By ID, I would think that would just be the called party number itself which is the dialstring your application would use when placing a call. The only "Type" that is set is the Numbering Type which is set from callctrl.cfg but is not associated with the called party number itself. The Numbering Type is just part of the ISDN Setup message. Are those what you are referring to?
Well this is all very historical stuff - and I gotta dig out my specs. The existing code for Diva cards for many years never set any special values for Calling or Called party number blocks. But in the last few years we have had to change that alot on our Diva code to setup Called Number Type and Id - and on Calling Number we have to set Type, Id, Presentation and Screening. Differently for different providers it seems.
So of course now we are converting this code to brooktrout cards and were just trying to match up most of the features and we could find the Calling Number stuff - but nothing for the Called number stuff, and yes I did expect it to maybe be a configuration setting.
here is my snippet from the specs - which doesn't cut/paste very well at all - so here is my transalation
3rd octet - contains '1', then 3 bits of Type of number and 4 bits of Id
My assumption is Eicon sends 0/0 if not specified, but I do not have a T1 analyzer to tell for sure.
For some of our providers we need to set '1' Id and '2' Type, which is Isdn and National for domestic calls but we set '0' and '0' for international since that is the way to trip '011' parsing etc.
So you can see a bit of a concern we have is how to flip this on the fly from call to call. I have a feeling I end up with multiple config files for domestic vs international possibly?
OK, when you mention "Isdn and National" those are values for Numbering Plan and Numbering Type and those are set in callctrl.cfg. I can't speak for Eicon boards at all, but I do know that the Numbering Plan and Type are not associated with the calling party number specifically. They are part of the whole ISDN Setup message.
Well they are associated in that they must match what you put into the calling number - mis-match and things will go badly. Very surprised I can set screening/presentation on the fly, but not the other 2 pieces. And totally unsure on Called number information field. I guess I gotta go callctrl.cfg spelunking now!! thanks.
I just realized it's actually called the
Figure 4-16/Q.931 – Calling party number information element
So it has to be directed related to the
Figure 4-14/Q.931 – Called party number information element
Right? just somehow they spread the values for the Q.931 SETUP subframe into many different places.
So I am looking for
- Id(aka plan)
- Presentation - callctrl.cfg - and via args_cc.calling_party_presentation
- Screening - callctrl.cfg and via args_cc.calling_party_screening
- Type - callctrl.cfg and ?via? args_cc override_numbering_type
- Id(aka plan) - callctrl.cfg and ?via? args_cc override_numbering_plan
So I found the CallCtrl.Cfg documentation for
Specifies a value that identifies the type of numbering plan used for
outbound calls (called party number).
Specifies a value that identifies the type of telephone number used
for outbound calls (called party number).
Specifies a value that indicates the type of presentation of the calling
party number the port uses when placing an outbound call.
Specifies a value that indicates whether the port provides and validates
the calling party number passed to the called party.
So the big question is where do you set plan/type information for the calling party number?
args_cc.connected_num looks promising
but that's for the 'CONNECTED' message, not the SETUP message.
Sorry for the long message but I am trying to lay this all out in my head too.
Without this we gotta rethink our move to Brooktrout I think, since some of our providers require specific values, and not consistent between them either.
I did a test with to look at a Setup message with an ISDN message decoder. I was incorrect about that the calling party and called party numbers having their own numbering type and plan. However, for the Brooktrout boards, the numbering type and plan are set by the same parameter in callctrl.cfg for both calling party and called party numbers. So when you set one, you've set both.
Thank you very much for digging further!! In our case I think we happen to luck out here, so far the values do match between called/caller - except for doing international calls.
But even use say different or same config files for that situation - international needing '0/0' for dial parsing vs id=1, type=2 for most domestic calls.
I have a problem since based on our current configuration for providers (that works) interinational Called needs 0/0 to get parsed properly, but Calling needs 1/2 for Id/Type - that could get us into some troubles.
This is just based on various configurations and here is a bit of a summary based on what we currently do/found works vs 'not works'.
use Called Id=1, Type=2, Intl=0/0, Calling Id=1, Type=2, Intl=same
use Called 0/0, Calling Id=1, Type=2, Intl=same
use Called Id=1, Type=2, Intl=0/0, Calling Id=1, Type=2, Presentation=0, Screening=1, Intl=same
So we maye still have some issues
Hello, it sounds here that at this point a formal case should be with Support. You can do that by contacting email@example.com. This forum is really meant just to answer quick questions like pointing to the available parameters in callctrl.cfg, for example. This appears now to be getting into the territory of a possible feature request, or certainly at least a deeper dive, and so a support case should be opened to handle that.