We’ve got an open NAP set up and have been able to get the user ends to register to our registrar via ProSBC and match ProSBC cached contacts on the username during outbound calls (inbound to ProSBC, outbound to carrier).
However, we’re also using ProSBC’s CDR (text now, RADIUS soon) for call billing. I don’t see a clear way to be able to, script driven or not, embed the auth username associated with the call to the CDR Record.
Trying to see if there’s a better way around this which eliminates creating one NAP + registration domain per register-type TRUNK customer whose call routing doesn’t go to the registrar (which works fine for extensions/endpoints..)
Hi cmsbnvx,
Before we point you at a solution, or confirm this would require an enhancement, we want to make sure we understand the setup correctly. A few clarifying questions:
Who is acting as the registrar?
ProSBC itself?
an upstream registrar behind ProSBC?
or ProSBC registering upstream on behalf of the endpoint?
Who is authenticating the REGISTER?
does ProSBC issue the Digest challenge itself, or does it relay the challenge from another system?
where do the credentials actually live?
Which identity do you want to appear in the CDR?
the Digest Authorization username
the registered AOR / Contact identity
the auth username on the outbound INVITE (if applicable)
or some other customer/account identifier associated with the registration
Can you provide a sanitized example of a typical REGISTER and INVITE? If possible, the most useful fields would be:
Authorization username
From
To
Contact
P-Asserted-Identity / P-Preferred-Identity if present
Are the registration username and the customer billing identity always the same? If yes, there may be a simpler mapping/workaround than exposing the Digest username directly.
Is the planned RADIUS usage for accounting/CDR export only, or also for SIP authentication?
Roughly how many trunk customers are involved, and is the concern mainly scale/operations, or do you specifically need a single shared ingress/registration model?
Do you need this value in:
the current text CDRs
future RADIUS accounting
or both
Once we have those details, we can tell you more definitively whether this is:
solvable with configuration or scripting
achievable by mapping to an existing identity already available to the CDR path
or something that would require an enhancement request
-Support