Hallo, 

ich habe oft die Situation das ich mich mit meinem Rechner über verschiedene Netzwerkkarten
in verschiedenen Subnetzen befinde. (z.B. WLAN für Internet, RJ45 für SIP Telefonie).

Bisher (PhonerLite 1.14) konnte ich wunderbar die IP auswählen was auch immer funktioniert hat.

Jetzt (mit 1.21) versucht PhonerLite diese automatisch zu erkennen was  zu dem Problem
führt das, z.B. das SIP - REGISTER über das 'richtige' Interface abgeschickt wird (richtig in dem
Sinne , das Interface welches per routing Tabelle für das Subnet des SIP-Registrar/Proxy konfiguriert ist) ,
dann aber in den Contact Header , die Adresse des anderen Interfaces eingefügt wird ...

z.B. (meine IP fürs SIP: 80.228.245.181 , im Contact aber meine 2.IP : 192.168.1.5 ):

Session Initiation Protocol
    Request-Line: REGISTER sip:sipreg.provider.de SIP/2.0
       Method: REGISTER
       [Resent Packet: False]
    Message Header
       Via: SIP/2.0/UDP 80.228.245.181;branch=z9hG4bK00c98221b5b9db1192d2005056c00008;rport
           Transport: UDP
           Sent-by Address: 80.228.245.181
           Branch: z9hG4bK00c98221b5b9db1192d2005056c00008
           RPort: rport
       From: PhonerLite <sip:49311845003@sipreg.provider.de>;tag=28751
           SIP Display info: PhonerLite 
           SIP from address: sip:49311845003@sipreg.provider.de
           SIP tag: 28751
       To: <sip:49311845003@sipreg.provider.de>
           SIP to address: sip:49311845003@sipreg.provider.de
       Call-ID: 8051F41A-B5B9-DB11-92D2-005056C00008@80.228.245.181
       CSeq: 1 REGISTER
           Sequence Number: 1
           Method: REGISTER
       Contact: <sip:49311845003@192.168.1.5>
           Contact Binding: <sip:49311845003@192.168.1.5>
               URI: <sip:49311845003@192.168.1.5>
                   SIP contact address: sip:49311845003@192.168.1.5
       Max-Forwards: 70
       User-Agent: SIPPER for PhonerLite
       Expires: 900
       Content-Length: 0


Das ist erstens zumindest unschön und zweitens in den meisten Fällen zum Scheitern verurteilt, da selbst wenn der Registrar diese Registrierung akzeptiert, errreicht er den Teilnehmer oftmals nicht unter dieser anderen IP (Routing u. NAT Probleme).

Somit bin ich momentan gezwungen eine alte Version zu verwenden, wo ich doch gern auch an den Verbesserungen
partizipieren würde.

Danke für dieses wirklich brauch- und  easy bedienbare Sip- Softphone

Thorsten

mit 1.22beta komme ich zum gleichen (negativen) Egebnis.

allerdings ... durch die 'richtige' Adresse im via Header bekomme ich schon Antwort
auf das Register (scheint also nicht unbedingt ein Routingproblem wie inital vermutet zu sein)
allerdings meint mein Registrar '404 not found'.

Zur Probe habe ich einfach mal das WLAN Interface (192....) abgeschaltet, und ohne jegliche
Konfigurationsänderung geht die Registrierung jetzt durch (einziger auf den ersten Blicksichtbarer Unterschied ist, das jetzt im Contact auch die 80.288..er Adressee steht)

Wenn man dann im RFC 3261 schaut meint dieser:
Contact: REGISTER requests MAY contain a Contact header field with
          zero or more values containing address bindings.

Somit scheint sich mein Registrar auch  nicht ganz korrekt zu verhalten, wenn er das 
'404 not found' auf Basis der Daten im Contact header schickt.

Trotzdem denke ich, wegen (auch aus RFC 3261 ):
  That is, the Contact header field value contains
   the URI at which the UA would like to receive requests ....

sollte im Contact header die IP stehen, welche benutzt wird um den Proxy zu erreichen.

ist unterwegs als PM an info@phoner.de

ich habe eine domain angegeben - mein registrar verwaltet diese Domäne, und die Nutzer sind
auch als <TelNummer>@Domäne eingetragen. Der Domänen FQDN ist auch in meiner Umgebung
nicht via DNS auflösbar. Die IP des Proxy spezifiziert genau den Proxy/Registrar zu dem ich die
SIP Messages schicke.

Thorsten

Es gibt nun offiziell eine neue PhonerLite-Version: 1.22
Kannst du es mit dieser bitte ausprobieren? Da sollte nun hoffentlich auch die richtige IP-Adresse drin stehen.

Per Mail habe ich erfahren, dass es mit der Version 1.23 nun funktioniert.