[sr-dev] DMQ: seems broken logic

Charles Chance charles.chance at sipcentric.com
Wed Oct 15 22:40:43 CEST 2014


Hi Daniel,

Perfect, thank you - now I understand.

Cheers,
Charles
 On 15 Oct 2014 21:11, "Daniel-Constantin Mierla" <miconda at gmail.com> wrote:

>  Hello,
>
> On 15/10/14 20:36, Charles Chance wrote:
>
> Hi Daniel,
>
> On 15 October 2014 14:51, Daniel-Constantin Mierla <miconda at gmail.com>
> wrote:
>
>>  Hello,
>>
>> one thing I wanted to add -- it may be good to backup the old value of
>> the sock and restore it later.
>>
>>
>  Thanks - I had that in mind already.
>
>
>>  I am not sure if this is used in a context of a request that is going to
>> be forwarded as well to some other address. If yes, then perhaps is it
>> safer to backup and restore initial socket value.
>>
>> Perhaps it needs to check if the transaction exists and if not, create it
>> first via tm api, then set the new socket for message and call the
>> t_replicate function, not to get the dmq server socket in tm.
>>
>>
>  Sorry, I don't fully understand the last part?
>
> t_replicate() create the transaction for the respective requests (if the
> transaction doesn't exist already). Creation of the transaction involves
> cloning to shared memory the sip_msg_t structure. If you update the forced
> socket to dmq server address for the request, it gets in shared memory with
> the new value, which may be wrong for further processing of the message in
> branch/failure routes.
>
> My suggestion is to check if transaction exists and if not, first create
> it and then backup socket, update it for dmq address, do the replication
> and restore the socket from backup (note that the dmq the function will
> still use the sip_msg_t from private memory even after creating the
> transaction).
>
> Cheers,
> Daniel
>
> --
> Daniel-Constantin Mierlahttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
>
>

-- 
www.sipcentric.com

Follow us on twitter @sipcentric <http://twitter.com/sipcentric>

Sipcentric Ltd. Company registered in England & Wales no. 7365592. Registered 
office: Faraday Wharf, Innovation Birmingham Campus, Holt Street, 
Birmingham Science Park, Birmingham B7 4BB.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20141015/0e3f4ec8/attachment.html>


More information about the sr-dev mailing list