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
) kann man tatsächlich Reifen bei einem anderen Anbieter als bei Porsche kaufen, solange sie den Schnittstellenspezifikationen/Vorgaben entsprechen und ja, sie passen auch 100 prozentig weil sich auch Porsche an die Schnittstellenbedingungen hält. Das Gleiche gilt übrigens auch für andere Zubehörteile die teilweise höherwertiger als das Original sind.
