Toggle sidebar Toggle sidebar

Eingehende Anrufe brechen ab - nur von 3CX zu 3CX

O

ollibraun

Forum User
Basic Certified
Mitglied seit
16. Oktober 2014
Beiträge
239
Hallo,

ich habe ein snom870-SIP 8.4.31 als Nebenstelle an einer 3CX. Bei eingehenden Anrufen brechen die Gespräche im Moment des Hörerabhebens ab. Dies tritt nur bei einem Kommunikationspartner auf, der ebenfalls eine 3CX einsetzt. VoIP-Provider sind 1&1 und sipbase.

Log - Abbruch ganz am Ende:

10:02:24.263|.Call.cpp(48)|Log5||??:Currently active calls [none]
10:02:37.896|.CallLeg.cpp(124)|Log5||CallLeg::onNewCall:[CM500002]: Info on incoming INVITE:
INVITE sip:[email protected]:5060;rinstance=61e32e19781adaea SIP/2.0
Via: SIP/2.0/UDP 212.227.67.135;branch=z9hG4bK540f.dd25b46c4561ca0791890520322a7d4f.0
Via: SIP/2.0/UDP 212.227.67.228;branch=z9hG4bK540f.6484aa95c88673eefd092abc77d8c076.0
Via: SIP/2.0/UDP 212.227.67.198;branch=z9hG4bK540f.d343410f3cfc1679f14c98f2d33712ce.0
Via: SIP/2.0/UDP 217.188.44.83;branch=z9hG4bK540f.06e93955.0
Via: SIP/2.0/UDP 195.71.188.9:5060;branch=z9hG4bK2mnn660020u0ts4vr6h1.1
Max-Forwards: 11
Record-Route:
Record-Route:
Record-Route:
Contact: "+493088667911"
To: "+493069545132"
From: "+493088667911";tag=1466603508
Call-ID: 477f3d12-5d7a5688-4e1ae2a9-b0de@1und1-5.sip.mgc.voip.telefonica.de
CSeq: 1 INVITE
Session-Expires: 1800
Min-SE: 1800
Allow: INVITE, ACK, PRACK, SUBSCRIBE, BYE, CANCEL, NOTIFY, INFO, REFER, UPDATE
Supported: timer
P-Asserted-Identity: +493088667911
Content-Length: 0


10:02:37.898|.Line.cpp(301)|Log5||LineCfg::getInboundTarget:Looking for inbound target: called=+493069545132; caller=+493088667911
10:02:37.898|.Line.cpp(355)|Log2||LineCfg::getInboundTarget:[CM503012]: Inbound out-of-office hours rule (unnamed) for 10629 forwards to DN:120
10:02:37.951|.CallCtrl.cpp(271)|Log2||CallCtrl::onIncomingCall:[CM503001]: Call(7): Incoming call from +493088667911@(Ln.10629@1+1 Kunden) to
10:02:37.954|.Line.cpp(1441)|Log2||Line::printEndpointInfo:[CM505003]: Provider:[1+1 Kunden] Device info: Device Not Identified: User Agent not matched; Capabilities:[reinvite, replaces, able-no-sdp, recvonly] UserAgent: [] PBX contact: [sip:[email protected]:5060]
10:02:37.955|.CallLeg.cpp(1126)|Log5||CallLeg::setRemoteSdp:Remote SDP is set for legC:7.1
10:02:37.956|.SLServer.cpp(832)|Log5|MediaServer|MediaServerReporting::SetRemoteParty:[MS210000] C:7.1:Offer received. RTP connection: 62.52.146.156:38788(38789)
10:02:37.956|.CallCtrl.cpp(441)|Log3||CallCtrl::onSelectRouteReq:[CM503010]: Making route(s) to
10:02:37.957|.CallCtrl.cpp(606)|Log2||CallCtrl::onSelectRouteReq:[CM503004]: Call(7): Route 1: Ext:Ext.120@[Dev:sip:[email protected]:5488,Dev:sip:[email protected]:3072;line=tj0wkgms,Dev:sip:[email protected]:5060;transport=udp;line=1wzf9f]
10:02:38.004|.SLServer.cpp(832)|Log5|MediaServer|MediaServerReporting::SetRemoteParty:[MS210002] C:7.2:Offer provided. Connection(transcoding mode): 127.0.0.1:7016(7017)
10:02:38.005|.Target.cpp(437)|Log2||Target::makeOneInvite:[CM503025]: Call(7): Calling Ext:Ext.120@[Dev:sip:[email protected]:5488]
10:02:38.010|.SLServer.cpp(832)|Log5|MediaServer|MediaServerReporting::SetRemoteParty:[MS210002] C:7.3:Offer provided. Connection(transcoding mode): 192.168.100.105:7018(7019)
10:02:38.012|.Target.cpp(437)|Log2||Target::makeOneInvite:[CM503025]: Call(7): Calling Ext:Ext.120@[Dev:sip:[email protected]:3072;line=tj0wkgms]
10:02:38.018|.SLServer.cpp(832)|Log5|MediaServer|MediaServerReporting::SetRemoteParty:[MS210002] C:7.4:Offer provided. Connection(transcoding mode): 192.168.100.105:7020(7021)
10:02:38.020|.Target.cpp(437)|Log2||Target::makeOneInvite:[CM503025]: Call(7): Calling Ext:Ext.120@[Dev:sip:[email protected]:5060;transport=udp;line=1wzf9f]
10:02:38.153|.CallLeg.cpp(289)|Log3||CallLeg::onAnswer:[CM503002]: Call(7): Alerting sip:[email protected]:3072;line=tj0wkgms
10:02:38.154|.Extension.cpp(1404)|Log3||Extension::printEndpointInfo:[CM505001]: Ext.120: Device info: Device Identified: [Man: Snom;Mod: 8xx series;Rev: General] Capabilities:[reinvite, replaces, able-no-sdp, recvonly] UserAgent: [snom870/8.4.31] PBX contact: [sip:[email protected]:5060]
10:02:38.192|.CallLeg.cpp(289)|Log3||CallLeg::onAnswer:[CM503002]: Call(7): Alerting sip:[email protected]:5060;transport=udp;line=1wzf9f
10:02:38.192|.Extension.cpp(1404)|Log3||Extension::printEndpointInfo:[CM505001]: Ext.120: Device info: Device Not Identified: User Agent not matched; Capabilities:[reinvite, replaces, able-no-sdp, recvonly] UserAgent: [snom-m9/9.3.9-a] PBX contact: [sip:[email protected]:5060]
10:02:38.207|.CallLeg.cpp(289)|Log3||CallLeg::onAnswer:[CM503002]: Call(7): Alerting sip:[email protected]:5488
10:02:38.207|.Extension.cpp(1404)|Log3||Extension::printEndpointInfo:[CM505001]: Ext.120: Device info: Device Not Identified: User Agent not matched; Capabilities:[reinvite, replaces, able-no-sdp, recvonly] UserAgent: [3CX Dialer for Ext.120] PBX contact: [sip:[email protected]:5060]
10:02:38.407|.CallLeg.cpp(124)|Log5||CallLeg::onNewCall:[CM500002]: Info on incoming INVITE:
INVITE sip:[email protected]:5060;nofwd=1 SIP/2.0
Via: SIP/2.0/UDP 127.0.0.1:5488;branch=z9hG4bK-d8754z-9527994ce119bc5d-1---d8754z-;rport=5488
Max-Forwards: 70
Contact:
To:
From: "+493088667911";tag=8f2f2974
Call-ID: ODg4MTM4Nzk1YmQ3NzIzZDc1ZDQzMDZiY2U4ZGU5NzM.
CSeq: 2 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE
Proxy-Authorization: Digest username="120",realm="3CXPhoneSystem",nonce="414d535c0412329e18:0a5aee51c543fac6d0a5e208579ed565",uri="sip:[email protected]:5060;nofwd=1",response="615ee22c300629b5bd7727afb1b52802",algorithm=MD5
Supported: replaces
User-Agent: 3CX Dialer for Ext.120
Content-Length: 0


10:02:38.412|.CallCtrl.cpp(271)|Log2||CallCtrl::onIncomingCall:[CM503001]: Call(8): Incoming call from Ext.120 to
10:02:38.418|.Extension.cpp(1404)|Log3||Extension::printEndpointInfo:[CM505001]: Ext.120: Device info: Device Not Identified: User Agent not matched; Capabilities:[reinvite, replaces, able-no-sdp, recvonly] UserAgent: [3CX Dialer for Ext.120] PBX contact: [sip:[email protected]:5060]
10:02:38.418|.CallLeg.cpp(1126)|Log5||CallLeg::setRemoteSdp:Remote SDP is set for legC:8.1
10:02:38.420|.SLServer.cpp(832)|Log5|MediaServer|MediaServerReporting::SetRemoteParty:[MS210000] C:8.1:Offer received. RTP connection: 127.0.0.1:32004(32005)
10:02:38.420|.CallCtrl.cpp(441)|Log3||CallCtrl::onSelectRouteReq:[CM503010]: Making route(s) to
10:02:38.421|.CallCtrl.cpp(606)|Log2||CallCtrl::onSelectRouteReq:[CM503004]: Call(8): Route 1: VoIPline:01788442200@(Ln.10629@1+1 Kunden)@[Dev:sip:[email protected]:5060]
10:02:38.514|.SLServer.cpp(832)|Log5|MediaServer|MediaServerReporting::SetRemoteParty:[MS210002] C:8.2:Offer provided. Connection(transcoding mode): 79.194.67.234:9014(9015)
10:02:38.514|.Target.cpp(437)|Log2||Target::makeOneInvite:[CM503025]: Call(8): Calling VoIPline:01788442200@(Ln.10629@1+1 Kunden)@[Dev:sip:[email protected]:5060]
10:02:41.118|.CallLeg.cpp(1126)|Log5||CallLeg::setRemoteSdp:Remote SDP is set for legC:7.3
10:02:41.119|.SLServer.cpp(832)|Log5|MediaServer|MediaServerReporting::SetRemoteParty:[MS210001] C:7.3:Answer received. RTP connection[unsecure]: 192.168.100.220:65072(65073)
10:02:41.121|.SLServer.cpp(832)|Log5|MediaServer|MediaServerReporting::SetRemoteParty:[MS210003] C:7.1:Answer provided. Connection(transcoding mode[unsecure]):79.194.67.234:9012(9013)
10:02:41.124|.CallCtrl.cpp(782)|Log2||CallCtrl::onLegConnected:[CM503007]: Call(7): Device joined: sip:[email protected]:5060
10:02:41.127|.CallCtrl.cpp(782)|Log2||CallCtrl::onLegConnected:[CM503007]: Call(7): Device joined: sip:[email protected]:3072;line=tj0wkgms
10:02:41.228|.CallLeg.cpp(300)|Log2||CallLeg::onFailure:[CM503003]: Call(7): Call to sip:[email protected] has failed; Cause: 487 Request Terminated; from IP:192.168.100.230:5060
10:02:41.322|.CallLeg.cpp(300)|Log2||CallLeg::onFailure:[CM503003]: Call(7): Call to sip:[email protected] has failed; Cause: 487 Request Terminated; from IP:127.0.0.1:5488
10:02:41.337|.Call.cpp(1293)|Log2||Call::Terminate:[CM503008]: Call(8): Call is terminated
10:02:41.338|.CallLeg.cpp(564)|Log5||CallLeg::onConfirmed:Session 16400 of leg C:7.1 is confirmed
10:02:41.403|.CallLeg.cpp(1126)|Log5||CallLeg::setRemoteSdp:Remote SDP is set for legC:7.1
10:02:41.404|.SLServer.cpp(832)|Log5|MediaServer|MediaServerReporting::SetRemoteParty:[MS210000] C:7.1:Offer received. RTP connection: 62.52.146.156:38788(38789)
10:02:41.405|.SLServer.cpp(832)|Log5|MediaServer|MediaServerReporting::SetRemoteParty:[MS210002] C:7.3:Offer provided. Connection(transcoding mode): 192.168.100.105:7018(7019)
10:02:41.466|.Call.cpp(1293)|Log2||Call::Terminate:[CM503008]: Call(7): Call is terminated
10:02:42.850|.SLServer.cpp(800)|Error1|MediaServer|MediaServerReporting::RTPReceiver:[MS105000] C:7.1: No RTP packets were received:remoteAddr=62.52.146.156:38788,extAddr=79.194.67.234:9012,localAddr=79.194.67.234:9012
 
naja, beide anlagen wissen dann nicht mehr das die andere 3CX ist wenn es via 1und1 bzw sipgate geht.
Anyway, mache einmal ein Wireshark Pcap davon auf deinem Server, dann sehen wir weiter...
https://www.3cx.de/blog/wireshark-aufzeichnungen/
 
Sorry, Stefan, geklärt: Es gab ein snom 870 und ein snom m9, beide mit der gleichen Identität an der 3CX. Dies führte dazu, dass eingehende Gespräche sofort abbrachen - allerdings nur von einer anderen 3CX aus, bei allen anderen eingehenden Anrufen gab es kein Problem. Netzwerkkabel m9 gezogen - Gespräche brechen nicht mehr ab.
 
Vielleicht war hier DND auf dem m9 aktiv.
 
@matictec wrote:Vielleicht war hier DND auf dem m9 aktiv.
Na ja, seit Inbetriebnahme vor sechs Wochen sind alle Anrufe dieses Kommunikationspartners beim Abheben des Hörers abgebrochen. Geschätze 300 eingehende Anrufe anderer Anrufer konnte ich dagegen annehmen.
 
erstelle mal ein Pcap auf beiden 3CX Servern von so einen anruf und poste es
 
Welche Firmware läuft auf den m9. Da hat sich vieles getan. Einiges ist aber auch noch offen.
 
Es ist die aktuelle m9-Fimware; ja, da hat sich einiges getan.

Anbei Quelle und Ziel.

Quelle:
Telefon auf 10.10.10.112, 3CX auf 10.10.10.10

Ziel:
Telefon auf 192.168.100.220 (snom 870) und .230 (snom m9), 3CX auf 192.168.100.105.

Wenn ich am snom 870 das Gespräch annehme, bricht die Verbindung ab.

Habe ich das m9 vom Strom getrennt, kann ich am snom 870 problemlos annehmen.
 
Ich bekomme die Pcaps nicht auseinander gedröselt.

Quelle ist der ausgehende Anruf über sipbase an 1und1 welches im pcap ziel zu sehen ist?
Mein Problem ist, ich sehe nicht den Invite von 1und1 an die PBX und dann den Ablauf an die Telefone.
 
Nochmal ein neuer Mitschnitt, ungefiltert. Anbei Quelle und Ziel.

Quelle:
Telefon auf 10.10.10.112, 3CX auf 10.10.10.10, Provider sipbase, ruft 03069545133 an.

Ziel:
Telefon auf 192.168.100.220 (snom 870) und .230 (snom m9), 3CX auf 192.168.100.105, Provider 1&1.

Wenn ich am snom 870 das Gespräch annehme, bricht die Verbindung ab.

Habe ich das m9 vom Strom getrennt, kann ich am snom 870 problemlos annehmen.

Nicht wundern - am Ziel wird parallel noch ein Handy angerufen (soll gleichzeitig klingeln). Das geht gerade nicht wegen fehlender Leitung, aber dies hat mit dem eigentlichen Problem nichts zu tun. Also auch wenn dieses Problem nicht besteht, tritt das oben genannte Problem auf.

Leider ist das Ergebnis zu groß für das Forum, ich möchte jetzt nichts filtern. Deshalb externer Download:
http://www.file-upload.net/download-3561432/Mitschnitt_komplett.zip.html
 
Würg, das ist ein ganz schön zerfahrenes Pcap (kannst du nichts für ;-))

Das Problem kommt von 1und1

Reason: Q.850;cause=38
38 Network out of order...

Und das ist 100% wen in dem Moment wo du die DECT Basis des Snom M9 von Netz nimmst.
Direkt? Mache mir bitte genau so auch mal ein Pcap, ich will den kleinen unterschied nun finden.
Aber schicke genau das Pcap einmal (Ziel) an 1und1 Support, die beenden den Call.
wenn 2 schauen geht es schneller
 
PS stelle mal an der Basis des M9 den Server Typen auf Opera um.
Hilft das schon? Wenn du das nicht gemacht hast, dann ist auch das BLF für das Telefon falsch...
 
Ganz ehrlich, ich habe unseren Media Server Main Dev einmal das Pcap gezeigt und er hat nur den Kopf geschüttelt.
Also 1und1 ist schlimmer als ich dachte ;-) Die Ziel PBX hat aber auch noch einen Account zu SipBase richtig? Zumindest sehe ich eine Anmeldung dazu...

Okey, dass das Snom M9 etwas damit zu tun hat glauben wir alle nicht, denn der Call Flow zu dem Telefon ist 1a und wird beendent. Aber was wir von 1und 1 sehen ist nicht so gut.

1. Warum kommt von 2 Servern der 1und1 der Invite zu ein und dem gleichem Call?
2. Warum bietet 1und1 keinen normalen Codec an? Alle Codecs beinhalten eine Modifikation, mache sind in der RFC andere nicht
3. Warum versucht der Provider nach dem Aufbau des Calls den Codec wieder zu ändern und wir glauben geht dabei in die brüche, da er 9 mal den gleichen Codec anbietet worauf er dann direkt auch den call beendent.

v=0
o=hiQ9200 153565945 391249976 IN IP4 62.52.146.188
s=Phone Call via hiQ9200 SIPCA
c=IN IP4 62.52.146.188
t=0 0
m=audio 33760 RTP/AVP 100 98
a=rtpmap:100 telephone-event/8000
a=fmtp:100 0-15
a=rtpmap:98 PCMA/8000
a=rtpmap:98 PCMA/8000
a=rtpmap:98 PCMA/8000
a=rtpmap:98 PCMA/8000
a=rtpmap:98 PCMA/8000
a=rtpmap:98 PCMA/8000
a=rtpmap:98 PCMA/8000
a=rtpmap:98 PCMA/8000
a=rtpmap:98 PCMA/8000
a=gpmd:98 vbd=yes
a=pmft: T38
a=ptime:20

Und dann kommt der abbau von 1und1

Record-Route:
Record-Route:
Record-Route:
Via: SIP/2.0/UDP 212.227.18.134;branch=z9hG4bKa16a.cdc4249316ccb41c9891e75b44b50ff0.0
Via: SIP/2.0/UDP 212.227.18.225;branch=z9hG4bKa16a.7958b0af1907cd273c621c28da08f27d.0
Via: SIP/2.0/UDP 212.227.18.138;branch=z9hG4bKa16a.b986fca603a68c1cc6d1e5647fe06f92.0
Via: SIP/2.0/UDP 195.71.188.9:5060;branch=z9hG4bKuqmoor001ou1tvsof1p1cd0000g10.1
From: "+493088667911";tag=166093004
To: "+493069545133";tag=f86c9229
Call-ID: 733e0031-17cf03a8-10beb5b6-8ae@1und1-3.sip.mgc.voip.telefonica.de
CSeq: 3 BYE
Max-Forwards: 66
Supported: timer
Reason: Q.850;cause=38
Content-Length: 0
 
Das Problem mit 1und1 haben diverse Kunden. Es handelt sich dabei in der Regel um Privatkunden die einen Bitstream-Zugang haben und Telefonie auch über VoIP bekommen. Hier tritt das Problem auch mit den vorkonfigurierten Telefonen auf.
 
@matictec: Es ist nicht der bekannte VDSL-Bug bei 1&1 (und Telekom-VDSL-Kunden), bei dem bei jedem eingehenden Anruf über die Fritz!Box das Gespräch abbricht, sobald es angenommen wird.

@stefanw:

Klarstellung: Ich ziehe nicht den Strom vom m9, während die Geräte klingeln, und dann bricht es ab.

Sondern so: Normalerweise habe ich hier snom 870 und m9. Alle Anrufe nehme ich am 870 an. Normalerweise kein Problem, nur der eine Kunde kann nicht anrufen (via 3CX/sipbase dort und 3CX/1&1 hier) - wenn ich am 870 abhebe, bricht es ab.

Wenn ich das m9 dauerhaft stromlos mache und dieser Kunde dann drei Stunden später anruft, kann ich's am 870 problemlos annehmen.

Hier nun zwei pcap - einmal ist das m9 vorhanden, einmal nicht:

http://www.file-upload.net/download-3564115/Mitschnitte-nur-Ziel.zip.html
 
Sorry, aber in beiden Pcaps wird der call abgebrochen. Nur dauert es manchmal länger als bei dem Anderem (0,9 Sekunden und ohne das m9 8 Sec). Das Problem mit bitte nun direkt mit 1und1 besprochen werden. Denn der Call Flow ist ansonsten 100% der gleiche. Also das M9 hat damit nicht viel zu schaffen nach meiner ansicht. Das Gezeigte Pcap ohne das m9 hat den gleichen Fehler wie mit.
 
Um antworten zu können musst du eingeloggt sein.

Einstieg für Admins

Statistik des Forums

Themen
44.413
Beiträge
232.713
Mitglieder
78.328
Neuestes Mitglied
as7h
3CX Logo Footer Copyright © Sitemap Datenschutz Impressum
Oben Unten