Hi Pablo,
On Fri, Feb 15, 2019 at 4:07 PM Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote:
>
> Hi Alin,
>
> On Fri, Feb 15, 2019 at 02:20:14PM +0100, Alin Năstac wrote:
> > On Fri, Feb 15, 2019 at 1:02 PM Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote:
> [...]
> > > On Mon, Dec 24, 2018 at 08:15:19AM +0100, Alin Nastac wrote:
> > > > When enabled, the sip_external_media logic will leave SDP
> > > > payload untouched when it detects that interface towards INVITEd
> > > > party is the same with the one towards media endpoint.
> > > >
> > > > The typical scenario for this logic is when a LAN SIP agent has more
> > > > than one IP address (uses a different address for media streams than
> > > > the one used on signalling stream) and it also forwards calls to a
> > > > voice mailbox located on the WAN side. In such case sip_direct_media
> > > > must be disabled (so normal calls could be handled by the SIP
> > > > helper), but media streams that are not traversing this router must
> > > > also be excluded from address translation (e.g. call forwards).
> > >
> > > This patch got stuck in my queue right before holidays. I'm very sorry
> > > about that.
> > >
> > > Still one more question: Now that we have explicit helper assignment
> > > via rule, and assuming automatic helper assignment is deprecated
> > > (actually, disabled by default these days since it is unsecure [1]).
> > >
> > > Would it be possible to skip this via explicit ruleset policy?
> >
> > Parameters such as sip_direct_signalling and sip_external_media
> > (latter being implemented in this patch) are global switches.
> > I guess we can implement them as sip helper parameters configurable
> > through the rule that enables the helper, but I haven't found yet a
> > helper that has such parameters ("-j CT --helper xxx" rules don't
> > allow passing any additional helper parameters). Probably their
> > values will have to be stored in nf_ct_sip_master struct associated
> > with the master conntrack.
>
> Hm, I was wondering if we could restrict the rule that comes with "-j
> CT --helper xxx" to skip these flows, but we need to inspect them to
> classify them as media flow... right? Given you check for the route to
> see if the media endpoint is reachable through the same interface, I'm
> thinking if it's possible to make it from the policy side. If helper
> is the only place where we can do this, that's fine too, I'm just
> exploring :-).
Actually almost all RELATED conntracks are media streams except the
one created at registration time with dport set to the WAN side port
of the master conntrack (usually 5060).
However, in this patch I don't try to block media streams that
traverse the box, The goal here is to avoid mangling SDP payload that
have to be forwarded as it was transmitted by the LAN host, to allow
media streams between 2 WAN side endpoints to contact each other
directly. So you see this decision cannot be taken outside the helper
context, because it is not the kind of ACCEPT/DROP dilemma. Signalling
packet needs to be always ACCEPTed, but its SDP payload need to be
translated only when the IP address transmitted by the LAN host as its
media stream address is behind the NAT box.
In other words, sip_external_media=1 is modifying the
sip_direct_media=0 behavior:
- master conntrack NATed, sip_direct_media=0, sip_external_media=0 :
SDP payload is always mangled by nf_nat_sip.c
- master conntrack NATed, sip_direct_media=0, sip_external_media=1 :
SDP payload is mangled when new media stream(s) will traverse the box
