Concurrency issues when creating a connection

[hateeyan]

When using DialogUA to send Invite concurrently, the connection will be created multiple times.

The log shows that the connection was created multiple times. Because the port was already bound, one of the requests failed.

failed to send sip invite: listen udp 10.9.232.246:5020: bind: address already in use
{"level":"debug","caller":"transportlayer","host":"10.9.232.246","port":5020,"network":"udp","time":"2025-01-02T10:21:12+08:00","message":"Via header used for creating connection"}
{"level":"debug","caller":"transportlayer","host":"10.9.232.246","port":5020,"network":"udp","time":"2025-01-02T10:21:12+08:00","message":"Via header used for creating connection"}
{"level":"debug","caller":"transport<UDP>","raddr":"10.9.232.246:8060","time":"2025-01-02T10:21:12+08:00","message":"New connection"}

We may need to add a mutex in CreateConnection and check whether the connection has been created by another goroutine.

sipgo/sip/transport_layer.go

Lines 396 to 401 in 4cd2184

	l.log.Debug().Str("host", viaHop.Host).Int("port", viaHop.Port).Str("network", network).Msg("Via header used for creating connection")
	c, err = transport.CreateConnection(ctx, laddr, raddr, l.handleMessage)
	if err != nil {
	return nil, err
	}

[emiago]

Hi @hateeyan Thanks for reporting this. I see now issue. I think this needs fix on way transport connection pool is used. Adding into list to fix

[emiago]

NOTE: Issue is only related for fixed IP. Recommendation is to build listener first.
Diago does this more nicely, as generally running full client requires both directions.
We may not introduce this contention as can be fixed with different usage.

@hateeyan Have you tried approach creating listener first, and then reusing his IP?

[hateeyan]

@hateeyan Have you tried approach creating listener first, and then reusing his IP?

@emiago Yeah, that's what I'm doing now.
But for a client, it is a little strange to create a listener first. Anyway, it is not a big problem.

[emiago]

@hateeyan yes I understand. It makes sense for non dialogs, but in dialogs you need to listen.
I will leave this open.