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 ?
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.
All these problems vanish if all pjsua instances specify --ip-addr 127.0.0.1.
Julian
---------------------------------
Rise to the challenge for Sport Relief with Yahoo! for Good
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20080305/e2374060/attachment.html
