asterisk users - Jul 2007 - Simple CDRs w/Asterisk/OpenSER.

Suggestions on how to use Asterisk to collect CDRs from a OpenSER-based 
proxy / call routing setup?  I need to get simple CDRs;  not for detailed
settlement/rating, but just for reconciliation with an ultimate TDM 
carrier just to make sure we only get billed for what we're actually
using.

I'd use the often-heralded approach of dumping a call from OpenSER into
Asterisk and having it bounce right back out toward the proxy by way of
REINVITEs.  I don't want the media running through Asterisk or Asterisk
being a limiting factor in that regard.

The problem is I don't have native G.729 support - we have no need for
it because neither the customer's network elements nor ours lack an
implementation of their own they can negotiate on just fine.  But
unfortunately Asterisk insists on natively homogenising the SDP from
both sides even if it subsequently removes itself from the media path!

So, I end up with situations where on the one side, I get, say:

 	Customer MGW --> OpenSER --> Asterisk - sends call as G.729.

 	Asterisk --> OpenSER --> Our MGW - our MGW prefers G.711a.

Now, if customer MGW <-> Our MGW were talking directly, as they do
when the deal is brokered through the OpenSER proxy, they would simply
negotiate upon what they agree.  But for some reason with Asterisk
this does not seem to be working as advertised;  we get lots of failed
calls if we pass them through Asterisk because one leg is one codec
and the other is another.  I am not sure how it arrives at that
conclusion despite the overlap of shared codecs (G.729 on both sides,
I would expect it to pass thru licence-free), and to be honest, I
don't particularly care if it's a bug or a feature, I just need it
not to introduce codec issues if I use it as a billing target.

Any help or insight would be greatly appreciated.

Thanks,

--
Alex Balashov
Evariste Systems
Web    : http://www.evaristesys.com/
Tel    : +1-678-954-0670
Direct : +1-678-954-0671

Asterisk is poor with codec negotiation . It does not check if it can avoid
transcoding  by forcing codec available to both sides .. instead it will
read it's config file and will select first allowed codec that  is also
available on other device on each leg of call and happily transcode between
them .There was a patch on digium submitted by someone for asterisk 1.2.12
or so but it isnt updated from long time .  I am sure guys at digium are
aware about it and working on it . It's not  a bug  since asterisk is not a
sip proxy and tries to keep media path through it to offer its pbx features
but it would be a great feature nonetheless if implemented .

On 05/07/07, Alex Balashov <abalashov at evaristesys.com>
wrote:
>
>
> Suggestions on how to use Asterisk to collect CDRs from a OpenSER-based
> proxy / call routing setup?  I need to get simple CDRs;  not for detailed
> settlement/rating, but just for reconciliation with an ultimate TDM
> carrier just to make sure we only get billed for what we're actually
> using.
>
> I'd use the often-heralded approach of dumping a call from OpenSER into
> Asterisk and having it bounce right back out toward the proxy by way of
> REINVITEs.  I don't want the media running through Asterisk or Asterisk
> being a limiting factor in that regard.
>
> The problem is I don't have native G.729 support - we have no need for
> it because neither the customer's network elements nor ours lack an
> implementation of their own they can negotiate on just fine.  But
> unfortunately Asterisk insists on natively homogenising the SDP from
> both sides even if it subsequently removes itself from the media path!
>
> So, I end up with situations where on the one side, I get, say:
>
>         Customer MGW --> OpenSER --> Asterisk - sends call as G.729.
>
>         Asterisk --> OpenSER --> Our MGW - our MGW prefers G.711a.
>
> Now, if customer MGW <-> Our MGW were talking directly, as they do
> when the deal is brokered through the OpenSER proxy, they would simply
> negotiate upon what they agree.  But for some reason with Asterisk
> this does not seem to be working as advertised;  we get lots of failed
> calls if we pass them through Asterisk because one leg is one codec
> and the other is another.  I am not sure how it arrives at that
> conclusion despite the overlap of shared codecs (G.729 on both sides,
> I would expect it to pass thru licence-free), and to be honest, I
> don't particularly care if it's a bug or a feature, I just need it
> not to introduce codec issues if I use it as a billing target.
>
> Any help or insight would be greatly appreciated.
>
> Thanks,
>
> --
> Alex Balashov
> Evariste Systems
> Web    : http://www.evaristesys.com/
> Tel    : +1-678-954-0670
> Direct : +1-678-954-0671
>
> _______________________________________________
> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.digium.com/pipermail/asterisk-users/attachments/20070705/c1cd8eaf/attachment.htm