Hi,
Raphael Coeffic wrote:
>
> Hi Richard,
>
> if you whish to add those config parameters, please go ahead!
> The only recommendation would be: please try to avoid having SEMS core
> headers bound into anything else than SipCtrlInterface.{h,cpp}. I know
to me it seems this doesn't have anything to do with SIP stack, its only
about advertised media connection address. Just replacing the string used
for localip in the calls to sdp.genRequest/sdp.genResponse in
AmSession.cpp should do it.This will not work for NAPT, of course, only for NAT. Btw, SEMS can not use more than one IF for media. one for signalling, and one for media is possible though. Stefan > that the outbound proxy stuff is used directly from trans_layer.cpp, but > i think we should try to avoid that. I was still hoping being able to > re-use the sip stack somewhere else ;-) > > Thanks, > Raphael. > > Richard Newman wrote: >> 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 > -- Stefan Sayer VoIP Services iptego GmbH Am Borsigturm 40 13507 Berlin Germany [EMAIL PROTECTED] www.iptego.de _______________________________________________ Semsdev mailing list [email protected] http://lists.iptel.org/mailman/listinfo/semsdev
