locked
MSPL routing based on a SIP URI for mediation calls RRS feed

  • Question

  • I've been experimenting with some MSPL routing based on a set of SIP URIs so that I only reroute messages for particular users.  This works fairly well in many cases, but I'm running into an issue where if a call is routed to/from a mediation server, the call may not be intercepted by the script unless a mediation endpoint is explicitly checked. 

    For example, if I look for anything routed to sip:user@example.com, who has a line URI in AD of tel:+19058825000;ext=1154, then a call to the user's SIP URI will be intercepted, but the call to the user's DID will not be if I'm only looking for the SIP URI.  The initial INVITE that goes to the FE has a TO header that looks like this:

    To

    : <sip:1154;phone-context=PstnGateway_192.168.200.42@rnd.computer-talk.com;user=phone>;epid=b82f23167d

    And while I could explicitly look for that URI, I'd have to pull this from AD.  At no point does the TO header get modified.  When the 180 RINGING comes back, the user's SIP URI is stored in the p-asserted-identity header, but at this point it's not possible to redirect the call with a ProxyRequest. 

    Is there any way to have a script on the front end identify an INVITE to a DID as a sip user?  Would it just mean installing lower in the hierarchy?  Is there a way of testing whether a TO URI will route to a specific SIP endpoint in a script that runs on the FE? 

    I could definitely do a couple of these things if I dispatched off to managed code, but I'd rather not incur that expense if I don't have to.  If it's possible to do everything script-side, I'd like to try it. 

    Monday, January 12, 2015 3:03 PM

All replies

  • Did you ever get an answer on this? I'm trying to figure the same thing out.
    Friday, November 15, 2019 8:39 PM