Hi Daniel,

Perfect, thank you - now I understand.

Cheers,
Charles

On 15 Oct 2014 21:11, "Daniel-Constantin Mierla" <miconda@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@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 Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda

www.sipcentric.com

Follow us on twitter @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.