Subject: RE: [SIP] Further editorial nit in the bis draft

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Thu, 10 May 2001 10:50:27 +0100

Now this discussion seems to have died down, can I ask Jonathan to summarise
the final changes as a result of the discussion....starting the with the
requested changed to harmonise the status-code name through the
specification.

I think we should also look at the 100-rel draft, which defines the PRACK
method. 

This contains the following statement in 6.2

   A PRACK request MUST NOT be cancelled. If a UAS receives a CANCEL
   request for a PRACK, it MUST respond to the CANCEL with a 405 (Method
   Not Allowed).

Aside from the fact that the first sentence is a repetition of the UAC
requirement that already exists in section 6.1, and it is therefore
inappropriate to repeat the MUST NOT here where we are specifying
requirements for the UAS, the second sentence would appear to be
unnecessarily inconsistent with other requirements relating to CANCEL. 

I guess the answer here depends on whether we are assuming finite processing
time for these things or not. In most cases the 200 OK for a PRACK will be
sent immediately, therefore a CANCEL will not be able to get in. If a CANCEL
really can get in, can anybody elaborate why it is dangerous to cancel the
PRACK like any other method. 

In any case, as the 405 response seems primarily to tell the sender what
methods are allowed, presumably it must indicate that CANCEL (whose support
is mandatory by all UACs) is an allowed method in the Allowed header field,
thereby telling the sender that he cannot use CANCEL because CANCEL is an
allowed method!!!!

The 100rel requirement appears is inconsistent with the rest of the CANCEL
handling, and I cannot see the danger in making it consistent.

thanks

Keith

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

> ----------
> From: 	Christer Holmberg[SMTP:[email-masked]]
> Sent: 	30 April 2001 6:46
> To: 	Igor Slepchin
> Cc: 	Jonathan Rosenberg; 'Sean Olson (EUS)'; 'Vijay Gurbani';
> [email-masked]'
> Subject: 	Re: [SIP] Further editorial nit in the bis draft
> 
> <<File: christer.holmberg.vcf>>
> 
> Hi all,
> 
> >Well, the original motivation for sending a BYE instead of a CANCEL to
> >terminate call setup was PSTN connectivity, since PSTN gateways may
> >apparently want to send ISUP in SIP call termination messaging.
> > 
> >With CANCELs being hop by hop and the note in 8.1 specifically
> prohibiting
> >sending payloads in CANCELs, it was somehow assumed that they are not
> suited
> >for conveying that ISUP payload. I never really bought into that argument
> so
> >I am fine with the proposed wording. However, at this point it may become
> a
> >compatibility issue if lots of folks have already implemented sending the
> >BYE. I'd recommend saying that UASs should be prepared to receive either
> a
> >BYE or a CANCEL but UACs SHOULD send a CANCEL and only BYE the 200
> responses
> >if any.
> 
> By saying that "UASs should be prepared to receive either a BYE or a
> CANCEL" would not solve anything, and soon we would have this discussion
> again, since many implementations would probably not implement support
> to receive BYE. My suggestion would be to say that "A UAS MUST be
> prepared to receive either a BYE or a CANCEL". A UAC can then send
> either BYE or CANCEL (no SHOULDs needed), depending on the functionality
> (Igor gave an example why a PSTN GW may want to use BYE instead of
> CANCEL).
> 
> However, it should be clearly written that BYEs are used to terminate
> whole calls/call setups, so that people don't start using them to
> "cancel" transactions, ie re-INVITEs.
> 
> I know that my MUST-proposal may have some backward compability issues,
> but solving those issues (not only in this case) by adding a lots of
> SHOULDs will in many cases only move the problems to a later stage...
> 
> Regards,
> 
> Christer Holmberg
> Ericsson Finland
> 
> 
> 
> 
> 
> 
> > 
> > ---
> > Igor Slepchin
> > 
> > > -----Original Message-----
> > > From: Jonathan Rosenberg [mailto:[email-masked]]
> > > Sent: Friday, April 27, 2001 11:21 AM
> > > To: 'Sean Olson (EUS)'; 'Vijay Gurbani'; Jonathan Rosenberg
> > > Cc: Christer Holmberg (LMF); [email-masked]'
> > > Subject: RE: [SIP] Further editorial nit in the bis draft
> > >
> > >
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Sean Olson (EUS) [mailto:[email-masked]]
> > > Sent: Friday, April 27, 2001 11:02 AM
> > > To: 'Vijay Gurbani'; Jonathan Rosenberg
> > > Cc: Christer Holmberg (LMF); [email-masked]'
> > > Subject: RE: [SIP] Further editorial nit in the bis draft
> > >
> > > >>Jonathan:
> > > >>
> > > >>I misinterpret many thing, but definitely not this one :-)  In
> > > >>some earlier
> > > >>posting, I made the same point: a BYE should be sent after a
> > > >>CANCEL iff
> > > >>the 200 OK (INVITE) from the UAS and the CANCEL pass each
> > > >>other on the wire.
> > > >
> > > >This is not what Jonathan is saying. He is referring to the
> > > >possibility of sending a BYE *instead* of a CANCEL, not sending
> > > >a BYE in the event a CANCEL crosses on the wire.
> > >
> > > Everyone loves to put words into my mouth...
> > >
> > > I was saying that the preferred approach is to send CANCEL
> > > first, and then
> > > iff you get a 200 OK anyway (which happens if the CANCEL and
> > > 200 OK pass on
> > > the wire) then send BYE. I was also saying we should keep
> > > "just send BYE" as
> > > a MAY. Vijay seems to be saying we should not even mention
> > > that possibility.
> > >
> > > -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.jdrosen.net                      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.

---

From: "Jo Hornsby" <[email-masked]>
Date: Thu, 10 May 2001 16:54:37 +0100

> unnecessarily inconsistent with other requirements relating to CANCEL. 
[...]

I would agree with this.

A typical proxy does not know anything about PRACK, and thus
would not know that it cannot CANCEL one.  Since CANCEL
provides a neat way, in general, to try and cleanup state on
transactions, it would be a shame if a proxy was violating
some effectively unknown rule.

However, that said, CANCEL doesn't seem useful for non-INVITEs
(unless they enfore very quick completion of transactions),
unless (perhaps) the request is forked.  And we know that
forking of non-INVITEs is typically undesirable.  So it's
difficult.

Thoughts?

 - Jo.

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 10 May 2001 19:13:13 +0300

Hi,

> forking of non-INVITEs is typically undesirable.  So it's

One proposal: "CANCEL can only be used to terminate an INVITE request".
Short and simple :)

Another idea would be to include Proxy-Require: 100rel, if the UAC knows
it may want to CANCEL a PRACK, but I don't know if that is a very good
think to do...

Regards,

Christer Holmberg
Ericsson Finland