[Asterisk-Users] CDR for transfered calls

[John Todd]

At 5:13 PM -0400 on 6/15/04, James Golovich wrote:
>On Tue, 15 Jun 2004, John Todd wrote:
>
>>
>>  Not all Asterisk channel types lose control when they step out of the
>>  media stream.  SIP devices will notify the proxy server (Asterisk, in
>>  our case) that a call has terminated, so even though the media stream
>>  never went through the "proxy" (Asterisk).  This is an important
>>  distinction between IAX2 and SIP - media and control messages are not
>>  tightly linked with SIP as they are with IAX2.  Until IAX2 has some
>>  type of "backwards path notification", there is no method (to my
>>  knowledge) that IAX2 can notify the origin servers that the call has
>>  been terminated.  The only way for any server in the path to know the
>>  status of the call (with IAX2) is to not transfer the call away from
>>  itself, thus bearing the full load of the media stream and the
>>  control channel.
>>
>>  I would be happy to learn of other's experiences in managing this
>>  issue, as it is quite important (mandatory, really) in any type of
>>  managed service environment.
>>
>
>If you depend on behavior of an unspecified client your asking for
>trouble. It would be pretty trivial to get a client to send back this
>'Call Completed' message right after a re-invite/native bridge has
>completed.  If you have access to the source you can modify the client to
>do it, or if you have access to the network you have something proxy'ng
>the packets and at certain times including or excluding certain messages
>
>James

1) That is true with SIP as well, so the threat is already 
understood.  If the Asterisk server in the middle receives a "Call 
Completed" message from one side, it should send a "Call Completed" 
message to the other side, which should (and I use the word "SHOULD" 
in the RFC meaning) cause the other side to hang up the call if it 
has not already done so.

   If there are two users of the same software package, and they 
conspire to generate bogus "Call Completed" messages and then ignore 
them, it would be possible for those two users to keep their media 
stream flowing and "cheat" the Asterisk server in the middle into 
thinking that the call had completed.  However, the media stream is 
not flowing through any Asterisk components, so this risk is limited. 
The trick is that if the same provider controls one side of the 
channel then this is not a problem since the endpoint that is owned 
by the "provider" would honor the "Call Completed" message.

   I think my point is "it's better to have some information than no 
information" in a provider setting.  It is ultimately impossible to 
regulate this if you're billing for it at the call level, but from a 
logging and troubleshooting perspective this is really a "good thing" 
to have.  The ability (default setting) for IAX2-to-IAX2 calls to 
"vanish" from the server's perspective after a call is set up will 
cause future heartache from customer service, metrics-gathering, and 
legal perspectives.

2) Any method needs to understand and consider the possibility of 
multiple levels of transferring.  This is the same headache with 
encryption.  If I have an architecture of three or four levels deep 
of IAX2 connections that pass a call between each other, the 
"original" server probably should somehow have the _option_ of 
keeping track of that call's length and status, and optionally 
closing the call down.  This is not just from a traditional telco 
point of view (billing, fraud, etc) but there are other reasons one 
might want to do this that are non-obvious.  The originating server 
needs to be able to control the status of a call that was passed to 
it without "nailing up" the media stream.


   I might be wrong here, on two counts: first, that any server in the 
path of reference needs to know the state of a call.  SIP is built on 
a stateless model, but Asterisk is half-stateless - it always keeps 
state for calls that are passing through it, but it tries to get rid 
of those calls as quickly as possible by relinquishing control to the 
clients.  Maybe this is good, maybe it's ultimately flawed.   The 
second place I might be flawed is that maybe we can keep the media 
stream; maybe it's not such a huge burden for what Asterisk is trying 
to do.  G.729 or ilbc are down in the <20 kbps range, so for a system 
that claims to be a "PBX", perhaps that's not a big deal.  If this 
claimed to be a "softswitch" then that would be a problem.  Many 
people are using it as a softswitch, which could cause the 
"half-stateless" and "media relay" problems to collide in a very ugly 
explosion of bad CDR's or Gig-E transit connections...

JT