Hallo,

Wenn ich PhonerLite auf einem PC verwende, der über ein VPN mit dem SIP Server verbunden ist, höre ich kein Klingeln beim Verbindungsaufbau und auch danach kein Audio vom Angerufenen.

Warum das so ist, habe ich bereits herausgefunden, bei den Recherchen zum selben Problem mit Linphone (siehe https://github.com/BelledonneCommunications/linphone-sdk/issues/487)

Bei PhonerLite hier ist es so:

Der PC hat die Adresse: 10.27.96.3 und den Port 5060
Der VPN Server hat die Addresse 192.168.17.17, mit der er dem SIP Server kommunziert.
Der Asterisk SIP Server Addresse 192.168.17.20, und weiß über einen ip route add Eintrag dass er Pakete für 10.27.96.3 an 192.168.17.17 schicken soll.

beim Register liefert der SIP Server ein Via mit 
  Via: SIP/2.0/UDP 10.27.96.3:5060;rport=5060;received=192.168.17.17;
zurück, als Mitteilung dass er die Pakete von der Adresse 192.168.17.17 erhalten hat.

PhonerLite ändert daraufhin seinen Contact
von
  Contact: <sip:100@10.27.96.3>;
zu
  Contact: <sip:100@192.168.17.17>;

was richtig ist, damit der Server weiß, wohin er ankommende Anrufe leiten soll.
Meiner Meinung nach müsste auch der Port mit angegeben werden, aber wohl nur, wenn er sich ändert.
also
  Contact: <sip:100@192.168.17.17:5060>;

Weiterhin ändert PhonerLite auch den Via Header von
  Via: SIP/2.0/UDP 10.27.96.3:5060;rport
zu
  Via: SIP/2.0/UDP 192.168.17.17:5060;rport
was gem o.g. Diskussion mit dem Linphone Entwickler laut rfc3261 nicht richtig ist.

Der Fehler mit dem fehlenden Ton kommt aber hierher:

  PhonerLite ändert auch die IP Adresse für die SDP Header, die beim INVITE gesendet werden:
  v=0
  o=- 2310767077 1 IN IP4 192.168.17.17
  s=PhonerLite/3.28
  c=IN IP4 192.168.17.17
  t=0 0
  m=audio 5062 RTP/AVP 8 0 3 9 18 101
  a=rtpmap:8 PCMA/8000
  a=rtpmap:0 PCMU/8000
  a=rtpmap:3 GSM/8000
  a=rtpmap:9 G722/8000
  a=rtpmap:18 G729/8000
  a=fmtp:18 annexb=yes
  a=rtpmap:101 telephone-event/8000
  a=fmtp:101 0-16
  a=ssrc:1701667894 cname:100@192.168.17.17
  a=sendrecv

Die ankommenden Audio SDP Pakete werden nun an 192.168.17.17 geschickt statt an 10.27.96.3

Wenn man hier die originale Adresse drin lässt, funktioniert es. Also:

  ...
  o=- 2310767077 1 IN IP4 10.27.96.3
  s=PhonerLite/3.28
  c=IN IP4 10.27.96.3
  ...

Dieser Beitrag ist also ein Change Request, die Adresse des PCs mit PhonerLite in den SDP Headern zu belassen.

Ja das funktioniert auch, dass die lokale IP Adresse erkannt wird. In meinem Fall wie beschrieben ist es 10.27.96.3.

Und diese Adresse sollte eben in den SDP Headern beim INVITE eingetragen werden. Und nicht die Adresse vom VPN Router, die beim OK nach INVITE über den "received" Parameter zurück geliefert wird.

Mit Fritzbox VPN Wireguard ist das Szenario etwas anders. Da ist die lokale IP 192.168.17.72 und diese wird auch über den "received" Parameter zurück geliefert. Deshalb funktioniert es da. 

Man kann auch einen Standard Wireguard VPN so konfigurieren, dass die Adresse des SIP Servers vom "iptables -j MASQUERADE ausgenommen wird. Dann funktioniert es auch mit dem jetzigen Verhalten von PhonerLite. Schön wäre es halt, wenn das nicht nötig wäre.

"Patch due rport" war tatsächlich  angekreuzt.

PhonerLite über Wireguard VPN funktioniert dann nicht, weil die Adresse 10.27.96.3 SDP Header durch 192.168.17.17 überschrieben wird:

o=- 4030269749 1 IN IP4 192.168.17.17
s=PhonerLite/3.28
c=IN IP4 192.168.17.17

Wenn man das Häkchen rausmacht, also "Patch due rport" nicht angekreuzt:

PhonerLite über Wireguard VPN funktioniert, weil die Adresse 10.27.96.3 im SDP Header erhalten bleibt

o=- 3400213675 1 IN IP4 10.27.96.3
s=PhonerLite/3.28
c=IN IP4 10.27.96.3

siehe beiliegende Logfiles (in ohne_mit_rport.txt)

Der Server weiß aber jetzt nicht mehr, wie er für einen  Anruf (INVITE) die Adresse 10.27.96.3 erreicht, wenn die 192.168.17.17 nicht mehr in den Contact geschrieben wird:
Contact: <sip:820@10.27.96.3>; statt Contact: <sip:820@192.168.17.17>;

Dazu gibt es 3 mögliche Lösungen
1) PhonerLite schreibt auch ohne "Patch due rport" nur (!) den Contact wie mit "Patch due rport"
2) im Asterisk macht man den Eintrag: 
rewrite_contact=yes  ; necessary if endpoint does not know/register public ip:port

On inbound SIP messages from this endpoint, the Contact header or an appropriate Record-Route header will be changed to have the source IP address and port. This option does not affect outbound messages sent to this endpoint. This option helps servers communicate with endpoints that are behind NATs. This option also helps reuse reliable transport connections such as TCP and TLS.

3) man erstellt eine Route auf dem Asterisk Server:
sudo ip route add 10.27.96.3/24 via 192.168.17.17

Lösung 3) ist bei mir sowieso schon eingerichtet, da die Adresse 10.27.96.3 ja auch für den SDP bekannt sein muss.

Somit funktioniert alles bestens.

Danke für die schnelle Reaktion und Unterstützung !