Eumex 800V VoIP mit Fritz!Box 7170

[blackmole]

Moin,
ich habe Probleme mit der Eumex 800V.
Mein Setup: Fritz!Box 7170 an DSL, Eumex 800V (FW 2.50) per Ethernet damit verbunden, IP x.100
Die Eumex ist als SIP-Client an der FB eingerichtet, das Registrieren funktioniert auch, aber die Anrufe nicht. Der SIP-Verkehr läuft, wie er laufen sollte, die Eumex antwortet auch korrekt, aber sie verarbeitet es nicht weiter, selbst bei "debug voip" taucht nichts auf.

Hier sind Wireshark-Mitschnitte von der LAN-Schnittstelle der FB:

No.     Time        Source                Destination           Protocol Info
     26 11.037092   fb                    eumex                 SIP/SDP  Request: INVITE sip:[email protected]:5060;line=0C7EFE4A49010010B21BD6CBF8003277, with session description
     27 11.302934   eumex                 fb                    SIP      Status: 180 Ringing
     28 11.311921   fb                    eumex                 SIP      Request: PRACK sip:[email protected]:5060;line=0C7EFE4A49010010B21BD6CBF8003277
     29 11.317245   eumex                 fb                    SIP      Status: 200 OK


     36 24.784699   fb                    eumex                 SIP      Request: CANCEL sip:[email protected]:5060;line=0C7EFE4A49010010B21BD6CBF8003277
     37 24.790175   eumex                 fb                    SIP      Status: 200 OK
     38 24.792065   eumex                 fb                    SIP      Status: 487 Request Cancelled
     39 24.797302   fb                    eumex                 SIP      Request: ACK sip:[email protected]:5060;line=0C7EFE4A49010010B21BD6CBF8003277

Offensichtlich stimmt auf der Ebene alles. Hat jemand eine Idee, wo es bei der Eumex haken könnte?

 

[gandalf94305]

Das könnte ein Codec-Problem sein. Welche Codecs wurden denn ausgehandelt (steht am Anfang des RTP-Stroms bzw. im SIP-Teil)? Gibt es irgendwelche OPTIONS, die die FBF schickt, die von der Eumex nicht erkannt werden... oder umgekehrt?

--gandalf.

 

[blackmole]

Hm das ist ein guter Hinweis. Es wird überhaupt kein Codec ausgehandelt, es fließen auch noch keine RTP-Daten. Ist das denn immer so oder ist das optional schon das Klingeln per RTP zu übertragen?

Hier die vier Pakete mal ausführlich:

INVITE sip:[email protected]:5060;line=28D30A4B49010010A56031B53540866E SIP/2.0
Via: SIP/2.0/UDP 192.168.178.1:5060;branch=z9hG4bK3277EBB2607C37A6
From: <sip:[email protected]>;tag=50A3251C92817B41
To: <sip:[email protected]:5060;line=28D30A4B49010010A56031B53540866E>
Call-ID: [email protected]
CSeq: 135 INVITE
Contact: <sip:[email protected]>
Max-Forwards: 70
Expires: 120
User-Agent: AVM FRITZ!Box Fon WLAN 7170 (UI) 29.04.76 (Jul 13 2009)
Supported: 100rel,replaces,timer
Allow-Events: telephone-event,refer
Allow: INVITE,ACK,OPTIONS,CANCEL,BYE,UPDATE,PRACK,INFO,SUBSCRIBE,NOTIFY,REFER,MESSAGE,PUBLISH
Content-Type: application/sdp
Accept: application/sdp, multipart/mixed
Accept-Encoding: identity
Content-Length:   359

v=0
o=user 9843575 9843575 IN IP4 192.168.178.1
s=call
c=IN IP4 192.168.178.1
t=0 0
m=audio 7078 RTP/AVP 8 0 2 102 100 99 97 101
a=sendrecv
a=rtpmap:2 G726-32/8000
a=rtpmap:102 G726-32/8000
a=rtpmap:100 G726-40/8000
a=rtpmap:99 G726-24/8000
a=rtpmap:97 iLBC/8000
a=fmtp:97 mode=30
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-11
a=rtcp:7079


SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 192.168.178.1:5060;branch=z9hG4bK3277EBB2607C37A6
From: <sip:[email protected]>;tag=50A3251C92817B41
To: <sip:[email protected]:5060;line=28D30A4B49010010A56031B53540866E>;tag=28D30A4B49010010A56031B53540866E
Call-ID: [email protected]
CSeq: 135 INVITE
Contact: <sip:[email protected]:5060;transport=udp;line=28D30A4B49010010A56031B53540866E>;expires=300
Max-Forwards: 70
Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, MESSAGE, SUBSCRIBE, PRACK, REFER
Supported: 100rel, replaces, timer
User-Agent: Eumex 800V 2.50 
Allow-Events: refer, message-summary, dialog
Require: 100rel
RSeq: 1
Content-Length: 0


PRACK sip:[email protected]:5060;line=28D30A4B49010010A56031B53540866E SIP/2.0
Via: SIP/2.0/UDP 192.168.178.1:5060;branch=z9hG4bKEF0B68FE39BAD490
From: <sip:[email protected]>;tag=50A3251C92817B41
To: <sip:[email protected]:5060;line=28D30A4B49010010A56031B53540866E>;tag=28D30A4B49010010A56031B53540866E
Call-ID: [email protected]
CSeq: 136 PRACK
RAck: 1 135 INVITE
Max-Forwards: 70
User-Agent: AVM FRITZ!Box Fon WLAN 7170 (UI) 29.04.76 (Jul 13 2009)
Content-Length: 0


SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.178.1:5060;branch=z9hG4bKEF0B68FE39BAD490
From: <sip:[email protected]>;tag=50A3251C92817B41
To: <sip:[email protected]:5060;line=28D30A4B49010010A56031B53540866E>;tag=28D30A4B49010010A56031B53540866E
Call-ID: [email protected]
CSeq: 136 PRACK
Max-Forwards: 70
Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, MESSAGE, SUBSCRIBE, PRACK, REFER
Supported: 100rel, replaces, timer
User-Agent: Eumex 800V 2.50 
Content-Length: 0

 

[gandalf94305]

Interessanterweise werden hier nur G726 und iLBC Codecs angeboten... Hmm... kein G.711?
Was ist denn in der Anlage an Codecs eingerichtet?

Kannst Du auch mal den passenden RTP-Datenstrom anschauen?

Weiterhin fällt mir auf, daß im Datenverkehr fritz.fonwlan.box steht. Wenn die Eumex das aufzulösen versucht, geht es wahrscheinlich nicht...

--gandalf.

 

[blackmole]

Hm ja der G711 fehlt, ist laut AVM aber in der FB drin und wird auch standardmäßig für die Verbindung mit Sipgate genutzt. Warum sie es hier nicht anbietet ist mir schleierhaft, in der voip.cfg steht auch

audiocodecs = "PCMA", "PCMU", "G726-32", "G726-40", "G726-24";

In der Eumex kann ich leider keine Konfiguration für die Codecs finden. Sie bietet ja auch gar keine Codecs an, gibt aber auch keine Fehlermeldung, dass die Codecs nicht passen würden (es taucht halt gar nichts in irgendwelchen Logs oder unter "debug voip" auf, außer der Registrierung). Wie gesagt, es kommt keine RTP-Verbindung zustande, die Eumex hat ja auch noch gar kein SDP-Paket gesendet, sodass die Fritzbox auch gar nicht wüsste, an welchen Port die Daten geschickt werden sollten und mit welchem Codec.

Die Eumex kann übrigens fritz.fonwlan.box auflösen, habs mit nem Ping getestet. (Als primary DNS ist halt die FB eingetragen)

 

[gandalf94305]

Hmm... dann dürfte das ein Eumex-spezifisches Problemchen sein... mal sehen, ob jemand anderes hier weiter helfen kann.

--gandalf.

 

[pingping]

Hallo zusammen,
viel kann ich da nicht an Tips beisteuern. Das hier:

Interessanterweise werden hier nur G726 und iLBC Codecs angeboten... Hmm... kein G.711?

..kann ich aber nicht nachvollziehen. In der m-line steht doch

m=audio 7078 RTP/AVP 8 0 2 102 100 99 97 101

Also G.711a ( 8 ) und G.711u ( 0 ) sind dabei. Bzgl. der Codecs stellt sich mir da nur die Frage ob in dem geposteten Trace die 200OK abgeschnitten wurde. Da fehlt der komplette SDP.

Gruß pingping

Edit: Spät gesehen. Von der Eumex kommt ja auch keine 200OK auf die Invite. Die im Trace sichtbare 200 OK ist die Antwort auf die Prack

SIP/2.0 200 OK
.....
CSeq: 136 PRACK

Was ist denn da im Trace zwischen Paket 29 und 36?

29 11.317245 eumex fb SIP Status: 200 OK


36 24.784699 fb eumex SIP Request: CANCEL

 

[blackmole]

Hmm... dann dürfte das ein Eumex-spezifisches Problemchen sein... mal sehen, ob jemand anderes hier weiter helfen kann.

Trotzdem danke für die Bemühungen!

Also G.711a ( 8 ) und G.711u ( 0 ) sind dabei.

Hm stimmt, G711 ist dabei, hat nur keine a-line. In den RFC steht a als optional drin, kann das trotzdem ein Problem sein?
Ich habe nichts abgeschnitten, was relevant sein könnte.
Bei Sipgate kommt das SDP mit einer 183 direkt nach der 100, offenbar verzichtet die Eumex darauf schon einen RTP-Stream beim Klingeln aufzubauen.

Was ist denn da im Trace zwischen Paket 29 und 36?

Müssten ARP-Request oder Telnet-Daten oder sowas sein, irgendwas, was nichts mit SIP zu tun hat.

 

[pingping]

Hallo,

Hm stimmt, G711 ist dabei, hat nur keine a-line. In den RFC steht a als optional drin, kann das trotzdem ein Problem sein?

Eigentlich nicht. Es ist gängige Praxis, dass statische Codecs nicht in einer a-line kommentiert werden. Wozu auch, die sind fest vergeben.

Bei Sipgate kommt das SDP mit einer 183 direkt nach der 100

Auch das ist optional und das "Nichtvorhandensein" der 183 dürfte in deinem Fall keine Rolle spielen.

Pakete 30 bis 35:

Müssten ARP-Request oder Telnet-Daten oder sowas sein, irgendwas, was nichts mit SIP zu tun hat.

Dann sind für mich da zwei Dinge die nicht passen könnten:
- Antwortet die Eumex nicht auf die Invite, müsste die FritzBox diese wenigstens wiederholen. SIP-Server tun das für gewöhnlich. Zumindest hab' ich das schon öfters gesehen.
- Die Eumex reagiert nicht auf die Invite. Evtl. ist die durch die Prack irritiert.
Leider kenne ich diese Konstellation nicht, drum wäre alles weitere Spekulation. Evtl. findet sich ja noch jemand der diese Zusammenschaltung besser kennt.

Gruß pingping

 

[blackmole]

Dann sind für mich da zwei Dinge die nicht passen könnten:
- Antwortet die Eumex nicht auf die Invite, müsste die FritzBox diese wenigstens wiederholen. SIP-Server tun das für gewöhnlich. Zumindest hab' ich das schon öfters gesehen.
- Die Eumex reagiert nicht auf die Invite. Evtl. ist die durch die Prack irritiert.

Die 180 ist doch eine Antwort auf das INVITE, so steht's zumindest im CSeq. Die Fritzbox müsste doch mit der 180 zufrieden sein, ich höre es mit dem anrufenden Telefon ja auch klingeln.

Hat jemand mit einer 800V ein funktionierendes VoIP-Setup und könnte den Stream mal dumpen? Würde mir ja schon weiterhelfen, wenn ich wüsste, wie der korrekterweise aussehen würde.

 

[pingping]

Hi,

Hat jemand mit einer 800V ein funktionierendes VoIP-Setup

Jetzt schon Hat mich nun doch auch interessiert.

und könnte den Stream mal dumpen?

done
Anhang anzeigen FBF7170_Eumex800V_ank.Gespr.zip

Nur kann ich dein Problem nicht reproduzieren, bei mir klappt das bestens. Wie es aussieht, liegt es bei dir an der Eumex. Hast du die schon mal in den Auslieferungszustand zurückgesetzt und dann neu konfiguriert?

Gruß pingping

Edit: hier noch die Konfig der Eumex (PW:0000):
Anhang anzeigen Eumex800V.zip
Die Eumex steckt mit LAN4 an der 7170.
IP der Eumex 192.168.178.10, DHCP-Bereich (ein):192.168.178.11 bis.18
Interne Nummer in der 7170 war bei mir 620.

 

[blackmole]

Sorry für die späte Antwort.
Danke für den Dump! Dann sieht das bei mir ja doch ganz normal aus.

In den Auslieferungszustand habe ich sie schon zurückgesetzt, blieb aber alles gleich.
Allerdings frage ich mich momentan, warum ich mich so auf's SIP konzentriert habe, offenbar scheitert es woanders. Denn die Telefone sind generell tot. Dachte vl werden sie durch SIP "aufgeweckt" und bin dann auf das Verhalten gestoßen, dass die Anlage den SIP-Verkehr gar nicht verarbeitet (also beim debug, in der Anrufliste etc) und hab mich dann daran festgebissen :/ Also die Anlage ist nur per Ethernet angeschlossen, hat also kein ISDN. Kann es sein, dass sie deswegen die Telefone einfach deaktiviert, weil sie denkt, ohne ISDN geht eh nichts? Wäre sinnlos, zumindest interne Gespräche müssten ja trotzdem ermöglicht werden, aber ne andere Idee habe ich gerade nicht. Zwei Telefone wurden schon getestet (die sonst auch laufen), aber die 10 und 11 funktionieren nicht. In der mpsDeviceTable steht AdminStatus auch auf enable. Hat jemand eine Idee, wie ich da weiterkommen könnte?