Project

General

Profile

Actions

Bug #6306

closed

Caller ID incorrectly formatted when routing a call out over IAX

Added by cquirin 2 months ago. Updated 5 days ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
12/13/2023
Due date:
% Done:

30%


Description

Recent testing has shown that Caller ID is not consistently formatted in international E.164 format and flagged as "international" when a call leaves divf over IAX. Calls from totalisator to CNET 499621. and other prefixes in Germany resulted in Caller ID to be sent out as 0301... instead of 4930...
Yate should have some functionality to do caller id screening and rewriting.

In any case, on CNET, the convention is that calls are sent out in international format, starting with the CC, without any leading zeros, nor a + sign. The use of + is restricted to indicate a PSTN (not CNET) number.

Actions #1

Updated by Billy549 about 1 month ago

It seems this bug is also causing some CNET numbers to reject calls - trying some UK numbers (ex. +44 1283 0816, listed as 'UK Ringing Tone' and +44 244 174 - Chester Faultsman's Ringback) I get "The person you are calling is not accepting anonymous calls. Please redial, without withholding your number". Trying a US ANAC number (+1 349 2622), my number is read as 030 5490 2100, where my UK CNET line I get 44 97......

Actions #2

Updated by laforge about 1 month ago

  • Status changed from New to In Progress

so what I'm seeing in the log is:

2024-01-10_16:36:22.796437 <sig/6:CALL> Incoming call from=03054902100 to=00420548123509 trunk=billy549 sigcall=0x7f1774003190 [0x7f1748002460]
ECHO PREROUTE in_line= id=sig/6 peerid= overlapped=false user= vars=id,module,status,address,billid,answered,direction,caller,called,callername,format,callernumtype,callernumplan,callerpres,callerscreening,callednumtype,callednumplan,overlapped,transfer-cap,handlers
2024-01-10_16:36:22.798112 <INFO> Classifying caller '03054902100' in context 'aucm2_ctx' in 1265 usec
2024-01-10_16:36:22.798484 <RegexRoute:ALL> Including context 'caller_to_national' by rule #1 '.*'
ECHO TO_NAT_BEGIN id=sig/6 caller=03054902100/unknown/unknown
ECHO TO_NAT_END id=sig/6 caller=03054902100/unknown/unknown
ECHO AUCM2 in_line= id=sig/6 overlapped=false called=00420548123509/unknown/unknown calling=// transfer-cap=speech vars=id,module,status,address,billid,answered,direction,caller,called,callername,format,callernumtype,callernumplan,callerpres,callerscreening,callednumtype,callednumplan,overlapped,transfer-cap,context,handlers
2024-01-10_16:36:22.799783 <RegexRoute:ALL> Including context 'convert_called' by rule #16 '.*'
ECHO CONVERT_CALLED id=sig/6 called=00420548123509/unknown/unknown
ECHO CONVERT_CALLED_END id=sig/6 called=00420548123509/unknown/unknown
2024-01-10_16:36:22.800427 <RegexRoute:ALL> Setting match string '00420548123509' by rule #18 '.*' in context 'aucm2_ctx'
2024-01-10_16:36:22.800560 <INFO> Could not route call to '00420548123509' in context 'aucm2_ctx', wasted 2101 usec
2024-01-10_16:36:22.801657 <enumroute:INFO> Returned 1 NAPTR records in 0.000993 s
2024-01-10_16:36:22.803598 <iaxengine:ALL> Outgoing Call: username=cnetguest host=90.182.167.229:0 called=420548123509 called context=(null) [0x55fde11e4a30]
2024-01-10_16:36:22.803816 <iaxengine:ALL> Transaction outgoing call=769 type=New remote=90.182.167.229:4569 [0x7f173c015a40]
2024-01-10_16:36:22.803996 <iax/2:ALL> Outgoing call. Transaction (0x7f173c015a40) callno=769 [0x7f173c0162b0]
2024-01-10_16:36:22.804152 <iaxengine:ALL> Transaction(769) starting [0x7f173c015a40]
2024-01-10_16:36:22.804417 <iaxengine:ALL> Transaction(769,0) posting Frame(6,1) oseq=0 iseq=0 stamp=2 [0x7f173c015a40]
2024-01-10_16:36:22.804473 <iaxengine:INFO> Sending frame [0x55fde11e4a30]^M
-----^M
IAX (0x06) - NEW (0x00000001)^M
  Outgoing to 90.182.167.229:4569 (Local address: 213.95.46.30:4569)^M
  Call (Local:Remote): 769:0. Timestamp: 2. Retrans: false. Sequence numbers: Out: 0 In: 0^M
  VERSION: 0x0002^M
  USERNAME: cnetguest^M
  CALLING_NUMBER: 03054902100^M
  CALLINGTON: 0x00 (unknown)^M
  CALLINGPRES: 0x01 (allowed,user-provided-passed)^M
  CALLINGTNS: 0x0000^M
  CALLED_NUMBER: 420548123509^M
  FORMAT: 0x00000008 (G.711 a-law)^M
  CAPABILITY: 0x0000000c (G.711 mu-law,G.711 a-law)^M
  CODEC_PREFS: ^M
  CALLTOKEN: ^M
-----

which indeed confirms that the CALLING_NUMBER is 03054902100 with unknown type-of-number. That's odd.

Actions #3

Updated by laforge about 1 month ago

the key question is why is the ton/npi 'unknown/unknown' for the incoming call from billy.

If I make a call from my ISDN phone it looks like this:

2024-01-10_22:33:07.002074 <RegexRoute:ALL> Including context 'caller_to_national' by rule #1 '.*'
ECHO TO_NAT_BEGIN id=sig/136 caller=3012342111/isdn/national
ECHO TO_NAT_END id=sig/136 caller=3012342111/isdn/national
ECHO AUCM2 in_line= id=sig/136 overlapped=no called=00420548123509// calling=// transfer-cap=3.1khz-audio vars=id,module,status,address,billid,answered,direction,caller,called,callername,format,callernumtype,call
ernumplan,callerpres,callerscreening,callednumtype,callednumplan,overlapped,transfer-cap,context,accept_call,callto,handlers,targetid
2024-01-10_22:33:07.002631 <RegexRoute:ALL> Including context 'convert_called' by rule #16 '.*'
ECHO CONVERT_CALLED id=sig/136 called=00420548123509//
2024-01-10_22:33:07.003278 <RegexRoute:ALL> Returning false from context 'convert_called'
ECHO CONVERT_CALLED_END id=sig/136 called=420548123509/isdn/international
2024-01-10_22:33:07.003552 <RegexRoute:ALL> Setting match string '420548123509' by rule #18 '.*' in context 'aucm2_ctx'
2024-01-10_22:33:07.003742 <RegexRoute:ALL> Jumping to context 'intl_outbound' by rule #19 '${callednumtype}^international$'
2024-01-10_22:33:07.003782 <RegexRoute:ALL> Including context 'caller_to_intl' by rule #1 '.*'
ECHO TO_INT_BEGIN id=sig/136 caller=3012342111/isdn/national
ECHO TO_INT_END id=sig/136 caller=493012342111/isdn/international
2024-01-10_22:33:07.003989 <INFO> Routing call to '420548123509' in context 'aucm2_ctx' via 'sig/420548123509.' in 1935 usec

so as we can see, the caller is already isnd/national, and the called number has 'empty' ton/npi, which then gets converted to the expected isdn/international, and from there it gets routed properly.

Actions #4

Updated by laforge about 1 month ago

I don't really know why billy's call use ton/npi unknwn vs. my calls empty. I've changed the routing configuration to treat both the same way. This should make the number conversion work as expected.

As for the CNET: I'm also getting the "not accepting anonymous calls" despite sending the following:

IAX (0x06) - NEW (0x00000001)
  Outgoing to 81.174.170.48:4569 (Local address: 213.95.46.30:4569)
  Call (Local:Remote): 771:0. Timestamp: 2. Retrans: true. Sequence numbers: Out: 0 In: 0
  VERSION: 0x0002
  USERNAME: cnetguest
  CALLING_NUMBER: 493012342111
  CALLINGTON: 0x10 (international)
  CALLINGPRES: 0x00 (allowed,user-provided)
  CALLINGTNS: 0x0000
  CALLED_NUMBER: 4412830816
  FORMAT: 0x00000008 (G.711 a-law)
  CAPABILITY: 0x0000000c (G.711 mu-law,G.711 a-law)
  CODEC_PREFS:
  CALLTOKEN: 31 37 30 34 39 32 32 39 36 36 3f 34 32 36 66 34 61 65 37 34 30 39 65 64 34 33 30 66 61 62 30 34 62 35 30 66 61 62 34 65 34 34 37 35 32 32 62 38 65 34 32

So as you can see it is the international number.

Regarding @cquirin's comment - I'm not even sure IAX2 would permit the inclusion of non-decimal digits in messages.

Actions #5

Updated by laforge about 1 month ago

  • % Done changed from 0 to 30

Even if I change the callington to 'unknown' instead of 'international', I'm still getting the "the person you'r calling does not accept anonymous calls". I guess it's a misconfiguration at the recipients end:

IAX (0x06) - NEW (0x00000001)
  Outgoing to 81.174.170.48:4569 (Local address: 213.95.46.30:4569)
  Call (Local:Remote): 773:0. Timestamp: 1. Retrans: true. Sequence numbers: Out: 0 In: 0
  VERSION: 0x0002
  USERNAME: cnetguest
  CALLING_NUMBER: 493012342111
  CALLINGTON: 0x00 (unknown)
  CALLINGPRES: 0x00 (allowed,user-provided)
  CALLINGTNS: 0x0000
  CALLED_NUMBER: 4412830816
  FORMAT: 0x00000008 (G.711 a-law)
  CAPABILITY: 0x0000000c (G.711 mu-law,G.711 a-law)
  CODEC_PREFS:
  CALLTOKEN: 31 37 30 34 39 32 33 34 30 34 3f 63 66 38 62 63 32 39 38 37 35 37 31 37 35 37 61 63 32 39 32 33 39 63 61 33 61 31 64 65 39 30 35 37 61 35 64 30 62 62 38

cquirin do you have any hints? Should the CALLINGPRES or CALLINGTNS be set differently? Those names should match 1:1 the IAX2 protocol field names.

Actions #6

Updated by laforge about 1 month ago

Billy549 wrote in #note-1:

Trying a US ANAC number (+1 349 2622), my number is read as 030 5490 2100, where my UK CNET line I get 44 97......

this works for me correctly (as expected: 4930....) - it should now hopefully also for you (since I changed the 'unknown/unknown' ton/npi translation as mentioned above

Actions #7

Updated by laforge about 1 month ago

  • Status changed from In Progress to Feedback
  • Assignee changed from laforge to Billy549
Actions #8

Updated by cquirin about 1 month ago

laforge wrote in #note-5:

Even if I change the callington to 'unknown' instead of 'international', I'm still getting the "the person you'r calling does not accept anonymous calls". I guess it's a misconfiguration at the recipients end:
[...]

cquirin do you have any hints? Should the CALLINGPRES or CALLINGTNS be set differently? Those names should match 1:1 the IAX2 protocol field names.

IAX allows for all ASCII characters to be used in number and name fields. On CNET callingpres must be set to allowed, screened or not. Callingtns does not matter for all CNET nodes I have seen so far. Some UK nodes accept calls only from UK numbers. There might be a bug on these nodes there. My CNET number 49 9621 708 allows calls from everywhere, even without caller id, and reads out the caller id (or indicates that there is no caller id available).

Actions #9

Updated by Billy549 about 1 month ago

Calling the US ANAC number, my CLID is still being read as 030... and not 4930... (and am still getting the "does not accept anonymous calls") - if your number is now correctly showing as +49 30..., you could try Peter Clark's FIP stream at +33 2280 4463, which I'm unable to access but is a different host to the UK numbers that fail for me.

I can likely email the person in charge of the numbers I mentioned and ask them to see what the config issue is on their side, but that of course doesn't fix all numbers - hopefully, a lot of them though!

Actions #10

Updated by Billy549 about 1 month ago

As requested in IRC, I made two phone calls - the first to a CNET number at 11:00 UTC (12:00) CET:

-----
2024-01-11_12:00:01.375420 <billy549/Q931:ALL> Call(0,1) direction=incoming TEI=0 [0x7fac04003f50]
2024-01-11_12:00:01.375557 <billy549/Q931:ALL> Call(0,1). State 'Null' --> 'CallPresent' [0x7fac04003f50]
2024-01-11_12:00:01.375725 <billy549/Q931:NOTE> Any Circuit
2024-01-11_12:00:01.375737 <billy549/Q931:NOTE> Now actually reserving
2024-01-11_12:00:01.375837 <billy549/B:ALL> ZapCircuit(1). IOCTL(SetLinear) failed on channel 1117 (param=0). 22: Invalid argument [0x56526cbbc6f0]
2024-01-11_12:00:01.375849 <billy549/B:ALL> ZapCircuit(1). IOCTL(SetToneDetect) failed on channel 1117 (param=0). 25: Inappropriate ioctl for device [0x56526cbbc6f0]
2024-01-11_12:00:01.375907 <billy549/Q931:ALL> Call(0,1). Connected to circuit 1 in 0 ms [0x7fac04003f50]
2024-01-11_12:00:01.375966 <sig/92:CALL> Incoming call from=03054902100 to=00612474998 trunk=billy549 sigcall=0x7fac04003f50 [0x7fabfc006020]
ECHO PREROUTE in_line= id=sig/92 peerid= overlapped=false user= vars=id,module,status,address,billid,answered,direction,caller,called,callername,format,callernumtype,callernumplan,callerpres,callerscreening,callednumtype,callednumplan,overlapped,transfer-cap,handlers
2024-01-11_12:00:01.377684 <INFO> Classifying caller '03054902100' in context 'aucm2_ctx' in 1346 usec
2024-01-11_12:00:01.378123 <RegexRoute:ALL> Including context 'caller_to_national' by rule #1 '.*'
ECHO TO_NAT_BEGIN id=sig/92 caller=03054902100/unknown/unknown
ECHO TO_NAT_END id=sig/92 caller=03054902100/unknown/unknown
ECHO AUCM2 in_line= id=sig/92 overlapped=false called=00612474998/unknown/unknown calling=// transfer-cap=speech vars=id,module,status,address,billid,answered,direction,caller,called,callername,format,callernumtype,callernumplan,callerpres,callerscreening,callednumtype,callednumplan,overlapped,transfer-cap,context,handlers
2024-01-11_12:00:01.378814 <RegexRoute:ALL> Including context 'convert_called' by rule #16 '.*'
ECHO CONVERT_CALLED id=sig/92 called=00612474998/unknown/unknown
2024-01-11_12:00:01.379457 <RegexRoute:ALL> Returning false from context 'convert_called'
ECHO CONVERT_CALLED_END id=sig/92 called=612474998/isdn/international
2024-01-11_12:00:01.379609 <RegexRoute:ALL> Setting match string '612474998' by rule #18 '.*' in context 'aucm2_ctx'
2024-01-11_12:00:01.379726 <RegexRoute:ALL> Jumping to context 'intl_outbound' by rule #19 '${callednumtype}^international$'
2024-01-11_12:00:01.379764 <RegexRoute:ALL> Including context 'caller_to_intl' by rule #1 '.*'
ECHO TO_INT_BEGIN id=sig/92 caller=03054902100/unknown/unknown
ECHO TO_INT_END id=sig/92 caller=03054902100/unknown/unknown
2024-01-11_12:00:01.379944 <RegexRoute:ALL> Returning false from context 'intl_outbound'
2024-01-11_12:00:01.379984 <INFO> Could not route call to '612474998' in context 'aucm2_ctx', wasted 1951 usec
2024-01-11_12:00:01.440430 <enumroute:INFO> Returned 1 NAPTR records in 0.060345 s
2024-01-11_12:00:01.463803 <iaxengine:ALL> Outgoing Call: username=cnetguest host=13.210.143.9:0 called=612474998 called context=(null) [0x56526c9fd920]
2024-01-11_12:00:01.463936 <iaxengine:ALL> Transaction outgoing call=31460 type=New remote=13.210.143.9:4569 [0x7fabdc013350]
2024-01-11_12:00:01.463977 <iax/48:ALL> Outgoing call. Transaction (0x7fabdc013350) callno=31460 [0x7fabdc014b00]
2024-01-11_12:00:01.464095 <iaxengine:ALL> Transaction(31460) starting [0x7fabdc013350]
2024-01-11_12:00:01.464116 <iaxengine:ALL> Transaction(31460,0) posting Frame(6,1) oseq=0 iseq=0 stamp=2 [0x7fabdc013350]
2024-01-11_12:00:01.464215 <iaxengine:INFO> Sending frame [0x56526c9fd920]
-----
IAX (0x06) - NEW (0x00000001)
  Outgoing to 13.210.143.9:4569 (Local address: 213.95.46.30:4569)
  Call (Local:Remote): 31460:0. Timestamp: 2. Retrans: false. Sequence numbers: Out: 0 In: 0
  VERSION: 0x0002
  USERNAME: cnetguest
  CALLING_NUMBER: 03054902100
  CALLINGTON: 0x00 (unknown)
  CALLINGPRES: 0x01 (allowed,user-provided-passed)
  CALLINGTNS: 0x0000
  CALLED_NUMBER: 612474998
  FORMAT: 0x00000008 (G.711 a-law)
  CAPABILITY: 0x0000000c (G.711 mu-law,G.711 a-law)
  CODEC_PREFS: 
  CALLTOKEN: 
-----
2024-01-11_12:00:01.464545 <iaxengine:ALL> Transaction(31460,0) state changed Unknown --> NewLocalInvite [0x7fabdc013350]
2024-01-11_12:00:01.464681 <billy549/Q931:ALL> Call(0,1). State 'CallPresent' --> 'IncomingProceeding' [0x7fac04003f50]
2024-01-11_12:00:01.464834 <billy549/Q931:INFO> Sending message (0x7fabdc016f40)
-----
CALL PROCEEDING
  [From initiator=false CallRef=1]
  Channel identification
-----
2024-01-11_12:00:01.739981 <iaxengine:INFO> Received frame [0x56526c9fd920]
-----
IAX (0x06) - CALLTOKEN (0x00000028)
  Incoming from 13.210.143.9:4569 (Local address: 213.95.46.30:4569)
  Call (Local:Remote): 31460:1. Timestamp: 2. Retrans: false. Sequence numbers: Out: 0 In: 1
  CALLTOKEN: 31 37 30 34 39 37 30 38 30 31 3f 36 37 64 35 33 31 38 66 36 33 37 36 39 62 34 64 30 32 30 32 64 66 32 33 34 37 66 35 66 35 61 30 38 33 62 32 33 66 63 37
-----
2024-01-11_12:00:01.740178 <iaxengine:INFO> Sending frame [0x56526c9fd920]
-----
IAX (0x06) - NEW (0x00000001)
  Outgoing to 13.210.143.9:4569 (Local address: 213.95.46.30:4569)
  Call (Local:Remote): 31460:0. Timestamp: 2. Retrans: true. Sequence numbers: Out: 0 In: 0
  VERSION: 0x0002
  USERNAME: cnetguest
  CALLING_NUMBER: 03054902100
  CALLINGTON: 0x00 (unknown)
  CALLINGPRES: 0x01 (allowed,user-provided-passed)
  CALLINGTNS: 0x0000
  CALLED_NUMBER: 612474998
  FORMAT: 0x00000008 (G.711 a-law)
  CAPABILITY: 0x0000000c (G.711 mu-law,G.711 a-law)
  CODEC_PREFS: 
  CALLTOKEN: 31 37 30 34 39 37 30 38 30 31 3f 36 37 64 35 33 31 38 66 36 33 37 36 39 62 34 64 30 32 30 32 64 66 32 33 34 37 66 35 66 35 61 30 38 33 62 32 33 66 63 37

The second, a direct OCTOI-OCTOI number (to Manawyrm) at 11:02 UTC (12:02 CET):

2024-01-11_12:02:02.883408 <billy549/Q931:INFO> Received message (0x7fac04001cc0)
-----
SETUP
  [From initiator=true CallRef=2]
  Bearer capability
  Channel identification
  Calling number
  Called number
-----
2024-01-11_12:02:02.883449 <billy549/Q931:ALL> Call(0,2) direction=incoming TEI=0 [0x7fac04003f50]
2024-01-11_12:02:02.886504 <billy549/Q931:ALL> Call(0,2). State 'Null' --> 'CallPresent' [0x7fac04003f50]
2024-01-11_12:02:02.886613 <billy549/Q931:NOTE> Any Circuit
2024-01-11_12:02:02.886620 <billy549/Q931:NOTE> Now actually reserving
2024-01-11_12:02:02.886733 <billy549/B:ALL> ZapCircuit(1). IOCTL(SetLinear) failed on channel 1117 (param=0). 22: Invalid argument [0x56526cbbc6f0]
2024-01-11_12:02:02.886743 <billy549/B:ALL> ZapCircuit(1). IOCTL(SetToneDetect) failed on channel 1117 (param=0). 25: Inappropriate ioctl for device [0x56526cbbc6f0]
2024-01-11_12:02:02.886867 <billy549/Q931:ALL> Call(0,2). Connected to circuit 1 in 0 ms [0x7fac04003f50]
2024-01-11_12:02:02.887124 <sig/93:CALL> Incoming call from=03054902100 to=03065027002 trunk=billy549 sigcall=0x7fac04003f50 [0x7fabfc006020]
ECHO PREROUTE in_line= id=sig/93 peerid= overlapped=false user= vars=id,module,status,address,billid,answered,direction,caller,called,callername,format,callernumtype,callernumplan,callerpres,callerscreening,callednumtype,callednumplan,overlapped,transfer-cap,handlers
2024-01-11_12:02:02.888784 <INFO> Classifying caller '03054902100' in context 'aucm2_ctx' in 774 usec
2024-01-11_12:02:02.888975 <RegexRoute:ALL> Including context 'caller_to_national' by rule #1 '.*'
ECHO TO_NAT_BEGIN id=sig/93 caller=03054902100/unknown/unknown
ECHO TO_NAT_END id=sig/93 caller=03054902100/unknown/unknown
2024-01-11_12:02:02.889189 <RegexRoute:ALL> Setting match string '65027002' by rule #3 '^030\(........\)$' in context 'aucm2_ctx'
2024-01-11_12:02:02.889208 <RegexRoute:ALL> Jumping to context 'berlin' by rule #4 '.*'
2024-01-11_12:02:02.889302 <INFO> Routing call to '65027002' in context 'aucm2_ctx' via 'sig/03065027002' in 339 usec
2024-01-11_12:02:02.889464 <sig/94:ALL> Trying to call on trunk 'manawyrm' [0x7fabdc01c8a0]
2024-01-11_12:02:02.889509 <manawyrm/Q931:ALL> Call(1,1) direction=outgoing TEI=0 [0x7fabdc012020]
2024-01-11_12:02:02.889519 <manawyrm/Q931:NOTE> Any Circuit
2024-01-11_12:02:02.889522 <manawyrm/Q931:NOTE> Now actually reserving
2024-01-11_12:02:02.889589 <manawyrm/B:ALL> ZapCircuit(1). IOCTL(SetLinear) failed on channel 528 (param=0). 22: Invalid argument [0x56526caad7f0]
2024-01-11_12:02:02.889630 <manawyrm/B:ALL> ZapCircuit(1). IOCTL(SetToneDetect) failed on channel 528 (param=0). 25: Inappropriate ioctl for device [0x56526caad7f0]
2024-01-11_12:02:02.889706 <manawyrm/Q931:ALL> Call(1,1). Connected to circuit 1 in 0 ms [0x7fabdc012020]
2024-01-11_12:02:02.889743 <manawyrm/Q931:NOTE> circuit == requested
2024-01-11_12:02:02.889809 <manawyrm/Q931:ALL> Call(1,1). State 'Null' --> 'CallInitiated' [0x7fabdc012020]
2024-01-11_12:02:02.889970 <sig/94:CALL> Outgoing call from=03054902100 to=03065027002 trunk=manawyrm sigcall=0x7fabdc012020 [0x7fabdc01c8a0]
2024-01-11_12:02:02.890047 <billy549/Q931:ALL> Call(0,2). State 'CallPresent' --> 'IncomingProceeding' [0x7fac04003f50]
2024-01-11_12:02:02.890132 <billy549/Q931:INFO> Sending message (0x7fabdc01e2f0)
-----
CALL PROCEEDING
  [From initiator=false CallRef=2]
  Channel identification
-----
2024-01-11_12:02:03.093371 <manawyrm/Q931:NOTE> circuit == requested
2024-01-11_12:02:03.093578 <manawyrm/Q931:ALL> Call(1,1). State 'CallInitiated' --> 'OutgoingProceeding' [0x7fabdc012020]
2024-01-11_12:02:03.093704 <ALL> DataTranslator::attachChain [0x7fabdc0161b0] 'alaw' -> [0x7fac04000b60] 'alaw' succeeded
2024-01-11_12:02:03.094018 <manawyrm/Q931:ALL> Call(1,1). State 'OutgoingProceeding' --> 'ConnectReq' [0x7fabdc012020]
2024-01-11_12:02:03.094152 <manawyrm/Q931:ALL> Call(1,1). State 'ConnectReq' --> 'Active' [0x7fabdc012020]
2024-01-11_12:02:03.094380 <sig/94:CALL> Call answered [0x7fabdc01c8a0]
2024-01-11_12:02:03.094403 <manawyrm/B:NOTE> ZapCircuit(1). Unable to send unknown event 23 [0x56526ca9af30]
2024-01-11_12:02:03.095130 <sig/93:CALL> Call answered [0x7fabfc006020]
2024-01-11_12:02:03.095312 <ALL> DataTranslator::attachChain [0x7fabdc004300] 'alaw' -> [0x7fabdc016f40] 'alaw' succeeded
2024-01-11_12:02:03.095367 <billy549/B:NOTE> ZapCircuit(1). Unable to send unknown event 23 [0x56526cbe4ae0]
2024-01-11_12:02:03.095454 <billy549/Q931:ALL> Call(0,2). State 'IncomingProceeding' --> 'CallPresent' [0x7fac04003f50]
2024-01-11_12:02:03.095680 <billy549/Q931:ALL> Call(0,2). State 'CallPresent' --> 'Active' [0x7fac04003f50]
2024-01-11_12:02:03.095998 <billy549/Q931:INFO> Sending message (0x7fac2c01f890)
-----
CONNECT
  [From initiator=false CallRef=2]
-----
2024-01-11_12:02:03.307356 <billy549/Q931:INFO> Received message (0x7fac04002f50)
-----
CONNECT ACK
  [From initiator=true CallRef=2]
-----

Actions #11

Updated by Billy549 about 1 month ago

I'd also like to add it seems Caller ID Name is being stripped too - manually setting my caller ID name in Asterisk and caller ID to +49 30 5490 2100 and then calling +44272624000 I still get the anonymous calls message.

Discussing this with the owner of that number (lpbkdotnet_14855):

lpbkdotnet — Today at 15:36
Rejected: (Invalid CLI) from CNet to 44272624000 from "" <03054902100> 213.95.46.30 I'll check what it classes as invalid, but I suspect it's just because the name is blank
Billy — Today at 15:36
Ah, I wonder if that's the issue we're having at OCTOI - I know when changing it to 4930... the CLID is updated but we're still rejected
Lack of CNAME would explain it though, if that's what it is please do let me know
lpbkdotnet — Today at 15:38
ahh. it's because it starts with a 0 and cnet expects numbers to start with a country code
the blank name will also be rejected, but with a "no anonymous calls" message
Billy — Today at 15:38
the blank name will also be rejected, but with a "no anonymous calls" message
that's exactly the error we've been getting! ty
Billy — Today at 15:40
we're still unsure why my number is coming through incorrectly via OCTOI but I can at least fix that manually on my side (temporarily), but the name thing makes perfect sense
Do you have a link to the standard CNET rules or smth that would explain that?
[just as proof so im not blindly telling changes]
lpbkdotnet — Today at 15:43
cnet isn't quite organised enough to have published that publicly in detail. There were a number of draft standards documents that circulated on the mailing lists, but I think the only place they exist is in peoples inboxes.  My validation rules are based on what ian sent me about 15 years ago or something
I can share that code with you though, I think it's pretty standard, certainly across the non-usa side of cnet
https://gist.github.com/paulseward/c4c6ab990c1a5da72418cb14a999d7ab

Actions #12

Updated by cquirin about 1 month ago

Billy549 wrote in #note-11:

I'd also like to add it seems Caller ID Name is being stripped too - manually setting my caller ID name in Asterisk and caller ID to +49 30 5490 2100 and then calling +44272624000 I still get the anonymous calls message.

Discussing this with the owner of that number (lpbkdotnet_14855):
[...]

Not all type of ISDN equipment does support transmission of Caller ID name.

I would recommend that we organize a testing campaign where all involved parties have their CLIs and debug logs open to clearly see what is happening.

Actions #13

Updated by laforge about 1 month ago

Billy549 wrote in #note-10:

As requested in IRC, I made two phone calls - the first to a CNET number at 11:00 UTC (12:00) CET:
[...]

The main difference seems again to be your unexpected representation of type-of-number and numbering-plan-indicator.

From you:

ECHO TO_NAT_BEGIN id=sig/92 caller=03054902100/unknown/unknown

From those of us using a German ISDN PBX, the calling party is identified as follows:

ECHO TO_NAT_BEGIN id=sig/136 caller=03012342111/isdn/subscriber

and that gets converted to

ECHO TO_NAT_END id=sig/136 caller=3012342111/isdn/national

For you, that doesn't happen as it's an unknown type. And everything from there on is just a follow-up error. The dialplan tries to convert the numbers at each step, but it doens't know how to interpret something that doesn't even claim it's an ISDN number, but an unknown number.

Actions #14

Updated by laforge about 1 month ago

I would still encourage you to try to configure your local [softs]switch better so it actually uses numbers in the isdn/E.164 numbering plan, and ideally also a subscriber number or a national or international, depending on which format you use.

I've meanwhile added a workaround. if your caller-id starts with 030 and is of type unknown, then it gets rewritten.

ECHO TO_NAT_BEGIN id=sig/127 caller=03054902103/unknown/unknown
ECHO TO_NAT_END id=sig/127 caller=3054902103/isdn/national
Actions #15

Updated by laforge about 1 month ago

Billy549 wrote in #note-11:

the blank name will also be rejected, but with a "no anonymous calls" message

The question now is: what should be the caller 'name'? I never read anywhere some kind of specification/documentation that it must be set, and to what it shall be set.

I've now set it to "OCTOI-${caller}" so the IAX NEW message looks like this;

-----
IAX (0x06) - NEW (0x00000001)
  Outgoing to 208.87.98.247:4569 (Local address: 213.95.46.30:4569)
  Call (Local:Remote): 20888:0. Timestamp: 1. Retrans: false. Sequence numbers: Out: 0 In: 0
  VERSION: 0x0002
  USERNAME: cnetguest
  CALLING_NUMBER: 493012342111
  CALLINGTON: 0x10 (international)
  CALLINGPRES: 0x00 (allowed,user-provided)
  CALLINGTNS: 0x0000
  CALLING_NAME: OCTOI-493012342111
  CALLED_NUMBER: 4416478000
  FORMAT: 0x00000008 (G.711 a-law)
  CAPABILITY: 0x0000000c (G.711 mu-law,G.711 a-law)
  CODEC_PREFS: 
  CALLTOKEN: 
-----

I guess this solves the puzzle?

Actions #16

Updated by Billy549 about 1 month ago

I will investigate my Asterisk plan and correct it where possible - thank you for the workaround.

I can confirm now that calling the numbers that previously rejected me due to being an "anonymous caller" now accept my calls - many thanks!

Actions #17

Updated by laforge about 1 month ago

cquirin wrote in #note-12:

I would recommend that we organize a testing campaign where all involved parties have their CLIs and debug logs open to clearly see what is happening.

Yes, that would be useful. In general I would love to go even one step further: have automatic test cases, like some piece of "dialer" code that attaches to DAHDI on the divf (like any of our subscribers) and then ends Q.931 call setup with all kinds of differnt caller/called numbers/ number types. This way it would be easy to trigger various possibilities in terms of TON, NPI, overlap or not, etc. and watch the logs.

Actions #18

Updated by Billy549 18 days ago

So, I looked and had figured out why my number was not correctly set - this was definitely a PEBCAK error. In /etc/asterisk/chan_dahdi.conf, I had

pridialplan=unknown
prilocaldialplan=unknown

I changed this to

pridialplan=international
prilocaldialplan=national
callerid = asreceived

(Adding caller ID as received to ensure it is set properly). This also fixed an issue where my number was showing as "305490..." instead of 030. However, I now cannot route out to C*NET - with my settings incorrectly set as unknown/unknown, I can call out to C*NET (and receive calls) just fine. NB: My CID is being incorrectly set as "49*0*3054902100" in the example shown, which is causing an ENUM lookup to fail.

2024-02-03_15:39:06.318201 <billy549/Q931:INFO> Received message (0x7f564c002900)
-----
SETUP
  [From initiator=true CallRef=4]
  Bearer capability
  Channel identification
  Calling number
  Called number
-----
2024-02-03_15:39:06.318247 <billy549/Q931:ALL> Call(0,4) direction=incoming TEI=0 [0x7f564c004100]
2024-02-03_15:39:06.318599 <billy549/Q931:ALL> Call(0,4). State 'Null' --> 'CallPresent' [0x7f564c004100]
2024-02-03_15:39:06.318716 <billy549/Q931:NOTE> Any Circuit
2024-02-03_15:39:06.318720 <billy549/Q931:NOTE> Now actually reserving
2024-02-03_15:39:06.318872 <billy549/B:ALL> ZapCircuit(1). IOCTL(SetLinear) failed on channel 1117 (param=0). 22: Invalid argument [0x55b7e754b6a0]
2024-02-03_15:39:06.318882 <billy549/B:ALL> ZapCircuit(1). IOCTL(SetToneDetect) failed on channel 1117 (param=0). 25: Inappropriate ioctl for device [0x55b7e754b6a0]
2024-02-03_15:39:06.319019 <billy549/Q931:ALL> Call(0,4). Connected to circuit 1 in 1 ms [0x7f564c004100]
2024-02-03_15:39:06.319244 <sig/89:CALL> Incoming call from=03054902100 to=0044244174 trunk=billy549 sigcall=0x7f564c004100 [0x7f5608006350]
ECHO PREROUTE in_line= id=sig/89 peerid= overlapped=false user= vars=id,module,status,address,billid,answered,direction,caller,called,callername,format,callernumtype,callernumplan,callerpres,callerscreening,callednumtype,callednumplan,overlapped,transfer-cap,handlers
2024-02-03_15:39:06.320604 <INFO> Classifying caller '03054902100' in context 'aucm2_ctx' in 779 usec
2024-02-03_15:39:06.320965 <RegexRoute:ALL> Including context 'caller_to_national' by rule #1 '.*'
ECHO TO_NAT_BEGIN id=sig/89 caller=03054902100/unknown/unknown
ECHO TO_NAT_END id=sig/89 caller=3054902100/isdn/national
ECHO AUCM2 in_line= id=sig/89 overlapped=false called=0044244174/unknown/unknown calling=// transfer-cap=3.1khz-audio vars=id,module,status,address,billid,answered,direction,caller,called,callername,format,callernumtype,callernumplan,callerpres,callerscreening,callednumtype,callednumplan,overlapped,transfer-cap,context,handlers
2024-02-03_15:39:06.321922 <RegexRoute:ALL> Including context 'convert_called' by rule #16 '.*'
ECHO CONVERT_CALLED id=sig/89 called=0044244174/unknown/unknown
2024-02-03_15:39:06.322406 <RegexRoute:ALL> Returning false from context 'convert_called'
ECHO CONVERT_CALLED_END id=sig/89 called=44244174/isdn/international
2024-02-03_15:39:06.322542 <RegexRoute:ALL> Setting match string '44244174' by rule #18 '.*' in context 'aucm2_ctx'
2024-02-03_15:39:06.322563 <RegexRoute:ALL> Jumping to context 'intl_outbound' by rule #19 '${callednumtype}^international$'
2024-02-03_15:39:06.322605 <RegexRoute:ALL> Including context 'caller_to_intl' by rule #1 '.*'
ECHO TO_INT_BEGIN id=sig/89 caller=3054902100/isdn/national
ECHO TO_INT_END id=sig/89 caller=493054902100/isdn/international
2024-02-03_15:39:06.323273 <RegexRoute:ALL> Returning false from context 'intl_outbound'
2024-02-03_15:39:06.323318 <INFO> Could not route call to '44244174' in context 'aucm2_ctx', wasted 2385 usec
2024-02-03_15:39:06.324777 <enumroute:INFO> Returned 1 NAPTR records in 0.001046 s
2024-02-03_15:39:06.325260 <iaxengine:ALL> Outgoing Call: username=cnetguest host=81.174.170.48:0 called=44244174 called context=(null) [0x55b7e7372a20]
2024-02-03_15:39:06.325317 <iaxengine:ALL> Transaction outgoing call=31745 type=New remote=81.174.170.48:4569 [0x7f5608015940]
2024-02-03_15:39:06.325330 <iax/5:ALL> Outgoing call. Transaction (0x7f5608015940) callno=31745 [0x7f560800d5f0]
2024-02-03_15:39:06.325398 <iaxengine:ALL> Transaction(31745) starting [0x7f5608015940]
2024-02-03_15:39:06.325479 <iaxengine:ALL> Transaction(31745,0) posting Frame(6,1) oseq=0 iseq=0 stamp=1 [0x7f5608015940]
2024-02-03_15:39:06.325516 <iaxengine:INFO> Sending frame [0x55b7e7372a20]
-----
IAX (0x06) - NEW (0x00000001)

However, with it set correctly as shown above, I get a no route error:

-----
SETUP
  [From initiator=true CallRef=1]
  Bearer capability
  Channel identification
  Calling number
  Called number
-----
2024-02-03_15:42:05.957359 <billy549/Q931:ALL> Call(0,1) direction=incoming TEI=0 [0x7f564c004350]
2024-02-03_15:42:05.959010 <billy549/Q931:ALL> Call(0,1). State 'Null' --> 'CallPresent' [0x7f564c004350]
2024-02-03_15:42:05.959092 <billy549/Q931:NOTE> Any Circuit
2024-02-03_15:42:05.959096 <billy549/Q931:NOTE> Now actually reserving
2024-02-03_15:42:05.959299 <billy549/B:ALL> ZapCircuit(1). IOCTL(SetLinear) failed on channel 1117 (param=0). 22: Invalid argument [0x55b7e754b6a0]
2024-02-03_15:42:05.959307 <billy549/B:ALL> ZapCircuit(1). IOCTL(SetToneDetect) failed on channel 1117 (param=0). 25: Inappropriate ioctl for device [0x55b7e754b6a0]
2024-02-03_15:42:05.959486 <billy549/Q931:ALL> Call(0,1). Connected to circuit 1 in 0 ms [0x7f564c004350]
2024-02-03_15:42:05.959697 <sig/96:CALL> Incoming call from=03054902100 to=0044244174 trunk=billy549 sigcall=0x7f564c004350 [0x7f5620009480]
ECHO PREROUTE in_line= id=sig/96 peerid= overlapped=false user= vars=id,module,status,address,billid,answered,direction,caller,called,callername,format,callernumtype,callernumplan,callerpres,callerscreening,callednumtype,callednumplan,overlapped,transfer-cap,handlers
2024-02-03_15:42:05.962110 <INFO> Classifying caller '03054902100' in context 'aucm2_ctx' in 1910 usec
2024-02-03_15:42:05.963042 <RegexRoute:ALL> Including context 'caller_to_national' by rule #1 '.*'
ECHO TO_NAT_BEGIN id=sig/96 caller=03054902100/isdn/national
ECHO TO_NAT_END id=sig/96 caller=03054902100/isdn/national
ECHO AUCM2 in_line= id=sig/96 overlapped=false called=0044244174/international/isdn calling=// transfer-cap=3.1khz-audio vars=id,module,status,address,billid,answered,direction,caller,called,callername,format,callernumtype,callernumplan,callerpres,callerscreening,callednumtype,callednumplan,overlapped,transfer-cap,context,handlers
2024-02-03_15:42:05.964623 <RegexRoute:ALL> Including context 'convert_called' by rule #16 '.*'
ECHO CONVERT_CALLED id=sig/96 called=0044244174/isdn/international
2024-02-03_15:42:05.965175 <RegexRoute:ALL> Returning false from context 'convert_called'
ECHO CONVERT_CALLED_END id=sig/96 called=0044244174/isdn/international
2024-02-03_15:42:05.965569 <RegexRoute:ALL> Setting match string '0044244174' by rule #18 '.*' in context 'aucm2_ctx'
2024-02-03_15:42:05.965794 <RegexRoute:ALL> Jumping to context 'intl_outbound' by rule #19 '${callednumtype}^international$'
2024-02-03_15:42:05.965833 <RegexRoute:ALL> Including context 'caller_to_intl' by rule #1 '.*'
ECHO TO_INT_BEGIN id=sig/96 caller=03054902100/isdn/national
ECHO TO_INT_END id=sig/96 caller=4903054902100/isdn/international
2024-02-03_15:42:05.966401 <RegexRoute:ALL> Returning false from context 'intl_outbound'
2024-02-03_15:42:05.966495 <INFO> Could not route call to '0044244174' in context 'aucm2_ctx', wasted 3595 usec
2024-02-03_15:42:05.995055 <enumroute:INFO> Returned 0 NAPTR records in 0.028402 s
2024-02-03_15:42:05.995284 <sig/96:CALL> Call hangup. Reason: 'noroute' [0x7f5620009480]
2024-02-03_15:42:05.995418 <billy549/Q931:ALL> Call(0,1). State 'CallPresent' --> 'DisconnectReq' [0x7f564c004350]
2024-02-03_15:42:05.995616 <billy549/Q931:INFO> Sending message (0x7f56080148a0)
-----
DISCONNECT
  [From initiator=false CallRef=1]
  Cause
-----
2024-02-03_15:42:05.995789 <sig/96:CALL> Call destroyed. Reason: 'noroute'. No signalling call  [0x7f5620009480]
2024-02-03_15:42:06.181253 <billy549/Q931:INFO> Received message (0x7f564c0048d0)
-----
RELEASE
  [From initiator=true CallRef=1]
  Cause
-----
2024-02-03_15:42:06.182469 <billy549/Q931:ALL> Call(0,1). State 'DisconnectReq' --> 'ReleaseReq' [0x7f564c004350]
2024-02-03_15:42:06.182483 <billy549/Q931:ALL> Call(0,1). State 'ReleaseReq' --> 'Null' [0x7f564c004350]
2024-02-03_15:42:06.182980 <billy549/Q931:INFO> Sending message (0x7f564c001490)
-----
RELEASE COMPLETE

Actions #19

Updated by laforge 9 days ago

Regarding the case with international numbers: In this case, there are no leading zeroes.

So if you are using an international number, it must be 44244174 and not 0044244174

Likweise, if you are using a national number, it must be something like 3012343038 and not 03012343038

This is, as far as I can tell, how it used to work (and in some cases still works) in the public ISDN/SS7 networks.

Actions #20

Updated by laforge 9 days ago

I've added some general explanation to Type_Of_Number_and_Numbering_Plan_Indicator

Actions #21

Updated by laforge 5 days ago

  • Status changed from Feedback to Resolved

I'm marking this as resolved. Feel free to re-open if some actual bugs are observed [again]. AFAICT it does what it's supposed to do these days.

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)