As 2013 draws to a close a quick summary of my favourite blog posts from 2013 – where does the time go!
In a SIP environment interoperability issues are unfortunately an expected reality. Sometimes vendor X will not interoperate fully with vendor Y and neither are willing or able to change their product. Equally some vendors may no longer be providing software updates.
So how can this be fixed most of the time with a quick, cheap and importantly still performant solution?
Enter SIP interceptor!
SIP Interceptor is a Linux userspace application. The purpose of SIP interceptor is to intercept and modify SIP packets (actually any IP packet) on the wire and to modify it before it reaches the application layer (userspace program) or after it has been sent from the application layer. SIP interceptor is built on the Linux “libnetfilter_queue” library. In userspace SIP interceptor uses “libnetfilter_queue” to connect to queue 0 (the default one) and get packets from the kernel. It modifies each packet if required, passes the packet back to the kernel (SIP Interceptor operates in NFQNL_COPY_PACKET mode) and finally issues a verdict on the packet (NF_ACCEPT the packet).
Regular expressions are used to specify how SIP messages should be modified and this gives SIP Interceptor great flexibility as well as minimising the packet inspection and modification overhead. For example using simple regular expressions SIP Interceptor can be used to modify SIP messages in the following way in order to quickly resolve SIP interoperability issues which it might not be possible to fix within the SIP application itself:
- Adding or removing custom SIP headers
- Removing or reordering Via: headers
- Adding a default SDP to INVITES without SDP
- Removing codecs within SDPs
- Removing multiple crypto attributes in SDPs with SRTP offered
- Manipulating P-Asserted-Identity headers on withheld numbers
- Removing non standard tags within the Call-Info header
- Translating one SIP response code to another
- Setting of QoS / Differentiated Services Code Point (DSCP) on SIP and RTP traffic
- Overwriting the Request URI header to fix redirect bugs
- Masking identities / implementing P-Asserted-Identity (PAI)
- Solving NAT headaches on SIP trunks
SIP Interceptor relies on NFQUEUE which is a Linux iptables and ip6tables target that delegates the decision on packets to a userspace application. The following command will pass all outgoing ICMP messages to SIP interceptor or, more correctly, it passes them to queue 0 on which SIP interceptor installs itself:
iptables -A OUTPUT -p icmp -j NFQUEUE --queue-num 0
This installs a rule in the OUTPUT chain to direct ICMP traffic to NFQUEUE and tells NFQUEUE to shunt them into queue 0. Note that if nothing is installed on the queue to set ACCEPT verdicts e.g. SIP Interceptor is not running the packets will be dropped. To remove the rule:
iptables -D OUTPUT -p icmp -j NFQUEUE --queue-num 0
The following rule will ask for a decision to a listening userspace program for all packets into the server:
iptables -A INPUT -j NFQUEUE --queue-num 0
The level of granularity can be increased by specifying IP addresses, port ranges etc. etc. For example, to add a rule to pass all packets to SIP Interceptor for incoming TCP packets to port 5060 from source IP in the 192.168.1.100-192.168.1.200 range only:
iptables -A INPUT -p tcp --dport 5060 -m iprange --src-range 192.168.1.100-192.168.1.200 -j NFQUEUE --queue-num 0
iptables -A INPUT -p udp --dport 5060 -j NFQUEUE --queue-num 0
-p sets the IP protocol for the rule, which can be either icmp, tcp, udp, or all, to match every supported protocol. In addition, any protocols listed in /etc/protocols may also be used. If this option is omitted when creating a rule, the all option is the default.
For more information please see:
Of course this solution only works for UDP and TCP transports. For SIP over TLS (and Windows OS for that matter) we would need to consider something a bit more complex like reSIProcate (http://www.resiprocate.org).
But hopefully this is a good start and you can see SIP Interceptor in action below.
Virgin Galactic is one of the universe’s most exciting, futuristic companies. Bitcoin, the virtual currency, has really captured the imagination recently as one of the world’s most innovative businesses looking to the future. So we think it is about time Virgin Galactic customers can choose to pay with bitcoins.
PS: I have decided not to sell a single one until 22/09/2016 …
On my current project we needed to send a SIP INFO message from SIP server. Before I forget here is how it can be done:
- Assign SIP INFO body to a variable:
- Assign extensions attributes:
- Send a private service request. Note that 105 is the ID of AttributePrivateMsgID and 3018 is the message ID for Advice of Charge (AoC). For reference other known values of AttributePrivateMsgID are:
3013 (GSIP_RECORD_START) – Starts GQM recording
3014 (GSIP_RECORD_STOP) – Stops a GQM recording
3015 (GSIP_RECORD_PAUSE ) – Pauses a GQM recording
3016 (GSIP_RECORD_RESUME ) Resumes a GQM recording
4012 – Start of Customer Greeting (See SIPS option greeting-notification)
4013 – End of Customer Greeting
- Test it – SIP INFO sent with supplied body:
13:59:12.608 Trc 04541 RequestPrivateService received from  (00000004 URS_1 192.168.1.11:44124)
AttributeExtensions  00 03 00 00..
13:59:12.608 Int 04543 Interaction message “RequestPrivateService” received from 17 (“URS_1”)
13:59:12.608 — created: CRequest@2aaaac041f20 RequestPrivateService-URS_1/259
13:59:12.608 +++ CIFace::Request +++
— new invoke
— thisCall by party
Numbers: +<0150> -<none>
Calls: 2aaaac035d30:1 none
Status: parsed:1 queued:0 sent:0 acked:0 preevent:0 event:0 context:0 transferred:0
— state check: ok
CIFace: Sent CRequest@2aaaac041f20 RequestPrivateService-URS_1/259
FinishRequest CRequest@2aaaac041f20 RequestPrivateService-URS_1/259
IFace stats: q=0 s=0
13:59:12.608: SipTServer::PrivateServiceAdviceOfCharge get destination from otherParty: 3001
13:59:12.608: SIPTR(11): Begin step 0 – SipTransactionExecuteCtiRequest(12)
13:59:12.608 SIPCONN(3001): CtiRequest(9)
13:59:12.608: SIPDLG: register TRN
13:59:12.608: Sending [19,TCP] 570 bytes to 192.168.1.11:5060 >>>>>
INFO sip:gw+Genesys@192.168.1.11:5060;tport=tcp;transport=tcp;gw=Genesys SIP/2.0
To: “3001 on FS” <sip:firstname.lastname@example.org>;tag=SQN3c6629UBNj
CSeq: 2 INFO
Via: SIP/2.0/TCP 192.168.1.11:5360;branch=z9hG4bK00383D8A-79FE-1287-BB5F-0B01A8C0AA77-8
For security reasons the forwarding of emails to external destinations is often disabled server side in Microsoft Exchange. If you really still want / need to do this then here is how:
- Add the following VBA code in the Visual Basic editor of Outlook (Alt-F11). Be sure to change email@example.com to the address where you want the mail to go and also adjust the days and times when you want forwarding to occur. Comment out the line “myattachments.Remove 1” if you want to forward attachments as well:
Sub AutoForwardEmail(Item As Outlook.MailItem)
Dim myFwd As Outlook.MailItem
Dim currentWeekDay As String
Dim currentHour As Integer
currentWeekDay = WeekdayName(weekDay(Date), False, vbSunday)
currentHour = hour(Time)
If currentWeekDay = “Saturday” Or currentWeekDay = “Sunday” Or currentHour < 9 Or currentHour > 17 Then
Set myFwd = Item.Forward
Set myattachments = myFwd.Attachments
While myattachments.Count > 0
Set myFwd = Nothing
- Enable Macros in Outlook (Tools -> Macro -> Security) and then restart Outlook:
- Tell Outlook to run this code for each inbound message (Tools -> Rules and Alerts -> New Rule -> Check Messages when they arrive -> Next -> YES -> Checkbox “Run a Script” -> Then select the script you just created e.g. “AutoForwardEmail”:
- Make sure that Outlook is running and connected to Exchange for this to work!
Snom Asset Manager (SAM) is a desktop application which provides a fully integrated solution for managing Snom IP Phone assets end to end throughout the asset lifecycle. When used in configuration with the Snom Asset Audit (SAA) desktop application the majority of the IP Phone provisioning process is fully automated and the built in checks ensure that the possibility of human error is minimised. A built in persistent storage mechanism allows Snom IP Phone assets to be tracked over a period of time and a history of asset status and information changes to be retrieved.
SAM is integrated with the following components of the provisioning solution:
- Provisioning Servers (HTTP / Web Servers)
- DHCP Servers
- Genesys Configuration Management Environment (CME) via Configuration Server
If required SAM can be used in conjunction with a standard barcode scanner and has built in checks to ensure that the scanned MAC address is a valid Snom MAC address otherwise the scanned input is ignored. This reduces the time to manage an asset since incorrectly scanned barcode labels are simply ignored.
SAM tracks the dynamic IP address assigned to an asset in two ways. Firstly through processing of HTTP logs fetched periodically from each configured provisioning server. This mechanism is also used to track the download of IP Phone specific configuration files and also firmware downloads. The second way is through the periodic fetching of DHCP lease logs from each configured DHCP server.
Automatic de-duplication of log entries from multiple provisioning servers and multiple DHCP servers always ensures that SAM provides a single source of truth in terms of the IP Phone’s current IP address and also firmware revision.
This information is available to support engineers through an asset status request. In this way support engineers can check if an IP Phone has recently downloaded new configuration information and/or firmware. In addition the current dynamic IP address assigned to the IP Phone can be determined and this allows engineers to login to the IP Phone via its secured Web UI interface to download IP Phone logs or to perform PCAP capture.
Enough talk – see SAM in action below!
Imagine this at the Ladbrokes World Darts Championship on Sky TV!
See more at: www.brynthedog.com
I suppose it was only a matter of time before somebody had their Bitcoins seized:
Genesys Customer Care is pleased to announce the global availability of the new Log File Management Tool (LFMT). This tool collects copies of Genesys application log files, stores them in a central repository, and provides an interface for retrieving the specific log files needed to troubleshoot an application issue. The LFMT was developed by our Customer Care team to make it easier and quicker to retrieve the right logs for troubleshooting, and thus reduce problem resolution times.
The goal of the new Log File Management Tool is to promote fast and targeted log file capture, reliable log file retention, and quick and easy log file retrieval. Built as a plug-in to Genesys Administrator Extension, the LFMT performs the following functions:
- Transfers copies of log files from application server hosts to a centralized log file repository
- Indexes log files into a central database according to customer-defined criteria, such as time or ConnID
- Scrubs sensitive data based on customer needs
- Provides a graphical user interface for customers and partners to easily search logs pertaining to an issue
- Provides a secure delivery method for customers, partners and Genesys Customer Care to share log files
- Enables unassisted log file retrieval by partners and Genesys Customer Care
The remote Mexican town of Villa Talea de Castro, which has a population of 2,500, now has its own mobile phone network.