26 May
2019
26 May
'19
5:01 p.m.
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
26 May
26 May
5:31 p.m.
Hello,
Have you tried using uac_replace_from()??
https://www.kamailio.org/docs/modules/5.2.x/modules/uac.html#idm1043096996
On Sun, May 26, 2019 at 08:02 Oded Arbel <odeda(a)cloudonix.io> wrote:
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
5:36 p.m.
Don’t think using remove_hf to rewrite the From is a good idea
Use uac_replace_from.
Le 26 mai 2019 à 17:03, Oded Arbel
<odeda(a)cloudonix.io> 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
6:07 p.m.
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 <odeda(a)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@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
7:52 p.m.
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<---
Any suggestions?
On Sun, May 26, 2019 at 7:10 PM Karsten Horsmann <khorsmann(a)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…
Cheers
Karsten Horsmann
Oded Arbel <odeda(a)cloudonix.io> schrieb am So., 26. Mai 2019, 17:02:
--
Oded Arbel
CTO, VP R&D
Cloudonix
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
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users 
7:57 p.m.
Contrary to the prime facie interpretation of its name, the ‘uac’ module does not in fact
provide a UAC, or the ability to initiate sessions, just some functionality that strays
from proxy orthodoxy and ventures into the realm of things only UAs are formally entitled
to do. This is the case with the naming of many Kamailio modules.
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.
—
Sent from mobile, with due apologies for brevity and errors.
On May 26, 2019, at 1:52 PM, Oded Arbel
<odeda(a)cloudonix.io> 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<---
Any suggestions?
On Sun, May 26, 2019 at 7:10 PM Karsten Horsmann
<khorsmann(a)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…
Cheers
Karsten Horsmann
Oded Arbel <odeda(a)cloudonix.io> schrieb am So., 26. Mai 2019, 17:02:
--
Oded Arbel
CTO, VP R&D
Cloudonix
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
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
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
8:27 p.m.
On Sun, May 26, 2019 at 8:59 PM Alex Balashov <abalashov(a)evaristesys.com> wrote:
Make sure you have the right reversion/cookie options
set,
I'm not sure what that means...
and that you only call uac_replace_from() once in the
message processing loop,
There is only one call in the code to `uac_replace_from()` which is
run once (and only for INVITE messages).
and that you don’t modify From any other way besides
that concurrently.
Aha! and that was apparently the problem. I have another place in the
code (probably from an earlier work trying to do the same thing) that
had:
$fU = $hdr(custom-caller-id-header)
Removing that solved the problem. I'm guessing its the same issue that
I had with the `remove_hf()` method, that removed `From` but somehow
somewhere got the value that was meant to replace $fU written into an
arbitrary location in the headers buffer.
Thanks for the support!
> On May 26, 2019, at 1:52 PM, Oded Arbel
<odeda(a)cloudonix.io> 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<---
--
Oded Arbel
27 May
27 May
1:01 a.m.
On Sun, May 26, 2019 at 09:27:01PM +0300, Oded Arbel wrote:
On Sun, May 26, 2019 at 8:59 PM Alex Balashov
<abalashov(a)evaristesys.com> 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
--
Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
Make sure you have the right reversion/cookie
options set,
I'm not sure what that means... 
9:37 a.m.
Hello Alex,
just a small comment:
If you use an appropriate db_mode for the dialog module storage then
this mode is also restart-persistent. I did some improvements here
recently, the fix was also back-ported.
Cheers,
Henning
Am 27.05.19 um 01:01 schrieb Alex Balashov:
On Sun, May 26, 2019 at 09:27:01PM +0300, Oded Arbel
wrote:
--
Henning Westerholt - https://skalatan.de/blog/
Kamailio services - https://skalatan.de/services
On Sun, May 26, 2019 at 8:59 PM Alex Balashov
<abalashov(a)evaristesys.com> 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
Make sure you have the right reversion/cookie
options set,
I'm not sure what that means...
1797
days inactive
1798
days old
8 comments
6 participants
participants (6)
-
Alex Balashov -
Henning Westerholt -
Joel Serrano -
Karsten Horsmann -
Nicolas Breuer -
Oded Arbel