[DOC] Wrong assumption about direction in the ng-control-protocol documentation

[vingarzan]

rtpengine version the issue has been seen with

N/A

Used distribution and its version

N/A

Linux kernel version used

N/A

CPU architecture issue was seen on (see uname -m)

None

Expected behaviour you didn't see

No response

Unexpected behaviour you saw

https://rtpengine.readthedocs.io/en/latest/ng_control_protocol.html#answer-message

It is claimed that "It doesn’t make sense to include the direction key in the answer message". However, when a call goes multiple times through the same SIP proxy, while we can discriminate on the SDP offer through the use of direction (2 different processing elements are triggered), if we abide by the documentation then then rtpengine probably can't identify the SDP answer correctly and only applies changes once.

This is a common case for example with a P-CSCF in IMS, which might handle in the same instance both the caller and the called party, yet each have completely separate processing applied. The Kamailio implementation does not seem to have a problem in sending the direction and, upon testing with my own client, it is effective to use it in the SDP answer.

Steps to reproduce the problem

Apply twice the SDP-offer to a call, with different directions. Then apply SDP-answer twice without direction -> only the first one works. But if we add the Direction parameter in the SDP-answer, everything works just fine. Hence the documentation is confusing.

Additional program output to the terminal or logs illustrating the issue

Anything else?

No response

[vingarzan]

If someone could confirm this, I'd happily provide a PR to fix the documentation. Else I would appreciate a reply if I'm missing something, yet this seems a feature in the rtpengine itself, so a "bug" in the documentation.

[rfuchs]

Apply twice the SDP-offer to a call, with different directions. Then apply SDP-answer twice without direction -> only the first one works.

This is entirely expected and how it's supposed to work. A second offer with the same call ID and the same tags would overwrite attributes selected in the first offer.

The correct way to do this is to either use different call IDs or different from/to-tags (if this is for a separate call leg of the same call going through the same rtpengine, which is what you seem to be doing), or to use the via-branch argument (if this is for a branched offer that would then get a single answer for one of the branches).

Trying to achieve what you're describing by putting direction in the answers will not work correctly as you still have just a single call with a single set of ports and you can't run two call legs through that. Things would break even worse if other attributes are present in the SDPs, such as encryption. So don't do that.

[vingarzan]

Technically I have the same call-leg, with the same call-id, from/to-tags.

I didn't know about the via-branch being a solution here. Unfortunately, since in my case I'm generating that when I would forward the requests out, would be usable but with extra complications (or could pop/use the 2nd Via on responses). But I think you are nudging me into a solution where I would simply augment the call-id with my discriminating indicator, since my node is the only one which has to be consistent with that parameter.

Many thanks for confirming that this is not how I should be using it! But, like I said, it seems to work for now 😝, at least for my basic transcoding purposes ... still, not a great idea to depend on it if it's not supposed to officially work like that.