You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
We are using the Sofia SIP stack as a SIP server for third parties to initiate SIP calls.
We have observed the following behavior
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:
Sample logs describing the issue:
The text was updated successfully, but these errors were encountered: