Telekom Germany SIP Trunk SRV Records and pjsip

[dirk2358]

@Stewart1

Outbound Proxy: sip:f-epp-110.edns.t-ipnet.de;lr

Did you ever test it with Deutsche Telekom (AllIP) or is it just theories? I definitely know that it’s not working using TLS (certificate validation error - yes, I used the correct server - not the one you mentioned here).
Using outbound proxy adds the following header to register:

Route: <sip:f-eps-100.edns.t-ipnet.de;lr>

Deutsche Telekom expects as proxy, if any: SIP-Proxy: tel.t-online.de (see here)
I wouldn’t be surprised if they would drop the request if there is another route entry as they expect as they are pretty picky regarding other broken headers / values, too.

Here is the documentation of the interfaces of Deutsche Telekom.

[Stewart1 (Stewart)]

@dirk2358

Using outbound proxy adds the following header to register:
Route: <sip:f-eps-100.edns.t-ipnet.de;lr>

Son-of-a-bitch, you are correct. I had not noticed this before, because it didn’t cause me any trouble.

However, you aren’t the only one plagued by this, and a gentleman with the problem submitted a patch that was accepted!

https://trac.pjsip.org/repos/ticket/832

So,
Outbound Proxy: sip:f-epp-110.edns.t-ipnet.de\;lr\;hide
and you should be good to go. Of course, finding and fixing the real problem would be better.

[billsimon]

What does it mean to loose-route (;lr) when you aren’t going to include the Route header (;hide)?

[Stewart1 (Stewart)]

;lr is probably meaningless with ;hide, but I tried the combination thinking that if ;hide just hides something, then I had better also include ;lr to avoid butchering the URI. It did what the OP asked for, so I stopped there.

[dirk2358]

@Stewart1

So,
Outbound Proxy: sip:f-epp-110.edns.t-ipnet.de\;lr\;hide
and you should be good to go.

This makes the Route header disappear, but doesn’t obviously fix the certificate error. May be it’s working with TCP.

@Stewart1

Of course, finding and fixing the real problem would be better.

Yes. As long as Asterisk isn’t fixed, it’s better or the only way, to do it via DNS manipulation and checking logfile of Asterisk for problems and accordingly changing DNS entries after unregistering the trunks. Finally reRegister to the new server.

As long as you don’t mind regarding availability, you may try the easy “Outbound proxy” - workaround (when not using TLS). This means, you’re not just unsecure (missing encryption), but also have reduced availability. From the Deutsche Telekom AllIP perspective, I can say, that the last 2 years those 3 servers (they are localized - others most probably see different servers) here never changed and had no outage at all - but that doesn’t say anything. Could be changed tomorrow.

[billsimon]

@dirk2358

As long as Asterisk isn’t fixed

I’m curious what the expected fix would be. It sounds like a stalemate. The provider blocks many registration attempts to one of its proxies for DDoS protection, so Asterisk uses the next proxy in the SRV. Both sides are doing what they should be doing.

[dirk2358]

Quoting myself:

@dirk2358

the key problem is: Asterisk can’t assure, that all subsequent requests must always go to the same destination as it initially registered to. Same problem could happen if the priority is changed in the SRV records some time later after registration. At this point, Asterisk would have to register to the new destination as soon as no more calls are active to this trunk.

[billsimon]

That may not be desired behavior for everyone. Perhaps if you initiated a feature request for Asterisk it could be an optional parameter.

[dirk2358]

Yes, that’s true - an optional parameter would be absolutely fine. George Joseph does know about the problem since more than a year.