15 Oct
2014
15 Oct
'14
11:40 p.m.
Hi Daniel,
Perfect, thank you - now I understand.
Cheers,
Charles
On 15 Oct 2014 21:11, "Daniel-Constantin Mierla" <miconda(a)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(a)gmail.com>
wrote:
--
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.
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