[OpenSIPS-Users] ACK Timer

Bogdan-Andrei Iancu bogdan at opensips.org
Thu Mar 14 17:58:43 CET 2013


Hi Khaled,

your mistake here is to set the timeout for INVITE under the has_totag() 
branch - initial INVITEs do not have TO tags.

Try:


if (has_totag()) {
              if (is_method("ACK")) {
                      $avp(timeout2) = 3540;
               }
               ..... (loose_route)

} else {

     if ( is_method("INVITE")) {
         $avp(timeout2) = 3;
     }

     .......

}



Regards,
Bogdan


Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com


On 03/11/2013 01:09 PM, M.Khaled W Chehab wrote:
>
> Dear Nicolas,
>
> I am using opensips 1.8.2 tls version ,the problem still exist while 
> even while I am using  the timer ,please update me if you have a 
> solution .
>
> if (has_totag()) {
>
>               if ( is_method("INVITE")) {
>
>                      $avp(timeout2) = 3;
>
>               } else if (is_method("ACK")) {
>
>                      $avp(timeout2) = 3540;
>
>               }
>
> Regards
>
> Khaled chehab
>
> *From:*Brito Nicolas [mailto:nicolas.brito at andrexen.com]
> *Sent:* Tuesday, February 12, 2013 4:52 PM
> *Cc:* M.Khaled W Chehab
> *Subject:* Re: [OpenSIPS-Users] ACK Timer
>
> Hi Khaled,
>
> What you posted at first seems good so far the dialog will be dropped 
> after 3 second which is not bad.
> The only other possibility is to actually make a detection in OpenSIPS 
> for CANCEL emition instead of ACK.
> If you are using FreeSWITCH i offer to send you a patch that solve 
> this behaviour.
>
> Regards
>
> Nicolas
>
> Le 12/02/2013 15:02, Muhammad Shahzad a écrit :
>
>     Ah, again typo, in last line of previous email, i meant to recover
>     loss of few seconds between 200 OK and CANCEL from caller, (not
>     ACK from caller, since ACK establishes a billable call).
>
>     Thank you.
>
>     On Tue, Feb 12, 2013 at 2:54 PM, Muhammad Shahzad
>     <shaheryarkh at gmail.com <mailto:shaheryarkh at gmail.com>> wrote:
>
>     Sorry i didn't see you are setting dialog timeout
>     for sequential INVITE, instead of initial INVITE, so this timeout
>     would actually have no effect on new call, it will effect only
>     established call (e.g. when caller or callee sets call on hold
>     etc.) and when that sequential INVITE comes in the destination has
>     to accept it within 3 seconds, which is OK, since call is already
>     established, only its state being changed.
>
>     Secondly, a call is not considered established till ACK arrives
>     from caller party. Since caller never sends ACK, so destination
>     should end call (after 32 seconds per RFC 3261) even if it does
>     not receives CANCEL from caller. And if destination receives
>     CANCEL, then call should end anyway. Such call can not be billed,
>     since it was never established.
>
>     From billing the caller prospective, you should start billing upon
>     receiving 200 OK from destination but you must discard it if
>     CANCEL comes from caller instead of ACK. In fact i have seen some
>     billing systems that actually start billing upon receiving ACK
>     from caller, rather 200 OK from destination. To overcome the loss
>     of few seconds (between 200 OK from destination and ACK from
>     caller), they use a different billing head called "connection
>     charges".
>
>     Thank you.
>
>     On Tue, Feb 12, 2013 at 2:24 PM, M.Khaled W Chehab
>     <kchehab at icucall.com <mailto:kchehab at icucall.com>> wrote:
>
>     Please can you show me by code  the better way(ensure Cancel)
>      since this is a critical issue and I am relaying the cancel and
>     after that trunk  send me more than 8 time 200 Ok  ,as is there a
>     way to stop/hangup the call since I receive the cancel from the
>     client
>
>     2-what do you mean destination must be very quick ( since 200 oK
>     is received  the normal reply (ACK) takes  millsec or I am wrong ?
>
>     Regards
>
>     *From:*Muhammad Shahzad [mailto:shaheryarkh at gmail.com
>     <mailto:shaheryarkh at gmail.com>]
>     *Sent:* Tuesday, February 12, 2013 3:05 PM
>     *To:* M.Khaled W Chehab
>     *Cc:* users at lists.opensips.org <mailto:users at lists.opensips.org>;
>     bogdan at opensips.org <mailto:bogdan at opensips.org>;
>     users-bounces at lists.opensips.org
>     <mailto:users-bounces at lists.opensips.org>; Muhammad Shahzad
>     *Subject:* Re: ACK Timer
>
>     This may work, only if you create dialog with 'B' flag, also 3
>     seconds look very short, destination must be very quick to ACK the
>     call.
>
>     I think there is a better way to achieve this, you only need to
>     ensure CANCEL is received at destination.
>
>
>     Thank you.
>
>     On Tue, Feb 12, 2013 at 1:45 PM, M.Khaled W Chehab
>     <kchehab at icucall.com <mailto:kchehab at icucall.com>> wrote:
>
>     Hi ,
>
>     I face a lot of scenarios where the customer send a cancel while
>     the  trunk send 200 OK and start the billing from its side ,so the
>     client call will be canceled from his side and goes to the max
>     call duration from my side and trunk side .
>
>     Si I draw this function below
>
>     loadmodule "dialog.so"
>
>     modparam("dialog", "timeout_avp", "$avp(timeout2)")
>
>     if (has_totag()) {
>
>                   if ( is_method("INVITE")) {
>
>                          $avp(timeout2) = 3;
>
>                   } else if (is_method("ACK")) {
>
>                          $avp(timeout2) = 3540;
>
>                   }
>
>     Do this function effect on my calls or cause  any problem
>
>     Regards
>
>     Khaled Chehab
>
>     Senior NGN Engineer
>
>     Description: icucall
>
>     Operations Office - Lebanon
>
>     Office    : +961 1 515155 ext 300
>
>     Mobile  : +961 3 045212
>
>     E-mail    : kchehab at icucall.com <mailto:kchehab at icucall.com>
>
>     MSN ID :khalidchehab at hotmail.com <mailto:khalidchehab at hotmail.com>
>
>     Skype    : k_chehab
>
>     Web Site: http://www.icucall.com
>
>     http://www.allohi.com
>
>
>
>     -- 
>     Muhammad Shahzad
>     -----------------------------------
>     CISCO Rich Media Communication Specialist (CRMCS)
>     CISCO Certified Network Associate (CCNA)
>     Cell: +49 176 99 83 10 85
>     MSN: shari_786pk at hotmail.com <mailto:shari_786pk at hotmail.com>
>     Email: shaheryarkh at googlemail.com <mailto:shaheryarkh at googlemail.com>
>
>
>
>     -- 
>     Muhammad Shahzad
>     -----------------------------------
>     CISCO Rich Media Communication Specialist (CRMCS)
>     CISCO Certified Network Associate (CCNA)
>     Cell: +49 176 99 83 10 85
>     MSN: shari_786pk at hotmail.com <mailto:shari_786pk at hotmail.com>
>     Email: shaheryarkh at googlemail.com <mailto:shaheryarkh at googlemail.com>
>
>
>
>     -- 
>     Muhammad Shahzad
>     -----------------------------------
>     CISCO Rich Media Communication Specialist (CRMCS)
>     CISCO Certified Network Associate (CCNA)
>     Cell: +49 176 99 83 10 85
>     MSN: shari_786pk at hotmail.com <mailto:shari_786pk at hotmail.com>
>     Email: shaheryarkh at googlemail.com <mailto:shaheryarkh at googlemail.com>
>
>
>
>
>     _______________________________________________
>
>     Users mailing list
>
>     Users at lists.opensips.org  <mailto:Users at lists.opensips.org>
>
>     http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20130314/7324e1fa/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 5316 bytes
Desc: not available
URL: <http://lists.opensips.org/pipermail/users/attachments/20130314/7324e1fa/attachment-0001.png>


More information about the Users mailing list