Troubleshooting Signaling Manipulation (SigMa) Scripts in Avaya Aura SBC

This is pretty obscure and I’m probably only talking to three people on the Internet right now, but if you have ever tried to troubleshoot SigMa scripts in the Avaya Aura Session Border Controller, you probably wish it had better logging. Actually, if you have ever gotten logging to work, please let me know. I had given up. However – I recently discovered a nice easy way to troubleshoot signaling manipulation, and consequently also discovered just how cumbersome this process really is.

The easy way to log is to set your own custom header in the SigMa script, then inspect the INVITE from the Session Manager’s point of view. For example, I added this SigMa script:

    act on request where {0ed28e3470e974017c124b0897303dd14e34b5245564abb28916e7d48d9b07c0}DIRECTION="INBOUND" and {0ed28e3470e974017c124b0897303dd14e34b5245564abb28916e7d48d9b07c0}ENTRY_POINT="PRE_ROUTING" {
        if({0ed28e3470e974017c124b0897303dd14e34b5245564abb28916e7d48d9b07c0}HEADERS["To"][1].URI.USER.regex_match("2025556199"))then {
            {0ed28e3470e974017c124b0897303dd14e34b5245564abb28916e7d48d9b07c0}HEADERS["roger-debug"][1] = {0ed28e3470e974017c124b0897303dd14e34b5245564abb28916e7d48d9b07c0}HEADERS["From"][1].URI.USER; 
            append({0ed28e3470e974017c124b0897303dd14e34b5245564abb28916e7d48d9b07c0}HEADERS["roger-debug"][1],"<");
            append({0ed28e3470e974017c124b0897303dd14e34b5245564abb28916e7d48d9b07c0}HEADERS["roger-debug"][1],"2135551212");
            append({0ed28e3470e974017c124b0897303dd14e34b5245564abb28916e7d48d9b07c0}HEADERS["roger-debug"][1],"@roger.corp>");
        }
    }

This SigMa script checks for calls to 202-555-6199 and creates a new header. Then, within Session Manager, you can look at the full header and see this info:

INVITE sip:2027216199@ares.corp SIP/2.0 
From: "PHONEGUY ROGER " <sip:6265554799@ares.corp>;tag=6698455617080545_c1b09.2.2.1404967301186.0_7074379_15030130 
To: <sip:2025556199@telco.corp> 
CSeq: 2 INVITE 
Call-ID: 9959340302389262@12.11.18.20 
Contact: <sip:10.10.20.71:5060;transport=tcp> 
Record-Route: <sip:10.10.20.71:5060;ipcs-line=63646;lr;transport=tcp> 
Allow: INVITE,ACK,CANCEL,BYE,INFO,PRACK 
Max-Forwards: 64 
Via: SIP/2.0/TCP 10.16.26.71:5060;branch=z9hG4bK-s1632-000279738415-1--s1632- 
Accept: application/sdp, application/isup, application/dtmf, application/dtmf-relay, multipart/mixed 
P-Asserted-Identity: "PHONEGUY ROGER " <sip:6265554799@telco.corp> 
Content-Disposition: session; handling=required 
Content-Type: application/sdp 
roger-debug: roger-debug: 6265554799< 
roger-debug: roger-debug: 62655547992135551212 
roger-debug: roger-debug: 6265554799@roger.corp> 
Content-Length: 241 
 
v=0 
o=Sonus_UAC 11647 11015 IN IP4 10.16.26.71 
s=SIP 
c=IN IP4 10.16.26.71 
t=0 0 
m=audio 19234 RTP/AVP 18 0 100 
a=rtpmap:18 G729/8000 
a=rtpmap:0 PCMU/8000 
a=rtpmap:100 telephone-event/8000 
a=fmtp:100 0-15 
a=sendrecv 
a=maxptime:30

For quick one-liners, this is pretty handy. However, you can see my attempt at creating ONE header with a new p-asserted-identity completely failed. I can generate a new header, but my attempts to append to it only created another header. I really hope the new version of software adds some better manipulation features. In the meantime, I’ll keep hacking away at it.

If anyone out there knows SigMa, please let me know!

52 thoughts on “Troubleshooting Signaling Manipulation (SigMa) Scripts in Avaya Aura SBC

  1. Shane O'Doherty

    Roger, were you able to make any headway with breaking down how SIGMA works on the A-SBC?
    I have a unique issue with one of my customers and I believe SIGMA might be my only option to address the problem. Basically I need to modify a diversion header based on the outbound CLID.

    Appreciate any feedback.

    Thank you.

    Reply
    1. roger Post author

      Hi Shane! Yes, I’m using signaling manipulation on my AT&T IPFlex trunks. While we were cutting to AT&T, we found that they were rejecting calls to tollfree numbers if I was trying to send an ANI that wasn’t part of my AT&T dialplan. You can imagine how hard this could be to manage. I had lots of DIDs that I hadn’t yet ported to AT&T, but I wanted to sent all my toll free calls to AT&T trunks. To fix this, I created a SigMa script that changed the p-asserted-identity header to my main billing telephone number for the AT&T account. In the last two years, not one user has mentioned it. The script doesn’t change the “From” header, just p-asserted-identity. And most tollfree calls are to conference bridges anyway, so nobody cares about the caller-id.

      Here is how I did it. You should be able to tweak this to modify the diversion header:

      It’s a two-step process. First, create the SigMa script by going to Global Profiles -> Signaling Manipulation. Create a new SigMa script. Mine looks like this:

      within session "ALL"
      {
          act on request where {0ed28e3470e974017c124b0897303dd14e34b5245564abb28916e7d48d9b07c0}DIRECTION="INBOUND" and {0ed28e3470e974017c124b0897303dd14e34b5245564abb28916e7d48d9b07c0}ENTRY_POINT="AFTER_NETWORK"
          {
              if({0ed28e3470e974017c124b0897303dd14e34b5245564abb28916e7d48d9b07c0}HEADERS["To"][1].URI.USER.regex_match("^1800|1866|1888|1877|855|844"))then
              {
                  remove({0ed28e3470e974017c124b0897303dd14e34b5245564abb28916e7d48d9b07c0}HEADERS["p-asserted-identity"][1]);
                  {0ed28e3470e974017c124b0897303dd14e34b5245564abb28916e7d48d9b07c0}HEADERS["p-asserted-identity"][1] = "12135551000<sip:12135551000@12.12.12.71>";
              }        
          }
      }
      

      When you save the SigMa script, it is checked for Syntax so if it saves, it should be good to go.

      Then apply this SigMa script to your server configuration at Global Profiles -> Server Configuration. Select your Server Profile and click the “Advanced” tab, then edit. From the Signaling Manipulation dropdown, select your new SigMa script. In my experience, you do not have to restart the app. The new script applies immediately.

      I hope this helps! Please let me know!

      Reply
  2. Sean

    Hello,
    Where can you find documentation on the syntax for this. I am trying to write a script to insert a +1 to the FROM address on each inbound calls, and can’t find any reliable docs, support.avaya is less then helpful when it comes to finding documentation.

    Reply
    1. Shane O'Doherty

      Sean,

      The only assistance I could with Sigma scripts was by using the Help button within the SBC itself.

      Shane

      Reply
      1. roger Post author

        The admin guide has a few pages of examples, and there are lots of interop documents online that mention SigMa scripts in the context of working with other carriers. But these are typically the same SigMa script recycled over-and-over.

        Avaya has a pretty good SBC team and a library of SigMa scripts, but but they don’t seem to have documentation to share with their customers. If you have a support contract with Avaya, you can get a SME on the phone and they’re usually pretty good about sharing a specific script for a specific application.

        Reply
    2. roger Post author

      There are NO DOCUMENTS that comprehensively explain SigMa scripting that I can find. I would use an “adaptation” in session manager to insert that +1. Is that an option for you? Are you using session manager?

      It is possible to manipulate the FROM header, but I don’t know if you can pre-pend a string. String manipulation is not easy in SigMa – there doesn’t seem to be a way to concatenate strings. If you can find a way to do it, please let us all know.

      Reply
      1. roger Post author

        Wait – tell me more! How do you manipulate the SIP headers in SM? I know about the adaptation rules, but can those be customized?

        Reply
        1. Gerard

          I was talking about adding the +1. But besides all this, I only use Sigma when I am sure I need it. I have had about ten cases where I needed it and I am not a pro but know my way around. And in 6.3 it is not working properly. Upgrade to 7 (the SBCE) as soon as you can.

          Reply
  3. Scott Wells

    Hey Roger, I’m currently working on an issue we are having with outbound SIP calls where, depending on the answering endpoint, our PBX display names are being sent as the outgoing name display. We would prefer the PBX names not be sent out, so we are trying to determine the best place to manipulate this information. SigMa scripting seems to be a viable option where we could replace any BPX display name information with our company name. Have you ever run into this? If so, do you use SigMa scripts to re-write headers to resolve? Any input you have would be appreciated. Thanks.
    As info: Avaya CM 6.3.9 –> SM 6.3.10 –> Sipera SBC –> AT&T IP Flex

    Reply
  4. crymy

    Hey Roger! I would like to modify the “To” field with the SigMa Script from 860 to 015160 and to be able to call another destination. I did this script and it is modyfing actually the “To” field, but the INVITE message remains the same and is calling the same number… Maybe you have some ideas. Thanks a lot!

    within session “INVITE”
    {
    act on message where {0ed28e3470e974017c124b0897303dd14e34b5245564abb28916e7d48d9b07c0}DIRECTION=”OUTBOUND” and {0ed28e3470e974017c124b0897303dd14e34b5245564abb28916e7d48d9b07c0}ENTRY_POINT=”POST_ROUTING”

    {
    {0ed28e3470e974017c124b0897303dd14e34b5245564abb28916e7d48d9b07c0}HEADERS[“To”][1].regex_replace(“8″,”0151”);
    }
    }

    INVITE sip:860@ac.de SIP/2.0 |
    From: “XXX” ;tag=801a39b2224e6119cc574db09600
    To:

    Reply
    1. roger Post author

      Yes, these scripts are so frustrating. I have also tried to modify the “to” header and yet the call routes the same way. If all went well with your script, it might break the routing though. I don’t know how sophisticated the regex engine is within SigMa, but if it follows guidelines, you’ll want to use the regex of “^8” to lock it to the first character. However, looking at some of the sample documents, it might replace the entire string! And there’s no (documented) way to back-reference the matched pattern. In Perl you’d be able to do /^8(.*)/ to match (and store) captured digits and re-use them later. Ugh! Or if you could simply concatenate variables! Sorry, I wish I had more info. There’s a new version for the SBC that I’ll install soon. Perhaps it does more. If you figure this out, please let me know. I could totally use it.

      Reply
      1. crymy

        Hi, Roger! Thank you for your answer. I will let you know if I will find something.
        Good luck with the new SBC installation.

        Reply
  5. crymy

    Hey Roger! I found something related to URI manipulation, but is not in Sigma… Maybe you are already aware about this, but I just found it now. It is in Global Profiles–>Server Interworking–>Interworking Profiles. In order to manipulate the detination numbers in the Provider’s direction, you add this rule on the Provider profile. Then the Interworking Profile should be assigned in the Server Configuration–>Server Profiles–>Advanced–>Interworking Profile for the Provider’s direction.
    I suppose, that maybe Sigma is only for the HEADERS, you can not change the URI part…

    8.* Replace 8 with 0987 None

    INVITE sip:098760@ac.de SIP/2.0
    From: “xxx” ;tag=04676d8a3ce618ff7574db09600
    To:

    .

    Reply
  6. Alex

    Hello,
    Sigma is universal method.
    You wrong in the syntax, must be:
    {0ed28e3470e974017c124b0897303dd14e34b5245564abb28916e7d48d9b07c0}HEADERS[“To”][1].URI.USER.regex_replace(“8″,”0151”);

    Reply
  7. Alex

    within session “INVITE”
    {
    act on request where {0ed28e3470e974017c124b0897303dd14e34b5245564abb28916e7d48d9b07c0}DIRECTION=”OUTBOUND” and {0ed28e3470e974017c124b0897303dd14e34b5245564abb28916e7d48d9b07c0}ENTRY_POINT=”POST_ROUTING”
    {
    {0ed28e3470e974017c124b0897303dd14e34b5245564abb28916e7d48d9b07c0}HEADERS[“To”][1].URI.USER.regex_replace(“8″,”0151”);
    {0ed28e3470e974017c124b0897303dd14e34b5245564abb28916e7d48d9b07c0}HEADERS[“Request_Line”][1].URI.USER.regex_replace(“8″,”0151”);
    }
    }

    Reply
  8. Thomas

    I realize this article is a bit old Roger, but I’ve used debugging in sigma scripting quite often, and it is not that hard to set it up. I recon that you have gotten it to work by now?

    Reply
    1. roger Post author

      Oh thanks for checking in. No, I’ve never gone back to this. Do you know how to concatenate strings in SIGMA? Specifically, I would like to replace the name with the telephone number so the callerid name is the phone number. There are many times the callerid name is “WIRELESS CALLER” and my Avaya only shows the name. Can I replace the name with the number?

      Reply
      1. Thomas

        I would think that should be possible. If I asume you need the “from” display name to be equal the from number? If that is the case you should be able to use something like:

        {0ed28e3470e974017c124b0897303dd14e34b5245564abb28916e7d48d9b07c0}variableFromNumber = {0ed28e3470e974017c124b0897303dd14e34b5245564abb28916e7d48d9b07c0}HEADERS[“FROM”][1].URI.USER;
        {0ed28e3470e974017c124b0897303dd14e34b5245564abb28916e7d48d9b07c0}HEADERS[“FROM”][1].DISPLAY_NAME = {0ed28e3470e974017c124b0897303dd14e34b5245564abb28916e7d48d9b07c0}variableFromNumber

        // Thomas

        Reply
        1. Thomas

          When it comes to general concatenation I would try this:

          {0ed28e3470e974017c124b0897303dd14e34b5245564abb28916e7d48d9b07c0}variableDisplayName = {0ed28e3470e974017c124b0897303dd14e34b5245564abb28916e7d48d9b07c0}HEADERS[“FROM”][1].DISPLAY_NAME;
          {0ed28e3470e974017c124b0897303dd14e34b5245564abb28916e7d48d9b07c0}variableFromNumber = {0ed28e3470e974017c124b0897303dd14e34b5245564abb28916e7d48d9b07c0}HEADERS[“FROM”][1].URI.USER;
          {0ed28e3470e974017c124b0897303dd14e34b5245564abb28916e7d48d9b07c0}HEADERS[“FROM”][1].DISPLAY_NAME = “{0ed28e3470e974017c124b0897303dd14e34b5245564abb28916e7d48d9b07c0}variableFromNumber {0ed28e3470e974017c124b0897303dd14e34b5245564abb28916e7d48d9b07c0}variableDisplayName”;

          This should give you both the display name and the phone number in the “from” display name.

          // Thomas

          Reply
          1. roger Post author

            Amazing. Variable replacement within quotes! There’s NOTHING in the documentation. THANK YOU SO MUCH FOR THIS!!!

          2. Nate

            I have crawled over the internet looking for a string concatenation method in the Sigma script. Trying the above method produces the literal variable names for the value in the header. Also noticed that you can’t append or remove headers that are not in the “original” packet. As in {0ed28e3470e974017c124b0897303dd14e34b5245564abb28916e7d48d9b07c0}HEADERS[“newH”][1] then try to append to it fails. Also tried to build variable on each other and it was a fail as well. Any other advice on building a string?

          3. roger Post author

            Man, that is SO frustrating. I don’t get into that SBC much anymore so I cannot play around. Do you have a support contract with Avaya? I managed to get in touch with the old Sipera team once. I was afraid to let them off the phone! You might be able to reach someone in that group. It’s probably pretty small.

  9. John Waber

    Roger,
    The following are responses to a couple issues raised above.
    First the SIP headers TO and FROM are purely cosmetic; they are not used for routing a SIP request such as an INVITE. Instead, routing of a request is determined by first by the top-most ROUTE header, and if none exist then by the REQUEST-URI (the top line of the request). The recipient of the request captures the address information found in the CONTACT header, and should use that address for populating the REQUEST-URI for all subsequent requests.
    Second, Avaya best practice is to perform as much manipulation as possible at the edge of your network (where the SBCE lives) and minimize the manipulations at the core (which is where ASM lives). Further, because they are more processor intensive, Avaya advises using SIGMA scripts only when the modification cannot be performed through the SBCE’s menus. Accordingly, the best place in the SBCE to introduce or remove the ‘+’, (an indication this is an E.164-compliant phone number) is in the INTERWORKING PROFILE, specifically on the URI MANIPULATION tab. CRYMY’s entry above describes this process in much better detail. On the other hand, adding/removing the plus sign in an ASM adaptation works just as well.
    Finally, every SIP Trunk Service Provider requires that all requests be sent to it with E.164 addressing. The flag that the phone number is an E.164 is the presence of the plus sign in the first position. However, most SIP Providers reject the request if the phone number does contain the plus sign. Ironic isn’t it.

    Reply
  10. Andre Gronwald

    Hi,
    logging within SigMa scripts is possible.
    you can do it with a print statement in sigma. be aware that the print needs to statements, e.g.
    print “Test SigMa”, “just a test.”;
    these outputs are visible in SSYNDI-logs if “INF” is enabled under “debugging” for sigma (just turn on everything for “inf”).

    Reply
  11. Joe Dinatale

    Hello,

    We are cutting over to Rogers SIP trunks, we are using Avaya SBC 7.1. Per integration docs we need to create a Sigma to remove headers due to 513 message to big. I created SigMa below but it is not allowing me to save says parser failed so I am definitely doing something wrong?? any help would be greatly appreciated.

    within session “INVITE”
    {
    act on request where {0ed28e3470e974017c124b0897303dd14e34b5245564abb28916e7d48d9b07c0}DIRECTION=”OUTBOUND” and {0ed28e3470e974017c124b0897303dd14e34b5245564abb28916e7d48d9b07c0}ENTRY_POINT=”POST_ROUTING”
    {

    // Remove unwanted Headers
    remove ({0ed28e3470e974017c124b0897303dd14e34b5245564abb28916e7d48d9b07c0}HEADERS[“History-Info”][3];
    remove ({0ed28e3470e974017c124b0897303dd14e34b5245564abb28916e7d48d9b07c0}HEADERS[“History-Info”][2];
    remove ({0ed28e3470e974017c124b0897303dd14e34b5245564abb28916e7d48d9b07c0}HEADERS[“History-Info”][1];
    remove ({0ed28e3470e974017c124b0897303dd14e34b5245564abb28916e7d48d9b07c0}HEADERS[“Alert-Info”][1];
    remove ({0ed28e3470e974017c124b0897303dd14e34b5245564abb28916e7d48d9b07c0}HEADERS[“x-nt-e164-clid”][1];
    remove ({0ed28e3470e974017c124b0897303dd14e34b5245564abb28916e7d48d9b07c0}HEADERS[“P-Asserted-Identity”][1];
    remove ({0ed28e3470e974017c124b0897303dd14e34b5245564abb28916e7d48d9b07c0}HEADERS[“P-AV-Message-Id”][1];
    remove ({0ed28e3470e974017c124b0897303dd14e34b5245564abb28916e7d48d9b07c0}HEADERS[“P-Charging-Vector”][1];
    remove ({0ed28e3470e974017c124b0897303dd14e34b5245564abb28916e7d48d9b07c0}HEADERS[“Av-Global-Session-ID”][1];
    }
    }

    Reply
    1. roger Post author

      So frustrating! Looks good to me. I would remove everything and re-build the script slowly to see where the parser chokes. For example, will it allow this? Oh by the way, the double quotes are “smart quotes” in your comment. Perhaps you can paste to plain-text and convert the quotes to regular ASCII character 34?

      within session “INVITE”
      {
      act on request where {0ed28e3470e974017c124b0897303dd14e34b5245564abb28916e7d48d9b07c0}DIRECTION=”OUTBOUND” and {0ed28e3470e974017c124b0897303dd14e34b5245564abb28916e7d48d9b07c0}ENTRY_POINT=”POST_ROUTING”
      {
      // Remove unwanted Headers
      }
      }

      Reply
    2. Gerard

      you forgot the ) before the ; at the end.

      within session “ALL”
      {
      act on message where {0ed28e3470e974017c124b0897303dd14e34b5245564abb28916e7d48d9b07c0}DIRECTION=”OUTBOUND” and {0ed28e3470e974017c124b0897303dd14e34b5245564abb28916e7d48d9b07c0}ENTRY_POINT=”POST_ROUTING”
      {
      remove({0ed28e3470e974017c124b0897303dd14e34b5245564abb28916e7d48d9b07c0}HEADERS[“P-Charging-Vector”][1]);
      }
      }

      Reply
  12. Mack

    How would you add SDP to a re-invite using Sigma? The initial invite contains SDP, however the re-invite doesn’t which causes the call to drop?

    Reply
    1. roger Post author

      Oh! I think this is something else. I had this problem when calling to/from other IPFlex customers. AT&T allows their customers to “see” each other and negotiate a direct connection. I was able to fix this by modifying the “Global Profiles -> Server Interworking” and setting one of these two things. Unfortunately I do not remember which profile I had to change. I think it was the ATT side, but it might have been the Avaya side, or maybe both. But the params were “Delayed SDP Handling” and/or “Re-Invite handling”

      One of those fixed it for me!

      Reply
      1. Gerard

        A reINVITE without SDP should not drop the call. When reINVITE handling is enabled on the interworking profile of the internal UA (Session Manager) the SBC compares the SDP of the initial INVITE with the SDP of the reINVITE. If these are identical, the SBC will handle the reINVITE. If the reINVITE is not there, or different, the SBC will just pass the reINVITE.

        Reply
  13. Gerard

    You might also search the Avaya support website for the ‘print’ command within sigma. This ‘prints’ your sigma into a logfile so you can see when it is called. It might help you all debugging sigma.

    Reply
      1. Gerard

        It will output text to the /archive/log/ipcs/ss/logfiles/elog/SSYNDI/ logs when debug logging is enabled for the SBC (Device Specific Settings->Troubleshooting->Debugging)

        So you can add things like:
        print “before”, {0ed28e3470e974017c124b0897303dd14e34b5245564abb28916e7d48d9b07c0}HEADERS[“Contact”][1].URI.HOST; and it will output ‘before’ followed by the contact’s host.

        Reply
  14. Damir

    Hi all
    That Sigma Script changes the REGISTER Contact Header from this:

    Contact:
    to this:
    Contact:

    My provider here is expecting the priority bit to be outside the quotes.. ;-( any ideas how the script should look like?
    Expectations from provider:
    Contact: ;q=1

    within session “REGISTER”
    {
    act on request where {0ed28e3470e974017c124b0897303dd14e34b5245564abb28916e7d48d9b07c0}DIRECTION=”OUTBOUND” and {0ed28e3470e974017c124b0897303dd14e34b5245564abb28916e7d48d9b07c0}ENTRY_POINT=”POST_ROUTING”
    {
    {0ed28e3470e974017c124b0897303dd14e34b5245564abb28916e7d48d9b07c0}HEADERS[“Contact”][1].regex_replace(“sip:CHVoiceSomething@10.10.10.10:5060;transport=udp”,”sip:CHVoiceSomethin@10.10.10.10.;q=1″);
    }
    }

    there is no usable documentation on this sigma scripting
    //Damir

    Reply
    1. roger Post author

      Man, you said it: “there is no usable documentation on this sigma scripting”

      Do you have any support with Avaya? Hardly anyone uses these SBCs anymore so it’s so frustrating! I wish I could help. I don’t have access to those SBCs anymore. That client is about to change to Cisco CUBEs, which I highly recommend if you can afford it.

      Reply
      1. Gerard

        The new 7.2.2. docs explain sigma in a pretty easy way. I would never recommend CUBE’s by the way. Please contact me if you are in need of any help.

        Reply
  15. Thomas

    Hi,

    Thanks for the post Roger, i am struggling with an issue where our Provider is sending us the invite with the main number and the actually dialed number in the To field. SBC then routes this call to SM with the invite header unchanged and SM will try to ring the number in the Invite and not the one in the To field. Is there a way to have this changed? I have tried looking up documentation on header and URI manipulation without luck and my sigma scripts didn’t work out.
    I have heard from colleagues that IPO can handle this but i have no luck finding docs on SBC and SM.

    Reply
    1. roger Post author

      Yes you *should* be able to do this. There are only three examples provided in the SBC docs, but I think one of them does something like this? I don’t get to play with that SBC much anymore. The community of users seems pretty small nowadays so it’s really hard to do anything creative.

      Reply
    2. Gerard

      You can try this one. Place it on the trunk server.

      within session “ALL”
      {
      act on message where {0ed28e3470e974017c124b0897303dd14e34b5245564abb28916e7d48d9b07c0}DIRECTION=”INBOUND” and {0ed28e3470e974017c124b0897303dd14e34b5245564abb28916e7d48d9b07c0}ENTRY_POINT=”PRE_ROUTING”
      {
      {0ed28e3470e974017c124b0897303dd14e34b5245564abb28916e7d48d9b07c0}HEADERS[“Request_Line”][1].URI.USER = {0ed28e3470e974017c124b0897303dd14e34b5245564abb28916e7d48d9b07c0}HEADERS[“To”][1].URI.USER;
      }
      }

      Some older SBC’s had problems parcing this and then I used this: (replace 1234567890 with your number)

      within session “ALL”
      {
      act on message where {0ed28e3470e974017c124b0897303dd14e34b5245564abb28916e7d48d9b07c0}DIRECTION=”INBOUND” and {0ed28e3470e974017c124b0897303dd14e34b5245564abb28916e7d48d9b07c0}ENTRY_POINT=”PRE_ROUTING”

      {
      if ({0ed28e3470e974017c124b0897303dd14e34b5245564abb28916e7d48d9b07c0}HEADERS[“Request_Line”][1].URI.USER.regex_match(“1234567890″)) then
      {
      {0ed28e3470e974017c124b0897303dd14e34b5245564abb28916e7d48d9b07c0}HEADERS[“Request_Line”][1].URI.USER = {0ed28e3470e974017c124b0897303dd14e34b5245564abb28916e7d48d9b07c0}HEADERS[“To”][1].URI.USER;
      }
      }
      }

      Reply
  16. Gerard van Hamburg

    If any of you guys need a SBC specialist please contact me. I am a freelance Avaya expert based in the Netherlands and work with SBC’s almost every day.

    Reply
  17. Juhartono

    How to assign CPN on SBC SIP trunk channel?
    I have 120 channel (licensed) on SBC, and my CM doesnot send CPNumber (anonymous), then SIP trunk provider reject the call.
    How to assign CPN on SBC channel, so outgoing call no rejected by SIP trunk provider?

    Reply
      1. Thomas

        To change From address to 123456
        This can be used to change the From address of an alarm server for example.
        within session “ALL”
        {
        act on message where %DIRECTION=”OUTBOUND” and %ENTRY_POINT=”POST_ROUTING”
        {
        %HEADERS [“From”][1].regex_replace (“MyAlarmServer”,”123456″);
        %HEADERS [“Contact”][1].regex_replace (“MyAlarmServer”,”123456″);
        %HEADERS [“Remote-Party-ID”][1].regex_replace (“MyAlarmServer”,”123456″);
        %HEADERS [“P-Asserted-Identity”][1].regex_replace (“MyAlarmServer”,”123456″);
        }
        }

        Reply
  18. Rale011

    Hi,

    Does anyone know how I can copy from PAI heade to From header? I receive in From header anonymous, but in PAI I see correct number and I want to place in From header.

    pls help 🙂

    Reply
  19. Rale011

    Hi,

    Can someone help me with anonymous in From header? I want to copy PAI header to From header for anonymous calls for incoming?

    Reply

Leave a Reply to Andre G Cancel reply

Your email address will not be published. Required fields are marked *