nonce Wert nicht beachtet

[timmbo]

Hallo.


Gestern kam es bei einer Anlage vor, das ein Register-Request gesendet wurde, der Provider mit dem nonce Wert geatwortet hatte, die 3CX aber dann nicht die erneute Anfrage mit md5 summe sendete.
Das ging etwa 3-4 Stunden so und plòtzlich war das System wieder registriert.

Ist das schonmal bei Jemanden vorgekommen?

 

[fxbastler]

Das ist mir noch nie irgendwo aufgefallen.

Das heißt, nach dem 407 proxy auth required kommt gar nichts nichts mehr von der 3CX? Die Sequenz bleibt vollkommen stehen / endet und fängt dann später (nach rereg time oder sofort?) wieder komplett von vorn an? Was für en Provider und was für ein Template? Hast du das mitgeschnitten?

 

[timmbo]

Nein, die 3CX sendet dauernd das erste Register Request.
Im dump steht auf Resent packet=77(Beispiel), die Zahl erhòht sich immer um eins.
Vom Provider kommt dann Unauthorized zurùck, was ja beim ersten mal normal ist.
Die anderen Anlagen im Rechenzentrum haben alle normal funktioniert, mit dem gleichen Provider.

 

[fxbastler]

Nein, die 3CX sendet dauernd das erste Register Request.
Im dump steht auf Resent packet=77(Beispiel), die Zahl erhòht sich immer um eins.
Vom Provider kommt dann Unauthorized zurùck, was ja beim ersten mal normal ist.
Die anderen Anlagen im Rechenzentrum haben alle normal funktioniert, mit dem gleichen Provider.

Was für en Provider und was für ein Template?

Ich könnte mir nur vorstellen, dass das Format im 407 nicht richtig ist.

 

[timmbo]

Dann hàtte das ja bei Allen nicht funktionieren dùrfen.
Provider ist nemox.net
Der funktioniert ja seit eh und je.

 

[timmbo]

Habe mit dem Provider gemeinsam darùber gesprochen, er sagt auch die 3CX hat auf den NONCE Rùckwert nicht reagiert oder ihn(System) nicht bekommen.
Das pcap ist ja auf der Netzwerkebene.
Die Frage die sich mit stellt, vielleicht hat das ja jemand schon beobachtet, wenn eine IP in der 3CX geblockt wird, ob der dann beim pcap File trotzdem zu sehen ist, oder eben nicht.

Update:

Ich habe den Grund wohl gefunden, die interne 3CX Firewall hat die IP des Providers geblockt, denn seit 20.05. 10:54 waren keine externen Gespràche mehr vorhanden, erst am 21.5. um 10:55 waren wieder welche in den CDRs sehen, das ist ein grosses Indiz, das die 3CX die Provider IP geblockt hat.

 

[timmbo]

Update2:

Eingehende Anrufe auf Durchwahlen die es nicht gibt, werden als nicht identifiezierter Call erkannt und werden "gezàhlt", kommt man dann nach einer bestimmten Anzahl auf die Blacklist. Leider ist es wohl nicht mehr mòglich ein * am Ende zu setzen, sozusagen als Catch-All.

 

[fxbastler]

Eingehende Anrufe auf Durchwahlen die es nicht gibt, werden als nicht identifiezierter Call erkannt und werden "gezàhlt", kommt man dann nach einer bestimmten Anzahl auf die Blacklist.

Das kann ich so nicht bestätigen. Wir haben Anlagen in denen nur wenige DID eingepflegt sind. Der gesamte Rest - und das passiert dort sehr häufig - geht bewusst auf die Standard Route des SIP Trunk. Solche Probleme hatten wir noch nie.

Leider ist es wohl nicht mehr mòglich ein * am Ende zu setzen, sozusagen als Catch-All.

Das geht noch immer. Das ist abhängig vom Template. Aber so wie du das verwenden willst bringt das nichts, schon ganz lange nicht mehr. Wenn überhaupt, dann wird das * nur zu Anfang der DID ausgewertet. Eines am Ende wird ignoriert bzw. als Teil der zu matchenden Nummer (und nicht als Wildcard) angesehen und so eine DID trifft damit nie. Dafür gibt es ja die Standard Route.

 

[fxbastler]

Die Frage die sich mit stellt, vielleicht hat das ja jemand schon beobachtet, wenn eine IP in der 3CX geblockt wird, ob der dann beim pcap File trotzdem zu sehen ist, oder eben nicht.

Das kann man ja bei Interesse selber nachstellen

 

[timmbo]

Komisch, die Standardroute ist gesetzt.
Ja, das pcap wird VOR dem Filter abgegriffen.
OK, dann wurde das(*) wohl mal geàndert.
Das SIP Invite und das To-Feld gehen beide an die Rufnummer mit Durchwahl @IP-der-3CX.(Kein NAT vorhanden)
Ist interessant warum es nicht zum Provider gehòrend erkannt wird und die Standardroute greift.
PAI usw. werden nicht gesendet.

 

[fxbastler]

Komisch, die Standardroute ist gesetzt.

Dann wird die wohl auch genutzt werden. Du beschreibst weiter oben, dass dann der Zähler für IP Blockierungen genutzt wird - das ist mir völlig unklar.

Ja, das pcap wird VOR dem Filter abgegriffen.

Vor welchem Filter? Wenn du in der 3CX einen Mitschnitt erzeugst, dann wird der immer an der NIC abgegriffen. Das ist (eingehend) vor allem anderen was da kommen könnte.

OK, dann wurde das(*) wohl mal geàndert.

Daran kann ich mich schon nicht erinnern. Soweit ich weiß 'ging das noch nie' (ein * in einer DID irgendwo anders außer eines vorn an erster Stelle). Macht auch logisch nicht unbedingt Sinn. Ich habe gerade in den noch vorh. orig. 3CX v18 Unterlagen von vor über 4 Jahren geschaut. Auch da steht das nicht drin.

Das SIP Invite und das To-Feld gehen beide an die Rufnummer mit Durchwahl @IP-der-3CX.(Kein NAT vorhanden)
Ist interessant warum es nicht zum Provider gehòrend erkannt wird und die Standardroute greift.

Dann Protokollierung hochschrauben, probieren, Log kontrollieren. Evtl. an den SIP Trunk Einstellungen drehen, da gibt es Möglichkeiten bei der Erkennung. Das geht auch ohne Neueinbindung des Trunk, z.B. per API und Powershell.

Nach wie vor die Frage: Was für ein SIP Trunk Template wird verwendet? Original 3CX ist das eher nicht, richtig?

 

[timmbo]

Template ist der von der IKB/nemox, der war mal dabei.
Der wurde aber fùr v20 abgeàndert.
Schaut jetzt so aus:

<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<doc xmlns:tcx="http://www.3cx.com">
<header>
<type>gateway-template</type>
<version>202404</version>
<time>2023-01-24 12:00:00</time>
<name>Nemox Net</name>
<url>https://www.3cx.com/partners/sip-trunks/</url>
<image></image>
<description>AT</description>
<priority>1</priority>
<templatetype>dedicated</templatetype>
</header>
<data>
<device>
<type>provider</type>
<manufacturer></manufacturer>
<model>Provider</model>
<!-- Friendly Name -->
<field name="Name">Nemox Net</field>
<field name="RegistrarHost">sip.nemox.net</field>
<field name="RegistrarPort">5060</field>
<field name="ProxyHost"></field>
<field name="ProxyPort">0</field>
<field name="SecondaryRegistrar"></field>
<field name="IPRestriction">IPV4</field>
<field name="TransportRestriction">UDP</field>
<field name="RequireAuthFor">4</field>
<field name="IpInContactReg">1</field>
<field name="IpInContactRegValue"></field>
<field name="TimeBetweenRegistration">60</field>
<field name="RegistrarInvite">1</field>
<field name="IsSupportReinvite">0</field>
<field name="IsSupportReplaces">0</field>
<field name="DisableVideo">1</field>
<field name="SecureRTP">0</field>
<field name="IsBindToMS">1</field>
<codecs>
<codec rfcname="pcma" />
</codecs>
<field name="ParameterIn" custom="" parameter="FromUserPart">$CallerNum</field>
<field name="ParameterIn" custom="" parameter="FromDisplayName">$CallerName</field>
<field name="ParameterIn" custom="" parameter="RequestLineURIUser">$CalledNum</field>
<field name="ParameterOut" custom="" parameter="RequestLineURIUser">$CalledNum</field>
<field name="ParameterOut" custom="" parameter="RequestLineURIHost">$GWHostPort</field>
<field name="ParameterOut" custom="" parameter="ContactUser">$OutboundCallerId</field>
<field name="ParameterOut" custom="" parameter="ContactHost">$ContactUri</field>
<field name="ParameterOut" custom="" parameter="ToDisplayName">$CalledName</field>
<field name="ParameterOut" custom="" parameter="ToUserPart">$CalledNum</field>
<field name="ParameterOut" custom="" parameter="ToHostPart">$GWHostPort</field>
<field name="ParameterOut" custom="" parameter="FromDisplayName">$CallerName</field>
<field name="ParameterOut" custom="" parameter="FromUserPart">$OriginatorCallerId</field>
<field name="ParameterOut" custom="" parameter="FromHostPart">$GWHostPort</field>
</device>
</data>
</doc>

 

[fxbastler]

^lässt sich schonmal nicht importieren ...