Stefan Sayer wrote:
> 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.
>
>
And what about Contact address and Via?
-Raphael.
> 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
>>
>>
>
>
>
_______________________________________________
Semsdev mailing list
[email protected]
http://lists.iptel.org/mailman/listinfo/semsdev
