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 %DIRECTION="INBOUND" and %ENTRY_POINT="PRE_ROUTING" {
        if(%HEADERS["To"][1].URI.USER.regex_match("2025556199"))then {
            %HEADERS["roger-debug"][1] = %HEADERS["From"][1].URI.USER; 
            append(%HEADERS["roger-debug"][1],"<");
            append(%HEADERS["roger-debug"][1],"2135551212");
            append(%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!

28 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 %DIRECTION="INBOUND" and %ENTRY_POINT="AFTER_NETWORK"
          {
              if(%HEADERS["To"][1].URI.USER.regex_match("^1800|1866|1888|1877|855|844"))then
              {
                  remove(%HEADERS["p-asserted-identity"][1]);
                  %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 %DIRECTION=”OUTBOUND” and %ENTRY_POINT=”POST_ROUTING”

    {
    %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. 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:

        %variableFromNumber = %HEADERS[“FROM”][1].URI.USER;
        %HEADERS[“FROM”][1].DISPLAY_NAME = %variableFromNumber

        // Thomas

        Reply
        1. Thomas

          When it comes to general concatenation I would try this:

          %variableDisplayName = %HEADERS[“FROM”][1].DISPLAY_NAME;
          %variableFromNumber = %HEADERS[“FROM”][1].URI.USER;
          %HEADERS[“FROM”][1].DISPLAY_NAME = “%variableFromNumber %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!!!

  7. 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
  8. 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
  9. 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 %DIRECTION=”OUTBOUND” and %ENTRY_POINT=”POST_ROUTING”
    {

    // Remove unwanted Headers
    remove (%HEADERS[“History-Info”][3];
    remove (%HEADERS[“History-Info”][2];
    remove (%HEADERS[“History-Info”][1];
    remove (%HEADERS[“Alert-Info”][1];
    remove (%HEADERS[“x-nt-e164-clid”][1];
    remove (%HEADERS[“P-Asserted-Identity”][1];
    remove (%HEADERS[“P-AV-Message-Id”][1];
    remove (%HEADERS[“P-Charging-Vector”][1];
    remove (%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 %DIRECTION=”OUTBOUND” and %ENTRY_POINT=”POST_ROUTING”
      {
      // Remove unwanted Headers
      }
      }

      Reply
  10. 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

Leave a Reply

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