Auch bei mir laufen Outcalls per PSTN und VoIP korrekt.
Aber eingehende Anrufe klappen nicht; auf dem Asterisk, an dem ein VoIP-Phone (tel#: 12) und der Speedport500V mit Bitswitcher 0.3.6 (tel#: 14) hängen, meldet:
- Called 12
- Called 14
- SIP/12-f862 is ringing
- SIP/14-45c2 is ringing
- Got SIP response 486 "Busy Here" back from 192.168.16.19
- SIP/14-45c2 is busy
Wieso meldet Bitswitcher die 486 an den Asterisk?
Eingehende Rufe per PSTN funktionieren.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Das Fehlverhalten hat mich zuletzt nicht weiter gestört, aber jetzt sollten auch eingehende SIP-Anrufe funktionieren.
Mir ist zudem gerade nicht (mehr) klar, wieso das ein Problem von vodsl sein soll, da die Originalfirmware sicher Anrufe eines SIP-Accounts an das angeschlossene Analogtelefon durchstellt; ansonsten macht die VoIP-Telefonie nur halben Sinn. Oder ist/war bei der Konstruktion dieses Speedports nur die Funktionaltät angedacht, ein Analoganschluß per ausgehendem VoIP aufzupeppen, damit man günstiger raustelefoniert?
Laut https://sourceforge.net/projects/bitswitcher/forums/forum/799261/topic/4047508 ist es zumindest kurzzeitig möglich, Telefonate per SIP zu empfangen. Dies widerspricht der Meinung, daß der vodsl eingehende SIP-Anrufe nicht durchstellt bzw. gar nicht erst annimmt. Kann mir jemand diesen Widerspruch erklären?
Danke,
Stefan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Aktueller Stand: Bei der Firmwareversion 0.3.8 lag das Problem, daß keine eingehenden VoIP-Anrufe ankamen daran, daß die Option "Bandwidth Optimized Voice Compression: " mit Haken versehen war. Ohne den Haken die VoIP-Anrufe problemlos an (reproduzierbar) und es wurde der alaw -Codec benutzt bei diesem Gespräch.
Mit Version klappt es derzeit sogar mit der Option "Bandwidth Optimized Voice Compression: "; evtl. ein neuer Codec in der Firmware des Speedport oder ich habe zwischenzeitlich etwas an den Codecs meines Asterisk gedreht. Für ausgehende Telefonate wurde bei einem Testtelefonat der g729-Codec verwendet, wobei eingehende Telefonate auch bei aktivierter Option der "nicht-bandbreiten-optimierte" alaw-Codec im Einsatz ist.
Soweit, so gut, und vielen Dank für die neue FW-Version,
Stefan Welte
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hallo,
ich habe seit dem Update auf die Version 3.4 folgendes Problem, auch ein zurückgehen auf die Vorversion brachte keine Lösung:
Outcalls laufen perfekt.
Incalls kommen nicht zu stande mit folgender Fehlermeldung (nur bei Carpo, Sipgate läuft gut):
(Terminal)
InternalEvSesInvited: Unsupported media type for MxCall 100:09:47 cmEptEventCb: op1 0, op2 17
(auf Protokollebene sieht es wie folgt aus)
< ... Ausschnitt>
23:05:42.413999 IP (tos 0x0, ttl 47, id 0, offset 0, flags [DF], proto UDP (17), length 402) 80.95.252.5.5060 > 77.12.255.60.5060: SIP, length: 374
SIP/2.0 486 Besetzt
Via: SIP/2.0/UDP 77.12.255.60;rport=5060;branch=z9hG4bK081772eb4
To: 00491783421301 <sip:0049178xxxxxxx@sip.carpo.de>;tag=652091636
From: muttiklimt <sip:mxxxxxxxt@carpo.de>;tag=e7f967583138ee2
Call-ID: cd50e89b136913be5433af9560e13756@77.12.255.60
CSeq: 1202726429 INVITE
Server: SER/iptego (2.1.0-dev18-tcp (x86_64/linux))
Content-Length: 0
23:05:42.417999 IP (tos 0x0, ttl 64, id 12, offset 0, flags [DF], proto UDP (17), length 639) 77.12.255.60.5060 > 80.95.252.5.5060: SIP, length: 611
ACK sip:00491783421301@sip.carpo.de SIP/2.0
Via: SIP/2.0/UDP 77.12.255.60;branch=z9hG4bK081772eb4
Max-Forwards: 70
Content-Length: 0
To: 004917xxxxxxx <sip:0049178xxxxxxx1@sip.carpo.de>;tag=652091636
From: muttiklimt <sip:mxxxxxxxt@carpo.de>;tag=e7f967583138ee2
Call-ID: cd50e89b136913be5433af9560e13756@77.12.255.60
CSeq: 1202726429 ACK
Proxy-Authorization:Digest response="dcf43ef24d778603187e5a8ae5b27298",username="mxxxxxxxt",realm="carpo",nonce="49f2bd9630b3492c538ebc05f015fbcbbc593582",uri="sip:0049xxxxxxxx1@sip.carpo.de"
User-Agent: T-Com Speedport W500V / Firmware v1.37 MxSF/v3.2.6.26
INVITE sip:muttiklimt@77.12.255.60 SIP/2.0
Record-Route: <sip:80.95.252.5;lr=on>
Record-Route: <sip:80.95.252.14:5070;lr=on>
Record-Route: <sip:80.95.252.5;lr=on>
Via: SIP/2.0/UDP 80.95.252.5;branch=0
Via: SIP/2.0/UDP 80.95.252.14:5070;rport=5070;branch=z9hG4bKf2c8.5f630527.0
Via: SIP/2.0/UDP 80.95.252.5;branch=0
Via: SIP/2.0/UDP 93.92.132.132;rport=5060;branch=z9hG4bKf2c8.b4e75b7.0
t: +493xxxxxxx <sip:004xxxxxxx4@carpo.de;user=phone>
f: +491xxxxxxx1 <sip:+4917xxxxxxx@carpo.de;user=phone>;tag=bb-1054353580
CSeq: 1000 INVITE
i: 40210496-193947fb-567ee418-77b7@subscriber2.interconnect.mgc.voip.telefonica.de
l: 455
User-Agent: SER/iptego (2.1.0-dev18-tcp (x86_64/linux))
Max-Forwards: 11
Allow: INVITE,CANCEL,BYE,ACK,PRACK
c: application/sdp
m: +49178xxxxxxx <sip:+49xxxxxxx@93.92.132.132:5060>
v=0
o=- 489924 0 IN IP4 62.53.160.3
s=Cisco SDP 0
c=IN IP4 62.53.160.3
t=0 0
m=audio 17300 RTP/AVP 8 0 101 18 102 103 4 99 100
a=rtpmap:101 G726-32/8000
a=rtpmap:102 G729a/8000
a=rtpmap:103 G729b/8000
a=rtpmap:99 telephone-event/8000
a=fmtp:99 0-15
a=rtpmap:100 X-NSE/8000
a=fmtp:100 192-194,200-202
a=X-sqn:0
a=X-cap: 1 audio RTP/AVP 100
a=X-cpar: a=rtpmap:100 X-NSE/8000
a=X-cpar: a=fmtp:100 192-194,200-202
a=X-cap: 2 image udptl t38
23:05:45.925999 IP (tos 0x0, ttl 64, id 13, offset 0, flags [DF], proto UDP (17), length 631) 77.12.255.60.5060 > 80.95.252.5.5060: SIP, length: 603
SIP/2.0 100 Trying
Call-ID: 40210496-193947fb-567ee418-77b7@subscriber2.interconnect.mgc.voip.telefonica.de
CSeq: 1000 INVITE
From: +491783421301 <sip:+4917xxxxxxx@carpo.de;user=phone>;tag=bb-1054353580
To: +493914089674 <sip:00493914089674@carpo.de;user=phone>;tag=6315ad688fbd2a7
Via: SIP/2.0/UDP 80.95.252.5;branch=0
Via: SIP/2.0/UDP 80.95.252.14:5070;branch=z9hG4bKf2c8.5f630527.0;rport=5070
Via: SIP/2.0/UDP 80.95.252.5;branch=0
Via: SIP/2.0/UDP 93.92.132.132;branch=z9hG4bKf2c8.b4e75b7.0;rport=5060
Content-Length: 0
User-Agent: T-Com Speedport W500V / Firmware v1.37 MxSF/v3.2.6.26
23:05:45.929999 IP (tos 0x0, ttl 64, id 14, offset 0, flags [DF], proto UDP (17), length 770) 77.12.255.60.5060 > 80.95.252.5.5060: SIP, length: 742
SIP/2.0 415 Unsupported Media Type
Call-ID: 40210496-193947fb-567ee418-77b7@subscriber2.interconnect.mgc.voip.telefonica.de
CSeq: 1000 INVITE
From: +491783421301 <sip:+491xxxxxxx@carpo.de;user=phone>;tag=bb-1054353580
To: +493914089674 <sip:00493xxxxxxx@carpo.de;user=phone>;tag=6315ad688fbd2a7
Via: SIP/2.0/UDP 80.95.252.5;branch=0
Via: SIP/2.0/UDP 80.95.252.14:5070;branch=z9hG4bKf2c8.5f630527.0;rport=5070
Via: SIP/2.0/UDP 80.95.252.5;branch=0
Via: SIP/2.0/UDP 93.92.132.132;branch=z9hG4bKf2c8.b4e75b7.0;rport=5060
Record-Route: <sip:80.95.252.5;lr=on>
Record-Route: <sip:80.95.252.14:5070;lr=on>
Record-Route: <sip:80.95.252.5;lr=on>
Content-Length: 0
User-Agent: T-Com Speedport W500V / Firmware v1.37 MxSF/v3.2.6.26
23:05:46.031999 IP (tos 0x0, ttl 47, id 0, offset 0, flags [DF], proto UDP (17), length 557) 80.95.252.5.5060 > 77.12.255.60.5060: SIP, length: 529
ACK sip:mutxxxxxxx@77.12.255.60 SIP/2.0
Max-Forwards: 10
Via: SIP/2.0/UDP 80.95.252.5;branch=0
Via: SIP/2.0/UDP 80.95.252.14:5070;rport=5070;branch=z9hG4bKf2c8.5f630527.0
f: +491xxxxxxx<sip:+4917xxxxxxx@carpo.de;user=phone>;tag=bb-1054353580
i: 40210496-193947fb-567ee418-77b7@subscriber2.interconnect.mgc.voip.telefonica.de
To: +493xxxxxxx<sip:004xxxxxxx@carpo.de;user=phone>;tag=6315ad688fbd2a7
CSeq: 1000 ACK
User-Agent: Sip EXpress router(0.10.99-iptelorg/tekelec-SOPv2 (i386/linux))
Content-Length: 0
Für Hinweise wäre ich sehr dankbar.
Gruß
Christoph
Auch bei mir laufen Outcalls per PSTN und VoIP korrekt.
Aber eingehende Anrufe klappen nicht; auf dem Asterisk, an dem ein VoIP-Phone (tel#: 12) und der Speedport500V mit Bitswitcher 0.3.6 (tel#: 14) hängen, meldet:
- Called 12
- Called 14
- SIP/12-f862 is ringing
- SIP/14-45c2 is ringing
- Got SIP response 486 "Busy Here" back from 192.168.16.19
- SIP/14-45c2 is busy
Wieso meldet Bitswitcher die 486 an den Asterisk?
Eingehende Rufe per PSTN funktionieren.
Leider kann Bitswitcher an diesem Verhalten nichts ändern. Wie schon so oft liegt das Problem beim Closed-Source Broadcom SIP-Client 'vodsl'.
Das Fehlverhalten hat mich zuletzt nicht weiter gestört, aber jetzt sollten auch eingehende SIP-Anrufe funktionieren.
Mir ist zudem gerade nicht (mehr) klar, wieso das ein Problem von vodsl sein soll, da die Originalfirmware sicher Anrufe eines SIP-Accounts an das angeschlossene Analogtelefon durchstellt; ansonsten macht die VoIP-Telefonie nur halben Sinn. Oder ist/war bei der Konstruktion dieses Speedports nur die Funktionaltät angedacht, ein Analoganschluß per ausgehendem VoIP aufzupeppen, damit man günstiger raustelefoniert?
Die Doku (http://bitswitcher.sourceforge.net/doku.html#ata) erwähnt diesbzgl. keine Einschränkung!?
Oder ist etwa dies (http://bitswitcher.sourceforge.net/faq.html#frage5) des Problems Lösung?
Danke im Voraus für die Klarstellung,
Stefan Welte
Laut https://sourceforge.net/projects/bitswitcher/forums/forum/799261/topic/4047508 ist es zumindest kurzzeitig möglich, Telefonate per SIP zu empfangen. Dies widerspricht der Meinung, daß der vodsl eingehende SIP-Anrufe nicht durchstellt bzw. gar nicht erst annimmt. Kann mir jemand diesen Widerspruch erklären?
Danke,
Stefan
Hallihallo zusammen,
hat niemand eine Erklärung parat?
Danke,
Stefan
Aktueller Stand: Bei der Firmwareversion 0.3.8 lag das Problem, daß keine eingehenden VoIP-Anrufe ankamen daran, daß die Option "Bandwidth Optimized Voice Compression: " mit Haken versehen war. Ohne den Haken die VoIP-Anrufe problemlos an (reproduzierbar) und es wurde der alaw -Codec benutzt bei diesem Gespräch.
Mit Version klappt es derzeit sogar mit der Option "Bandwidth Optimized Voice Compression: "; evtl. ein neuer Codec in der Firmware des Speedport oder ich habe zwischenzeitlich etwas an den Codecs meines Asterisk gedreht. Für ausgehende Telefonate wurde bei einem Testtelefonat der g729-Codec verwendet, wobei eingehende Telefonate auch bei aktivierter Option der "nicht-bandbreiten-optimierte" alaw-Codec im Einsatz ist.
Soweit, so gut, und vielen Dank für die neue FW-Version,
Stefan Welte