Normally this means that you haven't actually done anything with the call,
but you are t_relaying it out.
In other words, the RURI was destined for your opensips box.. That's how it
got there.. it hit opensips, then you sent it back out.. But you never
adjusted the RURI to point to the next hop
Hi, Gordon!
Actually this CDR is not encrypted, the data is taken plain text from
the message. Here is the interpretation of a few fields:
26A86646-D8FC11E3-9507C13F-D7186497@10.0.119.253 - callid
4BD8F748-1DEE - from tag
as09912ec8 - to tag
Best regards,
Razvan Crainea
OpenSIPS Core
Thank you Razvan for the clarification,
So it appears to be pulling data from somewhere that I do not want to
record. I presume that there should be a setting or definition in the
opensips.cfg file that would tell it where to pull the proper data from.
Here is a snippet of mine:
Hi, Gordon!
Those are the default CDR values, you can't prevent them from being
stored. However, if you want extra values, you should use the db_extra
module parameter[1].
[1] http://www.opensips.org/html/docs/modules/1.12.x/acc#id295025
Best regards,
Razvan Crainea
OpenSIPS Core Developer
This makes *a lot* of sense. Thanks!I expected the SIP REGISTER to be
terminated at the instance rather than forwarded as I had that user/pw
combo in the subscribers table. I assume it doesn't do that by default I
have to add a command to the routing logic to do that? Or, architecturally,
should I
So OpenSIPs doesn't do anything on it's own. If you just downloaded, and
compiled... I can say with like 99% certainty it's not going to do what you
want. It's just a toolkit.
For example, if your config doesn't explicitly check the register to see if
it's valid, it's not doing it.
The sample
