[VoiceOps] Question about billing on SIP trunks

[Aryn Nakaoka 808.356.2901]

If you show nothing , I wonder how they'd bill you. Or if you edit from to
a number within that area code, what then?

I'm assuming larger carriers would want something constant.



Aryn Nakaoka
808.356.2901


On Thu, Sep 20, 2018, 11:04 AM Joe Aponick <joea at voipinnovations.com> wrote:

> Does this provider have anything to say about the SIP privacy headers,
> P-Asserted-Identity and/or Remote-Party-ID?  Those are typically preferred
> for routing/billing purposes whereas From is typically preferred for
> display.
>
>
>
> You might be able to keep the original caller in the From header, and set
> the P-Asserted-Identity or RPID to the original destination and have the
> call be routed and billed based on that.
>
>
>
>
>
>
>
> *From:* VoiceOps <voiceops-bounces at voiceops.org> *On Behalf Of *Peter
> Crawford
> *Sent:* Thursday, September 20, 2018 4:35 PM
> *To:* voiceops at voiceops.org
> *Subject:* [VoiceOps] Question about billing on SIP trunks
>
>
>
> 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.
>
>
>     This message is for the designated recipient only and may contain
> privileged, proprietary, or otherwise confidential information. If you have
> received this message in error, please notify the sender immediately and
> delete the original. Any other use of the e-mail by you is prohibited.
> Unauthorized interception of this e-mail is a violation of federal criminal
> law. We reserve the right, when permitted by law, to scan electronic
> communications, including e-mail and instant messaging, for the purposes of
> security and compliance with our internal policy.
> _______________________________________________
> 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/29650e97/attachment.html>