crumb.isLink crumb.isFinalCrumb crumb.getClass crumb.css crumb.separatorCss crumb.getCss crumb.finalCrumb crumb.getText crumb.getIsLink crumb.getWrapperCss crumb.type crumb.url crumb.getUrl crumb.getType crumb.hashCode crumb.equals crumb.toString crumb.wrapperCss crumb.text crumb.getSeparatorCss crumb.class
crumb.isLink crumb.isFinalCrumb crumb.getClass crumb.css crumb.separatorCss crumb.getCss crumb.finalCrumb crumb.getText crumb.getIsLink crumb.getWrapperCss crumb.type crumb.url crumb.getUrl crumb.getType crumb.hashCode crumb.equals crumb.toString crumb.wrapperCss crumb.text crumb.getSeparatorCss crumb.class
crumb.isLink crumb.isFinalCrumb crumb.getClass crumb.css crumb.separatorCss crumb.getCss crumb.finalCrumb crumb.getText crumb.getIsLink crumb.getWrapperCss crumb.type crumb.url crumb.getUrl crumb.getType crumb.hashCode crumb.equals crumb.toString crumb.wrapperCss crumb.text crumb.getSeparatorCss crumb.class
crumb.isLink crumb.isFinalCrumb crumb.getClass crumb.css crumb.separatorCss crumb.getCss crumb.finalCrumb crumb.getText crumb.getIsLink crumb.getWrapperCss crumb.type crumb.url crumb.getUrl crumb.getType crumb.hashCode crumb.equals crumb.toString crumb.wrapperCss crumb.text crumb.getSeparatorCss crumb.class
crumb.isLink crumb.isFinalCrumb crumb.getClass crumb.css crumb.separatorCss crumb.getCss crumb.finalCrumb crumb.getText crumb.getIsLink crumb.getWrapperCss crumb.type crumb.url crumb.getUrl crumb.getType crumb.hashCode crumb.equals crumb.toString crumb.wrapperCss crumb.text crumb.getSeparatorCss crumb.class
Wir nutzen seit einigen Tagen den SIP-Trunk im registered mode mit einer Freeswitch PBX.
Soweit läuft alles, Telefonie möglich in beide Richtungen, ABER:
Wenn wir angerufen werden, hört der Anrufer in ca 50% der Fälle kein Freizeichen (SIP early media) sondern einfach nur Stille. Sobald wir den Ruf annehmen, ist eine Verständigung in beide Richtungen möglich.
Da das Freizeichen in unserer Anlage lokal erzeugt wird und während der Rufphase zur Telekom übermittelt wird, scheint das in manchen Fällen von dort nicht an den Anrufer weitergeleitet zu werden. Wir haben nun auch die 1TR118 und 1TR114 studiert und unseren Netzwerkverkehr analysiert, und finden nichts was ungewöhnlich ist.
Der Ablauf ist:
Telekom sendet uns ein INVITE
unsere Anlage sendet ein TRYING, gefolgt von 183 SESSION PROGRESS mit Codec PCMA.
Sodann startet der RTP Stream mit dem Freizeichen von unserer Anlage zur Telekom. Ziel-IP und Port sind korrekt.
Manchmal hört der Anrufer das Freizeichen, manchmal nicht.
Wir führen ca. 200 Testcalls durch und notieren dabei, welcher RTP-Server auf Seite der Telekom beim jeweiligen Call involviert ist, und ob der Anrufer das Freizeichen hören kann.
Ergebnis: wir notieren insgesamt 50 verschiedene IP-Adressen von Media-Servern, die bei den jeweiligen Calls auf Telekom Seite genutzt werden. Dabei stellt sich heraus, daß mit bestimmten Servern die early media Funktion klappt, mit anderen wiederum nicht.
Weitere Test-Anrufe bestätigen, daß es sich eindeutig an der IP-Adresse des Media Servers der Telekom festmachen lässt ob das Rufzeichen für den Anrufer zu hören ist oder nicht.
Beispiele: Alle IPs beginnen mit 217.0.132.x
IPs mit funktionierendem early media : x= 35,37,38,39,40,41,51,52,53,54,55,56,57,100,101,115,118,121
IPs mit nicht funktionierendem early media: x=3,4,5,6,7,8,9,20,22,25,131,133,134,135,136,137,147,149,151,152,165,166,167,168,169,179,180,181,182,183,184
Der Unterschied der beiden genannten Gruppen von Telekom Servern liegt in einem kleinen Detail:
Bei ankommenden Anrufen ist in der INVITE Message der zweiten Gruppe von Servern (nicht funktionierendes Early Media) folgender Header enthalten:
P_Early_Media: supported
Daraus lässt sich schließen, daß auf Telekom Seite verschiedene Konfigurationen bzw. Software-Stände parallel im Einsatz sind, wobei bei ankommenden oder abgehenden Calls zufällig einer von ihnen verwendet wird.
Da wir in unserer Antwort (183 Session Progress) den korrekten Header mitsenden (P_Early_Media: sendonly), und der early media RTP-Stream auch in der geforderten Zeit von <500ms startet an die korrekte IP und Port, fragt sich warum dieser für den Anrufer nicht zu hören ist.
Die weitere Frage ist, warum das Problem sonst niemand hat und ob early media überhaupt von den gängigen SIP-Trunk Anlagen wie Digitalisierungsbox, Agfeo, Elmeg etc verwendet wird oder ob diese Anlagen das gar nicht nutzen und mit einem "180 Ringing" (ohne SDP) das Rufzeichen auf der Gegenseite erzeugen lassen.
Im Anhang noch ein Beispiel-Callflow eines ankommenden Calls, bei dem early media nicht zu hören war, falls jemandem dazu noch was einfällt.
grüße!
MArkus
Ankommender Anruf, Anrufer hört kein early media:
von IP 217.0.26.195.5060 zu IP 80.14*.***.***
INVITE sip:5511**********@80.14*.***.***:5080;transport=tcp;gw=23dbdbf0-4e47-4d65-97d1-f8a5d4ed08c2 SIP/2.0
Via: SIP/2.0/TCP 217.0.26.195:5060;branch=z9hG4bK3749d164071ed210d1fbfb21858f16ac.3647afaa
Record-Route: <sip:reg.sip-trunk.telekom.de;transport=tcp;lr>
Max-Forwards: 53
To: <sip:+49913******@telekom.de;user=phone>
From: <sip:+491708******@sip-trunk.telekom.de;user=phone>;tag=01df7f1f
Call-ID: e2f0ec21012514a2@62.156.102.70
Contact: <sip:maB5kX1xbJMKUIlWFM1kyqLLvRDcv8Pyf0lweyoK/3lQGdS9LWsxx9t5Vhruz/+6@th1>
Supported: histinfo,timer
Session-Expires: 3600;refresher=uac
CSeq: 55638881 INVITE
Allow: ACK, BYE, CANCEL, INFO, INVITE, MESSAGE, NOTIFY, OPTIONS, PUBLISH, REFER, REGISTER, SUBSCRIBE, UPDATE
Min-SE: 900
P-Asserted-Identity: <sip:+49170******8@sip-trunk.telekom.de;user=phone>
P-Called-Party-ID: <sip:+49913******@sip-trunk.telekom.de;user=phone>
P-Early-Media: supported
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 699
v=0
o=- 0 0 IN IP4 217.0.26.195
s=on transit
c=IN IP4 217.0.132.9
t=0 0
m=audio 10656 RTP/AVP 100 101 9 102 103 104 3 8 105 106
b=AS:80
a=rtpmap:100 AMR-WB/16000
a=fmtp:100 mode-set=0,1,2; mode-change-period=2; mode-change-neighbor=1; max-red=0
a=rtpmap:101 AMR-WB/16000
a=fmtp:101 mode-change-capability=2; max-red=0
a=rtpmap:9 G722/8000
a=rtpmap:102 AMR/8000
a=fmtp:102 mode-set=0,2,4,7; mode-change-period=2; mode-change-neighbor=1;
a=rtpmap:103 AMR/8000
a=fmtp:103 mode-change-capability=2; max-red=0
a=rtpmap:104 GSM-EFR/8000
a=rtpmap:3 GSM/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:105 telephone-event/8000
a=rtpmap:106 telephone-event/16000
a=ptime:20
a=maxptime:30
von IP 80.14*.***.*** zu IP 217.0.26.195.5060
.SIP/2.0 100 Trying
Via: SIP/2.0/TCP 217.0.26.195:5060;branch=z9hG4bK3749d164071ed210d1fbfb21858f16ac.3647afaa;rport=5060
From: <sip:+49170******8@sip-trunk.telekom.de;user=phone>;tag=01df7f1f
To: <sip:+49913******@telekom.de;user=phone>
Call-ID: e2f0ec21012514a2@62.156.102.70
CSeq: 55638881 INVITE
User-Agent: FreeSWITCH
Content-Length: 0
von IP 80.14*.***.*** zu IP 217.0.26.195.5060
.SIP/2.0 183 Session Progress
Via: SIP/2.0/TCP 217.0.26.195:5060;branch=z9hG4bK3749d164071ed210d1fbfb21858f16ac.3647afaa;rport=5060
Record-Route: <sip:reg.sip-trunk.telekom.de;transport=tcp;lr>
From: <sip:+49170******8@sip-trunk.telekom.de;user=phone>;tag=01df7f1f
To: <sip:+49913******@telekom.de;user=phone>;tag=0FN3H9ZNF16Xp
Call-ID: e2f0ec21012514a2@62.156.102.70
CSeq: 55638881 INVITE
Contact: <sip:+49913******@80.14*.***.***:5080;transport=tcp>
User-Agent: FreeSWITCH
Accept: application/sdp
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY
Supported: timer, path, replaces
Allow-Events: talk, hold, conference, refer
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 222
P-Early-Media: sendonly
P-Asserted-Identity: "5511**********" <sip:5511**********@telekom.de>
v=0
o=FreeSWITCH 1541419807 1541419808 IN IP4 80.14*.***.***
s=FreeSWITCH
c=IN IP4 80.14*.***.***
t=0 0
m=audio 16600 RTP/AVP 8 105
a=rtpmap:8 PCMA/8000
a=rtpmap:105 telephone-event/8000
a=fmtp:105 0-16
a=ptime:20
Ab hier gingen RTP-Pakete raus an die 217.0.132.9 Port 10656 (Beginn ca 100ms nach dem Invite der Telekom).
von IP 80.14*.***.*** zu IP 217.0.26.195.5060
SIP/2.0 200 OK
Via: SIP/2.0/TCP 217.0.26.195:5060;branch=z9hG4bK3749d164071ed210d1fbfb21858f16ac.3647afaa;rport=5060
Record-Route: <sip:reg.sip-trunk.telekom.de;transport=tcp;lr>
From: <sip:+49170******8@sip-trunk.telekom.de;user=phone>;tag=01df7f1f
To: <sip:+49913******@telekom.de;user=phone>;tag=0FN3H9ZNF16Xp
Call-ID: e2f0ec21012514a2@62.156.102.70
CSeq: 55638881 INVITE
Contact: <sip:+49913******@80.14*.***.***:5080;transport=tcp>
User-Agent: FreeSWITCH
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY
Require: timer
Supported: timer, path, replaces
Allow-Events: talk, hold, conference, refer
Session-Expires: 3600;refresher=uac
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 222
P-Asserted-Identity: "100" <sip:100@telekom.de>
v=0
o=FreeSWITCH 1541419807 1541419808 IN IP4 80.14*.***.***
s=FreeSWITCH
c=IN IP4 80.14*.***.***
t=0 0
m=audio 16600 RTP/AVP 8 105
a=rtpmap:8 PCMA/8000
a=rtpmap:105 telephone-event/8000
a=fmtp:105 0-16
a=ptime:20
06.11.2018 12:45
06.11.2018 12:52
Danke, ich bin gespannt...
08.11.2018 12:33
12.11.2018 16:45
Hmm meine Firma wäre gern ordentlich telefonisch erreichbar, nimmt die Telekom das bei Geschäftskundenanschlüssen richtig ernst oder soll ich wieder auf ISDN umsteigen?
12.11.2018 16:52
12.11.2018 17:21 Zuletzt bearbeitet: 12.11.2018 17:26 durch den Autor
Hallo !?
Punkt 1: Die SipTrunk Schnittstelle ist von der Telekom spezifiziert, wer sagt denn dass ich nur bestimmte Anlagen betreiben kann wenn ich mich an die Spezifikation halte? Ich habe nirgends gelesen daß man nur Anlage x oder y benutzen kann.
Punkt 2: Das Problem tritt auch bei Anlagen auf, die für SipTrunk spezifiziert sind. Es gibt hier Meldungen daß auch Elmeg Anlagen mit bestimmten Softwareständen dieses Verhalten zeigen.
Punkt 3: Nur weil gängige Anlagen kein early media nutzen, muss es dennoch funktionieren wenn es in der Schnittstellen-Doku der Telekom als feature gelistet wird.
Punkt 4: Das Problem tritt abhängig davon auf, welchen Server der Telekom man zugeteilt bekommt, daher ist nicht automatisch von einem Kundenproblem auszugehen (siehe mein Post). Ihre Schlußfolgerung ist daher, sollten Sie es richtig durchgelesen haben, unlogisch.
Punkt 5: Sollte sich die Telekom nach einer Woche doch einmal dazu bewegen lassen sich zu äußern, wenn man eine 8 Stunden Entstörung hat. Aber daß die 8 Stunden eher 8 Wochen sein können hatte ich schon früher bei anderen Telekom Leitungen feststellen müssen...
Punkt 6: Melde dich doch wieder wenn du etwas produktives beitragen kannst. Ich habe ja auch sehr ordentlich mein Problem geschildert mit dem Ziel, für mich und andere eine schnelle Lösung zu finden. Ich erhoffte mir daher Antworten die etwas zur Lösung beitragen.
12.11.2018 17:28
Zu einer möglichen Ursache gab es bei bintec elmeg ein Software Update:
Telefonie – SIP Forking (# 1979): SIP Forking wurde nicht unterstützt,
weshalb es bei ausgehenden Rufen zum Ausbleiben des Ruftons kommen
konnte.
http://faq.bintec-elmeg.com/index.php?title=Sip_Forking
12.11.2018 17:36
es geht hier generell nur um ankommende Anrufe, und es tritt bei Elmeg mit aktueller Software sowie auch bei der Digitalisierungsbox auf, wie ein Kunde berichtet:
Insofern bin ich schon mal gespannt wo da der Fehler liegt. Aber rausfinden können wir das nur wenn die Telekom mithilft.
13.11.2018 13:21 Zuletzt bearbeitet: 13.11.2018 13:22 durch den Autor
Die Telekom hat mich heute angerufen und mitgeteilt, daß man "gerade festgestellt hat", daß es ein Problem beim Sip Trunk gibt mit Early Media. Bestimmte Telekom-Server würden das feature nicht korrekt unterstützen.
Einen Zeitrahmen wusste man nicht, "man arbeitet daran".
13.11.2018 13:31
14.11.2018 11:13
Gibt es zu dem Thema schon Neuigkeiten?
14.11.2018 11:18
14.11.2018 11:21
An wen wende ich mich bezüglich Erstattung der Grundgebühren? Ich habe mittlerweile ca. 20 Stunden in die Fehlersuche investiert und bin seit Umstellung auf den Sip Trunk nicht ordentlich erreichbar, viele Anrufer legen wieder auf wenn sie kein Freizeichen hören.
14.11.2018 12:21
14.11.2018 17:28
Ich habe eben mit dem Telekom Support gesprochen. Da weiß man nichts von einer Störung?
14.11.2018 18:18
Mit dem "support" der Telekom zu sprechen bringt auch nicht immer wirklich viel, in meinem Fall habe ich eine Woche lang gar keine Antwort bekommen und musste dann den Fall hier im Forum posten, damit wenigstens der Fehler schonmal bestätigt wurde. Ohne dieses Forum wäre vermutlich bis heute nichts passiert.
14.11.2018 19:33
Wenn man über ein Mobiltelefon anruft bekommt man ein Rufzeichen, über Festnetz jedoch nicht.
15.11.2018 10:39 Zuletzt bearbeitet: 15.11.2018 10:40 durch den Autor
Moin @Paul Muaddib,
über welchen Weg hast Du denn die Störung gemeldet?
Um einen Blick in Deine Daten zu werfen, bitte ich Dich, Deine Daten im Profil auszufüllen. Anschließend freue ich mich über eine kurze Rückmeldung.
Viele Grüße,
Lin J.
15.11.2018 17:23
15.11.2018 20:57
15.11.2018 23:16
Hallo @markus enz
ich habe das senden von early media bei freeswitch deaktiviert. So wie es aussieht bekomme ich nun wieder ein Freizeichen. Konnte aber noch nicht alles überprüfen. Das war leider nicht so einfach zu finden. Early media wird ausgelöst sobald eins der folgenden Kommandos oder Variablen im dialplan gesetzt wird.
<action application="set" data="ringback=$${de-ring}"/>
<action application="set" data="transfer_ringback=$${hold_music}"/>
<action application="pre_answer"/>
<action application="ring_ready"/>
Trotzdem ist es natürlich etwas unbefriedigend das man im Moment Early Media nicht verwenden kann. Zumal es vor 1 Woche noch funktioniert hat.
16.11.2018 09:42
18.11.2018 17:27
Hallo @Lin J.
da die Telekom Freeswitch nicht supported wird das wenig Sinn machen. Trotzdem vielen Dank für den Anruf. Im Moment komme ich mit meiner Lösung zurecht. Ob das Problem für @markus enz damit gelöst ist, weiß ich nicht. Schließlich war das sein Thread.
Grüße, Paul
19.11.2018 10:26
Auszug aus der Schnittstellenbeschreibung der Telekom zum SIP Trunk 1TR118
2.16 Early Media (üblicher Weise mit 183 eingesetzt)
Early media and the P-Early-Media header must be supported according to 1TR114 [2], otherwise announcements and ringback tones may not work properly. A SIP-PBX which does not support the P-Early-Media header should be able to detect early media and be prepared to generate the ringback tone locally if no early media is received.
Übersetzt:
Early Media und der P-Early-Media-Header müssen gemäß 1TR114 [2] unterstützt werden.
Ansonsten können Ansagen und Rückruftöne möglicherweise nicht ordnungsgemäß funktionieren.
Eine SIP-PBX, die den P-Early-Media-Header nicht unterstützt, sollte in der Lage sein, Early-Media erkennen zu können und
in der Lage sein, den Rückrufton lokal zu generieren, wenn kein Early-Media empfangen wird.
Sie benötigen eine persönliche Kaufberatung? Das Geschäftskundenteam der Telekom berät Sie gerne.
Informieren Sie sich über unsere aktuellen Festnetz- & Internet-Angebote.