search

rolandgenske / fapfon-proxy

Workaround for FRITZ!App Fon SIP via VPN
GNU General Public License v2.0
6 stars 1 forks source link

Problems with incoming call #1

Open nightvisi0n opened 4 years ago

nightvisi0n commented 4 years ago

Hello,

at first: thanks for this great project. Wondering why it hasn't got more attention yet. I've setup it in order to use Fritz!App Fon over a Wireguard VPN. Outgoing calls now work fine, but I'm struggling with incoming calls. They don't reach the Fritz!App Fon. According to the tcpdump logs below, it seems like the NOTIFY and INVITE SIP-messages have the wrong destination IP-Address.

Addresses

IPv4 Host
10.5.1.51 VPN Server
10.5.1.11 Fritz!Box
10.5.10.10 Fritz!App Fon vpn address
192.168.1.101 Fritz!App Fon local address

Logs

fapfon-proxy ``` Apr 01 16:47:01 wireguard fapfon-proxy[7822]: 200401 164701 V3 Box address 10.5.1.11:5060 Apr 01 16:47:01 wireguard fapfon-proxy[7822]: 200401 164701 V3 TCP: Server SIP port 5060 Apr 01 16:47:01 wireguard fapfon-proxy[7822]: 200401 164701 V3 UDP: Server SIP port 5060 Apr 01 16:47:01 wireguard fapfon-proxy[7822]: 200401 164701 V1 Start fapfon-proxy version 0.3.1221 Apr 01 16:47:31 wireguard fapfon-proxy[7822]: 200401 164731 V3 [1] Connect 10.5.10.10:59484/udp, contact 'JulnsiPhone_WIGI45ak' ```
REGISTER, SUBSCRIBE, NOTIFY tcpdump ``` IP 10.5.1.51.59741 > 10.5.1.11.5060: UDP, length 563 E..O.V@.@.j. ..3 ....]...;..REGISTER sip:fritz.box SIP/2.0 Via: SIP/2.0/UDP 192.168.1.101:63346;rport;branch=z9hG4bKPjUh8D15qIqUsW7IFIVwvOCClSqsT.5jsU Max-Forwards: 70 From: ;tag=Wek6GoxtDZR92wpGs6MDK9Ye7ocjvBUn To: Call-ID: vnZTMwW3Cg0CynbSbFkHAvAyEHlSUtIe CSeq: 2013 REGISTER User-Agent: FRITZ!AppFon/2460 sip/2.8 Contact: Expires: 3600 Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS Content-Length: 0 IP 10.5.1.11.5060 > 10.5.1.51.59741: UDP, length 465 E.......@... ... ..3...]....SIP/2.0 401 Unauthorized Via: SIP/2.0/UDP 192.168.1.101:63346;rport=59741;branch=z9hG4bKPjUh8D15qIqUsW7IFIVwvOCClSqsT.5jsU;received=10.5.1.51 From: ;tag=Wek6GoxtDZR92wpGs6MDK9Ye7ocjvBUn To: ;tag=584AD20568DEA182 Call-ID: vnZTMwW3Cg0CynbSbFkHAvAyEHlSUtIe CSeq: 2013 REGISTER WWW-Authenticate: User-Agent: FRITZ!OS Content-Length: 0 IP 10.5.1.51.59741 > 10.5.1.11.5060: UDP, length 725 E....Y@.@.i[ ..3 ....].....gREGISTER sip:fritz.box SIP/2.0 Via: SIP/2.0/UDP 10.5.1.51:63346;rport;branch=z9hG4bKPj3yC9S0Zy-lL8Ka9Y2FpmE7xo11JjVaW1 Max-Forwards: 70 From: ;tag=Wek6GoxtDZR92wpGs6MDK9Ye7ocjvBUn To: Call-ID: vnZTMwW3Cg0CynbSbFkHAvAyEHlSUtIe CSeq: 2014 REGISTER User-Agent: FRITZ!AppFon/2460 sip/2.8 Contact: Expires: 3600 Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS Authorization: Content-Length: 0 IP 10.5.1.11.5060 > 10.5.1.51.59741: UDP, length 854 E..r....@... ... ..3...].^.LSIP/2.0 200 OK Via: SIP/2.0/UDP 10.5.1.51:63346;rport=59741;branch=z9hG4bKPj3yC9S0Zy-lL8Ka9Y2FpmE7xo11JjVaW1 From: ;tag=Wek6GoxtDZR92wpGs6MDK9Ye7ocjvBUn To: ;tag=CAEA059669F625E9 Call-ID: vnZTMwW3Cg0CynbSbFkHAvAyEHlSUtIe CSeq: 2014 REGISTER Contact: ;expires=2468 Contact: ;expires=3009 Contact: ;expires=3600 User-Agent: AVM FRITZ!Box 7490 113.07.12 (Jul 3 2019) Supported: 100rel,replaces,timer Allow-Events: telephone-event,refer,reg Allow: INVITE,ACK,OPTIONS,CANCEL,BYE,UPDATE,PRACK,INFO,SUBSCRIBE,NOTIFY,REFER,MESSAGE,PUBLISH Accept: application/sdp, multipart/mixed Accept-Encoding: identity Content-Length: 0 IP 10.5.1.51.59741 > 10.5.1.11.5060: UDP, length 649 E....`@.@.i. ..3 ....]......SUBSCRIBE sip:JulnsiPhone_WIGI45ak@fritz.box SIP/2.0 Via: SIP/2.0/UDP 10.5.1.51:63346;rport;branch=z9hG4bKPjkCp4PT3SDJLWE1rjbUPp0cgp51Fk4U05 Max-Forwards: 70 From: ;tag=FI3m7cFpVlduMY0SDxyL4uNMhFDrxeZ3 To: Contact: Call-ID: I8QKBFAzYIvNuN8PKQFUmx6DZoZlgz7E CSeq: 26407 SUBSCRIBE Event: message-summary Expires: 3600 Supported: replaces, 100rel, timer, norefersub Accept: application/simple-message-summary Allow-Events: presence, message-summary, refer User-Agent: FRITZ!AppFon/2460 sip/2.8 Content-Length: 0 IP 10.5.1.11.5060 > 10.5.1.51.59741: UDP, length 444 E.......@... ... ..3...]....SIP/2.0 401 Unauthorized Via: SIP/2.0/UDP 10.5.1.51:63346;rport=59741;branch=z9hG4bKPjkCp4PT3SDJLWE1rjbUPp0cgp51Fk4U05 From: ;tag=FI3m7cFpVlduMY0SDxyL4uNMhFDrxeZ3 To: ;tag=661836827C13CA6A Call-ID: I8QKBFAzYIvNuN8PKQFUmx6DZoZlgz7E CSeq: 26407 SUBSCRIBE WWW-Authenticate: User-Agent: FRITZ!OS Content-Length: 0 IP 10.5.1.51.59741 > 10.5.1.11.5060: UDP, length 836 E..`.d@.@.h. ..3 ....]...L..SUBSCRIBE sip:JulnsiPhone_WIGI45ak@fritz.box SIP/2.0 Via: SIP/2.0/UDP 10.5.1.51:63346;rport;branch=z9hG4bKPj2Sp4DhU52t-cksw9Amk4JMBgIdzmrG.N Max-Forwards: 70 From: ;tag=FI3m7cFpVlduMY0SDxyL4uNMhFDrxeZ3 To: Contact: Call-ID: I8QKBFAzYIvNuN8PKQFUmx6DZoZlgz7E CSeq: 26408 SUBSCRIBE Event: message-summary Expires: 3600 Supported: replaces, 100rel, timer, norefersub Accept: application/simple-message-summary Allow-Events: presence, message-summary, refer User-Agent: FRITZ!AppFon/2460 sip/2.8 Authorization: Content-Length: 0 IP 10.5.1.11.5060 > 10.5.1.51.59741: UDP, length 413 E.......@... ... ..3...]....SIP/2.0 200 OK Via: SIP/2.0/UDP 10.5.1.51:63346;rport=59741;branch=z9hG4bKPj2Sp4DhU52t-cksw9Amk4JMBgIdzmrG.N From: ;tag=FI3m7cFpVlduMY0SDxyL4uNMhFDrxeZ3 To: ;tag=EDB7DB8D63E63FB4 Call-ID: I8QKBFAzYIvNuN8PKQFUmx6DZoZlgz7E CSeq: 26408 SUBSCRIBE Expires: 3600 User-Agent: AVM FRITZ!Box 7490 113.07.12 (Jul 3 2019) Content-Length: 0 IP 10.5.1.11.5060 > 192.168.1.101.63346: UDP, length 627 E.......@... ......e...r.{.nNOTIFY sip:JulnsiPhone_WIGI45ak@192.168.1.101:63346;ob SIP/2.0 Via: SIP/2.0/UDP 10.5.1.11:5060;branch=z9hG4bK38EBE33FB3E47D6E From: ;tag=EDB7DB8D63E63FB4 To: ;tag=FI3m7cFpVlduMY0SDxyL4uNMhFDrxeZ3 Call-ID: I8QKBFAzYIvNuN8PKQFUmx6DZoZlgz7E CSeq: 26409 NOTIFY Contact: Event: message-summary Subscription-State: active;expires=3600 Max-Forwards: 70 User-Agent: AVM FRITZ!Box 7490 113.07.12 (Jul 3 2019) Content-Type: application/simple-message-summary Content-Length: 22 Messages-Waiting: no ```
INVITE tcpdump ``` IP 10.5.1.11.5060 > 192.168.1.101.64053: UDP, length 1191 E.......@..S ......e...5....INVITE sip:JulnsiPhone_WIGI45ak@192.168.1.101:64053;ob SIP/2.0 Via: SIP/2.0/UDP 10.5.1.11:5060;branch=z9hG4bK44DCAD7B042159A1 From: "Julian Neureuther" ;tag=2E72CAD7107ABBB3 To: Call-ID: F21D8515D8E8F14C@10.5.1.11 CSeq: 8 INVITE Contact: Max-Forwards: 70 P-Called-Party-ID: Expires: 120 Session-Expires: 600;refresher=uac Min-SE: 90 User-Agent: AVM FRITZ!Box 7490 113.07.12 (Jul 3 2019) 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: 351 v=0 o=user 9358401 9358401 IN IP4 10.5.1.11 s=call c=IN IP4 10.5.1.11 t=0 0 m=audio 7082 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-15 a=rtcp:7083 ```
rolandgenske commented 4 years ago

Hi, thank you very much for your feedback. I'm sorry for my late reply, being very busy over the last months so I didn't visit my account for some time. Thank you for your detailed problem report, I'll see what I can do as soon as possible. Have a wonderful day. Best regards, Roland

scriptkiddy666 commented 3 years ago

Hi, did you have time to have a closer look at it? I just tried it on my Pi Zero W with the latest Raspberry Pi OS as well and incoming calls aren't working for me either. Outgoing calls ring at least, I have not tried to see if I am heard. And I had to disable ufw during the test, because I have no idea how to add a correct rule for it to get it to work. Do you need additional logs? (How can I create the tcpdumps?)

Thank you for your great tool, I hope you can get it working again sometime :-)

charliesz commented 3 years ago

Just my workaround for this problem. I use Tasker to disable wireguard in my home network and restart the fritzfon app and connect wureguard when leaving my home network. Screenshot_20210106-133407 Screenshot_20210106-133441

rolandgenske commented 3 years ago

Hi, I am sorry but I cannot reproduce what you describe. Here are at least 7 sites where fapfon-proxy is used all the time, exactly working as described. My personal settings are FRITZ!Box 7490 (FRITZ!OS 07.21) and FRITZ!APP FON 4.1.8 on iOS14.3, OpenVPN server and fapfon-proxy running on a Raspberry Pi 3 Mod. B+ in my home network. Please note that the iptables configuration is essential so that the SIP packets are really going through fapfon-proxy. If you don't have an appropriate iptables configuration, SIP packets go to the FRITZ!Box directly and fapfon-proxy has no effect. You might use the fapfom-proxy --dump option to check what happens exactly. Hope this helps. Best regards, Roland

scriptkiddy666 commented 3 years ago

Hi Roland, sorry for my late response. I just tried it again and it's still not working. Maybe something else is wrong in my setup. May you have a look at the logs I attached? (They look ok to me, as far as I understand your technical details in the readme.)

IPv4 Host
192.168.2.99 Pi-hole and PiVPN (with WireGuard)
192.168.2.1 FRITZ!Box
10.6.0.2 Fritz!App Fon VPN address

I'm using a FRITZ!Box 7590 (also FRITZ!OS 07.21) with FRITZ!App Fon 4.1.8 also on iOS 14.3

Ah and regarding ufw, I just had to execute sudo ufw allow 5060 so no big issue here, I think I was confused about the random ports on the client side.

I created two dump logfiles with an outgoing call via an active VPN connection. The prerouting looks fine to me and if I'm starting the service the fapfon-proxy.log content also looks fine to me. Without VPN the FRITZ!App Fon is working quite fine, and with VPN it makes no difference if ufw is on or off.

dump_BOX.txt dump_FON.txt fapfon-proxy.log PREROUTING.txt

@charliesz I'm using iOS so Tasker isn't an option for me, but I tried it manually and it makes no difference in my setup. Wireguard automatically connects if I'm not connected to my home Wifi anymore and automatically disconnects if I'm connected again. I tried it with an opened FRITZ!App Fon while connected to Wifi and then I disconnected my Wifi.

Best regards Markus

mrgreywater commented 3 years ago

Same issue here. With wireguard and fapfon on a rpi, you can establish an outgoing call, but no voice is heard on either side. I can provide logs if necessary.

tboerner commented 3 years ago

Here we are experiencing the incoming call issue as well. Everything else is fine.

When trying to call the Fritz!App Fon, the call doesn't get through. In the log we find: 211013 171710 V3 Box address 192.168.11.1:5060 211013 171710 V3 TCP: Server SIP port 5060 211013 171710 V3 UDP: Server SIP port 5060 211013 171710 V1 Start fapfon-proxy version 0.3.1221 211013 172630 V3 [1] Connect 100.64.0.101:40124/udp, contact 'SHIFT6m-qCJc7NtE' 211013 172645 V3 Failed to process packet: No Via header 211013 172645 V3 Failed to process packet: No From header 211013 172645 V3 Failed to process packet: No To header 211013 172645 V3 Failed to process packet: No Content-Length header 211013 172645 V3 [1] Packet from 100.64.0.101:40124/udp not recognized - disconnecting 211013 172645 V2 [1] Disconnect 211013 172700 V3 Failed to process packet: No Via header 211013 172700 V3 Failed to process packet: No From header 211013 172700 V3 Failed to process packet: No To header 211013 172700 V3 Failed to process packet: No Content-Length header 211013 172700 V3 Packet from 100.64.0.101:40124/udp not recognized 211013 172715 V3 Failed to process packet: No Via header 211013 172715 V3 Failed to process packet: No From header 211013 172715 V3 Failed to process packet: No To header 211013 172715 V3 Failed to process packet: No Content-Length header 211013 172715 V3 Packet from 100.64.0.101:40124/udp not recognized 211013 172731 V3 Failed to process packet: No Via header 211013 172731 V3 Failed to process packet: No From header 211013 172731 V3 Failed to process packet: No To header 211013 172731 V3 Failed to process packet: No Content-Length header 211013 172731 V3 Packet from 100.64.0.101:40124/udp not recognized 211013 172731 V3 [2] Connect 100.64.0.101:40124/udp, contact 'SHIFT6m-qCJc7NtE'

...where 100.64.0.101 is the address of the phone connected via WireGuard.

I am also attaching two dumps (FON / BOX) of failed calls to the Fritz!App Fon. There are Via/From/To - headers present in the dumps.

fapfon-proxy.dump.txt

rolandgenske commented 3 years ago

Hello tboerner,

This is very helpful, thank you. However, at the moment I don't see how the failure messages are related to the dumped packets, so I would like to ask you to create a combined dump/log file using a command line like below:

fapfon-proxy --dump=FON --dump=BOX --verbose=3 -l- 192.168.11.1 2>&1 | tee fp.log

This will create a "log/dump all" file named fp.log in your current directory. The --dump output goes to stdout, the -l- switch causes the log messages to be output to stdout as well, the 2>&1 is there in case anything is output to stderr.

Best regards Roland Genske

tboerner commented 3 years ago

Hey Roland,

Of course - I was just wondering how to do it.

What I did:

Best, Thomas fp.log

rolandgenske commented 3 years ago

Hello Thomas,

I just pushed a new version with additional hexdump diagnostics in case a packet cannot be processed. If possible, please repeat the test invocation using this new version, I hope that this will indicate the cause of the problem.

Best regards Roland Genske

tboerner commented 3 years ago

Hello Roland,

here you are. I'm under the impression the unrecognized packets are just empty: 0d 0a

Cheers, Thomas fp.log

rolandgenske commented 3 years ago

Thank you Thomas, these appear to be SIP keep-alive packets, as I just learned. Just preparing a new release.

rolandgenske commented 3 years ago

New release just pushed, hoping that this solves the problem. Could not test it because those empty packets don't appear in my environment (iOS, OpenVPN).

tboerner commented 3 years ago

Thanks for your quick reaction, Roland! Unfortunately the Fritz Fon App still doesn't ring. fapfon-proxy now complains incomplete packets.

fp.log

rolandgenske commented 3 years ago

Sorry, overlooked that the next_packet() caller did not accept incomplete UDP packets. Just pushed new release.

tboerner commented 3 years ago

Sorry, no success yet. No complaints about incomplete packets any more, but no ring either. Double-check w/o VPN and fapfon-proxy works.

fp.log

rolandgenske commented 3 years ago

Thomas,

Thank you very much for your great help. It seems that there are significant differences in how the FRITZ!App Fon works on iOS vs. Android. The proxy assumes that the contact contains the private mobile phone provider address, which appears to be different on Android. As a consequence, the address is not rewritten so that the Box does not connect to the proxy on incoming calls. I need to check this in detail. You could help me by creating another log, this time about an outgoing call (completely with pickup and hangup), if possible. Please check whether or not you hear audio (on both sides) during that call. You can, of course, obscure the phone number in your log if you want. This would be very helpful, thank you very much.

Best regards Roland Genske

tboerner commented 3 years ago

Roland, Well, take it as my way to thank you for your work and your effort to make it available to a greater public :-)

fp-out.log contains a complete outgoing call from the Fritz App Fon to an external number. Audio was ok in both directions. fp-in.log shows an attempt to call the Fon App from the same external number. The App did not ring, as expected. I am adding this because before I always tried to call the Fon App from another DECT phone connected to the same Fritzbox (internal call). Perhaps you can see a difference.

Thanks again, and best regards Thomas

fp-in.log fp-out.log