The "branch" value in the Via header is wrong for an ACK in response to an INVITE that requires authentication
The actual value is the one of the second INVITE (with auth) instead of the first one (without auth)
To comply with RFC3261#17.1.1.3, the ACK Via header must be the same as the corresponding INVITE message
As a result, the INVITE is finally rejected
The issue comes from seDlg.FirstRequest in SIPExerDialogLoop() being modified by SIPExerProcessResponse() before sgsip.SGSIPInviteToACKString() is called to send the ACK.
A quick and dirty fix is to make a deep clone of seDlg.FirstRequest and use this copy inthe call to sgsip.SGSIPInviteToACKString() but this is definitely not how this should be fixed.
# 1st INVITE message :
INVITE bob@localhost SIP/2.0
Via: SIP/2.0/UDP 172.17.0.20:42701;rport;branch=z9hG4bKSG.3d94bc0c-c3f8-4839-8b62-36fa47808d27
# This INVITE requires auth :
SIP/2.0 407 Proxy Authentication Required
Via: SIP/2.0/UDP 172.17.0.20:42701;rport=42701;branch=z9hG4bKSG.3d94bc0c-c3f8-4839-8b62-36fa47808d27
# ACK to INVITE with an incorrect branch value :
ACK bob@localhost SIP/2.0
Via: SIP/2.0/UDP 172.17.0.20:42701;rport;branch=z9hG4bKSG.35479688-1274-4aaf-b9b3-2f9bb4515ed9
#################### The branch value should be z9hG4bKSG.3d94bc0c-c3f8-4839-8b62-36fa47808d27
# 2nd INVITE with auth :
INVITE bob@localhost SIP/2.0
Via: SIP/2.0/UDP 172.17.0.20:42701;rport;branch=z9hG4bKSG.35479688-1274-4aaf-b9b3-2f9bb4515ed9
# As the ACK was not accepted, the INVITE is finally rejected :
SIP/2.0 407 Proxy Authentication Required
Via: SIP/2.0/UDP 172.17.0.20:42701;rport=42701;branch=z9hG4bKSG.3d94bc0c-c3f8-4839-8b62-36fa47808d27
The "branch" value in the Via header is wrong for an ACK in response to an INVITE that requires authentication The actual value is the one of the second INVITE (with auth) instead of the first one (without auth) To comply with RFC3261#17.1.1.3, the ACK Via header must be the same as the corresponding INVITE message As a result, the INVITE is finally rejected The issue comes from seDlg.FirstRequest in SIPExerDialogLoop() being modified by SIPExerProcessResponse() before sgsip.SGSIPInviteToACKString() is called to send the ACK. A quick and dirty fix is to make a deep clone of seDlg.FirstRequest and use this copy inthe call to sgsip.SGSIPInviteToACKString() but this is definitely not how this should be fixed.