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