[SR-Users] remove_hf() leaves junk in the headers?

[Oded Arbel]

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 at example.com972515340014>;tag=as0c32fd2e
---8<---

Any suggestions?

On Sun, May 26, 2019 at 7:10 PM Karsten Horsmann <khorsmann at gmail.com> wrote:
>
> 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_va
>
> Cheers
> Karsten Horsmann
>
>
> Oded Arbel <odeda at cloudonix.io> schrieb am So., 26. Mai 2019, 17:02:
>>
>> 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 at 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 at example.com:5066>;tag=as0bcee217
>> To: <sip:972522353283 at 10.20.30.40:5060>
>> Contact: <sip:972515340014 at 10.90.80.71:5066>
>> Call-ID: 722299dc15aad53d28172d433e8665f4 at 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 at 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 at 10.20.30.40:5060>
>> Contact: <sip:972515340014 at 10.90.80.71:5066>
>> Call-ID: 7b20ba5a549f6f886c22985146765736 at 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 at lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users



-- 
Oded Arbel
CTO, VP R&D
Cloudonix