Hi Mark,
Your email strikes me as if you haven't read the previous email exchange at:
https://mail.openvswitch.org/pipermail/ovs-dev/2017-November/341089.html
(TL;DR I've asked similar questions there)
Having said that, and knowing this is happening, my intention is exactly
this; Contribute with knowledge, where and how I can, in the form of
code or otherwise, _to help_ bring that into life.
I'm sure no-one is underestimating how complex SIP is, I certainly am
not. As a side note, it is also true that we are not looking into
writing a complete SIP stack, but something that allows us to verify the
exchanged traffic; It is my understanding that many shortcuts can be
taken with this in mind.
Hopefully this, together with the email I pointed to, clarifies things a
bit better.
Tiago
On 01/09/2018 07:33 PM, Mark Michelson 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://mail.openvswitch.org/pipermail/ovs-dev/2017-November/341089.html
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.
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.
Mark
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
