SIP Register request with CSeq Number

Hai Everyone,

I have an asterisk server installed on CentOS Linux release 7.9.2009 (Core) with Asterisk version Asterisk 16.17.0.

I have SIP trunks connected from the Telecom operator and now we have noticed an issue that SIP trunks get unregister when we are registration registration after the registration timeout.

So I have SIP trunk registered from the Operator at 13:00:00 and I have a registration timeout of 300 Seconds and when re-register at 13:35:00 SIP trunk provider sends back unauthorized instead of 200 OK. And Asterisk keeps sending re-registration until the SIP gets register.

But when we send the re-registration of the SIP trunk register we are able to see the same CSeq number which was used in the process request and the telecom operator wanted to us to send a new Cseq number for every new request.

Is there a way to suggest achieving the same?

Sample Wireshark trace below for reference.

Internet Protocol Version 4, Src: 10.10.10.10, Dst: 10.10.20.20
User Datagram Protocol, Src Port: 5060, Dst Port: 5060
Session Initiation Protocol (REGISTER)
Request-Line: REGISTER sip:10.10.20.20 SIP/2.0
Message Header
Via: SIP/2.0/UDP 10.10.10.10:5060;branch=z9hG4bK60722b31
Max-Forwards: 70
From: sip:68880888@10.10.20.20;tag=as0af0b750
To: sip:68880888@10.10.20.20
Call-ID: 76a211b70f1b7cba6cea00b93528dcf5@10.10.10.10
CSeq: 375 REGISTER

Frame 1301: 472 bytes on wire (3776 bits), 472 bytes captured (3776 bits)
Internet Protocol Version 4, Src: 10.10.20.20, Dst: 10.10.10.10
User Datagram Protocol, Src Port: 5060, Dst Port: 5060
Session Initiation Protocol (401)
Status-Line: SIP/2.0 401 Unauthorized
Message Header
Via: SIP/2.0/UDP 10.10.10.10:5060;branch=z9hG4bK60722b31
Call-ID: 76a211b70f1b7cba6cea00b93528dcf5@10.10.10.10
From: sip:68880888@10.10.20.20;tag=as0af0b750
To: sip:68880888@10.10.20.20;tag=a3gorjam
CSeq: 375 REGISTER

Frame 1332: 634 bytes on wire (5072 bits), 634 bytes captured (5072 bits)
Internet Protocol Version 4, Src: 10.10.10.10, Dst: 10.10.20.20
User Datagram Protocol, Src Port: 5060, Dst Port: 5060
Session Initiation Protocol (REGISTER)
Request-Line: REGISTER sip:10.10.20.20 SIP/2.0
Message Header
Via: SIP/2.0/UDP 10.10.10.10:5060;branch=z9hG4bK60722b31
Max-Forwards: 70
From: sip:68880888@10.10.20.20;tag=as0af0b750
To: sip:68880888@10.10.20.20
Call-ID: 76a211b70f1b7cba6cea00b93528dcf5@10.10.10.10
CSeq: 375 REGISTER

Frame 1333: 472 bytes on wire (3776 bits), 472 bytes captured (3776 bits)
Internet Protocol Version 4, Src: 10.10.20.20, Dst: 10.10.10.10
User Datagram Protocol, Src Port: 5060, Dst Port: 5060
Session Initiation Protocol (401)
Status-Line: SIP/2.0 401 Unauthorized
Message Header
Via: SIP/2.0/UDP 10.10.10.10:5060;branch=z9hG4bK60722b31
Call-ID: 76a211b70f1b7cba6cea00b93528dcf5@10.10.10.10
From: sip:68880888@10.10.20.20;tag=as0af0b750
To: sip:68880888@10.10.20.20;tag=a3gorjam
CSeq: 375 REGISTER

Maybe that there is something going wrong, but that’s difficult to say without knowing what is connected here.

The initial 401 is normal, but usually there should be a WWW-Authenticate header and this seems to stop the session progress.

I think you will find that a trace from Asterisk itself doesn’t show the 401s. Asterisk is retransmitting on a timeout, not responding to the 401.

If it is seeing the 401s, it isn’t matching them to the request. I think you may have obfuscated at leat the IP addresses, so it is possible you have made the response appear to match when the real one doesn’t.

Please find compete trace with WWW-Autheticate header.

Frame 1332: 634 bytes on wire (5072 bits), 634 bytes captured (5072 bits)
Internet Protocol Version 4, Src: 10.10.10.10, Dst: 10.10.20.20
User Datagram Protocol, Src Port: 5060, Dst Port: 5060
Session Initiation Protocol (REGISTER)
Request-Line: REGISTER sip:10.10.20.20 SIP/2.0
Message Header
Via: SIP/2.0/UDP 10.10.10.10:5060;branch=z9hG4bK60722b31
Max-Forwards: 70
From: sip:68880888@10.10.20.20;tag=as0af0b750
To: sip:68880888@10.10.20.20
Call-ID: 76a211b70f1b7cba6cea00b93528dcf5@10.10.10.10
CSeq: 375 REGISTER
Supported: replaces, timer
User-Agent: Telephony
Authorization: Digest username=“68880888”, realm=“SIP-68889200”, algorithm=MD5, uri=“sip:10.10.20.20”, nonce=“7fc5644cd2c7f6d73affa7c590e7d8af”, response=“4b00442e88b3de20f5f743f2cee6aa0d”
Expires: 300
Contact: sip:68880888@10.10.10.10:5060
Content-Length: 0

Frame 1333: 472 bytes on wire (3776 bits), 472 bytes captured (3776 bits)
Internet Protocol Version 4, Src: 10.10.20.20, Dst: 10.10.10.10
User Datagram Protocol, Src Port: 5060, Dst Port: 5060
Session Initiation Protocol (401)
Status-Line: SIP/2.0 401 Unauthorized
Message Header
Via: SIP/2.0/UDP 10.10.10.10:5060;branch=z9hG4bK60722b31
Call-ID: 76a211b70f1b7cba6cea00b93528dcf5@10.10.10.10
From: sip:68880888@10.10.20.20;tag=as0af0b750
To: sip:68880888@10.10.20.20;tag=a3gorjam
CSeq: 375 REGISTER
User-Agent: SoftSwitch
WWW-Authenticate: Digest realm=“SIP-68889200”,nonce=“bf272c5f1558befb11675e94def46b72”,ZTE-ID=f62ff22d0d55776fd2805afd9b2bd989
Content-Length: 0

Frame 1387: 634 bytes on wire (5072 bits), 634 bytes captured (5072 bits)
Internet Protocol Version 4, Src: 10.10.10.10, Dst: 10.10.20.20
User Datagram Protocol, Src Port: 5060, Dst Port: 5060
Session Initiation Protocol (REGISTER)
Request-Line: REGISTER sip:10.10.20.20 SIP/2.0
Message Header
Via: SIP/2.0/UDP 10.10.10.10:5060;branch=z9hG4bK60722b31
Max-Forwards: 70
From: sip:68880888@10.10.20.20;tag=as0af0b750
To: sip:68880888@10.10.20.20
Call-ID: 76a211b70f1b7cba6cea00b93528dcf5@10.10.10.10
CSeq: 375 REGISTER
Supported: replaces, timer
User-Agent: Telephony
Authorization: Digest username=“68880888”, realm=“SIP-68889200”, algorithm=MD5, uri=“sip:10.10.20.20”, nonce=“7fc5644cd2c7f6d73affa7c590e7d8af”, response=“4b00442e88b3de20f5f743f2cee6aa0d”
Expires: 300
Contact: sip:68880888@10.10.10.10:5060
Content-Length: 0

Frame 1419: 472 bytes on wire (3776 bits), 472 bytes captured (3776 bits)
Internet Protocol Version 4, Src: 10.10.20.20, Dst: 10.10.10.10
User Datagram Protocol, Src Port: 5060, Dst Port: 5060
Session Initiation Protocol (401)
Status-Line: SIP/2.0 401 Unauthorized
Message Header
Via: SIP/2.0/UDP 10.10.10.10:5060;branch=z9hG4bK60722b31
Call-ID: 76a211b70f1b7cba6cea00b93528dcf5@10.10.10.10
From: sip:68880888@10.10.20.20;tag=as0af0b750
To: sip:68880888@10.10.20.20;tag=a3gorjam
CSeq: 375 REGISTER
User-Agent: SoftSwitch
WWW-Authenticate: Digest realm=“SIP-68889200”,nonce=“bf272c5f1558befb11675e94def46b72”,ZTE-ID=f62ff22d0d55776fd2805afd9b2bd989
Content-Length: 0

@EkFudrek @david551

Below is the trace for the working scenario.

Frame 1468: 634 bytes on wire (5072 bits), 634 bytes captured (5072 bits)
Internet Protocol Version 4, Src: 10.10.10.10, Dst: 10.10.20.20
User Datagram Protocol, Src Port: 5060, Dst Port: 5060
Session Initiation Protocol (REGISTER)
Request-Line: REGISTER sip:10.10.20.20 SIP/2.0
Message Header
Via: SIP/2.0/UDP 10.10.10.10:5060;branch=z9hG4bK316b8dfd
Max-Forwards: 70
From: sip:68880888@10.10.20.20;tag=as0af0b750
To: sip:68880888@10.10.20.20
Call-ID: 76a211b70f1b7cba6cea00b93528dcf5@10.10.10.10
CSeq: 376 REGISTER
Supported: replaces, timer
User-Agent: Telephony
Authorization: Digest username=“68880888”, realm=“SIP-68889200”, algorithm=MD5, uri=“sip:10.10.20.20”, nonce=“bf272c5f1558befb11675e94def46b72”, response=“b03ac89127dd1fce96bbf3e563ab34b7”
Expires: 300
Contact: sip:68880888@10.10.10.10:5060
Content-Length: 0

Frame 1474: 424 bytes on wire (3392 bits), 424 bytes captured (3392 bits)
Internet Protocol Version 4, Src: 10.10.20.20, Dst: 10.10.10.10
User Datagram Protocol, Src Port: 5060, Dst Port: 5060
Session Initiation Protocol (200)
Status-Line: SIP/2.0 200 OK
Message Header
Via: SIP/2.0/UDP 10.10.10.10:5060;branch=z9hG4bK316b8dfd
Call-ID: 76a211b70f1b7cba6cea00b93528dcf5@10.10.10.10
From: sip:68880888@10.10.20.20;tag=as0af0b750
To: sip:68880888@10.10.20.20;tag=yrgr3amc
CSeq: 376 REGISTER
User-Agent: SoftSwitch
Date: Tue, 21 Sep 2021 13:32:35 GMT
Contact: sip:68880888@10.10.10.10:5060;expires=300
Content-Length: 0

So, it is working. Did you change anything? Or could it be simply a temporary network problem?

I haven’t changed anything - This issue happens intermittenly.

I need to send cseq must be increased by one for each request.

Any suggestion @EkFudrek @david551

Hai @david551 @EkFudrek

I have been checking this and found that Asterisk sends with the wrong Nonce to the Telecom operator for the Registration Packet and due to this the operator rejects the sip registration packet.
Asterisk was supposed to send the registration request with Nonce received from the previous unauthorized from Telecom operator and with new Cseq number. But the same is not happening intermittently.

is there any suggestion to correct this ?

No. Time Source Destination Protocol Length Info
3 2021-09-21 13:37:22.410347 10.10.10.10 10.10.20.20 SIP 634 Request: REGISTER sip:10.10.20.20 (1 binding) |

Frame 3: 634 bytes on wire (5072 bits), 634 bytes captured (5072 bits)
Internet Protocol Version 4, Src: 10.10.10.10, Dst: 10.10.20.20
User Datagram Protocol, Src Port: 5060, Dst Port: 5060
Session Initiation Protocol (REGISTER)
Request-Line: REGISTER sip:10.10.20.20 SIP/2.0
Message Header
Via: SIP/2.0/UDP 10.10.10.10:5060;branch=z9hG4bK700e676b
Max-Forwards: 70
From: sip:68880888@10.10.20.20;tag=as0af0b750
SIP from address: sip:68880888@10.10.20.20
SIP from tag: as0af0b750
To: sip:68880888@10.10.20.20
SIP to address: sip:68880888@10.10.20.20
Call-ID: 76a211b70f1b7cba6cea00b93528dcf5@10.10.10.10
CSeq: 377 REGISTER
Supported: replaces, timer
User-Agent: Telephony
Authorization: Digest username=“68880888”, realm=“SIP-68889200”, algorithm=MD5, uri=“sip:10.10.20.20”, nonce=“bf272c5f1558befb11675e94def46b72”, response=“b03ac89127dd1fce96bbf3e563ab34b7”
Authentication Scheme: Digest
Username: “68880888”
Realm: “SIP-68889200”
Algorithm: MD5
Authentication URI: “sip:10.10.20.20”
Nonce Value: “bf272c5f1558befb11675e94def46b72”
Digest Authentication Response: “b03ac89127dd1fce96bbf3e563ab34b7”
Expires: 300
Contact: sip:68880888@10.10.10.10:5060
Contact URI: sip:68880888@10.10.10.10:5060
Content-Length: 0

No. Time Source Destination Protocol Length Info
4 2021-09-21 13:37:22.422771 10.10.20.20 10.10.10.10 SIP 472 Status: 401 Unauthorized |

Frame 4: 472 bytes on wire (3776 bits), 472 bytes captured (3776 bits)
Internet Protocol Version 4, Src: 10.10.20.20, Dst: 10.10.10.10
User Datagram Protocol, Src Port: 5060, Dst Port: 5060
Session Initiation Protocol (401)
Status-Line: SIP/2.0 401 Unauthorized
Message Header
Via: SIP/2.0/UDP 10.10.10.10:5060;branch=z9hG4bK700e676b
Call-ID: 76a211b70f1b7cba6cea00b93528dcf5@10.10.10.10
From: sip:68880888@10.10.20.20;tag=as0af0b750
SIP from address: sip:68880888@10.10.20.20
SIP from tag: as0af0b750
To: sip:68880888@10.10.20.20;tag=bngrgl34
SIP to address: sip:68880888@10.10.20.20
SIP to tag: bngrgl34
CSeq: 377 REGISTER
User-Agent: ZTE-SoftSwitch
WWW-Authenticate: Digest realm=“SIP-68889200”,nonce=“5b6847c6f2b05851070a7c10602cce87”,ZTE-ID=694579d9636cb0748c101dfbc203134f
Authentication Scheme: Digest
Realm: “SIP-68889200”
Nonce Value: “5b6847c6f2b05851070a7c10602cce87”
ZTE-ID=694579d9636cb0748c101dfbc203134f
Content-Length: 0

No. Time Source Destination Protocol Length Info
5 2021-09-21 13:37:24.301300 10.10.10.10 10.10.20.20 SIP 634 Request: REGISTER sip:10.10.20.20 (1 binding) |

Frame 5: 634 bytes on wire (5072 bits), 634 bytes captured (5072 bits)
Internet Protocol Version 4, Src: 10.10.10.10, Dst: 10.10.20.20
User Datagram Protocol, Src Port: 5060, Dst Port: 5060
Session Initiation Protocol (REGISTER)
Request-Line: REGISTER sip:10.10.20.20 SIP/2.0
Message Header
Via: SIP/2.0/UDP 10.10.10.10:5060;branch=z9hG4bK700e676b
Max-Forwards: 70
From: sip:68880888@10.10.20.20;tag=as0af0b750
SIP from address: sip:68880888@10.10.20.20
SIP from tag: as0af0b750
To: sip:68880888@10.10.20.20
SIP to address: sip:68880888@10.10.20.20
Call-ID: 76a211b70f1b7cba6cea00b93528dcf5@10.10.10.10
CSeq: 377 REGISTER
Supported: replaces, timer
User-Agent: Telephony
Authorization: Digest username=“68880888”, realm=“SIP-68889200”, algorithm=MD5, uri=“sip:10.10.20.20”, nonce=“bf272c5f1558befb11675e94def46b72”, response=“b03ac89127dd1fce96bbf3e563ab34b7”
Authentication Scheme: Digest
Username: “68880888”
Realm: “SIP-68889200”
Algorithm: MD5
Authentication URI: “sip:10.10.20.20”
Nonce Value: “bf272c5f1558befb11675e94def46b72”
Digest Authentication Response: “b03ac89127dd1fce96bbf3e563ab34b7”
Expires: 300
Contact: sip:68880888@10.10.10.10:5060
Contact URI: sip:68880888@10.10.10.10:5060
Content-Length: 0

No. Time Source Destination Protocol Length Info
6 2021-09-21 13:37:24.306410 10.10.20.20 10.10.10.10 SIP 472 Status: 401 Unauthorized |

Frame 6: 472 bytes on wire (3776 bits), 472 bytes captured (3776 bits)
Internet Protocol Version 4, Src: 10.10.20.20, Dst: 10.10.10.10
User Datagram Protocol, Src Port: 5060, Dst Port: 5060
Session Initiation Protocol (401)
Status-Line: SIP/2.0 401 Unauthorized
Message Header
Via: SIP/2.0/UDP 10.10.10.10:5060;branch=z9hG4bK700e676b
Call-ID: 76a211b70f1b7cba6cea00b93528dcf5@10.10.10.10
From: sip:68880888@10.10.20.20;tag=as0af0b750
SIP from address: sip:68880888@10.10.20.20
SIP from tag: as0af0b750
To: sip:68880888@10.10.20.20;tag=bngrgl34
SIP to address: sip:68880888@10.10.20.20
SIP to tag: bngrgl34
CSeq: 377 REGISTER
User-Agent: ZTE-SoftSwitch
WWW-Authenticate: Digest realm=“SIP-68889200”,nonce=“5b6847c6f2b05851070a7c10602cce87”,ZTE-ID=694579d9636cb0748c101dfbc203134f
Authentication Scheme: Digest
Realm: “SIP-68889200”
Nonce Value: “5b6847c6f2b05851070a7c10602cce87”
ZTE-ID=694579d9636cb0748c101dfbc203134f
Content-Length: 0

No. Time Source Destination Protocol Length Info
7 2021-09-21 13:37:24.750605 10.10.10.10 10.10.20.20 SIP 634 Request: REGISTER sip:10.10.20.20 (1 binding) |

Frame 7: 634 bytes on wire (5072 bits), 634 bytes captured (5072 bits)
Internet Protocol Version 4, Src: 10.10.10.10, Dst: 10.10.20.20
User Datagram Protocol, Src Port: 5060, Dst Port: 5060
Session Initiation Protocol (REGISTER)
Request-Line: REGISTER sip:10.10.20.20 SIP/2.0
Message Header
Via: SIP/2.0/UDP 10.10.10.10:5060;branch=z9hG4bK700e676b
Max-Forwards: 70
From: sip:68880888@10.10.20.20;tag=as0af0b750
SIP from address: sip:68880888@10.10.20.20
SIP from tag: as0af0b750
To: sip:68880888@10.10.20.20
SIP to address: sip:68880888@10.10.20.20
Call-ID: 76a211b70f1b7cba6cea00b93528dcf5@10.10.10.10
CSeq: 377 REGISTER
Supported: replaces, timer
User-Agent: Telephony
Authorization: Digest username=“68880888”, realm=“SIP-68889200”, algorithm=MD5, uri=“sip:10.10.20.20”, nonce=“bf272c5f1558befb11675e94def46b72”, response=“b03ac89127dd1fce96bbf3e563ab34b7”
Authentication Scheme: Digest
Username: “68880888”
Realm: “SIP-68889200”
Algorithm: MD5
Authentication URI: “sip:10.10.20.20”
Nonce Value: “bf272c5f1558befb11675e94def46b72”
Digest Authentication Response: “b03ac89127dd1fce96bbf3e563ab34b7”
Expires: 300
Contact: sip:68880888@10.10.10.10:5060
Contact URI: sip:68880888@10.10.10.10:5060
Content-Length: 0

No. Time Source Destination Protocol Length Info
8 2021-09-21 13:37:24.755641 10.10.20.20 10.10.10.10 SIP 472 Status: 401 Unauthorized |

Frame 8: 472 bytes on wire (3776 bits), 472 bytes captured (3776 bits)
Internet Protocol Version 4, Src: 10.10.20.20, Dst: 10.10.10.10
User Datagram Protocol, Src Port: 5060, Dst Port: 5060
Session Initiation Protocol (401)
Status-Line: SIP/2.0 401 Unauthorized
Message Header
Via: SIP/2.0/UDP 10.10.10.10:5060;branch=z9hG4bK700e676b
Call-ID: 76a211b70f1b7cba6cea00b93528dcf5@10.10.10.10
From: sip:68880888@10.10.20.20;tag=as0af0b750
SIP from address: sip:68880888@10.10.20.20
SIP from tag: as0af0b750
To: sip:68880888@10.10.20.20;tag=bngrgl34
SIP to address: sip:68880888@10.10.20.20
SIP to tag: bngrgl34
CSeq: 377 REGISTER
User-Agent: ZTE-SoftSwitch
WWW-Authenticate: Digest realm=“SIP-68889200”,nonce=“5b6847c6f2b05851070a7c10602cce87”,ZTE-ID=694579d9636cb0748c101dfbc203134f
Authentication Scheme: Digest
Realm: “SIP-68889200”
Nonce Value: “5b6847c6f2b05851070a7c10602cce87”
ZTE-ID=694579d9636cb0748c101dfbc203134f
Content-Length: 0

No. Time Source Destination Protocol Length Info
9 2021-09-21 13:37:24.902966 10.10.10.10 10.10.20.20 SIP 634 Request: REGISTER sip:10.10.20.20 (1 binding) |

Frame 9: 634 bytes on wire (5072 bits), 634 bytes captured (5072 bits)
Internet Protocol Version 4, Src: 10.10.10.10, Dst: 10.10.20.20
User Datagram Protocol, Src Port: 5060, Dst Port: 5060
Session Initiation Protocol (REGISTER)
Request-Line: REGISTER sip:10.10.20.20 SIP/2.0
Message Header
Via: SIP/2.0/UDP 10.10.10.10:5060;branch=z9hG4bK5e0d1dec
Max-Forwards: 70
From: sip:68880888@10.10.20.20;tag=as0af0b750
SIP from address: sip:68880888@10.10.20.20
SIP from tag: as0af0b750
To: sip:68880888@10.10.20.20
SIP to address: sip:68880888@10.10.20.20
Call-ID: 76a211b70f1b7cba6cea00b93528dcf5@10.10.10.10
CSeq: 378 REGISTER
Supported: replaces, timer
User-Agent: Telephony
Authorization: Digest username=“68880888”, realm=“SIP-68889200”, algorithm=MD5, uri=“sip:10.10.20.20”, nonce=“5b6847c6f2b05851070a7c10602cce87”, response=“debb78c805d7496603f05d30e88368e1”
Authentication Scheme: Digest
Username: “68880888”
Realm: “SIP-68889200”
Algorithm: MD5
Authentication URI: “sip:10.10.20.20”
Nonce Value: “5b6847c6f2b05851070a7c10602cce87”
Digest Authentication Response: “debb78c805d7496603f05d30e88368e1”
Expires: 300
Contact: sip:68880888@10.10.10.10:5060
Contact URI: sip:68880888@10.10.10.10:5060
Content-Length: 0

No. Time Source Destination Protocol Length Info
10 2021-09-21 13:37:25.422681 10.10.10.10 10.10.20.20 SIP 634 Request: REGISTER sip:10.10.20.20 (1 binding) |

Frame 10: 634 bytes on wire (5072 bits), 634 bytes captured (5072 bits)
Internet Protocol Version 4, Src: 10.10.10.10, Dst: 10.10.20.20
User Datagram Protocol, Src Port: 5060, Dst Port: 5060
Session Initiation Protocol (REGISTER)
Request-Line: REGISTER sip:10.10.20.20 SIP/2.0
Message Header
Via: SIP/2.0/UDP 10.10.10.10:5060;branch=z9hG4bK5e0d1dec
Max-Forwards: 70
From: sip:68880888@10.10.20.20;tag=as0af0b750
SIP from address: sip:68880888@10.10.20.20
SIP from tag: as0af0b750
To: sip:68880888@10.10.20.20
SIP to address: sip:68880888@10.10.20.20
Call-ID: 76a211b70f1b7cba6cea00b93528dcf5@10.10.10.10
CSeq: 378 REGISTER
Supported: replaces, timer
User-Agent: Telephony
Authorization: Digest username=“68880888”, realm=“SIP-68889200”, algorithm=MD5, uri=“sip:10.10.20.20”, nonce=“5b6847c6f2b05851070a7c10602cce87”, response=“debb78c805d7496603f05d30e88368e1”
Authentication Scheme: Digest
Username: “68880888”
Realm: “SIP-68889200”
Algorithm: MD5
Authentication URI: “sip:10.10.20.20”
Nonce Value: “5b6847c6f2b05851070a7c10602cce87”
Digest Authentication Response: “debb78c805d7496603f05d30e88368e1”
Expires: 300
Contact: sip:68880888@10.10.10.10:5060
Contact URI: sip:68880888@10.10.10.10:5060
Content-Length: 0

No. Time Source Destination Protocol Length Info
11 2021-09-21 13:37:25.431774 10.10.20.20 10.10.10.10 SIP 472 Status: 401 Unauthorized |

Frame 11: 472 bytes on wire (3776 bits), 472 bytes captured (3776 bits)
Internet Protocol Version 4, Src: 10.10.20.20, Dst: 10.10.10.10
User Datagram Protocol, Src Port: 5060, Dst Port: 5060
Session Initiation Protocol (401)
Status-Line: SIP/2.0 401 Unauthorized
Message Header
Via: SIP/2.0/UDP 10.10.10.10:5060;branch=z9hG4bK5e0d1dec
Call-ID: 76a211b70f1b7cba6cea00b93528dcf5@10.10.10.10
From: sip:68880888@10.10.20.20;tag=as0af0b750
SIP from address: sip:68880888@10.10.20.20
SIP from tag: as0af0b750
To: sip:68880888@10.10.20.20;tag=m9adgm59
SIP to address: sip:68880888@10.10.20.20
SIP to tag: m9adgm59
CSeq: 378 REGISTER
User-Agent: ZTE-SoftSwitch
WWW-Authenticate: Digest realm=“SIP-68889200”,nonce=“511352bc0988bf25dc3a32a020edf0e0”,ZTE-ID=8abc21ef719f49de422e35bd366acae7
Authentication Scheme: Digest
Realm: “SIP-68889200”
Nonce Value: “511352bc0988bf25dc3a32a020edf0e0”
ZTE-ID=8abc21ef719f49de422e35bd366acae7
Content-Length: 0

No. Time Source Destination Protocol Length Info
12 2021-09-21 13:37:26.474149 10.10.20.20 10.10.10.10 SIP 472 Status: 401 Unauthorized |

Frame 12: 472 bytes on wire (3776 bits), 472 bytes captured (3776 bits)
Internet Protocol Version 4, Src: 10.10.20.20, Dst: 10.10.10.10
User Datagram Protocol, Src Port: 5060, Dst Port: 5060
Session Initiation Protocol (401)
Status-Line: SIP/2.0 401 Unauthorized
Message Header
Via: SIP/2.0/UDP 10.10.10.10:5060;branch=z9hG4bK5e0d1dec
Call-ID: 76a211b70f1b7cba6cea00b93528dcf5@10.10.10.10
From: sip:68880888@10.10.20.20;tag=as0af0b750
SIP from address: sip:68880888@10.10.20.20
SIP from tag: as0af0b750
To: sip:68880888@10.10.20.20;tag=m9adgm59
SIP to address: sip:68880888@10.10.20.20
SIP to tag: m9adgm59
CSeq: 378 REGISTER
User-Agent: ZTE-SoftSwitch
WWW-Authenticate: Digest realm=“SIP-68889200”,nonce=“511352bc0988bf25dc3a32a020edf0e0”,ZTE-ID=8abc21ef719f49de422e35bd366acae7
Authentication Scheme: Digest
Realm: “SIP-68889200”
Nonce Value: “511352bc0988bf25dc3a32a020edf0e0”
ZTE-ID=8abc21ef719f49de422e35bd366acae7
Content-Length: 0

Again that suggests that Asterisk is retransmitting, because it hasn’t seen the 401.

Again, please provide the logging from Asterisk, not from wireshark

They raised an issue[1] for this as well, and I asked for Asterisk logging there too.

[1] https://issues.asterisk.org/jira/browse/ASTERISK-29667

Asterisk_ChanSIP_Nounce_22092021.txt (307.8 KB)

Hai @jcolp @david551

When the issue was raised I don’t have the debug level logs enabled. Presently I have logs which WARNING, ERROR, VERBOSE - Attached is the same. Also, I have a Wireshark trace if required.

I will try to recreate the issue or will enable the debug, sip debug, and Wireshark logs when the issue again arises.

@jcolp - Also confirm should resume the version on this thread or bug thread

The debug logs have to be from when the issue occurred. You also need to pick a place to persue this right now - either the JIRA issue which probably won’t see much activity, or this thread.

I won’t really be responding in regards to the issue because I do not support chan_sip related things.

In that case PJSIP is your friend.I have configured trunks, where the service provider explicitly asked for nonces and long nonce lifetimes and this is working without problems for years.

I don’t understand that. The provider is the one that controls the nonce and its lifetime and, with digest authentication, the client has no choice but to provide the nonce.

If this would be consulting work, I would have to go back to the relevant docs, but in summary and out of memory, the lifetime of a nonce is given by the user and not the provider. PJSIP has the nonce_lifetime parameter. Once expired, I guess Asterisk will not include the next-nonce value in the upcoming REGISTER request, thereby triggering a complete challenge cycle.

In particular I am referring to the 1TR114 doc by the German Telekom. Not all of their VoIP products honor the nonce values, but for me 7200s works fine for their lines (not their trunks). You should be able to download the doc and chapter 4.2.7 is the important one. There’s another place where they ask for large nonce lifetimes in order to reduce the number of complete challenge cycles.

As far as I remember, there used to be a lot of “stale nonce value” messages in the past with chan_sip, which might be related to the current problem. Depending on how a provider’s SIP stack reacts, the problem might be the interaction with the UE. In that case the customer is out of luck, if there is no way to use proper values. But this is mere speculation here as I don’t know the details.

You appear to be talking about RFC 2617 enhancements, which “MUST NOT be specified if the server did not send a qop directive”, and the server did not send such a directive. The nonce you are referring to is actually called cnonce, and is additional to the nonce referred to in this thread.

Indeed, qop=“auth” or something like that is missing here. So we are essentially talking about RFC 2069 here, but didn’t RFC 2617 replace it (Digest access authentication - Wikipedia)?

Yes, but all the new features are optional.