[Home]

Summary:ASTERISK-28258: DUNDi Does Not Register chan_pjsip Realtime Endpoints On Register
Reporter:Ross Beer (rossbeer)Labels:pjsip
Date Opened:2019-01-24 05:57:40.000-0600Date Closed:
Priority:MinorRegression?
Status:Open/NewComponents:PBX/pbx_dundi
Versions:13.24.1 Frequency of
Occurrence		Constant
Related
Issues:
is related toASTERISK-28238 PJSIP realtime. getcontext not working with DUNDI
Environment:CentOS 7.6Attachments:
Description:DUNDi does not register PJSIP endpoints when the configuration is stored in a Realtime database.

Settings are all stored in the database, including AORs, contacts and endpoints.

Endpoints show as 'Unavailable' state when registered if qualify is not used, due to a recent change to the qualify process.

Any endpoints stored in the text config do register with DUNDi and show as available.
Comments:By: Asterisk Team (asteriskteam) 2019-01-24 05:57:41.615-0600

Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution.

A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report.

Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process].

Please note that once your issue enters an open state it has been accepted. As Asterisk is an open source project there is no guarantee or timeframe on when your issue will be looked into. If you need expedient resolution you will need to find and pay a suitable developer. Asking for an update on your issue will not yield any progress on it and will not result in a response. All updates are posted to the issue when they occur.
By: Kevin Harwell (kharwell) 2019-01-24 12:09:39.759-0600

Note I've applied the patch from for ASTERISK-28238 (https://gerrit.asterisk.org/#/c/asterisk/+/10879/)

I've been unable to duplicate this so far. I've tried it with endpoints, aors, auths, and contacts all configured for realtime, with and without qualifies enabled (e.g. qualify_frequency=30), and tried it with both a udp and tcp endpoint. As well with dynamic and static contacts. Each time the endpoint would appropriately create the extension in the "regcontext".

My contact did show as available though:
{noformat}
*CLI> pjsip show endpoint 103

Endpoint:  <Endpoint/CID.....................................>  <State.....>  <Channels.>
   I/OAuth:  <AuthId/UserName...........................................................>
       Aor:  <Aor............................................>  <MaxContact>
     Contact:  <Aor/ContactUri..........................> <Hash....> <Status> <RTT(ms)..>
 Transport:  <TransportId........>  <Type>  <cos>  <tos>  <BindAddress..................>
  Identify:  <Identify/Endpoint.........................................................>
       Match:  <criteria.........................>
   Channel:  <ChannelId......................................>  <State.....>  <Time.....>
       Exten: <DialedExten...........>  CLCID: <ConnectedLineCID.......>
==========================================================================================

Endpoint:  103                                                  Not in use    0 of inf
    InAuth:  103/103
       Aor:  103                                               10
     Contact:  103/sip:103@xx.xx.xx.xx:39638;transport=T df3d566f47 Avail         6.165
 Transport:  transport_tcp             tcp      0      0  0.0.0.0:5060

<snip>

*CLI> pjsip show aor 103

     Aor:  <Aor..............................................>  <MaxContact>
   Contact:  <Aor/ContactUri............................> <Hash....> <Status> <RTT(ms)..>
==========================================================================================

     Aor:  103                                                 10
   Contact:  103/sip:103@10.24.19.247:39638;transport=TCP df3d566f47 Avail         6.424


ParameterName        : ParameterValue
==================================================================
authenticate_qualify : false
contact              : sip:103@xx.xx.xx.xx:39638;transport=TCP;ob
default_expiration   : 3600
mailboxes            :
max_contacts         : 10
maximum_expiration   : 7200
minimum_expiration   : 60
outbound_proxy       :
qualify_frequency    : 30
qualify_timeout      : 3.000000
remove_existing      : false
support_path         : false
voicemail_extension  :

CLI> dialplan show dundi
[ Context 'dundi' created by 'SIP' ]
 '103' =>          1. Noop(103)                                  [SIP]

-= 1 extension (1 priority) in 1 context. =-
{noformat}


By: Kevin Harwell (kharwell) 2019-01-24 12:09:46.511-0600

The code works by dynamically adding the extension to the regcontext when the endpoint goes "online" and dynamically removing the extension when the endpoint goes "offline". The endpoint's status is aggregated by the contact and aor statuses. So yes, if one is marked "Unavailable" then I'd expect the endpoint to be "offline", thus the extension not existing in the "regcontext".

I guess the question is why is it not available? The reliable transport connection is still up? For the associated aor what's the output of:
{noformat}
*CLI> pjsip show aor <aor id>
{noformat}
Also please provide an Asterisk log with a SIP trace of the endpoint registering.
By: Ross Beer (rossbeer) 2019-01-28 04:23:35.239-0600

When using realtime the status only ever shows as 'Created' not 'Avail':

{noformat}
pjsip show aor <ID>

     Aor:  <Aor..............................................>  <MaxContact>
   Contact:  <Aor/ContactUri............................> <Hash....> <Status> <RTT(ms)..>
==========================================================================================

     Aor:  <ID>                                            1
   Contact:  <ID>/sip:<ID>@<IP ADDRESS>:51256;t 368082ea23 Created       0.000


ParameterName        : ParameterValue
========================================================================
authenticate_qualify : false
contact              : sip:<ID>@<IP ADDRESS>:51256;transport=TLS;ob
default_expiration   : 60
mailboxes            : <ID>@default
max_contacts         : 1
maximum_expiration   : 3600
minimum_expiration   : 60
outbound_proxy       :
qualify_frequency    : 0
qualify_timeout      : 0.000000
remove_existing      : true
support_path         : false
voicemail_extension  : <ID>
{noformat}
By: Kevin Harwell (kharwell) 2019-01-29 13:24:05.701-0600

What's the output of the following:
{noformat}
*CLI> core show version
{noformat}
I'm not entirely sure how your contact is marked "Created". When a dynamic contact gets added it is initially set to "Created", but immediately gets set to "Unknown" if the _qualify_frequency_ is zero.

To potentially move forward I think we are really going to need an Asterisk debug log (debug of at least 5) with the sip tracing included/enabled of the registration for the endpoint in question.
By: Ross Beer (rossbeer) 2019-02-04 05:47:27.402-0600

Looking at the file res/res_pjsip/pjsip_options.c it appears that the default status is 'Created' but I can't see this being changed when 'qualify_frequency=0'.

The ps_aor and ps_contacts table has 'qualify_frequency=0' and 'qualify_timeout=0'.

The issue with status not showing available started with commit https://gerrit.asterisk.org/#/c/asterisk/+/7710/, I raised a ticket at the time ASTERISK-27899

At line 501 the status is set:

{noformat}
       contact_status->rtt = 0;
contact_status->status = CREATED;
contact_status->last_status = CREATED;
res = ast_string_field_set(contact_status, uri, contact->uri);
res |= ast_string_field_set(contact_status, aor, contact->aor);
if (res) {
ao2_unlock(sip_options_contact_statuses);
ao2_ref(contact_status, -1);
return NULL;
}
{noformat}

One thing that is different from the standard is we use 'allow_unqualified_fetch=error' on 'contact' and 'aor' in sorcery.conf. Would this make a difference when creating the initial status?

{noformat}
contact/cache=memory_cache,expire_on_reload=yes
contact=realtime,ps_contacts,allow_unqualified_fetch=error

aor=config,pjsip.conf,criteria=type=aor
aor/cache=memory_cache,expire_on_reload=yes
aor=realtime,ps_aors,allow_unqualified_fetch=error
{noformat}
By: Kevin Harwell (kharwell) 2019-02-05 11:11:50.652-0600

That's it!
{noformat}
aor=realtime,ps_aors,allow_unqualified_fetch=error
{noformat}
If _allow_unqualified_fetch=error_ then the contact remains in a _Created_ status, the endpoint doesn't get updated to _online_, thus not added to the specified regcontext.
By: Kevin Harwell (kharwell) 2019-02-05 11:19:46.503-0600

[~rossbeer] I'm not entirely sure what affect that option is suppose to have. I'm opening the issue for someone to look more into it, but as a work around can you set that to "warn" or "yes"?
By: Ross Beer (rossbeer) 2019-02-11 00:07:33.813-0600

After testing the removal of allow_unqualified_fetch=error on aor and contacts the status still stays the same showing 'created'