I noticed that the scenarios which received the 200 OK to hangup a call caused sippy_cup to exit abruptly. I verified sipp (I am using v3.7.2) crashes with a segmentation violation. I also noticed that Wireshark was reporting invalid SIP message headers for the ACK, BYE and 200 OK BYE messages. I compiled a very simple call start/answer scenarios using sippy_cup and decided to run sipp manually. Using this method I was also capable of reproducing the problem.
I am familiar with sipp so I noticed there is a [routes] element after the Content-Length header in the xml file generated by sippy_cup. I removed the [routes] element from the XML scenario files and sipp no longer terminated due a segmentation fault. I also verified that after making that change to the ACK messages, Wireshark no longer complained about invalid SIP message headers.
I check the template for every one of those messages in scenario.rb. and found them to have [routes] at the end of the SIP message header. All of these messages specify a Content-Length header of 0 which probably explains why sipp crashes while parsing the 200 OK BYE.
Here are the exact lines in scenario.rb:
ACK - line 458
BYE - line 573
200 OK BYE - line 605
I know that SIP header parameters can be in any order but I don't think the Route-Record header can be after Content-Length especially if the message length is 0. I looked in a few places for information about this but couldn't verify it.
I noticed that the scenarios which received the 200 OK to hangup a call caused sippy_cup to exit abruptly. I verified sipp (I am using v3.7.2) crashes with a segmentation violation. I also noticed that Wireshark was reporting invalid SIP message headers for the ACK, BYE and 200 OK BYE messages. I compiled a very simple call start/answer scenarios using sippy_cup and decided to run sipp manually. Using this method I was also capable of reproducing the problem.
I am familiar with sipp so I noticed there is a [routes] element after the Content-Length header in the xml file generated by sippy_cup. I removed the [routes] element from the XML scenario files and sipp no longer terminated due a segmentation fault. I also verified that after making that change to the ACK messages, Wireshark no longer complained about invalid SIP message headers.
I check the template for every one of those messages in scenario.rb. and found them to have [routes] at the end of the SIP message header. All of these messages specify a Content-Length header of 0 which probably explains why sipp crashes while parsing the 200 OK BYE. Here are the exact lines in scenario.rb: