[asterisk-dev] Asterisk 16.9.0-rc1 Now Available - unusable with Deutsche Telekom

[Michael Maier]

On 09.03.20 at 19:04 George Joseph wrote:
> On Mon, Mar 9, 2020 at 10:59 AM Michael Maier <m1278468 at mailbox.org> wrote:
> 
>> On 09.03.20 at 13:43 George Joseph wrote:
>>> On Sun, Mar 8, 2020 at 2:48 PM George Joseph <gjoseph at digium.com> wrote:
>>>
>>>>
>>>>
>>>> On Fri, Mar 6, 2020 at 10:07 PM Michael Maier <m1278468 at mailbox.org>
>>>> wrote:
>>>>
>>>>> Hello!
>>>>>
>>>>> On 05.03.20 at 19:08 Asterisk Development Team wrote:
>>>>>>  * ASTERISK-28746 - res_pjsip_outbound_registration keeps
>>>>>>       retrying the first entry in a SRV record set
>>>>>>       (Reported by
>>>>>>       George Joseph)
>>>>>
>>>>> 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.
>>>>>
>>>>>
>>> I'm thinking more about this...   Basically, the only reason this worked
>> in
>>> the past is that the SRV processing was broken. :)
>>
>> Yes - that's definitely true. Sometime, "broken" isn't always that bad
>> but can be pretty good at the same time on the other hand :-)
>>
>> BTW:
>> While you're at it: it would be a great oportunity to get it sorted out
>> completely by globaly adding session stability (one trunk always uses
>> same IP destination for all actions. If the destionation can't be
>> reached any more (or misbehaves), you have to reregister to another IP
>> of the list and remember the new IP for all following actions).
>>
> 
> Yeah, we're thinking that's the only real solution but it's not a quick fix
> and will need some serious thought.  For instance, if on registration the
> first server in the set was successful but when Asterisk attempted to send
> a call, the first server failed, would you expect Asterisk to automatically
> try to re-register and then use the new server?

Exactly.

>  That would be a lot of
> work just to support DT.  Now if they could point to an RFC that codifies
> their required behavior it would be a different matter.  We checked around
> and couldn't find anything however.

The complete interface documentation and the related RFCs can be found
here (there system is based on IMS and 3GPP):

https://www.telekom.de/hilfe/geraete-zubehoer/telefone-und-anlagen/informationen-zu-telefonanlagen/schnittstellenbeschreibungen-fuer-hersteller?wt_mc=alias_1254_schnittstellenbeschreibungen&samChecked=true

Or direct link (in english language):
https://www.telekom.de/hilfe/downloads/1tr114.pdf

> 
> 
>>
>>> Anyway, What do the 3 numbers represent?  3 different DIDs and therefore
>> it
>>> could be any number, or 3 numbers for each DID, etc.?  How do you use
>> the 3
>>> numbers?
>>
>> The 3 numbers are 3 completely different numbers and DIDs at the same
>> time. They are used for in- and outbound calls and each number
>> represents an own trunk (as seen by FreePBX e.g.). You have to register
>> each number on its own to be able to place outbound calls and to get
>> inbound calls for this number. If you don't register a number and
>> someone calls this number, the caller gets a "the number you dialed is
>> currently not available - please try again later".
>>
> 
> OK I understand now.
> 
> I think the bottom line is that this isn't a regression and creating an
> option to disable a bug fix isn't a real solution.  While we figure out a
> long term solution I believe your only short term one is to use IP
> addresses or specific A/AAAA records ion your configuration.

For me, it's not a problem (I'm anyway buliding asterisk on my own
[because of missing mediasec support
http://lists.digium.com/pipermail/asterisk-dev/2019-September/077518.html ]
and I'm just reverting it) - but for many other users, it will be a huge
problem. Asterisk just wont work any more.

My current solution already is to use a RPZ with bind, which is filled
by a cron job with the actual working hosts of the SRV set. Broken
servers are received from the asterisk logfile. If a broken server is
detected, the broken one in the RPZ is removed and the three numbers are
reregeistered. Same is done if a server is removed from the SRV set.

By the way: Since years, I never needed to change any SRV set, because
they are runnig pretty stable. That's probably the reason, why people
very seldom face this problem.

But now, they will face it, because on most asterisk restarts, one of
the number can't be registered at the first attempt. Asterisk now uses
the second server and registration proceeds - but you can't place any call.


Thanks
Michael