<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Ron,<div><br></div><div>No, I don't believe the theory is not correct.</div><div><br></div><div>I'm going to think you have a customer that gets hung up on a lot, generating short-call surcharges from your carriers. &nbsp;You want to delay the BYE you send to the carrier... except that's not what triggers the call disconnect. &nbsp;The disconnect likely comes <i>from</i>&nbsp;the far-end via the carrier that's charging you. &nbsp;They're going to stop the clock when they send you BYE, not when you reply with a 200 OK.</div><div><br></div><div>Delaying the BYE through your proxy isn't going to help your bottom line. &nbsp;It'll just make your network messy.</div><div><br></div><div><br></div><div>- Jeff</div><div><br></div><div><br><div><div>On Jan 18, 2010, at 4:18 PM, Ron McCarthy wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Jeff,<br><br>Yes, that's the goal anyways :)<br><br>I guess in my mind I thought if I could delay the BYE from going to the upstream BUT send the BYE to the customer / ACK the BYE they sent then the end user has no ideal what's going on and we just leave the channel open for 5 to 11 seconds and then send the BYE to the upstream. Seemed that easy anyways, but figured it would not be.<br>
<br>If the far end hangs up that's fine, we get the BYE, ACK that BYE but do not send the BYE to the upstream, this in theory is correct right?<br><br>Ill have to look into b2b more, that might be the answer, we shall see.<br>
<br>Thanks for the input.<br><br><div class="gmail_quote">On Mon, Jan 18, 2010 at 2:00 PM, Jeff Pyle <span dir="ltr">&lt;<a href="mailto:jpyle@fidelityvoice.com">jpyle@fidelityvoice.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div style="">Ron,<div><br></div><div>Are you trying to avoid short-call charges from your carrier? &nbsp;It's not easy.</div><div><br></div><div>Even if this were possible, it wouldn't help if the far-end were to hang up first. &nbsp;Even if they don't hang up first, they're likely going to hang up during this 12-second window you're looking to create in Opensips. &nbsp;At best you'd buy yourself a second or so beyond actual disconnect time.</div>
<div><br></div><div>This isn't a good idea at the SIP level either. &nbsp;If you were to delay a BYE, you're going to get retransmissions from your UAC because it's looking for a 200 OK.</div><div><br></div><div>The only way I could think of doing it would be in a custom B2B scenario, but even then, it probably wouldn't work well. &nbsp;And in my opinion it's very complicated.</div>
<div><br></div><div><br></div><div>- Jeff</div><div><br></div><div><br></div><div><div><div><div></div><div class="h5"><div>On Jan 18, 2010, at 3:55 PM, Ron McCarthy wrote:</div><br></div></div><blockquote type="cite"><div>
<div></div><div class="h5">Hi List,<br>
<br>
When a user hangs up a call (call comes into proxy, connects to PSTN) and if the user that made the call hangups before a certain amount of time I want to delay sending the BYE to the upstream carrier, but ACK the BYE to the person they called and then have acc show the correct call timestamps of when the user really hanged up. Basically if a call is less then say 12 seconds id like to sleep() a few seconds until it's past 12 seconds then hang the call up.<br>


<br>
Inside the loose_route() and is_method("BYE") I put this:<br><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; $avp(s:nowts)=$Ts;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; $avp(s:calllength)=$avp(s:calltime) - $Ts;<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if($avp(s:calllength) &lt; "6"){<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; $avp(s:sleeptime)= "6" - $avp(s:calllength); <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; xlog("L_NOTICE","Now TS: $Ts Call was $avp(s:calllength) seconds long, sleeping for $avp(s:sleeptime)");<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; #sleep("$avp(s:sleeptime)");<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; } else {<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; xlog("L_NOTICE","Now TS: $Ts Call was $avp(s:calllength) seconds long, not sleeping");<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; }<br>
<br>
<br>
Inside the onreply_route I put this:<br><br>
&nbsp; if(t_check_status("200") &amp;&amp; is_method("INVITE")){<br>
&nbsp;&nbsp;&nbsp; $avp(s:calltime)=$Ts;<br>
&nbsp;&nbsp;&nbsp; xlog("L_NOTICE","Call connected at $avp(s:calltime)");<br>
&nbsp; }<br>
<br>
To me I would think I would then have the timestamp at when the call started (that parts works), then in the loose_route() I could take the current timestamp and subtract the two, then if less the X seconds, sleep before it sends the BYE.<br>


<br>
I know their is more to it then that, but as a starting point the $avp(s:calltime) var is NULL when the call hits loose_route() is, I have verified this by the log.<br>
<br>
Any help / insight on this would be great, I would think the variables would be accessible anyway I try to check for values, but it appears that is not the case.<br></div></div>
_______________________________________________<br>Users mailing list<br><a href="mailto:Users@lists.opensips.org" target="_blank">Users@lists.opensips.org</a><br><a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
</blockquote></div><br><div>
<span style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Verdana; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;">Regards,<br>
--------<br><b>Jeff Pyle</b><br><b>Director, Voice Engineering</b><br><b>Fidelity Voice &amp; Data</b><span>&nbsp;</span>|&nbsp;23250&nbsp;Chagrin Blvd, Suite 250&nbsp;|&nbsp;Beachwood,&nbsp;Ohio 44122<br>P: 216-245-4106<br>F: 216-595-0706<br>E:&nbsp;<a href="mailto:jpyle@fidelityvoice.com" target="_blank">jpyle@fidelityvoice.com</a><br>
<br>Visit us at&nbsp;<a href="http://www.fidelityvoice.com/" target="_blank">http://www.fidelityvoice.com</a><br><br>2008 &amp; 2009 Inductee to the prestigious&nbsp;Weatherhead 100<br><br></span><span><span>&lt;image.jpg&gt;</span></span>
</div>
<br></div></div><br>_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a><br>
<a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
<br></blockquote></div><br>
_______________________________________________<br>Users mailing list<br><a href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a><br>http://lists.opensips.org/cgi-bin/mailman/listinfo/users<br></blockquote></div><br></div></body></html>