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(a)cs.stir.ac.uk tel: 01786 46 7448 -- The University of Stirling is a university established in Scotland by charter at Stirling, FK9 4LA. Privileged/Confidential Information may be contained in this message. If you are not the addressee indicated in this message (or responsible for delivery of the message to such person), you may not disclose, copy or deliver this message to anyone and any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. In such case, you should destroy this message and kindly notify the sender by reply email. Please advise immediately if you or your employer do not consent to Internet email for messages of this kind. Opinions, conclusions and other information in this message that do not relate to the official business of the University of Stirling shall be understood as neither given nor endorsed by it.

At 01:22 PM 2/28/2003, Jiri Kuthan wrote: I realized another way how you can think of your policy server (if it makes sense in you scenario) -- rather than giving a full resulting message, it can give just diffs to the original message. Actually, sip cgi-bin (rfc-3050) is doing something similar -- it tells add_header, delete_header, etc. You can decide whether you would like to have them high-level (append_header, replace_header) or low-level (insert this string at offset 13). Just came in my mind and I aired it in case you are seeking kibitzing. -Jiri