SRTP example does not seem to work

[wdoekes]

@jeannotlanglois.

I'm testing the SRTP example like this:

../sipp -m 1 -sf ../sipp_scenarios/pfca_uas_both_crypto_simple.xml \
  -t u1 -mp 4000 -i 127.0.0.3 -p 5060 -srtpcheck_debug -trace_msg

../sipp -m 1 -sf ../sipp_scenarios/pfca_uac_bpattern_crypto_simple.xml \
  -t u1 -mp 5000 -i 127.0.0.2 -p 5060 -srtpcheck_debug 127.0.0.3:5060

And I'm getting a 253 exit code in the UAC (= FAILED rtp validation).

I've tried your commit b2f7d2acf216399f8cf563b5672ae15b78c21ded, to see if I broke it somewhere, but that fails in exactly the same manner as latest.

(This patch is done against your commit, or the UAS scenario fails on SIP messages.)

diff --git a/sipp_scenarios/pfca_uas_both_crypto_simple.xml b/sipp_scenarios/pfca_uas_both_crypto_simple.xml
index 5efb5ea..9dafac5 100644
--- a/sipp_scenarios/pfca_uas_both_crypto_simple.xml
+++ b/sipp_scenarios/pfca_uas_both_crypto_simple.xml
@@ -100,6 +100,9 @@
     ]]>
   </send>

+  <recv request="ACK">
+  </recv>
+
   <nop>
     <action>
         <exec rtp_echo="startaudio,0,PCMU/8000" />
@@ -107,9 +110,6 @@
     </action>
   </nop>

-  <recv request="ACK">
-  </recv>
-
   <nop>
     <action>
         <exec rtp_echo="updateaudio,0,PCMU/8000" />
@@ -119,7 +119,7 @@

   <recv request="BYE">
   </recv>
-  
+
   <send>
     <![CDATA[
       SIP/2.0 200 OK

Can you look into this?

[jeannotlanglois]

Hmmm... there might be an error in my sample command lines (the "-rtpcheck_debug" parameter is missing in both commandlines); also not sure if it matters but I always have the IP:port parameter of the UAC command line listed first - can you to see if the following works instead:

../sipp -m 1 -sf ../sipp_scenarios/pfca_uas_both_crypto_simple.xml -t u1 -mp 4000 -i 127.0.0.3 -p 5060 -rtcheck_debug -srtpcheck_debug -trace_msg

../sipp 127.0.0.3:5060 -m 1 -sf ../sipp_scenarios/pfca_uac_bpattern_crypto_simple.xml -t u1 -mp 5000 -i 127.0.0.2 -p 5060 -rtpcheck_debug -srtpcheck_debug

If that still fails please re-run the testcase one more time while simultaneously capturing a wireshark (e.g. tcpdump) trace that contains both the SIP signalling and the [S]RTP packets so that I can correlate a few things to see what is wrong.

Thanks!

-- Jeannot Langlois Software Developer SIP Inspector RFC Lawyer Refactoring Expert MiVoice Border Gateway Development Mitel Networks 4000 Innovation Drive Kanata (Ontario) K2K 3K1 http://www.mitel.comhttp://www.mitel.com/ @.**@.> x444364 (613) 691-3385 [Direct Dial]

"Never give in, never give in, never, never, never, never. In nothing, great or small, large or petty. Never give in except to convictions of honor and good sense."

• Winston Churchill

"Can I get an update on issue X? Did you fix issue X in stream Y?" [https://mitel.atlassian.net/issues/?filter=17325]

"When is MBG version X planned for GA? Will it include fix Y?" [https://mitel.atlassian.net/wiki/spaces/MBG/pages/5588287492/Project+Dashboard]

From: Walter Doekes @.> Sent: Wednesday, October 27, 2021 3:54 AM To: SIPp/sipp @.> Cc: Jeannot Langlois @.>; Mention @.> Subject: [SIPp/sipp] SRTP example does not seem to work (Issue #544)

@jeannotlangloishttps://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fjeannotlanglois&data=04%7C01%7Cjeannot.langlois%40mitel.com%7C2ed74bdd9f544781bb7808d9991ef891%7C4bff5a2bb30d493981ff8f76138347df%7C1%7C0%7C637709180585378906%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=y%2B4vSFtLW9rfLaeqvrzzlabfT8dVsZYRf2A%2F9XVIh%2Bs%3D&reserved=0.

I'm testing the SRTP example like this:

../sipp -m 1 -sf ../sipp_scenarios/pfca_uas_both_crypto_simple.xml \

-t u1 -mp 4000 -i 127.0.0.3 -p 5060 -srtpcheck_debug -trace_msg

../sipp -m 1 -sf ../sipp_scenarios/pfca_uac_bpattern_crypto_simple.xml \

-t u1 -mp 5000 -i 127.0.0.2 -p 5060 -srtpcheck_debug 127.0.0.3:5060

And I'm getting a 253 exit code in the UAC (= FAILED rtp validation).

I've tried your commit b2f7d2ahttps://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FSIPp%2Fsipp%2Fcommit%2Fb2f7d2acf216399f8cf563b5672ae15b78c21ded&data=04%7C01%7Cjeannot.langlois%40mitel.com%7C2ed74bdd9f544781bb7808d9991ef891%7C4bff5a2bb30d493981ff8f76138347df%7C1%7C0%7C637709180585378906%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=7eRWB0UfAl2mPWjZQZYEgB1wkHURoh8CbyKPO%2BaV6AY%3D&reserved=0, to see if I broke it somewhere, but that fails in exactly the same manner as latest.

(This patch is done against your commit, or the UAS scenario fails on SIP messages.)

diff --git a/sipp_scenarios/pfca_uas_both_crypto_simple.xml b/sipp_scenarios/pfca_uas_both_crypto_simple.xml

index 5efb5ea..9dafac5 100644

--- a/sipp_scenarios/pfca_uas_both_crypto_simple.xml

+++ b/sipp_scenarios/pfca_uas_both_crypto_simple.xml

@@ -100,6 +100,9 @@

 ]]>

@@ -107,9 +110,6 @@

 </action>

@@ -119,7 +119,7 @@

-

+

, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. ________________________________ NOTE: This e-mail (including any attachments) is for the sole use of the intended recipient(s) and may contain information that is confidential and/or protected by legal privilege. Any unauthorized review, use, copy, disclosure or distribution of this e-mail is strictly prohibited. If you are not the intended recipient, please notify Mitel immediately and destroy all copies of this e-mail. Mitel does not accept any liability for breach of security, error or virus that may result from the transmission of this message.

[wdoekes]

Okay. I ran this on SIPp v3.7.0_rc1-3-gd76b1c0-TLS-SCTP-PCAP. That is: d76b1c0405b9d052073dc8c1658ebb7f02bff5ae

../sipp -m 1 -sf ../sipp_scenarios/pfca_uas_both_crypto_simple.xml \
  -t u1 -i 127.0.0.3 -p 5060 -min_rtp_port 4000 \
  -rtpcheck_debug -srtpcheck_debug

I removed -mp in favor of -min_rtp_port since that's how you're using it. Omitting it would've worked fine too, but now the ports are better visible:

Run the UAC:

../sipp -m 1 -sf ../sipp_scenarios/pfca_uac_bpattern_crypto_simple.xml \
  -t u1 -i 127.0.0.2 -p 5060 -min_rtp_port 5000 \
  -rtpcheck_debug -srtpcheck_debug 127.0.0.3:5060

Results for SIP:

$ sipzamine srtp-pfca-544-1.pcap
[ 1-2851810@127.0.0.2 ]
2021-10-28 09:03:37.869669 127.0.0.2:5060 > 127.0.0.3:5060 10 INVITE
2021-10-28 09:03:37.870179 127.0.0.3:5060 > 127.0.0.2:5060 10 INVITE(180)
2021-10-28 09:03:37.870455 127.0.0.3:5060 > 127.0.0.2:5060 11 PRACK(200)
2021-10-28 09:03:37.871995 127.0.0.3:5060 > 127.0.0.2:5060 10 INVITE(200)
2021-10-28 09:03:37.872273 127.0.0.2:5060 > 127.0.0.3:5060 10 ACK
2021-10-28 09:03:39.876144 127.0.0.2:5060 > 127.0.0.3:5060 12 BYE
2021-10-28 09:03:39.876256 127.0.0.3:5060 > 127.0.0.2:5060 12 BYE(200)

UAC to UAS (two ports, as expected, one for audio and one for video):

$ tcpdump -nnr srtp-pfca-544-1.pcap src host 127.0.0.2 and not port 5060
09:03:37.971656 IP 127.0.0.2.5000 > 127.0.0.3.4000: UDP, length 182
09:03:37.971775 IP 127.0.0.2.5002 > 127.0.0.3.4002: UDP, length 1302
09:03:38.087327 IP 127.0.0.2.5000 > 127.0.0.3.4000: UDP, length 182
09:03:38.247794 IP 127.0.0.2.5000 > 127.0.0.3.4000: UDP, length 182
09:03:38.247904 IP 127.0.0.2.5002 > 127.0.0.3.4002: UDP, length 1302
...

UAS to UAC:

$ tcpdump -nnr srtp-pfca-544-1.pcap src host 127.0.0.3 and not port 5060
09:03:37.971700 IP 127.0.0.3.4000 > 127.0.0.2.5000: UDP, length 182
09:03:37.971837 IP 127.0.0.3.4002 > 127.0.0.2.5002: UDP, length 1302
09:03:38.087358 IP 127.0.0.3.4000 > 127.0.0.2.5000: UDP, length 182
09:03:38.247821 IP 127.0.0.3.4000 > 127.0.0.2.5000: UDP, length 182
09:03:38.247964 IP 127.0.0.3.4002 > 127.0.0.2.5002: UDP, length 1302
...

PCAP and debug logs attached. This should be fully reproducible.

srtp-pfca-544-1.pcap.gz srtp-pfca-544-1-uac.zip srtp-pfca-544-1-uas.zip

Observe how the UAC says FAILED for the audio and passed for the video:

$ grep -E 'FAILED|PASSED' uac/debug?file 
debugafile:TID: 140659690628864 COMPARISON FAILED 0 0x1 1 []
debugafile:TID: 140659690628864 ----FAILED RTP CHECK---- 0 0x1 1 []
debugafile:TID: 140659690628864 COMPARISON FAILED 0 0x2 2 []
debugafile:TID: 140659690628864 ----FAILED RTP CHECK---- 0 0x2 2 []
...
debugvfile:TID: 140659690628864 ----PASSED RTP CHECK---- 0 0x0 1 []
debugvfile:TID: 140659690628864 ----PASSED RTP CHECK---- 0 0x0 1 []
...

[jeannotlanglois]

Hello:

I just got back to work this morning - I'm planning to go over your emails on Tuesday this week. Hopefully this is something easily fixed once I figure it out.

-- Jeannot Langlois Software Developer SIP Inspector RFC Lawyer Refactoring Expert MiVoice Border Gateway Development Mitel Networks 4000 Innovation Drive Kanata (Ontario) K2K 3K1 http://www.mitel.comhttp://www.mitel.com/ @.**@.> x444364 (613) 691-3385 [Direct Dial]

"Never give in, never give in, never, never, never, never. In nothing, great or small, large or petty. Never give in except to convictions of honor and good sense."

• Winston Churchill

"Can I get an update on issue X? Did you fix issue X in stream Y?" [https://mitel.atlassian.net/issues/?filter=17325]

"When is MBG version X planned for GA? Will it include fix Y?" [https://mitel.atlassian.net/wiki/spaces/MBG/pages/5588287492/Project+Dashboard]

From: Walter Doekes @.> Sent: Thursday, October 28, 2021 3:16 AM To: SIPp/sipp @.> Cc: Jeannot Langlois @.>; Mention @.> Subject: Re: [SIPp/sipp] SRTP example does not seem to work (Issue #544)

Okay. I ran this on SIPp v3.7.0_rc1-3-gd76b1c0-TLS-SCTP-PCAP. That is: d76b1c0https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FSIPp%2Fsipp%2Fcommit%2Fd76b1c0405b9d052073dc8c1658ebb7f02bff5ae&data=04%7C01%7Cjeannot.langlois%40mitel.com%7C97e2211bec40455a90ad08d999e2bb46%7C4bff5a2bb30d493981ff8f76138347df%7C1%7C0%7C637710023103410145%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=UAnYtxaTR52%2FVtUdrU%2BI31cNC7Cqa1st%2B8pTTAM%2Bc08%3D&reserved=0

../sipp -m 1 -sf ../sipp_scenarios/pfca_uas_both_crypto_simple.xml \

-t u1 -i 127.0.0.3 -p 5060 -min_rtp_port 4000 \

-rtpcheck_debug -srtpcheck_debug

I removed -mp in favor of -min_rtp_port since that's how you're using it. Omitting it would've worked fine too, but now the ports are better visible:

Run the UAC:

../sipp -m 1 -sf ../sipp_scenarios/pfca_uac_bpattern_crypto_simple.xml \

-t u1 -i 127.0.0.2 -p 5060 -min_rtp_port 5000 \

-rtpcheck_debug -srtpcheck_debug 127.0.0.3:5060

Results for SIP:

$ sipzamine srtp-pfca-544-1.pcap

[ @.*** ]

2021-10-28 09:03:37.869669 127.0.0.2:5060 > 127.0.0.3:5060 10 INVITE

2021-10-28 09:03:37.870179 127.0.0.3:5060 > 127.0.0.2:5060 10 INVITE(180)

2021-10-28 09:03:37.870455 127.0.0.3:5060 > 127.0.0.2:5060 11 PRACK(200)

2021-10-28 09:03:37.871995 127.0.0.3:5060 > 127.0.0.2:5060 10 INVITE(200)

2021-10-28 09:03:37.872273 127.0.0.2:5060 > 127.0.0.3:5060 10 ACK

2021-10-28 09:03:39.876144 127.0.0.2:5060 > 127.0.0.3:5060 12 BYE

2021-10-28 09:03:39.876256 127.0.0.3:5060 > 127.0.0.2:5060 12 BYE(200)

UAC to UAS (two ports, as expected, one for audio and one for video):

$ tcpdump -nnr srtp-pfca-544-1.pcap src host 127.0.0.2 and not port 5060

09:03:37.971656 IP 127.0.0.2.5000 > 127.0.0.3.4000: UDP, length 182

09:03:37.971775 IP 127.0.0.2.5002 > 127.0.0.3.4002: UDP, length 1302

09:03:38.087327 IP 127.0.0.2.5000 > 127.0.0.3.4000: UDP, length 182

09:03:38.247794 IP 127.0.0.2.5000 > 127.0.0.3.4000: UDP, length 182

09:03:38.247904 IP 127.0.0.2.5002 > 127.0.0.3.4002: UDP, length 1302

...

UAS to UAC:

$ tcpdump -nnr srtp-pfca-544-1.pcap src host 127.0.0.3 and not port 5060

09:03:37.971700 IP 127.0.0.3.4000 > 127.0.0.2.5000: UDP, length 182

09:03:37.971837 IP 127.0.0.3.4002 > 127.0.0.2.5002: UDP, length 1302

09:03:38.087358 IP 127.0.0.3.4000 > 127.0.0.2.5000: UDP, length 182

09:03:38.247821 IP 127.0.0.3.4000 > 127.0.0.2.5000: UDP, length 182

09:03:38.247964 IP 127.0.0.3.4002 > 127.0.0.2.5002: UDP, length 1302

...

PCAP and debug logs attached. This should be fully reproducible.

srtp-pfca-544-1.pcap.gzhttps://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FSIPp%2Fsipp%2Ffiles%2F7431959%2Fsrtp-pfca-544-1.pcap.gz&data=04%7C01%7Cjeannot.langlois%40mitel.com%7C97e2211bec40455a90ad08d999e2bb46%7C4bff5a2bb30d493981ff8f76138347df%7C1%7C0%7C637710023103420139%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=oozeUbDkicgT6Cdi%2ByLpzDA3b6curDXqFf19ER6Wmbc%3D&reserved=0 srtp-pfca-544-1-uac.ziphttps://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FSIPp%2Fsipp%2Ffiles%2F7431968%2Fsrtp-pfca-544-1-uac.zip&data=04%7C01%7Cjeannot.langlois%40mitel.com%7C97e2211bec40455a90ad08d999e2bb46%7C4bff5a2bb30d493981ff8f76138347df%7C1%7C0%7C637710023103420139%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=0SVgiF%2Bs4W%2Fn1Lmi5DlNPlgKpxIy%2BSTivKFabwoqD0U%3D&reserved=0 srtp-pfca-544-1-uas.ziphttps://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FSIPp%2Fsipp%2Ffiles%2F7431969%2Fsrtp-pfca-544-1-uas.zip&data=04%7C01%7Cjeannot.langlois%40mitel.com%7C97e2211bec40455a90ad08d999e2bb46%7C4bff5a2bb30d493981ff8f76138347df%7C1%7C0%7C637710023103430135%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=EhhZWZHiafhEJGnkKs8UcQaX0JVxsYJItJeuzfnqUB8%3D&reserved=0

Observe how the UAC says FAILED for the audio and passed for the video:

$ grep -E 'FAILED|PASSED' uac/debug?file

debugafile:TID: 140659690628864 COMPARISON FAILED 0 0x1 1 []

debugafile:TID: 140659690628864 ----FAILED RTP CHECK---- 0 0x1 1 []

debugafile:TID: 140659690628864 COMPARISON FAILED 0 0x2 2 []

debugafile:TID: 140659690628864 ----FAILED RTP CHECK---- 0 0x2 2 []

...

debugvfile:TID: 140659690628864 ----PASSED RTP CHECK---- 0 0x0 1 []

debugvfile:TID: 140659690628864 ----PASSED RTP CHECK---- 0 0x0 1 []

...

- You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FSIPp%2Fsipp%2Fissues%2F544%23issuecomment-953566486&data=04%7C01%7Cjeannot.langlois%40mitel.com%7C97e2211bec40455a90ad08d999e2bb46%7C4bff5a2bb30d493981ff8f76138347df%7C1%7C0%7C637710023103430135%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=8FkYINmiH8SJlxhy8a%2B%2FpIXT26aqjhORz8N23Eze%2Bfs%3D&reserved=0, or unsubscribehttps://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAJK3K5MW5OMRUUY4OEWYYE3UJEBCJANCNFSM5GZU2PJA&data=04%7C01%7Cjeannot.langlois%40mitel.com%7C97e2211bec40455a90ad08d999e2bb46%7C4bff5a2bb30d493981ff8f76138347df%7C1%7C0%7C637710023103440129%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=5vBOvufPwecHigQvM8pC0j4YuFNkbAad8EXpRjK5lqU%3D&reserved=0. Triage notifications on the go with GitHub Mobile for iOShttps://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapps.apple.com%2Fapp%2Fapple-store%2Fid1477376905%3Fct%3Dnotification-email%26mt%3D8%26pt%3D524675&data=04%7C01%7Cjeannot.langlois%40mitel.com%7C97e2211bec40455a90ad08d999e2bb46%7C4bff5a2bb30d493981ff8f76138347df%7C1%7C0%7C637710023103440129%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=%2BWFhhqr4pLqm7X5CdwDTRLJc%2F5hAI%2BDlsSBfd9LBFK4%3D&reserved=0 or Androidhttps://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fplay.google.com%2Fstore%2Fapps%2Fdetails%3Fid%3Dcom.github.android%26referrer%3Dutm_campaign%253Dnotification-email%2526utm_medium%253Demail%2526utm_source%253Dgithub&data=04%7C01%7Cjeannot.langlois%40mitel.com%7C97e2211bec40455a90ad08d999e2bb46%7C4bff5a2bb30d493981ff8f76138347df%7C1%7C0%7C637710023103450122%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=4yyXvGRsIjAQowcGWotKLcqgxDm4xbRsIbmjAM9ol60%3D&reserved=0.

---

NOTE: This e-mail (including any attachments) is for the sole use of the intended recipient(s) and may contain information that is confidential and/or protected by legal privilege. Any unauthorized review, use, copy, disclosure or distribution of this e-mail is strictly prohibited. If you are not the intended recipient, please notify Mitel immediately and destroy all copies of this e-mail. Mitel does not accept any liability for breach of security, error or virus that may result from the transmission of this message.

[jeannotlanglois]

Hi Walter:

Thanks a lot for providing both the WireShark trace + debug logs - that is exactly what I needed.

I've started investigating this problem tonight. I have some doubts about a possible recent SRTP echo problem I've fixed recently but which I thought was non-critical for now I was was thinking of waiting until after the 3.7 release to submit it to avoid any confusion. But I'm not sure yet if this is what you're seeing or something else.

I'd like to dig deeper to confirm.

I certainly see something fishy in the AUDIO SRTP echoed back from the UAS (127.0.0.3) - it appears to be nearly-empty RTP packets so there is something that appears incorrect on the UAS AUDIO SRTP echo side.

• Before I try to set myself up to reproduce what you are seeing, would you mind doing two similar extra tests?

• I do see you are running the "bpattern" testcase ("b" for "both audio+video").

• Can you separately try the same test (while still capturing both a WireShark trace + the debug logs) but instead of using the "bpattern" (audiovideo testcase), rather try two separate tests with with:

a) the "apattern" (audioonly testcase)

and

b) the "vpattern" (videoonly testcase)?

=> I'd like to see if you are seeing a different behavior with those separate testcases compared to the "bpattern" testcase. => That would help narrow things down a little bit.

Thanks!

-- Jeannot Langlois Software Developer SIP Inspector RFC Lawyer Refactoring Expert MiVoice Border Gateway Development Mitel Networks 4000 Innovation Drive Kanata (Ontario) K2K 3K1 http://www.mitel.comhttp://www.mitel.com/ @.**@.> x444364 (613) 691-3385 [Direct Dial]

"Never give in, never give in, never, never, never, never. In nothing, great or small, large or petty. Never give in except to convictions of honor and good sense."

• Winston Churchill

"Can I get an update on issue X? Did you fix issue X in stream Y?" [https://mitel.atlassian.net/issues/?filter=17325]

"When is MBG version X planned for GA? Will it include fix Y?" [https://mitel.atlassian.net/wiki/spaces/MBG/pages/5588287492/Project+Dashboard]

From: Walter Doekes @.> Sent: Thursday, October 28, 2021 3:16 AM To: SIPp/sipp @.> Cc: Jeannot Langlois @.>; Mention @.> Subject: Re: [SIPp/sipp] SRTP example does not seem to work (Issue #544)

Okay. I ran this on SIPp v3.7.0_rc1-3-gd76b1c0-TLS-SCTP-PCAP. That is: d76b1c0https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FSIPp%2Fsipp%2Fcommit%2Fd76b1c0405b9d052073dc8c1658ebb7f02bff5ae&data=04%7C01%7Cjeannot.langlois%40mitel.com%7C97e2211bec40455a90ad08d999e2bb46%7C4bff5a2bb30d493981ff8f76138347df%7C1%7C0%7C637710023103410145%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=UAnYtxaTR52%2FVtUdrU%2BI31cNC7Cqa1st%2B8pTTAM%2Bc08%3D&reserved=0

../sipp -m 1 -sf ../sipp_scenarios/pfca_uas_both_crypto_simple.xml \

-t u1 -i 127.0.0.3 -p 5060 -min_rtp_port 4000 \

-rtpcheck_debug -srtpcheck_debug

I removed -mp in favor of -min_rtp_port since that's how you're using it. Omitting it would've worked fine too, but now the ports are better visible:

Run the UAC:

../sipp -m 1 -sf ../sipp_scenarios/pfca_uac_bpattern_crypto_simple.xml \

-t u1 -i 127.0.0.2 -p 5060 -min_rtp_port 5000 \

-rtpcheck_debug -srtpcheck_debug 127.0.0.3:5060

Results for SIP:

$ sipzamine srtp-pfca-544-1.pcap

[ @.*** ]

2021-10-28 09:03:37.869669 127.0.0.2:5060 > 127.0.0.3:5060 10 INVITE

2021-10-28 09:03:37.870179 127.0.0.3:5060 > 127.0.0.2:5060 10 INVITE(180)

2021-10-28 09:03:37.870455 127.0.0.3:5060 > 127.0.0.2:5060 11 PRACK(200)

2021-10-28 09:03:37.871995 127.0.0.3:5060 > 127.0.0.2:5060 10 INVITE(200)

2021-10-28 09:03:37.872273 127.0.0.2:5060 > 127.0.0.3:5060 10 ACK

2021-10-28 09:03:39.876144 127.0.0.2:5060 > 127.0.0.3:5060 12 BYE

2021-10-28 09:03:39.876256 127.0.0.3:5060 > 127.0.0.2:5060 12 BYE(200)

UAC to UAS (two ports, as expected, one for audio and one for video):

$ tcpdump -nnr srtp-pfca-544-1.pcap src host 127.0.0.2 and not port 5060

09:03:37.971656 IP 127.0.0.2.5000 > 127.0.0.3.4000: UDP, length 182

09:03:37.971775 IP 127.0.0.2.5002 > 127.0.0.3.4002: UDP, length 1302

09:03:38.087327 IP 127.0.0.2.5000 > 127.0.0.3.4000: UDP, length 182

09:03:38.247794 IP 127.0.0.2.5000 > 127.0.0.3.4000: UDP, length 182

09:03:38.247904 IP 127.0.0.2.5002 > 127.0.0.3.4002: UDP, length 1302

...

UAS to UAC:

$ tcpdump -nnr srtp-pfca-544-1.pcap src host 127.0.0.3 and not port 5060

09:03:37.971700 IP 127.0.0.3.4000 > 127.0.0.2.5000: UDP, length 182

09:03:37.971837 IP 127.0.0.3.4002 > 127.0.0.2.5002: UDP, length 1302

09:03:38.087358 IP 127.0.0.3.4000 > 127.0.0.2.5000: UDP, length 182

09:03:38.247821 IP 127.0.0.3.4000 > 127.0.0.2.5000: UDP, length 182

09:03:38.247964 IP 127.0.0.3.4002 > 127.0.0.2.5002: UDP, length 1302

...

PCAP and debug logs attached. This should be fully reproducible.

srtp-pfca-544-1.pcap.gzhttps://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FSIPp%2Fsipp%2Ffiles%2F7431959%2Fsrtp-pfca-544-1.pcap.gz&data=04%7C01%7Cjeannot.langlois%40mitel.com%7C97e2211bec40455a90ad08d999e2bb46%7C4bff5a2bb30d493981ff8f76138347df%7C1%7C0%7C637710023103420139%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=oozeUbDkicgT6Cdi%2ByLpzDA3b6curDXqFf19ER6Wmbc%3D&reserved=0 srtp-pfca-544-1-uac.ziphttps://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FSIPp%2Fsipp%2Ffiles%2F7431968%2Fsrtp-pfca-544-1-uac.zip&data=04%7C01%7Cjeannot.langlois%40mitel.com%7C97e2211bec40455a90ad08d999e2bb46%7C4bff5a2bb30d493981ff8f76138347df%7C1%7C0%7C637710023103420139%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=0SVgiF%2Bs4W%2Fn1Lmi5DlNPlgKpxIy%2BSTivKFabwoqD0U%3D&reserved=0 srtp-pfca-544-1-uas.ziphttps://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FSIPp%2Fsipp%2Ffiles%2F7431969%2Fsrtp-pfca-544-1-uas.zip&data=04%7C01%7Cjeannot.langlois%40mitel.com%7C97e2211bec40455a90ad08d999e2bb46%7C4bff5a2bb30d493981ff8f76138347df%7C1%7C0%7C637710023103430135%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=EhhZWZHiafhEJGnkKs8UcQaX0JVxsYJItJeuzfnqUB8%3D&reserved=0

Observe how the UAC says FAILED for the audio and passed for the video:

$ grep -E 'FAILED|PASSED' uac/debug?file

debugafile:TID: 140659690628864 COMPARISON FAILED 0 0x1 1 []

debugafile:TID: 140659690628864 ----FAILED RTP CHECK---- 0 0x1 1 []

debugafile:TID: 140659690628864 COMPARISON FAILED 0 0x2 2 []

debugafile:TID: 140659690628864 ----FAILED RTP CHECK---- 0 0x2 2 []

...

debugvfile:TID: 140659690628864 ----PASSED RTP CHECK---- 0 0x0 1 []

debugvfile:TID: 140659690628864 ----PASSED RTP CHECK---- 0 0x0 1 []

...

- You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FSIPp%2Fsipp%2Fissues%2F544%23issuecomment-953566486&data=04%7C01%7Cjeannot.langlois%40mitel.com%7C97e2211bec40455a90ad08d999e2bb46%7C4bff5a2bb30d493981ff8f76138347df%7C1%7C0%7C637710023103430135%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=8FkYINmiH8SJlxhy8a%2B%2FpIXT26aqjhORz8N23Eze%2Bfs%3D&reserved=0, or unsubscribehttps://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAJK3K5MW5OMRUUY4OEWYYE3UJEBCJANCNFSM5GZU2PJA&data=04%7C01%7Cjeannot.langlois%40mitel.com%7C97e2211bec40455a90ad08d999e2bb46%7C4bff5a2bb30d493981ff8f76138347df%7C1%7C0%7C637710023103440129%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=5vBOvufPwecHigQvM8pC0j4YuFNkbAad8EXpRjK5lqU%3D&reserved=0. Triage notifications on the go with GitHub Mobile for iOShttps://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapps.apple.com%2Fapp%2Fapple-store%2Fid1477376905%3Fct%3Dnotification-email%26mt%3D8%26pt%3D524675&data=04%7C01%7Cjeannot.langlois%40mitel.com%7C97e2211bec40455a90ad08d999e2bb46%7C4bff5a2bb30d493981ff8f76138347df%7C1%7C0%7C637710023103440129%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=%2BWFhhqr4pLqm7X5CdwDTRLJc%2F5hAI%2BDlsSBfd9LBFK4%3D&reserved=0 or Androidhttps://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fplay.google.com%2Fstore%2Fapps%2Fdetails%3Fid%3Dcom.github.android%26referrer%3Dutm_campaign%253Dnotification-email%2526utm_medium%253Demail%2526utm_source%253Dgithub&data=04%7C01%7Cjeannot.langlois%40mitel.com%7C97e2211bec40455a90ad08d999e2bb46%7C4bff5a2bb30d493981ff8f76138347df%7C1%7C0%7C637710023103450122%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=4yyXvGRsIjAQowcGWotKLcqgxDm4xbRsIbmjAM9ol60%3D&reserved=0.

---

NOTE: This e-mail (including any attachments) is for the sole use of the intended recipient(s) and may contain information that is confidential and/or protected by legal privilege. Any unauthorized review, use, copy, disclosure or distribution of this e-mail is strictly prohibited. If you are not the intended recipient, please notify Mitel immediately and destroy all copies of this e-mail. Mitel does not accept any liability for breach of security, error or virus that may result from the transmission of this message.

[wdoekes]

vpattern is happy (exit 0), apattern is not (exit 253, as above).

tcpdump -nnilo host 127.0.0.2 or host 127.0.0.3 -s0 -w apattern.pcap -vv

../sipp -m 1 -sf ../sipp_scenarios/pfca_uas_both_crypto_simple.xml \
  -t u1 -i 127.0.0.3 -p 5060 -min_rtp_port 4000 \
  -rtpcheck_debug -srtpcheck_debug

../sipp -m 1 -sf ../sipp_scenarios/pfca_uac_apattern_crypto_simple.xml \
  -t u1 -i 127.0.0.2 -p 5060 -min_rtp_port 5000 \
  -rtpcheck_debug -srtpcheck_debug 127.0.0.3:5060

544-apattern.pcap.zip 544-apattern-uac.zip 544-apattern-uas.zip

tcpdump -nnilo host 127.0.0.2 or host 127.0.0.3 -s0 -w vpattern.pcap -vv

../sipp -m 1 -sf ../sipp_scenarios/pfca_uas_both_crypto_simple.xml \
  -t u1 -i 127.0.0.3 -p 5060 -min_rtp_port 4000 \
  -rtpcheck_debug -srtpcheck_debug

../sipp -m 1 -sf ../sipp_scenarios/pfca_uac_vpattern_crypto_simple.xml \
  -t u1 -i 127.0.0.2 -p 5060 -min_rtp_port 5000 \
  -rtpcheck_debug -srtpcheck_debug 127.0.0.3:5060

544-vpattern.pcap.zip 544-vpattern-uac.zip 544-vpattern-uas.zip

The following strikes me as odd:

$ tcpdump -nnr srtp-pfca-544-1.pcap  src port 4000 | wc -l
13
$ tcpdump -nnr srtp-pfca-544-1.pcap  src port 4002 | wc -l
12

One more for audio originally? Not very hi res perhaps.

$ tcpdump -nnr apattern.pcap  src port 4000 | wc -l
95
$ tcpdump -nnr apattern.pcap  src port 4002 | wc -l
0

95 audio packets? Not 12 or 13?

$ tcpdump -nnr vpattern.pcap  src port 4000 | wc -l
0
$ tcpdump -nnr vpattern.pcap  src port 4002 | wc -l
12

That last one seems okay.

[jeannotlanglois]

The following strikes me as odd:

$ tcpdump -nnr srtp-pfca-544-1.pcap src port 4000 | wc -l 13 $ tcpdump -nnr srtp-pfca-544-1.pcap src port 4002 | wc -l 12

One more for audio originally? Not very hi res perhaps.

$ tcpdump -nnr apattern.pcap src port 4000 | wc -l 95 $ tcpdump -nnr apattern.pcap src port 4002 | wc -l 0

95 audio packets? Not 12 or 13?

$ tcpdump -nnr vpattern.pcap src port 4000 | wc -l 0 $ tcpdump -nnr vpattern.pcap src port 4002 | wc -l 12

That last one seems okay.

The discrepancies in the AUDIO vs VIDEO packet counts is perfectly normal - all these tests (bpattern, apattern, vpattern) are time-based and last the same amount of time. But the [S]RTP payload sizes have different sizes depending on which media is being simulated (e.g. the AUDIO [S]RTP packets have a much smaller payload size than the VIDEO [S]RTP packets therefore in the same amount of time elapsed many more AUDIO [S]RTP packets will be sent/received than VIDEO [S]RTP packets. So no worries to be had here.

Because these tests are time-based and have a very fine real-time resolution (e.g. milliseconds) it is also normal to see a slight difference in the [S]RTP packets being exchanged each time the same test is run. So again nothing suspicious about slight variations in the number of [S]RTP packets seen on different runs of the exact same test.

vpattern is happy (exit 0), apattern is not (exit 253, as above).

I see - so then the problem is definitely specific to the AUDIO SRTP echo while the VIDEO SRTP echo is fine. I will focus on the AUDIO SRTP echo log files then.

From a quick inspection I'm not sure this is the AUDIO [S]RTP echo bug I have recently fixed but I need to make sure. So later this week/weekend I will attempt reproduction of your testcase. If I manage to reproduce it I will apply my fix locally and see if it cures it then go from there.

I normally use two different private IP addresses on two separate systems, I have never tried with two instances on the same host via localhost, although I would expect this to work.

It definitely seems like the AUDIO SRTP echoed back is completely wrong and I won't quite see why that would be at first glance. I should be able to figure this out once I reproduce it. I'll give this a shot soon and will let you know what I get.

Thanks for the help so far :)

[jeannotlanglois]

No luck reproducing on my side yet.

I've tried to mimic what I believe is your setup -- I've setup two additional lo:0 / lo:1 loopback interfaces (respectively with IPs 127.0.0.2 / 127.0.0.3 to respectively act as UAC / UAS):

lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:7251293 errors:0 dropped:0 overruns:0 frame:0 TX packets:7251293 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:82286791244 (76.6 GiB) TX bytes:82286791244 (76.6 GiB)

lo:0 Link encap:Local Loopback inet addr:127.0.0.2 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:65536 Metric:1

lo:1 Link encap:Local Loopback inet addr:127.0.0.3 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:65536 Metric:1

Then I built your "release candidate" SIPP 3.7 commit "d76b1c0405b9d052073dc8c1658ebb7f02bff5ae" to ensure I am testing the same baseline as you are:

commit d76b1c0405b9d052073dc8c1658ebb7f02bff5ae Merge: 2b8330c 39284e0 Author: Walter Doekes Date: Wed Oct 27 13:13:05 2021 +0200

On the UAS side I run the following:

./sipp -sf sipp_scenarios/pfca_uas_audio_crypto_simple.xml \ -t u1 -i 127.0.0.3 -p 5060 -min_rtp_port 4000 \ -m 1 -rtpcheck_debug -srtpcheck_debug

NOTE #1: You used the "both" version of the UAS testcase here - I assume this is just a typo and you are actually using the "audio" version of the UAS testcase? (if not then you should be using both the same type of media test on both the UAC and UAS sides - that is important).

On the UAC side I run the following:

./sipp 127.0.0.3:5060 -sf sipp_scenarios/pfca_uac_apattern_crypto_simple.xml.MODIFIED \ -t u1 -i 127.0.0.2 -p 5060 -min_rtp_port 5000 \ -m 1 -rtpcheck_debug -srtpcheck_debug

NOTE #2: Since testing on 127.0.0.0/8 actually runs a bit faster than usual some slight limitation of my UAC-side testcase got apparent and prevented me from running the testcase (turns out that one of the ... blocks I use on the UAS side is not entirely done executing when an ACK comes in and this causes the scenario to fail on the UAC side) - so I applied the following modification on the UAC side to ensure the ACK was being sent a little later so to give some extra time on the UAS side to finish executing the ... block:

$ diff -u sipp_scenarios/pfca_uac_apattern_crypto_simple.xml sipp_scenarios/pfca_uac_apattern_crypto_simple.xml.MODIFIED
--- sipp_scenarios/pfca_uac_apattern_crypto_simple.xml  2020-10-31 13:53:40.641570351 -0400
+++ sipp_scenarios/pfca_uac_apattern_crypto_simple.xml.MODIFIED 2021-11-07 21:02:26.408757485 -0500
@@ -88,12 +88,13 @@
   <recv response="200">
   </recv>

-  <!-- NOTE:  [branch-5] is used to specify reuse of same [branch] value that was used five messages earlier (e.g. INVITE) -->
+  <pause milliseconds="450"/>
+
   <send>
     <![CDATA[

       ACK ***@***.***_ip]:[remote_port] SIP/2.0
-      Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch-5]
+      Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch-6]
       From: "16001" ***@***.***_ip]:[remote_port];tag=[call_number]
       To: ***@***.***_ip]:[remote_port][peer_tag_param]
       Call-ID: [call_id]

Everything runs fine - the apattern version of the scenario returns "0" on the UAC side as I would expect.

• Could you be encountering problem with NOTE #1 above? Or could you be encountering a problem with NOTE #2 above?

• I will likely need more details about your setup as I am puzzled as to how to reproduce the problem.

Attaching trace apattern_jl.pcap of my successful attempt described above.

-- Jeannot Langlois Software Developer SIP Inspector RFC Lawyer Refactoring Expert MiVoice Border Gateway Development Mitel Networks ...

[wdoekes]

I've tried to mimic what I believe is your setup -- I've setup two additional lo:0 / lo:1 loopback interfaces (respectively with IPs 127.0.0.2 / 127.0.0.3 to respectively act as UAC / UAS):

You're making things hard on yourself. Generally your lo interface has all the addresses in 127.0.0.0/8.

You can check this with:

# ip route list table local | grep /
local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1 

So, you can do this, without adding lo:1 and friends:

# nc -s 127.1.2.3 -l -p 1234
^C

While you cannot do this:

# nc -s 128.1.2.3 -l -p 1234
nc: Cannot assign requested address

Unless you add that to some interface:

# ip route add local 128.1.2.0/24 dev eno1
# nc -s 128.1.2.3 -l -p 1234 
^C

In fact, as soon as you add that route, you'll get ping replies immediately:

# ping 128.1.2.55 -c1
PING 128.1.2.55 (128.1.2.55) 56(84) bytes of data.
64 bytes from 128.1.2.55: icmp_seq=1 ttl=64 time=0.026 ms

So, no lo:0 and lo:1 needed.

In fact, if you add an IP address to lo. it automatically gets the route for the entire range in the local routing table:

# ip addr add 128.1.2.3/24 dev lo
# ip route list table local | grep /
local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1 
local 128.1.2.0/24 dev lo proto kernel scope host src 128.1.2.3 

And listening/binding to any IP in that range is then valid.

(next reply addresses the rest)

[wdoekes]

NOTE #1: You used the "both" version of the UAS testcase here - I assume this is just a typo and you are actually using the "audio" version of the UAS testcase? (if not then you should be using both the same type of media test on both the UAC and UAS sides - that is important).

No that was not a typo. I've done exactly as you told :stuck_out_tongue: -- change bpattern to apattern and vpattern. I think did make all my steps clear along the way.

NOTE #2: Since testing on 127.0.0.0/8 actually runs a bit faster than usual some slight limitation of my UAC-side testcase got apparent and prevented me from running the testcase (turns out that one of the ... blocks I use on the UAS side is not entirely done executing when an ACK comes in and this causes the scenario to fail on the UAC side) - so I applied the following modification on the UAC side to ensure the ACK was being sent a little later so to give some extra time on the UAS side to finish executing the ... block:

That looks like the inverse of the fix I applied to sipp_scenarios/pfca_uas_both_crypto_simple.xml. See the diff in the original post.

I can get running these to work, either by applying my patch or yours:

uas_args='-t u1 -i 127.0.0.3 -p 5060 -min_rtp_port 4000 -m 1'
xml=../sipp_scenarios/pfca_uas_audio_crypto_simple.xml
sipp -sf $xml $uas_args -rtpcheck_debug -srtpcheck_debug

uac_args='-t u1 -i 127.0.0.2 -p 5060 -min_rtp_port 5000 -m 1'
xml=../sipp_scenarios/pfca_uac_apattern_crypto_simple.xml
../sipp 127.0.0.3:5060 -sf $xml $uac_args -rtpcheck_debug -srtpcheck_debug

My patch:

diff --git a/sipp_scenarios/pfca_uas_audio_crypto_simple.xml b/sipp_scenarios/pfca_uas_audio_crypto_simple.xml
index b4c3231..5c8d25d 100644
--- a/sipp_scenarios/pfca_uas_audio_crypto_simple.xml
+++ b/sipp_scenarios/pfca_uas_audio_crypto_simple.xml
@@ -86,15 +86,15 @@
     ]]>
   </send>

+  <recv request="ACK">
+  </recv>
+
   <nop>
     <action>
       <exec rtp_echo="startaudio,0,PCMU/8000" />
     </action>
   </nop>

-  <recv request="ACK">
-  </recv>
-
   <nop>
     <action>
       <exec rtp_echo="updateaudio,0,PCMU/8000" />

or your patch:

diff --git a/sipp_scenarios/pfca_uac_apattern_crypto_simple.xml b/sipp_scenarios/pfca_uac_apattern_crypto_simple.xml
index e58d024..4fc2845 100644
--- a/sipp_scenarios/pfca_uac_apattern_crypto_simple.xml
+++ b/sipp_scenarios/pfca_uac_apattern_crypto_simple.xml
@@ -88,12 +88,14 @@
   <recv response="200">
   </recv>

-  <!-- NOTE:  [branch-5] is used to specify reuse of same [branch] value that was used five messages earlier (e.g. INVITE) -->
+  <pause milliseconds="450"/>
+
+  <!-- NOTE:  [branch-6] is used to specify reuse of same [branch] value that was used five messages earlier (e.g. INVITE) -->
   <send>
     <![CDATA[

       ACK sip:[service]@[remote_ip]:[remote_port] SIP/2.0
-      Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch-5]
+      Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch-6]
       From: "16001" <sip:16001@[remote_ip]:[remote_port]>;tag=[call_number]
       To: <sip:[service]@[remote_ip]:[remote_port]>[peer_tag_param]
       Call-ID: [call_id]

--

If I also apply this to the vpattern -- assuming my patch is as good as yours:

diff --git a/sipp_scenarios/pfca_uas_video_crypto_simple.xml b/sipp_scenarios/pfca_uas_video_crypto_simple.xml
index 84a11bd..2017fe9 100644
--- a/sipp_scenarios/pfca_uas_video_crypto_simple.xml
+++ b/sipp_scenarios/pfca_uas_video_crypto_simple.xml
@@ -87,15 +87,15 @@
     ]]>
   </send>

+  <recv request="ACK">
+  </recv>
+ 
   <nop>
     <action>
       <exec rtp_echo="startvideo,99,H264/90000" />
     </action>
   </nop>

-  <recv request="ACK">
-  </recv>
- 
   <nop>
     <action>
       <exec rtp_echo="updatevideo,99,H264/90000" />

Then I can run a for-loop on all of them:

for xml in ../sipp_scenarios/pfca_uas_{audio,video,both}_crypto_simple.xml; do
  sipp -sf $xml $uas_args -rtpcheck_debug -srtpcheck_debug
  sleep 2
done

for xml in ../sipp_scenarios/pfca_uac_{a,v,b}pattern_crypto_simple.xml; do
  ../sipp 127.0.0.3:5060 -sf $xml $uac_args -rtpcheck_debug -srtpcheck_debug >/dev/null 2>&1
  echo "exit code $? for $xml" >&2
  sleep 3
done

This results in:

exit code 0 for ../sipp_scenarios/pfca_uac_apattern_crypto_simple.xml
exit code 0 for ../sipp_scenarios/pfca_uac_vpattern_crypto_simple.xml
exit code 253 for ../sipp_scenarios/pfca_uac_bpattern_crypto_simple.xml

So, the initial conclusion must be that there is something off when combining both scenarios. I find it hard to believe that you wouldn't be able to reproduce that though. Did you try the both+bpattern scenario? (I did try reversing the patch on both+bpattern, but that did not change the outcome of 253 here.)

(I'll apply my swap of the recv/nop in the mean time. If that fix is bad and your version with the pause is better, I'd love to know why. Adding a "random" sleep to a scenario is generally not the best solution.)

[jeannotlanglois]

Thanks for the pointers Walter. Indeed, I very rarely work with /8 networks that it never occurred to me thata 127.0.0.2 and 127.0.0.3 were also usable on the same interface... haha. Alright, so this part would be out of the way for reproducing.

[jeannotlanglois]

Hmm... it’s possible I might not have been clear, but definitely with this:

Can you separately try the same test (while still capturing both a WireShark trace + the debug logs) but instead of using the “bpattern” (audiovideo testcase), rather try two separate tests with with: a) the “apattern” (audioonly testcase) and b) the “vpattern” (videoonly testcase)?

I was expecting that only the same types of media are tested together at the same time on both the UAC / UAS sides, e.g.:

1. apattern on UAC with audio on UAS
2. vpattern on UAC with video on UAS
3. bpattern on UAC with both on UAS

These testcases+design assume this otherwise they will obviously fail as the type of media sent/received on the UAC side is used to set expectations – anything sent is expected to be received back – so if you expect both audio+video to be sent/received on the UAC side but only echo back one of the two on the UAS by selecting the wrong testcase obviously this will fail.

Before I go any further, can you confirm that what you attempted is indeed what I’ve described above? (e.g. test a) fails (e.g. not happy), test b) succeeds (e.g. happy), test c) fails (e.g. not happy))?

I think I will have some more time on Wednesday evening here to dig further.

[wdoekes]

These testcases+design assume this otherwise they will obviously fail as the type of media sent/received on the UAC side is used to set expectations – anything sent is expected to be received back – so if you expect both audio+video to be sent/received on the UAC side but only echo back one of the two on the UAS by selecting the wrong testcase obviously this will fail.

You say "obviously", but the vpattern UAC scenario apparently has no issues with the both UAS scenario. If I just consider the exit status of the UAC, then extra received RTP (extra/unexpected audio or video) might not be an issue. That's why I did not bother to look for alternative UAS scenarios when doing the initial tests you asked for.

Before I go any further, can you confirm that what you attempted is indeed what I’ve described above? (e.g. test a) fails (e.g. not happy), test b) succeeds (e.g. happy), test c) fails (e.g. not happy))?

I did write the following, which I shall repeat here:

for xml in ../sipp_scenarios/pfca_uas_{audio,video,both}_crypto_simple.xml; do
  sipp -sf $xml $uas_args -rtpcheck_debug -srtpcheck_debug
  sleep 2
done

^- three UAS scenarios in a row

for xml in ../sipp_scenarios/pfca_uac_{a,v,b}pattern_crypto_simple.xml; do
  ../sipp 127.0.0.3:5060 -sf $xml $uac_args -rtpcheck_debug -srtpcheck_debug >/dev/null 2>&1
  echo "exit code $? for $xml" >&2
  sleep 3
done

^- three UAC scenarios in a row, with status output

exit code 0 for ../sipp_scenarios/pfca_uac_apattern_crypto_simple.xml
exit code 0 for ../sipp_scenarios/pfca_uac_vpattern_crypto_simple.xml
exit code 253 for ../sipp_scenarios/pfca_uac_bpattern_crypto_simple.xml

^- the status output

That is with SIPp version and scenarios from commit f44d0cf.

Spelled out in words instead of reproducible output, the shell example above tests:

• pfca_uas_audio_crypto_simple.xml against pfca_uac_apattern_crypto_simple.xml (happy),
• pfca_uas_video_crypto_simple.xml against pfca_uac_vpattern_crypto_simple.xml (happy) and
• pfca_uas_both_crypto_simple.xml against pfca_uac_bpattern_crypto_simple.xml (NOT happy) in that order.

[jeannotlanglois]

You say "obviously", but the vpattern UAC scenario apparently has no issues with the both UAS scenario.

That could be just a coincidence - I would not expect mismatched medias to work. This is design intent.

If I just consider the exit status of the UAC, then extra received RTP (extra/unexpected audio or video) might not be an issue. That's why I did not bother to look for alternative UAS scenarios when doing the initial tests you asked for.

Looks like you have misunderstood what I asked for:

"

• Can you separately try the same test (while still capturing both a WireShark trace + the debug logs) but instead of using the "bpattern" (audiovideo testcase), rather try two separate tests with with:

a) the "apattern" (audioonly testcase)

and

b) the "vpattern" (videoonly testcase)?

"

Here is what I meant to say:

Run test #1 (Point "a)"): replace string "bpattern" on the UAC side filename by "audio" AND string "both" on the UAS side filename by "audio") then let me know what return value this gets on the UAC side. Run test #2 (Point "b)"): replace string "bpattern" on the UAC side filename by "video" AND string "both" on the UAS side filename by "video") then let me know what return value this gets on the UAS side.

Considering that this is an [S]RTP echo utility that checks for how many packets sent are echoed back I consider it obvious that the similar media names have to be used on the UAC/UAS sides. Maybe I should have been clearer... but when I tend to be very clear I normally get told that I include too many details.

Better too much than not enough I guess.

For test "a)" I had understood that by "unhappy" you meant that you were getting 253 as the return code. For test "b)" I had understood that by "happy" you meant that you were getting 0 as the return code.

Did I understand correctly this time?

(I need to know if, on the setup you are using, both these two unit tests pass or not, then I can move on to the "bpattern" (UAC) / "both" (UAS) one.

At this point in time I've tried "a)" above and it is "happy" with return code 0.

Please confirm/clarify if I've missed something. If both tests "a)" and "b)" above work for you successfully then I will try the combined one next. I'm not reproducing your problem yet.

-- Jeannot Langlois Software Developer SIP Inspector RFC Lawyer Refactoring Expert MiVoice Border Gateway Development Mitel Networks 4000 Innovation Drive Kanata (Ontario) K2K 3K1 http://www.mitel.comhttp://www.mitel.com/ @.**@.> x444364 (613) 691-3385 [Direct Dial]

"Never give in, never give in, never, never, never, never. In nothing, great or small, large or petty. Never give in except to convictions of honor and good sense."

• Winston Churchill

"Can I get an update on issue X? Did you fix issue X in stream Y?" [https://mitel.atlassian.net/issues/?filter=17325]

"When is MBG version X planned for GA? Will it include fix Y?" [https://mitel.atlassian.net/wiki/spaces/MBG/pages/5588287492/Project+Dashboard]

From: Walter Doekes @.> Sent: Tuesday, November 9, 2021 7:34 AM To: SIPp/sipp @.> Cc: Jeannot Langlois @.>; Mention @.> Subject: Re: [SIPp/sipp] SRTP example does not seem to work (Issue #544)

These testcases+design assume this otherwise they will obviously fail as the type of media sent/received on the UAC side is used to set expectations - anything sent is expected to be received back - so if you expect both audio+video to be sent/received on the UAC side but only echo back one of the two on the UAS by selecting the wrong testcase obviously this will fail.

You say "obviously", but the vpattern UAC scenario apparently has no issues with the both UAS scenario. If I just consider the exit status of the UAC, then extra received RTP (extra/unexpected audio or video) might not be an issue. That's why I did not bother to look for alternative UAS scenarios when doing the initial tests you asked for.

Before I go any further, can you confirm that what you attempted is indeed what I've described above? (e.g. test a) fails (e.g. not happy), test b) succeeds (e.g. happy), test c) fails (e.g. not happy))?

I did write the following, which I shall repeat here:

for xml in ../sipp_scenarios/pfcauas{audio,video,both}_crypto_simple.xml; do

sipp -sf $xml $uas_args -rtpcheck_debug -srtpcheck_debug

sleep 2

done

^- three UAS scenarios in a row

for xml in ../sipp_scenarios/pfcauac{a,v,b}pattern_crypto_simple.xml; do

../sipp 127.0.0.3:5060 -sf $xml $uac_args -rtpcheck_debug -srtpcheck_debug >/dev/null 2>&1

echo "exit code $? for $xml" >&2

sleep 3

done

^- three UAC scenarios in a row, with status output

exit code 0 for ../sipp_scenarios/pfca_uac_apattern_crypto_simple.xml

exit code 0 for ../sipp_scenarios/pfca_uac_vpattern_crypto_simple.xml

exit code 253 for ../sipp_scenarios/pfca_uac_bpattern_crypto_simple.xml

^- the status output

That is with SIPp version and scenarios from commit f44d0cfhttps://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FSIPp%2Fsipp%2Fcommit%2Ff44d0cf5dec0013eff8fd7b4da885d455aa82e0e&data=04%7C01%7Cjeannot.langlois%40mitel.com%7C38ee8535dfd14b30eb2608d9a37d2d53%7C4bff5a2bb30d493981ff8f76138347df%7C1%7C0%7C637720580324972518%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=V%2Bp3e5KeGlyPrcAN0ovOjM5tkQseFUMNc4Eik34Sl0w%3D&reserved=0.

Spelled out in words instead of reproducible output, the shell example above tests:

• pfca_uas_audio_crypto_simple.xml against pfca_uac_apattern_crypto_simple.xml (happy),
• pfca_uas_video_crypto_simple.xml against pfca_uac_vpattern_crypto_simple.xml (happy) and
• pfca_uas_both_crypto_simple.xml against pfca_uac_bpattern_crypto_simple.xml (NOT happy) in that order.

- You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FSIPp%2Fsipp%2Fissues%2F544%23issuecomment-964110482&data=04%7C01%7Cjeannot.langlois%40mitel.com%7C38ee8535dfd14b30eb2608d9a37d2d53%7C4bff5a2bb30d493981ff8f76138347df%7C1%7C0%7C637720580324982511%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=0kK2m3RLuJtPYQYdSy%2B5Tc5Ai4x7mcaM9K72ALHwgCw%3D&reserved=0, or unsubscribehttps://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAJK3K5J46KZIBGRFFB626Z3ULEIKXANCNFSM5GZU2PJA&data=04%7C01%7Cjeannot.langlois%40mitel.com%7C38ee8535dfd14b30eb2608d9a37d2d53%7C4bff5a2bb30d493981ff8f76138347df%7C1%7C0%7C637720580324992504%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=VcF%2B6A4SUOWZ%2FmLb65qa4xW2PIR4Dg4%2FFzDPkVqCCy4%3D&reserved=0. Triage notifications on the go with GitHub Mobile for iOShttps://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapps.apple.com%2Fapp%2Fapple-store%2Fid1477376905%3Fct%3Dnotification-email%26mt%3D8%26pt%3D524675&data=04%7C01%7Cjeannot.langlois%40mitel.com%7C38ee8535dfd14b30eb2608d9a37d2d53%7C4bff5a2bb30d493981ff8f76138347df%7C1%7C0%7C637720580324992504%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ptjS7r2591rOUYyqX5r4wS8KamQjbBNwSqTLy%2FeLLY4%3D&reserved=0 or Androidhttps://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fplay.google.com%2Fstore%2Fapps%2Fdetails%3Fid%3Dcom.github.android%26referrer%3Dutm_campaign%253Dnotification-email%2526utm_medium%253Demail%2526utm_source%253Dgithub&data=04%7C01%7Cjeannot.langlois%40mitel.com%7C38ee8535dfd14b30eb2608d9a37d2d53%7C4bff5a2bb30d493981ff8f76138347df%7C1%7C0%7C637720580325002497%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=hNdVqP%2FKLQqGcT7eUxG5%2FH%2B3P%2FQjUx664Onqwm7qKcg%3D&reserved=0.

---

NOTE: This e-mail (including any attachments) is for the sole use of the intended recipient(s) and may contain information that is confidential and/or protected by legal privilege. Any unauthorized review, use, copy, disclosure or distribution of this e-mail is strictly prohibited. If you are not the intended recipient, please notify Mitel immediately and destroy all copies of this e-mail. Mitel does not accept any liability for breach of security, error or virus that may result from the transmission of this message.

[jeannotlanglois]

Ah - the bottom part of your last email was clipped out of my screen... got it now:

exit code 0 for ../sipp_scenarios/pfca_uac_apattern_crypto_simple.xml

exit code 0 for ../sipp_scenarios/pfca_uac_vpattern_crypto_simple.xml

exit code 253 for ../sipp_scenarios/pfca_uac_bpattern_crypto_simple.xml

^- the status output

So you've correctly got a 0 return code for BOTH the apattern/audio and vpattern/video testcases - good, that is what I was expecting when I first asked for these two.

I went ahead and also tried the last one (bpattern/both) - I'm also getting the 253 error. I've applied my latest UAS-side SRTP echo fix but it has no issue on this problem (I'm still getting 253 on the UAC side).

So i'm definitely reproducing the issue you are seeing now... it only shows up with the bpattern/both scenario, not the two individual ones.

NOTE: As for the problematic XML scenarios you are right - inverting the ACK and the ... action blocks on the UAS side is the correct fix. The one I had tried on the UAC side with a pause was just a quick hack.

I will investigate this issue and will get back to you once I've figured out what is the problem. Probably this coming weekend will be better for me to look into this.

Thanks!

-- Jeannot Langlois Software Developer SIP Inspector RFC Lawyer Refactoring Expert MiVoice Border Gateway Development Mitel Networks 4000 Innovation Drive Kanata (Ontario) K2K 3K1 http://www.mitel.comhttp://www.mitel.com/ @.**@.> x444364 (613) 691-3385 [Direct Dial]

"Never give in, never give in, never, never, never, never. In nothing, great or small, large or petty. Never give in except to convictions of honor and good sense."

• Winston Churchill

"Can I get an update on issue X? Did you fix issue X in stream Y?" [https://mitel.atlassian.net/issues/?filter=17325]

"When is MBG version X planned for GA? Will it include fix Y?" [https://mitel.atlassian.net/wiki/spaces/MBG/pages/5588287492/Project+Dashboard]

From: Jeannot Langlois Sent: Wednesday, November 10, 2021 9:36 PM To: SIPp/sipp @.>; SIPp/sipp @.> Cc: Mention @.***> Subject: RE: [SIPp/sipp] SRTP example does not seem to work (Issue #544)

You say "obviously", but the vpattern UAC scenario apparently has no issues with the both UAS scenario.

That could be just a coincidence - I would not expect mismatched medias to work. This is design intent.

If I just consider the exit status of the UAC, then extra received RTP (extra/unexpected audio or video) might not be an issue. That's why I did not bother to look for alternative UAS scenarios when doing the initial tests you asked for.

Looks like you have misunderstood what I asked for:

"

• Can you separately try the same test (while still capturing both a WireShark trace + the debug logs) but instead of using the "bpattern" (audiovideo testcase), rather try two separate tests with with:

a) the "apattern" (audioonly testcase)

and

b) the "vpattern" (videoonly testcase)?

"

Here is what I meant to say:

Run test #1 (Point "a)"): replace string "bpattern" on the UAC side filename by "audio" AND string "both" on the UAS side filename by "audio") then let me know what return value this gets on the UAC side. Run test #2 (Point "b)"): replace string "bpattern" on the UAC side filename by "video" AND string "both" on the UAS side filename by "video") then let me know what return value this gets on the UAS side.

Considering that this is an [S]RTP echo utility that checks for how many packets sent are echoed back I consider it obvious that the similar media names have to be used on the UAC/UAS sides. Maybe I should have been clearer... but when I tend to be very clear I normally get told that I include too many details.

Better too much than not enough I guess.

For test "a)" I had understood that by "unhappy" you meant that you were getting 253 as the return code. For test "b)" I had understood that by "happy" you meant that you were getting 0 as the return code.

Did I understand correctly this time?

(I need to know if, on the setup you are using, both these two unit tests pass or not, then I can move on to the "bpattern" (UAC) / "both" (UAS) one.

At this point in time I've tried "a)" above and it is "happy" with return code 0.

Please confirm/clarify if I've missed something. If both tests "a)" and "b)" above work for you successfully then I will try the combined one next. I'm not reproducing your problem yet.

-- Jeannot Langlois Software Developer SIP Inspector RFC Lawyer Refactoring Expert MiVoice Border Gateway Development Mitel Networks 4000 Innovation Drive Kanata (Ontario) K2K 3K1 http://www.mitel.comhttp://www.mitel.com/ @.**@.> x444364 (613) 691-3385 [Direct Dial]

"Never give in, never give in, never, never, never, never. In nothing, great or small, large or petty. Never give in except to convictions of honor and good sense."

• Winston Churchill

"Can I get an update on issue X? Did you fix issue X in stream Y?" [https://mitel.atlassian.net/issues/?filter=17325]

"When is MBG version X planned for GA? Will it include fix Y?" [https://mitel.atlassian.net/wiki/spaces/MBG/pages/5588287492/Project+Dashboard]

From: Walter Doekes @.> Sent: Tuesday, November 9, 2021 7:34 AM To: SIPp/sipp @.> Cc: Jeannot Langlois @.>; Mention @.> Subject: Re: [SIPp/sipp] SRTP example does not seem to work (Issue #544)

These testcases+design assume this otherwise they will obviously fail as the type of media sent/received on the UAC side is used to set expectations - anything sent is expected to be received back - so if you expect both audio+video to be sent/received on the UAC side but only echo back one of the two on the UAS by selecting the wrong testcase obviously this will fail.

You say "obviously", but the vpattern UAC scenario apparently has no issues with the both UAS scenario. If I just consider the exit status of the UAC, then extra received RTP (extra/unexpected audio or video) might not be an issue. That's why I did not bother to look for alternative UAS scenarios when doing the initial tests you asked for.

Before I go any further, can you confirm that what you attempted is indeed what I've described above? (e.g. test a) fails (e.g. not happy), test b) succeeds (e.g. happy), test c) fails (e.g. not happy))?

I did write the following, which I shall repeat here:

for xml in ../sipp_scenarios/pfcauas{audio,video,both}_crypto_simple.xml; do

sipp -sf $xml $uas_args -rtpcheck_debug -srtpcheck_debug

sleep 2

done

^- three UAS scenarios in a row

for xml in ../sipp_scenarios/pfcauac{a,v,b}pattern_crypto_simple.xml; do

../sipp 127.0.0.3:5060 -sf $xml $uac_args -rtpcheck_debug -srtpcheck_debug >/dev/null 2>&1

echo "exit code $? for $xml" >&2

sleep 3

done

^- three UAC scenarios in a row, with status output

exit code 0 for ../sipp_scenarios/pfca_uac_apattern_crypto_simple.xml

exit code 0 for ../sipp_scenarios/pfca_uac_vpattern_crypto_simple.xml

exit code 253 for ../sipp_scenarios/pfca_uac_bpattern_crypto_simple.xml

^- the status output

That is with SIPp version and scenarios from commit f44d0cfhttps://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FSIPp%2Fsipp%2Fcommit%2Ff44d0cf5dec0013eff8fd7b4da885d455aa82e0e&data=04%7C01%7Cjeannot.langlois%40mitel.com%7C38ee8535dfd14b30eb2608d9a37d2d53%7C4bff5a2bb30d493981ff8f76138347df%7C1%7C0%7C637720580324972518%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=V%2Bp3e5KeGlyPrcAN0ovOjM5tkQseFUMNc4Eik34Sl0w%3D&reserved=0.

Spelled out in words instead of reproducible output, the shell example above tests:

• pfca_uas_audio_crypto_simple.xml against pfca_uac_apattern_crypto_simple.xml (happy),
• pfca_uas_video_crypto_simple.xml against pfca_uac_vpattern_crypto_simple.xml (happy) and
• pfca_uas_both_crypto_simple.xml against pfca_uac_bpattern_crypto_simple.xml (NOT happy) in that order.

- You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FSIPp%2Fsipp%2Fissues%2F544%23issuecomment-964110482&data=04%7C01%7Cjeannot.langlois%40mitel.com%7C38ee8535dfd14b30eb2608d9a37d2d53%7C4bff5a2bb30d493981ff8f76138347df%7C1%7C0%7C637720580324982511%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=0kK2m3RLuJtPYQYdSy%2B5Tc5Ai4x7mcaM9K72ALHwgCw%3D&reserved=0, or unsubscribehttps://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAJK3K5J46KZIBGRFFB626Z3ULEIKXANCNFSM5GZU2PJA&data=04%7C01%7Cjeannot.langlois%40mitel.com%7C38ee8535dfd14b30eb2608d9a37d2d53%7C4bff5a2bb30d493981ff8f76138347df%7C1%7C0%7C637720580324992504%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=VcF%2B6A4SUOWZ%2FmLb65qa4xW2PIR4Dg4%2FFzDPkVqCCy4%3D&reserved=0. Triage notifications on the go with GitHub Mobile for iOShttps://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapps.apple.com%2Fapp%2Fapple-store%2Fid1477376905%3Fct%3Dnotification-email%26mt%3D8%26pt%3D524675&data=04%7C01%7Cjeannot.langlois%40mitel.com%7C38ee8535dfd14b30eb2608d9a37d2d53%7C4bff5a2bb30d493981ff8f76138347df%7C1%7C0%7C637720580324992504%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ptjS7r2591rOUYyqX5r4wS8KamQjbBNwSqTLy%2FeLLY4%3D&reserved=0 or Androidhttps://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fplay.google.com%2Fstore%2Fapps%2Fdetails%3Fid%3Dcom.github.android%26referrer%3Dutm_campaign%253Dnotification-email%2526utm_medium%253Demail%2526utm_source%253Dgithub&data=04%7C01%7Cjeannot.langlois%40mitel.com%7C38ee8535dfd14b30eb2608d9a37d2d53%7C4bff5a2bb30d493981ff8f76138347df%7C1%7C0%7C637720580325002497%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=hNdVqP%2FKLQqGcT7eUxG5%2FH%2B3P%2FQjUx664Onqwm7qKcg%3D&reserved=0.

---

NOTE: This e-mail (including any attachments) is for the sole use of the intended recipient(s) and may contain information that is confidential and/or protected by legal privilege. Any unauthorized review, use, copy, disclosure or distribution of this e-mail is strictly prohibited. If you are not the intended recipient, please notify Mitel immediately and destroy all copies of this e-mail. Mitel does not accept any liability for breach of security, error or virus that may result from the transmission of this message.

[wdoekes]

It looks like we're finally on the same page again :ok_hand:

Ah - the bottom part of your last email was clipped out of my screen

For the future, I implore you to look at the Issue tracker on github when things get muddy: https:// github.com /SIPp/sipp/ issues/544 E-mail can be a convenient medium, but I have a feeling some of the ticket formatting gets lost there causing us both to get frustrated with each other.

[jeannotlanglois]

Actually it was me just not scrolling enough towards the bottom of the screen after I had alt-TAB’ed to check things. No worries there. The important thing is that I can reproduce the problem now and will be looking at it more in-depth shortly.

Last night I did some quick debug traces and found out that what is sent before encryption from the UAC is different from what gets received back after decryption on the UAC. There is something that acts weird when both audio/video SRTP echo is performed at the same time (otherwise when used separately everything works great as the two separate unit test reveals).

-- Jeannot Langlois Software Developer SIP Inspector RFC Lawyer Refactoring Expert MiVoice Border Gateway Development Mitel Networks 4000 Innovation Drive Kanata (Ontario) K2K 3K1 http://www.mitel.comhttp://www.mitel.com/ @.**@.> x444364 (613) 691-3385 [Direct Dial]

"Never give in, never give in, never, never, never, never. In nothing, great or small, large or petty. Never give in except to convictions of honor and good sense." – Winston Churchill

"Can I get an update on issue X? Did you fix issue X in stream Y?" [https://mitel.atlassian.net/issues/?filter=17325]

"When is MBG version X planned for GA? Will it include fix Y?" [https://mitel.atlassian.net/wiki/spaces/MBG/pages/5588287492/Project+Dashboard]

From: Walter Doekes @.> Sent: Thursday, November 11, 2021 2:57 AM To: SIPp/sipp @.> Cc: Jeannot Langlois @.>; Mention @.> Subject: Re: [SIPp/sipp] SRTP example does not seem to work (Issue #544)

It looks like we're finally on the same page again 👌

Ah - the bottom part of your last email was clipped out of my screen

For the future, I emplore you to look at the Issue tracker on github when things get muddy: https:// github.com /SIPp/sipp/ issues/544 E-mail can be a convenient medium, but I have a feeling some of the ticket formatting gets lost there causing us both to get frustrated with each other.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FSIPp%2Fsipp%2Fissues%2F544%23issuecomment-966069581&data=04%7C01%7Cjeannot.langlois%40mitel.com%7Cec6c0c67ea5541181c3008d9a4e8cc9e%7C4bff5a2bb30d493981ff8f76138347df%7C1%7C0%7C637722142050335078%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=tEQ8fpHRpzXBBxcccgg5fMLO08lbaWBDYwYVY1MoLXQ%3D&reserved=0, or unsubscribehttps://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAJK3K5PX6BROOAB5Y7HRXOLULNZLTANCNFSM5GZU2PJA&data=04%7C01%7Cjeannot.langlois%40mitel.com%7Cec6c0c67ea5541181c3008d9a4e8cc9e%7C4bff5a2bb30d493981ff8f76138347df%7C1%7C0%7C637722142050335078%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=KjUdOBnSPDfpeV%2F2hgPJ%2Bnz1VcptzdWdoYV85pCSZlY%3D&reserved=0. Triage notifications on the go with GitHub Mobile for iOShttps://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapps.apple.com%2Fapp%2Fapple-store%2Fid1477376905%3Fct%3Dnotification-email%26mt%3D8%26pt%3D524675&data=04%7C01%7Cjeannot.langlois%40mitel.com%7Cec6c0c67ea5541181c3008d9a4e8cc9e%7C4bff5a2bb30d493981ff8f76138347df%7C1%7C0%7C637722142050345075%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Hv0Nfb6Ly28qNI3a3RxVH3qBQlehHJ9RTYpQdVZNUtM%3D&reserved=0 or Androidhttps://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fplay.google.com%2Fstore%2Fapps%2Fdetails%3Fid%3Dcom.github.android%26referrer%3Dutm_campaign%253Dnotification-email%2526utm_medium%253Demail%2526utm_source%253Dgithub&data=04%7C01%7Cjeannot.langlois%40mitel.com%7Cec6c0c67ea5541181c3008d9a4e8cc9e%7C4bff5a2bb30d493981ff8f76138347df%7C1%7C0%7C637722142050345075%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=UgD%2BH4kluBGCtwc7dGOrfufGt%2FMgQd7GbEt2Q1oGfYw%3D&reserved=0.

---

NOTE: This e-mail (including any attachments) is for the sole use of the intended recipient(s) and may contain information that is confidential and/or protected by legal privilege. Any unauthorized review, use, copy, disclosure or distribution of this e-mail is strictly prohibited. If you are not the intended recipient, please notify Mitel immediately and destroy all copies of this e-mail. Mitel does not accept any liability for breach of security, error or virus that may result from the transmission of this message.

[jeannotlanglois]

Hi there:

Just a quick heads up that I have not forgotten about this issue – I’ve taken a look this weekend but ran out of time. I definitely see an issue on the SRTP echo thread side – encrypted bytes are being properly received but for some reason that I yet need to figure out the JLSRTP processIncomingPacket() API returns an empty RTP payload after decryption – something fishy is happening in there – then this incorrect payload is reencrypted by JLSRTP processOutgoingPacket() API then sent back to the UAC side which of course triggers an error; this repeats for every packet. It’s really strange that this does not happen for video packets though.

This is where I am at now. I will continue to dig into this probably Thursday this week. I hope I am not blocking the release though. Sooner or later I’ll figure out this issue.

Cheers :)

-- Jeannot Langlois Software Developer SIP Inspector RFC Lawyer Refactoring Expert MiVoice Border Gateway Development Mitel Networks 4000 Innovation Drive Kanata (Ontario) K2K 3K1 http://www.mitel.comhttp://www.mitel.com/ @.**@.> x444364 (613) 691-3385 [Direct Dial]

"Never give in, never give in, never, never, never, never. In nothing, great or small, large or petty. Never give in except to convictions of honor and good sense." – Winston Churchill

"Can I get an update on issue X? Did you fix issue X in stream Y?" [https://mitel.atlassian.net/issues/?filter=17325]

"When is MBG version X planned for GA? Will it include fix Y?" [https://mitel.atlassian.net/wiki/spaces/MBG/pages/5588287492/Project+Dashboard]

From: Jeannot Langlois Sent: Thursday, November 11, 2021 10:00 AM To: SIPp/sipp @.>; SIPp/sipp @.> Cc: Mention @.***> Subject: RE: [SIPp/sipp] SRTP example does not seem to work (Issue #544)

Actually it was me just not scrolling enough towards the bottom of the screen after I had alt-TAB’ed to check things. No worries there. The important thing is that I can reproduce the problem now and will be looking at it more in-depth shortly.

Last night I did some quick debug traces and found out that what is sent before encryption from the UAC is different from what gets received back after decryption on the UAC. There is something that acts weird when both audio/video SRTP echo is performed at the same time (otherwise when used separately everything works great as the two separate unit test reveals).

-- Jeannot Langlois Software Developer SIP Inspector RFC Lawyer Refactoring Expert MiVoice Border Gateway Development Mitel Networks 4000 Innovation Drive Kanata (Ontario) K2K 3K1 http://www.mitel.comhttp://www.mitel.com/ @.**@.> x444364 (613) 691-3385 [Direct Dial]

"Never give in, never give in, never, never, never, never. In nothing, great or small, large or petty. Never give in except to convictions of honor and good sense." – Winston Churchill

"Can I get an update on issue X? Did you fix issue X in stream Y?" [https://mitel.atlassian.net/issues/?filter=17325]

"When is MBG version X planned for GA? Will it include fix Y?" [https://mitel.atlassian.net/wiki/spaces/MBG/pages/5588287492/Project+Dashboard]

From: Walter Doekes @.> Sent: Thursday, November 11, 2021 2:57 AM To: SIPp/sipp @.> Cc: Jeannot Langlois @.>; Mention @.> Subject: Re: [SIPp/sipp] SRTP example does not seem to work (Issue #544)

It looks like we're finally on the same page again 👌

Ah - the bottom part of your last email was clipped out of my screen

For the future, I emplore you to look at the Issue tracker on github when things get muddy: https:// github.com /SIPp/sipp/ issues/544 E-mail can be a convenient medium, but I have a feeling some of the ticket formatting gets lost there causing us both to get frustrated with each other.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FSIPp%2Fsipp%2Fissues%2F544%23issuecomment-966069581&data=04%7C01%7Cjeannot.langlois%40mitel.com%7Cec6c0c67ea5541181c3008d9a4e8cc9e%7C4bff5a2bb30d493981ff8f76138347df%7C1%7C0%7C637722142050335078%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=tEQ8fpHRpzXBBxcccgg5fMLO08lbaWBDYwYVY1MoLXQ%3D&reserved=0, or unsubscribehttps://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAJK3K5PX6BROOAB5Y7HRXOLULNZLTANCNFSM5GZU2PJA&data=04%7C01%7Cjeannot.langlois%40mitel.com%7Cec6c0c67ea5541181c3008d9a4e8cc9e%7C4bff5a2bb30d493981ff8f76138347df%7C1%7C0%7C637722142050335078%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=KjUdOBnSPDfpeV%2F2hgPJ%2Bnz1VcptzdWdoYV85pCSZlY%3D&reserved=0. Triage notifications on the go with GitHub Mobile for iOShttps://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapps.apple.com%2Fapp%2Fapple-store%2Fid1477376905%3Fct%3Dnotification-email%26mt%3D8%26pt%3D524675&data=04%7C01%7Cjeannot.langlois%40mitel.com%7Cec6c0c67ea5541181c3008d9a4e8cc9e%7C4bff5a2bb30d493981ff8f76138347df%7C1%7C0%7C637722142050345075%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Hv0Nfb6Ly28qNI3a3RxVH3qBQlehHJ9RTYpQdVZNUtM%3D&reserved=0 or Androidhttps://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fplay.google.com%2Fstore%2Fapps%2Fdetails%3Fid%3Dcom.github.android%26referrer%3Dutm_campaign%253Dnotification-email%2526utm_medium%253Demail%2526utm_source%253Dgithub&data=04%7C01%7Cjeannot.langlois%40mitel.com%7Cec6c0c67ea5541181c3008d9a4e8cc9e%7C4bff5a2bb30d493981ff8f76138347df%7C1%7C0%7C637722142050345075%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=UgD%2BH4kluBGCtwc7dGOrfufGt%2FMgQd7GbEt2Q1oGfYw%3D&reserved=0.

---

NOTE: This e-mail (including any attachments) is for the sole use of the intended recipient(s) and may contain information that is confidential and/or protected by legal privilege. Any unauthorized review, use, copy, disclosure or distribution of this e-mail is strictly prohibited. If you are not the intended recipient, please notify Mitel immediately and destroy all copies of this e-mail. Mitel does not accept any liability for breach of security, error or virus that may result from the transmission of this message.

[wdoekes]

Quickly thinking out loud:

It’s really strange that this does not happen for video packets though.

I would put my money on something getting limited by the slowest of the two media types. That's where I would start to look at least. (Thinking back to the 12/13 packets I saw in the both pcap, whereas there were 90+ packets in the audio pcap.)

[jeannotlanglois]

Just an heads up FYI: I got further into my troubleshooting today and narrowed things down to a promising lead. Expecting to likely finish this work this weekend. As soon as I have a tested fix I will definitely let you know.

Cheers :)

-- Jeannot Langlois Software Developer SIP Inspector RFC Lawyer Refactoring Expert MiVoice Border Gateway Development Mitel Networks 4000 Innovation Drive Kanata (Ontario) K2K 3K1 http://www.mitel.comhttp://www.mitel.com/ @.**@.> x444364 (613) 691-3385 [Direct Dial]

"Never give in, never give in, never, never, never, never. In nothing, great or small, large or petty. Never give in except to convictions of honor and good sense." – Winston Churchill

"Can I get an update on issue X? Did you fix issue X in stream Y?" [https://mitel.atlassian.net/issues/?filter=17325]

"When is MBG version X planned for GA? Will it include fix Y?" [https://mitel.atlassian.net/wiki/spaces/MBG/pages/5588287492/Project+Dashboard]

From: Jeannot Langlois Sent: Sunday, November 14, 2021 6:30 PM To: 'SIPp/sipp' @.>; 'SIPp/sipp' @.> Cc: 'Mention' @.***> Subject: RE: [SIPp/sipp] SRTP example does not seem to work (Issue #544)

Hi there:

Just a quick heads up that I have not forgotten about this issue – I’ve taken a look this weekend but ran out of time. I definitely see an issue on the SRTP echo thread side – encrypted bytes are being properly received but for some reason that I yet need to figure out the JLSRTP processIncomingPacket() API returns an empty RTP payload after decryption – something fishy is happening in there – then this incorrect payload is reencrypted by JLSRTP processOutgoingPacket() API then sent back to the UAC side which of course triggers an error; this repeats for every packet. It’s really strange that this does not happen for video packets though.

This is where I am at now. I will continue to dig into this probably Thursday this week. I hope I am not blocking the release though. Sooner or later I’ll figure out this issue.

Cheers :)

-- Jeannot Langlois Software Developer SIP Inspector RFC Lawyer Refactoring Expert MiVoice Border Gateway Development Mitel Networks 4000 Innovation Drive Kanata (Ontario) K2K 3K1 http://www.mitel.comhttp://www.mitel.com/ @.**@.> x444364 (613) 691-3385 [Direct Dial]

"Never give in, never give in, never, never, never, never. In nothing, great or small, large or petty. Never give in except to convictions of honor and good sense." – Winston Churchill

"Can I get an update on issue X? Did you fix issue X in stream Y?" [https://mitel.atlassian.net/issues/?filter=17325]

"When is MBG version X planned for GA? Will it include fix Y?" [https://mitel.atlassian.net/wiki/spaces/MBG/pages/5588287492/Project+Dashboard]

From: Jeannot Langlois Sent: Thursday, November 11, 2021 10:00 AM To: SIPp/sipp @.>; SIPp/sipp @.> Cc: Mention @.***> Subject: RE: [SIPp/sipp] SRTP example does not seem to work (Issue #544)

Actually it was me just not scrolling enough towards the bottom of the screen after I had alt-TAB’ed to check things. No worries there. The important thing is that I can reproduce the problem now and will be looking at it more in-depth shortly.

Last night I did some quick debug traces and found out that what is sent before encryption from the UAC is different from what gets received back after decryption on the UAC. There is something that acts weird when both audio/video SRTP echo is performed at the same time (otherwise when used separately everything works great as the two separate unit test reveals).

-- Jeannot Langlois Software Developer SIP Inspector RFC Lawyer Refactoring Expert MiVoice Border Gateway Development Mitel Networks 4000 Innovation Drive Kanata (Ontario) K2K 3K1 http://www.mitel.comhttp://www.mitel.com/ @.**@.> x444364 (613) 691-3385 [Direct Dial]

"Never give in, never give in, never, never, never, never. In nothing, great or small, large or petty. Never give in except to convictions of honor and good sense." – Winston Churchill

"Can I get an update on issue X? Did you fix issue X in stream Y?" [https://mitel.atlassian.net/issues/?filter=17325]

"When is MBG version X planned for GA? Will it include fix Y?" [https://mitel.atlassian.net/wiki/spaces/MBG/pages/5588287492/Project+Dashboard]

From: Walter Doekes @.> Sent: Thursday, November 11, 2021 2:57 AM To: SIPp/sipp @.> Cc: Jeannot Langlois @.>; Mention @.> Subject: Re: [SIPp/sipp] SRTP example does not seem to work (Issue #544)

It looks like we're finally on the same page again 👌

Ah - the bottom part of your last email was clipped out of my screen

For the future, I emplore you to look at the Issue tracker on github when things get muddy: https:// github.com /SIPp/sipp/ issues/544 E-mail can be a convenient medium, but I have a feeling some of the ticket formatting gets lost there causing us both to get frustrated with each other.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FSIPp%2Fsipp%2Fissues%2F544%23issuecomment-966069581&data=04%7C01%7Cjeannot.langlois%40mitel.com%7Cec6c0c67ea5541181c3008d9a4e8cc9e%7C4bff5a2bb30d493981ff8f76138347df%7C1%7C0%7C637722142050335078%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=tEQ8fpHRpzXBBxcccgg5fMLO08lbaWBDYwYVY1MoLXQ%3D&reserved=0, or unsubscribehttps://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAJK3K5PX6BROOAB5Y7HRXOLULNZLTANCNFSM5GZU2PJA&data=04%7C01%7Cjeannot.langlois%40mitel.com%7Cec6c0c67ea5541181c3008d9a4e8cc9e%7C4bff5a2bb30d493981ff8f76138347df%7C1%7C0%7C637722142050335078%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=KjUdOBnSPDfpeV%2F2hgPJ%2Bnz1VcptzdWdoYV85pCSZlY%3D&reserved=0. Triage notifications on the go with GitHub Mobile for iOShttps://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapps.apple.com%2Fapp%2Fapple-store%2Fid1477376905%3Fct%3Dnotification-email%26mt%3D8%26pt%3D524675&data=04%7C01%7Cjeannot.langlois%40mitel.com%7Cec6c0c67ea5541181c3008d9a4e8cc9e%7C4bff5a2bb30d493981ff8f76138347df%7C1%7C0%7C637722142050345075%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Hv0Nfb6Ly28qNI3a3RxVH3qBQlehHJ9RTYpQdVZNUtM%3D&reserved=0 or Androidhttps://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fplay.google.com%2Fstore%2Fapps%2Fdetails%3Fid%3Dcom.github.android%26referrer%3Dutm_campaign%253Dnotification-email%2526utm_medium%253Demail%2526utm_source%253Dgithub&data=04%7C01%7Cjeannot.langlois%40mitel.com%7Cec6c0c67ea5541181c3008d9a4e8cc9e%7C4bff5a2bb30d493981ff8f76138347df%7C1%7C0%7C637722142050345075%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=UgD%2BH4kluBGCtwc7dGOrfufGt%2FMgQd7GbEt2Q1oGfYw%3D&reserved=0.

---

NOTE: This e-mail (including any attachments) is for the sole use of the intended recipient(s) and may contain information that is confidential and/or protected by legal privilege. Any unauthorized review, use, copy, disclosure or distribution of this e-mail is strictly prohibited. If you are not the intended recipient, please notify Mitel immediately and destroy all copies of this e-mail. Mitel does not accept any liability for breach of security, error or virus that may result from the transmission of this message.

[wdoekes]

Great that you're making progress :+1:

[jeannotlanglois]

Heads up:

I’ve nailed down this issue. All testcases (audionly, videoonly, audiovideo) now pass flawlessly. I’d like to do some more integration testing tomorrow with my full setup. Then I can submit the fix as a pull request probably on Tuesday. I will also be submitting another small SRTP echo related fix which I’ve made recently. This way SIPP-3.7 will contain fixes for all known issues.

-- Jeannot Langlois Software Developer SIP Inspector RFC Lawyer Refactoring Expert MiVoice Border Gateway Development Mitel Networks 4000 Innovation Drive Kanata (Ontario) K2K 3K1 http://www.mitel.comhttp://www.mitel.com/ @.**@.> x444364 (613) 691-3385 [Direct Dial]

"Never give in, never give in, never, never, never, never. In nothing, great or small, large or petty. Never give in except to convictions of honor and good sense." – Winston Churchill

"Can I get an update on issue X? Did you fix issue X in stream Y?" [https://mitel.atlassian.net/issues/?filter=17325]

"When is MBG version X planned for GA? Will it include fix Y?" [https://mitel.atlassian.net/wiki/spaces/MBG/pages/5588287492/Project+Dashboard]

From: Jeannot Langlois Sent: Thursday, November 18, 2021 8:56 PM To: SIPp/sipp @.>; SIPp/sipp @.> Cc: Mention @.***> Subject: RE: [SIPp/sipp] SRTP example does not seem to work (Issue #544)

Just an heads up FYI: I got further into my troubleshooting today and narrowed things down to a promising lead. Expecting to likely finish this work this weekend. As soon as I have a tested fix I will definitely let you know.

Cheers :)

-- Jeannot Langlois Software Developer SIP Inspector RFC Lawyer Refactoring Expert MiVoice Border Gateway Development Mitel Networks 4000 Innovation Drive Kanata (Ontario) K2K 3K1 http://www.mitel.comhttp://www.mitel.com/ @.**@.> x444364 (613) 691-3385 [Direct Dial]

"Never give in, never give in, never, never, never, never. In nothing, great or small, large or petty. Never give in except to convictions of honor and good sense." – Winston Churchill

"Can I get an update on issue X? Did you fix issue X in stream Y?" [https://mitel.atlassian.net/issues/?filter=17325]

"When is MBG version X planned for GA? Will it include fix Y?" [https://mitel.atlassian.net/wiki/spaces/MBG/pages/5588287492/Project+Dashboard]

From: Jeannot Langlois Sent: Sunday, November 14, 2021 6:30 PM To: 'SIPp/sipp' @.>; 'SIPp/sipp' @.> Cc: 'Mention' @.***> Subject: RE: [SIPp/sipp] SRTP example does not seem to work (Issue #544)

Hi there:

Just a quick heads up that I have not forgotten about this issue – I’ve taken a look this weekend but ran out of time. I definitely see an issue on the SRTP echo thread side – encrypted bytes are being properly received but for some reason that I yet need to figure out the JLSRTP processIncomingPacket() API returns an empty RTP payload after decryption – something fishy is happening in there – then this incorrect payload is reencrypted by JLSRTP processOutgoingPacket() API then sent back to the UAC side which of course triggers an error; this repeats for every packet. It’s really strange that this does not happen for video packets though.

This is where I am at now. I will continue to dig into this probably Thursday this week. I hope I am not blocking the release though. Sooner or later I’ll figure out this issue.

Cheers :)

-- Jeannot Langlois Software Developer SIP Inspector RFC Lawyer Refactoring Expert MiVoice Border Gateway Development Mitel Networks 4000 Innovation Drive Kanata (Ontario) K2K 3K1 http://www.mitel.comhttp://www.mitel.com/ @.**@.> x444364 (613) 691-3385 [Direct Dial]

"Never give in, never give in, never, never, never, never. In nothing, great or small, large or petty. Never give in except to convictions of honor and good sense." – Winston Churchill

"Can I get an update on issue X? Did you fix issue X in stream Y?" [https://mitel.atlassian.net/issues/?filter=17325]

"When is MBG version X planned for GA? Will it include fix Y?" [https://mitel.atlassian.net/wiki/spaces/MBG/pages/5588287492/Project+Dashboard]

From: Jeannot Langlois Sent: Thursday, November 11, 2021 10:00 AM To: SIPp/sipp @.>; SIPp/sipp @.> Cc: Mention @.***> Subject: RE: [SIPp/sipp] SRTP example does not seem to work (Issue #544)

Actually it was me just not scrolling enough towards the bottom of the screen after I had alt-TAB’ed to check things. No worries there. The important thing is that I can reproduce the problem now and will be looking at it more in-depth shortly.

Last night I did some quick debug traces and found out that what is sent before encryption from the UAC is different from what gets received back after decryption on the UAC. There is something that acts weird when both audio/video SRTP echo is performed at the same time (otherwise when used separately everything works great as the two separate unit test reveals).

-- Jeannot Langlois Software Developer SIP Inspector RFC Lawyer Refactoring Expert MiVoice Border Gateway Development Mitel Networks 4000 Innovation Drive Kanata (Ontario) K2K 3K1 http://www.mitel.comhttp://www.mitel.com/ @.**@.> x444364 (613) 691-3385 [Direct Dial]

"Never give in, never give in, never, never, never, never. In nothing, great or small, large or petty. Never give in except to convictions of honor and good sense." – Winston Churchill

"Can I get an update on issue X? Did you fix issue X in stream Y?" [https://mitel.atlassian.net/issues/?filter=17325]

"When is MBG version X planned for GA? Will it include fix Y?" [https://mitel.atlassian.net/wiki/spaces/MBG/pages/5588287492/Project+Dashboard]

From: Walter Doekes @.> Sent: Thursday, November 11, 2021 2:57 AM To: SIPp/sipp @.> Cc: Jeannot Langlois @.>; Mention @.> Subject: Re: [SIPp/sipp] SRTP example does not seem to work (Issue #544)

It looks like we're finally on the same page again 👌

Ah - the bottom part of your last email was clipped out of my screen

For the future, I emplore you to look at the Issue tracker on github when things get muddy: https:// github.com /SIPp/sipp/ issues/544 E-mail can be a convenient medium, but I have a feeling some of the ticket formatting gets lost there causing us both to get frustrated with each other.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FSIPp%2Fsipp%2Fissues%2F544%23issuecomment-966069581&data=04%7C01%7Cjeannot.langlois%40mitel.com%7Cec6c0c67ea5541181c3008d9a4e8cc9e%7C4bff5a2bb30d493981ff8f76138347df%7C1%7C0%7C637722142050335078%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=tEQ8fpHRpzXBBxcccgg5fMLO08lbaWBDYwYVY1MoLXQ%3D&reserved=0, or unsubscribehttps://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAJK3K5PX6BROOAB5Y7HRXOLULNZLTANCNFSM5GZU2PJA&data=04%7C01%7Cjeannot.langlois%40mitel.com%7Cec6c0c67ea5541181c3008d9a4e8cc9e%7C4bff5a2bb30d493981ff8f76138347df%7C1%7C0%7C637722142050335078%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=KjUdOBnSPDfpeV%2F2hgPJ%2Bnz1VcptzdWdoYV85pCSZlY%3D&reserved=0. Triage notifications on the go with GitHub Mobile for iOShttps://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapps.apple.com%2Fapp%2Fapple-store%2Fid1477376905%3Fct%3Dnotification-email%26mt%3D8%26pt%3D524675&data=04%7C01%7Cjeannot.langlois%40mitel.com%7Cec6c0c67ea5541181c3008d9a4e8cc9e%7C4bff5a2bb30d493981ff8f76138347df%7C1%7C0%7C637722142050345075%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Hv0Nfb6Ly28qNI3a3RxVH3qBQlehHJ9RTYpQdVZNUtM%3D&reserved=0 or Androidhttps://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fplay.google.com%2Fstore%2Fapps%2Fdetails%3Fid%3Dcom.github.android%26referrer%3Dutm_campaign%253Dnotification-email%2526utm_medium%253Demail%2526utm_source%253Dgithub&data=04%7C01%7Cjeannot.langlois%40mitel.com%7Cec6c0c67ea5541181c3008d9a4e8cc9e%7C4bff5a2bb30d493981ff8f76138347df%7C1%7C0%7C637722142050345075%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=UgD%2BH4kluBGCtwc7dGOrfufGt%2FMgQd7GbEt2Q1oGfYw%3D&reserved=0.

---

NOTE: This e-mail (including any attachments) is for the sole use of the intended recipient(s) and may contain information that is confidential and/or protected by legal privilege. Any unauthorized review, use, copy, disclosure or distribution of this e-mail is strictly prohibited. If you are not the intended recipient, please notify Mitel immediately and destroy all copies of this e-mail. Mitel does not accept any liability for breach of security, error or virus that may result from the transmission of this message.

[jeannotlanglois]

Attempting to submit bugfix in this issue #544 now...

[jeannotlanglois]

I've submitted pull request #563 ( https://github.com/SIPp/sipp/pull/563 ). Let me know if there is anything else I need to do. Cheers... :)

[wdoekes]

That fix worked. Thanks!