I’m not familiar with QSIG, although the traces suggest that it is using ASCII, rather than telephony BCD, however, in my long past dealings with System X, I am pretty sure that the SS7 Telephony User Part only supports four bits per digit, so I wouldn’t expect an ASCII D to get across the public network. Moreover, I’m not aware of any use of the a, b, c, d digits.
So, firstly, by D do you mean DTMF D, or ASCII D?
Secondly, what is supposed to be responding to this D?
As to the different number format modes, I think you need to omit the initial 0 (or whatever is used in your country) when providing a National Number Dialled number.
This wouldn’t allow the sending of ASCII D, and I doubt it actually allows a, b, c, d, * or # either. (RFC 2916 doesn’t permit them when mapping to DNS names.)
The 44 is an ASCII D. Whether this means literally D or the extended BCD d digit, in QSIG, I don’t know.
[70 0d 80 {skip} 30 30 31 64]
Called Number (len=15) [ Ext: 1 TON: Unknown Number Type (0) NPI: Unknown Number Plan (0) ‘{skip}001d’ ]
< Cause (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) Spare: 0 Location: User (0)
< Ext: 1 Cause: Invalid number format (28), class = Normal Event (1) ]
well, “size doesn’t matter”.
How to call that numbers from asterisk?
“D” at end, is a routing firewall to avoid the number would be accessible by any person who does dial the number without d on the end.
It looks to me that your service provider is rejecting the D (and you still haven’t explained what you actually mean by D), probably because their network cannot transmit it.
Are you sure that the D should not be sent as a DTMF D, in band, after the service provider has established the call.
ABCD are the Extensions of Touchtones and they are usually found on Special Test phones (the ones that the Telephone Installers have). As far as I know, these numbers are not used by anyone except maybe the military.
I don’t think ISDN will accept these digits as a dial sequence, and as a previous poster mentioned, perhaps you should send them as DTMF instead of signalling.
Or if Asterisk doesnt support A B C D as DTMF, get a Sound Editor like Cool Edit Pro and Generate the A B C or D and Save them to a Wave File. After your call is answered, play them as a Prompt.
There may be terminology problems here and there is a limit on how much time I can spend on this, but when you said you used DTMF, did mean you did something like:
wait(1)
senddtmf(d)
after the Dial application returned?
Note that what you actually sent to the switch was in ASCII, not hex, and a hex d in TBCD corresponds to digit b. TBCD cannot represent digit d as the hex f code is used for something else, see, for example: <http://www.itu.int/ITU-T/asn1/database/itu-t/q/q825/1998/Q825-CDR-ASN1Module.html>. As TBCD is probably used in the public network connection protocols that means you can’t reliably send digit d and to send a TBCD 0xd, you would need to send digit b.
I have a feeling that this question would be better addressed to the support department of the vendor of the equipment you are trying to access.
Nope, under “tried DTMF” i mean:
Dial(ZAP/{skip}123,D(d))
Also, I have tried variants
Dial(ZAP/w{skip}123d)
Dial(ZAP/{skip}123wd)
Dial(ZAP/{skip}123dw)
with overlapdial=yes
Well, I have tried
Dial(ZAP/{skip}123b)
[70 0d 80 {skip} 31 32 33 62]
Called Number (len=15) [ Ext: 1 TON: Unknown Number Type (0) NPI: Unknown Number Plan (0) ‘{skip}123b’ ]
and
Dial(ZAP/{skip}123B)
[70 0d 80 {skip} 31 32 33 42]
Called Number (len=15) [ Ext: 1 TON: Unknown Number Type (0) NPI: Unknown Number Plan (0) ‘{skip}123B’ ]
With also no luck.
Provider (In-Telegence) says, that there no setup messages in traces with letters come to his end. So, seems that messages just not comes out from TE210 card!
Provider (In-Telegence) says, that there no setup messages in traces with letters come to his end. So, seems that messages just not comes out from TE210 card!
I don’t have the time to follow this further, but it would surprise me if the rejection was coming from the near end. I’d need to research QSIG and the source code to go further.
Have you confirmed with the provider, that their network is actually capable of forwarding digits beyond 0 to 9?
[quote]ollen die Buchstaben ein Routenschutz sein? Wenn ja, probieren Sie es mal mit einem B oder C. Ein F geht nicht, da das F fur “end of sign” steht.
Ein B oder C sollte aber funktionieren.[/quote]
I.e. we must use “B” to send hexD.
But messages with {skip}123B also doesn’t works, and not seen in providers’ trace.
I have tried even
[70 0d 80 {skip} 31 32 33 3b]
Called Number (len=15) [ Ext: 1 TON: Unknown Number Type (0) NPI: Unknown Number Plan (0) ‘{skip}123;’ ]
(note 0x3B as last letter).
Also not works.
And again:
< Cause (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) Spare: 0 Location: User (0)
< Ext: 1 Cause: Invalid number format (28), class = Normal Event (1) ]
Looks like problem found: provider found with message tracer, that messages there – so, seems problem not in digium card.
His switch blocks messages just it have arrived, without logging it at all.
Provider doing test on our port config:) Hope, that will helps.
Don’t close post: i’ll post solution and format of number to send, when get it worked right.