Orig append headers req - Not working

I have followed Orig append format and it does not work, Is there any use case or correct format to use this field?

As per documentation, below is what it says and it doesn’t seem to work, has anyone tried to test it or is it still not fully developed? looking for some feedback

Orig append headers req

Additional SIP headers that Yeti should add to request to the Gateway (in case of using Gateway as Originator of calls). Additional header fields are lines composed of a field name, followed by a colon (:), followed by a field body, and terminated by followin set of characters (‘rn’). A field name must be composed of printable US-ASCII characters (i.e., characters that have values between 33 and 126, inclusive), except colon. A field body may be composed of any US-ASCII characters, except for carriage return character (‘r’) and line feed character (‘n’). Format of headers: field-name1: field-value1**rn**field-name1: field-value2…, where *field-name1 and field-name2* - names of the custom fields, *field-value1 and field-value2* - values of the custom fields, **rn** - the carriage-return/line-feed pair.

Could you reproduce issue and provide pcap trace + logs with loglevel=3?

Have you tried applying to the Vendor end “Term” append headers req?

@dmitry.s I have put Append:1001**rn** in orig append headers req and I could see it in the log but also being removed. (I’ll also try to get pcap later)

Aug  5 09:23:49   sems[10860]: [10905/yeti:SqlCallProfile.cpp:515] DEBUG: aleg_sensor_level_id: 3
Aug  5 09:23:49   sems[10860]: [10905/yeti:SqlCallProfile.cpp:516] DEBUG: bleg_sensor_id: 1
Aug  5 09:23:49   sems[10860]: [10905/yeti:SqlCallProfile.cpp:517] DEBUG: bleg_sensor_level_id: 3
Aug  5 09:23:49   sems[10860]: [10905/yeti:SqlCallProfile.cpp:519] DEBUG: aleg_dtmf_send_mode_id: 1
Aug  5 09:23:49   sems[10860]: [10905/yeti:SqlCallProfile.cpp:520] DEBUG: bleg_dtmf_send_mode_id: 1
Aug  5 09:23:49   sems[10860]: [10905/yeti:SqlCallProfile.cpp:521] DEBUG: aleg_dtmf_recv_modes: 1
Aug  5 09:23:49   sems[10860]: [10905/yeti:SqlCallProfile.cpp:522] DEBUG: bleg_dtmf_recv_modes: 1
Aug  5 09:23:49   sems[10860]: [10905/yeti:SqlCallProfile.cpp:523] DEBUG: aleg_rtp_filter_inband_dtmf: 0
Aug  5 09:23:49   sems[10860]: [10905/yeti:SqlCallProfile.cpp:524] DEBUG: bleg_rtp_filter_inband_dtmf: 0
Aug  5 09:23:49   sems[10860]: [10905/yeti:SqlCallProfile.cpp:526] DEBUG: disable_early_media: 'no'
Aug  5 09:23:49   sems[10860]: [10905/yeti:SqlCallProfile.cpp:527] DEBUG: force_one_way_early_media 'no'
Aug  5 09:23:49   sems[10860]: [10905/yeti:SqlCallProfile.cpp:529] DEBUG: aleg_rel100_mode_id: 0
Aug  5 09:23:49   sems[10860]: [10905/yeti:SqlCallProfile.cpp:530] DEBUG: bleg_rel100_mode_id: 0
Aug  5 09:23:49   sems[10860]: [10905/yeti:SqlCallProfile.cpp:532] DEBUG: append_headers ''
Aug  5 09:23:49   sems[10860]: [10905/yeti:SqlCallProfile.cpp:533] DEBUG: append_headers_req ''
Aug  5 09:23:49   sems[10860]: [10905/yeti:SqlCallProfile.cpp:534] DEBUG: aleg_append_headers_reply ''
Aug  5 09:23:49   sems[10860]: [10905/yeti:SqlCallProfile.cpp:535] DEBUG: aleg_append_headers_req 'Append:1001**rn**'
Aug  5 09:23:49   sems[10860]: [10905/yeti:SqlCallProfile.cpp:537] DEBUG: radius_profile_id: 0
Aug  5 09:23:49   sems[10860]: [10905/yeti:SqlCallProfile.cpp:538] DEBUG: aleg_radius_acc_profile_id: 0
Aug  5 09:23:49   sems[10860]: [10905/yeti:SqlCallProfile.cpp:546] DEBUG: bleg_radius_acc_profile_id: 0

Aug  5 09:23:49   sems[10860]: [10905/yeti:SqlCallProfile.cpp:529] DEBUG: aleg_rel100_mode_id: 0
Aug  5 09:23:49   sems[10860]: [10905/yeti:SqlCallProfile.cpp:530] DEBUG: bleg_rel100_mode_id: 0
Aug  5 09:23:49   sems[10860]: [10905/yeti:SqlCallProfile.cpp:532] DEBUG: append_headers ''
Aug  5 09:23:49   sems[10860]: [10905/yeti:SqlCallProfile.cpp:533] DEBUG: append_headers_req ''
Aug  5 09:23:49   sems[10860]: [10905/yeti:SqlCallProfile.cpp:534] DEBUG: aleg_append_headers_reply ''
Aug  5 09:23:49   sems[10860]: [10905/yeti:SqlCallProfile.cpp:535] DEBUG: aleg_append_headers_req 'Append:1001**rn**'
Aug  5 09:23:49   sems[10860]: [10905/yeti:SqlCallProfile.cpp:537] DEBUG: radius_profile_id: 0
Aug  5 09:23:49   sems[10860]: [10905/yeti:SqlCallProfile.cpp:538] DEBUG: aleg_radius_acc_profile_id: 0
Aug  5 09:23:49   sems[10860]: [10905/yeti:SqlCallProfile.cpp:546] DEBUG: bleg_radius_acc_profile_id: 0
Aug  5 09:23:49   sems[10860]: [10905/yeti:SqlCallProfile.cpp:562] DEBUG: dynamic_field['auth_orig_ip']: 'gateway_public_ip' [CStr]

Aug  5 09:23:49   sems[10860]: [10905/yeti:SqlCallProfile.cpp:532] DEBUG: append_headers ''
Aug  5 09:23:49   sems[10860]: [10905/yeti:SqlCallProfile.cpp:533] DEBUG: append_headers_req ''
Aug  5 09:23:49   sems[10860]: [10905/yeti:SqlCallProfile.cpp:534] DEBUG: aleg_append_headers_reply ''
Aug  5 09:23:49   sems[10860]: [10905/yeti:SqlCallProfile.cpp:535] DEBUG: aleg_append_headers_req 'Append:1001**rn**'
Aug  5 09:23:49   sems[10860]: [10905/yeti:SqlCallProfile.cpp:537] DEBUG: radius_profile_id: 0
Aug  5 09:23:49   sems[10860]: [10905/yeti:SqlCallProfile.cpp:538] DEBUG: aleg_radius_acc_profile_id: 0
Aug  5 09:23:49   sems[10860]: [10905/yeti:SqlCallProfile.cpp:546] DEBUG: bleg_radius_acc_profile_id: 0
Aug  5 09:23:49   sems[10860]: [10905/yeti:SqlCallProfile.cpp:562] DEBUG: dynamic_field['auth_orig_ip']: 'gateway_public_ip' [CStr]

Aug  5 09:23:49   sems[10860]: [10905/yeti:SqlCallProfile.cpp:532] DEBUG: append_headers ''
Aug  5 09:23:49   sems[10860]: [10905/yeti:SqlCallProfile.cpp:533] DEBUG: append_headers_req ''
Aug  5 09:23:49   sems[10860]: [10905/yeti:SqlCallProfile.cpp:534] DEBUG: aleg_append_headers_reply ''
Aug  5 09:23:49   sems[10860]: [10905/yeti:SqlCallProfile.cpp:535] DEBUG: aleg_append_headers_req 'Append:1001**rn**'
Aug  5 09:23:49   sems[10860]: [10905/yeti:SqlCallProfile.cpp:537] DEBUG: radius_profile_id: 0
Aug  5 09:23:49   sems[10860]: [10905/yeti:SqlCallProfile.cpp:538] DEBUG: aleg_radius_acc_profile_id: 0

Aug  5 09:23:49   sems[10860]: [10905/yeti:SqlCallProfile.cpp:532] DEBUG: append_headers ''
Aug  5 09:23:49   sems[10860]: [10905/yeti:SqlCallProfile.cpp:533] DEBUG: append_headers_req ''
Aug  5 09:23:49   sems[10860]: [10905/yeti:SqlCallProfile.cpp:534] DEBUG: aleg_append_headers_reply ''
Aug  5 09:23:49   sems[10860]: [10905/yeti:SqlCallProfile.cpp:535] DEBUG: aleg_append_headers_req 'Append:1001**rn**'
Aug  5 09:23:49   sems[10860]: [10905/yeti:SqlCallProfile.cpp:537] DEBUG: radius_profile_id: 0
Aug  5 09:23:49   sems[10860]: [10905/yeti:SqlCallProfile.cpp:538] DEBUG: aleg_radius_acc_profile_id: 0

Aug  5 09:23:49   sems[10860]: [10869/yeti:SBCCallProfile.cpp:339] DEBUG: outbound_proxy = 'sip:sem_rtp_ip_leg'
Aug  5 09:23:49   sems[10860]: [10869/yeti:SBCCallProfile.cpp:601] DEBUG: append_headers: remove_empty_headers ''
Aug  5 09:23:49   sems[10860]: [10869/yeti:SBCCallProfile.cpp:601] DEBUG: append_headers_req: remove_empty_headers ''
Aug  5 09:23:49   sems[10860]: [10869/yeti:SBCCallProfile.cpp:601] DEBUG: aleg_append_headers_req: remove_empty_headers 'Append:1001**rn**'
Aug  5 09:23:49   sems[10860]: [10869/yeti:SBCCallProfile.cpp:601] DEBUG: aleg_append_headers_reply: remove_empty_headers ''
Aug  5 09:23:49   sems[10860]: [10869/core/sip/parse_uri.cpp:352] DEBUG: Converted URI port () to int (SipPort)
Aug  5 09:23:49   sems[10860]: [10869/yeti:ParamReplacer.cpp:667] DEBUG: from pattern replace: 'sip_usr_name <sip:sip_usr_name@$Oi>' -> 'sip_usr_name <sip:sip_usr_name@sems_rtp_ip>'

Aug  5 09:23:49   sems[10860]: [10869/yeti:SBCCallProfile.cpp:333] DEBUG: to = '<sip:dst_num@carrier_ip:SipPort>'
Aug  5 09:23:49   sems[10860]: [10869/yeti:SBCCallProfile.cpp:339] DEBUG: outbound_proxy = 'sip:carrier_int_ip'
Aug  5 09:23:49   sems[10860]: [10869/yeti:SBCCallProfile.cpp:601] DEBUG: append_headers: remove_empty_headers ''
Aug  5 09:23:49   sems[10860]: [10869/yeti:SBCCallProfile.cpp:601] DEBUG: append_headers_req: remove_empty_headers ''
Aug  5 09:23:49   sems[10860]: [10869/yeti:SBCCallProfile.cpp:601] DEBUG: aleg_append_headers_req: remove_empty_headers 'Append:1001**rn**'
Aug  5 09:23:49   sems[10860]: [10869/yeti:SBCCallProfile.cpp:601] DEBUG: aleg_append_headers_reply: remove_empty_headers ''
Aug  5 09:23:49   sems[10860]: [10869/core/sip/parse_uri.cpp:352] DEBUG: Converted URI port () to int (SipPort)

Append:1001\r\n

Thanks Dmitry but also i can see aleg_append_headers_req: remove_empty_headers 'Append:1001**rn**'

Any idea why it is removing? and also, or could Orig append header req be used to append values in sip header parameters?

Any idea why it is removing?

What removing?

Could you enter Append:1001\r\n in aleg_append_headers_req in web UI?

Sems is removing what I’m trying to append in the last line

Aug 13 13:17:54   sems[10860]: [10905/yeti:SqlCallProfile.cpp:535] DEBUG: aleg_append_headers_req 'Append:1001\r\n'
Aug 13 13:17:55   sems[10860]: [10905/yeti:SqlCallProfile.cpp:535] DEBUG: aleg_append_headers_req 'Append:1001\r\n'
Aug 13 13:17:55   sems[10860]: [10905/yeti:SqlCallProfile.cpp:535] DEBUG: aleg_append_headers_req 'Append:1001\r\n'
Aug 13 13:17:55   sems[10860]: [10905/yeti:SqlCallProfile.cpp:535] DEBUG: aleg_append_headers_req 'Append:1001\r\n'
Aug 13 13:17:55   sems[10860]: [10905/yeti:SqlCallProfile.cpp:535] DEBUG: aleg_append_headers_req 'Append:1001\r\n'
Aug 13 13:17:55   sems[10860]: [10866/yeti:ParamReplacer.cpp:667] DEBUG: aleg_append_headers_req pattern replace: 'Append:1001\r\n' -> 'Append:1001#015#012'
Aug 13 13:17:55   sems[10860]: [10866/yeti:SBCCallProfile.cpp:601] DEBUG: aleg_append_headers_req: remove_empty_headers 'Append:1001#015#012'
Aug 13 13:17:55   sems[10860]: [10866/yeti:ParamReplacer.cpp:667] DEBUG: aleg_append_headers_req pattern replace: 'Append:1001\r\n' -> 'Append:1001#015#012'
Aug 13 13:17:55   sems[10860]: [10866/yeti:SBCCallProfile.cpp:601] DEBUG: aleg_append_headers_req: remove_empty_headers 'Append:1001#015#012'

Yes, I can, here it is
image

As you can see the it is not appearing the leg a SIP header.

lebA - SIP Packet

2021/08/13 13:17:54.873976 lb_ip:port -> sem_ip:ports
INVITE sip:dst_num@lb.address:port SIP/2.0
Record-Route: <sip:lb.ip;lr;ftag=as459d0dbc>
Via: SIP/2.0/UDP lb.ip;branch=z9hG4bKdde7.b64e342c8776306fbbe65c44d10bbbe5.0
Via: SIP/2.0/UDP uac_ip:5127;received=uac_ip;branch=z9hG4bK77f05822;rport=5127
Max-Forwards: 69
From: "did" <sip:did@uac_nat_ip>;tag=as459d0dbc
To: <sip:dst_num@lb.address:port>
Contact: <sip:did@uac_ip:5127>
Call-ID: 287d308f4d60443f3a674b5311dc99fb@uac_nat_ip
CSeq: 102 INVITE
User-Agent: uac_ua 41.19.0.32
Date: Fri, 13 Aug 2021 03:17:54 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces, timer
Privacy: off
Remote-Party-ID: "did"<sip:did@lb.address>;privacy=off;screen=no
P-Asserted-Identity: "did" <sip:did@lb.address>
Content-Type: application/sdp
Content-Length: 283
X-ORIG-IP: uac_ip
X-ORIG-PORT: 5127
X-ORIG-PROTO: 1

v=0
o=root 1688953749 1688953749 IN IP4 uac_ip
s=UA PBX 1.6.2.6
c=IN IP4 uac_ip
t=0 0
m=audio 10190 RTP/AVP 8 0 3 101
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv

Leg b SIP Packet

2021/08/13 13:17:55.182425 sems_ip:ports -> ll_ip:port
INVITE sip:dst_num@car_ip:port SIP/2.0
Via: SIP/2.0/UDP sems_ip:ports;branch=z9hG4bKE3WsfaV8;rport
From: "did" <sip:did@sems_ip>;tag=12-6566A336-6115E4630002AF7A-5367C700
To: <sip:dst_num@car_ip:port>
CSeq: 10 INVITE
Call-ID: 12-3F52C9D4-6115E4630002AF80-5367C700
Route: <sip:ll_ip;lr>
Max-Forwards: 70
Privacy: off
P-Asserted-Identity: "did" <sip:did@lb.address>
User-Agent: yeti-switch 1.9.20
Content-Type: application/sdp
Contact: <sip:sems_ip:ports;transport=udp>
Content-Length: 281

v=0
o=yeti-switch 1688953749 1688953750 IN IP4 sems_ip
s=yeti-switch
t=0 0
m=audio 20929 RTP/AVP 0 18 101 8
c=IN IP4 sems_ip
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=rtpmap:101 telephone-event/8000
a=rtpmap:8 PCMA/8000
a=ptime:20
a=sendrecv

Orig append headers req appends headers to Requests sent to legA. There are no requests to legA on your trace.

How will Leg A get the Orig append headers req when the append is supposed to happen at SEMS or can the Loadbalancer is somehow getting the value from the WebUi?

Here is the call flow:
SIP Endpoint ----> LoadBalancer --LegA--> SEMS --LegB--> Carrier

In the above case, isn’t SEMS suppose to append the values set in WebUi of Orig append headers field for Leg B of sip INVITE?

How will Leg A get the Orig append headers req when the append is supposed to happen at SEMS or can the Loadbalancer is somehow getting the value from the WebUi?

SEMS will append headers to requests sent to LegA gateway within SIP dialog. For example BYE request.

Well that is what it is not doing at the moment as you can see in the SIP dialog of Leg A and it appears to be removed

Perhaps, if you could give an use case example to assert a billing code 1001 and a call is originated from an endpoint

could you read again:

Orig append headers req appends headers to Requests sent to legA. There are no requests to legA on your trace.

There are no requests from SEMS to legA gateway in your trace.

It is not clear what you want to configure. Do you want to add some header to request? to response? on lega? or legb?

I would like to configure to add some header to the request on legB
Would that be possible?

set *TERM APPEND HEADERS REQ=Append:1001\r\n at termination gateway.

Sorry, I mean to say to add some header to the request on legA of Origination gateway
For eg: How to add a header in the request in the call flow below
Endpoint → LoadBalancer → SEM

Configure your endpoint to add header because endpoind sends request in this case. But I have no idea why you need this, looks like useless.

It is actually a very useful use case when you have scenarios like the one below:

5 Origination Gateways and 1 Termination Gateway
3 our 5 origination gateways are required to send additional sip headers in leg A so the termination gateway can have specific header like P-asserted-identity and privacy header, etc carried forward from Leg A. otherwise the termination gateway will drop the call.

Currently, we have to duplicate termination gateways for every origination gateway
1 origination gateway = 1 same termination gateway and use term append header req in leg B, which is a system overkill

As discussed internally, we will look forward to you adding this feature in the future.