[Spce-user] Network Configuration

Fri Apr 19 09:48:52 EDT 2013

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sipwise.com/pipermail/spce-user_lists.sipwise.com/attachments/20130419/8bf8fcb7/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: postbox-contact.jpg
Type: image/jpeg
Size: 1201 bytes
Desc: not available
URL: <http://lists.sipwise.com/pipermail/spce-user_lists.sipwise.com/attachments/20130419/8bf8fcb7/attachment-0003.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: postbox-contact.jpg
Type: image/jpeg
Size: 1143 bytes
Desc: not available
URL: <http://lists.sipwise.com/pipermail/spce-user_lists.sipwise.com/attachments/20130419/8bf8fcb7/attachment-0004.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: postbox-contact.jpg
Type: image/jpeg
Size: 1221 bytes
Desc: not available
URL: <http://lists.sipwise.com/pipermail/spce-user_lists.sipwise.com/attachments/20130419/8bf8fcb7/attachment-0005.jpg>