Incoming INVITE With Portability Info And LRN
I am trying to set up my Asterisk server so that it will recognize an incoming call to the Asterisk’s own Location Routing Number (LRN), validating the “rn” in the INVITE and then using the Called Number from the INVITE as the extension in the dialplan.
The INVITE R-URI looks like:
INVITE sip:+19135041291;rn=+19136630000;npdi@12.4.240.200:5060;user=phone;transport=udp SIP/2.0
The +1913663000 is the LRN of the Asterisk box, so I would want to have the dialplan validate that the “rn” is that number. The +19136631291 is the extension within the system that they are trying to reach, that extension will vary, and will have an exten defined in the dialplan.
I assume that this is just going to require that I do some matching and substring-type variable replacement to hit a context with just the Called Number part of the request, but I wondered if anyone had a working example of this before I started putting too much effort into it.
As a PBX, Asterisk doesn’t have to worry about portability, but I am using it to simulate a full-blown Class 5 switch, so I have to have an LRN
assigned to it to allow users to port to that switch.
-Trey
7 thoughts on - Incoming INVITE With Portability Info And LRN
Le 18/03/2016 16:20, Trey Hilyard a
I am not sure that this is needed here. The Request URI has all of the values that I need. I agree that I might need to CUT part of the R-URI, but I don’t need access to any other header to find the info I need.
When the call arrives at the Asterisk right now, this is the exten/context that it is hitting, so it already has the info I need:
Executing [9135041291;rn=+19136630000;npdi@from_pstn:1]
As far as I can tell, I think that I just need to figure out how to make an extension entry that matches on the “rn=+19136630000\;npdi” and then moves to another context (or same one) with ${EXTEN,0,10}.
I just can’t get that first extension to match on the RN value.
I thought this would be as easy as
exten => _XXXXXXXXXX\;rn=+19136630000,1,Goto(from_pstn,${EXTEN:0:10})
But it appears that the pattern match doesn’t work once I get to the “r” in
“rn”. I am assuming that the pattern match doesn’t like dealing with characters without taking the entire URI.
I am working on a plan using a lot more CUTs than I think I should need, but we’ll see if it works.
Have you tried the ‘_!.’ pattern?
The ‘_x.’ pattern works fine.
How about something like:
[parse-lrn]
exten = _x.,1, verbose(1,[${EXTEN}@${CONTEXT}])
same = n, set(DID=${CUT(EXTEN,\;,1)})
same = n, set(LRN=${CUT(EXTEN,\;,2):3:12})
same = n, execif($[“${LRN:0:1}” = “+”]?set(LRN=${LRN:1}))
same = n, execif($[“${LRN:0:1}” = “1”]?set(LRN=${LRN:1}))
same = n, goto(${LRN},${DID},1)
same = n, hangup()
That’s a good one. One thing it doesn’t do is actually validate that the LRN is mine, but that shouldn’t be tough to add now the the LRN is in its own variable. Thanks for the help!