VCM/Fax: T.38-Ablehnung schlägt fehl

Forum zu LANCOM Systems VoIP Router/Gateways und zur LANCOM VoIP Option

Moderator: Lancom-Systems Moderatoren

Antworten
Benutzeravatar
Jirka
Beiträge: 5225
Registriert: 03 Jan 2005, 13:39
Wohnort: Ex-OPAL-Gebiet
Kontaktdaten:

VCM/Fax: T.38-Ablehnung schlägt fehl

Beitrag von Jirka »

Hallo zusammen,

so, für Dich lieber Koppelfeld hier der Beweis, dass es ohne T.38 auch nicht tut! Man kann es also drehen wie man will, an einem funktionierenden T.38 führt kein Weg vorbei.

Gegeben ist ein LANCOM 1783VA, 10.12-RU6, SIP-Trunk zur Telekom, SIP-Gateway zur Telefonanlage und ein Faxgerät am analogen Anschluss des 1783 mit SIP-PBX-Leitung zur Telefonanlage.

Zuerst schickt der LANCOM-Router an die Telefonanlage ein INVITE (über die SIP-PBX-Leitung vom analogen Anschluss):

Code: Alles auswählen

[SIP-Packet] 2018/03/15 08:42:28,975  Devicetime: 2018/03/15 08:39:50,815 [Packet]: 
Sending datagram (696 Bytes) from 192.168.193.1:5060 to 172.20.172.223:5060 using UDP (RtgTag 193):
INVITE sip:003022222222@172.20.172.223 SIP/2.0\r\n
Via: SIP/2.0/UDP 192.168.193.1:5060;branch=z9hG4bK-71de4a9f-d2b72e46;rport\r\n
From: "198"<sip:198@172.20.172.223;user=phone>;tag=-492501676--2047298180\r\n
To: <sip:003022222222@172.20.172.223;user=phone>\r\n
Call-ID: 926818518@00a0572e9685\r\n
CSeq: 100 INVITE\r\n
Max-Forwards: 70\r\n
User-Agent: LANCOM 1783VA (over ISDN) / 10.12.0292 / 06.03.2018\r\n
Supported: 100rel\r\n
Contact: <sip:198@192.168.193.1:5060;transport=UDP>\r\n
Content-Type: application/sdp\r\n
Content-Length: 185\r\n
\r\n
v=0\r\n
o=- 463409259 463409259 IN IP4 192.168.193.1\r\n
s=call\r\n
c=IN IP4 192.168.193.1\r\n
t=0 0\r\n
m=audio 14930 RTP/AVP 8 0\r\n
a=rtpmap:8 PCMA/8000\r\n
a=rtpmap:0 PCMU/8000\r\n
a=sendrecv\r\n
a=ptime:20\r\n

[SIP-Packet] 2018/03/15 08:42:29,041  Devicetime: 2018/03/15 08:39:50,832 [Packet]: 
Receiving datagram (431 Bytes) at 192.168.193.1:5060 from 172.20.172.223:5060 using UDP (RtgTag 193):
SIP/2.0 100 Trying\r\n
Via: SIP/2.0/UDP 192.168.193.1:5060;branch=z9hG4bK-71de4a9f-d2b72e46;rport=5060\r\n
To: <sip:003022222222@172.20.172.223;user=phone>\r\n
From: "198"<sip:198@172.20.172.223;user=phone>;tag=-492501676--2047298180\r\n
Call-ID: 926818518@00a0572e9685\r\n
CSeq: 100 INVITE\r\n
Allow: REGISTER, INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, INFO, SUBSCRIBE, UPDATE\r\n
User-Agent: T-Com IpPbxSrv/11.10.0.325\r\n
Content-Length: 0\r\n
\r\n
Die Telefonanlage schickt daraufhin das INVITE zum LANCOM:

Code: Alles auswählen

[SIP-Packet] 2018/03/15 08:42:29,063  Devicetime: 2018/03/15 08:39:50,886 [Packet]: 
Receiving datagram (1115 Bytes) at 192.168.193.1:13677 from 172.20.172.223:5060 using UDP (RtgTag 193):
INVITE sip:SIP88888880@192.168.193.1:13677;transport=udp SIP/2.0\r\n
Via: SIP/2.0/UDP 172.20.172.223:5060;branch=z9hG4bK-d8754z-2b4b673931568710-1---d8754z-;rport\r\n
Max-Forwards: 70\r\n
Contact: <sip:SIP88888880@172.20.172.223:5060;transport=udp>\r\n
To: <sip:+493022222222@172.20.172.223;user=phone>\r\n
From: "198"<sip:SIP88888880@172.20.172.223>;tag=e5688772\r\n
Call-ID: NTY0NmUyZWVhODNhYTg5N2NkNzY3YjMwMDBlMDIwMWI.\r\n
CSeq: 1 INVITE\r\n
Session-Expires: 90;refresher=uac\r\n
Min-SE: 90\r\n
Allow: REGISTER, INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, INFO, SUBSCRIBE, UPDATE\r\n
Content-Type: application/sdp\r\n
Supported: timer\r\n
User-Agent: T-Com IpPbxSrv/11.10.0.325\r\n
P-Asserted-Identity: "198"<sip:+4930888888811@172.20.172.223;user=phone>\r\n
P-Asserted-Identity: <sip:+4930888888898@172.20.172.223;user=phone;x-type=unknown;x-plan=unknown;x-pres=allowed;x-screen=network;x-sendingcomplete>\r\n
P-Preferred-Identity: "198"<sip:+4930888888811@172.20.172.223;user=phone>\r\n
Content-Length: 150\r\n
\r\n
v=0\r\n
o=- 36203273 1 IN IP4 192.168.193.1\r\n
s=T-Com IpPbxSrv\r\n
c=IN IP4 192.168.193.1\r\n
t=0 0\r\n
m=audio 14930 RTP/AVP 8\r\n
a=rtpmap:8 PCMA/8000\r\n
a=ptime:20\r\n

[SIP-Packet] 2018/03/15 08:42:29,063  Devicetime: 2018/03/15 08:39:50,888 [Packet]: 
Sending datagram (544 Bytes) from 192.168.193.1:13677 to 172.20.172.223:5060 using UDP (RtgTag 193):
SIP/2.0 100 Trying\r\n
Via: SIP/2.0/UDP 172.20.172.223:5060;branch=z9hG4bK-d8754z-2b4b673931568710-1---d8754z-;received=172.20.172.223;rport=5060\r\n
From: "198"<sip:SIP88888880@172.20.172.223>;tag=e5688772\r\n
To: <sip:+493022222222@172.20.172.223;user=phone>;tag=1239917669--496172056\r\n
Call-ID: NTY0NmUyZWVhODNhYTg5N2NkNzY3YjMwMDBlMDIwMWI.\r\n
CSeq: 1 INVITE\r\n
User-Agent: LANCOM 1783VA (over ISDN) / 10.12.0292 / 06.03.2018\r\n
Server: Lancom\r\n
Allow: REGISTER, INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, SUBSCRIBE, UPDATE, PRACK\r\n
Content-Length: 0\r\n
\r\n
Und der LANCOM schickt nun das INVITE über den SIP-Trunk zur Telekom:

Code: Alles auswählen

[SIP-Packet] 2018/03/15 08:42:29,867  Devicetime: 2018/03/15 08:39:51,643 [Packet]: 
Sending datagram (1178 Bytes) from 87.139.174.89:10803 to 217.0.26.35:5060 using TCP (RtgTag 0):
INVITE sip:+493022222222@sip-trunk.telekom.de SIP/2.0\r\n
Via: SIP/2.0/TCP 87.139.174.89:10803;branch=z9hG4bK-dce5ce31-3523aa4a;rport\r\n
From: "198"<sip:+4930888888811@sip-trunk.telekom.de;user=phone>;tag=-518221810--1415053033\r\n
To: <sip:+493022222222@sip-trunk.telekom.de>\r\n
Call-ID: 1321304917@00a0572e9685\r\n
CSeq: 100 INVITE\r\n
Max-Forwards: 70\r\n
User-Agent: LANCOM 1783VA (over ISDN) / 10.12.0292 / 06.03.2018\r\n
Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, SUBSCRIBE, UPDATE, PRACK\r\n
Supported: 100rel\r\n
Contact: <sip:+493088888880@87.139.174.89:10803;transport=TCP>\r\n
P-Asserted-Identity: <sip:+4930888888898@sip-trunk.telekom.de;user=phone>\r\n
Authorization: Digest username="551129101372", realm="sip-trunk.telekom.de", algorithm=MD5, uri="sip:+493022222222@sip-trunk.telekom.de", nonce="4161b00fbb411a554161b00f936e950f201e3af9453a6c58e7da75685e962783", response="f865273754b45e13ee7f244076992027"\r\n
Content-Type: application/sdp\r\n
Content-Length: 218\r\n
\r\n
v=0\r\n
o=- 3403170442 3403170442 IN IP4 87.139.174.89\r\n
s=call\r\n
c=IN IP4 87.139.174.89\r\n
t=0 0\r\n
m=audio 9726 RTP/AVP 8 101\r\n
a=rtpmap:8 PCMA/8000\r\n
a=rtpmap:101 telephone-event/8000\r\n
a=fmtp:101 0-15\r\n
a=sendrecv\r\n
a=ptime:20\r\n

[SIP-Packet] 2018/03/15 08:42:29,867  Devicetime: 2018/03/15 08:39:51,675 [Packet]: 
Receiving datagram (308 Bytes) at 87.139.174.89:10803 from 217.0.26.35:5060 using TCP (RtgTag 0):
SIP/2.0 100 Trying\r\n
Via: SIP/2.0/TCP 87.139.174.89:10803;rport;branch=z9hG4bK-dce5ce31-3523aa4a\r\n
To: <sip:+493022222222@sip-trunk.telekom.de>\r\n
From: 198 <sip:+4930888888811@sip-trunk.telekom.de;user=phone>;tag=-518221810--1415053033\r\n
Call-ID: 1321304917@00a0572e9685\r\n
CSeq: 100 INVITE\r\n
Content-Length: 0\r\n
\r\n
Nun kommt ein Ringing vom Provider, was der LANCOM an die Telefonanlage schickt und diese an den LANCOM (für den analogen Port):

Code: Alles auswählen

[SIP-Packet] 2018/03/15 08:42:30,153  Devicetime: 2018/03/15 08:39:51,929 [Packet]: 
Receiving datagram (654 Bytes) at 87.139.174.89:10803 from 217.0.26.35:5060 using TCP (RtgTag 0):
SIP/2.0 180 Ringing\r\n
Via: SIP/2.0/TCP 87.139.174.89:10803;rport=10803;branch=z9hG4bK-dce5ce31-3523aa4a\r\n
Record-Route: <sip:reg.sip-trunk.telekom.de;transport=tcp;lr>\r\n
To: <sip:+493022222222@sip-trunk.telekom.de>;tag=999f98e9\r\n
From: 198 <sip:+4930888888811@sip-trunk.telekom.de;user=phone>;tag=-518221810--1415053033\r\n
Call-ID: 1321304917@00a0572e9685\r\n
Contact: <sip:0ZsrlM7z777MXv5sqrZFnOT+8qaCsOg1ldHwe4P5pA1sij/T9A1WtlqeLVZjBsW8y50v@th1>\r\n
CSeq: 100 INVITE\r\n
Allow: ACK, BYE, CANCEL, INVITE, OPTIONS, PRACK, REFER, REGISTER, UPDATE\r\n
Reason: TSSI;cause=0\r\n
Call-Info: <sip:+493022222222@tel.t-online.de>;purpose=call-completion;m=NR\r\n
Content-Length: 0\r\n
\r\n

[SIP-Packet] 2018/03/15 08:42:30,153  Devicetime: 2018/03/15 08:39:51,929 [Packet]: 
Sending datagram (545 Bytes) from 192.168.193.1:13677 to 172.20.172.223:5060 using UDP (RtgTag 193):
SIP/2.0 180 Ringing\r\n
Via: SIP/2.0/UDP 172.20.172.223:5060;branch=z9hG4bK-d8754z-2b4b673931568710-1---d8754z-;received=172.20.172.223;rport=5060\r\n
From: "198"<sip:SIP88888880@172.20.172.223>;tag=e5688772\r\n
To: <sip:+493022222222@172.20.172.223;user=phone>;tag=1239917669--496172056\r\n
Call-ID: NTY0NmUyZWVhODNhYTg5N2NkNzY3YjMwMDBlMDIwMWI.\r\n
CSeq: 1 INVITE\r\n
User-Agent: LANCOM 1783VA (over ISDN) / 10.12.0292 / 06.03.2018\r\n
Server: Lancom\r\n
Allow: REGISTER, INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, SUBSCRIBE, UPDATE, PRACK\r\n
Content-Length: 0\r\n
\r\n

[SIP-Packet] 2018/03/15 08:42:30,153  Devicetime: 2018/03/15 08:39:51,951 [Packet]: 
Receiving datagram (696 Bytes) at 192.168.193.1:5060 from 172.20.172.223:5060 using UDP (RtgTag 193):
SIP/2.0 180 Ringing\r\n
Via: SIP/2.0/UDP 192.168.193.1:5060;branch=z9hG4bK-71de4a9f-d2b72e46;rport=5060\r\n
Contact: <sip:172.20.172.223:5060;transport=udp>\r\n
To: "XYZ BLN FAX"<sip:003022222222@172.20.172.223;user=phone>;tag=77715266\r\n
From: "198"<sip:198@172.20.172.223;user=phone>;tag=-492501676--2047298180\r\n
Call-ID: 926818518@00a0572e9685\r\n
CSeq: 100 INVITE\r\n
Allow: REGISTER, INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, INFO, SUBSCRIBE, UPDATE\r\n
User-Agent: T-Com IpPbxSrv/11.10.0.325\r\n
X-IPPBXAlertType: 0\r\n
X-IPPBXRedirected: false\r\n
X-IPPBXCalledNumber: 003022222222\r\n
X-IPPBXCalledName: XYZ BLN FAX\r\n
X-IPPBXServerCallId: 321996\r\n
X-IPPBXServerCallContext: cmvqshj1eurm\r\n
Content-Length: 0\r\n
\r\n
Jetzt kommt das OK, was den gleichen Weg geht. Das Telefongespräch besteht somit:

Code: Alles auswählen

[SIP-Packet] 2018/03/15 08:42:30,946  Devicetime: 2018/03/15 08:39:52,757 [Packet]: 
Receiving datagram (937 Bytes) at 87.139.174.89:10803 from 217.0.26.35:5060 using TCP (RtgTag 0):
SIP/2.0 200 OK\r\n
Via: SIP/2.0/TCP 87.139.174.89:10803;rport=10803;branch=z9hG4bK-dce5ce31-3523aa4a\r\n
Record-Route: <sip:reg.sip-trunk.telekom.de;transport=tcp;lr>\r\n
To: <sip:+493022222222@sip-trunk.telekom.de>;tag=999f98e9\r\n
From: 198 <sip:+4930888888811@sip-trunk.telekom.de;user=phone>;tag=-518221810--1415053033\r\n
Call-ID: 1321304917@00a0572e9685\r\n
Contact: <sip:0ZsrlM7z777MXv5sqrZFnOT+8qaCsOg1ldHwe4P5pA1sij/T9A1WtlqeLVZjBsW8y50v@th1>\r\n
CSeq: 100 INVITE\r\n
Allow: ACK, BYE, CANCEL, INVITE, OPTIONS, PRACK, REFER, REGISTER, SUBSCRIBE, UPDATE\r\n
Reason: TSSI;cause=0\r\n
Session-ID: 773c4000b02d5ccfe009969a7ce0b09b\r\n
Content-Type: application/sdp\r\n
Content-Disposition: session\r\n
Content-Length: 246\r\n
\r\n
v=0\r\n
o=- 1302532253 2563928410 IN IP4 217.0.26.35\r\n
s=on transit\r\n
c=IN IP4 217.0.132.54\r\n
t=0 0\r\n
m=audio 10244 RTP/AVP 8 0 101\r\n
a=rtpmap:8 PCMA/8000\r\n
a=rtpmap:0 PCMU/8000\r\n
a=rtpmap:101 telephone-event/8000\r\n
a=fmtp:101 0-15\r\n
a=sendrecv\r\n
a=ptime:20\r\n

[SIP-Packet] 2018/03/15 08:42:30,946  Devicetime: 2018/03/15 08:39:52,760 [Packet]: 
Sending datagram (802 Bytes) from 192.168.193.1:13677 to 172.20.172.223:5060 using UDP (RtgTag 193):
SIP/2.0 200 OK\r\n
Via: SIP/2.0/UDP 172.20.172.223:5060;branch=z9hG4bK-d8754z-2b4b673931568710-1---d8754z-;received=172.20.172.223;rport=5060\r\n
From: "198"<sip:SIP88888880@172.20.172.223>;tag=e5688772\r\n
To: <sip:+493022222222@172.20.172.223;user=phone>;tag=1239917669--496172056\r\n
Call-ID: NTY0NmUyZWVhODNhYTg5N2NkNzY3YjMwMDBlMDIwMWI.\r\n
CSeq: 1 INVITE\r\n
User-Agent: LANCOM 1783VA (over ISDN) / 10.12.0292 / 06.03.2018\r\n
Server: Lancom\r\n
Allow: REGISTER, INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, SUBSCRIBE, UPDATE, PRACK\r\n
Contact: <sip:SIP88888880@192.168.193.1:13677;transport=UDP>\r\n
Content-Type: application/sdp\r\n
Content-Length: 169\r\n
\r\n
v=0\r\n
o=- 0 0 IN IP4 192.168.193.1\r\n
s=call\r\n
c=IN IP4 192.168.193.1\r\n
t=0 0\r\n
m=audio 11254 RTP/AVP 8 0\r\n
a=rtpmap:8 PCMA/8000\r\n
a=rtpmap:0 PCMU/8000\r\n
a=sendrecv\r\n
a=ptime:20\r\n

[SIP-Packet] 2018/03/15 08:42:30,960  Devicetime: 2018/03/15 08:39:52,777 [Packet]: 
Receiving datagram (887 Bytes) at 192.168.193.1:13677 from 172.20.172.223:5060 using UDP (RtgTag 193):
ACK sip:SIP88888880@192.168.193.1:13677;transport=udp SIP/2.0\r\n
Via: SIP/2.0/UDP 172.20.172.223:5060;branch=z9hG4bK-d8754z-0b6f594a714fb36b-1---d8754z-;rport\r\n
Max-Forwards: 70\r\n
Contact: <sip:SIP88888880@172.20.172.223:5060;transport=udp>\r\n
To: <sip:+493022222222@172.20.172.223;user=phone>;tag=1239917669--496172056\r\n
From: "198"<sip:SIP88888880@172.20.172.223>;tag=e5688772\r\n
Call-ID: NTY0NmUyZWVhODNhYTg5N2NkNzY3YjMwMDBlMDIwMWI.\r\n
CSeq: 1 ACK\r\n
Allow: REGISTER, INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, INFO, SUBSCRIBE, UPDATE\r\n
User-Agent: T-Com IpPbxSrv/11.10.0.325\r\n
P-Asserted-Identity: "198"<sip:+4930888888811@172.20.172.223;user=phone>\r\n
P-Asserted-Identity: <sip:+4930888888898@172.20.172.223;user=phone;x-type=unknown;x-plan=unknown;x-pres=allowed;x-screen=network;x-sendingcomplete>\r\n
P-Preferred-Identity: "198"<sip:+4930888888811@172.20.172.223;user=phone>\r\n
Content-Length: 0\r\n
\r\n

[SIP-Packet] 2018/03/15 08:42:30,960  Devicetime: 2018/03/15 08:39:52,779 [Packet]: 
Sending datagram (915 Bytes) from 87.139.174.89:10803 to 217.0.26.35:5060 using TCP (RtgTag 0):
ACK sip:0ZsrlM7z777MXv5sqrZFnOT+8qaCsOg1ldHwe4P5pA1sij/T9A1WtlqeLVZjBsW8y50v@th1 SIP/2.0\r\n
Via: SIP/2.0/TCP 87.139.174.89:10803;branch=z9hG4bK-a53e4d7c-77edfacb;rport\r\n
Route: <sip:reg.sip-trunk.telekom.de;transport=tcp;lr>\r\n
From: "198"<sip:+4930888888811@sip-trunk.telekom.de;user=phone>;tag=-518221810--1415053033\r\n
To: <sip:+493022222222@sip-trunk.telekom.de>;tag=999f98e9\r\n
Call-ID: 1321304917@00a0572e9685\r\n
CSeq: 100 ACK\r\n
Max-Forwards: 70\r\n
User-Agent: LANCOM 1783VA (over ISDN) / 10.12.0292 / 06.03.2018\r\n
Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, SUBSCRIBE, UPDATE, PRACK\r\n
Authorization: Digest username="551129101372", realm="sip-trunk.telekom.de", algorithm=MD5, uri="sip:+493022222222@sip-trunk.telekom.de", nonce="4161b00fbb411a554161b00f936e950f201e3af9453a6c58e7da75685e962783", response="f865273754b45e13ee7f244076992027"\r\n
Session-ID: 773c4000b02d5ccfe009969a7ce0b09b\r\n
Content-Length: 0\r\n
\r\n

[SIP-Packet] 2018/03/15 08:42:30,960  Devicetime: 2018/03/15 08:39:52,781 [Packet]: 
Receiving datagram (872 Bytes) at 192.168.193.1:5060 from 172.20.172.223:5060 using UDP (RtgTag 193):
SIP/2.0 200 OK\r\n
Via: SIP/2.0/UDP 192.168.193.1:5060;branch=z9hG4bK-71de4a9f-d2b72e46;rport=5060\r\n
Contact: <sip:172.20.172.223:5060;transport=udp>\r\n
To: "XYZ BLN FAX"<sip:003022222222@172.20.172.223;user=phone>;tag=77715266\r\n
From: "198"<sip:198@172.20.172.223;user=phone>;tag=-492501676--2047298180\r\n
Call-ID: 926818518@00a0572e9685\r\n
CSeq: 100 INVITE\r\n
Allow: REGISTER, INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, INFO, SUBSCRIBE, UPDATE\r\n
Content-Type: application/sdp\r\n
User-Agent: T-Com IpPbxSrv/11.10.0.325\r\n
X-IPPBXServerCallId: 321996\r\n
X-IPPBXServerCallContext: cmvqshj1eurm\r\n
X-IPPBXRedirected: false\r\n
X-IPPBXCalledNumber: 003022222222\r\n
X-IPPBXCalledName: XYZ BLN FAX\r\n
Content-Length: 169\r\n
\r\n
v=0\r\n
o=- 0 0 IN IP4 192.168.193.1\r\n
s=call\r\n
c=IN IP4 192.168.193.1\r\n
t=0 0\r\n
m=audio 11254 RTP/AVP 8 0\r\n
a=rtpmap:8 PCMA/8000\r\n
a=rtpmap:0 PCMU/8000\r\n
a=sendrecv\r\n
a=ptime:20\r\n

[SIP-Packet] 2018/03/15 08:42:30,960  Devicetime: 2018/03/15 08:39:52,785 [Packet]: 
Sending datagram (418 Bytes) from 192.168.193.1:5060 to 172.20.172.223:5060 using UDP (RtgTag 193):
ACK sip:172.20.172.223:5060;transport=udp SIP/2.0\r\n
Via: SIP/2.0/UDP 192.168.193.1:5060;branch=z9hG4bK-97c1d697-51bf8097;rport\r\n
From: "198"<sip:198@172.20.172.223;user=phone>;tag=-492501676--2047298180\r\n
To: <sip:003022222222@172.20.172.223;user=phone>;tag=77715266\r\n
Call-ID: 926818518@00a0572e9685\r\n
CSeq: 100 ACK\r\n
Max-Forwards: 70\r\n
User-Agent: LANCOM 1783VA (over ISDN) / 10.12.0292 / 06.03.2018\r\n
Content-Length: 0\r\n
\r\n
Jetzt möchte die Gegenseite auf T.38 umschwenken, es kommt also ein Re-INVITE:

Code: Alles auswählen

[SIP-Packet] 2018/03/15 08:42:33,184  Devicetime: 2018/03/15 08:39:55,005 [Packet]: 
Receiving datagram (1004 Bytes) at 87.139.174.89:10803 from 217.0.26.35:5060 using TCP (RtgTag 0):
INVITE sip:+493088888880@87.139.174.89:10803;transport=TCP SIP/2.0\r\n
Via: SIP/2.0/TCP 217.0.26.35:5060;branch=z9hG4bKb6d4307a4fe070f3de91cdcecabfedcd.388e48eb\r\n
Record-Route: <sip:reg.sip-trunk.telekom.de;transport=tcp;lr>\r\n
Max-Forwards: 63\r\n
To: 198 <sip:+4930888888811@sip-trunk.telekom.de;user=phone>;tag=-518221810--1415053033\r\n
From: <sip:anonymous@anonymous.invalid>;tag=999f98e9\r\n
Call-ID: 1321304917@00a0572e9685\r\n
Contact: <sip:0ZsrlM7z777MXv5sqrZFnOT+8qaCsOg1ldHwe4P5pA1sij/T9A1WtlqeLVZjBsW8y50v@th1>\r\n
Supported: 100rel\r\n
CSeq: 13571533 INVITE\r\n
Allow: ACK, BYE, CANCEL, INVITE, OPTIONS, PRACK, REFER, REGISTER, SUBSCRIBE, UPDATE\r\n
Content-Type: application/sdp\r\n
Content-Disposition: session\r\n
Content-Length: 287\r\n
\r\n
v=0\r\n
o=- 1302532253 2563928411 IN IP4 217.0.26.35\r\n
s=on transit\r\n
c=IN IP4 217.0.132.54\r\n
t=0 0\r\n
m=image 10244 udptl t38\r\n
a=sendrecv\r\n
a=T38FaxVersion:0\r\n
a=T38MaxBitRate:14400\r\n
a=T38FaxRateManagement:transferredTCF\r\n
a=T38FaxMaxBuffer:4096\r\n
a=T38FaxMaxDatagram:500\r\n
a=T38FaxUdpEC:t38UDPFEC\r\n

[SIP-Packet] 2018/03/15 08:42:33,184  Devicetime: 2018/03/15 08:39:55,006 [Packet]: 
Sending datagram (589 Bytes) from 87.139.174.89:10803 to 217.0.26.35:5060 using TCP (RtgTag 0):
SIP/2.0 100 Trying\r\n
Via: SIP/2.0/TCP 217.0.26.35:5060;branch=z9hG4bKb6d4307a4fe070f3de91cdcecabfedcd.388e48eb;received=217.0.26.35\r\n
Record-Route: <sip:reg.sip-trunk.telekom.de;transport=tcp;lr>\r\n
From: <sip:+493022222222@sip-trunk.telekom.de>;tag=999f98e9\r\n
To: "198"<sip:+4930888888811@sip-trunk.telekom.de;user=phone>;tag=-518221810--1415053033\r\n
Call-ID: 1321304917@00a0572e9685\r\n
CSeq: 13571533 INVITE\r\n
User-Agent: LANCOM 1783VA (over ISDN) / 10.12.0292 / 06.03.2018\r\n
Server: Lancom\r\n
Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, SUBSCRIBE, UPDATE, PRACK\r\n
Content-Length: 0\r\n
\r\n
Der LANCOM gibt es wieder an die Telefonanlage weiter:

Code: Alles auswählen

[SIP-Packet] 2018/03/15 08:42:33,184  Devicetime: 2018/03/15 08:39:55,007 [Packet]: 
Sending datagram (1142 Bytes) from 192.168.193.1:13677 to 172.20.172.223:5060 using UDP (RtgTag 193):
INVITE sip:SIP88888880@172.20.172.223:5060;transport=udp SIP/2.0\r\n
Via: SIP/2.0/UDP 192.168.193.1:13677;branch=z9hG4bK-21b52188-e5053a0c;rport\r\n
From: <sip:+493022222222@172.20.172.223;user=phone>;tag=1239917669--496172056\r\n
To: "198"<sip:SIP88888880@172.20.172.223>;tag=e5688772\r\n
Call-ID: NTY0NmUyZWVhODNhYTg5N2NkNzY3YjMwMDBlMDIwMWI.\r\n
CSeq: 1 INVITE\r\n
Max-Forwards: 70\r\n
User-Agent: LANCOM 1783VA (over ISDN) / 10.12.0292 / 06.03.2018\r\n
Allow: REGISTER, INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, SUBSCRIBE, UPDATE, PRACK\r\n
Supported: 100rel\r\n
Contact: <sip:SIP88888880@192.168.193.1:13677;transport=UDP>\r\n
Authorization: Digest username="SIP88888880", realm="172.20.172.223", algorithm=MD5, uri="sip:SIP88888880@172.20.172.223:5060", nonce="280645502:bf36d45b7db5a7bb9f5d62d0573d30ed", response="c6bab9b46bd086cc9f6ad8c1e4e69561"\r\n
Content-Type: application/sdp\r\n
Content-Length: 266\r\n
\r\n
v=0\r\n
o=- 0 1 IN IP4 192.168.193.1\r\n
s=call\r\n
c=IN IP4 192.168.193.1\r\n
t=0 0\r\n
m=image 11254 udptl t38\r\n
a=sendrecv\r\n
a=T38FaxVersion:0\r\n
a=T38MaxBitRate:14400\r\n
a=T38FaxRateManagement:transferredTCF\r\n
a=T38FaxMaxBuffer:4096\r\n
a=T38FaxMaxDatagram:500\r\n
a=T38FaxUdpEC:t38UDPFEC\r\n

[SIP-Packet] 2018/03/15 08:42:33,254  Devicetime: 2018/03/15 08:39:55,024 [Packet]: 
Receiving datagram (461 Bytes) at 192.168.193.1:13677 from 172.20.172.223:5060 using UDP (RtgTag 193):
SIP/2.0 100 Trying\r\n
Via: SIP/2.0/UDP 192.168.193.1:13677;branch=z9hG4bK-21b52188-e5053a0c;rport=13677\r\n
To: "198"<sip:SIP88888880@172.20.172.223>;tag=e5688772\r\n
From: <sip:+493022222222@172.20.172.223;user=phone>;tag=1239917669--496172056\r\n
Call-ID: NTY0NmUyZWVhODNhYTg5N2NkNzY3YjMwMDBlMDIwMWI.\r\n
CSeq: 1 INVITE\r\n
Allow: REGISTER, INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, INFO, SUBSCRIBE, UPDATE\r\n
User-Agent: T-Com IpPbxSrv/11.10.0.325\r\n
Content-Length: 0\r\n
\r\n
Die Telefonanlage lehnt die Änderung auf T.38 nun aber ab. Der Codec T.38 ist in der Telefonanlage nicht zugelassen:

Code: Alles auswählen

[SIP-Packet] 2018/03/15 08:42:33,254  Devicetime: 2018/03/15 08:39:55,025 [Packet]: 
Receiving datagram (521 Bytes) at 192.168.193.1:13677 from 172.20.172.223:5060 using UDP (RtgTag 193):
SIP/2.0 488 Not Acceptable Here\r\n
Via: SIP/2.0/UDP 192.168.193.1:13677;branch=z9hG4bK-21b52188-e5053a0c;rport=13677\r\n
To: "198"<sip:SIP88888880@172.20.172.223>;tag=e5688772\r\n
From: <sip:+493022222222@172.20.172.223;user=phone>;tag=1239917669--496172056\r\n
Call-ID: NTY0NmUyZWVhODNhYTg5N2NkNzY3YjMwMDBlMDIwMWI.\r\n
CSeq: 1 INVITE\r\n
Allow: REGISTER, INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, INFO, SUBSCRIBE, UPDATE\r\n
User-Agent: T-Com IpPbxSrv/11.10.0.325\r\n
Warning: 399 host "MediaOffer Request Failed"\r\n
Content-Length: 0\r\n
\r\n

[SIP-Packet] 2018/03/15 08:42:33,254  Devicetime: 2018/03/15 08:39:55,026 [Packet]: 
Sending datagram (537 Bytes) from 192.168.193.1:13677 to 172.20.172.223:5060 using UDP (RtgTag 193):
ACK sip:SIP88888880@172.20.172.223:5060;transport=udp SIP/2.0\r\n
Via: SIP/2.0/UDP 192.168.193.1:13677;branch=z9hG4bK-21b52188-e5053a0c;rport\r\n
From: <sip:+493022222222@172.20.172.223;user=phone>;tag=1239917669--496172056\r\n
To: "198"<sip:SIP88888880@172.20.172.223>;tag=e5688772\r\n
Call-ID: NTY0NmUyZWVhODNhYTg5N2NkNzY3YjMwMDBlMDIwMWI.\r\n
CSeq: 1 ACK\r\n
Max-Forwards: 70\r\n
User-Agent: LANCOM 1783VA (over ISDN) / 10.12.0292 / 06.03.2018\r\n
Allow: REGISTER, INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, SUBSCRIBE, UPDATE, PRACK\r\n
Content-Length: 0\r\n
\r\n
Jetzt kommt es. Was macht der LANCOM aus dem "Not Acceptable"? Ein OK (in Richtung zum Provider/der Gegenseite):

Code: Alles auswählen

[SIP-Packet] 2018/03/15 08:42:33,254  Devicetime: 2018/03/15 08:39:55,029 [Packet]: 
Sending datagram (965 Bytes) from 87.139.174.89:10803 to 217.0.26.35:5060 using TCP (RtgTag 0):
SIP/2.0 200 OK\r\n
Via: SIP/2.0/TCP 217.0.26.35:5060;branch=z9hG4bKb6d4307a4fe070f3de91cdcecabfedcd.388e48eb;received=217.0.26.35\r\n
Record-Route: <sip:reg.sip-trunk.telekom.de;transport=tcp;lr>\r\n
From: <sip:+493022222222@sip-trunk.telekom.de>;tag=999f98e9\r\n
To: "198"<sip:+4930888888811@sip-trunk.telekom.de;user=phone>;tag=-518221810--1415053033\r\n
Call-ID: 1321304917@00a0572e9685\r\n
CSeq: 13571533 INVITE\r\n
User-Agent: LANCOM 1783VA (over ISDN) / 10.12.0292 / 06.03.2018\r\n
Server: Lancom\r\n
Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, SUBSCRIBE, UPDATE, PRACK\r\n
Contact: <sip:+493088888880@87.139.174.89:10803;transport=TCP>\r\n
Content-Type: application/sdp\r\n
Content-Length: 283\r\n
\r\n
v=0\r\n
o=- 3403170442 3403170443 IN IP4 87.139.174.89\r\n
s=call\r\n
c=IN IP4 87.139.174.89\r\n
t=0 0\r\n
m=image 9726 udptl t38\r\n
a=sendrecv\r\n
a=T38FaxVersion:0\r\n
a=T38MaxBitRate:14400\r\n
a=T38FaxRateManagement:transferredTCF\r\n
a=T38FaxMaxBuffer:4096\r\n
a=T38FaxMaxDatagram:512\r\n
a=T38FaxUdpEC:t38UDPFEC\r\n

[SIP-Packet] 2018/03/15 08:42:33,354  Devicetime: 2018/03/15 08:39:55,194 [Packet]: 
Receiving datagram (624 Bytes) at 87.139.174.89:10803 from 217.0.26.35:5060 using TCP (RtgTag 0):
ACK sip:+493088888880@87.139.174.89:10803;transport=TCP SIP/2.0\r\n
Via: SIP/2.0/TCP 217.0.26.35;branch=z9hG4bKb6d4307a4fe070f3de91cdcecabfedcd.03c9f973\r\n
Record-Route: <sip:reg.sip-trunk.telekom.de;transport=tcp;lr>\r\n
Max-Forwards: 63\r\n
To: 198 <sip:+4930888888811@sip-trunk.telekom.de;user=phone>;tag=-518221810--1415053033\r\n
From: <sip:anonymous@anonymous.invalid>;tag=999f98e9\r\n
Call-ID: 1321304917@00a0572e9685\r\n
Contact: <sip:0ZsrlM7z777MXv5sqrZFnOT+8qaCsOg1ldHwe4P5pA1sij/T9A1WtlqeLVZjBsW8y50v@th1>\r\n
CSeq: 13571533 ACK\r\n
Allow: ACK, BYE, CANCEL, INVITE, OPTIONS, PRACK, REFER, REGISTER, SUBSCRIBE, UPDATE\r\n
Content-Length: 0\r\n
\r\n
Dann geht natürlich nichts mehr, das Telefongespräch wird vom Fax beendet, ohne dass das Fax übertragen wurde:

Code: Alles auswählen

[SIP-Packet] 2018/03/15 08:43:10,704  Devicetime: 2018/03/15 08:40:32,547 [Packet]: 
Sending datagram (418 Bytes) from 192.168.193.1:5060 to 172.20.172.223:5060 using UDP (RtgTag 193):
BYE sip:172.20.172.223:5060;transport=udp SIP/2.0\r\n
Via: SIP/2.0/UDP 192.168.193.1:5060;branch=z9hG4bK-49e665f4-0b1d4e85;rport\r\n
From: "198"<sip:198@172.20.172.223;user=phone>;tag=-492501676--2047298180\r\n
To: <sip:003022222222@172.20.172.223;user=phone>;tag=77715266\r\n
Call-ID: 926818518@00a0572e9685\r\n
CSeq: 101 BYE\r\n
Max-Forwards: 70\r\n
User-Agent: LANCOM 1783VA (over ISDN) / 10.12.0292 / 06.03.2018\r\n
Content-Length: 0\r\n
\r\n

[SIP-Packet] 2018/03/15 08:43:10,752  Devicetime: 2018/03/15 08:40:32,577 [Packet]: 
Receiving datagram (905 Bytes) at 192.168.193.1:13677 from 172.20.172.223:5060 using UDP (RtgTag 193):
BYE sip:SIP88888880@192.168.193.1:13677;transport=udp SIP/2.0\r\n
Via: SIP/2.0/UDP 172.20.172.223:5060;branch=z9hG4bK-d8754z-9050ef3c69197f7c-1---d8754z-;rport\r\n
Max-Forwards: 70\r\n
Contact: <sip:SIP88888880@172.20.172.223:5060;transport=udp>\r\n
To: <sip:+493022222222@172.20.172.223;user=phone>;tag=1239917669--496172056\r\n
From: "198"<sip:SIP88888880@172.20.172.223>;tag=e5688772\r\n
Call-ID: NTY0NmUyZWVhODNhYTg5N2NkNzY3YjMwMDBlMDIwMWI.\r\n
CSeq: 2 BYE\r\n
Allow: REGISTER, INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, INFO, SUBSCRIBE, UPDATE\r\n
Supported: timer\r\n
User-Agent: T-Com IpPbxSrv/11.10.0.325\r\n
P-Asserted-Identity: "198"<sip:+4930888888811@172.20.172.223;user=phone>\r\n
P-Asserted-Identity: <sip:+4930888888898@172.20.172.223;user=phone;x-type=unknown;x-plan=unknown;x-pres=allowed;x-screen=network;x-sendingcomplete>\r\n
P-Preferred-Identity: "198"<sip:+4930888888811@172.20.172.223;user=phone>\r\n
Content-Length: 0\r\n
\r\n

[SIP-Packet] 2018/03/15 08:43:10,752  Devicetime: 2018/03/15 08:40:32,580 [Packet]: 
Sending datagram (611 Bytes) from 87.139.174.89:10803 to 217.0.26.35:5060 using TCP (RtgTag 0):
BYE sip:0ZsrlM7z777MXv5sqrZFnOT+8qaCsOg1ldHwe4P5pA1sij/T9A1WtlqeLVZjBsW8y50v@th1 SIP/2.0\r\n
Via: SIP/2.0/TCP 87.139.174.89:10803;branch=z9hG4bK-6a167122-0c9b375e;rport\r\n
Route: <sip:reg.sip-trunk.telekom.de;transport=tcp;lr>\r\n
From: "198"<sip:+4930888888811@sip-trunk.telekom.de;user=phone>;tag=-518221810--1415053033\r\n
To: <sip:+493022222222@sip-trunk.telekom.de>;tag=999f98e9\r\n
Call-ID: 1321304917@00a0572e9685\r\n
CSeq: 101 BYE\r\n
Max-Forwards: 70\r\n
User-Agent: LANCOM 1783VA (over ISDN) / 10.12.0292 / 06.03.2018\r\n
Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, SUBSCRIBE, UPDATE, PRACK\r\n
Content-Length: 0\r\n
\r\n
Vielen Dank und viele Grüße,
Jirka

P.S.: Nicht wundern, das Faxgerät hat eine eigene Rufnummer, soll nach extern aber die offizielle Faxnummer des Unternehmens übermitteln, deswegen die zwei Rufnummern.
Dr.Einstein
Beiträge: 2893
Registriert: 12 Jan 2010, 14:10

Re: VCM/Fax: T.38-Ablehnung schlägt fehl

Beitrag von Dr.Einstein »

Hi Jirka,

was hat das jetzt mit T.38 zutun, wenn der Lancom in der SIP Aushandlung einen Implementierungsfehler hat? (Dachte eigentlich, der ist schon lange raus, habe den mal vor Monaten mit der 9.24 gesehen)

Gruß Dr.Einstein
Benutzeravatar
Jirka
Beiträge: 5225
Registriert: 03 Jan 2005, 13:39
Wohnort: Ex-OPAL-Gebiet
Kontaktdaten:

Re: VCM/Fax: T.38-Ablehnung schlägt fehl

Beitrag von Jirka »

Hallo Dr. Einstein,

nur so viel, als dass ich Koppelfeld ein wenig ärgern wollte und dass es ohne T.38 zu erlauben in dem Fall nicht möglich ist, ein Fax abzuschicken. Ist doch logisch, oder verstehe ich die Frage falsch? Es soll Koppelfeld also zeigen, dass selbst mit ausgeschaltetem T.38 ein Fax nicht immer ankommen muss... Gut, das liegt jetzt nicht am T.38-Protokoll, aber eben am Zustand, ob T.38 aus- oder eingeschaltet ist.
Von LANCOM wünsche ich mir natürlich einen Fix für das Problem. Aber wenn Du schreibst, dass der Bug schon länger existiert, dann sollte ich T.38 doch besser wieder einschalten...

Viele Grüße,
Jirka
Dr.Einstein
Beiträge: 2893
Registriert: 12 Jan 2010, 14:10

Re: VCM/Fax: T.38-Ablehnung schlägt fehl

Beitrag von Dr.Einstein »

Oder auch nicht, weil T38 genauso wenig oder viel funktioniert :D Schönes Dauerthema, worüber wir uns alle ärgern können.

Gruß Dr.Einstein
Benutzeravatar
Jirka
Beiträge: 5225
Registriert: 03 Jan 2005, 13:39
Wohnort: Ex-OPAL-Gebiet
Kontaktdaten:

Re: VCM/Fax: T.38-Ablehnung schlägt fehl

Beitrag von Jirka »

Ja, ich versuche es ja auch schon zu umgehen und andere Lösungen zu präsentieren, aber es ist nicht immer einfach. Scan-to-E-Mail funktioniert schon wunderbar, habe ich mehrfach durchgesetzt, die Leute sind heute froh, dass ich ihnen das gezeigt habe. Weißt Du zufälligerweise für Mail-to-Printer eine Lösung? Jemand soll also eine E-Mail mit PDF-Datei als Anlage schicken und der Drucker soll die kurzfristig (max. 15 Min. später) selbständig ausdrucken, aber bitteschön nur die PDF-Anlage, weil alles andere wäre jetzt Papierverschwendung. Macht HP ePrint das zuverlässig? Oder hast Du eine bessere Idee? Scan-to-E-Mail soll also auf der anderen Seite wieder zu Papier werden, quasi ein neumodernes Fax. Und das ohne VoIP/SIP.
Benutzeravatar
hyperjojo
Beiträge: 801
Registriert: 26 Jul 2009, 02:26

Re: VCM/Fax: T.38-Ablehnung schlägt fehl

Beitrag von hyperjojo »

hi,
Jirka hat geschrieben:Weißt Du zufälligerweise für Mail-to-Printer eine Lösung? Jemand soll also eine E-Mail mit PDF-Datei als Anlage schicken und der Drucker soll die kurzfristig (max. 15 Min. später) selbständig ausdrucken, aber bitteschön nur die PDF-Anlage, weil alles andere wäre jetzt Papierverschwendung. Macht HP ePrint das zuverlässig? Oder hast Du eine bessere Idee? Scan-to-E-Mail soll also auf der anderen Seite wieder zu Papier werden, quasi ein neumodernes Fax. Und das ohne VoIP/SIP.
die Frage musste ich mir letzte Woche auch stellen. HP ePrint funktioniert bei mir super, allerdings nur mit Druckern die das auch unterstützen. Bei einem älteren Drucker habe ich Google Cloud Print eingesetzt, da gehts nicht per E-Mail sondern per Fileupload. Allerdings gefällt mir bei beiden Lösungen nicht, dass man alles an fremde (amerikanische) Unternehmen schickt. Vielleicht hat ja jemand eine andere Lösung im Einsatz, die man empfehlen könnte?

Gruß hyperjojo
andreas
Beiträge: 109
Registriert: 04 Jan 2005, 00:35

Re: VCM/Fax: T.38-Ablehnung schlägt fehl

Beitrag von andreas »

Jirka hat geschrieben:Weißt Du zufälligerweise für Mail-to-Printer eine Lösung? Jemand soll also eine E-Mail mit PDF-Datei als Anlage schicken und der Drucker soll die kurzfristig (max. 15 Min. später) selbständig ausdrucken, aber bitteschön nur die PDF-Anlage, weil alles andere wäre jetzt Papierverschwendung.
Du kannst Dir mal den "Automatic E-Mail Manager" von Namtuk anschauen:
http://www.namtuk.com/auto_email_manager.aspx

Der kann das und noch ein paar interessante Dinge mehr. Wir nutzen den bei Kunden um Rechnungen, die per Mail eingehen in die richtigen Verzeichnisse zu speichern und ggf. für den Steuerberater auszudrucken.

Den kannst Du auch so einstellen, dass er bei Mails von "Faxgateway" oder an "faxeingang@kunde" nur den Anhang ausdruckt und den auch in einem Verzeichnis speichert oder auch nicht

Leider haben die jetzt auch auf so ein besch... Abo-Modell umgestellt.

VG
Andreas
Benutzeravatar
MoinMoin
Moderator
Moderator
Beiträge: 1978
Registriert: 12 Nov 2004, 16:04

Re: VCM/Fax: T.38-Ablehnung schlägt fehl

Beitrag von MoinMoin »

Moin Jirka!
Jirka hat geschrieben:dass es ohne T.38 zu erlauben in dem Fall nicht möglich ist, ein Fax abzuschicken. Ist doch logisch, oder verstehe ich die Frage falsch? Es soll Koppelfeld also zeigen, dass selbst mit ausgeschaltetem T.38 ein Fax nicht immer ankommen muss... Gut, das liegt jetzt nicht am T.38-Protokoll, aber eben am Zustand, ob T.38 aus- oder eingeschaltet ist.
Hast du dauf dem LANCOM, das versucht, von G.711 zu T.38 zu transcodieren denn T.38 generell deaktiviert? Ansonsten ist das so gewollt, daß das LANCOM die Terminierung von T.38 im SIP übernimmt.

Was passiert denn nach der T.38-Umschaltung? Bricht die Übertragung von G.711 zum FAX-Geräte ab?

Ciao, Georg
Benutzeravatar
Jirka
Beiträge: 5225
Registriert: 03 Jan 2005, 13:39
Wohnort: Ex-OPAL-Gebiet
Kontaktdaten:

Re: VCM/Fax: T.38-Ablehnung schlägt fehl

Beitrag von Jirka »

Hallo Georg!
MoinMoin hat geschrieben:Hast du dauf dem LANCOM, das versucht, von G.711 zu T.38 zu transcodieren denn T.38 generell deaktiviert? Ansonsten ist das so gewollt, daß das LANCOM die Terminierung von T.38 im SIP übernimmt.
Oh nee!!!! :roll: Das hast Du mir doch schon mal gesagt!!! Daran zu denken, geht nicht in meinen Kopf rein. Schlimm.
Also im LANCOM war/ist T.38 an! Daher ist das Verhalten also ok! Sorry! Und vielen Dank für den erneuten Wink mit dem ganzen Zaun.
MoinMoin hat geschrieben:Was passiert denn nach der T.38-Umschaltung? Bricht die Übertragung von G.711 zum FAX-Geräte ab?
Ja, da gibt es neue Erkenntnisse. Denn nachdem es heute Vormittag auch mit T.38 in der Telefonanlage nicht ging, bin ich zur anderen Seite gefahren, habe da alles geprüft, und dann einen LANCOM hingestellt. Ergebnis: Im OK-Paket vom Re-INVITE, was bei dem LANCOM eintrifft, sind wieder 0.0.0.0 im SDP. Also das Problem hier: http://www.lancom-forum.de/all-ip-voip- ... 16671.html Von Telekom zu Telekom übrigens (Trunk zu normalem SIP-Account). Also wenn die Telekom jetzt T.38 einführen will, dann sollten die Probleme mit Re-INVITEs erst mal geklärt werden. Daraufhin wurde das Problem jetzt bei der Telekom auf Eskalation gesetzt. Der Kunde soll evt. an einem anderen Standort einen SIP-Trunk pure bekommen, wenn es damit nicht auftritt, werden alle Standorte umgestellt, weil die Klärung des Problems evt. länger braucht... Schauen wir mal.

Vielen Dank und viele Grüße,
Jirka

P.S.: Danke an Andreas und hyperjojo für die Tipps. Schauen wir mal. Ein Server läuft bei dem Kunden nicht Tag und Nacht, gut könnte ich bei mir laufen lassen.
Antworten