[VoiceOps] Question about billing on SIP trunks

[Ryan Delgrosso]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20180922/1d5fa68b/attachment.html>