Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

pjsip auf SRV umstellen

175 views
Skip to first unread message

Tim Ritberg

unread,
Feb 13, 2021, 5:13:56 AM2/13/21
to
Hi!

Die Telekom hat Kunden angeschrieben, SIP-Geräte müssen jetzt SRV nutzen.

Wo muss ich da bei Asterisk bzw pjsip drehen? Ich habe verschiedene
Sachen probiert. Im DNS-Log stehen aber noch Anfragen nach A und
gleichzeitig NAPTR:
(tel.t-online.de): query: tel.t-online.de IN NAPTR +E(0)D (127.0.0.1)
(tel.t-online.de): query: tel.t-online.de IN A +E(0)D (127.0.0.1)

Tim

Tim Ritberg

unread,
Feb 13, 2021, 5:32:38 AM2/13/21
to
Am 13.02.21 um 11:13 schrieb Tim Ritberg:

> (tel.t-online.de): query: tel.t-online.de IN NAPTR +E(0)D (127.0.0.1)
> (tel.t-online.de): query: tel.t-online.de IN A +E(0)D (127.0.0.1)
>

Beim DNS-Log hatte ich wohl nicht richtig geschaut:

11:28:09.523 query: stun.t-online.de IN A + (127.0.0.1)
11:28:10.673 query: tel.t-online.de IN NAPTR +E(0)D (127.0.0.1)
11:28:10.673 query: _sip._udp.tel.t-online.de IN SRV +E(0)D (127.0.0.1)
11:28:10.673 query: tel.t-online.de IN A +E(0)D (127.0.0.1)

Einmal fragt er nach A tel.t-online.de. Aber auch SRV. Ist das so richtig?

Tim

Henning Hucke

unread,
Feb 13, 2021, 8:37:42 AM2/13/21
to
On 2021-02-13, Tim Ritberg <t...@server.invalid> wrote:

Hallo Tim,

> [...]
> 11:28:09.523 query: stun.t-online.de IN A + (127.0.0.1)
> 11:28:10.673 query: tel.t-online.de IN NAPTR +E(0)D (127.0.0.1)
> 11:28:10.673 query: _sip._udp.tel.t-online.de IN SRV +E(0)D (127.0.0.1)
> 11:28:10.673 query: tel.t-online.de IN A +E(0)D (127.0.0.1)
>
> Einmal fragt er nach A tel.t-online.de. Aber auch SRV. Ist das so richtig?

wenn Du mit der Frage "Ist das so richtig?" meinst, ob Du die zitierten
Informationen richtig interpretierst: Nein.
Der "Standard" ist, dass die für einen SIP-Realm ("localpart@sip-realm")
zunächst per Abfrage vorhandener NAPTR-RRs ermittelt wird, welcher
DNS-Eintrag für zuständige SIP-Server abgefragt werden soll (hier:
"_sip._tcp.tel.t-online.de"). Für diesen werden dann SRV-RRs abgefragt,
die ein Set von Servern, deren Priotitäten, Gewichtungen und zu
verwendende Ports (nicht notwendigerweise aber üblicherweise der
SIP-Port 5060) liefern.

Ansonsten: Ohne den Inhalt der Benachrichtigung der Telekom / von
T-Online zu kennen, kann Dir die Frage kaum serös beantwortet werden -
es seidenn, der Antwortende hat diese Eenachrichtigung ebenfalls
erhalten.
Vermuten möchte ich, dass Deine Installation bereits alles richtig (TM)
macht und es der Telekom eher darum geht, dass älteren Installationen es
so tun, wie Deine.

Mit freundlichem Gruß,
Henning Hucke
--
Applause, n:
The echo of a platitude from the mouth of a fool.
-- Ambrose Bierce

Tim Ritberg

unread,
Feb 13, 2021, 9:32:12 AM2/13/21
to
Am 13.02.21 um 14:27 schrieb Henning Hucke:

>
> wenn Du mit der Frage "Ist das so richtig?" meinst, ob Du die zitierten
> Informationen richtig interpretierst: Nein.
> Der "Standard" ist, dass die für einen SIP-Realm ("localpart@sip-realm")
> zunächst per Abfrage vorhandener NAPTR-RRs ermittelt wird, welcher
> DNS-Eintrag für zuständige SIP-Server abgefragt werden soll (hier:
> "_sip._tcp.tel.t-online.de"). Für diesen werden dann SRV-RRs abgefragt,
> die ein Set von Servern, deren Priotitäten, Gewichtungen und zu
> verwendende Ports (nicht notwendigerweise aber üblicherweise der
> SIP-Port 5060) liefern.
>
Wie stellt man dann pjsip dafür ein?

> Ansonsten: Ohne den Inhalt der Benachrichtigung der Telekom / von
> T-Online zu kennen, kann Dir die Frage kaum serös beantwortet werden -

Das steht hier:
https://geschaeftskunden.telekom.de/hilfe-und-service/online-services/hilfe-internetanschluss/telefonieanpassung#telekom

Tim

Andreas Hartmann

unread,
Feb 14, 2021, 12:00:27 PM2/14/21
to
On 13.02.21 at 15:32 Tim Ritberg wrote:
> Am 13.02.21 um 14:27 schrieb Henning Hucke:
>
>>
>> wenn Du mit der Frage "Ist das so richtig?" meinst, ob Du die
>> zitierten Informationen richtig interpretierst: Nein.
>> Der "Standard" ist, dass die für einen SIP-Realm
>> ("localpart@sip-realm") zunächst per Abfrage vorhandener NAPTR-RRs
>> ermittelt wird, welcher DNS-Eintrag für zuständige SIP-Server
>> abgefragt werden soll (hier: "_sip._tcp.tel.t-online.de"). Für diesen
>> werden dann SRV-RRs abgefragt, die ein Set von Servern, deren
>> Priotitäten, Gewichtungen und zu verwendende Ports (nicht
>> notwendigerweise aber üblicherweise der SIP-Port 5060) liefern.
>>
> Wie stellt man dann pjsip dafür ein?

Das ist bei Asterisk / pjsip default, solange Du mit Hostnamen operierst
(tel.t-online.de). Außerdem - trace doch einfach mal über einige Stunden
den DNS-Verkehr, dann wirst Du es sehen.


Gruß
Andreas

Henning Hucke

unread,
Feb 14, 2021, 1:37:42 PM2/14/21
to
On 2021-02-13, Tim Ritberg <t...@server.invalid> wrote:


> Am 13.02.21 um 14:27 schrieb Henning Hucke:
>
> [...]
> Wie stellt man dann pjsip dafür ein?

Gar nicht. Die pjsip verwendende Applikation muss einiges mit tun.
Seit Asterisk 14 wird die Funktionalität unterstützt. Hätte man übrigens
googlen können mit den Stichworten "pjsip" und "SRV" - der BLOG-Artikel
bei Asterisk.

> [...]
Uhhhh! Da steht überhaupt gar nichts über technische Anforderungen. Aber
das, was dort steht, legt nahe, dass die beschriebene Funktionalität
benötigt wird, die bei Deiner Installation ganz offensichtlich bereits
vorhanden ist und genutzt wird.
Die Telekom ist schon auch so "intelligent", dass sie nicht hart
umstellen, sondern das neue bereits läuft, annouciert wird, dass das
Alte irgendwann ausgeschaltet wird und dann nochmal, dass es demnächst
ausgeschaltet wird. Letzteres ist offensichtlich kürzlich getan worden.

MfG Henning
--
If the future isn't what it used to be, does that mean that the past
is subject to change in times to come?

Tim Ritberg

unread,
Feb 14, 2021, 1:47:08 PM2/14/21
to
Am 14.02.21 um 17:58 schrieb Andreas Hartmann:
Ich hab ein Dauer-DNS-Log. Der A-Record wurde seit 2 Tagen gar nicht
mehr abgefragt. Scheinbar ist alles okay.

Tim

Tim Ritberg

unread,
Feb 20, 2021, 4:45:56 PM2/20/21
to
Am 14.02.21 um 19:47 schrieb Tim Ritberg:
Aber zu früh gefreut. Die Anmeldungen von Asterisk wurden alle rejected:
res_pjsip_outbound_registration.c: Fatal response '400' received from
'sip:tel.t-online.de' on registration attempt to
'sip:+49123...@tel.t-online.de:5060', stopping outbound registration

Tim

Andreas Hartmann

unread,
Feb 21, 2021, 3:00:47 AM2/21/21
to

On 20.02.21 at 22:45 Tim Ritberg wrote:
> Am 14.02.21 um 19:47 schrieb Tim Ritberg:
>> Am 14.02.21 um 17:58 schrieb Andreas Hartmann:
>>> On 13.02.21 at 15:32 Tim Ritberg wrote:
>>
>>>
>>> Das ist bei Asterisk / pjsip default, solange Du mit Hostnamen operierst
>>> (tel.t-online.de). Außerdem - trace doch einfach mal über einige Stunden
>>> den DNS-Verkehr, dann wirst Du es sehen.
>>>
>> Ich hab ein Dauer-DNS-Log. Der A-Record wurde seit 2 Tagen gar nicht mehr
>> abgefragt. Scheinbar ist alles okay.

Das verstehe ich irgendwie nicht - dass der seit 2 Tagen nicht mehr abgefragt
wurde. Asterisk fragt bei mir für jede Aktion sowohl NAPTR als auch SRV-Eintrag
ab. Sieht man schön im journal log der Bind RPZ. Irgendwie läuft da was noch schräg.

>>
>> Tim
>>
>
>
> Aber zu früh gefreut. Die Anmeldungen von Asterisk wurden alle rejected:
> res_pjsip_outbound_registration.c: Fatal response '400' received from
> 'sip:tel.t-online.de' on registration attempt to
> 'sip:+49123...@tel.t-online.de:5060', stopping outbound registration

Das ist "bad request" - offensichtlich ist der Server als Solcher ja noch da -
sonst würde er ja nicht mehr antworten.

Lässt Du einen SIP-Trace mitlaufen, damit Du sehen kannst, was Du hingeschickt
hast und was den 400 provoziert hat? Den SIP-Trace kannst Du entweder außerhalb
von Asterisk machen mit einem Tool oder innerhalb wie folgt (mit der Asterisk CLI):

asterisk -x "pjsip set logger on"
asterisk -x "pjsip set logger verbose off"
asterisk -x "pjsip set logger pcap trace.pcap"

Die Logs erscheinen dann im trace.pcap (was z.B. in /var/lib/asterisk/ liegen könnte).


Aber ja: Man sollte an dieser Stelle das Asterisk Log mitlesen und auf bestimmte
(Register-)Fehler reagieren und eine dedizierte RPZ im Bind entsprechend anpassen,
d.h. den existenten Server durch einen anderen aus der Originalliste ersetzen und
dann einen reRegister anstoßen (das geht von außen auch).

Mache ich derzeit auch noch nicht - was daran liegt, dass ich seit Jahren bisher
noch auf keine ernsthaften Probleme gestoßen bin, die auf die Telekom
zurückzuführen gewesen wären.


Gruß
Andreas

Tim Ritberg

unread,
Feb 21, 2021, 5:06:46 AM2/21/21
to
Am 21.02.21 um 08:45 schrieb Andreas Hartmann:

>
> Das verstehe ich irgendwie nicht - dass der seit 2 Tagen nicht mehr
> abgefragt wurde. Asterisk fragt bei mir für jede Aktion sowohl NAPTR als
> auch SRV-Eintrag ab. Sieht man schön im journal log der Bind RPZ.
> Irgendwie läuft da was noch schräg.

Aktion ist gut ;-)
Ich telefoniere darüber nicht. Ich benutze Asterisk nur als Anrufmonitor.



> Das ist "bad request" - offensichtlich ist der Server als Solcher ja
> noch da - sonst würde er ja nicht mehr antworten.
Das funktioniert jetzt auch wieder, hatte das lr vergessen.
Jetzt holt er sich etwa alle 30 min. den A-Record. SRV und NAPTR sehe
ich etwa alle 10 Min.

Tim




0 new messages