Subject: RE: [SIP] A question about Cancel request

From: "Yu, James" <[email-masked]>
Date: Tue, 17 Apr 2001 14:36:28 -0500

Alan,

CANCEL is to cancel a pending a request.  If the call has been established
and there is no pending request to be cancelled, sending a cancel will not
result in call termination.  A 3G wireless caller may be put on hold (e.g.,
call to service center) but mobile phone is out of radio contact with the
network (e.g., in the tunnel or outside coverage area).  The 3G network
knows about the situation; therefore, may need a way to terminate the call
(instead of waiting for the UA at the other side to terminate the call).

There is also a potential fraud case where the proxy servers want to stay in
the signaling path by using the record-route and route mechanism but the UAs
ignore the route and one of them sends the BYE directly to the other side to
terminate the call (the UAs can ignore the protocol rules if they are
programmed to do so).  A mechanism may be needed for the proxies in the
"route" to terminate the call - something like "proxy initiated disconnect."

James  

> -----Original Message-----
> From: Alan Johnston [mailto:[email-masked]]
> Sent: Tuesday, April 17, 2001 2:57 PM
> To: Drage, Keith (Keith)
> Cc: [email-masked]'
> Subject: Re: [SIP] A question about Cancel request
> 
> 
> Keith,
> 
> Of course nothing in the Call Flows draft is normative - in 
> any conflict between
> it and the RFC, the RFC holds.
> 
> Having said that, I'm not sure I understand your concern 
> here.  How many
> retransmissions the stateful proxy 2 does is an 
> implementation issue - it could
> choose to give up at any time.  Also, if the proxy wishes to 
> terminate the call,
> its only option is to send a CANCEL - it can not originate a 
> BYE.  The caller
> User A could send either a BYE or a CANCEL to terminate the call.
> 
> How and when a proxy initiates a CANCEL doesn't seem to need 
> to be spelled out
> in the SIP standard.
> 
> Thanks,
> Alan Johnston
> sip:[email-masked]
> 
> "Drage, Keith (Keith)" wrote:
> 
> > We have a clear incompatibility in the SIP drafts here.
> >
> > While draft-ietf-sip-call-flows-03.txt section 3.2.3 
> implies that the
> > expected action is to send a CANCEL, we have been unable to 
> find any text in
> > the bis-02 draft indicating any special use of CANCEL from 
> a proxy in this
> > case.
> >
> > The only text we have found is text that says anybody can 
> send a CANCEL at
> > any time.
> >
> > Whether it is MUST, MAY or MUST NOT I believe we do need 
> some text on this
> > subject.
> >
> > My view is that it would say MAY, possibly followed by some guidance
> > comments on conditions when it might be more appropriate 
> than others.
> >
> > by the way, the signalling flows draft says the CANCEL is 
> sent 7 times. I
> > thought 11 was the more appropriate number in this case, 
> using both T1 and
> > T2.
> >
> > Keith
> >
> > Keith Drage
> > Lucent Technologies
> > Tel: +44 1793 776249
> > Email: [email-masked]
> >
> > > ----------
> > > From:         Jonathan Rosenberg[SMTP:[email-masked]]
> > > Sent:         04 April 2001 7:30
> > > To:   'Mayank Sharma'; Chen, Xin (Xin); [email-masked]
> > > Subject:      RE: [SIP] A question about Cancel request
> > >
> > >
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Mayank Sharma [mailto:[email-masked]]
> > > > Sent: Tuesday, April 03, 2001 1:46 AM
> > > > To: Chen, Xin (Xin); [email-masked]
> > > > Subject: RE: [SIP] A question about Cancel request
> > > >
> > > >
> > > > > I have a basic question about sip.
> > > > > Cancel request is used to cancel a pending INVITE.
> > > > > In sip signalling establishment procedure, if the callee
> > > > > agent for some
> > > > > reason fails, it can't receive anything from its proxy, after
> > > > > the proxy
> > > > > server of the callee retransmittes 6 times INVITE messges, it
> > > > > should give up
> > > > > sending INVITE. My quesiton is whether the Cancel request is
> > > > > needed to send
> > > > > out by the proxy server to the callee, if so, it will cause
> > > > > another 11 times
> > > > > cancle request beeing sent.
> > > >
> > > > The Cancel is required to be sent to the callee. Simple
> > > > reason being that the
> > > >
> > > > proxy does not know weather the callee UA is down or is
> > > > simply not responding
> > > > for the time being. Sending Cancel ensures that in case UA is
> > > > not down this
> > > > Cancel
> > > > will cancel the previous Invite, and the UA is not supposed
> > > > to respond to
> > > > that Invite
> > > > at a later stage.
> > >
> > > Actually, I have debated whether or not CANCEL is useful 
> in the case where
> > > you never received any provisional response at all, not 
> even a 100. This
> > > is
> > > likely a sign that the device or the network has failed, 
> in which case the
> > > CANCEL is not useful.
> > >
> > > I would tend to think that the best answer is to say that 
> if you never
> > > receive a provisional response, you MAY send a CANCEL, but its not
> > > mandatory. If you do get a provisional response, you 
> SHOULD CANCEL upon
> > > timeout.
> > >
> > > -Jonathan R.
> > >
> > > ---
> > > Jonathan D. Rosenberg                       72 Eagle Rock Ave.
> > > Chief Scientist                             First Floor
> > > dynamicsoft                                 East Hanover, NJ 07936
> > > [email-masked]                     FAX:   (973) 952-5050
> > > http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
> > > http://www.dynamicsoft.com
> > >
> > > _______________________________________________
> > > This list is for continuing development of the SIP protocol.
> > > The sip-implementor'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" 
> in the body.
> > >
> >
> > _______________________________________________
> > This list is for continuing development of the SIP protocol.
> > The sip-implementor'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" 
> in the body.
> 
> 
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementor'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" in the body.
> 

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor'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" in the body.

---

From: "Dean Willis" <[email-masked]>
Date: Thu, 19 Apr 2001 14:36:43 -0500

The session-timer specification provides information to allow a stateful
proxy to know when to discard state on a call.

Bypassing the proxy is not really a "fraud" issue -- anybody billing on
proxied call terminations without having some other mechanisms that enforce
transiting the firewalls is just hoping that somebody will be nice to them.

--
Dean