Yeti Switch

Appearance

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