On 1/9/18, 12:44 PM, "ovs-dev-boun...@openvswitch.org on behalf of Darrell
Ball" <ovs-dev-boun...@openvswitch.org on behalf of db...@vmware.com> wrote:
On 1/9/18, 11:33 AM, "ovs-dev-boun...@openvswitch.org on behalf of Mark
Michelson" <ovs-dev-boun...@openvswitch.org on behalf of mmich...@redhat.com>
wrote:
On 12/22/2017 01:53 PM, Tiago Lam wrote:
> This patch-set is an initial approach at implementing the new SIP Alg,
> mentioned by Aaron at [1].
>
> I'm mostly interested in getting to know your thoughts of how this is
> headed. There are a couple of points that are worth bringing up:
> - As mentioned in patches 1/3 and 2/3, this is still a preliminary
> implementation, and some work will be needed to move away from some
> assuptions, like assuming the SIP traffic is always going over IPv4
> and TCP;
> - At the moment, the sip state is being stored in the conn struct. I
> followed the example of seq_skew_dir here, which is also stored
there,
> but realise this is not ideal. It seems storing it somewhere
agnostic
> will be ideal in the future, to avoid polluting that struct with
> different Alg's details;
> - The SIP helpers functions and structures are in conntrack-sip.h and
> conntrack-sip.c. This can create confusion when comparing to
> conntrack-tcp.c and other protocols since SIP is an Alg and is at a
> different level.
>
> With regards to testing, for now, this has been tested manually, by
> setting up the flows mentioned in patch 2/3 and having two VMs
connected
> to OvS, both using SIPp to simulate real traffic both ways. I'm going
to
> have a look at how this can be automated and added to
> tests/system-traffic.at, together with the rest of the already
existing
> tests.
>
> [1] [CONNTRACK] Discussions at OvS 2017:
>
https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_pipermail_ovs-2Ddev_2017-2DNovember_341089.html&d=DwICAg&c=uilaK90D4TOVoH58JNXRgQ&r=BVhFA09CGX7JQ5Ih-uZnsw&m=XHeuwSeMKQzqBJ1r6eAv0vsWJV6qkTRe0-B_iqUOl7Y&s=IDGICUZlL3v-yH_pfcZvMh00v6bCssbJ3bn-JvDuqWo&e=
>
> Tiago Lam (3):
> Conntrack: Add new API for future SIP Alg.
> Conntrack: Add initial support for new SIP Alg.
> Conntrack: Support asymmetric RTP port for SIP.
>
> include/openvswitch/ofp-actions.h | 4 +
> lib/automake.mk | 2 +
> lib/conntrack-private.h | 2 +
> lib/conntrack-sip.c | 491
++++++++++++++++++++++++++++++++++++++
> lib/conntrack-sip.h | 123 ++++++++++
> lib/conntrack.c | 254 +++++++++++++++++++-
> lib/ofp-parse.c | 5 +
> ofproto/ofproto-dpif-xlate.c | 3 +
> 8 files changed, 883 insertions(+), 1 deletion(-)
> create mode 100644 lib/conntrack-sip.c
> create mode 100644 lib/conntrack-sip.h
>
Hi Tiago,
Before starting in my current role, I worked for ten years doing VoIP
development with a strong focus on SIP.
SIP is a beast of a protocol, and seeing this patchset, I made some
notes about how things might possibly go wrong, and ... let's just say
there are quite a few :). I know that you are writing this as a proof
of
concept and that you have many TODO-style comments owning up to the
fact
that you know about some things that are missing, but I think it may go
deeper than you or anyone on the OVS development team realize.
That is definitely an assumption…
I'm willing to help out in this effort by donating SIP knowledge, but
before that, I'm curious what the end goal of the SIP ALG actually is.
I
have a feeling that the effort and expense of writing, and more
importantly maintaining, a proper SIP ALG may not be worth it.
As a side point, when I was working on VoIP software, one of the first
things we'd tell people who came to us with connectivity issues was
"turn off the SIP ALG in your router". This on its own resolved issues
with an alarming frequency.
Not a surprise; this was brought up internally when SIP support was first
mentioned by Redhat.
At a minimum, SIP ALGs would have a specific knob to enable them globally.
Tiago/Mark
s/SIP ALGs would have a specific knob/SIP ALG’s behaviors would have a specific
knob/
meaning certain behaviors (or capabilities) should be easily independently
enabled/disabled in the code
and later supported by user command to enable.
I have one general behavior identified so far.
Thanks Darrell
Mark
_______________________________________________
dev mailing list
d...@openvswitch.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddev&d=DwICAg&c=uilaK90D4TOVoH58JNXRgQ&r=BVhFA09CGX7JQ5Ih-uZnsw&m=XHeuwSeMKQzqBJ1r6eAv0vsWJV6qkTRe0-B_iqUOl7Y&s=nXBmkfSg5YmenXwzNh-0RDz6C2MEB--PZaZpvHc0E2U&e=
_______________________________________________
dev mailing list
d...@openvswitch.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddev&d=DwIGaQ&c=uilaK90D4TOVoH58JNXRgQ&r=BVhFA09CGX7JQ5Ih-uZnsw&m=MluiN-u13FZ3Q-MHU-jOtNsKLSW2KgdIaHtHXNxBMYA&s=M24vIhozi06cN8-vKg0kIhmsgPGMzljkDC7J963K9lw&e=
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
