Ungefragtes SIP Reinvite durch VCM

[Koppelfeld]

Hallo,
zunächst einmal: Wir sind mit den LANCOM - VoIP - Routern sehr zufrieden. Und immer wieder sagen Kunden, "da haben Sie uns vor zwei Jahren gut beraten - jetzt, wo die Telekom uns das ISDN kündigt, können wir diesen Stamokap-Oligopolisten endlich den Stinkefinger zeigen! ISDN-Kabel 'raus, VoIP - Provider registrieren, keine weitere Änderung der Infrastruktur -- der B/J - Hybrid kommt auch mit Annex J klar.
Hier muß man klar sagen: LANCOM hat auf Qualität gesetzt und das zählt sich jetzt für die Kunden aus!

Nun haben wir aber wieder ein Problem.
Den LANCOM VCM nehme ich in kleinen Installationen gerne als "Steuerbares ALG", denn
- das eingebaute ALG funktioniert nicht (kann auch gar nicht).
- Eine VoIP - Anlage, die von außen erreicht werden soll, braucht eine öffentliche IP-Adresse. Alles andere ist Pfusch und Mist.
- QoS wird vollautomatisch miterledigt.
- Die einzelnen Providerkonten können qua Routing-Tag bestimmten ISPs zugewiesen, daß ist der einzige Weg, einen "Telekom"-Account im Mischbetrieb zu nutzen.
- Ich spare mir eine Menge Ärger, weil der eingesetzte Router magenta-"zertifiziert" ist. Mit diesem albernen Totschlagargument arbeiten nur ausgemachte Schlitzohren, aber es stopft jedem nervigen "Hotliner" das Maul. Dann hat halt die Telekom den Ärger mit der Fehlersuche und ich die Unterhaltung. Unbezahlbar!
- Streßfreie Einrichtung ohne "Wizard", mit der Routing-Tabelle. Was will man mehr?

LANCOM also mit VCM als "man-in-the-middle", habe ich bestimmt 50 x im Einsatz, beschwerdefrei. Bis vor einer Woche.
Weil es sich um einen "Anlagenanschluß" eines sehr, äh, herausgeforderten rosa Providers handelte, sollte es, siehe oben, ein "zertifizierter" Router sein, und da war das Horror-Release 10.0 conditio sine qua non.

Seit ein paar Tagen werden Anrufer mit "IPhones" regelmäßig ca. 1 Sekunde nach Etablierung der RTP-Verbindungen eines eingehenden Rufes getrennt.
Kein Problem mit hochwertigen Telephonen.
Bislang hat mich das nicht gestört, "IPone"-Benutzer unterstütze ich nicht. Da ist Hopfen und Malz verloren.

Bloß: Man kann nicht immer so, wie man will.

Mit vorgehaltener Pistole habe ich nachgeschaut.
Das Bling-Ding aus Cupertino beherrscht seit einem Update wohl Voice-over-LTE und Voice-over-WLAN.

Sofern diese Features aktiviert sind, regt der LANCOM sowohl bei der TAS-Plattform als auch der nachgeschalteten Asterisk an, man möge sich doch bitte direkt verbinden.
Saudumm nur: Die Asterisk hat eine 1918-IP und darf gar nicht nach draußen.

Folge: Der media-Update schlägt fehl, daß Gespräch ist weg.

Vermeidung: Dem LANCOM auf Seiten der SIP - Konfig den Reinvite und Directmedia verbieten. Hat aber subtile Nachteile.

Deshalb meine Frage:
Kann ich dem VCM das Reinvite verbieten, irgendwo in den unendlichen Weiten der Konfiguration ?

[Jirka]

Hallo Koppelfeld,

Bloß: Man kann nicht immer so, wie man will.

wenn ich jetzt nicht mehr einschlafen kann, bist Du schuld! Ich kann fast nicht mehr vor Lachen.

Sofern diese Features aktiviert sind, regt der LANCOM sowohl bei der TAS-Plattform als auch der nachgeschalteten Asterisk an, man möge sich doch bitte direkt verbinden.

Was passiert jetzt genau?! Ich verstehe es nicht.
Normal denke ich ist es so: Das iPhone stellt fest: Es hat WLAN. Das WLAN bietet Internet. Ein (bestimmter?) Telekom-SIP-Server ist erreichbar. Jetzt kommt es, wenn die Features aktiv sind, auf die Idee sich an diesem SIP-Server zu registrieren, damit ein Gespräch, sollte es eingehen oder abgehend aufgebaut werden, statt über Mobilfunk über WLAN realisiert/aufgebaut wird (bessere Qualität, bessere Nutzung der Ressourcen). Dabei geht es aber immer um die Mobilfunknummer des iPhones/der dort integrierten SIM-Karte.
Normal müsste das am VCM vorbeigehen. Tut es das nicht?
Aber was hat das jetzt mit der Asterisk zu tun. Von daher frage ich mich jetzt meinst Du das, oder meinst Du, dass sich das iPhone als SIP-Client an der Asterisk registriert mit interner Nummer und da dann beim Gespräch ein Re-INVITE kommt, aber wieso?!
Hier brauch man erst mal ein SIP-Packet-Trace, damit man hier überhaupt sieht, was hier abgeht. Ich verstehe nämlich nicht, welches Gespräch Du meinst. Und andere vermutlich auch nicht.

Kann ich dem VCM das Reinvite verbieten, irgendwo in den unendlichen Weiten der Konfiguration ?

Nein, ich wüsste nicht.

Viele Grüße,
Jirka

[Koppelfeld]

Was passiert jetzt genau?! Ich verstehe es nicht.

Ein ganz normaler SIP Reinvite.
Der LANCOM sagt zu Provider und Asterisk, "Macht Ihr das 'mal schön untereinander aus, ich bin draußen".

Hier brauch man erst mal ein SIP-Packet-Trace, damit man hier überhaupt sieht, was hier abgeht. Ich verstehe nämlich nicht, welches Gespräch Du meinst. Und andere vermutlich auch nicht.

Darf es auch ein Debug-Log aus der Asterisk-Konsole sein ?

Code: Alles auswählen

    -- Executing [01702297393@chan-dispatcher:3] Dial("SIP/D8400-00040688", "SIP/01702297393@VGW-ESPBS,75") in new stack
  == Using SIP RTP CoS mark 5
    -- Called SIP/01702297393@VGW-ESPBS
    -- SIP/VGW-ESPBS-00040689 is making progress passing it to SIP/D8400-00040688
[Nov 29 12:22:19] NOTICE[37194][C-00014c23]: chan_sip.c:7127 try_suggested_sip_codec: Changing codec to 'alaw' for this call because of ${SIP_CODEC} variable
    -- SIP/VGW-ESPBS-00040689 requested media update control 26, passing it to SIP/D8400-00040688
    -- SIP/VGW-ESPBS-00040689 answered SIP/D8400-00040688
[Nov 29 12:22:25] NOTICE[37194][C-00014c23]: chan_sip.c:7127 try_suggested_sip_codec: Changing codec to 'alaw' for this call because of ${SIP_CODEC} variable
[Nov 29 12:22:25] NOTICE[37194][C-00014c23]: chan_sip.c:7127 try_suggested_sip_codec: Changing codec to 'alaw' for this call because of ${SIP_CODEC} variable
    -- Locally bridging SIP/D8400-00040688 and SIP/VGW-ESPBS-00040689
  == Spawn extension (chan-dispatcher, 01702297393, 3) exited non-zero on 'SIP/D8400-00040688'

[Jirka]

Hallo Koppelfeld,

ich verstehe immer noch nicht, um was für einen Anruf es geht, wie im obigen Posting schon detailliert gefragt. Da nützt einem das Debug-Log auch nichts, denn das geht daraus gar nicht hervor.

Also erstens ist es ein eingehender Anruf oder ein abgehender Anruf (in Bezug zum iPhone).
Und zweitens ist es ein Anruf auf einen/von einem (mehr oder weniger manuell konfigurierten) SIP-Account im iPhone (der sich z. B. an der Asterisk registriert) oder ist es ein Anruf auf den/von dem integrierten SIP-Account der die Alternativverbindung zum Mobilfunk realisiert (SIM-Karten-Rufnummer; Marketing-Bezeichnung "WLAN Call")?

Viele Grüße,
Jirka

[ua]

Hallo Koppelfeld,

also das echte "IPhone WLAN Call" (2-5G) wird Dich hier nicht stören.
Dabei wird ein IKEv2-Tunnel (mittels EAP-SIM) in das Provider-Netz aufgebaut,
siehst Du auch unter

Code: Alles auswählen

/Status/IP-Router/Connection-List

.
Problematischer sind VOIP-Clients (Jabber, Swyx, Unify u.a.) auf den Streichelkisten.

VG aus OBC

Udo

[cpuprofi]

Hallo Koppelfeld,

ich glaube Du mußt (auch wenn Du dazu wenig motiviert bist) mal einen Wireshark-Trace machen und den Rufaufbau beschreiben, damit man Deine Gedankengänge mal nachvollziehen kann...

Grüße
Cpuprofi