Jiri,
I don't think I completely understand your earlier answer -- or maybe it wasn't clear what I wanted to achieve.
| At 07:13 PM 2/25/2003, Stephan Reiff-Marganiec wrote: | >1) how do I get a message that I have received -- say in | char *msg_buf -- to | >be the message that is used for further routing? | | The mechanism we use now is reply_route. We mark transactions | to be revisited | when a final negative reply comes back with t_on_negative. | then, reply_route | is entered and the original request is processed again. One | could achieve | similar functionality which would be less script-programmable | but more powerful | using TM callbacks. |
Here is a little scenario (the module talks to My Server via a TCP Socket):
---- ------------------------ UAC ---------------> SER --------------------->remote end ---- INVITE(a) ------------------------ | /\ | | | INVITE(a) | ****INVITE(c), NOTIFY(d)***** / | ------------------------ MODULE ------------------------ | /\ | | | INVITE(a) | INVITE(c), NOTIFY(d) | | / | ------------------------ MY SERVER ------------------------
The user agent sends an invite (but this could be any other message) which is passed via a ser module to "My Server". My server now adopts the message dependent on some internal rules and will generate new sip messages, which are transferred back to the module. This exchange happens via a TCP connection and works. Module receives the message back and logs it. The whole process is triggered by start_exec() in the route block of ser.cfg. Within module I now have something like:
int start_exec(struct sipmsg *msg) { //... send msg to myserver and receive response // ... receive len of response // buf is: char *buf; n = recv(socket, buf, len, MSG_WAITALL); exit (1); }
at this point buf contains the reposnse(s) that I wish to replace the original message. They are plain sip messages (that is they are text). These message(s) should now be used in the routing instead of the original one. I do not need stateful routing ... hance the tm module seems to be an overkill.
Using Reply_route seems too restricted, as far as I understand it: Depending on the int return value the ser.cfg script knows what should happen. However, an int return is not rich enough for me (well, there simply would be too many cases), as the above example should show.
I appreciate your advice.
Stephan
-- Dr Stephan Reiff-Marganiec Research Fellow Department of Computing Science; University of Stirling email: srm@cs.stir.ac.uk tel: 01786 46 7448