18 Dec
2015
18 Dec
'15
3:55 p.m.
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
21 Dec
21 Dec
9:48 a.m.
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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Book: SIP Routing With Kamailio - http://www.asipto.com
http://miconda.eu
22 Dec
22 Dec
4:12 p.m.
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
5 Feb
5 Feb
9:16 a.m.
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
5:44 p.m.
On 05/02/16 09:16, smititelu wrote:
On 21.12.2015 10:48, Daniel-Constantin Mierla wrote:
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
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Book: SIP Routing With Kamailio - http://www.asipto.com
http://miconda.eu
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?
3005
days inactive
3054
days old
4 comments
3 participants
participants (3)
-
Andrew Pogrebennyk -
Daniel-Constantin Mierla -
smititelu