[Sammlung] Funktionseinschränkungen im "neuen" Sipgate Basic

[WrMulf]

Wenn dem so wäre, dann sollten wir unbedingt weiter über die Probleme diskutieren, vielleicht werden sie gelöst?

Ich gehöre zu den glücklichen, die Trunking 2 noch erhalten haben und seit heute habe ich auch eine Rufnummer geschaltet. Manche der Probleme mit der Rufnummerübertragung wurden schon genannt, ich hatte heute folgende Situation:

Ich rufe vom Handy die Trunking-Nummer an und leite den Anruf im Asterisk mit gesetztem "P-Preferred-Identity"-Eintrag sofort weiter an

a) einen Simquadrat-Anschluss
b) einen Sipgate-Basic-Neu-Anschluss
c) einen Sipgate-Basic-Alt-Anschluss (altes Design)

Nur im letzten Fall (c) kommt die Rufnummer des Handys an, die beiden anderen zeigen die Trunk-Rufnummer. Ich hatte ewig den Fall a) getestet und war am Verzweifeln, weil ich den Fehler bei mir gesucht habe. Trunking hat also auch nicht wirklich die Probleme von Basic der anderen Anschlüsse gelöst. Über Sipgate.io kann ich die abgehende Rufnummer von Basic-nach-Simquadrat setzen.

 

[sparkie]

Trunking hat also auch nicht wirklich die Probleme von Basic der anderen Anschlüsse gelöst.

ich habe leider keinen Anschluss mit a) oder b) und kann dein Problem dort deshalb nicht reproduzieren. Dass c) sich wie beschrieben verhaelt (es funktioniert ja wie erwartet) kann ich bestaetigen.

Fall a) und b) ist jedenfalls kein Problem von Trunking (als abgehendem Account). Bei Trunking wird NP und UPN naemlich korrekt uebertragen.

Ich vermute eher, dass Sipgate im Fall a) und b) nur die NP weitervermittelt (warum auch immer). DIe UPN wird unterschlagen. Es ist ein Problem des eingehenden Accounts.

Im Fall c) ist es hingegen genau umgekehrt. Da wird nur die UPN im SIP sichtbar. Die NP wird hingegen verschwiegen. Ich hatte dazu sogar schon mal eine Anfrage laufen. Es hat ohne Angabe von Gruenden geheissen, dass man das nicht fixen koenne. Jedenfalls entspricht das Verhalten c) eher der Erwartung als Fall a) oder b). Zumindest erlaubt es die Anzeige nicht verfizierter Rufnummern auf dem Zielgeraet, wie es in deinem Fall erforderlich ist.

[UPDATE]
habe gerade zufaellig gesehen das Problem ist seit 16. April 2013 offiziell bereits bekannt (hoert sich zumindest sehr aehnlich an)
Passiert ist aber immer noch nix.
Anzeigen der Absenderkennung bei Anrufen aus einem Sipgate Trunk zu Sipgate Team – sipgate Feedback

 

[FSnyder]

Falls es interessiert: Aktuell jetzt ist Trunking 2 wieder kostenlos zu haben.

Grüße
Snyder

 

[rosch]

Hier die Antwort vom Sipgate support zum Thema G.722 im neuen Design - anscheinend hat sich nicht nur das geändert sondern auch der SIP-server:

Von sipgate werden die folgenden Codecs unterstützt:

• G.729 - ~ 12 kbit/s
• G.711 - ~ 100 kbit/s
• GSM - 13 - 20 kbit/s
• G.726 - 16 - 40 kbit/s

Der G.722-Codec wird derzeit offiziell noch nicht unterstützt und ist bisher nur in ganz wenigen Anwendungsszenarien nutzbar - insbesondere in dem Fall, wenn sich zwei SIP-Endgeräte direkt miteinander "unterhalten". Wir werden diesen Codec aber absehbar, womit ein Zeitraum von mehreren Wochen gemeint ist, offiziell unterstützen. Bitte haben Sie hier noch ein wenig Geduld.

 

[SnoopyDog]

Heute hat man meinen Basic Account ebenfalls umgestellt. Erstes Problem: Ich mußte mein Paßwort zurücksetzen, mit dem bisherigen konnte ich mich nicht mehr anmelden. Ich habe ebenfalls den Eindruck, daß da ein komplett neues System parallel zum alten aufgesetzt wurde. Mein Guthaben wurde ja auch von "alt" nach "neu" umgebucht. In der alten Oberfläche habe ich jetzt 0€ und in der neuen Welt gab es eine Gutschrift. Übersichtlicher finde ich die neue Oberfläche nicht unbedingt und wesentlich teurer ist es auch geworden, wenn man wieder "Plus" wie früher buchen möchte.

Zum Thema "HD-Telefonie" und G.722 Codec: Im Jahr 2009 wurde es offiziell mit Pressemitteilung eingeführt:
http://www.ip-phone-forum.de/showthread.php?t=185704

Nachtrag:

Der G.722-Codec wird derzeit offiziell noch nicht unterstützt und ist bisher nur in ganz wenigen Anwendungsszenarien nutzbar

Naja, von dus.net zu einem Vodafone-Handy war es auch schon vor längerer Zeit möglich - ich war damals überrascht, wie gut das klang. Ist also kein spezielles Anwendungszenario.

 

[FSnyder]

Bis vor kurzem war G722 u.a. auch noch zwischen Sipgate-Basic-Teilnehmern möglich und wurde dann einfach deaktiviert.

Grüße
Snyder

 

[tob_]

Ist von der fehlenden Funktion "Absenderufnummer setzt Endgerät" ausschließlich "CLIP No Screening" betroffen (also "fremde" Nummern), oder kann ich am Endgerät (bzw. im Asterisk) auch nicht mehr auswählen, welche meiner eigenen Sipgate-Nummern übertragen werden sollen?

In unserem noch nicht umgestellten Account sind 4 Rufnummern, die der Asterisk aktuell noch als Absenderufnummer setzen kann...

 

[WrMulf]

Du kannst die Rufnummern (auch die eigenen) gar nicht mehr am Endgerät setzen. Da es nur eine SIP-Id gibt, kannst du in der Weboberfläche auch nur eine deiner vier Nummern als abgehende Nummer festlegen (für alle Endgeräte). Ob die 4 Nummern ANKOMMEND noch unterscheidbar sind, kann ich dir gar nicht beantworten, da mein SIP-Account mit mehreren Rufnummern noch nicht umgestellt wurde. Einer, der umgestellt wurde, den habe ich nach Sipgate Trunking portiert, aber da hatte ich nur eine Nummer, da gab es nichts zu unterscheiden.

 

[ilvoip]

Nach meinem Eindruck wurden auch die AGB eingeschränkt. Früher waren IMHO auch bei Flats 2 gleichzeitige Gespräche erlaubt. Inzwischen scheint es bei Flats modern zu werden nur ein gleichzeitiges Gespräch zu erlauben.

 

[sparkie]

"Tausende von Suchdroiden durchkaemmen die ganze Galaxis", hoerte Vader die Stimme Admiral Ozzels am anderen Ende der Bruecke sagen.

"Ich will Beweise, keine Hinweise"

 

[ilvoip]

Bitteschön:


Aus altem Account erkennbare Leistungsbeschreibung 2014:

2.2.1. An einem sipgate Anschluss können bis zu zwei parallele Telekommunikationsverbindungen entgegengenommen und Verbindungen zu anderen sipgate Anschlüssen sowie in das öffentliche Telefonnetz hergestellt werden. Die Durchlasswahrscheinlichkeit für diese Verbindungen liegt bei 97% im Jahresmittel.


Aus neuem Account(über Featurestore erreicht) in der Leistungsbeschreibung der neuen Deutschlandflat:
3.6. Beschränkung der gleichzeitigen Verbindungen über einen VoIP-Anschluss

Die Nutzung der VoIP-Sprachtarife ist beschränkt auf eine Sprachverbindung pro VoIP-Anschluss.

Die Einschränkung wurde erst in den neuen Leistungsbeschreibungen vorgenommen. Vorher gab es wohl keine separate Leistungsbeschreibung der Flat. Es gab auch früher nur eine Europa-Flat und jetzt gibt es 3 Flats.


Vielleicht haben andere Kunden ältere AGB und Leistungsbeschreibung gespeichert und können das bestätigen oder korrigieren.

 

[VoIP-seufz]

So, alle Dinge die genannt wurden und mir selbst aufgefallen sind, habe ich im Eröffnungspost eingetragen, damit es hier als Info übersichtlicher wird.
Die aktuellen und ehemaligen Plus-Kunden wurden nach meinen Infos immer noch nicht umgestellt. Oder kennt jemand solche Fälle?

 

[eisbaerin]

Auch Basic-Kunden wurden noch nicht alle umgestellt.
Eventuell liegt es daran, daß dort eine RUL nach Simquadrat aktiv ist.

 

[Rohrnetzmeister]

Mein Plus Account wurde bisher nicht umgestellt und einer meiner Basic Accounts auch nicht.

 

[WrMulf]

funktioniert denn die Unterscheidung der Rufnummern per SIP_HEADER(To) auch nicht mehr?

Die Antwort auf diese Frage ist mehr oder weniger offen geblieben, ich kann sie nachliefern:

INVITE sip:[email protected]:5060 SIP/2.0
Record-Route: <sip:217.10.79.9;lr;ftag=as10ae3c23>
Record-Route: <sip:172.20.40.7;lr>
Record-Route: <sip:217.10.68.137;lr;ftag=as10ae3c23>
Via: SIP/2.0/UDP 217.10.79.9;branch=z9hG4bKdcfb.76f07ddfee9528d9368d913d82d7e703.0
Via: SIP/2.0/UDP 172.20.40.7;branch=z9hG4bKdcfb.0387bc4537c1700c1b08bbe65d3a1054.0
Via: SIP/2.0/UDP 217.10.68.137;branch=z9hG4bKdcfb.c471fca4e27aee27d946379f75f42f37.0
Via: SIP/2.0/UDP 212.9.44.144:5060;branch=z9hG4bK177e8b8e
Max-Forwards: 67
From: "01577XXXXXXX" <sip:[email protected]>;tag=as10ae3c23
To: <sip:[email protected]>
Contact: <sip:[email protected]:5060>
Call-ID: [email protected]
CSeq: 103 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces
Content-Type: application/sdp
Content-Length: 416

v=0
o=root 1127211556 1127211557 IN IP4 212.9.44.144
s=sipgate VoIP GW
c=IN IP4 217.10.77.242
t=0 0
m=audio 20866 RTP/AVP 8 0 3 97 18 112 101
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:97 iLBC/8000
a=fmtp:97 mode=30
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:112 G726-32/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv
a=rtcp:20867

Es ist KEINE Unterscheidung der Rufnummer mehr über den SIP-Header möglich. Die bisherige P-Asserted-Identity-Methode funktioniert nicht mehr. Meine 10 (11) Rufnummern sind zu einer zusammengeschmolzen.

 

[Daniel308]

Was könnt Ihr als Alternative zu sipgate empfehlen? Was die gemacht haben gefällt mir absolut gar nicht mehr..

 

[sparkie]

Was könnt Ihr als Alternative zu sipgate empfehlen?

die Alternative zu Sipgate ist Sipgate. Steht alles weiter oben im Thread: #52

 

[ilvoip]

Was könnt Ihr als Alternative zu sipgate empfehlen?

Das hängt stets mit den Anforderungen zusammen. Billiger und nach SIP-Standard kann eigentlich jeder andere Anbieter.

 

[Tippfehler]

Nachdem ich das Sipgate-Thema bisher nur am Rande mitbekommen habe, gab es bei einem Belkannten, dem ich vor drei Jahren einen Sipgate-Plus-Tarif mit Europaflat empfohlen hatte seit ein paar Tagen massive Telefonieprobleme.
Es handelt sich um einen Vertrag mit drei Rufnummern und drei Unteraccounts e0, e1 und e2.

Zuerst haben die Telefone meist nur ein mal geklingelt, dann war das Gespräch weg.
Ich habe dann festgestellt, dass sich der Tarif auf Basic geändert hatte und das neue Webmenü war jetzt auch aktiv.
Weil die Zuordnungen nicht funktionierten, habe ich alle gelöscht und neu zugeordnet.
Das Gleiche habe ich auch auf der Fritzbox gemacht.
Jetzt war es so, dass wenn jemand auf der Nummer e0 oder e1 angerufen hatte, es auch auf dem nur bei e2 angemeldeten Gerät geklingelt hat.
In der Anrufliste standen zwei gleichzeitige Anrufe, auf e2 und e0, obwohl nur e0 angerufen wurde. Genau so war es auch, wenn jemand auf e1 angerufen hat, dann wurde auch Anrufe an e1 und e0 angezeigt.
Also nochmal alles gelöscht und die Fritzbox recovert.
Keine Änderung.
Besser wurde es erst, als ich die Registrierung von e0 in der Fritzbox deaktiviert hatte.

Wenn ich wieder alle drei Unteraccounts bei der Fritzbox aktiviere, gibt es wieder ein Durcheinander bei den ankommenden Anrufen.
Eine Unterscheidung der drei Rufnummern ankommend ist so leider nicht mehr möglich und es klingeln Telefone, die nicht mitklingeln sollten.
Das ist immerhin schon besser, als wenn die Telefone nur ein mal klingeln, aber so kann es natürlich nicht bleiben.
Der Bekannte muss deswegen auf den Unteraccount e0 verzichten und die zu e0 gehörende Rufnummer wurde einem anderen Account zugeordnet.
So funktioniert es jetzt.
Sipgate hat zum gemeldeten Fehler nur den Hinweis gegeben, dass wohl die Fritzbox falsch programmiert ist und ich Bilder von der Programmierung schicken soll.
Das ist sie aber sicher nicht, denn es war nicht meine erste Fritzbox, die ich programmiert habe. Vor der Umstellung bei Sipgate lief es ja drei Jahre lang. Das würde auch nicht erklären, warum zwei Anrufe auf unterschiedliche Eingangs-Rufnummern in der Anrufliste stehen.

Außerdem musste ich jetzt zwei mal hintereinander das Sipgate-Kennwort zurückseten, weil ein Anmeldung bei Sipgate nicht mehr möglich war.

Ich werde mit dem Sipgate-Support erstmal keine Brieffreundschaft beginnen, weil der Bekannte mit dieser eingeschränkten Einstellung gut leben kann, aber falls noch jemand so ein Problem hat, helfen ihm meine Erkenntnisse vielleicht weiter.

 

[tob_]

Es ist KEINE Unterscheidung der Rufnummer mehr über den SIP-Header möglich. Die bisherige P-Asserted-Identity-Methode funktioniert nicht mehr. Meine 10 (11) Rufnummern sind zu einer zusammengeschmolzen.

Sehr merkwürdig, bei mir ist das bei dem umgestellten Account noch möglich, über den To-Header - dort steht meine eigene, angewählte Nummer drin:

INVITE sip:[email protected]:5060 SIP/2.0
Record-Route: <sip:217.10.79.9;lr;ftag=as2d408bb9>
Record-Route: <sip:172.20.40.7;lr>
Record-Route: <sip:217.10.68.137;lr;ftag=as2d408bb9>
Via: SIP/2.0/UDP 217.10.79.9;branch=z9hG4bK5c65.f1d2c57dda2c997e799a70163ee5bcdf.0
Via: SIP/2.0/UDP 172.20.40.7;branch=z9hG4bK5c65.ba226c6f3d32ea2124e5f97df8e00f41.0
Via: SIP/2.0/UDP 217.10.68.137;branch=z9hG4bK5c65.1d5f67ab13c0e486ae71c2a79c5511d6.0
Via: SIP/2.0/UDP 217.10.77.45:5060;branch=z9hG4bK0a1bc0ea
Max-Forwards: 67
From: "0177XXXXXXX" <sip:[email protected]>;tag=as2d408bb9
To: <sip:[email protected]>
Contact: <sip:[email protected]:5060>
Call-ID: [email protected]
CSeq: 103 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces
Content-Type: application/sdp
Content-Length: 428

v=0
o=root 2026427659 2026427660 IN IP4 217.10.77.45
s=sipgate VoIP GW
c=IN IP4 217.10.77.45
t=0 0
m=audio 19582 RTP/AVP 8 0 3 97 18 112 101
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:97 iLBC/8000
a=fmtp:97 mode=30
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:112 G726-32/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv

Nur wenn ich über die Sipgate-Web-Gui einen Rückruf auslöse, steht die Sipgate-SIP-ID im To-Header:

To: <sip:[email protected]>

Komisch, dass es da solche Unterschiede gibt?

Solange das so noch geht, kann ich sipgate wenigstens noch für eingehende Telefonate verwenden - ausgehende über FVD oder easybell Business basic. Sobald eingehend auch nicht mehr unterschieden werden kann, gehen die Nummern zu easybell.