### Description
Upon interfacing with a specific carrier’s cloud relay service, upon the termination of the call by the called party after the phone rings, the tag value within the To header of the 408 response from the cloud relay side is altered. When Kamailio relays this 408 response to FreeSwitch, the sofia-sip protocol stack employed by FreeSwitch perceives it as a distinct dialog and does not promptly conclude the call. Given that the carrier’s personnel may lack the capability or the inclination to effect changes, we are looking to accommodate this scenario on the Kamailio side. Upon receipt of the 408 response from the carrier, we will determine if there has been a modification to the tag value in the To header. If such a change is detected, prior to forwarding the 408 response to FreeSwitch, we will rectify the tag value in the To header of the 408 response to correspond with the tag value from the 18x signaling messages.
Our system : OS: Rocky Linux release 9.3 (Blue Onyx) Kamailo vesion 5.7.3
### Troubleshooting
#### Reproduction In the kamailio.cfg, invoke a Python script within the onreply_route[MANAGE_REPLY] block The following two scenarios both result in content-related errors: 1. First, the ‘To’ header field is removed using msg.call_function(‘remove_hf’, ‘To’), and then the modified ‘To’ header field is added using msg.call_function(‘append_hf’, sip_to). 2. The tag value in the ‘To’ header field is changed back to the original value using msg.call_function(‘replace_hdrs’, toTag, originalToTag).
#### Log Messages Dec 4 13:45:00 sipp102 ./kamailio[391888]: INFO: {2 92091734 INVITE a18e6868-2ca5-123e-a394-00163e347028} app_python3 [mod_Logger.c:172]: logger_LM_INFO(): recv 408, sip_to_field_val = sip:130679333xx@39.106.31.1xx:5060;tag=3b47-eb967d112cba8f7d5eb856259e056294 toUri = sip:130679333xx@39.106.31.1xx:5060 toTag = tag=3b47-eb967d112cba8f7d5eb856259e056294 originalToTag = tag=as73409c31 Dec 4 13:45:00 sipp102 ./kamailio[391888]: CRITICAL: {2 92091734 INVITE a18e6868-2ca5-123e-a394-00163e347028} <core> [core/mem/q_malloc.c:515]: qm_free(): BUG: bad pointer 0x7f60c10a88a0 (out of memory block!) called from app_python3: python_msgobj.c: msg_call_function(258) - ignoring
#### SIP Traffic Received 408:
Forwarded 408:

SIP Traffic Received 408: 
why modify the to-tag? should not
Closed #4050 as completed.
First, the title of issues on tracker has to be like subject line on an email, pretty short.
Then, the tracker is of reporting bugs in C code once it is know to be so. For discussing about how to use Kamailio and build its configuration file, to figure out if you use it correctly or not (for example msg object has been deprecated (and removed) in favour of KEMI functions), use the sr-users@lists.kamailio.org mailing list.
First, in the kamailio.cfg configuration file, within the onreply_route[MANAGE_REPLY], determine if it is a 408 response to an INVITE. Then, use python_exec to call the py script of app_python3. In the py script, check if the To tag value in the 408 response has changed compared to the previously cached To tag value. If it has changed, use msg.call_function(‘replace’, toTag, originalToTag) to modify the To tag value in the 408 response to the original value when forwarding the 408. By performing this operation, the following error was found in Kamailio:
Dec 4 13:45:00 sipp102 ./kamailio[391888]: CRITICAL: {2 92091734 INVITE a18e6868-2ca5-123e-a394-00163e347028} [core/mem/q_malloc.c:515]: qm_free(): BUG: bad pointer 0x7f60c10a88a0 (out of memory block!) called from app_python3: python_msgobj.c: msg_call_function(258) - ignoring
I’m currently uncertain whether the issue lies in my usage or if there’s a related bug in Kamailio. Could I trouble you all for some advice?