[Spce-user] Network Configuration

Fri Apr 19 10:00:12 EDT 2013

Hi Deon,
sorry for the stupid question, have you assigned the rewrite rules set
to your subscribers or to your domain ?

This is how the rewrite rules works:

1. Let's suppose you make a call between 2 internal subscribers

2. You have assigned the rewrite rules set 'DEFAULT' to both of these
subscribers

3. A call B

4. spce take the caller and apply the INBOUND REWRITE RULES SET
'DEFAULT' to caller number and callee number .

5. spce make some other test and lookup the callee from database (call
is local).

6. spce apply OUTBOUND REWRITE RULES SET 'DEFAULT' to caller number and
callee number .

7. scpe forward the call to the callee.

Now outbound calls:

2. You have assigned the rewrite rules set 'DEFAULT' to local caller and
rewrite rules set 'MY_PEER' to your sip peer

3. A call B

4. spce take the caller and apply the INBOUND REWRITE RULES SET
'DEFAULT' to caller number and callee number .

5. spce make some other test and lookup the callee from database (call
is NOT local -> outbound call).

6. spce apply OUTBOUND REWRITE RULES SET 'MY_PEER' to caller number and
callee number .

7. scpe forward the call to the callee.

br,
Daniel

On 04/19/2013 03:48 PM, Deon Vermeulen wrote:
> Hi Daniel
> 
> I was confused with the previous mail and did not give you the complete
> rule set.
> 
> Here with my complete Rewrite Rules for completeness.
> 
> Inbound Rewrite for Caller:
> ˆ(00|\+)([1-9][0-9]+)$        \2
> ˆ0([1-9][0-9]+)$                   ${caller_cc}\1
> ˆ([1-9][0-9]+)$                     ${caller_cc}${caller_ac}\1
> 
> Inbound Rewrite for Callee:
> ˆ(00|\+)([1-9][0-9]+)$        \2
> ˆ0([1-9][0-9]+)$                   ${caller_cc}\1
> ˆ([1-9][0-9]+)$                     ${caller_cc}${caller_ac}\1
> 
> Outbound Rewrite for Caller:
> ˆ0([1-9][0-9]+)$                 +44\1        (I see I made a typo here
> as I have to strip "0" from CLI and append +44 for International CLI)
> 
> Outbound for Callee:
> ˆ(00|\+)([1-9][0-9]+)$             \2
> 
> 
> Looking at the above I guessing I don't properly understand the Rewrites
> working order?
> 
> 
> Thanks again for the assistance.
> 
> 
> Kind Regards
> Deon
> 
> 
>> Daniel Grotti <mailto:dgrotti at sipwise.com>
>> April 19, 2013 2:38 PM
>> Hi Deon,
>>
>> Your call come from user F=sip:0839999989 at 192.168.0.250, so his Inbound
>> rewrite rules will be applied
>>
>> INBOUND REWRITE RULES CALLER
>> INBOUND REWRITE RULES CALLEE
>>
>>
>> after that the system will apply the OUTBOUND REWRITE RULES set of the
>> callee (or the peer if the call is an outbound call).
>>
>> In your case the problem is with inbound rewrite rules for callee for
>> the user 0839999989, because his rewrite rules doesn't rewrite the
>> callee 0044113001417 into 44113001417.
>>
>> So you should have a rewrite rules like:
>>
>> ^(00|\+)([1-9][0-9]+)$ \2
>>
>> to strip 00 from callee, and you don't have a rules like this afaics.
>>
>>
>> br,
>> Daniel
>>
>>
>>
>>
>> _______________________________________________
>> Spce-user mailing list
>> Spce-user at lists.sipwise.com
>> http://lists.sipwise.com/listinfo/spce-user
>> Daniel Grotti <mailto:dgrotti at sipwise.com>
>> April 19, 2013 2:03 PM
>> So, in this case you need to check you Inbound Rewrite Rules for Calee
>> as the callee is 0044113001417 instead of 44113001417, as your alias:
>>
>> No matching rewrite rules for '0044113001417' found
>>
>>
>> br,
>> Daniel
>>
>>
>>
>> _______________________________________________
>> Spce-user mailing list
>> Spce-user at lists.sipwise.com
>> http://lists.sipwise.com/listinfo/spce-user
>> Daniel Grotti <mailto:dgrotti at sipwise.com>
>> April 19, 2013 1:02 PM
>> Hi Deon,
>>
>> The call fails to select a proper PSTN gateway for:
>>
>> caller: sip:44839999989 at 192.168.0.250
>>
>> callee: sip:0044113001417 at 192.168.0.250;transport=udp
>>
>>
>> It looks like you don't have any eligible peering rule for this
>> callee/caller.
>> How your Peering rules looks like ?
>>
>> br,
>> Daniel
>>
>>
>>
>> _______________________________________________
>> Spce-user mailing list
>> Spce-user at lists.sipwise.com
>> http://lists.sipwise.com/listinfo/spce-user
>> Deon Vermeulen <mailto:vermeulen.deon at gmail.com>
>> April 19, 2013 12:51 PM
>> I think I might  have resolved the issue to run media-proxy on
>> multiple interfaces on the same machine.
>> Once I can confirm this is working will I elaborate on how I achieved
>> this.
>>
>> I'm facing a problem though and it is as follows:
>>
>> I'm registered via SIP Client on my Internal Network
>> 0839999989 at 192.168.0.250.
>>
>> One of the Carriers is registered to fake subscriber
>> 0839999999 at 10.222.0.250 with Alias 44113001417.
>>
>> I've made 100% sure that my re-write rule is set on both the subscribers.
>>
>> I make call to 0044113001417 , but call fail with " No PSTN gateways
>> available " in the proxy log.
>>
>> I'm also not 100% sure why it is not calling to the local hosted
>> domain 10.222.0.250?
>>
>> The LB is listening on 10.222.0.250:6090.
>>
>> Attached the output of the call within the proxy log.
>>
>>
>> Thanks again for any assistance.
>>  
>> Kind Regards
>> Deon
>> Jon Bonilla (Manwe) <mailto:jbonilla at sipwise.com>
>> April 18, 2013 11:14 PM
>> El Thu, 18 Apr 2013 14:04:56 +0200
>>
>>
>> I have found this requirement, where the peer requires a vpn or any other
>> tunnel scenario to be established to send the traffic and they will
>> only accept
>> traffic from the tunnel. Most common carrier asking for this is
>> British Telecom
>> (BT)
>>
>> The extra_socket option does not work here because the rtp will still
>> be sent
>> and received in the default ip address, which is not the one used for the
>> tunnel.
>>
>> 2 ways of dealing with it:
>>
>> * Create the tunnel in your router. This is the "righ way" (imho).
>> I've also
>> seen operator purchasing a small cisco router just for this function. It's
>> easy and cheap.
>>
>> * Use an aditional spce to route the calls between the tunnel and the main
>> spce. This is the same Thilo achieves with his kamailio-sems combo. This
>> additional spce will listen in the tunnel address and that ip will be
>> routeable from/to the main spce's default ip address.
>>
>> _______________________________________________
>> Spce-user mailing list
>> Spce-user at lists.sipwise.com
>> http://lists.sipwise.com/listinfo/spce-user