Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

connection reset handling #283

Open
ozgurakcali opened this issue Jan 2, 2025 · 0 comments
Open

connection reset handling #283

ozgurakcali opened this issue Jan 2, 2025 · 0 comments

Comments

@ozgurakcali
Copy link

We are using the Sofia SIP stack as a SIP server for third parties to initiate SIP calls.

We have observed the following behavior

  • We receive SIP Invite over TLS
  • Sofia sends 100 Trying response
  • Sofia tries to send 183 response, it fails (connection reset by peer)
  • Sofia tries to send 200 response, tries to establish a TLS connection to the ip / port pair on the incoming connection, it fails.

The final step fails because the party integrating with us is not listening on the source port from the incoming connection, but instead they have are listening on a specific port, which they provide correctly on the VIA header.

RFC 3261 specifies that the clients should keep the connection open, and servers should respond to INVITE requests on these connections, but when the connection fails for some reason, the server should re-open a connection to the incoming IP address and the port number in the Via header. It looks like Sofia's behavior is incorrect here, trying to open a connection on the source port instead of the port specified on the Via header.

Relevant section on the RFC:

For reliable transports, the response is normally sent on the
   connection on which the request was received.  Therefore, the client
   transport MUST be prepared to receive the response on the same
   connection used to send the request.  Under error conditions, the
   server may attempt to open a new connection to send the response.  To
   handle this case, the transport layer MUST also be prepared to
   receive an incoming connection on the source IP address from which
   the request was sent and port number in the "sent-by" field.  It also
   MUST be prepared to receive incoming connections on any address and
   port that would be selected by a server based on the procedures
   described in Section 5 of [4].

Sample logs describing the issue:

# Incoming INVITE, specifying 5061 as the port
recv 1194 bytes from tls/[....]:54061 at 13:20:09.992271:
------------------------------------------------------------------------
INVITE sip:[email protected];transport=tls SIP/2.0
...
Via: SIP/2.0/TLS ......:5061;branch=z9hG4bK4633.e082cce6.0
...

# Trying to send 183, failure with Connection reset by peer
nta.c:6879 incoming_reply() nta: sent 183 Session Progress for INVITE (1)
nua_session.c:4131 signal_call_state_change() nua(0x7f9e9002b030): call state changed: received -> early, sent answer
soa.c:1268 soa_get_local_sdp() soa_get_local_sdp(static::0x7f9e9012fa80, [0x7f9ef1613c80], [0x7f9ef1613c88], [(nil)]) called
soa.c:615 soa_get_params() soa_get_params(static::0x7f9e9012fa80, ...) called
nua_stack.c:301 nua_stack_event() nua(0x7f9e9002b030): event i_state 183 Session Progress
nua_stack.c:389 nua_application_event() nua: nua_application_event: entering
nua.c:1170 nua_handle_unref_user() nua nua_handle_unref_user(0x7f9e9002b030): entering
nua_stack.c:558 nua_signal() nua(0x7f9e9002b030): sent signal r_handle_unref
nua.c:1157 nua_unref_user() nua: nua_unref_user: entering
nua_stack.c:558 nua_signal() nua((nil)): sent signal r_unref
nua_stack.c:599 nua_stack_signal() nua(0x7f9e9002b030): recv signal r_handle_unref
nua_stack.c:599 nua_stack_signal() nua((nil)): recv signal r_unref
tport.c:2796 tport_wakeup() tport_wakeup(0x7f9e900ac2a0): events IN HUP ERR
nta.c:2767 agent_tp_error() nta_agent: tport: Connection reset by peer
tport.c:2102 tport_close() tport_close(0x7f9e900ac2a0): tls/.....:54061/sips


# Trying to send 200, attempting to re-open a connection on the source port
nua.c:878 nua_respond() nua: nua_respond: entering
nua_stack.c:558 nua_signal() nua(0x7f9e9002b030): sent signal r_respond
nua_stack.c:601 nua_stack_signal() nua(0x7f9e9002b030): recv signal r_respond 200 OK
nua_params.c:484 nua_stack_set_params() nua: nua_stack_set_params: entering
soa.c:402 soa_set_params() soa_set_params(static::0x7f9e9012fa80, ...) called
soa.c:1051 soa_set_user_sdp() soa_set_user_sdp(static::0x7f9e9012fa80, (nil), 0x2defb1c2, -1) called
nua_session.c:2317 nua_invite_server_respond() nua: nua_invite_server_respond: entering
soa.c:1268 soa_get_local_sdp() soa_get_local_sdp(static::0x7f9e9012fa80, [(nil)], [0x7f9ef1613bb0], [0x7f9ef1613bac]) called
tport.c:3290 tport_tsend() tport_tsend(0x7f9e900ac2a0) tpn = TLS/.....:54061
tport.c:4076 tport_resolve() tport_resolve addrinfo = ......:54061
tport.c:866 tport_alloc_secondary() tport_alloc_secondary(0x7f9e90005c30): new secondary tport 0x7f9e9005b7a0
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant