Skip to content

Headers transit ​

By default Yeti are not relaying any headers from one call leg to another. Headers transit mechanism allows to configure such relaying.

After the routing, YETI performs filtering twice: for the origination Gateway and for the termination Gateway.

Gateway's parameter Transit headers from origination describes the transfer of headers from LegA to LegB, the parameter Transit headers from termination - from LegB to LegA.

For example, an incoming call arrives via the Gateway A and terminates via the Gateway B with the corresponding settings.

Gateway A:​
  • Transit headers from origination = X-TEST-H, X-YETI*
  • Transit headers from termination = X-YETI-AUTH-11
Gateway B:​
  • Transit headers from origination = X-TEST-H
  • Transit headers from termination = X-YETI-AUTH*

Then in case of receiving INVITE from Gateway A with such headers:

X-TEST-H: 123
X-TEST-H2: 000
X-YETI-H1: 321
X-YETI-AUTH-HEADER: 333

It will be filtered sequentially twice (with the filter X-TEST-H, X-YETI* and X-TEST-H) and, after filtering, INVITE will be formed to the Gateway B with such headers:

X-TEST-H: 123

Thus, in case if from Gateway B will be received 200OK message with headers:

X-YETI-AUTH-324: 333
X-YETI-AUTH-11: 11
X-YETI-TEST: 333

The headers will be filtered twice (by the filter X-YETI-AUTH*, and then by the X-YETI-AUTH-11 filter) and after filtering, a 200OK message will be generated to Gateway A with the following headers:

X-YETI-AUTH-11: 11