Hallo zusammen,
ich habe mir jetzt in einer ausführlichen Testsitzung die ganze Geschichte auch mal angeschaut. Um es vorweg zu nehmen, die Umsetzung ist halbherzig und taugt nichts. Das Problem ist damit definitiv nicht vom Tisch, sondern wird nur noch undurchsichtiger.
Testumgebung: LANCOM 1722, Gigaset S685 IP (jeweils aktuellste Firmware), 2 sipgate-basic-Accounts, davon der rufende mit zusätzlichen portierten Rufnummern.
Bei einem Anruf von von einem sipgate-Kunden zu einem sipgate-Kunden (der Anrufer ruft die normale Festnetznummer, nicht die SIP-ID), hat sich schlicht fast nichts geändert, außer dass folgende Zeile in der Invite-Nachricht auftaucht:
P-Asserted-Identity: <sip:
[email protected]>\r\n
Nun hängt es also vom Endgerät ab, ob dieses Feld beachtet wird, oder aber nicht. Das wurde hier im Forum durch einige ja auch schon so festgestellt. Bei mir ignoriert der LANCOM-Router diese Zeile und gibt sie auch nicht an das Gigaset weiter, folglich hat das Ganze bei mir zu keiner Problemlösung beigetragen. Die ganze Geschichte über das P-Asserted-Identity zu regeln finde ich ehrlich gesagt in dem VoIP-Chaos zwischen Display-Name, Number/Name (= SIP-ID) und des allgemein nicht definierten Formats der Rufnummernübertragung schon etwas unverschämt. Damit wälzt man schön die Pflicht der korrekten Rufnummernanzeige auf die Gerätehersteller und die widersprüchlich auszulegenden RFCs ab und entzieht sich in diesem Dickicht den echten Forderungen der Bundesnetzagentur.
Dazu kommt noch, dass die in diesem Feld übermittelte Rufnummer leider willkürlich gewählt wird, d. h. aus den zur Verfügung stehenden Rufnummern des Accounts wird einfach eine genommen. Obwohl in dem Account "Absenderrufnummer setzen" auf "setzt das Endgerät" konfiguriert ist, scheint das völlig ignoriert zu werden. Das Endgerät setzt völlig korrekt die zu übermittelnde Rufnummer aus dem Pool der portierten Rufnummern (die also wirklich zu dem sipgate-Account gehören, also keine beliebigen!), das funktioniert bei Anrufen ins Festnetz ja auch wunderbar, allerdings wird nun bei einem Anruf zu einem sipgate-Kunden nicht die korrekte/gewünschte Rufnummer übermittelt. Und ein Rückruf landet dann natürlich am falschen Telefon. Wenn man es genau betrachtet, werden bei diesem Anruf drei Rufnummern übermittelt: Im Display-Namen die selbst gesetzte korrekte Festnetznummer (Fritz!Boxen können diesen ja leider immer noch nicht anzeigen), die sipgate-SIP-ID und die Rufnummer im P-Asserted-Identity-Feld, die einer weiteren Festnetznummer entspricht. Welcher Otto-Normalverbraucher soll da noch durchsteigen bitte?
Somit muss man als sipgate-Kunde bei Anrufen an andere sipgate-Kunden (oft weiß man ja gar nicht, ob derjenige, den man anruft, Kunde bei sipgate ist) damit rechnen, dass die Rufnummer also nicht korrekt angezeigt wird und eine Identifizierung/ein Rückruf somit nicht möglich ist. Das Verhalten bei sipgate-Team ist definitiv ein anderes, da werden wirklich die korrekten Rufnummern übermittelt.
Umgekehrt muss man als sipgate-Kunde beachten, dass man möglicherweise (durch Rückruf) auf die SIP-ID zurückgerufen wird. D. h. (insbesondere für alle Asterisk- und LANCOM-Fans) bei Filterung/Zuordnung über die "To:"-Zeile (Gateway-Modus) ist sicherzustellen, dass also auch die SIP-ID gerufen werden kann.
Viele Grüße,
Jirka