On Mon, Mar 9, 2020 at 10:59 AM Michael Maier <[email protected]> wrote:
> On 09.03.20 at 13:43 George Joseph wrote: > > On Sun, Mar 8, 2020 at 2:48 PM George Joseph <[email protected]> wrote: > > > >> > >> > >> On Fri, Mar 6, 2020 at 10:07 PM Michael Maier <[email protected]> > >> 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]
-- _____________________________________________________________________ -- 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
