On 3/5/08, Julian Cable <julian.cable at yahoo.com> wrote: > Hi Benny, > > I can reproduce the problem with pjsua. I'm not surprised it doesn't come > up in many more real scenarios. > > Platform: > > laptop which was connected wirelessly with ip address 192.168.2.195 but is > now not connected and the ethernet interface has been brought down. the > hostname is still resolvable to 192.168.2.195. I think this is why pjsip > gets it wrong. > > two terminals open on the desktop. > > Terminal A runs: > $ pjsua --local-port 5061 --auto-answer 200 > > Terminal B runs > $ pjsua --local-port 5062 --auto-answer 200 > > in Terminal B dial terminal A using: > >>> m > sip:localhost:5061 > > Afterwards A is left in the CONNECTING state and B is in the CONFIRMED > state. > > What happens is that A sends the 200 OK to 127.0.0.1:5062 but B tries to > send the ACK to 192.168.2.195:5061. > > I guess this is probably what the protocol spec says, but its strange. > > If there is a bug in pjsua its that it sets its localuri from the hostname, > but doesn't use the results of gethostbyname to chose the outgoing interface > ? The problem is that the IP address has changed during run-time, and pjsua does not support this for now. Sorry. What should be done by the application is to detect the IP address change itself, then re-instantiate all SIP and media transports and re-register all the accounts manually. If you used STUN, then there is a bit of support for IP address change, although this won't happen immediately (it'll be detected on the next register refresh). > I also saw a different problem where the response goes to 5060. I think I > can reproduce this. If I run three instances of pjsua, call A from B, and > then get A to tell B to transfer to C then the NOTIFY doesn't go back to A > but to port 5060. > I tested call transfer on the same call sometime ago and I didn't recall any problems. I did not change my IP address during the test of course. cheers, -benny > All these problems vanish if all pjsua instances specify --ip-addr > 127.0.0.1. > > Julian
