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

[George Joseph]

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?  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.


>
> > 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.


>
>
> Thanks
> Michael
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev



-- 
George Joseph
Asterisk Software Developer
direct/fax +1 256 428 6012
Check us out at www.sangoma.com and www.asterisk.org
[image: image.png]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20200309/4b837341/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 5142 bytes
Desc: not available
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20200309/4b837341/attachment.png>