[VoiceOps] Question about billing on SIP trunks

Pete Eisengrein peeip989 at gmail.com
Fri Sep 21 10:41:33 EDT 2018


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20180921/eef22822/attachment.html>


More information about the VoiceOps mailing list