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!
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.
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!
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.
Sean,
The only assistance I could with Sigma scripts was by using the Help button within the SBC itself.
Shane
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.
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.
It is easier to use SM for this
Wait – tell me more! How do you manipulate the SIP headers in SM? I know about the adaptation rules, but can those be customized?
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.
Hey Sean,
Did you ever get this working? I am in the same boat now
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
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:
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.
Hi, Roger! Thank you for your answer. I will let you know if I will find something.
Good luck with the new SBC installation.
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:
.
Hello,
Sigma is universal method.
You wrong in the syntax, must be:
{0ed28e3470e974017c124b0897303dd14e34b5245564abb28916e7d48d9b07c0}HEADERS[“To”][1].URI.USER.regex_replace(“8″,”0151”);
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”);
}
}
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?
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?
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
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
Amazing. Variable replacement within quotes! There’s NOTHING in the documentation. THANK YOU SO MUCH FOR THIS!!!
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?
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.
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.
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”).
You can as well put logging into SigMa which will print pessages into logfiles at loglevel “Info”.
Hi Roger,
Can you please suggest an web or document to start learning SBC?
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];
}
}
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
}
}
there are “)” missing at the end of the remove-statements.
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]);
}
}
Roger,
Awesome forum! Learning a lot.
I am trying to insert a prefix into the inbound number. Adding a 3 or a 9, depending on the inbound number dialed.
I have some of it set, and I can replace DISPLAY_NAME, however that is not changing the CID number, it is only changing the CID name.
What would allow me to insert a prefix in the number?
I am able to act on a matched number. That part works.
I am able to replace the Name (which I do not want to do).
I just can’t figure out how to manipulate the Caller ID Number.
within session “ALL”
{
act on request where {0ed28e3470e974017c124b0897303dd14e34b5245564abb28916e7d48d9b07c0}DIRECTION=”INBOUND” and {0ed28e3470e974017c124b0897303dd14e34b5245564abb28916e7d48d9b07c0}ENTRY_POINT=”PRE_ROUTING”
{
if ({0ed28e3470e974017c124b0897303dd14e34b5245564abb28916e7d48d9b07c0}HEADERS[“To”][1].URI.USER.regex_match(“6665554444(.*)”))
then
{
{0ed28e3470e974017c124b0897303dd14e34b5245564abb28916e7d48d9b07c0}HEADERS[“From”][1].DISPLAY_NAME = “5552223333”;
}
}
}
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?
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!
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.
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.
Thanks for that, Gerald. I tried it early on, but could never find the logfile! Do you know where it is?
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.
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
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.
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.
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.
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.
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;
}
}
}
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.
how I can contact you?
Sorry it’s been so long. You can reach me at roger@rogerthephoneguy.com
Hi!
If you wan´t two if-clause, like:
if (exists(%HEADERS[“Accept-Contact”][1])); and
if (%HEADERS[“To”][1].URI.USER.regex_match(“^.4610184*”)) then
….
How do you write then, I can´t find anytinh regarding two statemensts in if-claouse
Thanks !
Sorry I’m late. Did you figure this out? I don’t know, but you should be able to nest the if statements:
if (exists(%HEADERS[“Accept-Contact”][1])) {
if (%HEADERS[“To”][1].URI.USER.regex_match(“^.4610184*”)) {
//both are true
}
}
I can barely remember what I did yesterday . I think I got it worked out, but how, I don’t remember. I can try your clause in our lab. Thanks for answering, even if it was a bit late
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?
Did you figure this out?
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″);
}
}
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 🙂
Hi,
Can someone help me with anonymous in From header? I want to copy PAI header to From header for anonymous calls for incoming?
Hi.
Can you help me to and tell me how I can create script for copying PAI header to From?
What is ‘{0ed28e3470e974017c124b0897303dd14e34b5245564abb28916e7d48d9b07c0}’ in the responses above?
Sorry – when I migrated from hosted wordpress at godaddy to a local instance, i got a bunch of those nuids in there. I need to clean them up.