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.
That's an interesting question, and I think/hope several people on here will have answers. One thing I can say is that there may be legal issues requiring that behavior, to avoid "toll diversion." In our case we only sell flat-rate minutes so our customers don't see that detail. On Thu, Sep 20, 2018 at 1:38 PM Peter Crawford <pdcraw27 at gmail.com> 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
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.
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
Thanks for the replies. I'll withhold the both organizations' names publicly at this point....still a bit sensitive :) We've been looking into PAI, but haven't done any testing yet. As for modifying the FROM number, the billing absolutely reflects what we send. If I originate a local call from our network, but send a FROM that looks long distance, we get billed long distance. Caller ID aside, we can completely avoid long distance charges if we set our FROM field to be something local to the TO field. On Thu, Sep 20, 2018 at 5:09 PM Aryn Nakaoka 808.356.2901 < anakaoka at trinet-hi.com> wrote:
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
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
I would think it would only matter if the called party is served by the PSTN network because that's the only time that MOU billing should take place. However, it may be that your service provider doesn't differentiate and just bills you MOU charges based on what you send them so that they're covered just in case it hits the PSTN network. Mary Lou Carey BackUP Telecom Consulting Office: 615-771-7868 (temporary) Cell: 615-796-1111 On 2018-09-20 06:20 PM, Ryan Delgrosso wrote:
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
VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
As mentioned, the P-Asserted-Id should do the trick. I can't find an RFC for it, nor where I saw this previously, but there is an order of precedence for the headers. I don't remember them all but I do know that P-Asserted-Identity > Diversion > From The other headers fit in there somewhere too, but I think PAI is really what you want. On Thu, Sep 20, 2018 at 4:38 PM Peter Crawford <pdcraw27 at gmail.com> 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
The precedence is Diversion > PAI > RPID > FROM? since in a forwarded call the original legs PAI/RPID/FROM can be retained but the diversion would indicate a change in originator. On 9/21/2018 7:41 AM, Pete Eisengrein wrote:
As mentioned, the P-Asserted-Id should do the trick. I can't find an RFC for it, nor where I saw this previously, but there is an order of precedence for the headers. I don't remember them all but I do know that
P-Asserted-Identity > Diversion > From
The other headers fit in there somewhere too, but I think PAI is really what you want.
On Thu, Sep 20, 2018 at 4:38 PM Peter Crawford <pdcraw27 at gmail.com <mailto:pdcraw27 at gmail.com>> 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 <mailto:VoiceOps at voiceops.org> https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
Thank you all for the feedback. This confirms my initial thought- that FROM is probably the last thing that should be used. On Fri, Sep 21, 2018 at 10:41 AM Pete Eisengrein <peeip989 at gmail.com> wrote:
As mentioned, the P-Asserted-Id should do the trick. I can't find an RFC for it, nor where I saw this previously, but there is an order of precedence for the headers. I don't remember them all but I do know that
P-Asserted-Identity > Diversion > From
The other headers fit in there somewhere too, but I think PAI is really what you want.
On Thu, Sep 20, 2018 at 4:38 PM Peter Crawford <pdcraw27 at gmail.com> 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
participants (7)
-
anakaoka＠trinet-hi.com -
caalvarez＠gmail.com -
joea＠voipinnovations.com -
marylou＠backuptelecom.com -
pdcraw27＠gmail.com -
peeip989＠gmail.com -
ryandelgrosso＠gmail.com