Subject: RE: [SIP] Terminating pending calls

From: Will van der Leij <[email-masked]>
Date: Fri, 19 Jan 2001 19:02:50 +0200

> I think the draft was very clear in stating that the call 
> needs to be ACK'ed
> then BYE'd.
> 
> The far end would already have it's data stream set up, if it 
> went through any proxies, since it already received its ACK.
> 
> So, sending a BYE instead of an ACK doesn't really buy you 
> any benefits, 
> except to break the RFC and save a couple of packet round trips.
> 
> -Dave

Hi Dave,
It is the setting up of the data stream that interests me.
If the BYE is arrives after the ACK, the call is established, 
possibly long enough for the user to be billed for a call he had
rejected. It is this scenario I'm investigating.

Will

> 
> 
> 
> On Thu, Jan 18, 2001 at 12:19:08PM +0200, Will van der Leij wrote:
> > Hi,
> > My apologies if this has been covered somewhere in the archives,
> > I'm still scanning through them.
> > 
> > I have a question regarding the termination of pending INVITEs
> > without the possibility of the call being set up.
> > Consider sending an INVITE which gets a 200 OK response.
> > The UA decides, fow whatever reason, to drop the call. To do
> > this, the UA sends a BYE. The INVITE, however, needs to be
> > ACKed as well. Now if the BYE and ACK follow different routes,
> > then there is the possibility that the ACK arrives first and 
> > the call gets set up before the BYE terminates it.
> > 
> > Is there anything wrong with sending the BYE after receiving
> > the 200 OK for the INVITE and then only ACKing the INVITE after
> > receiving the 200 OK response to the BYE? The only draw back I 
> > can see here is that the server might retransmit the response 
> > before it receives the BYE. Or do we send them together?
> > 
> > I was also wondering why we need to send an ACK if we are going to
> > send a BYE for the call? Can the BYE, in such a case, not perform
> > the role of the ACK as far as the server is concerned?
> > 
> > Regards,
> > Will van der Leij
> > 
> > __________/\/^^^^^^\______
> > W.R.van der Leij
> > Azisa (Pty) Ltd.
> > http://www.azisa.co.za
> > 
> > _______________________________________________
> > This list is for continuing development of the SIP protocol.
> > The sip-implementer's list is the place to discuss implementation,
> > and to receive advice on understanding existing sip.
> > To subscribe to it, send mail to [email-masked] with
> > "subscribe sip-implementors" in the body.
> 
> ----- End forwarded message -----
> 
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementer's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to [email-masked] with
> "subscribe sip-implementors" in the body.
> 

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to [email-masked] with
"subscribe sip-implementors" in the body.

---

From: David Frascone <[email-masked]>
Date: Fri, 19 Jan 2001 11:22:27 -0600

> rejected. It is this scenario I'm investigating.

It really depends on what you're billing.  Since the caller has already
terminated, billing on the caller will be nil.  Now, the callee could be
sending data, but he could not have received any, and his sent data would
not have been received.

I think you could design a billing algorithm to handle this race condition
pretty easily.