[SR-Users] How to reduce re-INVITE time in Kamailio

Anuran Barman anuranbarman at gmail.com
Wed Dec 18 07:30:16 CET 2019


@Henning Westerholt
So I loaded the sst.so module and setup the params it said to set like
below:




*modparam("dialog", "timeout_avp", "$avp(i:10)")# Set the sst modules
timeout_avp to be the same valuemodparam("sst", "timeout_avp",
"$avp(i:10)")modparam("sst", "min_se", 10)*

and also set the flag in INVITE method in *request_route* {}





*        # account only INVITEs        if (is_method("INVITE")) {
      setflag(FLT_ACC); # do accounting                setflag(5);        }*

and also set the  *t_set_retr* in *route*{}









*route {        dlg_manage();        t_set_retr(10, 0);        if
(is_method("BYE")) {                $var(elapsed) = ( $Ts - $dlg(start_ts)
);                xlog ("L_INFO", "Completed $dlg(from_uri) to $dlg(to_uri)
-                $var(elapsed) duration");        }}*

but still I am getting the INVITE after  57-59 seconds later. How do I do
this?

On Wed, Dec 18, 2019 at 9:40 AM Anuran Barman <anuranbarman at gmail.com>
wrote:

> Thank you all for the detailed information. Let me try both changing the
> transmission time and also suspending the invite transaction. That NAT port
> close did not hit my mind. Thanks for putting light on that.
>
> On Wed, 18 Dec 2019 at 9:35 AM, Patrick Wakano <pwakano at gmail.com> wrote:
>
>> As I understood Anuran is after the SIP retransmission timer.
>> From the description, I think the first INVITE, which I assume triggers
>> the pushkit voip to IOS stuff, is missed, then (with default timer T1)
>> after 500ms the first retransmission is done, then after another 500ms you
>> get the 2nd, then after 1s the 3rd, after 2s the 4th, after 4s the 5th,
>> after 8s the 6th and finally after 16s the 7th. This is probably why if you
>> wait 10/15s it works, because probably the 5th or 6th retransmission hits
>> your client. If you wait just 5s you can fall under one window without
>> retransmission (if you miss the 5th you have to wait 8s for the next
>> retransmission).
>> You can change the timer T1 in the TM module and hope the retransmissions
>> do the job for you. It might work but doesn't look safe to me. I have no
>> idea how this pushkit voip event works, but you may have problems of NAT
>> ports being closed due to lack of SIP activity, then the INVITE will never
>> reach your destination anyway.
>> The way to go seems what David has suggested about suspending the Invite
>> transaction while your client start-up and register, but I don't know
>> details about this....
>>
>> Cheers,
>> Patrick Wakano
>>
>>
>>
>> On Wed, 18 Dec 2019 at 07:34, Henning Westerholt <hw at skalatan.de> wrote:
>>
>>> As mentioned, it is more a User agent related topic. But there is a
>>> module that provide related functions in Kamailio:
>>>
>>> https://kamailio.org/docs/modules/stable/modules/sst.html
>>>
>>> Cheers,
>>>
>>> Henning
>>>
>>>
>>> Am 17.12.19 um 19:51 schrieb Anuran Barman:
>>>
>>> Thanks for the reply. Sharing doc links of Session timer settings
>>> related to Kamailio specifically will be greatly appreciated.
>>>
>>> On Wed, 18 Dec 2019 at 12:18 AM, Yuriy Gorlichenko <ovoshlook at gmail.com>
>>> wrote:
>>>
>>>> Session-Expires header ( Just remembered right name) will help you
>>>> See rfc 4028
>>>> https://tools.ietf.org/html/rfc4028#page-6
>>>>
>>>> On Tue, 17 Dec 2019, 19:44 Yuriy Gorlichenko, <ovoshlook at gmail.com>
>>>> wrote:
>>>>
>>>>> Hi. It is no a kamailio question but sip question itself. You can
>>>>> manage how often te invite will be by using session-timers. It will help
>>>>> you to setup time range between reInvite ir whatever message you will use
>>>>> as keepalive
>>>>>
>>>>> On Tue, 17 Dec 2019, 19:34 Anuran Barman, <anuranbarman at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hi, I am using Kamailio for my SIP Phone app. My main SIP client is
>>>>>> the iOS app. Till now everything is working fine regarding the calling. But
>>>>>> the problem is when the app is killed I am not able to pick up incoming
>>>>>> call. The thing is, when app is killed I am sending PushKit VOIP message to
>>>>>> my ios app to wake it up. App is waking up. But by the time app is waking
>>>>>> up, the original INVITE message got missed up. So according to SIP protocol
>>>>>> it will re-INVITE after some time. Currently if I keep my app open for
>>>>>> 10-15 secs after it wakes up, I am able to get the re-INVITE and everything
>>>>>> works fine just as it was supposed to. But waiting 10-15 sec on the app is
>>>>>> not practical in any sense.
>>>>>>
>>>>>> So my question is there any way I can reduce the re-INVITE time to
>>>>>> like 5/6 seconds so that as soon as the app open it will wait for 5/6
>>>>>> seconds (practical upto some extent) and it will get the call ? Or what
>>>>>> kamailio is using as the interval time is a SIP standard and can not be
>>>>>> changed? If possible to do so, how can I do that? Please help.
>>>>>> _______________________________________________
>>>>>> Kamailio (SER) - Users Mailing List
>>>>>> sr-users at lists.kamailio.org
>>>>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>>>>
>>>>> _______________________________________________
>>>> Kamailio (SER) - Users Mailing List
>>>> sr-users at lists.kamailio.org
>>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>>
>>>
>>> _______________________________________________
>>> Kamailio (SER) - Users Mailing Listsr-users at lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>
>>> --
>>> Kamailio Merchandising - https://skalatan.de/merchandising/
>>> Kamailio services - https://skalatan.de/services
>>> Henning Westerholt - https://skalatan.de/blog/
>>>
>>> _______________________________________________
>>> Kamailio (SER) - Users Mailing List
>>> sr-users at lists.kamailio.org
>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20191218/49f5180f/attachment.html>


More information about the sr-users mailing list