No forwarding of DID to extension - but they are recognized when coming into the pbx

[GRAT]

Dear community,

we are using a beronet gateway to route 5 analog lines into our 3cx system.

So far, everything was working fine until we tried to call through to an extension via DID.

No matter which DID we added to the number: the call always stuck with the default extension that is configured in the Trunk.

What I already tried:

• The DIDs I want to call exist and are associated with an extension.
• The Catch all DID ist the last in the list
• I ran a report about Trunks/DIDs and to my surprise, the calls showed up correctly:

This was before I called the number with the DID attached:


then I called the number with the DID 1620 attached:


So to me it seems that the DID is detected correctly - but it is not routed to the extension (which happens to be also 1620) but to the default number of the trunk.

Thanks in advance for your help - I hope it is just a small adjustment I have to make.

Best regards,

G

edit: we also have two sip trunks in use - both of them have no problems with the same DIDs.

 

[cobaltit]

How to solve Source Identification issues with your VoIP Provider in 3CX

 

[GRAT]

Hello cobaltit and thank you for the link.

This is what the log says:

 >48b8d15300e0/Participant DN.10002/Line dn-name='#### ####' epname='######@(Ln.10002@BeroNet bero*fix BRI (400/1600/6400))'
   did_number=1620
   disp_name=### ###
   number=#########
   sip.contact=<sip:10002@##.##.##.##:5060>
   sip.from="#####"<sip:10002@##.##.##.##:5060>;tag=jeg2UpDmB3BKD
   sip.rl_uri=sip:1620@1##.##.##.##:5060
   sip.src_addr=##.##.##.##:5060
   sip.to=<sip:1620@##.##.##.##:5060>
   sip.user_ag=Berofix VOIP Gateway (16.12)
   target=1111

The ###s contained personal information.

1620 is the DID and extension where the call should go to.

1111 (the target at the end) ist where the call finally ends up.

This is what is configured in the corresponding section in the trunk options:



From what I understand, the line (sip.rl_uri=sip:1620@1##.##.##.##:5060) is correct - there is also no difference when I select To:user part.

Sorry if I did not quite get your clue.

I also tried to make a custom match for the number:



No change with this alteration.

Any help is appreciated,

thanks,

G

 

[cobaltit]

That looks like the log on the beronet or is that from wireshark?.. what does the log in 3CX show?

 

[GRAT]

That is the 3cx log (systemstatus).

Edit: this is, what I find so strange: according to the report that I ran (Screenshots in my second post) the 3cx recognizes the DID 1620, otherwise I do not think it would generate the report correctly. But no matter which DID is called, it always goes back to the default number specified in the trunk.

 

[cobaltit]

Can you put the activity log on verbose and post a snip from there?

 

[GRAT]

This is from the activity log on verbose:

11/28/2020 9:11:25 AM - L:42.1[Line:10002<<#########2] got Terminated Recv Req BYE from ######:5060 tid=t9mK3HNc6v74a Call-ID=fa840762-1d15-1233-0ead-2d31b6a40893:

BYE sip:1620@#####'xxf:5060 SIP/2.0

Via: SIP/2.0/UDP #######;rport=5060;branch=z9hG4bKt9mK3HNc6v74a

Max-Forwards: 70

Contact: <sip:10002@#####$$$$$:5060>

To: <sip:[email protected]#####8:5060>;tag=6be9702b

From: "#######2"<sip:10002@####'xx48:5060>;tag=ca5ecc1v4v9cQ

Call-ID: fa840762-1d15-1233-0ead-2d31b6a40893

CSeq: 70642744 BYE

Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, SUBSCRIBE, NOTIFY, REFER, UPDATE, INFO, REGISTER

Proxy-Authorization: Digest username="###2",realm="3CXPhoneSystem",nonce="414d53595fc2060c01:9ef5f28c2b47bcb419d2efe548ee34cc",algorithm=MD5,uri="sip:1620@####'xxy:5060",response="38aedd28d9c31525a37535446a611023"

Supported: timer, 100rel, replaces

User-Agent: Berofix VOIP Gateway (16.12)

Reason: Q.850;cause=16;text="Normal call clearing"

Content-Length: 0

 

[cobaltit]

That looks like the end of the call. You want to scroll down in the activity log after filtering on the call, hit the 'Load more' button until there's no more to load and grab the first lines like this:

11/28/2020 12:39:38 AM - [CM503001]: Call(C:356): Incoming call from Line:10000<<SRCCIDNUM to <sip:[email protected]:5060>

11/28/2020 12:39:38 AM - Leg L:356.1[Line:10000<<SRCCIDNUM] has external party ID {SRCCIDNUM}

11/28/2020 12:39:38 AM - L:356.1[Line:10000<<SRCCIDNUM]: forced source is used for outbound: 192.168.50.253

11/28/2020 12:39:38 AM - IncomingCall: C:356 from <sip:[email protected]:0/UDP> to <sip:[email protected]:5060/UDP>

11/28/2020 12:39:38 AM - Added leg L:C:356.1[No endpoint yet]

This is the first 5 lines of a call to one of my customers with a PRI gateway (sorry no Beronet devices). In the example above SRCCIDNUM is my office number and DSTDIDNUM was the number I called as passed to 3CX. .254 is 3CX and .253 is the PRI gateway. 8002 is the IVR destination the inbound rule is sending the call to based off the DSTDIDNUM.

11/28/2020 12:39:38 AM - [CM500002]: Call(C:356): Info on incoming INVITE from Line:10000<<SRCCIDNUM:
Invite-IN Recv Req INVITE from 192.168.50.253:5060 tid=7ebf8f28 [email protected]:
INVITE sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.50.253:5060;branch=z9hG4bK7ebf8f28;rport=5060
Max-Forwards: 70
Contact: <sip:[email protected]>
To: <sip:[email protected]:5060>
From: "SRCCIDNAME" <sip:[email protected]>;tag=as5829146c

This is the header for the first invite. Again you see the DSTDIDNUM which is what the inbound rule is matching.

Then a few more lines in you should see something like this:

11/28/2020 12:39:38 AM - [CM503010]: Call(C:356): Making route(s) from Line:10000<<SRCCIDNUM to <sip:[email protected]:5060/UDP>

Which is 3CX saying it found a match and is sending the call to the IVR based off the inbound rule.

 

[GRAT]

Hello,

thank you for your help - with your help I was able to analyze the logs correctly:

The problem is, that the beronet does not hand over the called number to the 3cx completely but just the internal number of the beronet and the added number (=DID).

When I change the DID inbound rule to *1240 everything works fine.

So I can point my 3cx partner to the beronet to fix this issue and in the meanwhile we have a workaround (changing the DID rules to just

Thank you for your help!