[border-controller-none]
    type=friend
    nat=yes
    host=10.0.0.1
    insecure=port,invite
    promiscredir=yes
    context=example-sip

[border-controller-anon]
    type=friend
    nat=yes
    fromuser=Anonymous
    fromdomain=anonymous.invalid 
    host=10.0.0.1
    insecure=port,invite
    promiscredir=yes
    context=example-sip

[border-controller-unkn]
    type=friend
    nat=yes
    fromuser=Unknown
    fromdomain=unknown.invalid 
    host=10.0.0.1
    insecure=port,invite
    promiscredir=yes
    context=example-sip

This allows me to turn presentation into a subroutine in extensions.conf...


[example-presentations]

; --- anon bogon present pai ---

  exten => 71,1,NoOp()
  exten => 71,n,SIPAddHeader(P-Asserted-Identity ) 
  exten => 71,n,SIPAddHeader(Privacy: header\; session)
  exten => 71,n,Set(CALLERID(all)=anonymous <>)
  exten => 71,n,Set(PrivacyInd=anon)
  exten => 71,n,Return()

... and this can in turn be called by a context...

  exten =>_XX*.,1,NoOp()
  exten => _XX*.,n,Gosub(example-presentations,${EXTEN:0:2},1)              
  exten => _XX*.,n,Dial(SIP/+${EXTEN:3}@border-controller-${PrivacyInd}) 
  exten => _XX*.,n,Hangup()

... which greatly simplifies a lot of testing by turning presentations into reusable scenarios and is very handy for spoofing privacy headers in a lab environment.

email: Josh Fuller | tag: /technology/telecommunications/voip | permanent link | Share on Facebook

Sat, 12 Apr 2008

lookaround to cut trailing digits out of a phone number

If you have a sip:+15558675309123@foo.bar number and you need to cut out some digits out of the +15558675309123 once you've parsed it out regex lookaround can be your best friend.

Try using ^(\+.*)(?=...$) in your parser and you will instantly find your needed results of +15558675309 are available.

email: Josh Fuller | tag: /technology/telecommunications/voip/regex | permanent link | Share on Facebook

Sat, 08 Mar 2008

OpenIMS

http://www.openimscore.org/

Cool.

email: Josh Fuller | tag: /technology/telecommunications/voip | permanent link | Share on Facebook

Mon, 18 Feb 2008

A VoIP troubleshooting tool manifesto for the Next Generation

We in the telecommunications world are at a strange crossroads--- a "singularity," for lack of a better term--- where legacy circuit switched voice and current generation packet switched voice exist within one constantly evolving and relatively unstable network platform.

In the legacy world call processing happens in a fairly linear fashion: telephony switches send messages back and forth over common signalling points using well defined protocols. Voice circuits always remain in an idle state waiting for control messages that "turn on" the voice path.

In the "Now Generation," complex network elements are commissioned within our ever-growing data complexes at an exponential rate. This current technology does not use signalling formats or media paths that allow existing legacy telephony monitoring tools to be used for performance analysis, triage of call outages and day-to-day operational readiness and maintenance. True "Next Generation" call processing and signalling is far less linear than traditional telephony. Existing network services such as bind are retooled to become services such as enum. In a purely IP world media and signalling paths are no longer static. Voice and signalling paths are created only when needed and those resources are released back to a pool of loosely interconnected devices once no longer required.

Servers chop media into small packets with an address on each one telling the network devices where to send them. Inside of each packet is a payload. The payload is a piece of the media transmitted inside the packet. The sending server sends the packet to a nearby router and forgets about it.

The nearby router send the packet to another router that is closer to the recipient server. When the receiving server finally gets the packets (which may have all taken completely different paths to get there), it uses instructions contained within the packets to reassemble the data into its original state.

Vendor monitoring technologies partially fill the surveillance gaps in networks but do not support open and extensible signalling and media protocols due to architecture "racism." Oddly, the basic media formats are almost always thrown away due to cost savings in server storage.

Bit flushing is also a quick and dirty way to increase monitoring probe performance without actually using scalable hardware. Not capturing the media packets is a dangerous and confusing choice which is the network equivalent of throwing the baby out with the bathwater. Existing call processing tools have a very poor capacity to measure in-band signalling methods such as RFC-2833 DTMF. The all-important DNS queries--- the glue that makes enum NAPTR possible--- are often completely invisible. At a bare minimum media must always be watched for the possible existence of tertiary signalling.

Sadly, the true issue isn't something as simple as vendor lock-in, budget constraints or protocol exclusion. The real issue is that there is no such thing as a switch anymore, a voice path or a circuit.

The network itself is the point that must be monitored.

Read that again. Drill it into your brain. The network itself is the point that must be monitored.

Why?

VoIP is a moving target with numerous protocols loosely gathered together in a server farm pretending to be a traditional telephony network.

A single call progressing through this server farm may use many different protocols and transport mechanisms for completion.

For example: cdp; skinny; sccp; sgcp; rvp/ip; h.245; h.225; megaco; h.248; dns; enum; sip; sip-t; rfc-2833 dtmf; inband signalling; rtp; rtcp; rtsp; t.38; t.30; ulaw; alaw; gsm; gcp; ss7; mf; unistim; mgcp; SDP envelopes; sigtran; q.931; radius; h.323.

Now for the real mind blowing experience: By the time you finish reading the list it has already become obsolete.

Our seemingly impossible challenge is to develop and deploy tools that both graphically and logically depict a call from end to end on a network that has numerous traditional and non-traditional signalling and media ingress and egress points.

Since IP networks effectively forget about the packets they have already handled it becomes impossible to troubleshoot VoIP calls without being able to disassemble, rethread and reassemble transmitted packets into a cohesive call end-to-end.

Integration with legacy networks such as traditional TDM causes even more confusion as the intersecting technology boundaries create logically and functionally different calls in the network.

In the past, I have suggested that the solution for this is an open-standards based unix tool with the capacity to:

capture a feed from all network probes in parallel
intelligent packet capture and merge with no duplication of packets
capable of capturing ALL protocols associated with VoIP and TDM

In a perfect world this would be a real time active capture device that creates both a visual depiction and a packet-capture dump of a call. These storage files should be in an open and extensible format such as tcpdump. At a minimum this tool should include every single leg of the call from the ingress to egress point of a voice network.

If I were to create such a system I would leverage open-source products (such as sipP, Wireshark, Asterisk and Sip Scenario) to create a distributed packet capture tool while avoiding vendor hardware and software lock-in. I would attract and retain in-house resources solely tasked to create a customized open-source platform capable of understanding both "next generation" and legacy technologies.

Any system I would source from a vendor would have to support open standards and would have to be based on an easily upgraded and extensible technology geared towards an eventual migration to IMS. I also would urge organizations responsible for deployment of VoIP infrastructure to restructure their teams that work on "Next Generation" services into cohesive organizations to remove interdepartmental roadblocks, compartmentalization of knowledge and entrenched corporate beauracracy.

Finally, I would forbid any potential vendor from treating Internet Explorer as a personal extension of their command and control environment.

email: Josh Fuller | tag: /technology/telecommunications/voip | permanent link | Share on Facebook

Sat, 02 Feb 2008

Using sipP as a Call Generator to load test Asterisk on Ubuntu Server

Using sipP as a Call Generator to load test Asterisk on Ubuntu Server

Note: this requires you to have access to more than one Asterisk server within a network! You also need access to the superuser account.

Preparation and Existing Configuration Backup

Log in to your Asterisk server and become superuser with sudo -s
Change to the superuser's home with cd ~
Backup the current Asterisk configs with tar czvf asterisk-configs.tgz /etc/asterisk
Ensure sipP is installed with apt-get install sip-tester

Test Configuration

Map out the scenario you plan to test.

+--------+ call => +--------+
|Asterisk|---------|Asterisk|
|Server  |---------|Server  |
+--------+ <= call +--------+

Set up your Asterisk extensions to answer and hangup in each server

extensions.conf example

[default]

  exten => service,1,Answer()
  exten => service,n,Dial(SIP/1234@remote-peer)

  exten => t,1,Hangup()

[sipp]

  exten => 1234,1,Answer()
  exten => 1234,n,Milliwatt() ; this provides the media for rtp loopback

sip.conf example

[sippuac]
type=friend
username=sippuac
host=dynamic
context=sipp
insecure=port,invite
nat=yes
promiscredir=no

Connect to each server and set up some background sipP sessions.

From each Asterisk server (with Asterisk running)

sipp `ifconfig eth0|grep "inet addr"|cut -d: -f2|awk '{ print $1}'` -i `ifconfig eth1|grep "inet addr"|cut -d: -f2|awk '{ print $1}'` -d 1s -l 100 -aa -mi `ifconfig eth1|grep "inet addr"|cut -d: -f2|awk '{ print $1}'` -rtp_echo -nd -r 12 -bg

This generates about 12cps with a call duration of one second. You can use the -bg flag to keep the calls running in the background.

Start tshark on a system that can see the entire network

tshark -i capture eth -r "sip" -w name of file.cap

Wait while test completes

killall sipp on any server where you had it running and [ctrl]-[c] the tshark session
save data

email: Josh Fuller | tag: /technology/telecommunications/voip | permanent link | Share on Facebook