I added allow_reload to my transport and configured res_stun_monitor. After the set time Asterisk logs
res_stun_monitor.c:151 stun_monitor_request: Old external address/port 0.0.0.0:0 now seen as publicip:port
but there is no re-register. Additionally still the “old” IP is transmitted in an INVITE.
I’m using version 14.5.0 with pjsip.
The .conf file still needs to be updated as far as I know. That’s the extent of my knowledge in the area.
OK, this doesn’t make sense to me. The monitor knows the new IP and should reload automatically. How shall I know that the IP changed?
I added ice_support=yes but it’s still not working.
After executing ‘pjsip reload’ (which doesn’t make sense) Asterisk says:
Module 'res_pjsip.so' reloaded successfully.
Module 'res_pjsip_authenticator_digest.so' reloaded successfully.
Module 'res_pjsip_endpoint_identifier_ip.so' reloaded successfully.
Module 'res_pjsip_mwi.so' reloaded successfully.
Module 'res_pjsip_notify.so' reloaded successfully.
Module 'res_pjsip_outbound_publish.so' reloaded successfully.
Module 'res_pjsip_publish_asterisk.so' reloaded successfully.
Module 'res_pjsip_outbound_registration.so' reloaded successfully.
NOTICE[4031]: sorcery.c:1409 sorcery_object_load: Type 'system' is not reloadable, maintaining previous values
The res_stun_monitor module detects that the external IP address has changed and raises an event internally that other modules can know it has. The res_pjsip_outbound_registration module has basic support for that, when it receives that event it does a re-registration. That event does not cause the information in the registration itself to be altered.
Dynamic IPs and PJSIP are not currently something many people do, so it hasn’t seen much focus.
So you mean the easiest way is restarting Asterisk in case of an IP change?
That is guaranteed to work.
Very sad. I would have had a nice solution for my problem, but if the development is not yet at this point I should prefer the other way. Who is responsible for this feature meaning who has to integrate the automatical reload?
Asterisk is an open source project. Any changes can be made and contributed by anyone. There is no single person or entity responsible for it all.
I know about the open source orientation and it’s very important to me. The official developer of Asterisk is Digium, isn’t it? If the automatical reload feature shall be added, has this to be done by Digium or by pjproject?
So whom to ask for integrating such a feature?
I believe the Proxy needs to add a Record-Route header, giving its public address. Otherwise the ITSP will not be able to send Re-INVITE, or BYE transactions to the correct place. You might get away with it with TCP, but not with UDP.
As noted before, I think it would be unusual to get a 403 because of this. It would be more normal that the Re-INVITE or BYE got lost.
@david551 Unfortunately, I’m not experienced with SIP. Don’t you think the ITSP is simply not accepting proxies?
The public IP is included in the added Via header, is it not sufficient?
There are a host of contributors to Asterisk, not all of them work for Digium. You can see who’s been contributing lately here [1]. If there’s a capability you want in Asterisk, you can write it up yourself and work through the patch contribution process [2] or you can find someone else to do it for you. Digium isn’t the responsible party for coding up feature requests that people present. There is no responsible party for that. If you’re trying to find someone else to build a feature for you, you’re welcome to solicit people on these community forums (perhaps people are already reading this thread) or on the asterisk-users mailing list [3]. Additionally, Bug Bounties [4] can also apply to feature requests.
1 - https://gerrit.asterisk.org/#/q/status:merged
2 - Home - Asterisk Documentation
3 - asterisk-users Info Page
4 - Home - Asterisk Documentation
Via only covers the current transaction, and not even the ACK (although, the ACK is going the other way, in this case).
For any subsequent transaction, Contact is used. E.g. a load balancing proxy will forward to a worker, and the worker will respond with Contact, so that further communication is direct, and the proxy doesn’t need to remember anything. To keep the proxy in circuit, as you need to do, you must add a Record-Route header.
As you stated though, this wouldn’t be the cause of the 403. That’s separate.
When you say outgoing calls are failing, I interpret that as saying incoming ones work. Is that actually true?
Unfortunately, Asterisk sends 401 Unauthorized to the ITSP. Perhaps somebody could have a short look at my Asterisk configuration (adapted):
[global]
type=global
endpoint_identifier_order=ip,username
default_from_user=mynumber
[transport-udp]
type=transport
protocol=udp
bind=localip
local_net=localip/24
allow_reload=yes
[provider_mynumber]
type=registration
transport=transport-udp
outbound_auth=provider_mynumber_auth
server_uri=sip:sip.provider.com
client_uri=sip:mynumber@sip.provider.com
retry_interval=60
forbidden_retry_interval=300
expiration=480
auth_rejection_permanent=false
outbound_proxy=sip:localip:5069\;lr
[provider_mynumber_auth]
type=auth
auth_type=userpass
password=*******
username=mynumber
realm=sip.provider.com
[provider_out]
type=endpoint
transport=transport-udp
context=unspecified
disallow=all
allow=g722
allow=alaw
outbound_auth=provider_mynumber_auth
aors=provider_out
callerid=mynumber
from_user=mynumber
from_domain=sip.provider.com
timers=no
rtp_symmetric=yes
direct_media=no
outbound_proxy=sip:localip:5069\;lr
[provider_out]
type=aor
contact=sip:mynumber@sip.provider.com
[provider_in]
type=endpoint
transport=transport-udp
context=provider_in
disallow=all
allow=g722
allow=alaw
outbound_auth=provider_mynumber_auth
[provider_in]
type=identify
endpoint=provider_in
match=217.0.0.0/13
... Softphone
I believe there are some mistakes.
These are the current happenings:
Registration: working
Outgoing calls: 403 Forbidden (by ITSP)
Incoming calls: 401 Unauthorized (by Asterisk)
If incoming calls are reaching Asterisk, it means that the proxy is handling Contact correctly on the register. I had wondered if it was registering with the private address and the ITSP was rejecting based on source IP address.
401 is not an error, but it is normally a misconfiguration if one is sent to an ITSP.
Asterisk sends a WWW-Authenticate header to the ITSP with realm=asterisk. How to stop that?
I’m afraid I can only answer that for chan_sip.
In general terms, though, you must make sure that the provider matches a known end point and that endpoint is configured not to require the peer to authenticate.
For the second part, on chan_sip, you would use remotesecret, rather than secret, although a lot of old cook book solutions suggest using insecure-invite, with secret.
For the first part, check that the endpoint IP addresses matches the source IP address from which Asterisk receives the request (might be the proxy).
I saw No matching endpoint found in the log file. By reference to which parameters is an endpoint matched?