Tag in Request Line of ACK

[jrozhon]

Hi,

first, let me thank you for your work. I am on the development branch and found out that ACK requests are formatted improperly having ";tag=xxxx" in request line. Example:

ACK sip:[email protected]>;tag=z9hG4bK4e07408562bedb8b60ce05c1d SIP/2.0
Via: SIP/2.0/UDP x.x.x.x:5070;branch=z9hG4bK4e07408562bedb8b60ce05c1d;rport=5070;received=xxx
Max-Forwards: 70
To: "" <sip:[email protected]>;tag=251d4995
From: "" <sip:[email protected]>;tag=4cb0f475
Call-ID: [email protected]:5070
CSeq: 1 ACK
User-Agent: pyVoIP 2.0.0
Content-Length: 0

This comes from the fact that the request line is populated by the contents of request.headers["To"]["raw"].

I fixed it by:

--- pyVoIP_orig/pyVoIP/SIP.py   2023-01-23 17:14:24.520953996 +0100
+++ pyVoIP/pyVoIP/SIP.py        2023-01-23 17:40:44.314523342 +0100
@@ -1400,7 +1400,7 @@

     def gen_ack(self, request: SIPMessage) -> str:
         tag = self.tagLibrary[request.headers["Call-ID"]]
-        t = request.headers["To"]["raw"].strip("<").strip(">")
+        t = request.headers["To"]["uri"].strip("<").strip(">")
         ackMessage = f"ACK {t} SIP/2.0\r\n"
         ackMessage += self._gen_response_via_header(request)
         ackMessage += "Max-Forwards: 70\r\n"

Now, ACK seems to be properly formatted.

ACK sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP x.x.x.x:5070;branch=z9hG4bK4e07408562bedb8b60ce05c1d;rport=5070;received=x.x.x.x
Max-Forwards: 70
To: "" <sip:[email protected]>;tag=5dc7fdbc
From: "" <sip:[email protected]>;tag=9b47e14d
Call-ID: [email protected]:5070
CSeq: 1 ACK
User-Agent: pyVoIP 2.0.0
Content-Length: 0

Please, let me know if I can help you fix this issue.

[tayler6000]

This issue was resolved in the development branch in commit c3acacc. This is still an issue in pyVoIP v1.6.4 however. @jrozhon do you remember if this caused a PBX, UAS, Proxy, or similar to not accept the ACK? If so, this would be a broken feature and I would consider patching it and releasing v1.6.5.

Moving to the Todo - Patching status for now.

[tayler6000]

Upon further checking, this is actually not an issue in master.

[jrozhon]

Hi, in my case, it caused Asterisk to ignore the ACK, but I think this would be a general issue