[Freeswitch-users] Profile configuration

[Kamigishi Rei]

Hello,

I have the following question regarding FS profile setup: is it
considered normal to only have one profile at all? (The server is not
behind a NAT/firewall; LAN users have direct routes to it.)

From what I gather from the sample configuration, it's pretty much
possible to distinguish between authenticated ("our own") users and
external SIP requests via the dialplan.
Quoting,

    <extension name="check_auth" continue="true">
      <condition field="${sip_authorized}" expression="^true$"
break="never">
        <anti-action application="respond" data="407"/>
      </condition>
    </extension>

    <extension name="transfer_to_default">
      <condition>
        <action application="transfer" data="${destination_number} XML
default"/>
      </condition>
    </extension>

Basically, I'd like FS to accept all calls (internal and external alike)
on 5060, and use 5070 for external providers we register with.
To get the "internal" profile to work like that on 5060, I have to
comment the "apply-inbound-acl" setting (sip_profiles/internal.xml), and
disable auth checking (internal_auth_calls=false in vars.xml).

Would that be the correct solution, or is that somehow considered
"insecure"? According to internal.xml, all non-authenticated (without
user_context defined) calls fall into the public context anyway, and
having an "is the user authenticated?" check in the public context
allows us to transfer the call to the correct dialplan—so what are the
security risks then?

Speaking of which, is there a point in having user_context defined for
users who need the default context, if they can just be redirected to
that context via check_auth extension of the public context?

Thanks in advance.

-- 
Kamigishi Rei
KREI-RIPE


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 479 bytes
Desc: OpenPGP digital signature
Url : http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20110112/495808b9/attachment-0001.bin