Modification of To-Tag in 200 OK for CANCEL request

[alexey-khabulyak]

Hi. I have simple call flow:

 UAS        PROXY        UAS
1 |   INVITE  |           |
  |---------->|           |
2 |    100    |           |
  |<----------|           |
3 |           |   INVITE  |
  |           |---------->|
4 |           |    100    |
  |           |<----------|
5 |           |    180    |
  |           |<----------|
6 |    180    |           |
  |<----------|           |
7 |           |    183    |
  |           |<----------|
8 |    183    |           |
  |<----------|           |
9 |  CANCEL   |           |
  |---------->|           |
10|           |  CANCEL   |
  |           |---------->|
11|    200    |           |
  |<----------|           |
12|           |    200    |
  |           |<----------|
13|           |    487    |
  |           |<----------|
14|           |    ACK    |
  |           |---------->|
15|    487    |           |
  |<----------|           |
16|    ACK    |           |
  |---------->|           |

One of our customers complains that TO-TAGs in 183 (packet 8) and 200(packet 11) are not equal(their devices see 2 to-tag during 1 dialog). I found in RFC 3261that it's ok(https://datatracker.ietf.org/doc/html/rfc3261#section-16.10).
183 is forwarded from UAS(UAS sets to-tag) and 200 is generated by Kamailio. This is why to-tags in 183 and 200 are not equal.

Is it possible to use to-tag from master branch(ofc if we have received a reply from UAS and we have this tag)?

[miconda]

The proxy generates the CANCEL, therefore it sets its own To-tag. In the case of single branch forwarding, what you want may work, but parallel/serial forking is a common scenario and then the INVITE has many outgoing branches, each of them responding with different To-tag, it such case the UA receives many To-tags as well and therefore it should cope with them and be RFC3261 compliant.

As a possible workaround, for the simple case of sending out a single branch, directly to UAS, maybe you can get it working by storing the R-URI/$ru (eventually also the dst uri/$du) of the outgoing INVITE in htable by call-id and when CANCEL is processed use them to send it out in stateless mode (with forward()). The INVITE transaction won't be cancelled by kamailio, but the UAS will respond with 487 that will terminate it.

Given the above remarks, I won't keep this feature request open, because seems of very little usefulness. Obviously, a pull request adding such behaviour will be considered for merging (it has to be configurable via modparam). If no registered developed commits to add it and wants this item open here, it will be closed soon.

[alexey-khabulyak]

Got it. Thnx for you answer!