So how do most of you deal with billing of forwarded calls (specifically where the calling number on the forwarded leg is using the original calling number from the inbound leg) in a SIP environment when the originally called number is not preserved in the new invite? In this case there is no way to match the calling or called number to a specific customer. Do you bill by IP address or interface instead? Do you somehow use a system that correlates the forwarded leg to the original inbound leg? I've come across this issue a few different times when trying to bill off of SIP messaging logs, for instance radius off a SIP SBC or SQL logs from SER. Thanks, -Scott
Scott Berkman wrote:
So how do most of you deal with billing of forwarded calls (specifically where the calling number on the forwarded leg is using the original calling number from the inbound leg) in a SIP environment when the originally called number is not preserved in the new invite? In this case there is no way to match the calling or called number to a specific customer.
Do you bill by IP address or interface instead? Do you somehow use a system that correlates the forwarded leg to the original inbound leg? I?ve come across this issue a few different times when trying to bill off of SIP messaging logs, for instance radius off a SIP SBC or SQL logs from SER.
In my view, that depends on what is doing the forwarding. If it's the customer handset actually initiating the forward, then it should just look like a normal termination call from the customer. If it's a multi-tenant switch or other call control agent, it should have some way of associating forwarded calls with an account and sticking an account ID or similar into the CDRs, which will reveal who to bill and presumably the rate plan to use. If it can't do that, the product sucks. -- Alex -- Alex Balashov - Principal Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671
Look for the presence of a diversion header, if the diversion header is there, then that is the responsible party. I cannot speak to the particulars of your platform, but as long as you make sure that if a diversion header is present it is assigned as the responsible party your billing should come out correct in this flow. If your switch/endpoint is not adding a diversion header then I am inclined to agree with Alex. On Wed, 2009-11-11 at 13:01 -0500, Alex Balashov wrote:
Scott Berkman wrote:
So how do most of you deal with billing of forwarded calls (specifically where the calling number on the forwarded leg is using the original calling number from the inbound leg) in a SIP environment when the originally called number is not preserved in the new invite? In this case there is no way to match the calling or called number to a specific customer.
Do you bill by IP address or interface instead? Do you somehow use a system that correlates the forwarded leg to the original inbound leg? I?ve come across this issue a few different times when trying to bill off of SIP messaging logs, for instance radius off a SIP SBC or SQL logs from SER.
In my view, that depends on what is doing the forwarding.
If it's the customer handset actually initiating the forward, then it should just look like a normal termination call from the customer.
If it's a multi-tenant switch or other call control agent, it should have some way of associating forwarded calls with an account and sticking an account ID or similar into the CDRs, which will reveal who to bill and presumably the rate plan to use.
If it can't do that, the product sucks.
-- Alex
Think about this in the context of a SIP trunking provider where the systems in question are customer systems that you cannot control, pull CDR off of, or require diversion headers from. You can't tell the customer you won't provide them SIP trunks because "their system sucks". Because you are trying to support a wide range of systems, the presence or absence of a diversion header will be a variable. -Scott -----Original Message----- From: anorexicpoodle [mailto:anorexicpoodle at gmail.com] Sent: Wednesday, November 11, 2009 3:12 PM To: Alex Balashov Cc: Scott Berkman; voiceops at voiceops.org Subject: Re: [VoiceOps] Billing of Forwarded Calls Look for the presence of a diversion header, if the diversion header is there, then that is the responsible party. I cannot speak to the particulars of your platform, but as long as you make sure that if a diversion header is present it is assigned as the responsible party your billing should come out correct in this flow. If your switch/endpoint is not adding a diversion header then I am inclined to agree with Alex. On Wed, 2009-11-11 at 13:01 -0500, Alex Balashov wrote:
Scott Berkman wrote:
So how do most of you deal with billing of forwarded calls (specifically where the calling number on the forwarded leg is using the original calling number from the inbound leg) in a SIP environment when the originally called number is not preserved in the new invite? In this case there is no way to match the calling or called number to a specific customer.
Do you bill by IP address or interface instead? Do you somehow use a system that correlates the forwarded leg to the original inbound leg? I?ve come across this issue a few different times when trying to bill off of SIP messaging logs, for instance radius off a SIP SBC or SQL logs from SER.
In my view, that depends on what is doing the forwarding.
If it's the customer handset actually initiating the forward, then it should just look like a normal termination call from the customer.
If it's a multi-tenant switch or other call control agent, it should have some way of associating forwarded calls with an account and sticking an account ID or similar into the CDRs, which will reveal who to bill and presumably the rate plan to use.
If it can't do that, the product sucks.
-- Alex
Yes, but if a call comes from a SIP trunk from a system located on the customer's premises, what is the issue? Why not just bill the call as a normal termination call, just as if someone picked up the phone and placed it? Scott Berkman wrote:
Think about this in the context of a SIP trunking provider where the systems in question are customer systems that you cannot control, pull CDR off of, or require diversion headers from. You can't tell the customer you won't provide them SIP trunks because "their system sucks". Because you are trying to support a wide range of systems, the presence or absence of a diversion header will be a variable.
-Scott
-----Original Message----- From: anorexicpoodle [mailto:anorexicpoodle at gmail.com] Sent: Wednesday, November 11, 2009 3:12 PM To: Alex Balashov Cc: Scott Berkman; voiceops at voiceops.org Subject: Re: [VoiceOps] Billing of Forwarded Calls
Look for the presence of a diversion header, if the diversion header is there, then that is the responsible party. I cannot speak to the particulars of your platform, but as long as you make sure that if a diversion header is present it is assigned as the responsible party your billing should come out correct in this flow. If your switch/endpoint is not adding a diversion header then I am inclined to agree with Alex.
On Wed, 2009-11-11 at 13:01 -0500, Alex Balashov wrote:
Scott Berkman wrote:
So how do most of you deal with billing of forwarded calls (specifically where the calling number on the forwarded leg is using the original calling number from the inbound leg) in a SIP environment when the originally called number is not preserved in the new invite? In this case there is no way to match the calling or called number to a specific customer.
Do you bill by IP address or interface instead? Do you somehow use a system that correlates the forwarded leg to the original inbound leg? I?ve come across this issue a few different times when trying to bill off of SIP messaging logs, for instance radius off a SIP SBC or SQL logs from SER. In my view, that depends on what is doing the forwarding.
If it's the customer handset actually initiating the forward, then it should just look like a normal termination call from the customer.
If it's a multi-tenant switch or other call control agent, it should have some way of associating forwarded calls with an account and sticking an account ID or similar into the CDRs, which will reveal who to bill and presumably the rate plan to use.
If it can't do that, the product sucks.
-- Alex
-- Alex Balashov - Principal Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671
Because on a normal termination call the call is sent with the From user as one of the customer's numbers. When a call is forwarded, perhaps as part of a find-me follow-me type feature, the system preserves the original caller's number as the From. Some PBX's do use diversion headers, some use them only on "internal" calls, IE not to a provider's trunk, and some don't send them at all. Again, some customer systems do not support authentication, and some carrier platforms (such as the Metaswitch) do not support authentication on trunks. In this case we are trying to bill a number of different platforms off one central system, the records of the SBCs that sit in the middle of everything and see all the traffic. They just don't know how to correlate calls they don't see as related based on SIP headers. -Scott -----Original Message----- From: Alex Balashov [mailto:abalashov at evaristesys.com] Sent: Wednesday, November 11, 2009 3:29 PM To: Scott Berkman Cc: 'anorexicpoodle'; voiceops at voiceops.org Subject: Re: [VoiceOps] Billing of Forwarded Calls Yes, but if a call comes from a SIP trunk from a system located on the customer's premises, what is the issue? Why not just bill the call as a normal termination call, just as if someone picked up the phone and placed it? Scott Berkman wrote:
Think about this in the context of a SIP trunking provider where the systems in question are customer systems that you cannot control, pull CDR off of, or require diversion headers from. You can't tell the customer you won't provide them SIP trunks because "their system sucks". Because you are trying to support a wide range of systems, the presence or absence of a diversion header will be a variable.
-Scott
-----Original Message----- From: anorexicpoodle [mailto:anorexicpoodle at gmail.com] Sent: Wednesday, November 11, 2009 3:12 PM To: Alex Balashov Cc: Scott Berkman; voiceops at voiceops.org Subject: Re: [VoiceOps] Billing of Forwarded Calls
Look for the presence of a diversion header, if the diversion header is there, then that is the responsible party. I cannot speak to the particulars of your platform, but as long as you make sure that if a diversion header is present it is assigned as the responsible party your billing should come out correct in this flow. If your switch/endpoint is not adding a diversion header then I am inclined to agree with Alex.
On Wed, 2009-11-11 at 13:01 -0500, Alex Balashov wrote:
Scott Berkman wrote:
So how do most of you deal with billing of forwarded calls (specifically where the calling number on the forwarded leg is using the original calling number from the inbound leg) in a SIP environment when the originally called number is not preserved in the new invite? In this case there is no way to match the calling or called number to a specific customer.
Do you bill by IP address or interface instead? Do you somehow use a system that correlates the forwarded leg to the original inbound leg? I?ve come across this issue a few different times when trying to bill off of SIP messaging logs, for instance radius off a SIP SBC or SQL logs from SER. In my view, that depends on what is doing the forwarding.
If it's the customer handset actually initiating the forward, then it should just look like a normal termination call from the customer.
If it's a multi-tenant switch or other call control agent, it should have some way of associating forwarded calls with an account and sticking an account ID or similar into the CDRs, which will reveal who to bill and presumably the rate plan to use.
If it can't do that, the product sucks.
-- Alex
-- Alex Balashov - Principal Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671
What SBCs are you using? Scott Berkman wrote:
Because on a normal termination call the call is sent with the From user as one of the customer's numbers. When a call is forwarded, perhaps as part of a find-me follow-me type feature, the system preserves the original caller's number as the From. Some PBX's do use diversion headers, some use them only on "internal" calls, IE not to a provider's trunk, and some don't send them at all. Again, some customer systems do not support authentication, and some carrier platforms (such as the Metaswitch) do not support authentication on trunks. In this case we are trying to bill a number of different platforms off one central system, the records of the SBCs that sit in the middle of everything and see all the traffic. They just don't know how to correlate calls they don't see as related based on SIP headers.
-Scott
-----Original Message----- From: Alex Balashov [mailto:abalashov at evaristesys.com] Sent: Wednesday, November 11, 2009 3:29 PM To: Scott Berkman Cc: 'anorexicpoodle'; voiceops at voiceops.org Subject: Re: [VoiceOps] Billing of Forwarded Calls
Yes, but if a call comes from a SIP trunk from a system located on the customer's premises, what is the issue? Why not just bill the call as a normal termination call, just as if someone picked up the phone and placed it?
Scott Berkman wrote:
Think about this in the context of a SIP trunking provider where the systems in question are customer systems that you cannot control, pull CDR off of, or require diversion headers from. You can't tell the customer you won't provide them SIP trunks because "their system sucks". Because you are trying to support a wide range of systems, the presence or absence of a diversion header will be a variable.
-Scott
-----Original Message----- From: anorexicpoodle [mailto:anorexicpoodle at gmail.com] Sent: Wednesday, November 11, 2009 3:12 PM To: Alex Balashov Cc: Scott Berkman; voiceops at voiceops.org Subject: Re: [VoiceOps] Billing of Forwarded Calls
Look for the presence of a diversion header, if the diversion header is there, then that is the responsible party. I cannot speak to the particulars of your platform, but as long as you make sure that if a diversion header is present it is assigned as the responsible party your billing should come out correct in this flow. If your switch/endpoint is not adding a diversion header then I am inclined to agree with Alex.
On Wed, 2009-11-11 at 13:01 -0500, Alex Balashov wrote:
Scott Berkman wrote:
So how do most of you deal with billing of forwarded calls (specifically where the calling number on the forwarded leg is using the original calling number from the inbound leg) in a SIP environment when the originally called number is not preserved in the new invite? In this case there is no way to match the calling or called number to a specific customer.
Do you bill by IP address or interface instead? Do you somehow use a system that correlates the forwarded leg to the original inbound leg? I?ve come across this issue a few different times when trying to bill off of SIP messaging logs, for instance radius off a SIP SBC or SQL logs from SER.
In my view, that depends on what is doing the forwarding.
If it's the customer handset actually initiating the forward, then it should just look like a normal termination call from the customer.
If it's a multi-tenant switch or other call control agent, it should have some way of associating forwarded calls with an account and sticking an account ID or similar into the CDRs, which will reveal who to bill and presumably the rate plan to use.
If it can't do that, the product sucks.
-- Alex
Acme. -Scott From: Lee Riemer [mailto:lriemer at bestline.net] Sent: Wednesday, November 11, 2009 4:12 PM To: Scott Berkman Cc: 'Alex Balashov'; voiceops at voiceops.org Subject: Re: [VoiceOps] Billing of Forwarded Calls What SBCs are you using? Scott Berkman wrote: Because on a normal termination call the call is sent with the From user as one of the customer's numbers. When a call is forwarded, perhaps as part of a find-me follow-me type feature, the system preserves the original caller's number as the From. Some PBX's do use diversion headers, some use them only on "internal" calls, IE not to a provider's trunk, and some don't send them at all. Again, some customer systems do not support authentication, and some carrier platforms (such as the Metaswitch) do not support authentication on trunks. In this case we are trying to bill a number of different platforms off one central system, the records of the SBCs that sit in the middle of everything and see all the traffic. They just don't know how to correlate calls they don't see as related based on SIP headers. -Scott -----Original Message----- From: Alex Balashov [mailto:abalashov at evaristesys.com] Sent: Wednesday, November 11, 2009 3:29 PM To: Scott Berkman Cc: 'anorexicpoodle'; voiceops at voiceops.org Subject: Re: [VoiceOps] Billing of Forwarded Calls Yes, but if a call comes from a SIP trunk from a system located on the customer's premises, what is the issue? Why not just bill the call as a normal termination call, just as if someone picked up the phone and placed it? Scott Berkman wrote: Think about this in the context of a SIP trunking provider where the systems in question are customer systems that you cannot control, pull CDR off of, or require diversion headers from. You can't tell the customer you won't provide them SIP trunks because "their system sucks". Because you are trying to support a wide range of systems, the presence or absence of a diversion header will be a variable. -Scott -----Original Message----- From: anorexicpoodle [mailto:anorexicpoodle at gmail.com] Sent: Wednesday, November 11, 2009 3:12 PM To: Alex Balashov Cc: Scott Berkman; voiceops at voiceops.org Subject: Re: [VoiceOps] Billing of Forwarded Calls Look for the presence of a diversion header, if the diversion header is there, then that is the responsible party. I cannot speak to the particulars of your platform, but as long as you make sure that if a diversion header is present it is assigned as the responsible party your billing should come out correct in this flow. If your switch/endpoint is not adding a diversion header then I am inclined to agree with Alex. On Wed, 2009-11-11 at 13:01 -0500, Alex Balashov wrote: Scott Berkman wrote: So how do most of you deal with billing of forwarded calls (specifically where the calling number on the forwarded leg is using the original calling number from the inbound leg) in a SIP environment when the originally called number is not preserved in the new invite? In this case there is no way to match the calling or called number to a specific customer. Do you bill by IP address or interface instead? Do you somehow use a system that correlates the forwarded leg to the original inbound leg? I?ve come across this issue a few different times when trying to bill off of SIP messaging logs, for instance radius off a SIP SBC or SQL logs from SER. In my view, that depends on what is doing the forwarding. If it's the customer handset actually initiating the forward, then it should just look like a normal termination call from the customer. If it's a multi-tenant switch or other call control agent, it should have some way of associating forwarded calls with an account and sticking an account ID or similar into the CDRs, which will reveal who to bill and presumably the rate plan to use. If it can't do that, the product sucks. -- Alex
Are these forwarded calls coming through session-agents if they're not authenticated? Scott Berkman wrote:
Acme.
-Scott
*From:* Lee Riemer [mailto:lriemer at bestline.net] *Sent:* Wednesday, November 11, 2009 4:12 PM *To:* Scott Berkman *Cc:* 'Alex Balashov'; voiceops at voiceops.org *Subject:* Re: [VoiceOps] Billing of Forwarded Calls
What SBCs are you using?
Scott Berkman wrote:
Because on a normal termination call the call is sent with the From user as one of the customer's numbers. When a call is forwarded, perhaps as part of a find-me follow-me type feature, the system preserves the original caller's number as the From. Some PBX's do use diversion headers, some use them only on "internal" calls, IE not to a provider's trunk, and some don't send them at all. Again, some customer systems do not support authentication, and some carrier platforms (such as the Metaswitch) do not support authentication on trunks. In this case we are trying to bill a number of different platforms off one central system, the records of the SBCs that sit in the middle of everything and see all the traffic. They just don't know how to correlate calls they don't see as related based on SIP headers.
-Scott
-----Original Message----- From: Alex Balashov [mailto:abalashov at evaristesys.com] Sent: Wednesday, November 11, 2009 3:29 PM To: Scott Berkman Cc: 'anorexicpoodle'; voiceops at voiceops.org <mailto:voiceops at voiceops.org> Subject: Re: [VoiceOps] Billing of Forwarded Calls
Yes, but if a call comes from a SIP trunk from a system located on the customer's premises, what is the issue? Why not just bill the call as a normal termination call, just as if someone picked up the phone and placed it?
Scott Berkman wrote:
Think about this in the context of a SIP trunking provider where the systems in question are customer systems that you cannot control, pull CDR off of, or require diversion headers from. You can't tell the customer you won't provide them SIP trunks because "their system sucks". Because you are trying to support a wide range of systems, the presence or absence of a diversion header will be a variable.
-Scott
-----Original Message-----
From: anorexicpoodle [mailto:anorexicpoodle at gmail.com]
Sent: Wednesday, November 11, 2009 3:12 PM
To: Alex Balashov
Cc: Scott Berkman; voiceops at voiceops.org <mailto:voiceops at voiceops.org>
Subject: Re: [VoiceOps] Billing of Forwarded Calls
Look for the presence of a diversion header, if the diversion header is
there, then that is the responsible party. I cannot speak to the
particulars of your platform, but as long as you make sure that if a
diversion header is present it is assigned as the responsible party your
billing should come out correct in this flow. If your switch/endpoint is
not adding a diversion header then I am inclined to agree with Alex.
On Wed, 2009-11-11 at 13:01 -0500, Alex Balashov wrote:
Scott Berkman wrote:
So how do most of you deal with billing of forwarded calls (specifically
where the calling number on the forwarded leg is using the original
calling number from the inbound leg) in a SIP environment when the
originally called number is not preserved in the new invite? In this
case there is no way to match the calling or called number to a specific
customer.
Do you bill by IP address or interface instead? Do you somehow use a
system that correlates the forwarded leg to the original inbound leg?
I?ve come across this issue a few different times when trying to bill
off of SIP messaging logs, for instance radius off a SIP SBC or SQL logs
from SER.
In my view, that depends on what is doing the forwarding.
If it's the customer handset actually initiating the forward, then it
should just look like a normal termination call from the customer.
If it's a multi-tenant switch or other call control agent, it should
have some way of associating forwarded calls with an account and
sticking an account ID or similar into the CDRs, which will reveal who
to bill and presumably the rate plan to use.
If it can't do that, the product sucks.
-- Alex
Yes from a ?known and trusted? IP. -Scott From: Lee Riemer [mailto:lriemer at bestline.net] Sent: Wednesday, November 11, 2009 5:53 PM To: Scott Berkman Cc: 'Alex Balashov'; voiceops at voiceops.org Subject: Re: [VoiceOps] Billing of Forwarded Calls Are these forwarded calls coming through session-agents if they're not authenticated? Scott Berkman wrote: Acme. -Scott From: Lee Riemer [mailto:lriemer at bestline.net] Sent: Wednesday, November 11, 2009 4:12 PM To: Scott Berkman Cc: 'Alex Balashov'; voiceops at voiceops.org Subject: Re: [VoiceOps] Billing of Forwarded Calls What SBCs are you using? Scott Berkman wrote: Because on a normal termination call the call is sent with the From user as one of the customer's numbers. When a call is forwarded, perhaps as part of a find-me follow-me type feature, the system preserves the original caller's number as the From. Some PBX's do use diversion headers, some use them only on "internal" calls, IE not to a provider's trunk, and some don't send them at all. Again, some customer systems do not support authentication, and some carrier platforms (such as the Metaswitch) do not support authentication on trunks. In this case we are trying to bill a number of different platforms off one central system, the records of the SBCs that sit in the middle of everything and see all the traffic. They just don't know how to correlate calls they don't see as related based on SIP headers. -Scott -----Original Message----- From: Alex Balashov [mailto:abalashov at evaristesys.com] Sent: Wednesday, November 11, 2009 3:29 PM To: Scott Berkman Cc: 'anorexicpoodle'; voiceops at voiceops.org Subject: Re: [VoiceOps] Billing of Forwarded Calls Yes, but if a call comes from a SIP trunk from a system located on the customer's premises, what is the issue? Why not just bill the call as a normal termination call, just as if someone picked up the phone and placed it? Scott Berkman wrote: Think about this in the context of a SIP trunking provider where the systems in question are customer systems that you cannot control, pull CDR off of, or require diversion headers from. You can't tell the customer you won't provide them SIP trunks because "their system sucks". Because you are trying to support a wide range of systems, the presence or absence of a diversion header will be a variable. -Scott -----Original Message----- From: anorexicpoodle [mailto:anorexicpoodle at gmail.com] Sent: Wednesday, November 11, 2009 3:12 PM To: Alex Balashov Cc: Scott Berkman; voiceops at voiceops.org Subject: Re: [VoiceOps] Billing of Forwarded Calls Look for the presence of a diversion header, if the diversion header is there, then that is the responsible party. I cannot speak to the particulars of your platform, but as long as you make sure that if a diversion header is present it is assigned as the responsible party your billing should come out correct in this flow. If your switch/endpoint is not adding a diversion header then I am inclined to agree with Alex. On Wed, 2009-11-11 at 13:01 -0500, Alex Balashov wrote: Scott Berkman wrote: So how do most of you deal with billing of forwarded calls (specifically where the calling number on the forwarded leg is using the original calling number from the inbound leg) in a SIP environment when the originally called number is not preserved in the new invite? In this case there is no way to match the calling or called number to a specific customer. Do you bill by IP address or interface instead? Do you somehow use a system that correlates the forwarded leg to the original inbound leg? I?ve come across this issue a few different times when trying to bill off of SIP messaging logs, for instance radius off a SIP SBC or SQL logs from SER. In my view, that depends on what is doing the forwarding. If it's the customer handset actually initiating the forward, then it should just look like a normal termination call from the customer. If it's a multi-tenant switch or other call control agent, it should have some way of associating forwarded calls with an account and sticking an account ID or similar into the CDRs, which will reveal who to bill and presumably the rate plan to use. If it can't do that, the product sucks. -- Alex
Actually depending on how you have constructed your trunk in Metaswitch you can indeed authenticate the call, just turn on the SIP Authentication required flag in the configured SIP binding for your trunk. Be aware this will force it to authenticate invite, cancel and bye messages so this may be undesirable but it will certainly get you what you need. Given the scope of your problem though you know who is originating the call since it would be coming from a configured sip binding, are the billing records Metaswitch produces insufficient for this? On Wed, 2009-11-11 at 16:01 -0500, Scott Berkman wrote:
Because on a normal termination call the call is sent with the From user as one of the customer's numbers. When a call is forwarded, perhaps as part of a find-me follow-me type feature, the system preserves the original caller's number as the From. Some PBX's do use diversion headers, some use them only on "internal" calls, IE not to a provider's trunk, and some don't send them at all. Again, some customer systems do not support authentication, and some carrier platforms (such as the Metaswitch) do not support authentication on trunks. In this case we are trying to bill a number of different platforms off one central system, the records of the SBCs that sit in the middle of everything and see all the traffic. They just don't know how to correlate calls they don't see as related based on SIP headers.
-Scott
-----Original Message----- From: Alex Balashov [mailto:abalashov at evaristesys.com] Sent: Wednesday, November 11, 2009 3:29 PM To: Scott Berkman Cc: 'anorexicpoodle'; voiceops at voiceops.org Subject: Re: [VoiceOps] Billing of Forwarded Calls
Yes, but if a call comes from a SIP trunk from a system located on the customer's premises, what is the issue? Why not just bill the call as a normal termination call, just as if someone picked up the phone and placed it?
Scott Berkman wrote:
Think about this in the context of a SIP trunking provider where the systems in question are customer systems that you cannot control, pull CDR off of, or require diversion headers from. You can't tell the customer you won't provide them SIP trunks because "their system sucks". Because you are trying to support a wide range of systems, the presence or absence of a diversion header will be a variable.
-Scott
-----Original Message----- From: anorexicpoodle [mailto:anorexicpoodle at gmail.com] Sent: Wednesday, November 11, 2009 3:12 PM To: Alex Balashov Cc: Scott Berkman; voiceops at voiceops.org Subject: Re: [VoiceOps] Billing of Forwarded Calls
Look for the presence of a diversion header, if the diversion header is there, then that is the responsible party. I cannot speak to the particulars of your platform, but as long as you make sure that if a diversion header is present it is assigned as the responsible party your billing should come out correct in this flow. If your switch/endpoint is not adding a diversion header then I am inclined to agree with Alex.
On Wed, 2009-11-11 at 13:01 -0500, Alex Balashov wrote:
Scott Berkman wrote:
So how do most of you deal with billing of forwarded calls (specifically where the calling number on the forwarded leg is using the original calling number from the inbound leg) in a SIP environment when the originally called number is not preserved in the new invite? In this case there is no way to match the calling or called number to a specific customer.
Do you bill by IP address or interface instead? Do you somehow use a system that correlates the forwarded leg to the original inbound leg? I?ve come across this issue a few different times when trying to bill off of SIP messaging logs, for instance radius off a SIP SBC or SQL logs from SER. In my view, that depends on what is doing the forwarding.
If it's the customer handset actually initiating the forward, then it should just look like a normal termination call from the customer.
If it's a multi-tenant switch or other call control agent, it should have some way of associating forwarded calls with an account and sticking an account ID or similar into the CDRs, which will reveal who to bill and presumably the rate plan to use.
If it can't do that, the product sucks.
-- Alex
I think the problem is some of the CPE can only handle static IP-to-IP SIP trunks - no UAC capable of answering 407 challenges or doing registration, which often go hand in hand. Also, BYEs and CANCELs should not be authenticated; that's silly, they're already anchored to dialogs for which there is known state. Only initial INVITEs. Can you really not change that in the Metaswitch? anorexicpoodle wrote:
Actually depending on how you have constructed your trunk in Metaswitch you can indeed authenticate the call, just turn on the SIP Authentication required flag in the configured SIP binding for your trunk. Be aware this will force it to authenticate invite, cancel and bye messages so this may be undesirable but it will certainly get you what you need.
Given the scope of your problem though you know who is originating the call since it would be coming from a configured sip binding, are the billing records Metaswitch produces insufficient for this?
-- Alex Balashov - Principal Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671
What's wrong with authenticating BYEs and CANCELs? I see them as just as important as an INVITE. Anyone can some around, sniff the dialog and spoof a BYE or CANCEL. Alex Balashov wrote:
I think the problem is some of the CPE can only handle static IP-to-IP SIP trunks - no UAC capable of answering 407 challenges or doing registration, which often go hand in hand.
Also, BYEs and CANCELs should not be authenticated; that's silly, they're already anchored to dialogs for which there is known state. Only initial INVITEs. Can you really not change that in the Metaswitch?
anorexicpoodle wrote:
Actually depending on how you have constructed your trunk in Metaswitch you can indeed authenticate the call, just turn on the SIP Authentication required flag in the configured SIP binding for your trunk. Be aware this will force it to authenticate invite, cancel and bye messages so this may be undesirable but it will certainly get you what you need.
Given the scope of your problem though you know who is originating the call since it would be coming from a configured sip binding, are the billing records Metaswitch produces insufficient for this?
Lee Riemer wrote:
What's wrong with authenticating BYEs and CANCELs? I see them as just as important as an INVITE. Anyone can some around, sniff the dialog and spoof a BYE or CANCEL.
They'd have to spoof a Call-ID, From and To tags, correct CSeqs, any loose-routing parameters present in the Route and/or Record-Route headers, and the Route header itself. I suppose it *could* be done... but... -- Alex Balashov - Principal Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671
I agree. Shouldn't be too hard if you're sniffing the line, say on a wi-fi connection. Listen for INVITEs, pull dialog info, spoof CANCELs. Nice little DOS attack. Alex Balashov wrote:
Lee Riemer wrote:
What's wrong with authenticating BYEs and CANCELs? I see them as just as important as an INVITE. Anyone can some around, sniff the dialog and spoof a BYE or CANCEL.
They'd have to spoof a Call-ID, From and To tags, correct CSeqs, any loose-routing parameters present in the Route and/or Record-Route headers, and the Route header itself.
I suppose it *could* be done... but...
Actually I would be far more concerned about the spoofing of refer messages, which is one of the message types it doesn't auth. It struck me as unusual that it would auth a bye and not a refer. On Wed, 2009-11-11 at 16:20 -0600, Lee Riemer wrote:
I agree. Shouldn't be too hard if you're sniffing the line, say on a wi-fi connection. Listen for INVITEs, pull dialog info, spoof CANCELs. Nice little DOS attack.
Alex Balashov wrote:
Lee Riemer wrote:
What's wrong with authenticating BYEs and CANCELs? I see them as just as important as an INVITE. Anyone can some around, sniff the dialog and spoof a BYE or CANCEL.
They'd have to spoof a Call-ID, From and To tags, correct CSeqs, any loose-routing parameters present in the Route and/or Record-Route headers, and the Route header itself.
I suppose it *could* be done... but...
Hmm.... I'll have to check this out. anorexicpoodle wrote:
Actually I would be far more concerned about the spoofing of refer messages, which is one of the message types it doesn't auth. It struck me as unusual that it would auth a bye and not a refer.
On Wed, 2009-11-11 at 16:20 -0600, Lee Riemer wrote:
I agree. Shouldn't be too hard if you're sniffing the line, say on a wi-fi connection. Listen for INVITEs, pull dialog info, spoof CANCELs. Nice little DOS attack.
Alex Balashov wrote:
Lee Riemer wrote:
What's wrong with authenticating BYEs and CANCELs? I see them as just as important as an INVITE. Anyone can some around, sniff the dialog and spoof a BYE or CANCEL.
They'd have to spoof a Call-ID, From and To tags, correct CSeqs, any loose-routing parameters present in the Route and/or Record-Route headers, and the Route header itself.
I suppose it *could* be done... but...
Lee Riemer wrote:
I agree. Shouldn't be too hard if you're sniffing the line, say on a wi-fi connection. Listen for INVITEs, pull dialog info, spoof CANCELs. Nice little DOS attack.
Of course. But if I had to speculate as to the reason why BYEs, for example, are not commonly challenged by ITSP edge equipment, it would be because the concept of potentially forbidding someone to hang up their own call - however improbable the set of circumstances in that might arise - appears perverse, prima facie. -- Alex Balashov - Principal Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671
Yep turning on authentication authenticates invites and byes, I was mistaken about the cancel. Unfortunately it doesn't seem to be a config option with any granularity to it, simply on or off per connection. On Wed, 2009-11-11 at 16:36 -0500, Alex Balashov wrote:
I think the problem is some of the CPE can only handle static IP-to-IP SIP trunks - no UAC capable of answering 407 challenges or doing registration, which often go hand in hand.
Also, BYEs and CANCELs should not be authenticated; that's silly, they're already anchored to dialogs for which there is known state. Only initial INVITEs. Can you really not change that in the Metaswitch?
anorexicpoodle wrote:
Actually depending on how you have constructed your trunk in Metaswitch you can indeed authenticate the call, just turn on the SIP Authentication required flag in the configured SIP binding for your trunk. Be aware this will force it to authenticate invite, cancel and bye messages so this may be undesirable but it will certainly get you what you need.
Given the scope of your problem though you know who is originating the call since it would be coming from a configured sip binding, are the billing records Metaswitch produces insufficient for this?
The Metaswitch is just one of a number of systems involved in everything. The idea was to bill off the Radius records from the SBC's, because every call touches them. Not every call touches the Metaswitch, so we are trying to avoid dealing with those records as well. The Metaswitch trunk auth may help, we'll look into that. Thanks, -Scott -----Original Message----- From: anorexicpoodle [mailto:anorexicpoodle at gmail.com] Sent: Wednesday, November 11, 2009 4:26 PM To: Scott Berkman Cc: 'Alex Balashov'; voiceops at voiceops.org Subject: RE: [VoiceOps] Billing of Forwarded Calls Actually depending on how you have constructed your trunk in Metaswitch you can indeed authenticate the call, just turn on the SIP Authentication required flag in the configured SIP binding for your trunk. Be aware this will force it to authenticate invite, cancel and bye messages so this may be undesirable but it will certainly get you what you need. Given the scope of your problem though you know who is originating the call since it would be coming from a configured sip binding, are the billing records Metaswitch produces insufficient for this? On Wed, 2009-11-11 at 16:01 -0500, Scott Berkman wrote:
Because on a normal termination call the call is sent with the From user as one of the customer's numbers. When a call is forwarded, perhaps as part of a find-me follow-me type feature, the system preserves the original caller's number as the From. Some PBX's do use diversion headers, some use them only on "internal" calls, IE not to a provider's trunk, and some don't send them at all. Again, some customer systems do not support authentication, and some carrier platforms (such as the Metaswitch) do not support authentication on trunks. In this case we are trying to bill a number of different platforms off one central system, the records of the SBCs that sit in the middle of everything and see all the traffic. They just don't know how to correlate calls they don't see as related based on SIP headers.
-Scott
-----Original Message----- From: Alex Balashov [mailto:abalashov at evaristesys.com] Sent: Wednesday, November 11, 2009 3:29 PM To: Scott Berkman Cc: 'anorexicpoodle'; voiceops at voiceops.org Subject: Re: [VoiceOps] Billing of Forwarded Calls
Yes, but if a call comes from a SIP trunk from a system located on the customer's premises, what is the issue? Why not just bill the call as a normal termination call, just as if someone picked up the phone and placed it?
Scott Berkman wrote:
Think about this in the context of a SIP trunking provider where the systems in question are customer systems that you cannot control, pull CDR off of, or require diversion headers from. You can't tell the customer you won't provide them SIP trunks because "their system sucks". Because you are trying to support a wide range of systems, the presence or absence of a diversion header will be a variable.
-Scott
-----Original Message----- From: anorexicpoodle [mailto:anorexicpoodle at gmail.com] Sent: Wednesday, November 11, 2009 3:12 PM To: Alex Balashov Cc: Scott Berkman; voiceops at voiceops.org Subject: Re: [VoiceOps] Billing of Forwarded Calls
Look for the presence of a diversion header, if the diversion header is there, then that is the responsible party. I cannot speak to the particulars of your platform, but as long as you make sure that if a diversion header is present it is assigned as the responsible party your billing should come out correct in this flow. If your switch/endpoint is not adding a diversion header then I am inclined to agree with Alex.
On Wed, 2009-11-11 at 13:01 -0500, Alex Balashov wrote:
Scott Berkman wrote:
So how do most of you deal with billing of forwarded calls (specifically where the calling number on the forwarded leg is using the original calling number from the inbound leg) in a SIP environment when the originally called number is not preserved in the new invite? In this case there is no way to match the calling or called number to a specific customer.
Do you bill by IP address or interface instead? Do you somehow use a system that correlates the forwarded leg to the original inbound leg? I?ve come across this issue a few different times when trying to bill off of SIP messaging logs, for instance radius off a SIP SBC or SQL logs from SER. In my view, that depends on what is doing the forwarding.
If it's the customer handset actually initiating the forward, then it should just look like a normal termination call from the customer.
If it's a multi-tenant switch or other call control agent, it should have some way of associating forwarded calls with an account and sticking an account ID or similar into the CDRs, which will reveal who to bill and presumably the rate plan to use.
If it can't do that, the product sucks.
-- Alex
Food for thought since this is a problem I have dealt with as well, If you restrict your view to only SBC radius logs you will miss some events. Perhaps this isn't critical to your deployment though but I find that a lot of on-switch events and a lot of the meta-data that comes with the billing records is hugely valuable to producing complete billing records. This was my experience with Sylantro, especially when more unusual call flows got involved such as ACD queuing etc. On Wed, 2009-11-11 at 16:40 -0500, Scott Berkman wrote:
The Metaswitch is just one of a number of systems involved in everything. The idea was to bill off the Radius records from the SBC's, because every call touches them. Not every call touches the Metaswitch, so we are trying to avoid dealing with those records as well.
The Metaswitch trunk auth may help, we'll look into that.
Thanks,
-Scott
-----Original Message----- From: anorexicpoodle [mailto:anorexicpoodle at gmail.com] Sent: Wednesday, November 11, 2009 4:26 PM To: Scott Berkman Cc: 'Alex Balashov'; voiceops at voiceops.org Subject: RE: [VoiceOps] Billing of Forwarded Calls
Actually depending on how you have constructed your trunk in Metaswitch you can indeed authenticate the call, just turn on the SIP Authentication required flag in the configured SIP binding for your trunk. Be aware this will force it to authenticate invite, cancel and bye messages so this may be undesirable but it will certainly get you what you need.
Given the scope of your problem though you know who is originating the call since it would be coming from a configured sip binding, are the billing records Metaswitch produces insufficient for this?
On Wed, 2009-11-11 at 16:01 -0500, Scott Berkman wrote:
Because on a normal termination call the call is sent with the From user as one of the customer's numbers. When a call is forwarded, perhaps as part of a find-me follow-me type feature, the system preserves the original caller's number as the From. Some PBX's do use diversion headers, some use them only on "internal" calls, IE not to a provider's trunk, and some don't send them at all. Again, some customer systems do not support authentication, and some carrier platforms (such as the Metaswitch) do not support authentication on trunks. In this case we are trying to bill a number of different platforms off one central system, the records of the SBCs that sit in the middle of everything and see all the traffic. They just don't know how to correlate calls they don't see as related based on SIP headers.
-Scott
-----Original Message----- From: Alex Balashov [mailto:abalashov at evaristesys.com] Sent: Wednesday, November 11, 2009 3:29 PM To: Scott Berkman Cc: 'anorexicpoodle'; voiceops at voiceops.org Subject: Re: [VoiceOps] Billing of Forwarded Calls
Yes, but if a call comes from a SIP trunk from a system located on the customer's premises, what is the issue? Why not just bill the call as a normal termination call, just as if someone picked up the phone and placed it?
Scott Berkman wrote:
Think about this in the context of a SIP trunking provider where the systems in question are customer systems that you cannot control, pull CDR off of, or require diversion headers from. You can't tell the customer you won't provide them SIP trunks because "their system sucks". Because you are trying to support a wide range of systems, the presence or absence of a diversion header will be a variable.
-Scott
-----Original Message----- From: anorexicpoodle [mailto:anorexicpoodle at gmail.com] Sent: Wednesday, November 11, 2009 3:12 PM To: Alex Balashov Cc: Scott Berkman; voiceops at voiceops.org Subject: Re: [VoiceOps] Billing of Forwarded Calls
Look for the presence of a diversion header, if the diversion header is there, then that is the responsible party. I cannot speak to the particulars of your platform, but as long as you make sure that if a diversion header is present it is assigned as the responsible party your billing should come out correct in this flow. If your switch/endpoint is not adding a diversion header then I am inclined to agree with Alex.
On Wed, 2009-11-11 at 13:01 -0500, Alex Balashov wrote:
Scott Berkman wrote:
So how do most of you deal with billing of forwarded calls (specifically where the calling number on the forwarded leg is using the original calling number from the inbound leg) in a SIP environment when the originally called number is not preserved in the new invite? In this case there is no way to match the calling or called number to a specific customer.
Do you bill by IP address or interface instead? Do you somehow use a system that correlates the forwarded leg to the original inbound leg? I?ve come across this issue a few different times when trying to bill off of SIP messaging logs, for instance radius off a SIP SBC or SQL logs from SER. In my view, that depends on what is doing the forwarding.
If it's the customer handset actually initiating the forward, then it should just look like a normal termination call from the customer.
If it's a multi-tenant switch or other call control agent, it should have some way of associating forwarded calls with an account and sticking an account ID or similar into the CDRs, which will reveal who to bill and presumably the rate plan to use.
If it can't do that, the product sucks.
-- Alex
If this is in the context of a customer trunk, and the forward is being completed via invite from their system, and I presume that means that they will stay in the flow for the duration, then you can either: A: Assign their trunk a default source ani for all traffic that doesn't have a valid source (from, diversion etc) assigned to the trunk. B: Reject the call since it was offered from an ANI that is not provisioned on the customers trunk. C: Challenge all invites and assign the call to the authenticating account Unfortunately if the CPE can't/won't tell you the actual originating number and the 2 calls are not explicitly related (forwarded by B2BUA so callid is different etc) then you don't have much other recourse. On Wed, 2009-11-11 at 15:23 -0500, Scott Berkman wrote:
Think about this in the context of a SIP trunking provider where the systems in question are customer systems that you cannot control, pull CDR off of, or require diversion headers from. You can't tell the customer you won't provide them SIP trunks because "their system sucks". Because you are trying to support a wide range of systems, the presence or absence of a diversion header will be a variable.
-Scott
-----Original Message----- From: anorexicpoodle [mailto:anorexicpoodle at gmail.com] Sent: Wednesday, November 11, 2009 3:12 PM To: Alex Balashov Cc: Scott Berkman; voiceops at voiceops.org Subject: Re: [VoiceOps] Billing of Forwarded Calls
Look for the presence of a diversion header, if the diversion header is there, then that is the responsible party. I cannot speak to the particulars of your platform, but as long as you make sure that if a diversion header is present it is assigned as the responsible party your billing should come out correct in this flow. If your switch/endpoint is not adding a diversion header then I am inclined to agree with Alex.
On Wed, 2009-11-11 at 13:01 -0500, Alex Balashov wrote:
Scott Berkman wrote:
So how do most of you deal with billing of forwarded calls (specifically where the calling number on the forwarded leg is using the original calling number from the inbound leg) in a SIP environment when the originally called number is not preserved in the new invite? In this case there is no way to match the calling or called number to a specific customer.
Do you bill by IP address or interface instead? Do you somehow use a system that correlates the forwarded leg to the original inbound leg? I?ve come across this issue a few different times when trying to bill off of SIP messaging logs, for instance radius off a SIP SBC or SQL logs from SER.
In my view, that depends on what is doing the forwarding.
If it's the customer handset actually initiating the forward, then it should just look like a normal termination call from the customer.
If it's a multi-tenant switch or other call control agent, it should have some way of associating forwarded calls with an account and sticking an account ID or similar into the CDRs, which will reveal who to bill and presumably the rate plan to use.
If it can't do that, the product sucks.
-- Alex
anorexicpoodle wrote:
C: Challenge all invites and assign the call to the authenticating account
I would go for this option. -- Alex Balashov - Principal Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671
A is not possible since the ANI being sent is ?valid? in NANP. B is not possible based on customer demands, otherwise this would be my preferred solution. C is not supported by some of the systems involved. -Scott From: anorexicpoodle [mailto:anorexicpoodle at gmail.com] Sent: Wednesday, November 11, 2009 3:47 PM To: Scott Berkman Cc: 'Alex Balashov'; voiceops at voiceops.org Subject: RE: [VoiceOps] Billing of Forwarded Calls If this is in the context of a customer trunk, and the forward is being completed via invite from their system, and I presume that means that they will stay in the flow for the duration, then you can either: A: Assign their trunk a default source ani for all traffic that doesn't have a valid source (from, diversion etc) assigned to the trunk. B: Reject the call since it was offered from an ANI that is not provisioned on the customers trunk. C: Challenge all invites and assign the call to the authenticating account Unfortunately if the CPE can't/won't tell you the actual originating number and the 2 calls are not explicitly related (forwarded by B2BUA so callid is different etc) then you don't have much other recourse. On Wed, 2009-11-11 at 15:23 -0500, Scott Berkman wrote: Think about this in the context of a SIP trunking provider where the systems in question are customer systems that you cannot control, pull CDR off of, or require diversion headers from. You can't tell the customer you won't provide them SIP trunks because "their system sucks". Because you are trying to support a wide range of systems, the presence or absence of a diversion header will be a variable. -Scott -----Original Message----- From: anorexicpoodle [mailto:anorexicpoodle at gmail.com] Sent: Wednesday, November 11, 2009 3:12 PM To: Alex Balashov Cc: Scott Berkman; voiceops at voiceops.org Subject: Re: [VoiceOps] Billing of Forwarded Calls Look for the presence of a diversion header, if the diversion header is there, then that is the responsible party. I cannot speak to the particulars of your platform, but as long as you make sure that if a diversion header is present it is assigned as the responsible party your billing should come out correct in this flow. If your switch/endpoint is not adding a diversion header then I am inclined to agree with Alex. On Wed, 2009-11-11 at 13:01 -0500, Alex Balashov wrote:
Scott Berkman wrote:
So how do most of you deal with billing of forwarded calls (specifically where the calling number on the forwarded leg is using the original calling number from the inbound leg) in a SIP environment when the originally called number is not preserved in the new invite? In this case there is no way to match the calling or called number to a specific customer.
Do you bill by IP address or interface instead? Do you somehow use a system that correlates the forwarded leg to the original inbound leg? I?ve come across this issue a few different times when trying to bill off of SIP messaging logs, for instance radius off a SIP SBC or SQL logs from SER.
In my view, that depends on what is doing the forwarding.
If it's the customer handset actually initiating the forward, then it should just look like a normal termination call from the customer.
If it's a multi-tenant switch or other call control agent, it should have some way of associating forwarded calls with an account and sticking an account ID or similar into the CDRs, which will reveal who to bill and presumably the rate plan to use.
If it can't do that, the product sucks.
-- Alex
Then you're screwed. This is why I mandate the use of CPE that supports authentication and/or registration; if it can't be authenticated, it can't be authorised or accounted either. AAA for the win. Scott Berkman wrote:
A is not possible since the ANI being sent is ?valid? in NANP. B is not possible based on customer demands, otherwise this would be my preferred solution. C is not supported by some of the systems involved.
-Scott
*From:* anorexicpoodle [mailto:anorexicpoodle at gmail.com] *Sent:* Wednesday, November 11, 2009 3:47 PM *To:* Scott Berkman *Cc:* 'Alex Balashov'; voiceops at voiceops.org *Subject:* RE: [VoiceOps] Billing of Forwarded Calls
If this is in the context of a customer trunk, and the forward is being completed via invite from their system, and I presume that means that they will stay in the flow for the duration, then you can either:
A: Assign their trunk a default source ani for all traffic that doesn't have a valid source (from, diversion etc) assigned to the trunk.
B: Reject the call since it was offered from an ANI that is not provisioned on the customers trunk.
C: Challenge all invites and assign the call to the authenticating account
Unfortunately if the CPE can't/won't tell you the actual originating number and the 2 calls are not explicitly related (forwarded by B2BUA so callid is different etc) then you don't have much other recourse.
On Wed, 2009-11-11 at 15:23 -0500, Scott Berkman wrote:
Think about this in the context of a SIP trunking provider where the systems in question are customer systems that you cannot control, pull CDR off of, or require diversion headers from. You can't tell the customer you won't provide them SIP trunks because "their system sucks". Because you are trying to support a wide range of systems, the presence or absence of a diversion header will be a variable.
-Scott
-----Original Message-----
From: anorexicpoodle [mailto:anorexicpoodle at gmail.com]
Sent: Wednesday, November 11, 2009 3:12 PM
To: Alex Balashov
Cc: Scott Berkman; voiceops at voiceops.org <mailto:voiceops at voiceops.org>
Subject: Re: [VoiceOps] Billing of Forwarded Calls
Look for the presence of a diversion header, if the diversion header is
there, then that is the responsible party. I cannot speak to the
particulars of your platform, but as long as you make sure that if a
diversion header is present it is assigned as the responsible party your
billing should come out correct in this flow. If your switch/endpoint is
not adding a diversion header then I am inclined to agree with Alex.
On Wed, 2009-11-11 at 13:01 -0500, Alex Balashov wrote:
Scott Berkman wrote:
So how do most of you deal with billing of forwarded calls (specifically
where the calling number on the forwarded leg is using the original
calling number from the inbound leg) in a SIP environment when the
originally called number is not preserved in the new invite? In this
case there is no way to match the calling or called number to a specific
customer.
Do you bill by IP address or interface instead? Do you somehow use a
system that correlates the forwarded leg to the original inbound leg?
I?ve come across this issue a few different times when trying to bill
off of SIP messaging logs, for instance radius off a SIP SBC or SQL logs
from SER.
In my view, that depends on what is doing the forwarding.
If it's the customer handset actually initiating the forward, then it
should just look like a normal termination call from the customer.
If it's a multi-tenant switch or other call control agent, it should
have some way of associating forwarded calls with an account and
sticking an account ID or similar into the CDRs, which will reveal who
to bill and presumably the rate plan to use.
If it can't do that, the product sucks.
-- Alex
-- Alex Balashov - Principal Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671
Scott Berkman wrote:
A is not possible since the ANI being sent is ?valid? in NANP. B is not possible based on customer demands, otherwise this would be my preferred solution. C is not supported by some of the systems involved.
It sounds like you've got bigger problems then. What's to keep your customers from sending calls from a non-assigned number and skirting your CDRs for *all* their calls? It seems to me that the two scenarios are identical. Corey
If you authenticate the invite, can't you use the username to bill? Scott Berkman wrote:
So how do most of you deal with billing of forwarded calls (specifically where the calling number on the forwarded leg is using the original calling number from the inbound leg) in a SIP environment when the originally called number is not preserved in the new invite? In this case there is no way to match the calling or called number to a specific customer.
Do you bill by IP address or interface instead? Do you somehow use a system that correlates the forwarded leg to the original inbound leg? I've come across this issue a few different times when trying to bill off of SIP messaging logs, for instance radius off a SIP SBC or SQL logs from SER.
Thanks,
-Scott
------------------------------------------------------------------------
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
Many platforms don't support authentication on SIP trunks. -Scott From: Lee Riemer [mailto:lriemer at bestline.net] Sent: Wednesday, November 11, 2009 1:15 PM To: Scott Berkman Cc: voiceops at voiceops.org Subject: Re: [VoiceOps] Billing of Forwarded Calls If you authenticate the invite, can't you use the username to bill? Scott Berkman wrote: So how do most of you deal with billing of forwarded calls (specifically where the calling number on the forwarded leg is using the original calling number from the inbound leg) in a SIP environment when the originally called number is not preserved in the new invite? In this case there is no way to match the calling or called number to a specific customer. Do you bill by IP address or interface instead? Do you somehow use a system that correlates the forwarded leg to the original inbound leg? I've come across this issue a few different times when trying to bill off of SIP messaging logs, for instance radius off a SIP SBC or SQL logs from SER. Thanks, -Scott _____ _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
participants (5)
-
abalashov＠evaristesys.com -
anorexicpoodle＠gmail.com -
lriemer＠bestline.net -
scott＠sberkman.net -
tensai＠zmonkey.org