Le 26 mai 2019 à 17:03, Oded Arbel &lt;odeda(a)cloudonix.io&gt; a écrit : I'm trying to rewrite the `From` header in an invite going out to an external system (*), by calling remove_hf("From"); followed by append_hf("From: <some value>\r\n"); but the result is an invalid SIP message, because apparently after `remove_hf()` finishes, it leaves the content of $fU in place of the `From` header - just the raw text, without a header name or even a "\r\n" - and that eats the next header line and breaks the INVITE. Here is how the INVITE originally looks (without either `remove_hf()` or `append_hf()`): ---8<--- INVITE sip:972522353283@10.20.30.40:5060 SIP/2.0 Record-Route: <sip:10.90.80.70;lr;did=649.f0b> Via: SIP/2.0/UDP 10.90.80.70:5060;branch=z9hG4bK6188.ff5c4fd855bd2970fdf32d4807b114c2.0 Via: SIP/2.0/UDP 10.90.80.71:5066;received=10.90.80.71;branch=z9hG4bK581897a4;rport=5066 Max-Forwards: 69 From: <sip:972515340014@example.com:5066>;tag=as0bcee217 To: <sip:972522353283@10.20.30.40:5060> Contact: <sip:972515340014@10.90.80.71:5066> Call-ID: 722299dc15aad53d28172d433e8665f4@10.90.80.71:5066 CSeq: 102 INVITE User-Agent: Asterisk PBX 14.7.2 Date: Sun, 26 May 2019 14:42:52 GMT Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE Supported: replaces X-CID: ad199638-4df3-4aef-81f1-1b50581032a7 Content-Type: application/sdp Content-Length: 280 v=0 o=root 817636675 817636675 IN IP4 10.50.60.70 s=Asterisk PBX 14.7.2 c=IN IP4 10.50.60.70 t=0 0 m=audio 39064 RTP/AVP 8 0 18 9 a=maxptime:60 a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:18 G729/8000 a=rtpmap:9 G722/8000 a=sendrecv a=rtcp:39065 a=ptime:20 ---8<--- and here is another call with the same setup, with just `remove_hf("From");` being invoked (without calling `append_hf()` - this is just for reproduction): ---8<--- INVITE sip:972522353283@10.20.30.40:5060 SIP/2.0 Record-Route: <sip:10.90.80.70;lr;did=f45.91b1> Via: SIP/2.0/UDP 10.90.80.70:5060;branch=z9hG4bK024d.2690ebf7a809edca2208e6b2561ccf9e.0 Via: SIP/2.0/UDP 10.90.80.71:5066;received=10.90.80.71;branch=z9hG4bK79ae3073;rport=5066 Max-Forwards: 69 972515340014To: <sip:972522353283@10.20.30.40:5060> Contact: <sip:972515340014@10.90.80.71:5066> Call-ID: 7b20ba5a549f6f886c22985146765736@10.90.80.71:5066 CSeq: 102 INVITE User-Agent: Asterisk PBX 14.7.2 Date: Sun, 26 May 2019 14:44:20 GMT Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE Supported: replaces X-CID: ffbb4ac1-3a0f-4dd6-9ce9-7ad24361081a Content-Type: application/sdp Content-Length: 280 v=0 o=root 509740923 509740923 IN IP4 10.50.60.70 s=Asterisk PBX 14.7.2 c=IN IP4 10.50.60.70 t=0 0 m=audio 39102 RTP/AVP 8 0 18 9 a=maxptime:60 a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:18 G729/8000 a=rtpmap:9 G722/8000 a=sendrecv a=rtcp:39103 a=ptime:20 ---8<--- As you can see, the `From` header is indeed gone, but it left the $fU just before the `To` header. WTF? I'm running Kamailio 5.2.2 built locally. Notes: *) the problem I'm trying to solve is that I can't get my Asterisk installation to generate the `From` header I want, the reason is out of scope of this question, so I'm sending custom SIP headers over to Kamaiio and I want to rewrite the header in Kamailio to the "correct" value. -- Oded Arbel _______________________________________________ Kamailio (SER) - Users Mailing List sr-users(a)lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Hi Oded, I would better use uac_replace_from like described in the Kamailio wiki. (link below) This function takes also care of rewriting it back AFAIK. http://www.kamailio.org/wiki/tutorials/faq/main#how_to_set_different_header… Cheers Karsten Horsmann Oded Arbel &lt;odeda(a)cloudonix.io&gt; schrieb am So., 26. Mai 2019, 17:02: _______________________________________________ Kamailio (SER) - Users Mailing List sr-users(a)lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Make sure you have the right reversion/cookie options set,

and that you only call uac_replace_from() once in the message processing loop,

and that you don’t modify From any other way besides that concurrently.

> On May 26, 2019, at 1:52 PM, Oded Arbel &lt;odeda(a)cloudonix.io&gt; wrote: > > I have just tried to use `uac_replace_from()` (which I wasn't familiar > with - we haven't used the uac module in our setup up till now, and > from its description I didn't think it would be appropriate as we are > not initiating sessions from Kamailio). > > We the following code in place, instead of the `remove_hf()` and `append_hf()`: > > ---8<--- > uac_replace_from("sip:$var(from_user)@$var(from_domain)"); > ---8<--- > > The headers are no longer broken, but do not look OK - I still have > another copy of the $fU stuck somewhere in the middle. The `From` > header no looks as thus: > > ---8<--- > From: <sip:972515340014@example.com972515340014>;tag=as0c32fd2e > ---8<---

On Sun, May 26, 2019 at 09:27:01PM +0300, Oded Arbel wrote: Sorry, that wasn't a very clear response on my part. I was referring to these parameters: https://kamailio.org/docs/modules/5.2.x/modules/uac.html#uac.p.restore_mode https://kamailio.org/docs/modules/5.2.x/modules/uac.html#uac.p.restore_dlg The way the uac_replace_{to,from}() mechanism works is that given an INVITE going from A to B, and passing through proxy P, P will modify the header in flight and store the original value in some fashion. Taking advantage of its role in series to the path of any replies or new in-dialog requests going from B back to A, P will statefully revert the header value to the stored original, so that A is none the wiser as to the fact that the header has been modified. Meanwhile, B will continue to see the modified value at all times. This removes the problem of the proxy P modifying these values en route in a way that gives rise to an rejection from A -- "Hey, I didn't send that!" The settings in this area mostly relate to the way in which this original value is stored. There are two ways. One is to throw it into a Record-Route header parameter, taking advantage of the proxy's role (if record_route() is called/an RR header is added upon processing the initial INVITE) in the entire life cycle of the dialog. The proxy will intercept the original value in the RR header (encoded or encrypted somehow) and revert it in messages going back to "A". The other way is to use the dialog module's runtime memory of dialogs, if enabled. This method is perhaps a bit more sanitary, but has the disadvantage of not being particularly stateless or restart-persistent. -- Alex