Wrong endpoint identified on standalone installs with single IP address #1959

devserge · 2022-12-05T15:04:12Z

Description

When trying to make an outbound call (either external or internal) the calls wont't be placed.
When opening up the asterisk log, it returns the following AGI error:
AGI ERROR ["PJSIP/proxytrunks-000001a1", "DDI (the ddi, either the extension number or +31 number) not found in database.")

We tried everything, but nothing seems to change the error.
It looks like it always tries to look up the specific DID up in an database, either if it is for an internal or external call.
We tried setting up different outgound routings, routing plans and more.
Are we missing something or is this a bug?

IvozProvider version: 3.0
Related sections:
- SIP & Telephony

devserge · 2022-12-08T09:20:51Z

Hey,

I am wondering if there is any update in this case?
Should I replace this question to the community on Google?

Or is it an issue in the portal itself?
We tried everything, but this Asterisk error is just now known by me.

Thanks for an reply in advance

Kaian · 2022-12-12T10:06:40Z

Hi @devserge

Sorry for the delay, we have been on holidays these days.

We haven't experienced this problem, it may be some configuration error. We may need more information. Is this a vPBX outbound call from a User or a Friend?

Be sure you have configured an Outbound DDI on the User, Friend or Company that is placing the call, it will be used as presentation in P-Asserted-Identity header.

Regards

MichaelSTK · 2022-12-13T15:08:36Z

Hi

Incoming calls are fine

We have linked several DDI to a vPBX and to a residential.

vPBX (outbound user call - Outbound DDI on Company and also tested on user directly)
As soon as we call a telephone number without a country code, for example 0612200000 (mobile number), we get the error message.
~# [01f7c01c] [Kernel.php:60] AGI Error ("PJSIP/proxytrunks-00000077", "DDI +31612200000 not found in database.")

vPBX Terminal to Terminal
If we want to call another user within the vpbx with the extension number 101, he will give the following error message.
~# [d8b4d6a5] [Kernel.php:60] AGI Error ("PJSIP/proxytrunks-00000078", "DDI 101 not found in database.")

We also tested residential and we get the same error messages there too

Kind regards

Kaian · 2022-12-13T15:20:49Z

Hi @MichaelSTK

The errors lines alone are not enough to determine where the problem is, please provide all the call logs.
You can use call hash (p.e d8b4d6a5 in the last error) to grep all mensajes from the call (from both asterisk and kamailio)

If we want to call another user within the vpbx with the extension number 101, he will give the following error message.
~# [d8b4d6a5] [Kernel.php:60] AGI Error ("PJSIP/proxytrunks-00000078", "DDI 101 not found in database.")

That makes no sense at all. That message is only printed on incoming calls from external entities (DDI Providers). Calls from users or residential should never use that endpoint (they have their own PJSIP endpoint). The endpoint matching is done using X-Info-Endpoint header that should be present in the initial INVITE from Kamailio Users to Asterisk.

We will require logs and a full SIP dialog in PCAP format containing the traffic from User Phone -> Kamailio Users -> Asterisk, so we can check why that endpoint is being matched.

I assuming you have properly configured the terminals agains kamailio@users using company domain (that must point to users public IP address), and not placing calls directly from the terminal to asterisk.

Regards

MichaelSTK · 2022-12-13T16:02:36Z

Call from my phone extention 102 to mobile number

--- kamtail-proxyusers
[Dec 13 16:33:30] [cfd14e1d] AUTH: Auth needed (sip:102@1000.mydomain.nl;transport=TLS from tls:MYIP) - no_credentials
[Dec 13 16:33:30] [cfd14e1d] Request: INVITE sip:0612345678@1000.mydomain.nl;transport=TLS from sip:102@1000.mydomain.nl;transport=TLS (2 INVITE - tls:MYIP:59727) [S_wVIzfHeFMj9KTe8cQPtw..]
[Dec 13 16:33:30] [cfd14e1d] CLASSIFY: vpbx call Terminals#4 (b2:c3)
[Dec 13 16:33:30] [cfd14e1d] APPLY-TRANSFORMATION: '0612345678' -> '+31612345678' (applied rule: 'From out of area national to e164')
[Dec 13 16:33:30] [cfd14e1d] RELAY: Relaying to UDP:127.0.0.1:6060 (sip:+31612345678@1000.mydomain.nl;transport=TLS via sip:127.0.0.1:6060)
[Dec 13 16:33:30] [cfd14e1d] REALTIME: users:b2:c3:u7:S_wVIzfHeFMj9KTe8cQPtw.. -> {"Event":"Trying","Time":1670945610,"Call-ID":"S_wVIzfHeFMj9KTe8cQPtw..","Brand":"MyCompany","Company":"MyCompany - PBX - 1000","Direction":"outbound","Owner":"102 - Michael Mobiel","Party":"+31612345678","ID":"cb1cbbb3"}
[Dec 13 16:33:30] [cfd14e1d] RTPENGINE: rtpengine_manage [replace-session-connection replace-origin SIP-source-address ICE=remove RTP/AVP call-id=users-outbound-S_wVIzfHeFMj9KTe8cQPtw.. label=Aleg_label]
[Dec 13 16:33:30] [cfd14e1d] Response: 100 Trying from sip:102@1000.mydomain.nl (2 INVITE - udp:127.0.0.1:6060)
[Dec 13 16:33:30] [cfd14e1d] MANAGE_REPLY: '102@1000.mydomain.nl' has 1 calls now
[Dec 13 16:33:30] [cfd14e1d] REALTIME: users:b2:c3:u7:S_wVIzfHeFMj9KTe8cQPtw.. -> {"Event":"Proceeding","Time":1670945610,"Call-ID":"S_wVIzfHeFMj9KTe8cQPtw..","ID":"cb1cbbb3"}
[Dec 13 16:33:31] [cfd14e1d] Response: 603 Decline from sip:102@1000.mydomain.nl (2 INVITE - udp:127.0.0.1:6060)
[Dec 13 16:33:31] [cfd14e1d] MANAGE-FAILURE-AS: INVITE FAILED: '603 Decline' to '2 INVITE' from 'sip:102@1000.mydomain.nl;transport=TLS' (udp:127.0.0.1:6060)
[Dec 13 16:33:31] [cfd14e1d] RTPENGINE: rtpengine_manage [replace-session-connection replace-origin SIP-source-address ICE=remove RTP/AVP call-id=users-outbound-S_wVIzfHeFMj9KTe8cQPtw.. label=Aleg_label]
[Dec 13 16:33:31] [cfd14e1d] REALTIME: users:b2:c3:u7:S_wVIzfHeFMj9KTe8cQPtw.. -> {"Event":"Terminated","Time":1670945611,"Call-ID":"S_wVIzfHeFMj9KTe8cQPtw..","ID":"cb1cbbb3"}
[Dec 13 16:33:31] acc [acc.c:281]: acc_log_request(): ACC: transaction answered: timestamp=1670945611;utctime=2022-12-13 15:33:31;method=INVITE;from_tag=c8b2525b;to_tag=0122ab8c-002e-4794-849d-80a99703a620;call_id=S_wVIzfHeFMj9KTe8cQPtw..;code=603;reason=Decline;from_user=102;from_domain=1000.mydomain.nl;src_ip=84.MYIP.61;ruri_user=+31612345678;ruri_domain=1000.mydomain.nl;cseq=2;callid=S_wVIzfHeFMj9KTe8cQPtw..;cidhash=cfd14e1d
[Dec 13 16:33:31] [cfd14e1d] Request: ACK sip:0612345678@1000.mydomain.nl;transport=TLS from sip:102@1000.mydomain.nl;transport=TLS (2 ACK - tls:84.MYIP.61:59727) [S_wVIzfHeFMj9KTe8cQPtw..]

----- asterisk
> [a6cb5b43] Executing [+31612345678@trunks:1] NoOp("PJSIP/proxytrunks-0000008f", "Incoming external call from "" <102> to +31612345678") in new stack
> [a6cb5b43] Executing [+31612345678@trunks:2] AGI("PJSIP/proxytrunks-0000008f", "agi://127.0.0.1:4573/fastagi-runner.php?command=Dialplan/Trunks") in new stack
> [a6cb5b43] [Kernel.php:60 ] AGI Error ("PJSIP/proxytrunks-0000008f", "DDI +31612345678 not found in database.")
-- <PJSIP/proxytrunks-0000008f>AGI Script agi://127.0.0.1:4573/fastagi-runner.php?command=Dialplan/Trunks completed, returning 0
-- Auto fallthrough, channel 'PJSIP/proxytrunks-0000008f' status is 'UNKNOWN'

--- I assuming you have properly configured the terminals agains kamailio@users using company domain (that must point to users public IP address), and not placing calls directly from the terminal to asterisk.-----

Global Config,

My domain is complete with DNS to server ip

Added a brand: TestBrand with sip domein: sip.testbrand.com
Added a vPBX (brand TestBrand): Named TestPBXBrand with sip domain 1001.testbrand.com
Added a DDI to the vPBX and add users, terminals and extensions to it in client config

Zoiper registration 102@1001.testbrand.com works well, no problem.

Hope this is what you mean, if not what commands should I run for what you are looking for?

Thanks.

Kind regards.
Michael

Kaian · 2022-12-13T16:48:56Z

Hi!

It's strange, I'm missing some logs in kamailio@users about setting X-Info-Endpoint header and dispatching to Application Server

At least this message should be part of the logs:

ivozprovider/kamailio/users/config/kamailio.cfg

Line 1184 in 93a365e

xinfo("[$dlg_var(cidhash)] DISPATCH-TO-AS: going to <$ru> via <$du>\n");

That log is printed in the route in charge of setting the endpoint information for asterisk that has previously detected as Terminal#4

 [Dec 13 16:33:30] [cfd14e1d] CLASSIFY: vpbx call Terminals#4 (b2:c3)

Instead of printing DISPATCH_TO_AS info message the logs go to RELAY route directly

[Dec 13 16:33:30] [cfd14e1d] RELAY: Relaying to UDP:127.0.0.1:6060 (sip:+31612345678@1000.mydomain.nl;transport=TLS via sip:127.0.0.1:6060)

Can you verify the /etc/kamailio/proxyusers/kamailio.cfg contents are the same as https://raw.githubusercontent.com/irontec/ivozprovider/halliday/kamailio/users/config/kamailio.cfg

Can you provide the version of installed kamailio users config (dpkg -l ivozprovider-kamailio-users)?

Regards!

MichaelSTK · 2022-12-13T20:17:34Z

Hi,

Thanks for your reply that quick.

I'll compare the other files tomorrow.
Is there a way to easily compare the file on the server with the online version?

dpkg -l ivozprovider-kamailio-users
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-===========================-=======================================-============-=================================================================
ii ivozprovider-kamailio-users 3.0~~3.0.0~~20220714.226~058bb92+halliday all IVOZ Provider - Kamailio - Configuration files for Users kamailio

Kind regards.
Michael

Kaian · 2022-12-14T09:05:07Z

Hi!

I have noticed the missing logs are INFO messages, so it's normal not to be displayed in default debug level that only display NOTICE.

Are you using the same IP address for trunks and users proxies?
Please edit /etc/asterisk/config/pjsip.conf file and change endpoint_identifier_order to:

endpoint_identifier_order=header,ip,username,anonymous

And restart asterisk.

Give it a try, maybe this may fix outbound calls but break inbound calls from kamailio@trunks.

Regards

MichaelSTK · 2022-12-14T09:42:26Z

File not exist (/etc/asterisk/config/pjsip.conf )

~# Dir /etc/asterisk/
acl.conf confbridge.conf manager.conf queues.conf
ari.conf dialplan modules.conf res_fax.conf
asterisk.conf extconfig.conf musiconhold.conf res_odbc.conf
ccss.conf extensions.conf phpagi.conf rtp.conf
cdr.conf features.conf pjproject.conf sorcery.conf
cel.conf http.conf pjsip.conf syslog.conf
cli.conf indications.conf pjsip_notify.conf udptl.conf
codecs.conf logger.conf queuerules.conf voicemail.conf

No idea what is going wrong but it seems that the automatic installation is not going well.

I use 1 ip address

Is there a possibility for a meeting? then you can see for yourself what is going wrong.

Kind regards
Michael

Kaian · 2022-12-14T09:48:55Z

Hi

Most probably the X-Info-Endpoint matchpoint indetifier implemented in #1615 is not compatible with standalone installs with a single IP. Standalone versions using a single machine are not suitable for production so they are not as battle tested and some bugs may appear.

Please try using two different public IP addresses for trunks and users and check if the error persists.

Regards

MichaelSTK · 2022-12-14T10:11:34Z

Unfortunately I don't have 2 IP addresses at the moment, installation on 2 servers? or 1 server with 2 ip addresses?

Kaian · 2022-12-14T10:15:07Z

The problem seems related to using 1 IP address for both Kamailio Trunks and Users proxies, so 1 server 2 IP addresses will probably be a workaround for this issue.

MichaelSTK · 2022-12-14T12:15:54Z

Okay thank you for your response.

I'm going to see what I can do.

Thank you

damidani · 2024-05-19T00:49:43Z

Hello,
on my server I put two ip that corrected the problem of 603 decline but for calls I have no audio...

jai les ip
.27
.25
I put the .25 in proxyuser and .27 in proxytrunk
that didn't fix anything

Kaian self-assigned this Dec 12, 2022

Kaian added +evaluate Pending evaluation * halliday * IvozProvider 3.x Halliday Release labels Dec 12, 2022

Kaian changed the title ~~Outbound calls wont be placed (DDI not found in database)~~ Wrong endpoint identified on standalone installs with single IP address Dec 14, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Wrong endpoint identified on standalone installs with single IP address #1959

Wrong endpoint identified on standalone installs with single IP address #1959

devserge commented Dec 5, 2022 •

edited

Loading

devserge commented Dec 8, 2022

Kaian commented Dec 12, 2022 •

edited

Loading

MichaelSTK commented Dec 13, 2022

Kaian commented Dec 13, 2022 •

edited

Loading

MichaelSTK commented Dec 13, 2022

Kaian commented Dec 13, 2022

MichaelSTK commented Dec 13, 2022 •

edited

Loading

Kaian commented Dec 14, 2022 •

edited

Loading

MichaelSTK commented Dec 14, 2022 •

edited

Loading

Kaian commented Dec 14, 2022 •

edited

Loading

MichaelSTK commented Dec 14, 2022

Kaian commented Dec 14, 2022

MichaelSTK commented Dec 14, 2022

damidani commented May 19, 2024

Wrong endpoint identified on standalone installs with single IP address #1959

Wrong endpoint identified on standalone installs with single IP address #1959

Comments

devserge commented Dec 5, 2022 • edited Loading

Description

devserge commented Dec 8, 2022

Kaian commented Dec 12, 2022 • edited Loading

MichaelSTK commented Dec 13, 2022

Kaian commented Dec 13, 2022 • edited Loading

MichaelSTK commented Dec 13, 2022

Kaian commented Dec 13, 2022

MichaelSTK commented Dec 13, 2022 • edited Loading

Kaian commented Dec 14, 2022 • edited Loading

MichaelSTK commented Dec 14, 2022 • edited Loading

Kaian commented Dec 14, 2022 • edited Loading

MichaelSTK commented Dec 14, 2022

Kaian commented Dec 14, 2022

MichaelSTK commented Dec 14, 2022

damidani commented May 19, 2024

devserge commented Dec 5, 2022 •

edited

Loading

Kaian commented Dec 12, 2022 •

edited

Loading

Kaian commented Dec 13, 2022 •

edited

Loading

MichaelSTK commented Dec 13, 2022 •

edited

Loading

Kaian commented Dec 14, 2022 •

edited

Loading

MichaelSTK commented Dec 14, 2022 •

edited

Loading

Kaian commented Dec 14, 2022 •

edited

Loading