[asterisk-bugs] [JIRA] (ASTERISK-28775) SRV fix for ASTERISK-28746 fails with Deutsche Telecom

Mon Mar 9 11:01:25 CDT 2020

     [ https://issues.asterisk.org/jira/browse/ASTERISK-28775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Maier updated ASTERISK-28775:
-------------------------------------

    Status: Waiting for Feedback  (was: Waiting for Feedback)

Some more information:

That's what you get for SRV from DNS:

dig +noall +answer _sips._tcp.tel.t-online.de SRV
_sips._tcp.tel.t-online.de. 767 IN SRV 20 0 5061 d-eps-100.edns.t-ipnet.de.
_sips._tcp.tel.t-online.de. 767 IN SRV 10 0 5061 hh-eps-110.edns.t-ipnet.de.
_sips._tcp.tel.t-online.de. 767 IN SRV 30 0 5061 h2-eps-100.edns.t-ipnet.de.

Following, you can find 3 accounts (numbers), which all have to be registered individually. Strictly speaking, it's one account, which registers 3 (or even more) numbers. They are all registered to tel.t-online.de. After registration, you have to take care, that all subsequent actions (like OPTIONS, INVITE, ...) must be sent to the same server you initially registered to.
The identification (and therefore the assignment to the correct trunk) of incoming calls is done via line option.

Registering to d-eps-100.edns.t-ipnet.de but sending an INVITE for an outgoing call later on to hh-eps-110.edns.t-ipnet.de fails, because hh-eps-110.edns.t-ipnet.de doesn't know anything about the registration to d-eps-100.edns.t-ipnet.de.
This wasn't any problem so far, because the Deutsche Telekom servers have been rock stable over many years now.

pjsip.aor.conf:
[telekomPJSIP-890]
type=aor
qualify_frequency=240
contact=sip:+491234567890 at tel.t-online.de

[telekomPJSIP-141]
type=aor
qualify_frequency=240
contact=sip:+4924681012141 at tel.t-online.de

[telekomPJSIP-821]
type=aor
qualify_frequency=240
contact=sip:+4936912151821 at tel.t-online.de

pjsip.auth.conf:
[telekomPJSIP-890]
type=auth
auth_type=userpass
password=secret
username=+491234567890

[telekomPJSIP-141]
type=auth
auth_type=userpass
password=secret
username=+4924681012141

[telekomPJSIP-821]
type=auth
auth_type=userpass
password=secret
username=+4936912151821

pjsip.endpoint.conf:
[telekomPJSIP-890]
type=endpoint
transport=0.0.0.0-tls
context=from-pstn
disallow=all
allow=g722,alaw,ulaw
aors=telekomPJSIP-890
send_connected_line=yes
language=de
outbound_auth=telekomPJSIP-890
from_domain=tel.t-online.de
from_user=+491234567890
contact_user=+491234567890
t38_udptl=no
t38_udptl_ec=none
fax_detect=no
trust_id_inbound=no
t38_udptl_nat=no
direct_media=no
rewrite_contact=yes
media_encryption=sdes
rtp_symmetric=yes
dtmf_mode=rfc4733

[telekomPJSIP-141]
type=endpoint
transport=0.0.0.0-tls
context=from-pstn
disallow=all
allow=alaw,ulaw
aors=telekomPJSIP-141
send_connected_line=false
language=de
outbound_auth=telekomPJSIP-141
from_domain=tel.t-online.de
from_user=+4924681012141
contact_user=+4924681012141
t38_udptl=no
t38_udptl_ec=none
fax_detect=no
trust_id_inbound=no
t38_udptl_nat=no
direct_media=no
rewrite_contact=yes
media_encryption=sdes
rtp_symmetric=yes
dtmf_mode=rfc4733

[telekomPJSIP-821]
type=endpoint
transport=0.0.0.0-tls
context=from-pstn
disallow=all
allow=alaw,ulaw
aors=telekomPJSIP-821
send_connected_line=false
language=de
outbound_auth=telekomPJSIP-821
from_domain=tel.t-online.de
from_user=+4936912151821
contact_user=+4936912151821
t38_udptl=no
t38_udptl_ec=none
fax_detect=no
trust_id_inbound=no
t38_udptl_nat=no
direct_media=no
rewrite_contact=yes
media_encryption=sdes
rtp_symmetric=yes
dtmf_mode=rfc4733

pjsip.registration.conf:
[telekomPJSIP-890]
type=registration
transport=0.0.0.0-tls
outbound_auth=telekomPJSIP-890
retry_interval=60
fatal_retry_interval=0
forbidden_retry_interval=10
max_retries=10000
expiration=660
line=yes
endpoint=telekomPJSIP-890
auth_rejection_permanent=yes
contact_user=+491234567890
server_uri=sip:tel.t-online.de
client_uri=sip:+491234567890 at tel.t-online.de

[telekomPJSIP-141]
type=registration
transport=0.0.0.0-tls
outbound_auth=telekomPJSIP-141
retry_interval=60
fatal_retry_interval=0
forbidden_retry_interval=10
max_retries=10000
expiration=660
line=yes
endpoint=telekomPJSIP-141
auth_rejection_permanent=yes
contact_user=+4924681012141
server_uri=sip:tel.t-online.de
client_uri=sip:+4924681012141 at tel.t-online.de

[telekomPJSIP-821]
type=registration
transport=0.0.0.0-tls
outbound_auth=telekomPJSIP-821
retry_interval=60
fatal_retry_interval=0
forbidden_retry_interval=10
max_retries=10000
expiration=660
line=yes
endpoint=telekomPJSIP-821
auth_rejection_permanent=yes
contact_user=+4936912151821
server_uri=sip:tel.t-online.de
client_uri=sip:+4936912151821 at tel.t-online.de

pjsip.identify.conf
[telekomPJSIP-890]
type=identify
endpoint=telekomPJSIP-890
match=127.0.0.10

[telekomPJSIP-141]
type=identify
endpoint=telekomPJSIP-141
match=127.0.0.10

[telekomPJSIP-821]
type=identify
endpoint=telekomPJSIP-821
match=127.0.0.10

> SRV fix for ASTERISK-28746 fails with Deutsche Telecom
> ------------------------------------------------------
>
>                 Key: ASTERISK-28775
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-28775
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_pjsip_outbound_registration
>    Affects Versions: 16.9.0
>            Reporter: Michael Maier
>            Assignee: Michael Maier
>
> From [~micha]
> I just tested the new version 16.9.0.rc1 and promptly got an error with
> this patch. With Deutsche Telekom, you always get a SRV record set. On
> the other hand, you mostly have to register 3 numbers - each must be
> registered on its own - to the same destination. Therefore, on startup,
> there are 3 registers done to the same destination. Often, one of the
> three numbers fails to register on the first attempt and therefore, it
> is done twice.
> With this patch, you're now using the second of usually 3 SRV entries
> and registration is done successfully (which would have worked too, if
> you would have used the first entry again, because it's just a very
> temporary problem) - but all succeeding calls (outgoing INVITEs) are now
> rejected (403 Forbidden), because they are going to the first entry of
> the SRV record set - which fails on Deutsche Telekom, because they await
> all subsequent actions to be done at the same server as the registration
> was done.
> Therefore, this patch is a no go for all users of Deutsche Telekom or
> any other provider relying on all actions to be done to always the same
> destination IP.
> Therefore, please make this new feature switchable or add another
> feature, which takes care to always use the same destination IP as
> initially used for the registration. You have to take care, too, that
> there is more than one number at the same time - but all of them using
> the same destination SRV hostname, but they could have different IP
> addresses - but each number must use its own IP which was initially used
> for the register.
> For convenience, I attached the reverse patch to remove the offending
> patch which makes asterisk mainly unusable for users of Deutsche Telekom.

--
This message was sent by Atlassian JIRA
(v6.2#6252)