[Serusers] Need way to specify SOURCE IP address on packets of SIP messages being emitted by SER

Greger Viken Teigre greger at teigre.com
Sat Mar 8 09:57:05 CET 2008


Hi Frank,
You have my full sympathy. The old PSTN (and H323) guys say "SIP has so 
many incompatibilities". It's easy to reduce incompatibilities when 
there's  only one way to do things... But trying to bridge new ways of 
doing things in SIP with PSTN seems to take more time than it deserves.

Kudos to you for your thorough description of the problem. It should be 
posted on iptel.org as an example of why you should stay away from 
PSTN... (joke: I know it cannot be avoided). (And I won't ask why you 
need SER in there at all...)

My knee-jerk reaction would be to try to take SER out of the picture, 
not use it to solve the problem. Why? Because one day you want to get 
rid of that terrible provider of TDM-style SIP services and swap it 
would something more "SIP-like". Also, if you can remove the complexity 
into a separate layer, you are better off maintaining the whole thing. 
That being said, what you are looking for came in SER 2.0: 
force_send_socket() 2.0 will also store the incoming interface and reply 
to the correct one automatically (instead of using one interface as source).

So, some ideas that may or may not work in your situation:
- Use iptables to rewrite SIP packets (you create your own bogus ip 
addresses for the switch, then use an outgoing packet rule to pick up 
the bogus dst address, rewrite to the tdm ip AND change the src ip)
- Use one SER instance per company and only listen to a pair of IP 
addresses for each instance
- Use lcr as a starting point and write your own module that does the 
matching from database. I think Andreas Graning wrote an extension to 
the lcr module that added some new matching criteria that you might use

It may be that I don't see the full picture, but I think iptables would 
be the easiest. Use lcr module to map into the bogus switch addresses 
(then you can dynamically reload).  Adding a new company will be a lot 
easier, because you don't have to change ser.cfg and restart ser, you 
just add a new virtual ip in lcr db table, add a new iptables ruleset 
and nudge ser to reload lcr table.

Hope it helps.
g-)

Frank Durda IV wrote:
> I have a problem that I thought SER could solve but now that I
> need it, the method isn't obvious.
>
> First, as an example, let's say I have three independent
> organizations running Asterisk boxes, which send me
> the SIP and RTP audio for calls.  Let's call them
>
> Company A       Asterisk box at 31.1.2.3
> Company B       Asterisk box at 42.4.5.6
> Company C       Asterisk box at 53.7.8.9
>
> So they are one side of the SER box all communicating SIP to a single
> interface.   On the other side is a TDM PSTN switch capable of
> accepting SIP calls.  The PSTN switch has exactly one IP address,
> which we will call 101.2.3.4.
>
> Inside the PSTN switch, for calls originating in TDM headed to SIP,
> a "Route List" directs calls for a given trunk group (everything is
> visualized in TDM terms even if the terms don't really apply) to a
> specific IP address, where the SIP INVITE should go for this call.
>
> In the case of a SIP to TDM call, when an INVITE comes in, the PSTN
> switch looks through that list of Routes that point to IP addresses
> and when it finds an IP address match, it knows which trunk group to
> associate with this call for billing.  This also acts as a simple
> friend/foe mechanism, because if there is no route pointing at your
> SIP source, it rejects your INVITES.
>
> So, if Company A, B and C were communicating directly with the PSTN
> switch (no SER), you would simply need three trunk groups where
> each IP address pointed directly to the Asterisk boxes at those
> companies, like this:
>
> TGN     SIP IP
> 1111 -> 31.1.2.3
> 2222 -> 42.4.5.6
> 3333 -> 53.7.8.9
>
> and all would be well.  However, when you insert a SER box between
> those the Asterisk boxes belonging to those companies and the
> PSTN switch, problems arise.
>
> I originally decided to address the issue by establishing two groups
> of three IP addresses, one set that the Asterisk servers would
> individually send their INVITEs to, and three that the PSTN switch
> could send its INVITES to.  SER already supports the idea of
> listening on numerous IP addresses, so that was easy (although the
> documentation for "listen" and "alias" is weak and a code review was
> needed to determine what alias actually did, something other than
> what the "alias" option of an ifconfig command does...).
>
> Anyway, we have a setup like this:
>
>                          interface    interface      interface
>                          em1 on SER   em0 on SER     sig0 on PSTN
>                          10.1.0.0/16  10.2.0.0/16    101.2.3.0/28
>
> Company A 31.1.2.3  ---- 10.1.2.3 SER 10.2.0.1 ----  101.2.3.4
>
> Company B 42.4.5.6  ---- 10.1.5.6 SER 10.2.0.2 ----  101.2.3.4
>
> Company C 53.7.8.9  ---- 10.1.8.9 SER 10.2.0.3 ----  101.2.3.4
>
> Inside the ser.cfg, it is simple enough to rewrite the "host address"
> (where you want the packet to go) to reflect the new destination
> once that is determined, and for TDM to SIP calls work okay from the
> perspective of the PSTN switch, but then it really never cared whether
> the SER box was there or not.  As long as the PSTN switch knows who to bill,
> it is vaguely happy.  To accomplish that, the routes inside the PSTN
> switch were altered to point to the SIP IP addresses that
> the PSTN switch would have contact with, as in:
>
> TGN     SIP IP
> 1111 -> 10.2.0.1
> 2222 -> 10.2.0.2
> 3333 -> 10.2.0.3
>
> (Changing the IPs in the PSTN switch turns out to be a non-trivial
>  operation.)
>
>
> The more serious problem arises with a call going SIP to TDM, because
> when the SER box sends a packet on to the PSTN box at 101.2.3.4,
> it needs to also re-write the SOURCE IP of the packet to reflect the
> appropriate IP address on the em0 interface, not just the
> first IP address that is discovered on the interface.
> What it does right now is send everything out under the first IP
> address listed on that interface, usually 10.2.0.1, so calls
> fail to set up properly as the replies go back to company A even
> if coming from company B or C.
>
> Is there a function in SER that lets you set the right address to use
> on outgoing packets?   As all of the IP addresses that would be used
> are in fact ones set on that interface, it should be just a
> question of setting the right one, but I haven't found a function for
> ser.cfg or loadable module that clearly states that it will do this.
>
> So in summary, when Company B sends an INVITE to 10.1.5.6
> from their 42.4.5.6 system, I need to have SER send an invite to
> 101.2.3.4 from 10.2.0.2 and never any other address that happens
> to be on that same interface.  And when the reply to the INVITE comes
> to 10.2.0.2 from 101.2.3.4, I need SER to forward it on to 42.4.5.6
> from 10.1.5.6.
>
> Note that while I am showing an example with three companies, there
> will be dozens, even hundreds of unique IPs involved here, hence
> the enormous netblocks set aside for each interface on the SER box.
>
> I'm certainly open to alternative methods to get SER to alter the
> headers of the packets it forwards exactly as needed, but keep in
> mind that I have basically zero control over how the PSTN switch
> does things, and it has exactly one IP address (three actually, but
> one does all the SIP work) that you send to and it originates from,
> yet is keenly interested in where packets it receives came from
> (for billing purposes) so you can't expect any help from the
> PSTN switch side.
>
> So is there a function callable from ser.cfg to force set the SOURCE
> IP address on SIP messages on a message by message basis?
> We are currently using ser-0.9.6.
>
> Thanks for your assistance,
>
> Frank Durda
>
>
> _______________________________________________
> Serusers mailing list
> Serusers at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers
>
>
>   
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 2844 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20080308/0188dc2d/attachment.bin>


More information about the sr-users mailing list