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 <shaherya...@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 <kche...@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:shaherya...@gmail.com] >> *Sent:* Tuesday, February 12, 2013 3:05 PM >> *To:* M.Khaled W Chehab >> *Cc:* users@lists.opensips.org; bog...@opensips.org; >> users-boun...@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 <kche...@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**** >> >> [image: Description: icucall]**** >> >> Operations Office - Lebanon**** >> >> Office : +961 1 515155 ext 300**** >> >> Mobile : +961 3 045212**** >> >> E-mail : kche...@icucall.com**** >> >> MSN ID :khalidche...@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_78...@hotmail.com >> Email: shaherya...@googlemail.com **** >> > > > > -- > Muhammad Shahzad > ----------------------------------- > CISCO Rich Media Communication Specialist (CRMCS) > CISCO Certified Network Associate (CCNA) > Cell: +49 176 99 83 10 85 > MSN: shari_78...@hotmail.com > Email: shaherya...@googlemail.com > -- Muhammad Shahzad ----------------------------------- CISCO Rich Media Communication Specialist (CRMCS) CISCO Certified Network Associate (CCNA) Cell: +49 176 99 83 10 85 MSN: shari_78...@hotmail.com Email: shaherya...@googlemail.com
<<image001.png>>
_______________________________________________ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users