LUA normalization script - change c= in SDP

[Keith Abbott]

Good day,

I am just getting my feet wet in LUA normalization scripting for cisco.

Im attempting to modify a private IP that appears in the c= header of the SDP (for a remote user), with the public-facing IP.

The background for this is that we are interfacing with redsky for e911 for our work-from-home users, via an internet SIP trunk configured on call manager. Test calls connect but have no audio. Redsky indicates we need to present the public IP in the SDP, instead of the private IP, and since cubes arent used, etc, the only way I can see to do this is a LUA script to change those entries.

The first script Im trying is the most basic I can come up with (The IPs have been changed to protect the guilty - theyre not even possible mostly!)

M = {}
trace.enable()
function M.inbound_INVITE(msg)
local sdp = msg:getSdp()
if sdp
then
local InIP4_line = sdp:getLine("c=","IN IP4 172.172.172")
if InIP4_line
then
--Replace ip v4 addr with pub-facing IP.
--escaped using % when using gsub.
InIP4_line = InIP4_line:gsub("172.172.172", "333.331.341.341")
sdp = sdp:modifyLine("c=", "172.17.102.58", InIP4_line)
msg:setSdp(sdp)
end
end
end
return M

When using this script, making a test call from my home jabber phone, with my vpn IP matching the 172.17.102.58, then gathering logs from RTMT, I see the call - the c= record matches the c=IN IP4 172.17.102.58  in the 'Before outbound SIP Normalization' in the logs, but always shows 'After inbound (no change) SIP Normalization'

So I am presuming Im making some basic mistake that perhaps someone can point out to me.

After that if you could give me a hint on generalizing the private IP so it just looks at the 172.17.x.x and replaces it with the entire public IP that would be great!

Thanks for your help

wolf

[Keith Abbott]

Note.

the line

sdp = sdp:modifyLine("c=", "172.17.102.58", InIP4_line)

should read:

sdp = sdp:modifyLine("c=", "172.172.172.58", InIP4_line)

and all references to 172.172.172 - should indicate 172.172.172.58

so the correct script is:

M = {}
trace.enable()
function M.inbound_INVITE(msg)
local sdp = msg:getSdp()
if sdp
then
local InIP4_line = sdp:getLine("c=","IN IP4 172.172.172.58")
if InIP4_line
then
--Replace ip v4 addr with pub-facing IP.
--escaped using % when using gsub.
InIP4_line = InIP4_line:gsub("172.172.172.58", "333.331.341.341")
sdp = sdp:modifyLine("c=", "172.172.172.58", InIP4_line)
msg:setSdp(sdp)
end
end
end
return M

[Keith Abbott]

ok - reviewing the logs I found this error:

//SIPLua/Error/SipContexts_removeContext: call contexts object is missing

The only reference I can find for it suggests increasing the memory and number of lines allowed for the script - which I increased to 1000 KB and 2000 instructions - which seems more than enough to me.

Can anyone provide input?

thanks

[Keith Abbott]

also another very general question:
if the invite is coming from a remote call manager phone (jabber in this case) into call manager - then out the trunk, is that characterized as an inbound_invite or outbound_invite?

So HomeJabberUserOnCiscoCM --> CiscoCM --> CiscoTrunkwNormalizeScript --> Internet --> Redsky

[Keith Abbott]

Finally, Ive put some trace.format statements in the script to try to help troubleshoot it:

M = {}
trace.enable()
function M.inbound_INVITE(msg)
trace.format("message captured: ",msg)
local sdp = msg:getSdp()
trace.format("sdp captured: ",sdp)
if sdp
then
trace.format("------ IN IF Then ------")

as examples - output from those should show up in log files, correct? so I should see a log entry that says "------ IN IF Then ------"?

Because I dont see any of them - further suggesting the 'object missing' error is killing the script before it runs

[Omygod380]

How did you make out with this? I need to create a script to change the SDP header because of NAT with our internal/external IPs. I am very new to LUA scripting as well, any insights/resources would be greatly appreciated. 

[Keith Abbott]

Hi 380,

We did eventually get things going but note - most of our changes needed to be on the firewall side, and based on your description I think that is true with you as well. If its a case of NAT getting in the way I think you probably need to ensure your ALG is enabled on your firewall. Im not sure your situation but it was complicated for us as we had devices front-ending remote users - into our network - through the corp fw - then back out to internet cloud provider. So you will need to be sure you understand the data path to know where ALG needs to be enabled or you end up with mixed results. In our case it was on the corp FW instead of the remote access devices.

Thanks