You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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:
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.
The text was updated successfully, but these errors were encountered: