Ribbon: Advanced SIP manipulation

390

Hi folks,

I came around some „special“ way to use the SMM feature of the Ribbon SBC Edge series when I needed to connect an SBC with the provider sipgate in Germany. It was not that hard to build a SIP-Trunk connecting to their platform.

The more interesting topic was the presenting of the correct calling number towards the called destination. When I first configured the (very plain) routing / transformation, I showed up with my main line and not the extension at the destination. Basically I ran into some „Manipulation is done twice“ issue.

So I want to share some pieces and would be happy if anybody with a better setup/idea pings me for sure 😉

I re-created the setup in my lab, so basically it is:

PhonerLite (local SIP client) <-> Ribbon SBC Edge <-> ISP sipgate

First I configured the SBC to accept a registration locally and connected the PhonerLite to the SBC:

• 

• 

• 

The next step was – obviously – to set up the SIP trunk connection towards sipgate. I won’t share any full config as I cannot guarantee that this is going to work in e.g. one year or later, so please always find your own way to connect to this ISP (or check their documentation)

• 

• 

As you can see, there is an outgoing SIP Message Manipulation Table marked in the sipgate Signalling Group. This is the part I am going to talk about a bit more in depth now.

I ran into the problem that sipgate forced me to send them my sipgate -username (118xxxxxx) in the FROM-Header towards their plattform. So I tried to send them the calling information using the P-Preferred-Identity.

Basically, I made an outbound SMM which copies the value out of the FROM-Header and puts it into the PPI.

• 

Afterwards I modified the FROM to represent my sipgate user account:

• 

Ready to go. I started a call from the PhonerLite which provided its calling number in the FROM header. It was processed through Transformation/Call Routing and hitted the SIP Message Manipulation. So as mentioned:

1. the FROM was copied into the PPI
2. the FROM was overwritten with the sipgate account

• 

What happened then was that I got a 407 Proxy Auth from sipgate and the SBC was sending another INVITE to sipgate, using the provided nonce and providing the full user-creds (password, response, etc..)

But what was this? On my destination phone I got the main line on the display.

As you can see in previous screenshots the extension used on my PhonerLite ends with -684. So something was wrong either with sipgate or with my SBC. So I checked the logs again. After getting the challenge request from sipgate the SBC sent out a second INVITE to them. But this time I had my sipgate account „11xxxxxxxx“ in both headers: FROM and PPI.

• 

How was this possible?

I checked the log file mainly in the region above the displayed INVITE. And I sawthat my outgoing SMM was done a second time. This means in the first ste p I copied the calling number and pasted it into PPI. (all good)

Then I replaced the FROM with the account of sipgate (all good²)

But when getting the challenge request, the SBC will do the same again.

Means another time the device will copy the FROM-header (which is already 11txxxx – the username of sipgate) and put it into the PPI. And then it will replace the already manipulated FROM header with the same value again – which is a step idc about at this point.

• 

At this point I needed a little break and re-thought all steps taken so far. What I need is the username in the FROM header. What I also need is a (dynamic) way to send the calling numbers in the PPI header. There wouldn’t be any benefit to build something to insert calling number(s) statically into the PPI.

I checked the log again and saw something logical, which one forgets pretty easy:

• 

I realized that my transformation tables used for this outgoing call were only processed once. For sure this is a logical thing because the transformation is part of the routing logic. And once the decision was made there is no reson to go through this part of the routing engine again.

So let’s summarize:

1. We have SMM (SIP Manipulation) in place, which does 80% of what we need in theory
2. These will be processed for each SIP paket they apply to – one can limit them to e.g. only INVITE, RINGINGs or whatever btw.
3. We have Transformation tables (always part of a routing decision) which are processed once per call flow, regardless of any challenge request.

So why not combining both parts to achieve our target?

I added a rule in my Transformation table which does nothing else but copying the calling address (calling number stored in FROM header) and pastes it into a value.

• 

Afterwards I changed my PPI rule, so that the PPI is not going to be build using the FROM URI information. Instead of this the PPI is modified using the previously stored value.

• 

At the very end I did another test call and it worked fine. So this is one way to work with values and headers on the Ribbon SBC series. There is much more stuff to share – especially SIP Manipulation combined with conditions (coming soon)

I hope this might help somebody to do similar stuff and to get the correct information displayed by using variables in the Transformation tables.

Cheers!

•