Hi Raphael, > if i understood well your issue, you are using SEMS behind a NAT, > and the callers may also be behind another (or same) NAT. Is that > right?
Yes. (Though NAT on the client side shouldn't really be a problem right now (my own calls will be going through some NAT fixing stuff).) > The reason why it does not work at the moment is that it never has > been a covered scenario. That makes sense, then :) > As i understood, it would be enough for your scenario to be able to > configure the external IP (i guess you have some port forwarding > mechanism) (and maybe the external port also), is that right? That's my opinion, yes. So far as I can tell from my first look, putting the public IP in the Contact header and SDP body should make everything work; this should "just" mean splitting the bound listen address and the defined "public" address. There could be some hidden complexity here: e.g., what happens when SEMS is listening on two interfaces? Right now I expect it replies from the interface that received the message... > I would like to avoid to implement to much NAT traversal stuff like > STUN & Co., Agreed and understood! ICE and STUN are best avoided. > but i think that a possibility to configure the external IP and port > would be a pretty easy thing to do. Sweet. Is this something you'd rather do? I'm happy to work on it, and I promise to try not to break anything, but I can't promise that I'll succeed :D -R _______________________________________________ Semsdev mailing list [email protected] http://lists.iptel.org/mailman/listinfo/semsdev
