[Problem] FritzBox 7490 "hinter" SpeedPort Hybrid für Telefonie: Registrierung OK, Anrufsignalisierung OK, kein Audio in beide Richtungen

[LaCruz]

Guten Tag,

ich hab eine 7490 hinter dem Speedport Hybrid (SPH) am Start. Die Rufnummern registrieren sich und Rufaufbau funktioniert. Jedoch kein Audio?!
Welch Ports fehlen hier auf der SPH? Hab eschon die ganze 7490 auf DSL gesetzt.
STUN wurde auch in 7490 gesetzt und Anleitung https://lubensky.de/hybrid/ beachtet.

Jemand eine Idee?

Gruß
LaCruz

 

[koyaanisqatsi]

Moinsen


Für STUN Nutzung braucht es keine Portfreigaben/Portweiterleitungen.
Was sagt denn das "SIP invite Log" (In den erweiterten Support Daten) der 7490 dazu?

 

[LaCruz]

SIP INVITE log
----------
2020-12-20 11:17:14.630 - IN: my=192.168.0.10%14:5060 peer=217.0.21.2 port=5060 UDP, sipiface=none:
INVITE sip:[email protected];transport=udp 2.0
Via: SIP/2.0/UDP 217.0.21.2:5060;branch=z9hG4bKg3Zqkv7i43243ygjsuivgl5fcd23z8u3
Record-Route: <sip:217.0.21.2;transport=udp;lr>
From: <sip:[email protected];user=phone>;tag=h7g4Esbg_p65553t1634232m535888c1089557884s1_2772126789-2045011058
To: <sip:[email protected];user=phone>
Call-ID: p65553t1888843243m535654c1089557884s2
CSeq: 1 INVITE
Contact: <sip:[email protected];transport=udp>;video;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"
Max-forwards: 58
accept-contact: *;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"
Min-se: 900
P-asserted-identity: <sip:[email protected];user=phone>
P-asserted-identity: <tel:+49XXXXXXXX>
Session-expires: 1800
Supported: timer
Session-id: 84f12c409a7434235a608a2f9e0129681
Allow: REGISTER,  REFER,  NOTIFY,  SUBSCRIBE,  PUBLISH,  UPDATE,  INFO,  INVITE,  ACK,  OPTIONS,  CANCEL,  BYE
Content-Type: application/sdp
Accept: application/3gpp-ims+xml, application/sdp
Content-Length:   754

v=0
o=- 1076964935 2772126555 IN IP4 192.168.0.1
s=sip call
c=IN IP4 192.168.0.1
b=RR:3000
b=RS:1000
b=AS:80
t=0 0
m=audio 7070 RTP/AVP 112 116 9 118 8 0 110 111
b=RR:3000
b=RS:1000
b=AS:80
a=sendrecv
a=ptime:20
a=maxptime:240
a=msi:mavodi-0-1[email protected]10.137.201.12-10.137.207.3&&UAGBER04-203
a=rtpmap:112 EVS/16000
a=fmtp:112 br=5.9-24.4;bw=nb-swb;max-red=0
a=rtpmap:116 AMR-WB/16000/1
a=fmtp:116 mode-change-capability=2;max-red=220
a=rtpmap:9 G722/8000
a=rtpmap:118 AMR/8000/1
a=fmtp:118 mode-change-capability=2;max-red=220
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:110 telephone-event/8000
a=fmtp:110 0-15
a=rtpmap:111 telephone-event/16000
a=fmtp:111 0-15

SPH - 192.168.0.1
FB7490 - 192.168.0.10

 

[koyaanisqatsi]

Hm, etwas wirr, find ich.
Wegen 2x P_Asserted_Identity, der Letzte wird wahrscheinlich zur Gültigen deklariert/ausgewertet und der hat keine IP.
Dann im SDP, in c=IN IP4 192.168.0.1 sollte m.E. keine private IP auftauchen.
...und User-Agent: fehlt komplett, danach guck ich immer als Erstes, weil dort der "Verursacher" drinne steht.

Da stimmt also ne Menge nicht und ich würde es mal mit einen anderen STUN Server probieren.
Der ist beliebig wählbar, ähnlich den DNS Servern, also nimm mal nen anderen.
Zum Beispiel: stun.ekiga.net:3478 (Standardport 3478 muss nicht angegeben werden)

Also, bei STUN Nutzung wird normalerweise eine sehr hohe Portnummer für SIP genutzt, nicht 5060, die für die Erreichbarkeit (eingehende Anrufe) offengehalten wird.

 

[LaCruz]

Unnötiges Vollzitat von darüber entfernt by stoney

STUN hatte ich stun.t-online.de.
Teste ich morgen mal. Danke schonmal.

 

[LaCruz]

Heute nochmal getestet:

2020-12-21 17:03:39.673 - IN: my=192.168.0.10%14:5060 peer=217.0.21.2 port=5060 UDP, sipiface=none:
INVITE sip:[email protected];user=phone;uniq=84A29B4F70EA14C7758F64635D17C 2.0
Via: SIP/2.0/UDP 217.0.21.2:5060;branch=z9hG4bKg3Zqkv7idjvfvvwtuefzw81cfuswjdl5g
Record-Route: <sip:217.0.21.2;transport=udp;lr>
From: <sip:[email protected];user=phone>;tag=h7g4Esbg_p65553t1608566619m568212c1103739582s1_2582976335-868212715
To: <sip:[email protected];user=phone>
Call-ID: p65553t1608566619m574562c1103739582s2
CSeq: 1 INVITE
Contact: <sip:[email protected];transport=udp>;video;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"
Max-forwards: 58
accept-contact: *;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"
Min-se: 900
P-asserted-identity: <sip:[email protected];user=phone>
P-asserted-identity: <tel:+49XXXXXXXX>
Session-expires: 1800
Supported: timer
Session-id: b5ed8d445c55a83d2f072325464092
Allow: REGISTER,  REFER,  NOTIFY,  SUBSCRIBE,  PUBLISH,  UPDATE,  INFO,  INVITE,  ACK,  OPTIONS,  CANCEL,  BYE
Content-Type: application/sdp
Accept: application/3gpp-ims+xml, application/sdp
Content-Length:   753

v=0
o=- 1306369028 2582976109 IN IP4 192.168.0.1
s=sip call
c=IN IP4 192.168.0.1
b=RR:3000
b=RS:1000
b=AS:80
t=0 0
m=audio 7070 RTP/AVP 112 116 9 118 8 0 110 111
b=RR:3000
b=RS:1000
b=AS:80
a=sendrecv
a=ptime:20
a=maxptime:240
a=msi:mavodi-0-[email protected]10.137.207.12-10.137.201.3&&UAGHTT04-78
a=rtpmap:112 EVS/16000
a=fmtp:112 br=5.9-24.4;bw=nb-swb;max-red=0
a=rtpmap:116 AMR-WB/16000/1
a=fmtp:116 mode-change-capability=2;max-red=220
a=rtpmap:9 G722/8000
a=rtpmap:118 AMR/8000/1
a=fmtp:118 mode-change-capability=2;max-red=220
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:110 telephone-event/8000
a=fmtp:110 0-15
a=rtpmap:111 telephone-event/16000
a=fmtp:111 0-15

Erster Rufaufbau Audio. Zweiter Rufaufbau kein Audio.
:-(

 

[koyaanisqatsi]

Ich seh auch nicht den klitzekleinsten Hinweis, dass da STUN direkt mit...

Contact: <sip:[email protected];transport=udp>;video;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"

...genutzt wird. Und das SDP, sieht eher danach aus, als wenn 192.168.0.1 das managen soll.
Und ja, ich gebs auch zu, dass ich mir auf...

a=msi:mavodi-0-[email protected]10.137.207.12-10.137.201.3&&UAGHTT04-78

...überhaupt keinen Reim machen kann.

P-Asserted-Identity: ist auch noch da, komisch geschrieben ( kleines a und i ) und verwirrt.

 

[LaCruz]

Danke trotzdem... Werd' es wohl mit Doppel NAT nochmal probieren. Wollte gern alles in einem Netz haben...

 

[erik]

Das Problem ist, dass der Sip-Proxy des Speedport Hybrid da drin rumpfuscht. Eine kleine Änderung seitens des Providers (und die Telekom änderte letztens dauernd was) und die Bastelei fängt von vorne an. Deshalb habe ich die Hybridnutzung aufgegeben und nehme den LTE-Zugang nur noch als Backup.

Ob die Telefonie mit dem Hybridrouter selber funktioniert, dafür ist die Telekom ja zuständig und das wird von denen auch unterstützt. Außerdem unterstützen sie noch ihren ISDN-Adapter, will man also sicher gehen muß man den verwenden und die Fritzbox per ISDN anschließen, eine andere Möglichkeit mehrere Telefonnummern hinter dem Speedport abzugreifen gibt es ja nicht. Es ist enttäuschend dass nicht mal der Speedport Pro interne SIP-Telefone und damit die interne Anmeldung einer Fritzbox unterstützt.

 

[ws65]

Eine kleine Änderung seitens des Providers (und die Telekom änderte letztens dauernd was) und die Bastelei fängt von vorne an.

genau diese Problem hatte ich auch!
ist zwar schon etwas länger her, aber ich hatte bei meinem Bruder die Telefonie auch mal mit einer FB 7272 hinter einem Speedport Hybrid eingerichtet.
hat auch mal mehrere Monate funktioniert, aber dann kamen für den Speedport Updates und seit dem funktioniert das nicht mehr zuverlassig!

hab das dann aufgegeben!