[Spce-user] New: cant figure out some things
dave at optionsdsl.ca
Wed Sep 7 09:23:31 EDT 2011
I will get that dump ASAP. Out in the field now and I think you guys are in a wildly different time zone :).
On 2011-09-07, at 8:54 AM, Skyler <skchopperguy at gmail.com> wrote:
> On Wed, 2011-09-07 at 08:35 -0400, Dave wrote:
>> Actually that was a bad example. If I try to dial an e164 number the results are the same.
> Interesting. So if you dial a valid telephone number ie: 19059631054
> you're getting the same Forbidden To?
>> What do you mean by peering rules? I have one for the outbound provider it's just a default one as per the handbook. The inbound provider one has no rules at all
> In 'Sip Peerings' within admin you should have a peering contract
> assigned and a Sip Peerings Group created. In the Sip peerings group,
> you should have Peering Servers and Peering Rules. The Peering Rule
> right now sounds to be blank (like in the docs).
> With this setup, a call to any number (e.164 or other) would go
> upstream to your peer if not found locally. Which will work fine, but
> you are saying that a valid e.164 is also refused?
> Really its not a problem to not have a peering rule in place to
> block/not route an invalid e.164 from going upstream at this point. It
> will be denied as it should but in future when your ears are wet ;) you
> can play with the peering rules for better routing and call handling.
> What does tcpdump look like on a call with to a valid e.164?
>> On 2011-09-07, at 8:26 AM, Skyler <skchopperguy at gmail.com> wrote:
>>> On Wed, 2011-09-07 at 07:50 -0400, Dave Massey wrote:
>>>> I attached a tcpdump of a phone call from a softphone registered to SPCE and attempted call from that phone to the SIP provider/PSTN
>>> 905888 is not a valid e.164 number, hence "Forbidden To". Looks like
>>> you are dialing 905888 on your iPhone and SPCE cannot find a local user
>>> '905888' so it tries the peering list. Which appears to be set as
>>> 'blank' for peering rules so the call is sent upstream ... then denied
>>> as '905888' is an invalid e.164 address.
>>> The problem is that you don't have any peering rules set for your peer.
More information about the Spce-user