ramdyne (Posts about sip)

Worst SIP implementation of the moment

ramdyne — Wed, 09 Oct 2013 21:07:25 GMT

There must be something very wrong with the way the Siemens OpenScape Office PBX's SIP stack handles SIP error codes or the way people configure it by default.

Suppose you make a call and forget a digit somewhere in the middle. Your PSTN provider (or someone else) detects that the number is not quite sufficient and replies to your INVITE with an error message containing "SIP/2.0 484 Address Incomplete".

Normal SIP implementations send an error up the stack to the end user who then hears some kind of error code through their handset or some error code on the display of their phone. Is OpenScape doing that? Noooooooo.....

When OpenScape receives an error code other than "486 Busy" or "500 Internal Server Error", it sends out as many retry calls as it can, one after the other, until it hits the maximum number of simultaneous calls it has configured on the SIP trunk (even though these calls are not simultaneous).

If you're using the distribution between successful and failed calls to monitor the health of your platform, behavour like this very quickly starts to trigger alarms that something is not quite right, especially when endusers are absolutely convinced the number they dialled is correct. Hundreds of failed calls within a minute or two are not unusual in cases like this.

Cisco SIP fraud protection in IOS 15.1T

ramdyne — Fri, 28 Jan 2011 23:04:03 GMT

A couple of weeks ago a colleague thought it'd be nice to try and run a completely new version of IOS on our test AS5350XM "voice" gateway. It ran without any issues but since the ISDN30 connected to it is hardly used we never really tried to put any calls through it. That is until I had to test some ISDN30 equipment and lacking a PBX the 5350 was the next best thing to test it with.

So I tried to build a SIP > ISDN > SIP path with two ISDN30 gateways back to back. Calling out from the 5350 worked like a charm, but I couldn't get incoming calls towards the gateway to work. I completely redid all the dial peers, number translations, the works. I was completely lost, even turning on debug didn't appear to show any useful info. It matched the correct dial peers but still the calls coming in on the SIP interface were not routed to the ISDN30 interface.

I started spelling every single line of debugging I could enable and got nowhere until I found something like the following:

> 000184: *Apr 30 14:38:57.251: //3/F146D6B0800C/CCAPI/cc_process_call_setup_ind: > CCAPI handed cid 3 with tag 1002 to app "_ManagedAppProcess_TOLLFRAUD_APP"

System Message: WARNING/2 (<string>, line 7); backlink

Inline emphasis start-string without end-string.

I knew I hadn't installed this application on the gateway, so where did it come from? I <a href="http://www.google.com/#hl=en&sugexp=ldymls&xhr=t&q=_ManagedAppProcess_TOLLFRAUD_APP&cp=32&pf=p&sclient=psy&site=&source=hp&aq=f&aqi=&aql=&oq=_ManagedAppProcess_TOLLFRAUD_APP&pbx=1&fp=d9008d84f286047">googled</a> for it and found a nice article at the Cisco website called <a href="http://www.cisco.com/en/US/tech/tk652/tk90/technologies_tech_note09186a0080b3e123.shtml">Toll-Fraud Prevention Feature in IOS Release 15.1(2)T</a>. This article describes how IOS 15.1 will now by default reject all incoming SIP calls until the IP address sending the initial INVITE has been explicitly added as something I'd call a "trusted peer".

One nice piece of wishful thinking from Cisco is this:

> When booting a version of IOS with the toll-fraud prevention application, > this is printed to the device's console during the boot sequence:

Following voice command is enabled: ..voice service voip ....ip address trusted authenticate

The command enables the ip address authentication on incoming H.323 or SIP trunk calls for toll fraud prevention supports.

Please use "show ip address trusted list" command to display a list of valid ip addresses for incoming H.323 or SIP trunk calls.

Additional valid ip addresses can be added via the following command line: ..voice service voip ....ip address trusted list ....ipv4 <ipv4-address> [</ipv4><ipv4 network-mask>] </ipv4>

As if these things all have serial consoles attached to them.

Anyway what's the easiest way to recognize calls being rejected like this?

Logging as mentioned above on the 5350 (or one of its sisters, the 5400, 5800 or any other Cisco "voice" capable hardware

INVITE messages being replied to with a 403 Forbidden with a Reason header containing a "Q.850 disconnect cause value of 21, which represents 'Call Rejected'"

Nokia E series phone on OpenSIPS based SIP platform

ramdyne — Thu, 07 Jan 2010 17:20:59 GMT

..raw:: html

<html><body><p>If you want to use the SIP client on a Nokia E or N series phone make sure the software on it is up to date. Then go to "Connection settings" and scroll all the way down to SIP/VoIP profile, create a new profile and fill in the requested values. The big one here is to NOT fill in the Proxy settings, only fill in the Registrar items.

</p></body></html>

Voice quality reporting for Cisco VoIP using FreeRadius

ramdyne — Fri, 20 Mar 2009 22:45:09 GMT

This is an, I hope, comprehensive writeup on how to configure a Cisco gateway to send RADIUS Accounting details to a RADIUS server running FreeRadius. Among other things, these RADIUS packets contain <a href="http://www.cisco.com/en/US/docs/ios/voice/cdr/developer/guide/cdrdefs.html#wp1011077">useful information about the quality of the audio</a> as perceived by the calling and called parties of the call.

First we have to configure the Cisco hardware to send the RADIUS packets. I'm using a Cisco AS5350XM configured to send only RADIUS accounting details at the end of the call. Note that although the configuration suggests as much, you're not required to use H.323, SIP will also work just as well.

aaa new-model
aaa group server radius voip-accounting
 server [ip address] auth-port 1812 acct-port 1813
 ip radius source-interface GigabitEthernet0/0
aaa accounting connection h323 stop-only group voip-accounting
radius-server host [ip address] auth-port 1812 acct-port 1813 key 7 [secret]
radius-server vsa send accounting

Note how I'm telling it basically the same thing twice. Apparently this is really necessary, haven't had the time to properly test. This was the easy part.

Setting "aaa new-model" is, as far as I know, required but it will also mess up the way logging in to your Cisco equipment works. Setting this will mean that you will need a username + password combination to log in and the enable password, instead of just a password and the enable password.

Now make sure FreeRADIUS is up and running on a server reachable by the Cisco hardware. Edit /etc/freeradius/radiusd and make sure that the "with_cisco_vsa_hack" is set to yes:

with_cisco_vsa_hack = yes

Edit /etc/freeradius/dictionary so that the Cisco dictionary is NOT specifically loaded

$INCLUDE        /usr/share/freeradius/dictionary

Add the following to the dictionary file to be able to use the values the Cisco equipment is sending you (there's lots more information in the RADIUS packets, this is just what I needed):

ATTRIBUTE       coder-type-rate         118     string  Cisco
ATTRIBUTE       hiwater-playout-delay   119     string  Cisco
ATTRIBUTE       lowater-playout-delay   120     string  Cisco
ATTRIBUTE       round-trip-delay        121     string  Cisco
ATTRIBUTE       late-packets            122     string  Cisco
ATTRIBUTE       lost-packets            123     string  Cisco
ATTRIBUTE       early-packets           124     string  Cisco

I had to make sure the numbers didn't overlap with the existing values already in the Cisco dictionary. This is kinda important, you don't want to end up with the wrong data in the wrong column. Swapping source and destination numbers is totally possible if you're not careful.

Now it's time to insert a record in the database. For some reason my colleague who setup the radius server inserted the query into /etc/freeradius/sql/mysql/dialup.conf (check the comments). There might be better places. If you only want to save the end of call records, make sure you have no other accounting queries active in the queries file:

accounting_stop_query = "INSERT INTO ${acct_table}
(RadAcctId,
 AcctSessionId,
 AcctUniqueId,
 UserName,
 Realm,
 NASIPAddress,
 CiscoNASPort,
 NASPortId,
 NASPortType,
 AcctStartTime,
 AcctStopTime,
 AcctSessionTime,
 AcctAuthentic,
 ConnectInfo_start,
 ConnectInfo_stop,
 AcctInputOctets,
 AcctOutputOctets,
 CalledStationId,
 CallingStationId,
 AcctTerminateCause,
 ServiceType,
 FramedProtocol,
 FramedIPAddress,
 AcctStartDelay,
 AcctStopDelay,
 H323GWId,
 H323CallOrigin,
 H323CallType,
 H323Setuptime,
 H323ConnectTime,
 H323DisconnectTime,
 H323DisconnectCause,
 H323RemoteAddress,
 H323VoiceQuality,
 H323ConfId,
 Timestamp,
 codec,
 hiwater,
 lowater,
 roundtrip,
 plate,
 plost,
 pearly,
 DestinationId )
VALUES (
 '',
 '%{Acct-Session-Id}',
 '%{Acct-Unique-Session-Id}',
 '%{SQL-User-Name}',
 '%{Realm}',
 '%{NAS-IP-Address}',
 '%{Cisco-NAS-Port}',
 '%{NAS-Port-Id}',
 '%{NAS-Port-Type}',
 from_unixtime(unix_timestamp('%S')-%{Acct-Session-Time}),
 '%S',
 '%{Acct-Session-Time}',
 '%{Acct-Authentic}',
 '',
 '%{Connect-Info}',
 '%{Acct-Input-Octets}',
 '%{Acct-Output-Octets}',
 '%{Called-Station-Id}',
 '%{Calling-Station-Id}',
 '%{Acct-Terminate-Cause}',
 '%{Service-Type}',
 '%{Framed-Protocol}',
 '%{Framed-IP-Address}',
 '0',
 '%{Acct-Delay-Time}',
 '%{h323-remote-address}',
 '%{h323-call-origin}',
 '%{h323-call-type}',
 '%{h323-setup-time}',
 '%{h323-connect-time}',
 '%{h323-disconnect-time}',
 '%{h323-disconnect-cause}',
 '%{h323-remote-address}',
 '%{h323-voice-quality}',
 '%{h323-conf-id}' ,
 '%{Timestamp}',
 '%{coder-type-rate}',
 '%{hiwater-playout-delay}',
 '%{lowater-playout-delay}',
 '%{round-trip-delay}',
 '%{late-packets}',
 '%{lost-packets}',
 '%{early-packets}',
 '%{remote-media-address}'
)"

Note that we only added the last few SQL parameters and somehow FreeRADIUS is able to provide the rest. Make sure you have the correct table name and columns configured (double/triplecheck the query and your table).

The column H323VoiceQuality will contain the so called ICPIF impairment factor. A small writeup of what that means is <a href="http://ccie11440.blogspot.com/2007/11/calculated-planning-impairment-factor.html">here</a>.