Manipulating contacts header results in a malformed SIP packet

List overview All Threads
Download

newer

older

Transformations - urlencode

Pike Module Clarification

Andrew White

19 Mar 2020 19 Mar '20

4:42 a.m.

Hi all, Hope everyone is well, and looking forward to seeing you all whenever Kamailio World ends up being! I’m currently dealing with an issue which I’m unsure if it’s due to my own implementation, or a bug. When attempting to manipulate the Contact header via app_ruby, the SIP message I send ends up being malformed. Here’s the code I’m using: def replace_contact_header(uri) #KSR::HDR.remove("Contact") if KSR::HDR.is_present('Contact') > 0 #KSR::HDR.append("Contact: #{uri}\r\n") KSR::HDR.rmappend("Contact", "Contact: #{uri}\r\n") end Note that I have tried both rmappend and the commented out functions too. I call this with a custom built URI, such as <61400123123(a)kamailio.test.uconnected.com.au <mailto:61400123123@kamailio.test.uconnected.com.au>>. This function is called just before a KSR::TM.t_relay(). Here’s the result I get watching from tshark (some info scrubbed for privacy): Record-Route: <sip:1.2.3.4;lr;ftag=e3p42efd3635HH;vst=AAAAAAAAAAAAAAAAAAAAAAoUXVFHDQAAs83AEGwAAFgwCQA8QY3RlZC5jb20uYXU-;did=927.f0f2> … Call-ID: 3de29646-e423-1238-e712-023563fb337c CSeq: 17736747 INVITE sip:4.5.6.7:5060;alias=10.100.1.1~5060~1Content-Type: application/sdp Content-Length: 483 Contact: <sip:61400123123@kamailio.test.uconnected.com.au> In this case, 4.5.6.7 is the PBX I made the call from (and the value of the original Contact header), and 1.2.3.4 is what kamailio.test.uconnected.com.au <http://kamailio.test.uconnected.com.au/> resolves to, and is this Kamailio instance. Here’s a copy of the same thing when I don’t call my replace_contact_header function and t_relay: Record-Route: <sip:1.2.3.4;lr;ftag=j6jebCSa5Qap6c;vst=AAAAAAAAAAAAAAAAAAAAAAoUXVND38dTgwEGEAEGwAAFgwCQA8Fdn83lZC5jb20uYXU-;did=827.40b> ... Call-ID: 249571c5-e91a-ae91-6d8e-023563fb337c CSeq: 17735867 INVITE Contact: <sip:4.5.6.7:5060;alias=10.100.1.1~5060~1> Content-Type: application/sdp Content-Length: 483 Given the relative simplicity of the function, I have to assume this is an error with how the function is manipulating the existing Contact header? It seems that the “Contact: <“ part of the header is being removed as well as the “>\r\n", but the rest being left. I’m currently using commit 283e468401d809ca9b71368c32badf3a70d48b8b <https://github.com/kamailio/kamailio/commit/283e46> on Amazon Linux 2, which is CentOS/RHEL based. Thanks! Andrew

Attachments:

attachment.html (text/html — 5.6 KB)

Show replies by date

Alex Balashov

19 Mar 19 Mar

4:49 a.m.

Hi Andrew, The Content-Length header, if present, is the header that must appear last in a SIP message, per RFC 3261 § 7.5 So, any method of manipulation of the Contact must manipulate it in place. A common favourite - if you absolutely must manipulate the Contact - is to substitute it. You can also insert the header at an arbitrary position: https://kamailio.org/docs/modules/5.3.x/modules/textopsx.html#textopsx.f.in… But a better question might perhaps be: why do you want to manipulate the Contact header? While it may perhaps be legitimately necessary occasionally, my finding has been that in 99% of cases, it's the wrong way to solve a problem. -- Alex On Thu, Mar 19, 2020 at 12:42:51PM +1100, Andrew White wrote:

...

_______________________________________________ Kamailio (SER) - Users Mailing List sr-users(a)lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

-- 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/

Andrew White

5:53 a.m.

Hey Alex, Thanks so much for the prompt reply! The substitute and arbitrary position options look useful. In these cases, will Kamailio automatically recalculate the Content-Length, or do I need to manually rewrite this somehow? I did read that in researching before emailing, from similar thread you responded to about 5 years ago! In this case, we have a specific upstream provider who reject our Contact header in the normal format we send, and require it to be in a specific format. As such, I can manipulate the header on our PBX or on Kamailio. Given Kamailio is aware of the provider we’re sending to and the PBX is not, it seems simpler to do on Kamailio. Thanks! Andrew

...

On 19 Mar 2020, at 12:49 pm, Alex Balashov <abalashov(a)evaristesys.com> wrote: Hi Andrew, The Content-Length header, if present, is the header that must appear last in a SIP message, per RFC 3261 § 7.5 So, any method of manipulation of the Contact must manipulate it in place. A common favourite - if you absolutely must manipulate the Contact - is to substitute it. You can also insert the header at an arbitrary position: https://kamailio.org/docs/modules/5.3.x/modules/textopsx.html#textopsx.f.in… <https://kamailio.org/docs/modules/5.3.x/modules/textopsx.html#textopsx.f.insert_hf_value> But a better question might perhaps be: why do you want to manipulate the Contact header? While it may perhaps be legitimately necessary occasionally, my finding has been that in 99% of cases, it's the wrong way to solve a problem. -- Alex On Thu, Mar 19, 2020 at 12:42:51PM +1100, Andrew White wrote:

Hi all, Hope everyone is well, and looking forward to seeing you all whenever Kamailio World ends up being! I’m currently dealing with an issue which I’m unsure if it’s due to my own implementation, or a bug. When attempting to manipulate the Contact header via app_ruby, the SIP message I send ends up being malformed. Here’s the code I’m using: def replace_contact_header(uri) #KSR::HDR.remove("Contact") if KSR::HDR.is_present('Contact') > 0 #KSR::HDR.append("Contact: #{uri}\r\n") KSR::HDR.rmappend("Contact", "Contact: #{uri}\r\n") end Note that I have tried both rmappend and the commented out functions too. I call this with a custom built URI, such as <61400123123(a)kamailio.test.uconnected.com.au <mailto:61400123123@kamailio.test.uconnected.com.au> <mailto:61400123123@kamailio.test.uconnected.com.au <mailto:61400123123@kamailio.test.uconnected.com.au>>>. This function is called just before a KSR::TM.t_relay(). Here’s the result I get watching from tshark (some info scrubbed for privacy): Record-Route: <sip:1.2.3.4;lr;ftag=e3p42efd3635HH;vst=AAAAAAAAAAAAAAAAAAAAAAoUXVFHDQAAs83AEGwAAFgwCQA8QY3RlZC5jb20uYXU-;did=927.f0f2 <sip:1.2.3.4;lr;ftag=e3p42efd3635HH;vst=AAAAAAAAAAAAAAAAAAAAAAoUXVFHDQAAs83AEGwAAFgwCQA8QY3RlZC5jb20uYXU-;did=927.f0f2>> … Call-ID: 3de29646-e423-1238-e712-023563fb337c CSeq: 17736747 INVITE sip:4.5.6.7:5060;alias=10.100.1.1~5060~1Content-Type: <sip:4.5.6.7:5060;alias=10.100.1.1~5060~1Content-Type:> application/sdp Content-Length: 483 Contact: <sip:61400123123@kamailio.test.uconnected.com.au <sip:61400123123@kamailio.test.uconnected.com.au>> In this case, 4.5.6.7 is the PBX I made the call from (and the value of the original Contact header), and 1.2.3.4 is what kamailio.test.uconnected.com.au <http://kamailio.test.uconnected.com.au/> <http://kamailio.test.uconnected.com.au/ <http://kamailio.test.uconnected.com.au/>> resolves to, and is this Kamailio instance. Here’s a copy of the same thing when I don’t call my replace_contact_header function and t_relay: Record-Route: <sip:1.2.3.4;lr;ftag=j6jebCSa5Qap6c;vst=AAAAAAAAAAAAAAAAAAAAAAoUXVND38dTgwEGEAEGwAAFgwCQA8Fdn83lZC5jb20uYXU-;did=827.40b <sip:1.2.3.4;lr;ftag=j6jebCSa5Qap6c;vst=AAAAAAAAAAAAAAAAAAAAAAoUXVND38dTgwEGEAEGwAAFgwCQA8Fdn83lZC5jb20uYXU-;did=827.40b>> ... Call-ID: 249571c5-e91a-ae91-6d8e-023563fb337c CSeq: 17735867 INVITE Contact: <sip:4.5.6.7:5060;alias=10.100.1.1~5060~1 <sip:4.5.6.7:5060;alias=10.100.1.1~5060~1>> Content-Type: application/sdp Content-Length: 483 Given the relative simplicity of the function, I have to assume this is an error with how the function is manipulating the existing Contact header? It seems that the “Contact: <“ part of the header is being removed as well as the “>\r\n", but the rest being left. I’m currently using commit 283e468401d809ca9b71368c32badf3a70d48b8b <https://github.com/kamailio/kamailio/commit/283e46 <https://github.com/kamailio/kamailio/commit/283e46>> on Amazon Linux 2, which is CentOS/RHEL based. Thanks! Andrew

_______________________________________________ Kamailio (SER) - Users Mailing List sr-users(a)lists.kamailio.org <mailto:sr-users@lists.kamailio.org> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>

-- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/ <http://www.evaristesys.com/>, http://www.csrpswitch.com/ <http://www.csrpswitch.com/> _______________________________________________ Kamailio (SER) - Users Mailing List sr-users(a)lists.kamailio.org <mailto:sr-users@lists.kamailio.org> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>

Alex Balashov

6:01 a.m.

Hi Andrew, On Thu, Mar 19, 2020 at 01:53:53PM +1100, Andrew White wrote:

...

The substitute and arbitrary position options look useful. In these cases, will Kamailio automatically recalculate the Content-Length, or do I need to manually rewrite this somehow?

The Content-Length pertains to the length of an (optional) encapsulated message body only, and not to the length of the SIP message as such, and therefore does not apply to any of its headers. Encapsulated bodies are used to transport messages of another protocol inside SIP. In SIP land, the most common encapsulated payload is the SDP payload, e.g. ... Content-Type: application/sdp Content-Length: xxx [SDP of length xxx goes here] If an encapsulated body is not present, Content-Length is still mandatory but must be set to 0.

...

I did read that in researching before emailing, from similar thread you responded to about 5 years ago! In this case, we have a specific upstream provider who reject our Contact header in the normal format we send, and require it to be in a specific format. As such, I can manipulate the header on our PBX or on Kamailio. Given Kamailio is aware of the provider we’re sending to and the PBX is not, it seems simpler to do on Kamailio.

The problem with that philosophy is that Contact is fundamentally a creature of the user agent, not of the proxy, so the proxy shouldn't be manipulating it. Any time you manipulate it, you run the risk that a message reliant on that value will be sent in the other direction (the PBX), and the PBX says, "What?! That's not what I sent!" If that happens, you rapidly descend into an unmanageable hellscape of stateful management of this value so as to fool the PBX into thinking that you didn't change it, and so forth. This should really be done on the calling UA if at all possible. Ideally you could somehow tweak the PBX to send the value in the desired format to begin with. Kamailio provides a lot of tools to shoot onesself in the foot with. It makes things technically possible that shouldn't necessarily be done just because they are possible. IMHO. :-) -- 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/

Andrew White

6:36 a.m.

Hey Alex, Thanks, that does make a lot of sense. I’ve certainly gotten myself into some situations before using the powerful and dangerous toolset that is Kamailio! I will look into the PBX doing this, however it’s a bit tricky, as it’s not aware of the specific requirements of the next hop, or even what the next hop is. Regardless though, I’m not completely sure if the location of the Content-Length header is the issue here. I’ve manipulated both Content-Type and Content-Length to the bottom of the headers with the following code just to see if this does solve the problem, and it doesn’t appear to: replace_contact_header(“<sip:61400123123@kamailio.test.uconnected.com.au>") cl = KSR::PV.gete("$cl") cT = KSR::PV.gete("$cT") KSR::HDR.remove("Content-Type") if KSR::HDR.is_present('Content-Type') > 0 KSR::HDR.append("Content-Type: #{cT}\r\n") KSR::HDR.remove("Content-Length") if KSR::HDR.is_present('Content-Length') > 0 KSR::HDR.append("Content-Length: #{cl}\r\n") Record-Route: <sip:1.2.3.4;lr;ftag=e4ZXUgGac1e8K;vst=AAAAAAAAAAAAAAAAAAAAAAoUXVFHDQAVd93nfAEGwAAFgwCQA8QY3RlZC5jb20uYXU-;did=923.76f1> ... Call-ID: 814ec57f-e433-83ca-6d8e-023563fb337c CSeq: 17740239 INVITE sip:4.5.6.7:5060;alias=10.100.1.1~5060~1Contact: <sip:61400123123@kamailio.test.uconnected.com.au <sip:61400123123@kamailio.test.uconnected.com.au>> Content-Type: application/sdp Content-Length: 483 Given this is now in line with RFC location of the Content-Length, doesn’t this indicate an issue beyond correct placement of this header? It still seems like the Contact header is still being removed incorrect by the function. FYI I ran a test call with just the KSR::HDR.remove("Contact") call, and still saw the issue: Record-Route: <sip:1.2.3.4;lr;ftag=j8428v06y47jj;vst=AAAAAAAAAAAAAAAAAAAAAAoUXVFHDQGfdDfEGEAEGwAAFgwCQA8QY3RlZC5jb20uYXU-;did=ead.25c1> Call-ID: 0e349984-b83a-1238-6d8e-023563fb337c CSeq: 17740572 INVITE sip:4.5.6.7:5060;alias=10.100.1.1~5060~1Content-Type: application/scp Content-Length: 483 Thanks! Andrew

...

On 19 Mar 2020, at 2:01 pm, Alex Balashov <abalashov(a)evaristesys.com> wrote: Hi Andrew, On Thu, Mar 19, 2020 at 01:53:53PM +1100, Andrew White wrote:

The substitute and arbitrary position options look useful. In these cases, will Kamailio automatically recalculate the Content-Length, or do I need to manually rewrite this somehow?

Henning Westerholt

23 Mar 23 Mar

8:24 p.m.

Hi Alex, to refresh this old discussion, are you sure that the requirement that the Content-Length header needs to be at the end of the SIP message is enforced or even defined? If you use old Kamailio standard modules like "path" it places its header directly at the end of the message, after the Content-Length. I also failed to find a MUST in the section 7.5 of the RFC and also in 20.14. about the header position. Cheers, Henning -- Henning Westerholt – https://skalatan.de/blog/ Kamailio services – https://gilawa.com -----Original Message----- From: sr-users <sr-users-bounces(a)lists.kamailio.org> On Behalf Of Alex Balashov Sent: Thursday, March 19, 2020 2:49 AM To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org> Subject: Re: [SR-Users] Manipulating contacts header results in a malformed SIP packet Hi Andrew, The Content-Length header, if present, is the header that must appear last in a SIP message, per RFC 3261 § 7.5 So, any method of manipulation of the Contact must manipulate it in place. A common favourite - if you absolutely must manipulate the Contact - is to substitute it. You can also insert the header at an arbitrary position: https://kamailio.org/docs/modules/5.3.x/modules/textopsx.html#textopsx.f.in… But a better question might perhaps be: why do you want to manipulate the Contact header? While it may perhaps be legitimately necessary occasionally, my finding has been that in 99% of cases, it's the wrong way to solve a problem. -- Alex On Thu, Mar 19, 2020 at 12:42:51PM +1100, Andrew White wrote:

...

Hi all, Hope everyone is well, and looking forward to seeing you all whenever Kamailio World ends up being! I’m currently dealing with an issue which I’m unsure if it’s due to my own implementation, or a bug. When attempting to manipulate the Contact header via app_ruby, the SIP message I send ends up being malformed. Here’s the code I’m using: def replace_contact_header(uri) #KSR::HDR.remove("Contact") if KSR::HDR.is_present('Contact') > 0 #KSR::HDR.append("Contact: #{uri}\r\n") KSR::HDR.rmappend("Contact", "Contact: #{uri}\r\n") end Note that I have tried both rmappend and the commented out functions too. I call this with a custom built URI, such as <61400123123(a)kamailio.test.uconnected.com.au <mailto:61400123123@kamailio.test.uconnected.com.au>>. This function is called just before a KSR::TM.t_relay(). Here’s the result I get watching from tshark (some info scrubbed for privacy): Record-Route: <sip:1.2.3.4;lr;ftag=e3p42efd3635HH;vst=AAAAAAAAAAAAAAAAAAAAAAoUXVFHDQ AAs83AEGwAAFgwCQA8QY3RlZC5jb20uYXU-;did=927.f0f2> … Call-ID: 3de29646-e423-1238-e712-023563fb337c CSeq: 17736747 INVITE sip:4.5.6.7:5060;alias=10.100.1.1~5060~1Content-Type: application/sdp Content-Length: 483 Contact: <sip:61400123123@kamailio.test.uconnected.com.au> In this case, 4.5.6.7 is the PBX I made the call from (and the value of the original Contact header), and 1.2.3.4 is what kamailio.test.uconnected.com.au <http://kamailio.test.uconnected.com.au/> resolves to, and is this Kamailio instance. Here’s a copy of the same thing when I don’t call my replace_contact_header function and t_relay: Record-Route: <sip:1.2.3.4;lr;ftag=j6jebCSa5Qap6c;vst=AAAAAAAAAAAAAAAAAAAAAAoUXVND38 dTgwEGEAEGwAAFgwCQA8Fdn83lZC5jb20uYXU-;did=827.40b> ... Call-ID: 249571c5-e91a-ae91-6d8e-023563fb337c CSeq: 17735867 INVITE Contact: <sip:4.5.6.7:5060;alias=10.100.1.1~5060~1> Content-Type: application/sdp Content-Length: 483 Given the relative simplicity of the function, I have to assume this is an error with how the function is manipulating the existing Contact header? It seems that the “Contact: <“ part of the header is being removed as well as the “>\r\n", but the rest being left. I’m currently using commit 283e468401d809ca9b71368c32badf3a70d48b8b <https://github.com/kamailio/kamailio/commit/283e46> on Amazon Linux 2, which is CentOS/RHEL based. Thanks! Andrew

...

_______________________________________________ Kamailio (SER) - Users Mailing List sr-users(a)lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

-- 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/ _______________________________________________ Kamailio (SER) - Users Mailing List sr-users(a)lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Sergey Safarov

19 Mar 19 Mar

7:10 a.m.

Looks as not expected here sip:4.5.6.7:5060;alias=10.100.1.1~5060~1Content-Type: application/sdp About contact header. Yes it is really important header. If your carrier want specific Contact header format, then I recommend try use other provider. Contact header used also for RURI headers. So you cannot simple change Contact. Kamailio is very good SP proxy. For you will more simple invite Kamailio tech guy to configure inter-working with this specific carrier. On Thu, Mar 19, 2020 at 4:43 AM Andrew White <andrew(a)uconnected.com.au> wrote:

...

… Call-ID: 3de29646-e423-1238-e712-023563fb337c CSeq: 17736747 INVITE sip:4.5.6.7:5060;alias=10.100.1.1~5060~1Content-Type: application/sdp Content-Length: 483 Contact: <sip:61400123123@kamailio.test.uconnected.com.au> In this case, 4.5.6.7 is the PBX I made the call from (and the value of the original Contact header), and 1.2.3.4 is what kamailio.test.uconnected.com.au resolves to, and is this Kamailio instance. Here’s a copy of the same thing when I don’t call my replace_contact_header function and t_relay: Record-Route: < sip:1.2.3.4;lr;ftag=j6jebCSa5Qap6c;vst=AAAAAAAAAAAAAAAAAAAAAAoUXVND38dTgwEGEAEGwAAFgwCQA8Fdn83lZC5jb20uYXU-;did=827.40b

... Call-ID: 249571c5-e91a-ae91-6d8e-023563fb337c CSeq: 17735867 INVITE Contact: <sip:4.5.6.7:5060;alias=10.100.1.1~5060~1> Content-Type: application/sdp Content-Length: 483 Given the relative simplicity of the function, I have to assume this is an error with how the function is manipulating the existing Contact header? It seems that the “Contact: <“ part of the header is being removed as well as the “>\r\n", but the rest being left. I’m currently using commit 283e468401d809ca9b71368c32badf3a70d48b8b <https://github.com/kamailio/kamailio/commit/283e46> on Amazon Linux 2, which is CentOS/RHEL based. Thanks! Andrew _______________________________________________ Kamailio (SER) - Users Mailing List sr-users(a)lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Bastian Triller

20 Mar 20 Mar

2:01 p.m.

You're using set_contact_alias(), which already changes the Contact header. Try msg_apply_changes() before your 2nd Contact header change. On Thu, Mar 19, 2020 at 5:11 AM Sergey Safarov <s.safarov(a)gmail.com> wrote:

...

_______________________________________________ Kamailio (SER) - Users Mailing List sr-users(a)lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

1708

days inactive

1712

days old

sr-users@lists.kamailio.org

Manage subscription

7 comments

5 participants

tags (0)

participants (5)

Alex Balashov
Andrew White
Bastian Triller
Henning Westerholt
Sergey Safarov