Hello,
I don't understand why msg_apply changes() can be called from REQUEST_ROUTE *only*. Can someone explain? Can this be extended to *FAILURE_ROUTES *also?
Basically I need to call this from FAILURE_ROUTES in order to avoid double SDP for rtpengine offers. Searching in the mailing list I could see that there could be other means of handling this like keeping and reading the SDP from an avp(write/read_sdp_pv), but I find the above method pretty straightforward.
Thanks, Stefan
Hello,
in failure route the sip message is cloned in shared memory, with many references to shared memory buffer, as well as shorter size (just to fit the sip message) of the buffer storing the message (the core used a private memory buffer to max capacity configured for message size).
Changing these shared memory references and buffers will be a lot of operations.
If you intend to work on it, then make it configurable and in first phase a compile time option with #define/#ifdef macros. Such change will have a lot of effects, so it is better to have an easy way to switch on/off.
Cheers, Daniel
On 18/12/15 15:55, smititelu wrote:
Hello,
I don't understand why msg_apply changes() can be called from REQUEST_ROUTE *only*. Can someone explain? Can this be extended to *FAILURE_ROUTES *also?
Basically I need to call this from FAILURE_ROUTES in order to avoid double SDP for rtpengine offers. Searching in the mailing list I could see that there could be other means of handling this like keeping and reading the SDP from an avp(write/read_sdp_pv), but I find the above method pretty straightforward.
Thanks, Stefan
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
On 21.12.2015 10:48, Daniel-Constantin Mierla wrote:
Hello,
in failure route the sip message is cloned in shared memory, with many references to shared memory buffer, as well as shorter size (just to fit the sip message) of the buffer storing the message (the core used a private memory buffer to max capacity configured for message size).
I'm not sure where to I start working on this. Can you give some tips on the places/functions to look on and try to extend for failure routes?
Regards, Stefan
On 05/02/16 09:16, smititelu wrote:
On 21.12.2015 10:48, Daniel-Constantin Mierla wrote:
Hello,
in failure route the sip message is cloned in shared memory, with many references to shared memory buffer, as well as shorter size (just to fit the sip message) of the buffer storing the message (the core used a private memory buffer to max capacity configured for message size).
I'm not sure where to I start working on this. Can you give some tips on the places/functions to look on and try to extend for failure routes?
First to look at is how the transaction structure is created -- see t_newtran() as a starting point. Updating the content of the sip request requires to do changes in the 'uas' structure of the transaction.
It may simplify by allocating more than the message buffer for the clone in shared memory for transaction and then be sure that updated request doesn't exceed the allocated buffer. Still, some other fields need to be updated as well, as they point to the values inside the previous sip message content.
Cheers, Daniel
Hi, I have a similar issue with kamailio 4.3.4. I want to append a header to external 486 or 603 reply. If I got it right I should call append_hf, not append_to_reply which is for locally generated replies.
I've added append_hf() and in the end of failure route call exit but for some reason that header does not appear on the wire. So I have added msg_apply_changes() in failure route to see if it changes something for me. 1st surprise is that kamailio actually started with this config. 2nd surprise is that is still doesn't work and throws an error which I didn't see before:
Dec 22 16:01:34 sp1 (local7.info) proxy[23957]: INFO: <script>: >>>>>>>> append reply_sock='udp:10.15.20.143:5060' in REPLY_ROUTE_NAT - ID=O4Oh8J6hm5ESJag-hlhXQIcBf6HSuZ2g UA='<null>' Dec 22 16:01:34 sp1 (local7.err) proxy[23957]: ERROR: tm [t_reply.c:289]: update_totag_set(): ERROR: update_totag_set: to not parsed
Is that an expected behavior or why can't I append any header in failure route?
Regards, Andrew
On 12/18/2015 03:55 PM, smititelu wrote:
Hello,
I don't understand why msg_apply changes() can be called from REQUEST_ROUTE *only*. Can someone explain? Can this be extended to *FAILURE_ROUTES *also?
Basically I need to call this from FAILURE_ROUTES in order to avoid double SDP for rtpengine offers. Searching in the mailing list I could see that there could be other means of handling this like keeping and reading the SDP from an avp(write/read_sdp_pv), but I find the above method pretty straightforward.
Thanks, Stefan
-
Andrew Pogrebennyk -
Daniel-Constantin Mierla -
smititelu