[SR-Users] Evapi reply processing

Daniel-Constantin Mierla miconda at gmail.com
Thu Dec 4 11:44:38 CET 2014


Hello,

there is a function that 'parks' the request already:

http://kamailio.org/docs/modules/stable/modules/evapi.html#evapi.f.evapi_async_relay

Be sure you keep somehow the values of $T(id_index) and $T(id_label)
(either in htable, or send them to cgrates and they have to be returned
back in reply) to resume the transaction with t_continue():

http://kamailio.org/docs/modules/stable/modules/tmx.html#idp110920

Cheers,
Daniel

On 04/12/14 10:51, DanB wrote:
> Hey Guys,
>
> We are in the process of implementing prepaid control using CGRateS
> engine and for that we will be using evapi module (thanks Daniel again
> for that).
>
> I was wondering if you can advice us whether the path we are taking is
> the correct one.
>
> On INVITE, we will initiate a MaxCallTimeout (sort of call auth) to
> CGRateS via evapi. Once request sent, we should "park" the request
> somehow (right now we are considering sleep in the process via usleep
> and recheck for the answer every 5-10 milliseconds). Answer should be
> shared via htable. Could you recommend us a better approach?
>
> On reply, the answer processed in event route evapi:message-received
> should set in htable a key of combination callid:fromtag with the
> maximum call duration or auth reject if not enough balance. This key
> should be processed by the sleeping process on wakeup.
>
> What do u think, is there a better way to approach the 2 ways
> communication?
>
> Thanks in advance for any kind of tip!
>
> DanB
>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20141204/1ef652c0/attachment.html>


More information about the sr-users mailing list