[ovs-dev] [PATCH 0/3] Initial support for new SIP Alg.

Darrell Ball dball at vmware.com
Tue Jan 9 20:44:14 UTC 2018



On 1/9/18, 11:33 AM, "ovs-dev-bounces at openvswitch.org on behalf of Mark Michelson" <ovs-dev-bounces at openvswitch.org on behalf of mmichels at 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.

    
    Mark
    _______________________________________________
    dev mailing list
    dev at 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=
    





More information about the dev mailing list