Hi
We are using the t_suspend and t_continue functionality to asynchronously send Diameter messages.
This works nicely when we suspend and resume on a SIP request. However in some circumstances we want to send a Diameter message on a SIP response.
I have found that the SIP responses continue to be relayed despite being suspended and returning 0 to the cfg file.
I am investigating the cause but before I get any deeper does anyone know if the t_suspend and t_continue functionality in the tm module can be used on a SIP response?
Regards Richard.
This email is subject to the disclaimer of Smile Communications (PTY) Ltd. at http://www.smilecoms.com/disclaimer
Hello,
t_suspend() and t_continue() are only for requests at this moment.
Cheers, Daniel
On 3/6/13 2:49 PM, Richard Good wrote:
Hi
We are using the t_suspend and t_continue functionality to asynchronously send Diameter messages.
This works nicely when we suspend and resume on a SIP request. However in some circumstances we want to send a Diameter message on a SIP response.
I have found that the SIP responses continue to be relayed despite being suspended and returning 0 to the cfg file.
I am investigating the cause but before I get any deeper does anyone know if the t_suspend and t_continue functionality in the tm module can be used on a SIP response?
Regards Richard.
This email is subject to the disclaimer of Smile Communications (PTY) Ltd. at http://www.smilecoms.com/disclaimer
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Hi Daniel and other TM experts
We have been working on a prototype for being able to use the t_suspend() and t_continue() methods for SIP responses. The version in branch /tmp/tm_async_reply_support is working, though still needs to be 100% tested and only works for 1 branch (i.e. no forking)**
Would it be possible for you to have a look at this branch code and see if we are on the right track. The code is working but TM (as mentioned in the documentation ;)) can be tricky to program and we want to make sure we are not breaking anything, as the goal is to get this into the master branch.
The changes we have done:
1. parser/msg_parser.h: added new message state FL_RPL_SUSPENDED 2. tm/h_table.h: added int suspended_request to ua_server and int suspended_reply to ua_client 3. tm/t_suspend.c:t_suspend 1. Changed suspend method to check if the message is a request or response and set the suspended_request/suspended_reply variable accordingly 2. If its a request we do as the existing code 3. If its a response we get the correct uac branch, clone the msg into t->uac[branch].reply and set the msg state to FL_RPL_SUSPENDED 4. tm/t_reply.c: if msg is in state FL_RPL_SUSPENDED then we skip sending the reply on 5. tm/t_suspend.c:t_continue 1. Check if this uas was suspended - if so this is a continue for a request so continue with existing code 2. If not then we search for the branch that was suspended 3. Once branch is found unsuspend the message state 4. do pre-script, run_top_route and post scripts 5. Relay the reply using basically the same code we skipped in step 4
First next step after we confirm we are on the right track is to add forking support - this will require a new t_continue method where the calling application passes in the branch of the suspended reply when wanting to continue.
Any comments/feedback would be appreciated.
Regards
Richard.
On 11 March 2013 14:34, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
t_suspend() and t_continue() are only for requests at this moment.
Cheers, Daniel
On 3/6/13 2:49 PM, Richard Good wrote:
Hi
We are using the t_suspend and t_continue functionality to asynchronously send Diameter messages.
This works nicely when we suspend and resume on a SIP request. However in some circumstances we want to send a Diameter message on a SIP response.
I have found that the SIP responses continue to be relayed despite being suspended and returning 0 to the cfg file.
I am investigating the cause but before I get any deeper does anyone know if the t_suspend and t_continue functionality in the tm module can be used on a SIP response?
Regards Richard.
This email is subject to the disclaimer of Smile Communications (PTY) Ltd. at http://www.smilecoms.com/disclaimer
sr-dev mailing listsr-dev@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-- Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio World Conference, April 16-17, 2013, Berlin
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
This email is subject to the disclaimer of Smile Communications (PTY) Ltd. at http://www.smilecoms.com/disclaimer
Hi
I've finally got working functionality for t-suspend and t_continue for SIP responses in the tmp/tm_async_reply_support branch.
I've memory and load tested the branch and have also isolated the changes so that if there are problems they will only be experienced if you use the new API functions.
However keeping mind that TM can be tricky to program (as mentioned in the documentation ;)) - I've included below a summary of the changes and a git diff against the latest master. So the TM experts can have a look and see if there are any obvious problems.
If there are no complaints or queries I will commit the changes to master next week Friday (July 12).
Regards Richard.
Change summary: 1. parser/msg_parser.h: added new message state FL_RPL_SUSPENDED 2. tm_load.c: new api functions: *t_suspend_reply*, *t_continue_reply* and *t_cancel_suspend_reply* 3. t_suspend.c/h: new methods: *t_suspend_reply*, *t_continue_reply* and * t_cancel_suspend_reply *4. tm/t_reply.c: if msg is in state FL_RPL_SUSPENDED then we skip sending the reply on 5. tm/t_reply.c/h: new methods to fake env for responses: *faked_env_resp, faked_resp, free_faked_resp * 6. API documentation to include new functions: *t_suspend_reply*, * t_continue_reply* and *t_cancel_suspend_reply
* * * * *
On 18 March 2013 14:13, Richard Good richard.good@smilecoms.com wrote:
Hi Daniel and other TM experts
We have been working on a prototype for being able to use the t_suspend() and t_continue() methods for SIP responses. The version in branch /tmp/tm_async_reply_support is working, though still needs to be 100% tested and only works for 1 branch (i.e. no forking)**
Would it be possible for you to have a look at this branch code and see if we are on the right track. The code is working but TM (as mentioned in the documentation ;)) can be tricky to program and we want to make sure we are not breaking anything, as the goal is to get this into the master branch.
The changes we have done:
- parser/msg_parser.h: added new message state FL_RPL_SUSPENDED
- tm/h_table.h: added int suspended_request to ua_server and int
suspended_reply to ua_client 3. tm/t_suspend.c:t_suspend 1. Changed suspend method to check if the message is a request or response and set the suspended_request/suspended_reply variable accordingly 2. If its a request we do as the existing code 3. If its a response we get the correct uac branch, clone the msg into t->uac[branch].reply and set the msg state to FL_RPL_SUSPENDED 4. tm/t_reply.c: if msg is in state FL_RPL_SUSPENDED then we skip sending the reply on 5. tm/t_suspend.c:t_continue 1. Check if this uas was suspended - if so this is a continue for a request so continue with existing code 2. If not then we search for the branch that was suspended 3. Once branch is found unsuspend the message state 4. do pre-script, run_top_route and post scripts 5. Relay the reply using basically the same code we skipped in step 4
First next step after we confirm we are on the right track is to add forking support - this will require a new t_continue method where the calling application passes in the branch of the suspended reply when wanting to continue.
Any comments/feedback would be appreciated.
Regards
Richard.
On 11 March 2013 14:34, Daniel-Constantin Mierla miconda@gmail.comwrote:
Hello,
t_suspend() and t_continue() are only for requests at this moment.
Cheers, Daniel
On 3/6/13 2:49 PM, Richard Good wrote:
Hi
We are using the t_suspend and t_continue functionality to asynchronously send Diameter messages.
This works nicely when we suspend and resume on a SIP request. However in some circumstances we want to send a Diameter message on a SIP response.
I have found that the SIP responses continue to be relayed despite being suspended and returning 0 to the cfg file.
I am investigating the cause but before I get any deeper does anyone know if the t_suspend and t_continue functionality in the tm module can be used on a SIP response?
Regards Richard.
This email is subject to the disclaimer of Smile Communications (PTY) Ltd. at http://www.smilecoms.com/disclaimer
sr-dev mailing listsr-dev@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-- Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio World Conference, April 16-17, 2013, Berlin
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
This email is subject to the disclaimer of Smile Communications at http://www.smilecoms.com/disclaimer
Hello,
the patch cannot be applied as it is. The comments contain references to request processing, which is obviously wrong. Then I have seen code specific to requests, like managing the request uri or dst uri -- these fields shouldn't be set for replies, it's ok as safety to clear them up, but not cloning.
From the patch I see the new function are only for internal usage, not for config file. Are they supposed to be used only in the transaction context (i.e., after the transaction is matched for reply)?
Cheers, Daniel
On 7/4/13 5:24 PM, Richard Good wrote:
Hi
I've finally got working functionality for t-suspend and t_continue for SIP responses in the tmp/tm_async_reply_support branch.
I've memory and load tested the branch and have also isolated the changes so that if there are problems they will only be experienced if you use the new API functions.
However keeping mind that TM can be tricky to program (as mentioned in the documentation ;)) - I've included below a summary of the changes and a git diff against the latest master. So the TM experts can have a look and see if there are any obvious problems.
If there are no complaints or queries I will commit the changes to master next week Friday (July 12).
Regards Richard.
Change summary:
- parser/msg_parser.h: added new message state FL_RPL_SUSPENDED
- tm_load.c: new api functions: *t_suspend_reply*,
*t_continue_reply* and *t_cancel_suspend_reply* 3. t_suspend.c/h: new methods: *t_suspend_reply*, *t_continue_reply* and *t_cancel_suspend_reply *4. tm/t_reply.c: if msg is in state FL_RPL_SUSPENDED then we skip sending the reply on 5. tm/t_reply.c/h: new methods to fake env for responses: *faked_env_resp, faked_resp, free_faked_resp
- API documentation to include new functions: *t_suspend_reply*,
*t_continue_reply* and *t_cancel_suspend_reply
On 18 March 2013 14:13, Richard Good <richard.good@smilecoms.com mailto:richard.good@smilecoms.com> wrote:
Hi Daniel and other TM experts We have been working on a prototype for being able to use the t_suspend() and t_continue() methods for SIP responses. The version in branch /tmp/tm_async_reply_support is working, though still needs to be 100% tested and only works for 1 branch (i.e. no forking) Would it be possible for you to have a look at this branch code and see if we are on the right track. The code is working but TM (as mentioned in the documentation ;)) can be tricky to program and we want to make sure we are not breaking anything, as the goal is to get this into the master branch. The changes we have done: 1. parser/msg_parser.h: added new message state FL_RPL_SUSPENDED 2. tm/h_table.h: added int suspended_request to ua_server and int suspended_reply to ua_client 3. tm/t_suspend.c:t_suspend 1. Changed suspend method to check if the message is a request or response and set the suspended_request/suspended_reply variable accordingly 2. If its a request we do as the existing code 3. If its a response we get the correct uac branch, clone the msg into t->uac[branch].reply and set the msg state to FL_RPL_SUSPENDED 4. tm/t_reply.c: if msg is in state FL_RPL_SUSPENDED then we skip sending the reply on 5. tm/t_suspend.c:t_continue 1. Check if this uas was suspended - if so this is a continue for a request so continue with existing code 2. If not then we search for the branch that was suspended 3. Once branch is found unsuspend the message state 4. do pre-script, run_top_route and post scripts 5. Relay the reply using basically the same code we skipped in step 4 First next step after we confirm we are on the right track is to add forking support - this will require a new t_continue method where the calling application passes in the branch of the suspended reply when wanting to continue. Any comments/feedback would be appreciated. Regards Richard. On 11 March 2013 14:34, Daniel-Constantin Mierla <miconda@gmail.com <mailto:miconda@gmail.com>> wrote: Hello, t_suspend() and t_continue() are only for requests at this moment. Cheers, Daniel On 3/6/13 2:49 PM, Richard Good wrote:Hi We are using the t_suspend and t_continue functionality to asynchronously send Diameter messages. This works nicely when we suspend and resume on a SIP request. However in some circumstances we want to send a Diameter message on a SIP response. I have found that the SIP responses continue to be relayed despite being suspended and returning 0 to the cfg file. I am investigating the cause but before I get any deeper does anyone know if the t_suspend and t_continue functionality in the tm module can be used on a SIP response? Regards Richard. This email is subject to the disclaimer of Smile Communications (PTY) Ltd. athttp://www.smilecoms.com/disclaimer _______________________________________________ sr-dev mailing list sr-dev@lists.sip-router.org <mailto:sr-dev@lists.sip-router.org> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev-- Daniel-Constantin Mierla -http://www.asipto.com http://twitter.com/#!/miconda <http://twitter.com/#%21/miconda> -http://www.linkedin.com/in/miconda Kamailio World Conference, April 16-17, 2013, Berlin -http://conference.kamailio.com - _______________________________________________ sr-dev mailing list sr-dev@lists.sip-router.org <mailto:sr-dev@lists.sip-router.org> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-devThis email is subject to the disclaimer of Smile Communications at http://www.smilecoms.com/disclaimer
Hi
Thanks very much for the quick feedback. My comments inline.
Regards Richard.
On 6 July 2013 19:48, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
the patch cannot be applied as it is. The comments contain references to request processing, which is obviously wrong. Then I have seen code specific to requests, like managing the request uri or dst uri -- these fields shouldn't be set for replies, it's ok as safety to clear them up, but not cloning.
I've gone through the code (and comments) in detail and removed all incorrect references to request code. I've also removed the dst/request URI management from the faked_resp method. Attached is the patch for these changes.
From the patch I see the new function are only for internal usage, not for config file. Are they supposed to be used only in the transaction context (i.e., after the transaction is matched for reply)?
This patch closely follows the pattern of the t_suspend(), t_continue() functions that are for programmatic use only. We use the t_suspend_reply() and t_continue_reply() functions in the ims_qos module so did not need to expose it to the config file.
I suppose the suspend functionality for requests and responses could be exposed to the config file if required - but it has not been done in this patch.
Cheers, Daniel
On 7/4/13 5:24 PM, Richard Good wrote:
HiI've finally got working functionality for t-suspend and t_continue for SIP responses in the tmp/tm_async_reply_support branch.
I've memory and load tested the branch and have also isolated the changes so that if there are problems they will only be experienced if you use the new API functions.
However keeping mind that TM can be tricky to program (as mentioned in the documentation ;)) - I've included below a summary of the changes and a git diff against the latest master. So the TM experts can have a look and see if there are any obvious problems.
If there are no complaints or queries I will commit the changes to master next week Friday (July 12).
Regards Richard.
Change summary:
- parser/msg_parser.h: added new message state FL_RPL_SUSPENDED
- tm_load.c: new api functions: *t_suspend_reply*, *t_continue_reply*and
*t_cancel_suspend_reply* 3. t_suspend.c/h: new methods: *t_suspend_reply*, *t_continue_reply* and *t_cancel_suspend_reply *4. tm/t_reply.c: if msg is in state FL_RPL_SUSPENDED then we skip sending the reply on 5. tm/t_reply.c/h: new methods to fake env for responses: *faked_env_resp, faked_resp, free_faked_resp
- API documentation to include new functions: *t_suspend_reply*, *
t_continue_reply* and *t_cancel_suspend_reply
On 18 March 2013 14:13, Richard Good richard.good@smilecoms.com wrote:
Hi Daniel and other TM experts
We have been working on a prototype for being able to use the t_suspend() and t_continue() methods for SIP responses. The version in branch /tmp/tm_async_reply_support is working, though still needs to be 100% tested and only works for 1 branch (i.e. no forking)
Would it be possible for you to have a look at this branch code and see if we are on the right track. The code is working but TM (as mentioned in the documentation ;)) can be tricky to program and we want to make sure we are not breaking anything, as the goal is to get this into the master branch.
The changes we have done:
- parser/msg_parser.h: added new message state FL_RPL_SUSPENDED
- tm/h_table.h: added int suspended_request to ua_server and int
suspended_reply to ua_client 3. tm/t_suspend.c:t_suspend 1. Changed suspend method to check if the message is a request or response and set the suspended_request/suspended_reply variable accordingly 2. If its a request we do as the existing code 3. If its a response we get the correct uac branch, clone the msg into t->uac[branch].reply and set the msg state to FL_RPL_SUSPENDED 4. tm/t_reply.c: if msg is in state FL_RPL_SUSPENDED then we skip sending the reply on 5. tm/t_suspend.c:t_continue 1. Check if this uas was suspended - if so this is a continue for a request so continue with existing code 2. If not then we search for the branch that was suspended 3. Once branch is found unsuspend the message state 4. do pre-script, run_top_route and post scripts 5. Relay the reply using basically the same code we skipped in step 4
First next step after we confirm we are on the right track is to add forking support - this will require a new t_continue method where the calling application passes in the branch of the suspended reply when wanting to continue.
Any comments/feedback would be appreciated.
Regards
Richard.
On 11 March 2013 14:34, Daniel-Constantin Mierla miconda@gmail.comwrote:
Hello,
t_suspend() and t_continue() are only for requests at this moment.
Cheers, Daniel
On 3/6/13 2:49 PM, Richard Good wrote:
Hi
We are using the t_suspend and t_continue functionality to asynchronously send Diameter messages.
This works nicely when we suspend and resume on a SIP request. However in some circumstances we want to send a Diameter message on a SIP response.
I have found that the SIP responses continue to be relayed despite being suspended and returning 0 to the cfg file.
I am investigating the cause but before I get any deeper does anyone know if the t_suspend and t_continue functionality in the tm module can be used on a SIP response?
Regards Richard.
This email is subject to the disclaimer of Smile Communications (PTY) Ltd. at http://www.smilecoms.com/disclaimer
sr-dev mailing listsr-dev@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-- Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio World Conference, April 16-17, 2013, Berlin
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
This email is subject to the disclaimer of Smile Communications at http://www.smilecoms.com/disclaimer-- Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
This email is subject to the disclaimer of Smile Communications at http://www.smilecoms.com/disclaimer
Hello,
is still work on this patch on personal branches? I have seen Jason committing stuff, although some patched seemed to be to sip request suspend/continue.
Also, for review, would be good to have a single patch generated (diff between the branches), because is hard to follow with patches to patches.
Cheers, Daniel
On 7/8/13 12:38 PM, Richard Good wrote:
Hi
Thanks very much for the quick feedback. My comments inline.
Regards Richard.
On 6 July 2013 19:48, Daniel-Constantin Mierla <miconda@gmail.com mailto:miconda@gmail.com> wrote:
Hello, the patch cannot be applied as it is. The comments contain references to request processing, which is obviously wrong. Then I have seen code specific to requests, like managing the request uri or dst uri -- these fields shouldn't be set for replies, it's ok as safety to clear them up, but not cloning.I've gone through the code (and comments) in detail and removed all incorrect references to request code. I've also removed the dst/request URI management from the faked_resp method. Attached is the patch for these changes.
From the patch I see the new function are only for internal usage, not for config file. Are they supposed to be used only in the transaction context (i.e., after the transaction is matched for reply)?This patch closely follows the pattern of the t_suspend(), t_continue() functions that are for programmatic use only. We use the t_suspend_reply() and t_continue_reply() functions in the ims_qos module so did not need to expose it to the config file.
I suppose the suspend functionality for requests and responses could be exposed to the config file if required - but it has not been done in this patch.
Cheers, Daniel On 7/4/13 5:24 PM, Richard Good wrote:Hi I've finally got working functionality for t-suspend and t_continue for SIP responses in the tmp/tm_async_reply_support branch. I've memory and load tested the branch and have also isolated the changes so that if there are problems they will only be experienced if you use the new API functions. However keeping mind that TM can be tricky to program (as mentioned in the documentation ;)) - I've included below a summary of the changes and a git diff against the latest master. So the TM experts can have a look and see if there are any obvious problems. If there are no complaints or queries I will commit the changes to master next week Friday (July 12). Regards Richard. Change summary: 1. parser/msg_parser.h: added new message state FL_RPL_SUSPENDED 2. tm_load.c: new api functions: *t_suspend_reply*, *t_continue_reply* and *t_cancel_suspend_reply* 3. t_suspend.c/h: new methods: *t_suspend_reply*, *t_continue_reply* and *t_cancel_suspend_reply *4. tm/t_reply.c: if msg is in state FL_RPL_SUSPENDED then we skip sending the reply on 5. tm/t_reply.c/h: new methods to fake env for responses: *faked_env_resp, faked_resp, free_faked_resp * 6. API documentation to include new functions: *t_suspend_reply*, *t_continue_reply* and *t_cancel_suspend_reply * * * * * On 18 March 2013 14:13, Richard Good <richard.good@smilecoms.com <mailto:richard.good@smilecoms.com>> wrote: Hi Daniel and other TM experts We have been working on a prototype for being able to use the t_suspend() and t_continue() methods for SIP responses. The version in branch /tmp/tm_async_reply_support is working, though still needs to be 100% tested and only works for 1 branch (i.e. no forking) Would it be possible for you to have a look at this branch code and see if we are on the right track. The code is working but TM (as mentioned in the documentation ;)) can be tricky to program and we want to make sure we are not breaking anything, as the goal is to get this into the master branch. The changes we have done: 1. parser/msg_parser.h: added new message state FL_RPL_SUSPENDED 2. tm/h_table.h: added int suspended_request to ua_server and int suspended_reply to ua_client 3. tm/t_suspend.c:t_suspend 1. Changed suspend method to check if the message is a request or response and set the suspended_request/suspended_reply variable accordingly 2. If its a request we do as the existing code 3. If its a response we get the correct uac branch, clone the msg into t->uac[branch].reply and set the msg state to FL_RPL_SUSPENDED 4. tm/t_reply.c: if msg is in state FL_RPL_SUSPENDED then we skip sending the reply on 5. tm/t_suspend.c:t_continue 1. Check if this uas was suspended - if so this is a continue for a request so continue with existing code 2. If not then we search for the branch that was suspended 3. Once branch is found unsuspend the message state 4. do pre-script, run_top_route and post scripts 5. Relay the reply using basically the same code we skipped in step 4 First next step after we confirm we are on the right track is to add forking support - this will require a new t_continue method where the calling application passes in the branch of the suspended reply when wanting to continue. Any comments/feedback would be appreciated. Regards Richard. On 11 March 2013 14:34, Daniel-Constantin Mierla <miconda@gmail.com <mailto:miconda@gmail.com>> wrote: Hello, t_suspend() and t_continue() are only for requests at this moment. Cheers, Daniel On 3/6/13 2:49 PM, Richard Good wrote:Hi We are using the t_suspend and t_continue functionality to asynchronously send Diameter messages. This works nicely when we suspend and resume on a SIP request. However in some circumstances we want to send a Diameter message on a SIP response. I have found that the SIP responses continue to be relayed despite being suspended and returning 0 to the cfg file. I am investigating the cause but before I get any deeper does anyone know if the t_suspend and t_continue functionality in the tm module can be used on a SIP response? Regards Richard. This email is subject to the disclaimer of Smile Communications (PTY) Ltd. athttp://www.smilecoms.com/disclaimer _______________________________________________ sr-dev mailing list sr-dev@lists.sip-router.org <mailto:sr-dev@lists.sip-router.org> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev-- Daniel-Constantin Mierla -http://www.asipto.com http://twitter.com/#!/miconda <http://twitter.com/#%21/miconda> -http://www.linkedin.com/in/miconda Kamailio World Conference, April 16-17, 2013, Berlin -http://conference.kamailio.com - _______________________________________________ sr-dev mailing list sr-dev@lists.sip-router.org <mailto:sr-dev@lists.sip-router.org> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev This email is subject to the disclaimer of Smile Communications athttp://www.smilecoms.com/disclaimer-- Daniel-Constantin Mierla -http://www.asipto.com http://twitter.com/#!/miconda <http://twitter.com/#%21/miconda> -http://www.linkedin.com/in/micondaThis email is subject to the disclaimer of Smile Communications at http://www.smilecoms.com/disclaimer
Hi Daniel
The branch is a tmp branch and Jason has also been using it to do improvements to the general TM supend/continue functionality.
We are just in final stages and cleaning, load and memory testing. Once thats there we will provide a single patch for discussion.
Regards Richard.
On 12 July 2013 16:28, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
is still work on this patch on personal branches? I have seen Jason committing stuff, although some patched seemed to be to sip request suspend/continue.
Also, for review, would be good to have a single patch generated (diff between the branches), because is hard to follow with patches to patches.
Cheers, Daniel
On 7/8/13 12:38 PM, Richard Good wrote:
Hi
Thanks very much for the quick feedback. My comments inline.
Regards Richard.
On 6 July 2013 19:48, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
the patch cannot be applied as it is. The comments contain references to request processing, which is obviously wrong. Then I have seen code specific to requests, like managing the request uri or dst uri -- these fields shouldn't be set for replies, it's ok as safety to clear them up, but not cloning.
I've gone through the code (and comments) in detail and removed all incorrect references to request code. I've also removed the dst/request URI management from the faked_resp method. Attached is the patch for these changes.
From the patch I see the new function are only for internal usage, not for config file. Are they supposed to be used only in the transaction context (i.e., after the transaction is matched for reply)?
This patch closely follows the pattern of the t_suspend(), t_continue() functions that are for programmatic use only. We use the t_suspend_reply() and t_continue_reply() functions in the ims_qos module so did not need to expose it to the config file.
I suppose the suspend functionality for requests and responses could be exposed to the config file if required - but it has not been done in this patch.
Cheers, Daniel
On 7/4/13 5:24 PM, Richard Good wrote:
HiI've finally got working functionality for t-suspend and t_continue for SIP responses in the tmp/tm_async_reply_support branch.
I've memory and load tested the branch and have also isolated the changes so that if there are problems they will only be experienced if you use the new API functions.
However keeping mind that TM can be tricky to program (as mentioned in the documentation ;)) - I've included below a summary of the changes and a git diff against the latest master. So the TM experts can have a look and see if there are any obvious problems.
If there are no complaints or queries I will commit the changes to master next week Friday (July 12).
Regards Richard.
Change summary:
- parser/msg_parser.h: added new message state FL_RPL_SUSPENDED
- tm_load.c: new api functions: *t_suspend_reply*, *t_continue_reply*and
*t_cancel_suspend_reply* 3. t_suspend.c/h: new methods: *t_suspend_reply*, *t_continue_reply*and *t_cancel_suspend_reply *4. tm/t_reply.c: if msg is in state FL_RPL_SUSPENDED then we skip sending the reply on 5. tm/t_reply.c/h: new methods to fake env for responses: *faked_env_resp, faked_resp, free_faked_resp
- API documentation to include new functions: *t_suspend_reply*, *
t_continue_reply* and *t_cancel_suspend_reply
On 18 March 2013 14:13, Richard Good richard.good@smilecoms.com wrote:
Hi Daniel and other TM experts
We have been working on a prototype for being able to use the t_suspend() and t_continue() methods for SIP responses. The version in branch /tmp/tm_async_reply_support is working, though still needs to be 100% tested and only works for 1 branch (i.e. no forking)
Would it be possible for you to have a look at this branch code and see if we are on the right track. The code is working but TM (as mentioned in the documentation ;)) can be tricky to program and we want to make sure we are not breaking anything, as the goal is to get this into the master branch.
The changes we have done:
- parser/msg_parser.h: added new message state FL_RPL_SUSPENDED
- tm/h_table.h: added int suspended_request to ua_server and int
suspended_reply to ua_client 3. tm/t_suspend.c:t_suspend 1. Changed suspend method to check if the message is a request or response and set the suspended_request/suspended_reply variable accordingly 2. If its a request we do as the existing code 3. If its a response we get the correct uac branch, clone the msg into t->uac[branch].reply and set the msg state to FL_RPL_SUSPENDED 4. tm/t_reply.c: if msg is in state FL_RPL_SUSPENDED then we skip sending the reply on 5. tm/t_suspend.c:t_continue 1. Check if this uas was suspended - if so this is a continue for a request so continue with existing code 2. If not then we search for the branch that was suspended 3. Once branch is found unsuspend the message state 4. do pre-script, run_top_route and post scripts 5. Relay the reply using basically the same code we skipped in step 4
First next step after we confirm we are on the right track is to add forking support - this will require a new t_continue method where the calling application passes in the branch of the suspended reply when wanting to continue.
Any comments/feedback would be appreciated.
Regards
Richard.
On 11 March 2013 14:34, Daniel-Constantin Mierla miconda@gmail.comwrote:
Hello,
t_suspend() and t_continue() are only for requests at this moment.
Cheers, Daniel
On 3/6/13 2:49 PM, Richard Good wrote:
Hi
We are using the t_suspend and t_continue functionality to asynchronously send Diameter messages.
This works nicely when we suspend and resume on a SIP request. However in some circumstances we want to send a Diameter message on a SIP response.
I have found that the SIP responses continue to be relayed despite being suspended and returning 0 to the cfg file.
I am investigating the cause but before I get any deeper does anyone know if the t_suspend and t_continue functionality in the tm module can be used on a SIP response?
Regards Richard.
This email is subject to the disclaimer of Smile Communications (PTY) Ltd. at http://www.smilecoms.com/disclaimer
sr-dev mailing listsr-dev@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-- Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio World Conference, April 16-17, 2013, Berlin
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
This email is subject to the disclaimer of Smile Communications at http://www.smilecoms.com/disclaimer-- Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
This email is subject to the disclaimer of Smile Communications at http://www.smilecoms.com/disclaimer
-- Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
This email is subject to the disclaimer of Smile Communications at http://www.smilecoms.com/disclaimer
-
Daniel-Constantin Mierla -
Richard Good