[SR-Users] Re: Too many 200:OK sip responses

[Olle E. Johansson]

> On 5 Jan 2023, at 07:06, Waqar 40  wrote:
> 
> Dear All,
> 
> For a normal call, Kamailio receives 200:OK sip response for the method 
> invite only once but for some calls, it receives 200:OK too many times around 
> 6 to 7. And I also do not receive BYE or any other packets for this kind of 
> call. How can I detect such calls in Kamailio and cancel them? I am inserting 
> data of the calls in the database when the call occurs and deleting it when 
> BYE is received but for these calls as I don't receive BYE so I am unable to 
> delete the record of such calls.
The 200 OK is retransmitted until an ACK is received. You have a routing 
problem somewhere.

> Is there a way to detect such calls? Like How can I count if the number of 
> 200:OK responses is more than one or anything like that?
The problem is not the number of 200 Ok but the missing ACK. Does the 200 OK 
reach the calling end point? Does it transmit an ACK? Is that received by 
Kamailio?

/O

__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

[SR-Users] Too many 200:OK sip responses

[Waqar 40]

Dear All,

For a normal call, Kamailio receives 200:OK sip response for the method
invite only once but for some calls, it receives 200:OK too many times
around 6 to 7. And I also do not receive BYE or any other packets for this
kind of call. How can I detect such calls in Kamailio and cancel them? I am
inserting data of the calls in the database when the call occurs and
deleting it when BYE is received but for these calls as I don't receive BYE
so I am unable to delete the record of such calls.
Is there a way to detect such calls? Like How can I count if the number of
200:OK responses is more than one or anything like that?

Regards
Vicky
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

[SR-Users] pkg memory leak when acc module cdr_enabled

[Juha Heinanen]

In latest stable K release, we noticed pkg memory leak (pgk memory usage
increases by each processed call).  It turned out that the leak goes
away if acc module cdr_enable is not enabled.

Could be a bug in dialog or acc module.  Any debug instructions if the
bug is not obvious?

-- Juha
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

[SR-Users] Re: Dispatcher Incoming

[Henning Westerholt]

Hello Alex,

I completely agree to your point regarding the product management topic.

Some of our customers are also doing upgrades from chan_sip to chan_pjsip right 
now. Let's see if they are affected, then I could have a closer look to that 
code. In case there is a fix, I will let you (and the list know), for sure.

Cheers,

Henning

-- 
Henning Westerholt - https://skalatan.de/blog/
Kamailio services - https://gilawa.com

-Original Message-
From: Alex Balashov  
Sent: Wednesday, January 4, 2023 6:27 PM
To: Kamailio (SER) - Users Mailing List 
Subject: [SR-Users] Re: Dispatcher Incoming


> On Jan 4, 2023, at 12:17 PM, Henning Westerholt  wrote:
> 
> so far, we did not have any customer that need this functionality.

I've had numerous customers who have needed the functionality, and ended up 
having to use something like the "imaginative" Contact workaround instead.

I suppose it's hard to say whether the functionality was strictly necessary or 
born of a more puristic sensibility about how to make the proxy trapezoid work. 
:-) 

However, a very common scenario for us is a customer from chan_sip to 
chan_pjsip, and having previously relied on Path support because it existed in 
chan_sip for approximately a decade. This means we had to totally rearchitect 
their systems, some of which have been very stable for about that long. 

No, it's not that I'm entitled and think open-source projects owe us something 
for free, of course. But from a product management point of view, I think this 
is quite embarrassing. It's better to never have offered Path at all than to 
implement it (with considerable fanfare at the time!), then break it via a 
mandatory and quite controversial upgrade path (chan_sip -> chan_pjsip), then 
obstinately refuse to fix it.

-- Alex

--
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web: https://evaristesys.com
Tel: +1-706-510-6800

__
Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send 
an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

[SR-Users] Re: Dispatcher Incoming

[Alex Balashov]

> On Jan 4, 2023, at 12:17 PM, Henning Westerholt  wrote:
> 
> so far, we did not have any customer that need this functionality.

I've had numerous customers who have needed the functionality, and ended up 
having to use something like the "imaginative" Contact workaround instead.

I suppose it's hard to say whether the functionality was strictly necessary or 
born of a more puristic sensibility about how to make the proxy trapezoid work. 
:-) 

However, a very common scenario for us is a customer from chan_sip to 
chan_pjsip, and having previously relied on Path support because it existed in 
chan_sip for approximately a decade. This means we had to totally rearchitect 
their systems, some of which have been very stable for about that long. 

No, it's not that I'm entitled and think open-source projects owe us something 
for free, of course. But from a product management point of view, I think this 
is quite embarrassing. It's better to never have offered Path at all than to 
implement it (with considerable fanfare at the time!), then break it via a 
mandatory and quite controversial upgrade path (chan_sip -> chan_pjsip), then 
obstinately refuse to fix it.

-- Alex

-- 
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web: https://evaristesys.com
Tel: +1-706-510-6800

__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

[SR-Users] Re: Dispatcher Incoming

[Henning Westerholt]

Hi Alex,

so far, we did not have any customer that need this functionality.

We did some work in asterisk chan_pjsip recently related to a special inter-op 
bug [1]. But it's certainly a bit more work as for Kamailio, especially if you 
are not doing it that often and are not familiar with the processes.

Cheers,

Henning

[1] https://issues.asterisk.org/jira/browse/ASTERISK-30193

-- 
Henning Westerholt - https://skalatan.de/blog/
Kamailio services - https://gilawa.com

-Original Message-
From: Alex Balashov  
Sent: Wednesday, January 4, 2023 5:44 PM
To: Kamailio (SER) - Users Mailing List 
Subject: [SR-Users] Re: Dispatcher Incoming


> On Jan 4, 2023, at 8:25 AM, Henning Westerholt  wrote:
> 
>  it seems that this bug apparently does not harm to many people, or the 
> workaround with the outbound proxy works for most of them.

I've been complaining about it constantly, but lack the PJSIP depth to provide 
a robust fix. 

I think it's quite unfortunate because it's functionality that used to exist in 
chan_sip, when it was finally added in Asterisk 12. Systems were built with 
that assumption in mind. chan_pjsip isn't supposed to be a step backwards... 

-- Alex

--
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web: https://evaristesys.com
Tel: +1-706-510-6800

__
Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send 
an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

[SR-Users] Re: Dispatcher Incoming

[Alex Balashov]

> On Jan 4, 2023, at 8:25 AM, Henning Westerholt  wrote:
> 
>  it seems that this bug apparently does not harm to many people, or the 
> workaround with the outbound proxy works for most of them.

I've been complaining about it constantly, but lack the PJSIP depth to provide 
a robust fix. 

I think it's quite unfortunate because it's functionality that used to exist in 
chan_sip, when it was finally added in Asterisk 12. Systems were built with 
that assumption in mind. chan_pjsip isn't supposed to be a step backwards... 

-- Alex

-- 
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web: https://evaristesys.com
Tel: +1-706-510-6800

__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

[SR-Users] Re: Call drop when reinvite is proceed

[Henning Westerholt]

Hello,

as mentioned, analyse the sip traces, the re-INVITE in particular regarding 
Route header etc..

Cheers,

Henning

-- 
Henning Westerholt - https://skalatan.de/blog/
Kamailio services - https://gilawa.com

-Original Message-
From: nathan.casti...@snapcom.fr  
Sent: Wednesday, January 4, 2023 2:28 PM
To: sr-users@lists.kamailio.org
Subject: [SR-Users] Call drop when reinvite is proceed

Hello all,

I'm trying to figure out one problem on my Kamailio server.

When kamailio receive a reinvite from the infra, I get the error message "477 - 
Unforunately error on sending to next hop" and the call drop. 
I don't understand why this message appears as the first invite is well 
answered and the call is going well.

Any ideas how to resolve this issue ?

Thanks in advance for your help.
Regards,
Nathan
__
Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send 
an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

[SR-Users] Re: Call drop when reinvite is proceed

[Olle E. Johansson]

> On 4 Jan 2023, at 14:28, nathan.casti...@snapcom.fr wrote:
> 
> Hello all,
> 
> I'm trying to figure out one problem on my Kamailio server.
> 
> When kamailio receive a reinvite from the infra, I get the error message "477 
> - Unforunately error on sending to next hop" and the call drop. 
> I don't understand why this message appears as the first invite is well 
> answered and the call is going well.
The first invite and a reinvite is routed different ways. The re-invite is in 
dialog and thus follows the record route and the contact address.

> 
> Any ideas how to resolve this issue ?
Read the headers and figure it out :-)

Cheers,
/O

__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

[SR-Users] Call drop when reinvite is proceed

[nathan . castillo]

Hello all,

I'm trying to figure out one problem on my Kamailio server.

When kamailio receive a reinvite from the infra, I get the error message "477 - 
Unforunately error on sending to next hop" and the call drop. 
I don't understand why this message appears as the first invite is well 
answered and the call is going well.

Any ideas how to resolve this issue ?

Thanks in advance for your help.
Regards,
Nathan
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

[SR-Users] Re: Dispatcher Incoming

[Henning Westerholt]

Hello,

it seems that this bug apparently does not harm to many people, or the 
workaround with the outbound proxy works for most of them.

Nobody from the open source community or other companies did it picked up as 
well in the last years.

Cheers,

Henning

--
Henning Westerholt – https://skalatan.de/blog/
Kamailio services – https://gilawa.com

From: nutxase 
Sent: Wednesday, January 4, 2023 11:54 AM
To: sr-users@lists.kamailio.org
Subject: [SR-Users] Re: Dispatcher Incoming

Thanks for the workaround Alex

I do find it pathetic on digiums part that they still havent done anything 
about it.

Cheers

Sent with Proton Mail secure email.

--- Original Message ---
On Tuesday, January 3rd, 2023 at 5:26 PM, nutxase 
mailto:nutx...@proton.me>> wrote:


Hi All

I have setup kamailio using dispatcher to proxy registrations from the UAC to 
asterisk
but when asterisk sends an incoming call it does not seem to keep the path 
header and therefore kamailio sends 404
is there anyway around this?

Thanks

Sent with Proton Mail secure email.

__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

[SR-Users] Re: How to have Kamailio retry backends

[Henning Westerholt]

Hello,

you can use different methods, a common way is to use the htable module fort 
that.
If you are fine with a dialog-stateful proxy, you can also just use the dialog 
module for that – for a counter per dialog.

Cheers,

Henning

--
Henning Westerholt – https://skalatan.de/blog/
Kamailio services – https://gilawa.com

From: Unai Rodriguez 
Sent: Wednesday, December 21, 2022 12:42 PM
To: Kamailio (SER) - Users Mailing List ; Henning 
Westerholt 
Subject: RE: [SR-Users] How to have Kamailio retry backends

I’d like to implement a counter per INVITE. Do I need to use the counters 
(https://www.kamailio.org/docs/modules/devel/modules/counters.html) module or 
statistics (https://kamailio.org/docs/modules/devel/modules/statistics.html) 
module or could someone provide any pointers? Thank you so much

With best wishes,
Unai Rodriguez
On 13 Dec 2022, 18:28 +0100, Henning Westerholt 
mailto:h...@gilawa.com>>, wrote:

Hello,

regarding limiting the number of gateways retries, you can use different 
failure routes (e.g. jump from first to second and then stop), you can keep an 
counter, or probably just rely on ds_next_dst() reaching the end of available 
gateways in the XAVP (did not checked code).

Cheers,

Henning

--
Henning Westerholt – https://skalatan.de/blog/
Kamailio services – https://gilawa.com

From: Unai Rodriguez mailto:u...@rodr.org>>
Sent: Tuesday, December 13, 2022 5:32 PM
To: Kamailio (SER) - Users Mailing List 
mailto:sr-users@lists.kamailio.org>>; Henning 
Westerholt mailto:h...@gilawa.com>>
Subject: RE: [SR-Users] How to have Kamailio retry backends

Hi Henning/All,

After some digging we realized the system was already retrying thanks to this 
block on kamailio.cfg

# Try next destionations in failure route
failure_route[RTF_DISPATCH] {
if (t_is_canceled()) {
exit;
}
# next DST - only for 500 or local timeout
if (t_check_status("500")
or (t_branch_timeout() and !t_branch_replied())) {
if(ds_next_dst()) {
t_on_failure("RTF_DISPATCH");
route(RELAY);
exit;
}
}
}

How can we control the maximum number of retries? Seems to be infinite at the 
moment? Or !t_branch_replied()means that each backend can only reply once?

Thanks you

With best wishes,
Unai Rodriguez
On 6 Dec 2022, 10:04 +0100, Henning Westerholt 
mailto:h...@gilawa.com>>, wrote:
Hello,

you can implement this by using a failure_route. There is one example in the 
dispatcher module configuration how to do it.

Cheers,

Henning

--
Henning Westerholt – https://skalatan.de/blog/
Kamailio services – https://gilawa.com

From: sr-users 
mailto:sr-users-boun...@lists.kamailio.org>>
 On Behalf Of Unai Rodriguez
Sent: Saturday, December 3, 2022 5:16 PM
To: sr-users@lists.kamailio.org
Subject: [SR-Users] How to have Kamailio retry backends

Dear List,

We’re using Kamailio to load balance MRCP requests to multiple backend groups 
with a configuration as follows:

# kamailio.cfg
...
...
route[DISPATCH] {
if($ua=="mrcp_backend_1") {
if(!ds_select_dst("1", "4")) {
   send_reply("404", "No 
destination");
   exit;
}
}
if($ua=="mrcp_backend_2") {
if(!ds_select_dst("2", "4")) {
   send_reply("404", "No 
destination");
   exit;
}
}
xlog("L_DBG", "--- SCRIPT: going to <$ru> via <$du>\n");
t_on_failure("RTF_DISPATCH");
route(RELAY);
exit;
}
...
...

# dispatcher.list
1 sip:mrcp01.server.int:8060;transport=tcp
1 sip:mrcp02.server.int:8060;transport=tcp

2 sip:mrcp03.server.int:8060;transport=tcp
2 sip:mrcp04.server.int:8060;transport=tcp

With this configuration, Kamailio load balances the initial SIP INVITE among 
the MRCP servers. After the INVITE, the service communicates directly to the 
MRCP servers via SIP (for hanging up the call), MRCPv2 (for sending speech 
control messages), and RTP (for sending audio).

We would like to implement a configurable number of retries, so that if a 
particular backend times out, Kamailio would retry X times to other backend(s). 
In short, something equivalent to HAProxy’s 
retries,
 but for Kamailio. This probably implies having Kamailio always as part of our 
communication (not just load balancing the initial SIP INVITE).

I haven’t been able to find much information about this, could someone provide 
some pointers?

Thank you so much

With best wishes,
Unai Rodriguez
__

[SR-Users] Re: Dispatcher Incoming

[nutxase]

Thanks for the workaround Alex

I do find it pathetic on digiums part that they still havent done anything 
about it.

Cheers

Sent with [Proton Mail](https://proton.me/) secure email.

--- Original Message ---
On Tuesday, January 3rd, 2023 at 5:26 PM, nutxase  wrote:

> Hi All
>
> I have setup kamailio using dispatcher to proxy registrations from the UAC to 
> asterisk
> but when asterisk sends an incoming call it does not seem to keep the path 
> header and therefore kamailio sends 404
> is there anyway around this?
>
> Thanks
>
> Sent with [Proton Mail](https://proton.me/) secure email.__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

[SR-Users] Re: Recover call in ringing state

[Devang Dhandhalya]

Hello Henning

Thanks for Response, When Remote Server goes down in Ringing Call state we
will not get any Negative Response from remote server and we should not
wait for transaction timeout because its to 1-2 min
so in this case there is anything that we found Remote server is down and
we can check INVITE transaction failover and we generate INVITE using that
same transaction.
Using the Dispatcher event route we will get if any of the remote servers
are down but how we can get a call transaction is failed and can generate a
call.


Regards
Devang Dhandhalya

On Tue, Dec 6, 2022 at 3:12 PM Henning Westerholt  wrote:

> Hello,
>
>
>
> you can do this by using a failure_route. There is one example for
> voicemail I think in the Kamailio default configuration.
>
>
>
> Cheers,
>
>
>
> Henning
>
>
>
> --
>
> Henning Westerholt – https://skalatan.de/blog/
>
> Kamailio services – https://gilawa.com
>
>
>
> *From:* sr-users  *On Behalf Of *Devang
> Dhandhalya
> *Sent:* Wednesday, November 30, 2022 7:16 PM
> *To:* Kamailio (SER) - Users Mailing List 
> *Subject:* [SR-Users] Recover call in ringing state
>
>
>
> Hello All
>
>
>
> I have below setup :
>
> SBC -> kamailio -> Media server(remote) -> web-client
>
>
>
> Call comes from sbc to kamilio and it relays to Remote server to end user,
> In Ringing state if remote server goes down then in kamailio there is any
> way to Recover that ringing call like we can generate new invite for other
> Remote server which is active state, for relaying call i am using
> dispatcher module..
>
>
> I tried with tm.cancel RPC command but it works only if the remote server
> is running , when I crash the remote server at that time tm.cancel is not
> generating cancel to remote server.
>
>
> Please suggest if there is any other way to generate INVITE.
>
> Regards
> Devang Dhandhalya
>
>
>
> 
>
> *Disclaimer*
>
> In addition to generic Disclaimer which you have agreed on our website,
> any views or opinions presented in this email are solely those of the
> originator and do not necessarily represent those of the Company or its
> sister concerns. Any liability (in negligence, contract or otherwise)
> arising from any third party taking any action, or refraining from taking
> any action on the basis of any of the information contained in this email
> is hereby excluded.
>
>
>
> *Confidentiality*
>
> This communication (including any attachment/s) is intended only for the
> use of the addressee(s) and contains information that is PRIVILEGED AND
> CONFIDENTIAL. Unauthorized reading, dissemination, distribution, or copying
> of this communication is prohibited. Please inform originator if you have
> received it in error.
>
>
>
> *Caution for viruses, malware etc.*
>
> This communication, including any attachments, may not be free of viruses,
> trojans, similar or new contaminants/malware, interceptions or
> interference, and may not be compatible with your systems. You shall carry
> out virus/malware scanning on your own before opening any attachment to
> this e-mail. The sender of this e-mail and Company including its sister
> concerns shall not be liable for any damage that may incur to you as a
> result of viruses, incompleteness of this message, a delay in receipt of
> this message or any other computer problems.
>


-- 
Regards,
*Devang Dhandhalya*

[image: Ecosmob Technologies Pvt. Ltd.] 

Ecosmob Technologies Pvt. Ltd.
https://www.ecosmob.com

VoIP | Web | Mobile | IoT | Big Data

-- 
* 
*
*Disclaimer*

In addition to generic 
Disclaimer which you have agreed on our website, any views or opinions 
presented in this email are solely those of the originator and do not 
necessarily represent those of the Company or its sister concerns. Any 
liability (in negligence, contract or otherwise) arising from any third 
party taking any action, or refraining from taking any action on the basis 
of any of the information contained in this email is hereby excluded.



*Confidentiality*
This communication (including any attachment/s) is 
intended only for the use of the addressee(s) and contains information that 
is PRIVILEGED AND CONFIDENTIAL. Unauthorized reading, dissemination, 
distribution, or copying of this communication is prohibited. Please inform 
originator if you have received it in error.


*Caution for viruses, 
malware etc.*
This communication, including any attachments, may not be 
free of viruses, trojans, similar or new contaminants/malware, 
interceptions or interference, and may not be compatible with your systems. 
You shall carry out virus/malware scanning on your own before opening any 
attachment to this e-mail. The sender of this e-mail and Company including 
its sister concerns shall not be liable for any damage that may incur to 
you as a result of viruses, incompleteness of this message, a delay in 
receipt of this message or any other computer problems. 

[SR-Users] Re: Recover call in ringing state

[Henning Westerholt]

Hello,

you can tune the transaction timeouts with tm configuration values and also tm 
functions to your needs. But I agree that at a server failure in ringing state 
it takes usually longer to go to the failure_route.

For that reasons you use dispatcher probing, it will detect the failure and 
then route the next calls to a working server. The calls in ringing state will 
of course not handled by that and probably fail.

Cheers,

Henning

--
Henning Westerholt – https://skalatan.de/blog/
Kamailio services – https://gilawa.com

From: Devang Dhandhalya 
Sent: Wednesday, January 4, 2023 10:07 AM
To: Henning Westerholt 
Cc: Kamailio (SER) - Users Mailing List 
Subject: Re: [SR-Users] Recover call in ringing state

Hello Henning

Thanks for Response, When Remote Server goes down in Ringing Call state we will 
not get any Negative Response from remote server and we should not  wait for 
transaction timeout because its to 1-2 min
so in this case there is anything that we found Remote server is down and we 
can check INVITE transaction failover and we generate INVITE using that same 
transaction.
Using the Dispatcher event route we will get if any of the remote servers are 
down but how we can get a call transaction is failed and can generate a call.


Regards
Devang Dhandhalya

On Tue, Dec 6, 2022 at 3:12 PM Henning Westerholt 
mailto:h...@gilawa.com>> wrote:
Hello,

you can do this by using a failure_route. There is one example for voicemail I 
think in the Kamailio default configuration.

Cheers,

Henning

--
Henning Westerholt – https://skalatan.de/blog/
Kamailio services – https://gilawa.com

From: sr-users 
mailto:sr-users-boun...@lists.kamailio.org>>
 On Behalf Of Devang Dhandhalya
Sent: Wednesday, November 30, 2022 7:16 PM
To: Kamailio (SER) - Users Mailing List 
mailto:sr-users@lists.kamailio.org>>
Subject: [SR-Users] Recover call in ringing state

Hello All

I have below setup :
SBC -> kamailio -> Media server(remote) -> web-client

Call comes from sbc to kamilio and it relays to Remote server to end user, In 
Ringing state if remote server goes down then in kamailio there is any way to 
Recover that ringing call like we can generate new invite for other Remote 
server which is active state, for relaying call i am using dispatcher module..

I tried with tm.cancel RPC command but it works only if the remote server is 
running , when I crash the remote server at that time tm.cancel is not 
generating cancel to remote server.

Please suggest if there is any other way to generate INVITE.

Regards
Devang Dhandhalya

[Das Bild wurde vom Absender entfernt.]
Disclaimer
In addition to generic Disclaimer which you have agreed on our website, any 
views or opinions presented in this email are solely those of the originator 
and do not necessarily represent those of the Company or its sister concerns. 
Any liability (in negligence, contract or otherwise) arising from any third 
party taking any action, or refraining from taking any action on the basis of 
any of the information contained in this email is hereby excluded.

Confidentiality
This communication (including any attachment/s) is intended only for the use of 
the addressee(s) and contains information that is PRIVILEGED AND CONFIDENTIAL. 
Unauthorized reading, dissemination, distribution, or copying of this 
communication is prohibited. Please inform originator if you have received it 
in error.

Caution for viruses, malware etc.
This communication, including any attachments, may not be free of viruses, 
trojans, similar or new contaminants/malware, interceptions or interference, 
and may not be compatible with your systems. You shall carry out virus/malware 
scanning on your own before opening any attachment to this e-mail. The sender 
of this e-mail and Company including its sister concerns shall not be liable 
for any damage that may incur to you as a result of viruses, incompleteness of 
this message, a delay in receipt of this message or any other computer problems.


--
Regards,
Devang Dhandhalya

[Das Bild wurde vom Absender entfernt. Ecosmob Technologies Pvt. 
Ltd.]

Ecosmob Technologies Pvt. Ltd.
https://www.ecosmob.com

VoIP | Web | Mobile | IoT | Big Data

[cid:~WRD1504.jpg]
Disclaimer
In addition to generic Disclaimer which you have agreed on our website, any 
views or opinions presented in this email are solely those of the originator 
and do not necessarily represent those of the Company or its sister concerns. 
Any liability (in negligence, contract or otherwise) arising from any third 
party taking any action, or refraining from taking any action on the basis of 
any of the information contained in this email is hereby excluded.

Confidentiality
This communication (including any attachment/s) is intended only for the use of 
the addressee(s) and contains information that is PRIVILEGED AND