[Spce-user] best practices on delivering SIP trunks to customers and individual registrations where endpoints on private IP

[Stephen Donovan]

to expand on what I posted earlier...


I've found the problem with calling from a pbx to registered subscriber:  When e164 to ruri option is selected to send DIDs to the PBX, this also normalizes the invite to an on net subscriber to include the 1


e164 to ruri on, INVITE:16623184122 at 10.x.x.x


e164 to ruri off, INVITE:6623184122 at 10.x.x.x


It is my understanding this function is to send the e164 number instead of the subscriber username on inbound calls, not anything else.


My question is, is there a way to normalize the invites with a rewrite rule or other configuration??  Or is there a way to send the e164 number to the subscriber where needed and NOT send e164 in the invite to another subscriber?


sipwise version is 2.8, with latest updates, freepbx is on the trunk that requires e164 to ruri, arris tm602g cable emta with sip firmware is the registered subscriber.  The Arris device responds to the invite with busy if the number in the invite request does not exactly match the username it is registered with.  In our case, we do the area code + number without the country code, I have hundreds of devices out there registered like this.  I did test my mta at home, changed it to register with a username of 16623184122 and all works as expected.


On the rest of the issues I posted about, I have learned that the only way to really do sip trunking with a mitel pbx is to place an sbc on site.  I can make everything work well on my trunk by running the traffic over a tunnel to the customer and turning on rtp proxy, however, the other provider this customer has refuses to proxy rtp, breaking calls that come in one trunk and forward out another.  The solution there should be to do an sbc with both trunks and deliver a single trunk to the customer's PBX.



Stephen

________________________________
From: Spce-user <spce-user-bounces at lists.sipwise.com> on behalf of Stephen Donovan <stephen at belzonicable.net>
Sent: Sunday, May 01, 2016 10:38:35 AM
To: 'spce-user at lists.sipwise.com'
Subject: [Spce-user] best practices on delivering SIP trunks to customers and individual registrations where endpoints on private IP

Here is the scenario:

Small cable operation.


1.       Residential customers have Arris emta in 10.15.xxx.xxx. They have direct access to sipwise box which is on a public IP.  These customers have no trouble making or receiving calls, or talking to each other (subscriber to subscriber)


2.       Hosted PBX customers have asterisk VMs with public IP addressed and have a subscriber built for them with a static registration and their IP as a trusted source.  These can make and receive calls no problem amongst themselves and the PSTN.



3.       External SIP trunk customer.  I have an Adtran TA908e on site with a public IP on its outside interface, a private IP on their voice network on the inside interface, doing stateful sip and rtp proxy with their Mitel PBX. SIP/RTP traffic should come and go to the public IP address of the Adtran box (it does).  They can make and receive calls fine with PSTN.



The problem comes in as follows:

1.       Asterisk PBX at my office cannot call a residential subscriber which is registered.  I get a 486 busy even when the subscriber is idle.

2.       Registered subscriber on an Arris emta on a private ip can place a call to the customer with the Adtran and Mitel PBX but no audio.  External calls to this PBX work fine.

3.       Occasionally have problems reported by PBX customers that they get one way or no audio when forwarding calls back out to an external destination.

I understand more data is going to be needed, I will be glad to provide anything requested.  I will actually be on site at the Mitel PBX customer’s location tomorrow morning, I plan on capturing some traffic on their network and inspecting closely to see if it can be determined where some issues are happening with them.  Probably unrelated to anything I’m doing, some IP phones on their mitel system are unable to make outbound calls, we see the call then immediately a cancel comes from them, a couple IP phones and no digital phones on that system show that problem.


Stephen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sipwise.com/pipermail/spce-user_lists.sipwise.com/attachments/20160505/56111669/attachment-0001.html>