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 <[email protected]
<mailto:[email protected]>> 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 <[email protected]
<mailto:[email protected]>> 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
<[email protected] <mailto:[email protected]>> 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
[email protected] <mailto:[email protected]>
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
[email protected]
<mailto:[email protected]>
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/miconda
This email is subject to the disclaimer of Smile Communications at
http://www.smilecoms.com/disclaimer
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
_______________________________________________
sr-dev mailing list
[email protected]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
