stefankopieczek/gossip

SIP stack in Golang

gossip

SIP stack in Golang, for use by stateful SIP UAs, whether client, server, or proxy.

Project status

Version: V0.2

Gossip is now capable of basic SIP 2.0 transactions over UDP and TCP and has been live tested with real softphones. It is still missing some compatibility features, isn't well tested and has a few known bugs.

APIs will change without warning until V1.0.

This readme will be updated as work progresses.

gossip's Issues

Gossip re-orders header and URI params

• If we are acting as a transparent proxy, we may reorder header params and URI params when we forward messages.
• Gossip processes header and URI params in an undefined order.
• String representations of SIP messages received by gossip may show params in a diferent order to that received off the wire.

This is because the Params object that stores them holds them in a map, which doesn't have a defined iteration order.

Fixer should uncomment the broken stringify tests.

Broken build in after merging pull request #17

Pull request 55436d1 breaks the Gossip Gatekeeper build:
http://54.68.45.135:8080/job/Gossip%20Gatekeeper/48/console

The failing test passes on my PC, but failed twice in a row on Jenkins.

Unable to capture responses corresponding to a request

Here's a small test I wrote to check register messages. It is almost similar to existent test for INVITE message with some modifications

var userid string = "user1"
func TestSendRegisterUDP(t *testing.T) {
    register, err := request([]string{
        "REGISTER sip:ims.hom SIP/2.0",
        "Via: SIP/2.0/UDP " + c_CLIENT + ";rport;branch=z9hG4bK996329494",
        "Route: <sip:pcscf.ims.hom;lr>",
        "From: <sip:"+userid+"@ims.hom>;tag=1224392795",
        "To: <sip:"+userid+"@ims.hom>",
        "Call-ID: 1379275388",
        "CSeq: 1 REGISTER",
        "Contact: <sip:"+userid+"@192.168.1.39:5060>",
        "Authorization: Digest username=\""+userid+"@ims.hom\", realm=\"ims.hom\", nonce=\" \", uri=\"sip:ims.hom\", response=\" \"",
        "Max-Forwards: 70",
        "User-Agent: eXosip/3.1.0",
        "Expires: 600000",
        "Supported: path",
        "Supported: gruu",
        "Content-Length: 0",
        "",
        "",
    })
    assertNoError(t, err)
    ok, err := response([]string{
        "SIP/2.0 401 Unauthorized",
        "CSeq: 1 REGISTER",
        "Via: SIP/2.0/UDP " + c_SERVER + ";branch=z9hG4bK996329494",
        "",
        "",
    })

    test := transactionTest{actions: []action{
        &clientSend{register},
        &clientRecv{ok},
    }}
    test.Execute(t)
}

func (test *transactionTest) Execute(t *testing.T) {
    var err error
    test.client, err = NewManager("udp", c_CLIENT)
    assertNoError(t, err)
    defer test.client.Stop()

    for _, actn := range test.actions {
        testLog.Debug("Performing action %v", actn)
        actn.Act(test)
    }
}

type clientSend struct {
    msg *base.Request
}

func (actn *clientSend) Act(test *transactionTest) error {
    test.lastTx = test.client.Send(actn.msg, c_SERVER)
    return nil
}

type clientRecv struct {
    expected *base.Response
}

func (actn *clientRecv) Act(test *transactionTest) error {
    go func() error {
        for {
            fmt.Println("Checking Responses")
            responses := test.lastTx.Responses()
            select {
            case response, ok := <-responses:
                if !ok {
                    return fmt.Errorf("Response channel prematurely closed")
                } else if response.String() != actn.expected.String() {
                    return fmt.Errorf("Unexpected response:\n%s", response.String())
                } else {
                    return nil
                }
            case <-time.After(time.Duration(1)*time.Second):
                return fmt.Errorf("Timed out waiting for response")
            }
        }
    }()
    return nil
}

However, the issue here is, although I can see a response from the server via tcpdump, I'm not able to capture it via the response channel.
I've couple of questions:

• Is this the correct way to listen for response? If not, can you please guide me on the same.
• If this is the correct way, is there any way I could help fix the bug?

Note: We've a working version of Project Clearwater which acts like a server.

Examples

Hello,

Any chance of you including some example apps? Maybe something akin to a "hello-world.go" ?

John

Transaction layer does not correlate ACKs to 2xx final responses properly.

We do not deal with the fact that an ACK to a 2xx response has a different branch parameter, so we currently just drop them on the floor.

Need to include some cleverer matching in this case to send it to the right transaction.

Replies are being sent back from a random source port

Hello,
First of all, thanks for the excellent work..
Seems like when running a UDP 'server' all replies are being sent from a random source port.
This will mostly work but in many cases (especially NATed clinets) it might cause some problems. Firewalls will usually drop such message if the source/dest port/ip cannot be matched.
Ideally, the server should send responses to the same ip:port that the request was received from.

Panic in connWatcher when connTable is stopped

If connTable.Stop() is called when at least one connection in the table has expired, the connWatcher panics when it receives the stop message from the connTable.

Cause is that when the connWatcher nil-s out its connection both on expiry and when it is stopped; the second nil causes a nil dereference.

Could just do a nil check here, but there's a wider issue that the connWatcher should be GC'd on socket expiry, and it currently isn't. We can't just remove it from the table inline, because we're running on a separate goroutine so this could cause races. So we'll need a dedicated goroutine for the connTable which serializes conn updates and expiries.

Interface rewrite

Our interface is a bit weird at the moment, and uses channels and stuff to communicate with the user. I think exposing channels like this is a bad idea. If we expose a simpler interface, the user can decide to send the messages down channels themselves if they like.

I propose a handler based interface similar to net/http. Something like:

// Create transport.
transport := transport.NewUDP(...)

// Create TM.
tm := &transaction.Manager{
    Transport: transport,
    Handler: myHandler,
}

// Blocks forever.
tm.ListenAndServeSIP()

Client API becomes blocking (greatly simplifying testing)

// Non-invite flow.
req := &base.Request{...}
resp, err := tm.Send(req)
// ... do stuff

// Invite flow.
req := &base.Request{...}
resp, err := tm.Send(req)
tm.Ack(resp)

Additionally propose renaming "base" package to "sip" so the main objects are called helpful things like sip.Request, sip.Response etc etc.

Gossip should support the rport parameter in Via headers

See RFC 3581 for details.

Parser does not maintain order of parameters (URI/Header)

The parser does not store the order of URI/Header parameters.
This means that we may arbitrarily re-order parameters at random.

Shouldn't be an issue that causes messages to fail, but sad if you're writing a simple proxy.

MassUDP test is flaky under load

e.g.

--- FAIL: TestMassUDP (0.73s)
transport_fv_test.go:49: Error - received an unexpected number of messages: 9978

http://claudebox.duckdns.org/job/gossip-pr/30/console

Clean up go vet violations and add vet to CI

[Bug] Uninitialized timer, Sending Requests via TCP

I was trying to run the INVITE tests on top of TCP as opposed to that of UDP.
Here is a minor relevant log:

=== RUN TestAAAASetup
--- PASS: TestAAAASetup (0.00s)
=== RUN TestSendInviteTCP
DEBUG: Chan 0x1854430c gets '0'
DEBUG: Chan 0x1854430c sends '0'
DEBUG: Parser buffer returns line 'INVITE sip:[email protected] SIP/2.0'
DEBUG: Parser buffer returns line 'Via: SIP/2.0/TCP 192.168.1.39:5060;branch=z9hG4bK776asdhds'
DEBUG: Parser buffer returns line ''
DEBUG: Parser 0x18544300 parsing header "Via: SIP/2.0/TCP 192.168.1.39:5060;branch=z9hG4bK776asdhds"
DEBUG: Parser buffer returns chunk ''
DEBUG: Stopping parser 0x18544300
DEBUG: Parser 0x18544300 stopped
DEBUG: Notifier 0x18536b20 has new listener 0x18544640
>>> DEBUG: Performing action &{0x18544480}
DEBUG: [manager::Send]Sending to 192.168.1.41:5060: INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/TCP 192.168.1.39:5060;branch=z9hG4bK776asdhds


DEBUG: Query connection for address 192.168.1.41:5060 returns nil (no registered watcher)
DEBUG: No stored connection for address 192.168.1.41:5060; generate a new one
DEBUG: Parser 0x18544300 stopped
INFO: Begin serving TCP on address 192.168.1.39:5060
DEBUG: Chan 0x1854430c will dispose
DEBUG: Chan 0x1854430c disposing...
DEBUG: Chan 0x1854430c disposed
DEBUG: No connection watcher registered for 192.168.1.41:5060; spawn one
DEBUG: Connection 0x18536cc0 waiting for new data on sock
DEBUG: Stopping parser 0x18544880
DEBUG: Parser 0x18544880 stopped
panic: time: Stop called on uninitialized Timer

goroutine 16 [running]:
time.(*Timer).Stop(0x18538660, 0x18544900)
    /usr/local/go/src/time/sleep.go:59 +0x61
github.com/stefankopieczek/gossip/transport.func·002(0x18536d20)
    /home/ubuntu32/gossip/src/github.com/stefankopieczek/gossip/transport/conntable.go:66 +0x2fb
created by github.com/stefankopieczek/gossip/transport.(*connTable).Notify
    /home/ubuntu32/gossip/src/github.com/stefankopieczek/gossip/transport/conntable.go:79 +0x32a

Is the following function correct place to initialize the timer and fix the bug?

// Create a new connection table.
func (t *connTable) Init() {
    t.conns = make(map[string]*connWatcher)
}

Why Send via UDP should open and close connection?

Hi,
I would like to ask what is the reason behind opening a new connection and closing it immediately when sending the data using Send() function on UDP transport?

Why don't the function use the one from listeningPoints as there should be a minimum of one connection in here due to the call of Listen() in transport.manager.NewManager() ?

And shouldn't we also need to wait for response of the Send() function (e.g. in ClientTransaction case) in the same source port? Closing the connection will close the source port and the response will not be received.

Improve logging, bonus edition

Logs should include the last line of the stack trace before the log call, and a line reference if possible, e.g.

2015-07-17 08:40 [18425] foo.go (fooDoer.doBar:83): The fooDoer did a bar.

Where is the main function

Hi,
I am trying to lean the sip protocol in Go. I am new to network programming. I wanted to follow the code from main section until I understand how its implemnted. I cant find the main function. How is this code/server started.
Regards
Bheki

Missing implementation of Stringer interface for type NoString ?

Shouldn't we add the implementation of Stringer interface for base.NoString, as for base.String ?

Transport layer should be unit tested.

Aiming for 100% coverage in all components.

在生产环境可以使用吗?

在生产环境可以使用吗?

Abandoned?

I'd like to use this library in one of my projects, but it looks quite abandoned with no licensing.

Is there a plan to do any more work on this?

Transport tests should be moved to the test package

The current transport tests are really FVs, not ITs, so should live in the 'test' package.

Transaction layer does not support devices which don't comply with RFC3261

The transaction layer does not currently implement the ghetto response matching described in RFC3261 section 17, for compatibility with devices which don't comply with the newer spec.

It currently only matches with branch/CSeq.

Transaction layer should be unit tested.

Aiming for 100% coverage in all components.

Improve logging

Logging library should log a timestamp and a thread ID.

transport.Manager.Stop() returns before closing all sockets

... they close shortly afterwards, but there's a race window where Stop() has returned but the sockets are still bound.

This means that the sockets can't be reused immediately – subsequent binds might fail with a "socket in use" if they happen too soon after the previous manager is stopped.

In particular this causes occasional failures in the transport tests.

Question: Why did you use channels as arguments in your parser?

This code here: https://github.com/StefanKopieczek/gossip/blob/master/parser/parser.go#L103

I am trying to get a grasp on why you would create the parser this way. Is there any particular reason or was it just a pattern you prefer using?

Display name fails to parse

The parser rejects the following:

From: "John"<sip:[email protected]>

and

To: Jane<sip:[email protected]>

... However, having a space before the angle bracket should not be compulsory, per rfc 3261 20.10.

We should write some tests based on the RFC 4475 SIP Torture Test messages

See RFC 4475.

We should make sure our parser can parse these torture test messages.