topos: remove contact header for CANCEL,BYE,PRACK REQUESTS

[emvondo]

Pre-Submission Checklist

• Commit message has the format required by CONTRIBUTING guide
• Commits are split per component (core, individual modules, libs, utils, ...)
• Each component has a single commit (if not, squash them into one commit)
• No commits to README files for modules (changes must be done to docbook files
  in doc/ subfolder, the README file is autogenerated)

Type Of Change

• Small bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds new functionality)
• Breaking change (fix or feature that would change existing functionality)

Checklist:

• PR should be backported to stable branches
• Tested changes locally
• Related to issue #XXXX (replace XXXX with an open issue number)

Description

According to RFC 3261 & 3262 CANCEL , PRACK and BYE requests and their associated responses (most of them) must not have contact header

[miconda]

Thanks for the PR!

I couldn't find an explicit statement about CANCEL and Contact header in the RFC, I haven't searched much, though. IBM site claims it is a SHOULD NOT:

• https://www.ibm.com/support/pages/apar/PM77734

I will think how this could be added with some flexibility around it.

[henningw]

@miconda I think this is the relevant table in section 20 link

Seems to be pretty clear, if I read it correctly.

      -: The header field is not applicable.

   "Not applicable" means that the header
   field MUST NOT be present in a request.  If one is placed in a
   request by mistake, it MUST be ignored by the UAS receiving the
   request.  Similarly, a header field labeled "not applicable" for a
   response means that the UAS MUST NOT place the header field in the
   response, and the UAC MUST ignore the header field in the response.

      Header field          where   proxy ACK BYE CAN INV OPT REG
      ___________________________________________________________
      Contact                 R            o   -   -   m   o   o
      Contact                1xx           -   -   -   o   -   -
      Contact                2xx           -   -   -   m   o   o
      Contact                3xx      d    -   o   -   o   o   o
      Contact                485           -   o   -   o   o   o

[miconda]

@henningw: ok -- I made it configurable just in case other methods have same requirements, or one needs the old behaviour for whatever reason.

At the end it didn't break the behaviour due to the must ignore statement:

   If one is placed in a
   request by mistake, it MUST be ignored by the UAS receiving the
   request.

Closing this one.

[henningw]

Thanks, great solution.