Would it be possible to obtain the caller's IP address in a SIP Normalization script?

[gboucher]

We have an application that usually relies on a CTI app to obtain a caller's IP address and we'd like to see if we could implement something similar using a SIP Normalization script instead.

What we would like to do is add a custom sip header to the outbound SIP INVITE that includes the original caller's IP address.

I haven't seen anything in the lua script documentation that would provide information on the original caller.

Gaetan

[Jonathan Els]

Although perhaps others can weigh in here as well, I would argue that you can't do this reliably.

Reasons:

• Can't use From, To, Contact headers, as these are over-written by proxies.
• The best options would be to inspect the media address in SDP, as this would be the IP that you'd be sending to on teh far-end.  There are a number of gotchas with this (multiple media addresses, separate media/signalling addresses, etc)
• Your scheme would become complex as you'd need to account for EO and DO cases for SDP inspection
• "Original Caller" quickly becomes a loaded concept - if calls go through forwarding?  Normalization scripts are attached to trunks...  is an upstream SBC considered a "caller" to you?
• Normalization scripts only work for trunks... not for locally registered phones.  Is this your use case?
• You haven't mentioned the usage, so in a NAT scenario, I don't know if you want the private or public IP address.  If you inspect the SDP, you'd be making an assumption that the IP provided is (a) the public IP and (b) publically reachable... Not always the case for either!
  

If you're trying to use locally registered phones (I'm presuming, please correct if wrong), then the correct answer is surely to use JTAPI.  You can get a lot more phone-related information from that API.

Can you give a bit more information on what you're trying to achieve?  If it is feasible with Lua, then I can definitely help you out in extracting the correct IP and inserting a custom header.  But as I've suggested, I think this approach is riddled with caveats.

[gboucher]

Thanks for you comments.

This is used in the context of processing 911 calls. So typically, the caller is "local" to the CUCM placing the outbound call.

The reason for having the original caller's IP present somewhere in the outbound call it so the server receiving the 911 call can figure out the caller's physical location (this server processes the call before forwarding to the actual PSAP).

As far as using JTAPI, this is basically what we are presently doing and it works well. But I was trying to find a "lighter" solution that would not require an external process. That is why the SIP Normalization scripts seemed promising. But I was hoping for some service to provide information on the call being processed, but it looks like all these services are SIP based.

While this may partly work for cases where the caller is SIP based, I'm not sure what happens when the caller is using a legacy signaling (SCCP, H.323, etc) while the outbound leg is SIP? Would the SIP Normalization script see any information for the inbound leg since it's not SIP?

Gaëtan

[Mark Stover]

You can run a Normalization Script on the SIP line side (the phone), which would create fewer barriers to this, but this hasn't really been fully vetted as a 911 solution, which makes me nervous when there are numerous off the shelf solutions out there. You even have an Emergency Call Handler built into Unified CM.

Release Notes for Cisco Unified Communications Manager and IM and Presence Service, Release 11.0(1) - New and Changed F…

[Jonathan Els]

Really?  I had read that normalization scripts were only supported for trunks.

[Mark Stover]

You have to apply it using a SIP Profile (you cannot configure directly on a phone), but you can send SIP line-side calls through a Normalization script.

Mark

[Jonathan Els]

Awesome!  Good to know, thank you for the confirmation.

[Jonathan Els]

One more question - the way you're describing, this should be supported for 3rd party SIP devices as well?

[Mark Stover]

It is tied to the SIP stack, not the phone specifically, so yes, it would handle 3rd-party SIP phones.