pjsip-2.0, STUN and public_addr

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

I'm switching to pjsip-2.0 and I'm wondering something about the way 
media transport is created.
My question is linked to ticket 539, and maybe what I'll ask for is 
already planned :).

It sounds that there is now already an option to setup per account media 
transport settings. That's great and it could solve an issue raised by 
many users that expect to be able to use a sip server in their LAN at 
the same time than a public sip server.

However, regarding source code, I'm wondering if it will go fine with 
the STUN setting.
As far as I can understand from the code, if there is stun server 
configured in pjsua_var, it will be used first. Then, if no stun server 
are set, it will use the public_addr from account (and then try to 
fallback to bound_addr).

The point is that using this approach, in the use case you don't want an 
account to use the stun server useful for other accounts, you'll not be 
able to send the public_addr in the neg and it will still use the 
address resolved by the stun server. Correct me if I'm wrong, that's 
just my first impression by reading source code.

I guess, that in one way this approach can reply to another use case (if 
you don't want the public_addr to have a bigger priority than stun 
server). But I think that it would be nice to have either :

  * One option in account media transport to tell that we don't want to 
use STUN for this transport
-- OR (would be much more powerful I think) --
  * A stun server cfg per media transport (or maybe per transport). And 
a way to say that we'd like to use the global stun server config (by 
default to true).

Is that planned, or is there already a way to do that with current 
pjsip-2.0 alpha release?

Thx in advance,
R?gis



[Index of Archives]     [Asterisk Users]     [Asterisk App Development]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [Linux API]
  Powered by Linux