[PROBLEM] Sipgate mit veralteter Serverkonfiguration?!

[der_Gersthofer]

Sipgate scheint, wie noch bis vor einiger Zeit auch Nikotel, mit einer veralteten Serverkonfiguration die wohl nicht RFC entspricht zu arbeiten.

Disable username encoding (registrations) muss aktiviert werden an entsprechenden SIP Registrierungsservern wie dem IX67 Router, sonst gehen kostenpflichtige ausgehende Gespräche nicht.

Nikotel hatte dieses Problem ursprünglich auch, hat dies aber schon vor Wochen gefixt...

2. Do you have the CLID (caller ID) in your device activated and containing your SIP ID? If caller ID isn't activated, calls to pstn lines will not go through. On the Grandstream devices, this can be found at the bottom (version 5.16) of the configuration page.

Der Unterschied im Sip-Protokoll ist in der Contact-Zeile, wo in der funktionierenden Variante "sipgateID@meineIP;line=hash" steht, in der abgewiesenen "hash@meineIP".

(hash ist irgendein kryptischer Schlüssel, der die Verbindung identifiziert, sipgateID ist meine ID, die ich als Nutzer-Kennung in der Konfig eintragen muß)

Eingehende Gespräche und kostenlose Gespräche funktionieren dagegen in beiden Varianten einwandfrei!

 

[betateilchen]

Aber eigentlich ist das doch nicht wirklich neu ? Aus diesem Grund gibt es doch schon seit Anbeginn der VoIP-Tage die Option "User ID is phone number: No Yes" (zumindest bei Grandstream-Geräten heißt die so).

Ob das Ganze was mit "veralteter" Technik zu tun hat, wage ich zu bezweifeln - ich halte das eher für eine "Einstellungssache" des VoIP Servers.

 

[der_Gersthofer]

Intertex schrieb mir damals (weil Nikotel genau dieses Problem hatte), dass dies nicht den RFC-Regelungen entsprechen würde.
Die Folge ist:
[email protected] ist etwas anderes als
[email protected]

Wenn nun der Nutzername nicht codiert wird, dann klingeln bei eingehenden Anrufen im Netzwerk alle Geräte mit markus und nicht nur die mit [email protected]

 

[der_Gersthofer]

Ach, und ein weiteres Problem hat sich ergeben (wohl daraus?):

Anrufe ins Mobilfunknetz sind nicht möglich:
JUN 09 06:53:22 t2 info send sf 192.168.0.121: SIP/2.0 407 Proxy Authentication Required
JUN 09 06:53:22 tSip info recv 192.168.0.121: SIP/2.0 482 Loop Detected
JUN 09 06:53:22 t1 info send sf 217.10.79.9: SIP/2.0 482 Loop Detected
JUN 09 06:53:22 tSip info recv 217.10.79.9: SIP/2.0 405 Method Not Allowed
JUN 09 06:53:22 t2 info send sf 192.168.0.121: SIP/2.0 405 Method Not Allowed


Auf der UK-Seite von Sipgate findet man immerhin, dass man die Funktion ausschalten muss
http://www.sipgate.co.uk/faq/index.php?aktion=artikel&type=faq&rubrik=688&id=391&lang=de
Warum
a) nicht auch auf den deutschen Seiten
b) wird das nicht einfach ordnungsgemäß implementiert?

 

[der_Gersthofer]

Nachdem das Problem immer noch besteht. Intertex schrieb mir:

To be able to differentiate between two users with same username, for example [email protected] and [email protected], this unit encodes the registration information (Contact header field) to make the registration unique (e.g. sip:[email protected]). However, some SIP servers seem to implement the SIP standard poorly in that they don't copy the exact information from the Contact URI of the REGISTER to the request-URI of the incoming INVITE message.

 

[invite]

hm, vielleicht sollte sich intertex einmal mit sipgate in verbindung setzten.

 

[der_Gersthofer]

Na ja, es ist ja kein Intertex Problem da man das auch ausschalten kann (was aber nicht sinnvoll ist, gerade wenn man Accounts bei mehreren Providern hat alle mit der selben ID).
Sipgate müsste aber eben die exakte Information der Contact URI der REGISTER Meldung in die request-RI der eingehende INVITE Meldung kopieren - und das machen sie offensichtlich nicht, was aber eben nicht dem SIP Standard entspricht.