ghettovoice / gosip Goto Github PK

View Code? Open in Web Editor NEW

390.0 23.0 87.0 913 KB

SIP in Go

License: BSD 2-Clause "Simplified" License

Go 99.81% Makefile 0.19%

sip golang hacktoberfest

gosip's People

Contributors

Stargazers

Watchers

Forkers

yuyiqi90111 masterclock songlei150 cloudwebrtc fathandsomeboy chenhao5-intel tslyc thinklib resipwebrtc ikingye maxid the-locksmith wangscript007 matrix-org vbomfim kudryavtsevdmitry pengtianabc sanfooh mxh120831853 greatitman brnt pieerepi ygj201011 caixiong110 flystar8 jamesyin689 mashitda utsl42 cqu20141693 sputnik-systems emiago armourknight juphoon ik5 sumu11690 cnbailh awaiskhalidawan zlopo coopot angwangiot kele1997 qdwl zhusenrao wulalawulala pidato cobe687 karlma sreeram-narayanan umputma fochive00 fangdaoyuan nguyen0096 firetiger23 july1921 winlinvip xiangxud lx32056127 eriklee1895 zengtaoxian pk32495 zslink azhaocn kennyzhu2013 dmitry-kovalev zoushuanglong twangjie wxc9102 asdlei99 sdfighting general252 dyncming braams bvisonl belakalotay okhowang charlestamz mhardeman conversenow auleaf mitslyj albert1666 unmark-code yangjuncode

gosip's Issues

i got this pannic

in connection_pool line 690
It tells me this channel output has been closed

did we need protect by wg like what i did

Response cannot be sent due to the incorrect transport

Hi @ghettovoice,
A client send out a request using UDP, and the length of the message is greater than MTU(1500 bytes).
I'am using NewResponseFromRequest to create a response from the request. But req.Transport() returns "TCP", which caused the response cannot be sent back to the client.
The Transport function changes origional "UDP" to "TCP" in request.go
https://github.com/ghettovoice/gosip/blob/master/sip/request.go
if tp == "UDP" && len(req.String()) > int(MTU)-200 { tp = "TCP" }
I deleted the above code, and the issued was fixed. So I think the code may be deleted, do you agree with me or any other better way to avoid the issue?

listen on both udp and tcp

According to 18.2.1 Receiving Requests

For any port and interface that a server listens on for UDP, it MUST listen on that same port and interface for TCP. This is because a message may need to be sent using TCP, rather than UDP, if it is too large.

Should I listen on the same port for both udp and tcp?

Can the tel format be supported?

I see in the function ParseUri only support sip and sips，can the tel fomat be supported？

gosip panic

the stack is below:

panic: invalid argument to Intn

goroutine 29 [running]:
math/rand.(*Rand).Intn(0xc0000f8180, 0x0)
	/usr/lib/go/src/math/rand/rand.go:180 +0x72
math/rand.Intn(0x0)
	/usr/lib/go/src/math/rand/rand.go:453 +0x34
github.com/ghettovoice/gosip/transport.(*layer).Send(0xc00041a640, {0x1a3ae58, 0xc00043a420})
	/home/weihg/code/go/pkg/mod/github.com/ghettovoice/gosip@v0.0.0-20231212083318-2c9f9eaee8d5/transport/layer.go:239 +0x4a5
github.com/cloudwebrtc/go-sip-ua/pkg/stack.(*SipStack).Send(0xc000000540, {0x1a3ae58, 0xc00043a420})
	/home/weihg/code/go/pkg/mod/github.com/yangjuncode/go-sip-ua@v1.1.8/pkg/stack/stack.go:435 +0x22e
github.com/cloudwebrtc/go-sip-ua/pkg/stack.(*sipTransport).Send(0xc000426468, {0x1a3ae58, 0xc00043a420})
	/home/weihg/code/go/pkg/mod/github.com/yangjuncode/go-sip-ua@v1.1.8/pkg/stack/stack.go:572 +0x45
github.com/ghettovoice/gosip/transaction.(*clientTx).Init(0xc00031a000)
	/home/weihg/code/go/pkg/mod/github.com/ghettovoice/gosip@v0.0.0-20231212083318-2c9f9eaee8d5/transaction/client_tx.go:92 +0xc3
github.com/ghettovoice/gosip/transaction.(*layer).Request(0xc00051ca00, {0x1a3b480, 0xc00043a420})
	/home/weihg/code/go/pkg/mod/github.com/ghettovoice/gosip@v0.0.0-20231212083318-2c9f9eaee8d5/transaction/layer.go:140 +0x4fc

Seems there is Memory Leak

HI Ghettovoice,
I just create 150 endpoints and use RequestWithContext do the REGISTER every 30S, seems there is memory leak. I saw the usage of this process keep increasing. Below is the capture of the pprof. Please help check.

Thank You
William

typo

gosip/sip/builder.go

Lines 281 to 283 in 9ce75dd

    
           if rb.to == nil { 
        
           	return nil, fmt.Errorf("empty 'From' header") 
        
           }

From should be To

How to response the register method in a correct way?

Hi, ghettovoice. How can I use gosip to add a tag in the response ? It's said in the RFC3261

the request has no "to tag" in the to header.

   REGISTER sip:registrar.biloxi.com SIP/2.0
   Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7
   Max-Forwards: 70
   To: Bob <sip:[email protected]>
   From: Bob <sip:[email protected]>;tag=456248
   Call-ID: 843817637684230@998sdasdh09
   CSeq: 1826 REGISTER
   Contact: <sip:[email protected]>
   Expires: 7200
   Content-Length: 0

but the response has:
SIP/2.0 200 OK
Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7
;received=192.0.2.4
To: Bob sip:[email protected];tag=2493k59kd
From: Bob sip:[email protected];tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Contact: sip:[email protected]
Expires: 7200
Content-Length: 0

How can I add a to tag in the response using gosip?

Outbound proxy

Hi @ghettovoice would you be interested in a outbound proxy setting? Maybe by changing the NewLayer function signature? But this would be a breaking change. If you are interested I can create a pr but first I want to discuss it with you.

Registry

new goroutines for user handlers

In function serve, we add waitgroup, launch a goroutine for each request.

			srv.hwg.Add(1)
			go srv.handleRequest(tx.Origin(), tx)

In function handleRequest, the waitgroup is done.

func (srv *server) handleRequest(req sip.Request, tx sip.ServerTransaction) {
	defer srv.hwg.Done()

But in the end of handleRequest, we launch another goroutine to run the user handler.

	go handler(req, tx)
}

When the sever is shutdown, goroutines running user handlers may leak?

[Feature Request]: pure client mode

In my case, I would like to mock lots of sip devices to communicate with the upstream UA using TCP.

For now, I must listen to a port for a device, but the communication will not use the server part at all. Because the upstream will just use the TCP connection set up by the client.

So, maybe we need a pure TCP client without having to listen on any port.

received_by and received_from for multi port listening

In cases of listening at 0.0.0.0:5060 or multi interfaces, for response of sip message, it needs to present the contact header, such as Contact: sip:192.168.1.100:5060;transport=udp, is there a way to retrive the recevied from and received by address from transcation?

how to send 487 when i recieve cancel

hello:
code like this,when i recievd cancel ,it seems hard to send 487 when i using the transaction

cancel := <-tx.Cancels()
		if cancel != nil {
			response := sip.NewResponseFromRequest(req, cancel, 200, "ok", "")
			tx.Respond(response)
}

and how to send 487

Goroutine leaks with CANCEL

There is a problem with the UAS state machine，while a CANCEL request send by UAC for pending INVITE, the goroutine leaks.

[Feature Request] Export metrics of sip server.

When using in product env, we usually want to export service metrics to Prometheus.

For example, the client count (using TCP/UDP), transaction count, active dialog count, err rate, etc.

Maybe we should add some more functions for this purpose.

Add support for WSS/WS transport.

Add WebSocket transport to support sip client with WebRTC, for example, JsSIP, dart-sip-ua,
Or as a gateway to WebRTC to SIP.

Does ElasticChan have mem-leak problem?

Hello @ghettovoice,

"Slice is a contiguous segment of an underlying array."

To my knowledge, if we are using a slice which is a fragment of a underlying array, the underlying array will never be collected by GC. And in the design of ElasticChan, we frequently push and poll elements from this slice. So, is there a mem-leak problem?

gosip/util/elasticchan.go

Line 108 in 4da3368

c.buffer = c.buffer[1:]

I tried as upon codes, but didn't find mem-leak. But why? This question is like a knot in my mind. Could you pls give me an answer?

How to use this library? What is the main function?

PBX server

Is it possible to build a PBX server, based on this project?

Parser fully ignore the rules for character escaping/unescaping

Maybe we should use parser from here.

Go routine leaks with tcp connection?

When a tcp connection received, this go routine will add once, but when the connection disconnect,the go routine still exist.

WSS -> UDP B2BUA : "TCP not supported"

Hi,

I have been using your library via the cloudwebrtc/go-sip-ua library and I am building a B2BUA to accept calls over WSS & TLS and start a new "B leg" over UDP to another SIP server. So far I have been successfully able to accept calls over UDP and start a new UDP "B leg", but when I use WSS I get a cryptic error:

[2021-06-07 11:26:59.725] ERROR UserAgent: INVITE: Request [INVITE] failed, err => transport.UnsupportedProtocolError: protocol TCP is not supported

Is this something you have seen before?

I can clearly see that TCP is defined in the default protocol factory here, I don't see that being overwritten in cloudwebrtc/go-sip-ua nor am I overwriting it myself.

I have already opened an issue with cloudwebrtc (cloudwebrtc/go-sip-ua#56) but I am opening one here since your library is the one initially throwing the error.

More detailed logs

In JSON logs below see field sipURI which is the newly constructed SIP URI for the B-leg.

connection_key=wss:<public-ip>:37916 destination=<public-ip>:37916 protocol_ptr=0xc00020c000 received_at=2021-06-07 11:26:59.723770792 +0000 UTC m=+66.491320370 request_id=b90ee9e6-d551-4225-9e0c-5ae80c0cf5b8 response_id=b90ee9e6-d551-4225-9e0c-5ae80c0cf5b8 source=10.89.5.252:5443 transaction_key=z9hG4bK7616340__0rkf2tfldjrh.invalid__443__INVITE transaction_ptr=0xc0000fa9a0 transport=WSS transport_layer_ptr=0xc000208000
{"level":"debug","version":"v0.0.0-dev","sipURI":"sip:<to-user>@<b-leg-domain>;lang=fr;transport=udp","time":"2021-06-07T11:26:59Z","caller":"/app/cuppa.go:93"}
{"level":"debug","version":"v0.0.0-dev","called":"sip:<to-user>@<A-leg-domain>;lang=fr","time":"2021-06-07T11:26:59Z","caller":"/app/cuppa.go:94"}
[2021-06-07 11:26:59.725] DEBUG transaction.Layer: client transaction created destination= request_id=4e07eea6-a680-437f-bb3a-27e533ad0bdb source= transaction_key=z9hG4bK.qTo7TdnZhwBwoMzVC2FnWJh58AYslaaP__INVITE transaction_layer_ptr=0xc000078100 transaction_ptr=0xc00031b440 transport=
[2021-06-07 11:26:59.725] DEBUG transaction.ClientTx: initialising INVITE transaction FSM destination= request_id=4e07eea6-a680-437f-bb3a-27e533ad0bdb source= transaction_key=z9hG4bK.qTo7TdnZhwBwoMzVC2FnWJh58AYslaaP__INVITE transaction_layer_ptr=0xc000078100 transaction_ptr=0xc00031b440 transport=
[2021-06-07 11:26:59.725] DEBUG transaction.ClientTx: act_trans_err destination= request_id=4e07eea6-a680-437f-bb3a-27e533ad0bdb source= transaction_key=z9hG4bK.qTo7TdnZhwBwoMzVC2FnWJh58AYslaaP__INVITE transaction_layer_ptr=0xc000078100 transaction_ptr=0xc00031b440 transport=
[2021-06-07 11:26:59.725] DEBUG transaction.ClientTx: act_delete destination= request_id=4e07eea6-a680-437f-bb3a-27e533ad0bdb source= transaction_key=z9hG4bK.qTo7TdnZhwBwoMzVC2FnWJh58AYslaaP__INVITE transaction_layer_ptr=0xc000078100 transaction_ptr=0xc00031b440 transport=
[2021-06-07 11:26:59.725] DEBUG transaction.ClientTx: transaction done destination= request_id=4e07eea6-a680-437f-bb3a-27e533ad0bdb source= transaction_key=z9hG4bK.qTo7TdnZhwBwoMzVC2FnWJh58AYslaaP__INVITE transaction_layer_ptr=0xc000078100 transaction_ptr=0xc00031b440 transport=
[2021-06-07 11:26:59.725] ERROR UserAgent: INVITE: Request [INVITE] failed, err => transport.UnsupportedProtocolError: protocol TCP is not supported
{"level":"warn","version":"v0.0.0-dev","call-id":"vun32hm9s7gr6ht1l6b8","time":"2021-06-07T11:26:59Z","caller":"/app/cuppa.go:99","message":"B-leg session err transport.UnsupportedProtocolError: protocol TCP is not supported"}

Wrong remote address of client

Hi @ghettovoice ,
I am using gosip lib and created a sip server with UDP. Most of time it works well, but sometimes the remote address of the client request is wrong, which was changed to other client's remote address. Once this happens, all the following requests' remote address are wrong, so the reponses cannot be sent to the correct clients. TCP doesn't have this issue. The reproduction is difficult, but it occurs from time to time. Could you help to find out the issue and fix it?

How does the server send invite to the client

How does the server send invite to the client after register

Add "rport" in via to support NAT

Problem:
Can not connenct to SIP server when client behind a NAT network.

Request Log:

Via: SIP/2.0/UDP 192.168.1.187:50066;branch=z9hG4bK.iJM9FQ5m5ZRW0ZJZTAvNGlTyN9JPA6Nl
......
What's expected:

Via: SIP/2.0/UDP 192.168.1.187:50066;rport;branch=z9hG4bK.iJM9FQ5m5ZRW0ZJZTAvNGlTyN9JPA6Nl
......
Solution:
Add an additional "rport" parameter in "Via" when request is prepared. (RFC3581)
I submitted a PR draft at cloudwebrtc/go-sip-ua#98. This PR only checks the functionality, not the configuration, which may need to be added.

Doesn't work with IPV6 addresses

When I try to send a register message using ipv6 protocol I receive the following error:

[2021-11-19 16:29:14.709] ERROR UserAgent: Request [REGISTER] failed, err => send SIP message through TCP protocol to ****:****:6b2:9201:273:e371:67ad:fd1e:5060: transport.ProtocolError<protocol_ptr=0xc00019aa80> resolve target address TCP ****:****:6b2:9201:273:e371:67ad:fd1e:5060 failed: address ****:****:6b2:9201:273:e371:67ad:fd1e:5060: too many colons in address

It looks like the problem is somewhere here:

gosip/transport/layer.go

Line 285 in f0c4b77

if addr, err := net.ResolveTCPAddr("tcp", addrStr); err == nil {

[BUG] panic error

It looks like I'd been attacked, and then the program occurred panic err

Anything can help me plz?

[BUG] panic when request with empty "rport" in via header

I meet panic when sent Request with empty "rport" param in ia header.

The panic is as below:
`panic: runtime error: index out of range [0] with length 0 [recovered]
panic: runtime error: index out of range [0] with length 0

goroutine 12 [running]:
testing.tRunner.func1.2({0x1607fc0, 0xc00002f4e8})
/Users/go/go1.19/src/testing/testing.go:1396 +0x24e
testing.tRunner.func1()
/Users/go/go1.19/src/testing/testing.go:1399 +0x39f
panic({0x1607fc0, 0xc00002f4e8})
/Users/go/go1.19/src/runtime/panic.go:884 +0x212
github.com/ghettovoice/gosip/sip.(*headerParams).ToString(0xc00007fb40, 0x3b)
/Users/code/gosip/sip/headers.go:197 +0x438
github.com/ghettovoice/gosip/sip.(*ViaHop).String(0xc000038d80)
/Users/code/gosip/sip/headers.go:1141 +0x1e2
github.com/ghettovoice/gosip/sip.ViaHeader.Value({0xc000014100, 0x1, 0x10f62be?})
/Users/code/gosip/sip/headers.go:1060 +0x5d
github.com/ghettovoice/gosip/sip.ViaHeader.String({0xc000014100?, 0xc000143340?, 0xc000032dc0?})
/Users/code/gosip/sip/headers.go:1052 +0x25
github.com/ghettovoice/gosip/sip.(*headers).String(0xc00007fac0)
/Users/code/gosip/sip/message.go:148 +0x15e`

I fond the problem is when the code run to sip.(*headerParams).ToString(), if the header param key is empty, then valStr will be empy, so valStr[0] out of range.

My solution: #45

Why does the via header not carry the rport field？

Hi GhettoVoice, gosip is a very good library, but in the public network environment, I initiated the registration, has not received the response of the server, capture packet analysis, is the request does not have the rport field caused. Here's my solution:

    // add empty cotent
hop, _ := msg.ViaHop() 
hop.Params.Add("rport",sip.String{""})

for _, conn := range p.connections.All() {
	parts := strings.Split(string(conn.Key()), ":")
	if parts[2] == port {
		logger := log.AddFieldsFrom(p.Log(), conn, msg)
		logger.Tracef("writing SIP message to %s %s", p.Network(), raddr)

		if _, err = conn.WriteTo([]byte(msg.String()), raddr); err != nil {
			return &ProtocolError{
				Err:      err,
				Op:       fmt.Sprintf("write SIP message to the %s connection", conn.Key()),
				ProtoPtr: fmt.Sprintf("%p", p),
			}
		}

		return nil
	}
}

Todo

tx layer refactoring and tests
basic UA and dialogs
tls protocol

is there any demo for SIP client? thank you

leak memoy

I use https://github.com/cloudwebrtc/go-sip-ua.git repo to finish something and this repo import gosip

I run bench test,and meet memeory problem

I think maybe my program didn't delete tx which created by NewServerTx

I read gosip source code and location transaction.commonTx. I can't find anyone write data to commonTx.done ,so I don't understand how did transaction.layer.serveTransaction() exit

	for {
		select {
		case <-txl.canceled:
			logger.Info("transaction canceled")
			tx.Terminate()
			return
		case <-tx.Done(): // where write data?
			logger.Info("transaction done")
			return
		}
	}

Can you tell me how where write data to tx.done?

question about the requestWithContext function

Hi，@ghettovoice trouble you agin
my example code :

cancelCtx,cancel := context.WithTimeout(*mainCtx, 5*time.Second)
srv.RequestWithContext(*ctx, *inviteRequest, gosip.WithResponseHandler(func(res sip.Response, request sip.Request) {

    }
}))

after 5 seconds，RequestWithContext function does not end.

I know from the server.go source file that requestWithContext will create two coroutines.

The first goroutine when the context is cancelled, the coroutine terminates and the message transaction is cancelled.

The second goroutine when the request message gets a response or the request transaction occur exception, such as a transaction timeout.

The way I understand it, when the context is cancelled, the transaction is cancelled, requestWithContext should be done, so why wait for the response, wait for the transaction to time out. My solution:

func (srv *server) requestWithContext(
	ctx context.Context,
	request sip.Request,
	attempt int,
	options ...RequestWithContextOption,
) (sip.Response, error) {
	tx, err := srv.Request(request)
	if err != nil {
		return nil, err
	}
        //...
	go func() {
		defer wg.Done()

		select {
		case <-done:
		case <-ctx.Done():
			if err := tx.Cancel(); err != nil {
				srv.Log().Error("cancel transaction failed", log.Fields{
					"transaction_key": tx.Key(),
				})
			}
		}
	}()
	go func() {
		defer func() {
			close(done)
			wg.Done()
		}()

		for {
			select {
                        //solution code 
			case <-ctx.Done():
				errs <- fmt.Errorf("ctx cancel")
				return
			case err, ok := <-txErrs:
				if !ok {
					txErrs = nil
					// errors chan was closed
					// we continue to pull responses until close
					continue
				}
				errs <- err
				return
			case response, ok := <-txResponses:
				//....
			}
		}
	}()

	var res sip.Response
	select {
	case err = <-errs:
	case res = <-responses:
	}

	wg.Wait()

	return res, err
}

Cannot receive data in udp transport.

This commit caused the problem.
363788f#diff-e86e601ae5292817399a481c2c0ed49aeb67b393ac0cddc00d4aa31c491b40b1R105

This modification uses DialUDP to create an independent udp conn to send data.
udp.go

	baseConn, err := net.DialUDP(p.network, laddr, raddr)
	...
	key := ConnectionKey(fmt.Sprintf("%s:%s", p.network, baseConn.LocalAddr()))
	conn := NewConnection(baseConn, key, p.network, p.Log())

	logger := log.AddFieldsFrom(p.Log(), conn, msg)
	logger.Tracef("writing SIP message to %s %s", p.Network(), raddr)

	_, err = conn.Write([]byte(msg.String()))
	...

but the newly created connection is not added to the p.connections pool,
some code missing here causes no data to be received.
like this.

	err = p.connections.Put(conn, sockTTL)
	if err != nil {
		err = &ProtocolError{
			Err:      err,
			Op:       fmt.Sprintf("put %s connection to the pool", conn.Key()),
			ProtoPtr: fmt.Sprintf("%p", p),
		}
	}

@ghettovoice I am a little confused here. Before this modification, we can use the listened udp transport (0.0.0.0:5060) to send data, but after changing to DialUDP, it will cause a new udpConn to be dialed every time UDP data is sent. , Should this be a bug?

Predefined SIP Code

100, 180, 200 and so on

nil pointer reference

Hello,

In client_tx.go, the following code can try to call res.Short() when res is nil following a DNS failure to resolve the Host.

	err = &TxTransportError{
		fmt.Errorf("transaction failed to send %s: %w", res.Short(), err),
		tx.Key(),
		fmt.Sprintf("%p", tx),
	}

This workaround fixes the issue but may not be the right way to handle the problem

	reason := "<unknown>"
	if res != nil {
		reason = res.Short()
	}

	err = &TxTransportError{
		fmt.Errorf("transaction failed to send %s: %w", res.Short(), err),
		tx.Key(),
		fmt.Sprintf("%p", tx),
	}

AuthFromValue support value without quote

for example

Authorization:  Digest username="1001",realm="sip.com",nonce="QEI/UdFatD81f/bAdV81/O+MabB7wfxFfT/Nx6j/5GgA",uri="sip:sip.com",response="ba301be0efa4b5e686a395f134350b56",cnonce="d30111921524392bfe61db082ca2c28e",nc=00000001,qop=auth,algorithm=MD5

nc, qop, algorithm's value has no quote

sip.NewAckRequest ignore body parameter

sip.NewAckRequest has a body parameter, but for some reason it ignores it and automatically sets the body to the empty string:

gosip/sip/request.go

Line 315 in 6b80e2d

ackRequest.SetBody("", true)

This is misleading behavior.

Licence

Hi,

I see some code that was forked from the gossip library.
How does the LGPL-2.1 license from the forked code affect another library that wants to use your library?
Can I still use this library without disclosing my source code?

Thanks,
Trial97

sip server blocked while receiving a large UDP message

After receiving a UDP message that message length is larger than 4096, the udp server is blocked and cann't recover any more.
parser Write blocked,

parser parse blocked,

parse buffer,

The issue can be reproduced. I try to fix the issue, using the following code,the issue can be fixed.

How to add a custom request header

I wanted to implement the call transfer function via gosip, via the REFER method, but could not find a way to add a custom request header，Hoping for help，thanks!

Seems there is memory leak

hi Ghettovoice，
Sorry， Seems I made a mistake to close the previous issue. here. I had to resubmit a new one.

Below is my test code, please check.
test.zip

B.R
William

Character Escaping by chapter 19.1.2

I don't see any code about the character escaping in ParseSipUri， except params part.

I rewrite parse logic using "net/url" like below:

func ParseSipUri(uriStr string) (uri sip.SipUri, err error) {
	//direct parse, get query param
	var r1 *url.URL
	r1, err = url.Parse(uriStr)
	if err != nil {
		return
	}
	if r1.Scheme == "sips" {
		uri.FIsEncrypted = true
	} else if r1.Scheme != "sip" {
		err = fmt.Errorf("wrong schema:%s", r1.Scheme)
		return
	}
	//parse userInfo, host and uri-params
	//replace ";" to "?" and "&" like query params
	var sb strings.Builder
	sb.WriteString("//")
	beforeHost := true
	firstParam := true
	for i := 0; i < len(r1.Opaque); i++ {
		ch := r1.Opaque[i]
		switch ch {
		case '@':
			if beforeHost {
				beforeHost = false
			}
		case ';':
			if !beforeHost {
				if firstParam {
					ch = '?'
					firstParam = false
				} else {
					ch = '&'
				}
			}
		}
		sb.WriteByte(ch)
	}
	r2, err := url.Parse(sb.String())
	if err != nil {
		return
	}
	uri.FHost = strings.ToLower(r2.Hostname())
	if r2.Port() != "" {
		portRaw64, _ := strconv.ParseUint(r2.Port(), 10, 16)
		portRaw16 := uint16(portRaw64)
		uri.FPort = (*sip.Port)(&portRaw16)
	}
	if r2.User != nil {
		uri.FUser = sip.String{Str: r2.User.Username()}
		if pass, ok := r2.User.Password(); ok {
			uri.FPassword = sip.String{Str: pass}
		}
	}
	uri.FHeaders = sip.NewParams()
	uri.FUriParams = sip.NewParams()
	for param, vs := range map[sip.Params]url.Values{
		uri.FHeaders:   r1.Query(),
		uri.FUriParams: r2.Query()} {
		for k, v := range vs {
			if len(v) == 0 {
				param.Add(k, nil)
				continue
			}
			for _, s := range v {
				param.Add(k, sip.String{Str: strings.ToLower(s)})
			}
		}
	}
	return
}

I test it with sip:%61lice;day=tuesday:[email protected];transport=TCP;method=REGISTER?to=sip:bob%40biloxi.com.

How to use it

I use the server below to compile a binary file and run it. Can I register on the server using a software phone?

Could this be a bug in getOrCreateConnection in tcp.go

The below snippet :
if err != nil {
tcp.Log().Debugf("connection for remote address %s %s not found, create a new one", tcp.Network(), raddr)

	tcpConn, err := net.DialTCP(network, nil, raddr)
	if err != nil {
		return nil, &ProtocolError{
			err,
			fmt.Sprintf("connect to %s %s address", tcp.Network(), raddr),
			fmt.Sprintf("%p", tcp),
		}
	}

	conn = NewConnection(tcpConn, key, tcp.Log())

	err = tcp.connections.Put(conn, sockTTL)
}

return conn, err

Could it be the intention is to reuse err variable inside the if block ?
This line will create new err variable inside if block. So if err is nil the if block, it will still return error from the function.

tcpConn, err := net.DialTCP(network, nil, raddr)

Consider silencing some of the warning logs from the Parser

It's not uncommon for non-SIP traffic to hit the port the gosip server is listening on; for example Linphone sends regular keepalive packets every 10s after it's interacted with a server (and I've seen other software do that as well).
When this happens, the logs suddenly become filled with logs such as

WARN[2021-23-03 16:04:46.101] Parser 0xc0000b8240 failed to read start line ''  connection_handler_ptr=0xc00027e000 connection_key="udp:0.0.0.0:5060" connection_network=UDP connection_pool_ptr=0xc000276000 connection_ptr=0xc00023afc0 parser_ptr=0xc0000b8240 prefix=parser.Parser protocol_ptr=0xc000272040 sip_server_ptr=0xc0000a2a20 transport_layer_ptr=0xc0000c3680
WARN[2021-23-03 16:04:46.101] ignore error: %sparser.InvalidStartLineError: Parser 0xc0000b8240 failed to parse first line of message: transmission beginning '' is not a SIP message  connection_handler_ptr=0xc00027e000 connection_key="udp:0.0.0.0:5060" connection_network=UDP connection_pool_ptr=0xc000276000 connection_ptr=0xc00023afc0 prefix=transport.ConnectionHandler protocol_ptr=0xc000272040 sip_server_ptr=0xc0000a2a20 transport_layer_ptr=0xc0000c3680
WARN[2021-23-03 16:04:56.101] Parser 0xc0000b8240 failed to read start line ''  connection_handler_ptr=0xc00027e000 connection_key="udp:0.0.0.0:5060" connection_network=UDP connection_pool_ptr=0xc000276000 connection_ptr=0xc00023afc0 parser_ptr=0xc0000b8240 prefix=parser.Parser protocol_ptr=0xc000272040 sip_server_ptr=0xc0000a2a20 transport_layer_ptr=0xc0000c3680
WARN[2021-23-03 16:04:56.101] ignore error: %sparser.InvalidStartLineError: Parser 0xc0000b8240 failed to parse first line of message: transmission beginning '' is not a SIP message  connection_handler_ptr=0xc00027e000 connection_key="udp:0.0.0.0:5060" connection_network=UDP connection_pool_ptr=0xc000276000 connection_ptr=0xc00023afc0 prefix=transport.ConnectionHandler protocol_ptr=0xc000272040 sip_server_ptr=0xc0000a2a20 transport_layer_ptr=0xc0000c3680
WARN[2021-23-03 16:05:06.121] Parser 0xc0000b8240 failed to read start line ''  connection_handler_ptr=0xc00027e000 connection_key="udp:0.0.0.0:5060" connection_network=UDP connection_pool_ptr=0xc000276000 connection_ptr=0xc00023afc0 parser_ptr=0xc0000b8240 prefix=parser.Parser protocol_ptr=0xc000272040 sip_server_ptr=0xc0000a2a20 transport_layer_ptr=0xc0000c3680
WARN[2021-23-03 16:05:06.121] ignore error: %sparser.InvalidStartLineError: Parser 0xc0000b8240 failed to parse first line of message: transmission beginning '' is not a SIP message  connection_handler_ptr=0xc00027e000 connection_key="udp:0.0.0.0:5060" connection_network=UDP connection_pool_ptr=0xc000276000 connection_ptr=0xc00023afc0 prefix=transport.ConnectionHandler protocol_ptr=0xc000272040 sip_server_ptr=0xc0000a2a20 transport_layer_ptr=0xc0000c3680
WARN[2021-23-03 16:05:16.141] Parser 0xc0000b8240 failed to read start line ''  connection_handler_ptr=0xc00027e000 connection_key="udp:0.0.0.0:5060" connection_network=UDP connection_pool_ptr=0xc000276000 connection_ptr=0xc00023afc0 parser_ptr=0xc0000b8240 prefix=parser.Parser protocol_ptr=0xc000272040 sip_server_ptr=0xc0000a2a20 transport_layer_ptr=0xc0000c3680
WARN[2021-23-03 16:05:16.141] ignore error: %sparser.InvalidStartLineError: Parser 0xc0000b8240 failed to parse first line of message: transmission beginning '' is not a SIP message  connection_handler_ptr=0xc00027e000 connection_key="udp:0.0.0.0:5060" connection_network=UDP connection_pool_ptr=0xc000276000 connection_ptr=0xc00023afc0 prefix=transport.ConnectionHandler protocol_ptr=0xc000272040 sip_server_ptr=0xc0000a2a20 transport_layer_ptr=0xc0000c3680
WARN[2021-23-03 16:05:26.161] Parser 0xc0000b8240 failed to read start line ''  connection_handler_ptr=0xc00027e000 connection_key="udp:0.0.0.0:5060" connection_network=UDP connection_pool_ptr=0xc000276000 connection_ptr=0xc00023afc0 parser_ptr=0xc0000b8240 prefix=parser.Parser protocol_ptr=0xc000272040 sip_server_ptr=0xc0000a2a20 transport_layer_ptr=0xc0000c3680
WARN[2021-23-03 16:05:26.161] ignore error: %sparser.InvalidStartLineError: Parser 0xc0000b8240 failed to parse first line of message: transmission beginning '' is not a SIP message  connection_handler_ptr=0xc00027e000 connection_key="udp:0.0.0.0:5060" connection_network=UDP connection_pool_ptr=0xc000276000 connection_ptr=0xc00023afc0 prefix=transport.ConnectionHandler protocol_ptr=0xc000272040 sip_server_ptr=0xc0000a2a20 transport_layer_ptr=0xc0000c3680
WARN[2021-23-03 16:05:36.181] Parser 0xc0000b8240 failed to read start line ''  connection_handler_ptr=0xc00027e000 connection_key="udp:0.0.0.0:5060" connection_network=UDP connection_pool_ptr=0xc000276000 connection_ptr=0xc00023afc0 parser_ptr=0xc0000b8240 prefix=parser.Parser protocol_ptr=0xc000272040 sip_server_ptr=0xc0000a2a20 transport_layer_ptr=0xc0000c3680
WARN[2021-23-03 16:05:36.181] ignore error: %sparser.InvalidStartLineError: Parser 0xc0000b8240 failed to parse first line of message: transmission beginning '' is not a SIP message  connection_handler_ptr=0xc00027e000 connection_key="udp:0.0.0.0:5060" connection_network=UDP connection_pool_ptr=0xc000276000 connection_ptr=0xc00023afc0 prefix=transport.ConnectionHandler protocol_ptr=0xc000272040 sip_server_ptr=0xc0000a2a20 transport_layer_ptr=0xc0000c3680

WARN[2021-17-03 08:24:14.195] ignore error: %sparser.InvalidMessageFormat: Parser 0xc00007e000 cannot write data: double CRLF sequence not found in the input data  connection_handler_ptr=0xc000278000 connection_key="udp:0.0.0.0:5063" connection_network=UDP connection_pool_ptr=0xc0000d8790 connection_ptr=0xc000270230 prefix=transport.ConnectionHandler protocol_ptr=0xc000145ac0 sip_server_ptr=0xc00010b200 transport_layer_ptr=0xc000159ea0
WARN[2021-17-03 08:24:14.195] ignore error: %sparser.InvalidMessageFormat: Parser 0xc00007e000 cannot write data: double CRLF sequence not found in the input data  connection_handler_ptr=0xc000278000 connection_key="udp:0.0.0.0:5063" connection_network=UDP connection_pool_ptr=0xc0000d8790 connection_ptr=0xc000270230 prefix=transport.ConnectionHandler protocol_ptr=0xc000145ac0 sip_server_ptr=0xc00010b200 transport_layer_ptr=0xc000159ea0
WARN[2021-17-03 08:24:14.195] ignore error: %sparser.InvalidMessageFormat: Parser 0xc00007e000 cannot write data: double CRLF sequence not found in the input data  connection_handler_ptr=0xc000278000 connection_key="udp:0.0.0.0:5063" connection_network=UDP connection_pool_ptr=0xc0000d8790 connection_ptr=0xc000270230 prefix=transport.ConnectionHandler protocol_ptr=0xc000145ac0 sip_server_ptr=0xc00010b200 transport_layer_ptr=0xc000159ea0
WARN[2021-17-03 08:24:14.196] ignore error: %sparser.InvalidMessageFormat: Parser 0xc00007e000 cannot write data: double CRLF sequence not found in the input data  connection_handler_ptr=0xc000278000 connection_key="udp:0.0.0.0:5063" connection_network=UDP connection_pool_ptr=0xc0000d8790 connection_ptr=0xc000270230 prefix=transport.ConnectionHandler protocol_ptr=0xc000145ac0 sip_server_ptr=0xc00010b200 transport_layer_ptr=0xc000159ea0
WARN[2021-17-03 08:24:14.196] ignore error: %sparser.InvalidMessageFormat: Parser 0xc00007e000 cannot write data: double CRLF sequence not found in the input data  connection_handler_ptr=0xc000278000 connection_key="udp:0.0.0.0:5063" connection_network=UDP connection_pool_ptr=0xc0000d8790 connection_ptr=0xc000270230 prefix=transport.ConnectionHandler protocol_ptr=0xc000145ac0 sip_server_ptr=0xc00010b200 transport_layer_ptr=0xc000159ea0
WARN[2021-17-03 08:24:14.196] ignore error: %sparser.InvalidMessageFormat: Parser 0xc00007e000 cannot write data: double CRLF sequence not found in the input data  connection_handler_ptr=0xc000278000 connection_key="udp:0.0.0.0:5063" connection_network=UDP connection_pool_ptr=0xc0000d8790 connection_ptr=0xc000270230 prefix=transport.ConnectionHandler protocol_ptr=0xc000145ac0 sip_server_ptr=0xc00010b200 transport_layer_ptr=0xc000159ea0
WARN[2021-17-03 08:24:14.196] ignore error: %sparser.InvalidMessageFormat: Parser 0xc00007e000 cannot write data: double CRLF sequence not found in the input data  connection_handler_ptr=0xc000278000 connection_key="udp:0.0.0.0:5063" connection_network=UDP connection_pool_ptr=0xc0000d8790 connection_ptr=0xc000270230 prefix=transport.ConnectionHandler protocol_ptr=0xc000145ac0 sip_server_ptr=0xc00010b200 transport_layer_ptr=0xc000159ea0
WARN[2021-17-03 08:25:14.195] ignore error: %sparser.InvalidMessageFormat: Parser 0xc00007e000 cannot write data: double CRLF sequence not found in the input data  connection_handler_ptr=0xc000278000 connection_key="udp:0.0.0.0:5063" connection_network=UDP connection_pool_ptr=0xc0000d8790 connection_ptr=0xc000270230 prefix=transport.ConnectionHandler protocol_ptr=0xc000145ac0 sip_server_ptr=0xc00010b200 transport_layer_ptr=0xc000159ea0
WARN[2021-17-03 08:25:14.195] ignore error: %sparser.InvalidMessageFormat: Parser 0xc00007e000 cannot write data: double CRLF sequence not found in the input data  connection_handler_ptr=0xc000278000 connection_key="udp:0.0.0.0:5063" connection_network=UDP connection_pool_ptr=0xc0000d8790 connection_ptr=0xc000270230 prefix=transport.ConnectionHandler protocol_ptr=0xc000145ac0 sip_server_ptr=0xc00010b200 transport_layer_ptr=0xc000159ea0
WARN[2021-17-03 08:25:14.195] ignore error: %sparser.InvalidMessageFormat: Parser 0xc00007e000 cannot write data: double CRLF sequence not found in the input data  connection_handler_ptr=0xc000278000 connection_key="udp:0.0.0.0:5063" connection_network=UDP connection_pool_ptr=0xc0000d8790 connection_ptr=0xc000270230 prefix=transport.ConnectionHandler protocol_ptr=0xc000145ac0 sip_server_ptr=0xc00010b200 transport_layer_ptr=0xc000159ea0
WARN[2021-17-03 08:25:14.195] ignore error: %sparser.InvalidMessageFormat: Parser 0xc00007e000 cannot write data: double CRLF sequence not found in the input data  connection_handler_ptr=0xc000278000 connection_key="udp:0.0.0.0:5063" connection_network=UDP connection_pool_ptr=0xc0000d8790 connection_ptr=0xc000270230 prefix=transport.ConnectionHandler protocol_ptr=0xc000145ac0 sip_server_ptr=0xc00010b200 transport_layer_ptr=0xc000159ea0
WARN[2021-17-03 08:25:14.196] ignore error: %sparser.InvalidMessageFormat: Parser 0xc00007e000 cannot write data: double CRLF sequence not found in the input data  connection_handler_ptr=0xc000278000 connection_key="udp:0.0.0.0:5063" connection_network=UDP connection_pool_ptr=0xc0000d8790 connection_ptr=0xc000270230 prefix=transport.ConnectionHandler protocol_ptr=0xc000145ac0 sip_server_ptr=0xc00010b200 transport_layer_ptr=0xc000159ea0
WARN[2021-17-03 08:25:14.196] ignore error: %sparser.InvalidMessageFormat: Parser 0xc00007e000 cannot write data: double CRLF sequence not found in the input data  connection_handler_ptr=0xc000278000 connection_key="udp:0.0.0.0:5063" connection_network=UDP connection_pool_ptr=0xc0000d8790 connection_ptr=0xc000270230 prefix=transport.ConnectionHandler protocol_ptr=0xc000145ac0 sip_server_ptr=0xc00010b200 transport_layer_ptr=0xc000159ea0
WARN[2021-17-03 08:25:14.196] ignore error: %sparser.InvalidMessageFormat: Parser 0xc00007e000 cannot write data: double CRLF sequence not found in the input data  connection_handler_ptr=0xc000278000 connection_key="udp:0.0.0.0:5063" connection_network=UDP connection_pool_ptr=0xc0000d8790 connection_ptr=0xc000270230 prefix=transport.ConnectionHandler protocol_ptr=0xc000145ac0 sip_server_ptr=0xc00010b200 transport_layer_ptr=0xc000159ea0
WARN[2021-17-03 08:26:14.196] ignore error: %sparser.InvalidMessageFormat: Parser 0xc00007e000 cannot write data: double CRLF sequence not found in the input data  connection_handler_ptr=0xc000278000 connection_key="udp:0.0.0.0:5063" connection_network=UDP connection_pool_ptr=0xc0000d8790 connection_ptr=0xc000270230 prefix=transport.ConnectionHandler protocol_ptr=0xc000145ac0 sip_server_ptr=0xc00010b200 transport_layer_ptr=0xc000159ea0
WARN[2021-17-03 08:26:14.196] ignore error: %sparser.InvalidMessageFormat: Parser 0xc00007e000 cannot write data: double CRLF sequence not found in the input data  connection_handler_ptr=0xc000278000 connection_key="udp:0.0.0.0:5063" connection_network=UDP connection_pool_ptr=0xc0000d8790 connection_ptr=0xc000270230 prefix=transport.ConnectionHandler protocol_ptr=0xc000145ac0 sip_server_ptr=0xc00010b200 transport_layer_ptr=0xc000159ea0
WARN[2021-17-03 08:26:14.197] ignore error: %sparser.InvalidMessageFormat: Parser 0xc00007e000 cannot write data: double CRLF sequence not found in the input data  connection_handler_ptr=0xc000278000 connection_key="udp:0.0.0.0:5063" connection_network=UDP connection_pool_ptr=0xc0000d8790 connection_ptr=0xc000270230 prefix=transport.ConnectionHandler protocol_ptr=0xc000145ac0 sip_server_ptr=0xc00010b200 transport_layer_ptr=0xc000159ea0
WARN[2021-17-03 08:26:14.197] ignore error: %sparser.InvalidMessageFormat: Parser 0xc00007e000 cannot write data: double CRLF sequence not found in the input data  connection_handler_ptr=0xc000278000 connection_key="udp:0.0.0.0:5063" connection_network=UDP connection_pool_ptr=0xc0000d8790 connection_ptr=0xc000270230 prefix=transport.ConnectionHandler protocol_ptr=0xc000145ac0 sip_server_ptr=0xc00010b200 transport_layer_ptr=0xc000159ea0
WARN[2021-17-03 08:26:14.197] ignore error: %sparser.InvalidMessageFormat: Parser 0xc00007e000 cannot write data: double CRLF sequence not found in the input data  connection_handler_ptr=0xc000278000 connection_key="udp:0.0.0.0:5063" connection_network=UDP connection_pool_ptr=0xc0000d8790 connection_ptr=0xc000270230 prefix=transport.ConnectionHandler protocol_ptr=0xc000145ac0 sip_server_ptr=0xc00010b200 transport_layer_ptr=0xc000159ea0
WARN[2021-17-03 08:26:14.197] ignore error: %sparser.InvalidMessageFormat: Parser 0xc00007e000 cannot write data: double CRLF sequence not found in the input data  connection_handler_ptr=0xc000278000 connection_key="udp:0.0.0.0:5063" connection_network=UDP connection_pool_ptr=0xc0000d8790 connection_ptr=0xc000270230 prefix=transport.ConnectionHandler protocol_ptr=0xc000145ac0 sip_server_ptr=0xc00010b200 transport_layer_ptr=0xc000159ea0
WARN[2021-17-03 08:26:14.197] ignore error: %sparser.InvalidMessageFormat: Parser 0xc00007e000 cannot write data: double CRLF sequence not found in the input data  connection_handler_ptr=0xc000278000 connection_key="udp:0.0.0.0:5063" connection_network=UDP connection_pool_ptr=0xc0000d8790 connection_ptr=0xc000270230 prefix=transport.ConnectionHandler protocol_ptr=0xc000145ac0 sip_server_ptr=0xc00010b200 transport_layer_ptr=0xc000159ea0
WARN[2021-17-03 08:27:14.196] ignore error: %sparser.InvalidMessageFormat: Parser 0xc00007e000 cannot write data: double CRLF sequence not found in the input data  connection_handler_ptr=0xc000278000 connection_key="udp:0.0.0.0:5063" connection_network=UDP connection_pool_ptr=0xc0000d8790 connection_ptr=0xc000270230 prefix=transport.ConnectionHandler protocol_ptr=0xc000145ac0 sip_server_ptr=0xc00010b200 transport_layer_ptr=0xc000159ea0
WARN[2021-17-03 08:27:14.196] ignore error: %sparser.InvalidMessageFormat: Parser 0xc00007e000 cannot write data: double CRLF sequence not found in the input data  connection_handler_ptr=0xc000278000 connection_key="udp:0.0.0.0:5063" connection_network=UDP connection_pool_ptr=0xc0000d8790 connection_ptr=0xc000270230 prefix=transport.ConnectionHandler protocol_ptr=0xc000145ac0 sip_server_ptr=0xc00010b200 transport_layer_ptr=0xc000159ea0
WARN[2021-17-03 08:27:14.196] ignore error: %sparser.InvalidMessageFormat: Parser 0xc00007e000 cannot write data: double CRLF sequence not found in the input data  connection_handler_ptr=0xc000278000 connection_key="udp:0.0.0.0:5063" connection_network=UDP connection_pool_ptr=0xc0000d8790 connection_ptr=0xc000270230 prefix=transport.ConnectionHandler protocol_ptr=0xc000145ac0 sip_server_ptr=0xc00010b200 transport_layer_ptr=0xc000159ea0
WARN[2021-17-03 08:27:14.196] ignore error: %sparser.InvalidMessageFormat: Parser 0xc00007e000 cannot write data: double CRLF sequence not found in the input data  connection_handler_ptr=0xc000278000 connection_key="udp:0.0.0.0:5063" connection_network=UDP connection_pool_ptr=0xc0000d8790 connection_ptr=0xc000270230 prefix=transport.ConnectionHandler protocol_ptr=0xc000145ac0 sip_server_ptr=0xc00010b200 transport_layer_ptr=0xc000159ea0
WARN[2021-17-03 08:27:14.196] ignore error: %sparser.InvalidMessageFormat: Parser 0xc00007e000 cannot write data: double CRLF sequence not found in the input data  connection_handler_ptr=0xc000278000 connection_key="udp:0.0.0.0:5063" connection_network=UDP connection_pool_ptr=0xc0000d8790 connection_ptr=0xc000270230 prefix=transport.ConnectionHandler protocol_ptr=0xc000145ac0 sip_server_ptr=0xc00010b200 transport_layer_ptr=0xc000159ea0
WARN[2021-17-03 08:27:14.197] ignore error: %sparser.InvalidMessageFormat: Parser 0xc00007e000 cannot write data: double CRLF sequence not found in the input data  connection_handler_ptr=0xc000278000 connection_key="udp:0.0.0.0:5063" connection_network=UDP connection_pool_ptr=0xc0000d8790 connection_ptr=0xc000270230 prefix=transport.ConnectionHandler protocol_ptr=0xc000145ac0 sip_server_ptr=0xc00010b200 transport_layer_ptr=0xc000159ea0
WARN[2021-17-03 08:27:14.197] ignore error: %sparser.InvalidMessageFormat: Parser 0xc00007e000 cannot write data: double CRLF sequence not found in the input data  connection_handler_ptr=0xc000278000 connection_key="udp:0.0.0.0:5063" connection_network=UDP connection_pool_ptr=0xc0000d8790 connection_ptr=0xc000270230 prefix=transport.ConnectionHandler protocol_ptr=0xc000145ac0 sip_server_ptr=0xc00010b200 transport_layer_ptr=0xc000159ea0
WARN[2021-17-03 08:28:14.216] ignore error: %sparser.InvalidMessageFormat: Parser 0xc00007e000 cannot write data: double CRLF sequence not found in the input data  connection_handler_ptr=0xc000278000 connection_key="udp:0.0.0.0:5063" connection_network=UDP connection_pool_ptr=0xc0000d8790 connection_ptr=0xc000270230 prefix=transport.ConnectionHandler protocol_ptr=0xc000145ac0 sip_server_ptr=0xc00010b200 transport_layer_ptr=0xc000159ea0
WARN[2021-17-03 08:28:14.217] ignore error: %sparser.InvalidMessageFormat: Parser 0xc00007e000 cannot write data: double CRLF sequence not found in the input data  connection_handler_ptr=0xc000278000 connection_key="udp:0.0.0.0:5063" connection_network=UDP connection_pool_ptr=0xc0000d8790 connection_ptr=0xc000270230 prefix=transport.ConnectionHandler protocol_ptr=0xc000145ac0 sip_server_ptr=0xc00010b200 transport_layer_ptr=0xc000159ea0
WARN[2021-17-03 08:28:14.217] ignore error: %sparser.InvalidMessageFormat: Parser 0xc00007e000 cannot write data: double CRLF sequence not found in the input data  connection_handler_ptr=0xc000278000 connection_key="udp:0.0.0.0:5063" connection_network=UDP connection_pool_ptr=0xc0000d8790 connection_ptr=0xc000270230 prefix=transport.ConnectionHandler protocol_ptr=0xc000145ac0 sip_server_ptr=0xc00010b200 transport_layer_ptr=0xc000159ea0
WARN[2021-17-03 08:28:14.217] ignore error: %sparser.InvalidMessageFormat: Parser 0xc00007e000 cannot write data: double CRLF sequence not found in the input data  connection_handler_ptr=0xc000278000 connection_key="udp:0.0.0.0:5063" connection_network=UDP connection_pool_ptr=0xc0000d8790 connection_ptr=0xc000270230 prefix=transport.ConnectionHandler protocol_ptr=0xc000145ac0 sip_server_ptr=0xc00010b200 transport_layer_ptr=0xc000159ea0

Which is pretty annoying, because it offers no way to print the info logs from gosip without having them flooded by these warnings.

Maybe these warnings could be removed, or silenced via a field in the gosip.ServerConfig?

	if rb.to == nil {
	return nil, fmt.Errorf("empty 'From' header")
	}