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

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Wed, 18 Apr 2001 09:59:13 +0100

My concern is that primarily we have a hole in the bis draft about what the
proxy should do in this case.

Having transmitted the INVITE, and failed to receive a response (despite
retransmitting according to the fairly fully specified algorithm), is it
required to send a CANCEL forward in order to cancel the INVITE, as
indicated by the call-flows draft, but with no supporting text in the bis
draft, or is it permissable, or even required, to do nothing further in the
forward direction, and merely provide a response in the backward direction.

As specifications by absence of procedures normally imply that one should
not do such a procedure, my reading of the current bis draft would be that I
would normally do nothing in the forward direction in this case, whereas the
call-flows draft indicates that CANCEL in the forward direction would be the
normal operation.

Keith

Keith Drage
Lucent Technologies
Tel: +44 1793 776249
Email: [email-masked]

> ----------
> From: 	Alan Johnston[SMTP:[email-masked]]
> Sent: 	17 April 2001 19:57
> 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: Pekka Pessi <[email-masked]>
Date: 19 Apr 2001 08:55:05 +0300

>forward direction, and merely provide a response in the backward direction.

        The section 12.4 in the bis-02 (Nov 2000) states that a forking
        proxy MAY send a CANCEL to all incomplete branches.  A stateful
        proxy is a forking proxy with one fork.

        A reasonable approach would be to retransmit CANCEL only if a
        provisional response has been received for that transaction.

                                                Pekka