[Spce-user] Network Configuration
Daniel Grotti
dgrotti at sipwise.com
Fri Apr 19 09:38:43 EDT 2013
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
On 04/19/2013 03:30 PM, Deon Vermeulen wrote:
> What I don't understand is that I have the Outbound Rewrite Rules set
> for Callee as well as Caller on the fake subscriber as well as on the
> registered subscriber I'm calling from:
>
> Default Rewrite Rule (This is set on the Subscriber for Local/National
> Calls)
> Outbound Rewrite for Caller:
> ˆ0([1-9][0-9]+)$ | 44\1 | CLI to E.164
>
> Outbound Rewrite for Callee:
> ˆ0([1-9][0-9]+)$ | ${caller_cc}\1 | National
> to E.164
>
>
> International Rewrite Rule (This is set on the fake Subscriber for
> International Calls to and from this Carrier)
> Outbound Rewrite for Caller:
> ^([1-9][0-9]+)$ | +\ | E.164 to
> International
>
> Outbound Rewrite for Callee:
> ˆ(00|\+)([1-9][0-9]+)$ | \2 | International
> to E.164
>
>
> I just did a random test to call 44113001417 on a fake subscriber on the
> same domain, but I still get the exact same errors:
>
> - No matching rewrite rules for '0839999989' found
> - No matching rewrite rules for '44113001417' found
> - No PSTN gateways available
>
> Please correct me if I'm wrong but it's not supposed to look for a
> gateway if the destination is local? In this case an Alias.
> I also don't understand why any of the Rewrite Rules are not hit at any
> stage of the call setup?
>
>
> Kind Regards
> Deon
>
>> 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
>> Thilo Bangert <mailto:thilo.bangert at gmail.com>
>> April 18, 2013 1:04 PM
>> On Thursday, April 18, 2013 11:58:02 AM Deon Vermeulen wrote:
>>> Hi
>>>
>>> Can anyone please help me to achieve the following network configuration:
>>>
>>> PROVIDER 2
>>>
>>>
>>> SIP TRUNK
>>>
>>>
>>> Internal Network ---- SIP TRUNK ----- SPCE ----- SIP TRUNK -----
>>> PROVIDER 1
>>>
>>>
>>> SIP TRUNK
>>>
>>>
>>> PROVIDER 3
>>>
>>
>> we have solved this by having provider specific peering gateways, consisting
>> of a kamailio and sems combo on a different (virtual) host.
>>
>> kind regards
>> Thilo
>>
>>
>>> Thanks a lot.
>>>
>>> Kind Regards
>>>
>>> Deon
>>
>> _______________________________________________
>> Spce-user mailing list
>> Spce-user at lists.sipwise.com
>> http://lists.sipwise.com/listinfo/spce-user
More information about the Spce-user
mailing list