Dear Sir or Madam:
We have our DMG1000 set for SRTP, but not for TLS / SIPS. This is solely for development purposes. We will turn the TLS back on once we get the SRTP working.
We are at the point where we see these messages in the DMG trace log--
041:41.734 [KDR ] Code Key generation for ssrc[0], transformer[0], pkt idx [x-x]041:41.734 [KDR ] Code Cipher key for ssrc[0], transformer[0], 5df003f82487361a8f47f65e4fa6fe48ccafb3e3fa2ab69c07e2ea8a87bc041:41.734 [KDR ] Code Auth key for ssrc[0], transformer[0], ebfd6ded73c38eaece0b041:41.734 [KDR ] Code Key generation for ssrc[0], transformer[1], pkt idx [x-x]041:41.736 [KDR ] Code Cipher key for ssrc[0], transformer[1], b343d1f285f062c683c5e4f44857ec84101bdc946421b2ed80149be76490041:41.736 [KDR ] Code Auth key for ssrc[0], transformer[1], b11aa2179b483ef0e2e1041:41.736 [MKI ] Code Rx Session created for master key index [0=11]041:41.736 [KDR ] Code Key generation for ssrc[0], transformer[0], pkt idx [x-x]041:41.736 [KDR ] Code Cipher key for ssrc[0], transformer[0], 8d6844b0d46b2b13d74410f588c18217bd1fb2fd31ed8b3b693d1b4f7610041:41.738 [KDR ] Code Auth key for ssrc[0], transformer[0], 7c664d3a2d41a1c1aa1b041:41.738 [KDR ] Code Key generation for ssrc[0], transformer[1], pkt idx [x-x]041:41.738 [KDR ] Code Cipher key for ssrc[0], transformer[1], 47602ab176337c4b8793c936644d7c2bd1db67762342231e2f93997e1fe2041:41.738 [KDR ] Code Auth key for ssrc[0], transformer[1], 962ee8a52df4ebf59fbc041:41.740 [MKI ] Code Tx Session created for master key index [0=43]
For both the Tx and Rx, we derive the same values for "Cipher key for ssrc[0], transformer[0]" and "Auth key for ssrc[0], transformer[0]". (Now having written that, RFC 3711 says the length of the authorization key should be 160 bits, not 80 bits...but, that is not the reason for my posting.)
The problem we have is that we see no other errors in the trace log (and all options for the trace log are on). Yet, we cannot hear the SRTP audio being sent from our SIP app to the DMG1000 and then onto the M2616 phone.
We have three more possible clues. First, a Wireshark made on the DMG1000 shows that the DMG1000 is not sending any SRTP or RTP packets to our SIP app. But, we can see that SRTP packets we are sending from the SIP app to the DMG1000 did arrive at the DMG1000.
Second, we can cause constant errors to appear in the trace log if we send SRTP packets where we cause the app to send an erroneous MKI value!! That means the DMG1000 firmware is receiving and processing our SRTP packets. BTW, sending an erroneous authorization tag seems to not generate any messages in the trace log.
Third, the SIP call is not rejected. But, with the other clues I've stated above, that should be obvious.
Do you have any recommendations for how to set the trace log or any other setting in the DMG1000 so that we can further troubleshoot this problem? I have attached a screen print of our settings.
Thank you!
What build of DMG firmware are you running? Some quick things you can try...first, the DMG100x only does 30ms frames when using SRTP. So try setting that to 30ms frames and retest (however you will also have to make the same changes on the application as far as frame size is concerned).
Other things you can try:
; MKI on Transmit Stream: Yes No srtpTxMkiEnable = No
; Authentication Tag Length: SHA1_32_bit SHA1_80_bit srtpAuthTag = SHA1_32_bit
; UnEncrypted SRTP Enable: Yes No srtpUnEncryptedSRTP = No
MKI on transmit and auth tag length are configurable via the web...however depending on the build you have, UnEncrypted SRTP Enable may only be a config.ini only parameter. So you would have to export the config file, make the change (set it to NO), and import the config file back into the DMG.
Hope this helps.
OK, we went to 30ms G.711 packets. The audio from our SIP client to the TDM phone now works. Thanks!
But, looking at the Wireshark from the DMG1000 shows that the DMG1000 still isn't sending any audio packets back to the SIP client.
We can't spot any errors in the trace log. Just to make sure we were not missing anything, we searched the trace log for "err" and all we found was this tag eGCC_ERROR_SUCCESS and "Error Stats:".
Here is the version information--
; ***************** Dialogic Media Gateway *****************; Version Information:; 00-a0-e6-89-99-0d 192.168.1.7; Gateway Application (ROM): |6.0.SU4.0.012| |TUE JUL 28 21:08:15 2009| ; Gateway Application: |6.0.SU4.0.012| |TUE JUL 28 21:08:15 2009| ; Main Board Boot (ROM): |6.0.SU4.0.012| |TUE JUL 28 20:55:43 2009| ; DSP Firmware (ROM): |9.1 w/Fax| |FRI MAY 20 16:38:20 2005| ; DSP Firmware: |9.1 w/Fax| |FRI MAY 20 16:38:20 2005| ; Telephony Interface Application: 6.53; Telephony Interface Firmware: Platform 3 Build 190; Telephony Interface Boot: 6.0; Telephony Interface ID: 2-Wire (0x0); Adept Config: Default; *****************************************************************
Try posting the traces for review....same trace masks as before please. Also attach the wireshark trace. Make sure that you uncheck RTP before running the wireshark trace. Otherwise, you will not see RTP packets. If you have a per unit plan or HAMG contract, it may be best at this point to exercise your support contract and get a case entered with Dialogic directly.
I have posted the trace log, the Wireshark, and the Config.ini files. The SIP client is 192.168.1.112 (phone number 5400) and the DMG1000 is 192.168.1.7. The M2616's phone number is 6781.
As the Wireshark will indicate, we could hear SRTP audio with no problems that was moving from the SIP client to the DMG1000 and onto an M2616.
