[VoiceOps] Question about billing on SIP trunks

Ryan Delgrosso ryandelgrosso at gmail.com
Thu Sep 20 19:20:44 EDT 2018

So if it were me operating whoever your provider is, I would take the 
diversion as the originating number of the leg in question and bill 
appropriately, as the PAI/FROM in this case is display only.

That being said, does the provider youre with make a distinction between 
local/LD? thats relatively archaic these days as the aggregate cost of 
national termination is so low most stopped caring, it might be worth 
considering moving to another provider.

On 9/20/2018 1:34 PM, Peter Crawford wrote:
> Hello voice-ops:
> Enterprise admin here.
> We just converted from ISDN to SIP (and changed providers) and we're 
> seeing some undesirable billing behavior.  I'm hoping I can get some 
> objective feedback from different providers.
> If a call comes into our system, and we forward it off-net using the 
> SIP trunks (using either "standard" call forwarding or a call 
> forking/paralleling feature like Avaya's EC500 or Cisco's Single 
> Number Reach), we send the call with the SIP FROM header of the 
> original caller (which is desirable to preserve callerID).  We also 
> include a Diversion Header with one of our phone numbers (the original 
> destination of the call).
> We're being billed based on the *original* calling number, which 
> sometimes results in long distance charges, even if this leg of the 
> call is local to us.  This is particularly onerous if the inbound call 
> is international!
> So, the question is- what *should* we be billed on: FROM or DIVERSION.
> At one point, the provider indicated that P-Charge-Info was supported, 
> but now backing away from that.
> Do we have any recourse (technical or otherwise)?
> Thanks.
> _______________________________________________
> VoiceOps mailing list
> VoiceOps at voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20180920/7bece18a/attachment.html>

More information about the VoiceOps mailing list