### Description
I used sip_p_charging_vector() function of siputils with flag f (remove + generate). This function works fine if call is received without a P-Charging-Vector and only generate needs to be done. But if the INVITE already contains a P-Charging-Vector and this vector needs to be removed and replaced by a new generated P-Charging-Vector the output is messed up. The sip_p_charging_vector() function with flag r (remove) works fine too. P-Charging-Vector is removed if INVITE contains one. So for me this looks like an issue with the combination of remove + generate.
See SIP Traffic attached. The "old" P-Charging-Vector is not deleted and additionaly instead of a new P-Charging-Vector the "old" P-Charging-Vector is added again above SDP. Also some part of the next line "Session-Exp" is added and "TH: dih".
----- TH: dih icid-value=0d702d06-5700-103e-00-00-00-10-6b-03-dd-04;icid-generated-at=213.xxx.xxx.xxx Session-Exp -----
### Troubleshooting
#### Reproduction
It looks like the issue is triggered always a p-charging-vector is received by kamailio and sip_p_charging_vector() with flag f is called.
#### Log Messages
<!-- Check the syslog file and if there are relevant log messages printed by Kamailio, add them next, or attach to issue, or provide a link to download them (e.g., to a pastebin site). -->
``` (paste your log messages here) ```
#### SIP Traffic
``` **This message is received by kamailio (Incoming):** INVITE sip:+49xxxxxxxx;npdi;rn=+49xxxxxxxx@bob.com:5060;user=phone SIP/2.0 Via: SIP/2.0/UDP 213.xxx.xxx.xxx:5060;branch=z9hG4bK08Bf3722bac16f3e05b From: sip:+43xxxxxxxx@alice.com;user=phone;tag=gK085abca7 To: sip:+49xxxxxxxx0@92.xxx.xxx.xxx:5060;user=phone Call-ID: 168341746_132086108@213.xxx.xxx.xxx CSeq: 373279 INVITE Max-Forwards: 67 Allow: INVITE,ACK,CANCEL,BYE,REGISTER,REFER,INFO,SUBSCRIBE,NOTIFY,PRACK,UPDATE,OPTIONS,MESSAGE,PUBLISH Accept: application/sdp, application/isup, application/dtmf, application/dtmf-relay, multipart/mixed Contact: sip:+43xxxxxxxx@213.xxx.xxx.xxx:5060 P-Asserted-Identity: sip:+43xxxxxxxx@alice.com:5060;user=phone Supported: timer,100rel,histinfo P-Charging-Vector: icid-value=0d702d06-5700-103e-00-00-00-10-6b-03-dd-04;icid-generated-at=213.xxx.xxx.xxx Session-Expires: 1800 Min-SE: 90 Content-Length: 236 Content-Disposition: session; handling=required Content-Type: application/sdp
v=0 o=Sonus_UAC 278609 22801 IN IP4 213.xxx.xxx.xxx s=SIP Media Capabilities c=IN IP4 213.xxx.xxx.xxx t=0 0 m=audio 29020 RTP/AVP 8 101 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendrecv a=ptime:20
**This message is send out by kamailio (outgoing):** INVITE sip:+49xxxxxxxx;npdi;rn=+49xxxxxxxx@bob.com:5060;user=phone SIP/2.0 Record-Route: sip:172.xxx.xxx.xxx;r2=on;lr=on;ftag=gK085abca7 Record-Route: sip:92.xxx.xxx.xxx9;r2=on;lr=on;ftag=gK085abca7 Via: SIP/2.0/UDP 172.xxx.xxx.xxx;branch=z9hG4bKc451.940fa2c220f96c1ef968de3c156db262.0 Via: SIP/2.0/UDP 213.xxx.xxx.xxx:5060;TH=div;branch=z9hG4bK08Bf3722bac16f3e05b From: sip:+43xxxxxxxx@alice.com;user=phone;tag=gK085abca7 To: sip:+49xxxxxxxx@92.xxx.xxx.xxx:5060;user=phone Call-ID: 168341746_132086108@213.xxx.xxx.xxx CSeq: 373279 INVITE Max-Forwards: 66 Allow: INVITE,ACK,CANCEL,BYE,REGISTER,REFER,INFO,SUBSCRIBE,NOTIFY,PRACK,UPDATE,OPTIONS,MESSAGE,PUBLISH Accept: application/sdp, application/isup, application/dtmf, application/dtmf-relay, multipart/mixed Contact: sip:+43xxxxxxxx@213.xxx.xxx.xxx:5060 P-Asserted-Identity: sip:+43xxxxxxxx@alice.com:5060;user=phone Supported: timer,100rel,histinfo P-Charging-Vector: icid-value=0d702d06-5700-103e-00-00-00-10-6b-03-dd-04;icid-generated-at=213.xxx.xxx.xxx Session-Expires: 1800 Min-SE: 90 Content-Length: 252 Content-Disposition: session; handling=required Content-Type: application/sdp **_TH: dih icid-value=0d702d06-5700-103e-00-00-00-10-6b-03-dd-04;icid-generated-at=213.xxx.xxx.xxx Session-Exp_** v=0 o=Sonus_UAC 278609 22801 IN IP4 92.xxx.xxx.xxx s=SIP Media Capabilities c=IN IP4 92.xxx.xxx.xxx t=0 0 m=audio 34622 RTP/AVP 8 101 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendrecv a=rtcp:34623 a=ptime:20 ```
### Additional Information
``` version: kamailio 5.8.2 (x86_64/linux) 3fa5f4 flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, MEM_JOIN_FREE, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST, HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_SEND_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: 3fa5f4 compiled on 15:54:29 Jul 22 2024 with gcc 10.2.1 ```
* **Operating System**:
``` Debian GNU/Linux 11 5.10.0-26-amd64 #1 SMP Debian 5.10.197-1 (2023-09-29) x86_64 GNU/Linux ```
Are you using topoh module? If yes, can you try without it and see if P-Charging-Vector operations are ok?
Hi Daniel,
yes, topoh is active. But without topoh the problem is more or less the same. Exept the line "TH: dih" is missing:
``` INVITE sip:+49xxxxxxxx;npdi;rn=+49xxxxxxxx@bob.com;user=phone SIP/2.0 Record-Route: sip:62.xxx.xxx.xxx:5070;r2=on;lr;reinv_vbd=del;BT2C=inat+;flag=udp Record-Route: sip:62.xxx.xxx.xxx;r2=on;lr;reinv_vbd=del;BT2C=inat+;flag=udp Via: SIP/2.0/UDP 62.xxx.xxx.xxx:5070;branch=z9hG4bK7b0f.6d6fba114474d518861d077151ab15c4.0 Via: SIP/2.0/UDP 62.xxx.xxx.xxx:6038;branch=z9hG4bKv1vb4a2060dlmghpcp00.1 Max-Forwards: 62 Session-Expires: 1800;refresher=uac Min-SE: 1800 Supported: timer,histinfo To: sip:+49xxxxxxxx@bob.com;user=phone From: "+49xxxxxxxx" sip:+49xxxxxxxx@alice.com;user=phone;tag=3930969934-318037072 Call-ID: 157063545-3930969934-2127799619@DFRA4-TSBC01.mydomain.com P-Asserted-Identity: sip:+49xxxxxxxx@alice.com;user=phone CSeq: 1 INVITE Allow: PUBLISH,MESSAGE,UPDATE,PRACK,SUBSCRIBE,REFER,INFO,NOTIFY,REGISTER,OPTIONS,BYE,INVITE,ACK,CANCEL Contact: sip:62.xxx.xxx.xxx:6038;transport=udp Content-Type: application/sdp Accept: application/sdp P-Charging-Vector: icid-value=oj25k1o6ihb23s06ehc83ro5o9ce7rtd93s23slupg10;icid-generated-at=10.xxx.xxx.xxx Content-Length: 273
v=0 o=DFRA4-TSBC01 21989954271838208 11720080987521025 IN IP4 62.xxx.xxx.xxx s=sip call c=IN IP4 62.xxx.xxx.xxx t=0 0 m=audio 64822 RTP/AVP 0 8 18 101 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendrecv a=ptime:20
INVITE sip:+49xxxxxxxx;npdi;rn=+49xxxxxxxx@bob.com;user=phone SIP/2.0 Record-Route: sip:172.xxx.xxx.xxx;r2=on;lr=on;ftag=3930969934-318037072 Record-Route: sip:92.xxx.xxx.xxx;r2=on;lr=on;ftag=3930969934-318037072 Record-Route: sip:62.xxx.xxx.xxx:5070;r2=on;lr;reinv_vbd=del;BT2C=inat+;flag=udp Record-Route: sip:62.xxx.xxx.xxx;r2=on;lr;reinv_vbd=del;BT2C=inat+;flag=udp Via: SIP/2.0/UDP 172.xxx.xxx.xxx;branch=z9hG4bK7b0f.2f311cd0af50a9dfee475476beb76ccb.0 Via: SIP/2.0/UDP 62.xxx.xxx.xxx:5070;branch=z9hG4bK7b0f.6d6fba114474d518861d077151ab15c4.0 Via: SIP/2.0/UDP 62.xxx.xxx.xxx:6038;branch=z9hG4bKv1vb4a2060dlmghpcp00.1 Max-Forwards: 61 Session-Expires: 1800;refresher=uac Min-SE: 1800 Supported: timer,histinfo To: sip:+49xxxxxxxx@bob.com;user=phone From: "+49xxxxxxxx" sip:+49xxxxxxxx@alice.com;user=phone;tag=3930969934-318037072 Call-ID: 157063545-3930969934-2127799619@DFRA4-TSBC01.mydomain.com P-Asserted-Identity: sip:+49xxxxxxxx@alice.com;user=phone CSeq: 1 INVITE Allow: PUBLISH,MESSAGE,UPDATE,PRACK,SUBSCRIBE,REFER,INFO,NOTIFY,REGISTER,OPTIONS,BYE,INVITE,ACK,CANCEL Contact: sip:62.xxx.xxx.xxx:6038;transport=udp Content-Type: application/sdp Accept: application/sdp P-Charging-Vector: icid-value=oj25k1o6ihb23s06ehc83ro5o9ce7rtd93s23slupg10;icid-generated-at=10.xxx.xxx.xxx Content-Length: 310 icid-value=oj25k1o6ihb23s06ehc83ro5o9ce7rtd93s23slupg10;icid-generated-at=10.xxx.xxx.xxx Content-L v=0 o=DFRA4-TSBC01 21989954271838208 11720080987521025 IN IP4 92.xxx.xxx.xxx s=sip call c=IN IP4 92.xxx.xxx.xxx t=0 0 m=audio 26708 RTP/AVP 0 8 18 101 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendrecv a=rtcp:26709 a=ptime:20 ```
I just wanted to be sure that topos is not creating any issue, because `TH` should never leave Kamailio as a header. As it looks right now, some lenght is not computed right, because it adds more data than needs, which was in the buffer at some point in time.
In this example, the incorrect length also included part of the SDP. This generated an additional error message because there was a duplicate Content-Length header :
``` INVITE sip:+49xxxxxxxxxx@bob.com;transport=udp;user=phone SIP/2.0 Call-ID: 02817-MD-4463d585-52e48e045@c4swlmgc2.alice.com Contact: sip:212.xxx.xxx.xxx:5060 Content-Type: application/sdp CSeq: 1133935713 INVITE From: "0xxxxxxxxxx" sip:+49xxxxxxxxxx@alice.com;user=phone;tag=02817-RD-4463d586-4f6eb2e21 Max-Forwards: 66 Record-Route: sip:212.xxx.xxx.xxx:5060;user=00048987;lr;Cpkt=S;C=on-cirpack Route: sip:bob.com;transport=udp;lr Supported: histinfo To: sip:+49xxxxxxxxxx@bob.com;user=phone Via: SIP/2.0/UDP 212.xxx.xxx.xxx:5060;branch=z9hG4bK-SBUV-07e9a5a9-120bc337 P-Early-Media: supported User-Agent: Cirpack Allow: INVITE,ACK,UPDATE,BYE,CANCEL,OPTIONS P-Asserted-Identity: "0xxxxxxxxxx"sip:+49xxxxxxxxxx@alice.com;user=phone P-Charging-Vector: icid-value="IBCF-1-172198114070166333715934";orig-ioi=3GPP-UTRAN Content-Length: 248
v=0 o=anonymous 172198114002 172198114002 IN IP4 212.xxx.xxx.xxx s=SIP Call c=IN IP4 212.xxx.xxx.xxx t=0 0 m=audio 31096 RTP/AVP 8 101 b=AS:82 a=rtpmap:8 PCMA/8000/1 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:20 a=sendrecv
INVITE sip:+49xxxxxxxxxx@bob.com;transport=udp;user=phone SIP/2.0 Record-Route: sip:172.xxx.xxx.xxx;r2=on;lr=on;ftag=02817-RD-4463d586-4f6eb2e21 Record-Route: sip:92.xxx.xxx.xxx;r2=on;lr=on;ftag=02817-RD-4463d586-4f6eb2e21 Call-ID: 02817-MD-4463d585-52e48e045@c4swlmgc2.alice.com Contact: sip:212.xxx.xxx.xxx:5060 Content-Type: application/sdp CSeq: 1133935713 INVITE From: "0xxxxxxxxx" sip:+49xxxxxxxxx@alice.com;user=phone;tag=02817-RD-4463d586-4f6eb2e21 Max-Forwards: 65 Record-Route: sip:212.xxx.xxx.xxx:5060;user=00048987;lr;Cpkt=S;C=on-cirpack Supported: histinfo To: sip:+49xxxxxxxxx@bob.com;user=phone Via: SIP/2.0/UDP 172.xxx.xxx.xxx;branch=z9hG4bKfc7e.32b1e1b8641843f6f10ffaa78b49ad63.0 Via: SIP/2.0/UDP 212.xxx.xxx.xxx:5060;branch=z9hG4bK-SBUV-07e9a5a9-120bc337 User-Agent: Cirpack Allow: INVITE,ACK,UPDATE,BYE,CANCEL,OPTIONS P-Asserted-Identity: "0xxxxxxxxx"sip:+49xxxxxxxxx@alice.com;user=phone P-Charging-Vector: icid-value="IBCF-1-172198114070166333715934";orig-ioi=3GPP-UTRAN Content-Length: 258 icid-value="IBCF-1-172198114070166333715934";orig-ioi=3GPP-UTRAN Content-Length: 248
v=0 o=a v=0 o=anonymous 172198114002 172198114002 IN IP4 92.xxx.xxx.xxx s=SIP Call c=IN IP4 92.xxx.xxx.xxx t=0 0 m=audio 40848 RTP/AVP 8 101 b=AS:82 a=rtpmap:8 PCMA/8000/1 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendrecv a=rtcp ```
Apart from the incorrect length, it seems strange to me that the PCV is being copied at all. If I understand the F-flag correctly, the old header should be deleted and a new one generated.
`Manage the P-Charging-Vector header (RFC7315). The flags can be: 'r' - remove; 'g' - generate; 'f' - force (remove + generate).`
The documentation says "remove + generate", so I'd say this is then buggy behavior.
I looked briefly at the code and ... it's a bit questionable if it would work but in some certain combinations of calls.
1. To either replace or remove the header is conditioned additionally by `_siputils_pcv_status == PCV_PARSED`. From what I could deduce, that's not set, unless you tried to get that header and it was parsed... I have no idea why replace/remove would be conditioned by that. (But when it works, then removes both the value and the header name, I think.)
2. Adding the header is done with a lump at a position which seems a bit... arbitrary to me: `msg->parsed - msg->buf`, so where the parsing stopped before. Lumps were always scary to me, so I'd guess maybe some deleted headers pushes it in the message body. Also: the added part is just the header value, skipping the header name part, albeit that's written in a buffer. So matches what you see in the message. I'm wondering how it would work for a simple generate...
3. The last issue is why it's the same value, which I don't know if it still matters given 1&2. There are some parsing-back extra complications after generating, so that might be the issue. Or lumps issues again?
Maybe @neutrino38 can pitch in?
P.S. I'd suggest an alternative path, to only generate a PCV value in C-code and return it to the script (or if there is a UUID/unique/etc generator function in the script that'd be enough), then use other script functions to add the header with that value wherever you want, remove older values, etc.
I might have found the cause for the behavior. The `msg->eoh` value is probably wrong when adding the new P-Charging-Vector lump after removing the previous one. It must be recalculated in `parse_headers`. I have created a branch for testing the fix. As the code was edited on a theory basis, can someone please test if it works? Thank you.
https://github.com/lachbaer/kamailio/commit/39f786dcd2f2f061d27d93ec403972d5...
The bug was in the whole handling of the internal buffer for the P-Charging-Vector handler. One buffer for the original and the rewritten header, but handled in similar but different ways. Took some time to find that!
I have added a new buffer when creating a new PCV header. The original buffer is for the header's body as it is put there in `sip_parse_charging_vector`. Additionally I have altered the lump handling. It should have worked the way it was, but now the lumps are chained in case the PCV is replaced.
The code is tested and works in a test environment. Night's calling, PR will come the next days.
This issue is stale because it has been open 6 weeks with no activity. Remove stale label or comment or this will be closed in 2 weeks.
Closed #3929 as completed.
-
Daniel-Constantin Mierla -
Dragos Vingarzan
-
Eik Rentzow
-
github-actions[bot]
-
Michael
-
Victor Seva