8 Oct
2013
8 Oct
'13
1:14 p.m.
Hello,
I've setup two Kamailio machines, one which does all the processing and the second one
which always replies with a 500 Server Internal Error, to test my Dispatcher fail-over.
When routing a call, the call is always routed to the second Kamailio first, to test the
fail-over.
What happens in this scenario is the 500 is received by the main Kamailio and the 500
message is duplicated to the capture server. After this the failure_route kicks in and the
500 is obviously never sent back to the initiator.
The changes made to the 500 message (adding a new header), in onreply_route, aren't
present when the message is duplicated to the capture server, because the original 500
message is duplicated instead of the modified one.
I tried the following things, but none of them worked:
- Adding the header and calling sip_trace();, but this doesn't work since
sip_trace() duplicated the message prior to changes made to it.
- Msg_apply_changes(), doesn't work either, since I can't use it in
onreply_route
- Append_to_reply(), cannot be used from onreply_route
Appending new headers to replies works, but only when the reply is also sent back to the
initiator, since I have the setflag(22) set. This makes sure the processed messages are
also duplicated.
In this case the 500 is never sent back.
Anyone have an idea how to solve this?
Regards,
Grant
8 Oct
8 Oct
2:05 p.m.
Hello,
upcoming 4.1 (still master branch now, but feature freeze phase) has
msg_apply_changes() working for reply routes.
Cheers,
Daniel
On 10/8/13 12:14 PM, Grant Bagdasarian wrote:
Hello,
I've setup two Kamailio machines, one which does all the processing
and the second one which always replies with a 500 Server Internal
Error, to test my Dispatcher fail-over.
When routing a call, the call is always routed to the second Kamailio
first, to test the fail-over.
What happens in this scenario is the 500 is received by the main
Kamailio and the 500 message is duplicated to the capture server.
After this the failure_route kicks in and the 500 is obviously never
sent back to the initiator.
The changes made to the 500 message (adding a new header), in
onreply_route, aren't present when the message is duplicated to the
capture server, because the original 500 message is duplicated instead
of the modified one.
I tried the following things, but none of them worked:
-Adding the header and calling sip_trace();, but this doesn't work
since sip_trace() duplicated the message prior to changes made to it.
-Msg_apply_changes(), doesn't work either, since I can't use it in
onreply_route
-Append_to_reply(), cannot be used from onreply_route
Appending new headers to replies works, but only when the reply is
also sent back to the initiator, since I have the setflag(22) set.
This makes sure the processed messages are also duplicated.
In this case the 500 is never sent back.
Anyone have an idea how to solve this?
Regards,
Grant
_______________________________________________
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://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Trainings - Berlin, Nov 25-28; Miami, Nov 18-20, 2013
- more details about Kamailio trainings at http://www.asipto.com -
2:10 p.m.
That's some good news =).
I'll just wait for the 4.1 release then.
Thanks!
From: sr-users-bounces(a)lists.sip-router.org [mailto:sr-users-bounces@lists.sip-router.org]
On Behalf Of Daniel-Constantin Mierla
Sent: Tuesday, October 8, 2013 1:05 PM
To: Kamailio (SER) - Users Mailing List
Subject: Re: [SR-Users] Apply changes made to sip reply in onreply_route
Hello,
upcoming 4.1 (still master branch now, but feature freeze phase) has msg_apply_changes()
working for reply routes.
Cheers,
Daniel
On 10/8/13 12:14 PM, Grant Bagdasarian wrote:
Hello,
I've setup two Kamailio machines, one which does all the processing and the second one
which always replies with a 500 Server Internal Error, to test my Dispatcher fail-over.
When routing a call, the call is always routed to the second Kamailio first, to test the
fail-over.
What happens in this scenario is the 500 is received by the main Kamailio and the 500
message is duplicated to the capture server. After this the failure_route kicks in and the
500 is obviously never sent back to the initiator.
The changes made to the 500 message (adding a new header), in onreply_route, aren't
present when the message is duplicated to the capture server, because the original 500
message is duplicated instead of the modified one.
I tried the following things, but none of them worked:
- Adding the header and calling sip_trace();, but this doesn't work since
sip_trace() duplicated the message prior to changes made to it.
- Msg_apply_changes(), doesn't work either, since I can't use it in
onreply_route
- Append_to_reply(), cannot be used from onreply_route
Appending new headers to replies works, but only when the reply is also sent back to the
initiator, since I have the setflag(22) set. This makes sure the processed messages are
also duplicated.
In this case the 500 is never sent back.
Anyone have an idea how to solve this?
Regards,
Grant
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org<mailto:sr-users@lists.sip-router.org>
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Trainings - Berlin, Nov 25-28; Miami, Nov 18-20, 2013
- more details about Kamailio trainings at http://www.asipto.com -
3:50 p.m.
Am 08.10.2013 12:14, schrieb Grant Bagdasarian:
Hello,
I've setup two Kamailio machines, one which does all the processing
and the second one which always replies with a 500 Server Internal
Error, to test my Dispatcher fail-over.
When routing a call, the call is always routed to the second Kamailio
first, to test the fail-over.
What happens in this scenario is the 500 is received by the main
Kamailio and the 500 message is duplicated to the capture server.
After this the failure_route kicks in and the 500 is obviously never
sent back to the initiator.
The changes made to the 500 message (adding a new header), in
onreply_route, aren't present when the message is duplicated to the
capture server, because the original 500 message is duplicated instead
of the modified one.
Out of curiosity -why do you add a header to the response if it is
likely to be dropped (depending of the response in the second branch)?
Just to signal data to the capture server?
klaus
4:32 p.m.
It's for our logging. Each INVITE is pretty much a separate row in our logging table.
Responses and in-dialog requests on the INVITE trigger an update on the row, where the
state of the row is updated.
This allows us to see in which (custom) state each call is.
Each time the Dispatcher tries a destination, an INVITE goes out and is also captured. A
row is then created in our logging table. When the destination replies with a 500, the
state should be changed to "Failed".
When the Dispatcher tries the next destination, this should trigger a new row in the
table.
I'm using custom headers to store and pass data around, which are used by our services
to translate the SIP messages into our own format for logging.
From: sr-users-bounces(a)lists.sip-router.org [mailto:sr-users-bounces@lists.sip-router.org]
On Behalf Of Klaus Darilion
Sent: Tuesday, October 8, 2013 2:51 PM
To: sr-users(a)lists.sip-router.org
Subject: Re: [SR-Users] Apply changes made to sip reply in onreply_route
Am 08.10.2013 12:14, schrieb Grant Bagdasarian:
Hello,
I've setup two Kamailio machines, one which does all the processing and the second one
which always replies with a 500 Server Internal Error, to test my Dispatcher fail-over.
When routing a call, the call is always routed to the second Kamailio first, to test the
fail-over.
What happens in this scenario is the 500 is received by the main Kamailio and the 500
message is duplicated to the capture server. After this the failure_route kicks in and the
500 is obviously never sent back to the initiator.
The changes made to the 500 message (adding a new header), in onreply_route, aren't
present when the message is duplicated to the capture server, because the original 500
message is duplicated instead of the modified one.
Out of curiosity -why do you add a header to the response if it is likely to be dropped
(depending of the response in the second branch)? Just to signal data to the capture
server?
klaus
4067
days inactive
4067
days old
4 comments
3 participants
participants (3)
-
Daniel-Constantin Mierla -
Grant Bagdasarian -
Klaus Darilion