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

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

The main thing I am looking for is that we come up with a consistent rule
that means that anybody specifying a new method does not have to write their
own set of rules - the rules will be in the bis draft.

Both Adam's (and others) approach (allowed only on methods where the final
response is not immediate), and the current bis approach (allowed on all
methods whether it is useful or not) can be drafted as a consistent set of
rules, and at the end of the day, I do not mind which we get. 

Having agreed that set of rules, we can (should) then remove all information
relating to CANCEL from the various extension drafts, and maybe even write
such a statement in the guidelines document for authors of future
extensions, safe in the knowledge that there is no scope for
misinterpretation amongst implementors (well some days we can be optimistic
:-) ).

Keith

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

> ----------
> From: 	[email-masked][SMTP:[email-masked]]
> Reply To: 	[email-masked]
> Sent: 	10 May 2001 19:28
> To: 	Jo Hornsby
> Cc: 	Drage, Keith (Keith); Jonathan Rosenberg; [email-masked]
> Subject: 	RE: [SIP] Further editorial nit in the bis draft
> 
> > -----Original Message-----
> > From: Christer Holmberg [mailto:[email-masked]]
> >
> > One proposal: "CANCEL can only be used to terminate an INVITE 
> > request".
> > Short and simple :)
> 
> This is exactly what I suggested to the group in Minneapolis. I haven't
> heard any arguments why this is a bad idea, and only one very weak one
> about how forbidding "CANCEL" for non-invites would change the overall
> network behavior from its current state.
> 
> In light of the fact that INVITE is the only long-running transaction
> we allow, I beleive that forbidding CANCEL for non-INVITEs helps new
> implementors by making it clear that they don't need code to handle
> situations which cannot arise.
> 
> /a
> 

_______________________________________________
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: 11 May 2001 15:56:42 +0300

In message <[email-masked]> "Drage, Keith (Keith)" <[email-masked]> writes:
>   A BYE request from either called or calling party terminates any
>   pending INVITE at a UA, but the INVITE request transaction MUST be
>   completed with a final response and ACK.

        Another nit.  This contradicts with the text in 11.3:

                                                Pekka

11.3 Caller Receives Response to Initial Request

   Multiple responses may arrive at the UAC for a single INVITE request,
   due to a forking proxy. Each response is distinguished by the "tag"
   parameter in the To header field, and each represents a distinct call
   leg. The caller MAY choose to acknowledge or terminate the call with
   each responding UAS. To acknowledge, it sends an ACK request, and to
   terminate it sends a BYE request.  The To header field in the ACK or
   BYE MUST be the same as the To field in the 200 response, including
   any tag. The From header field MUST be the same as the From header
   field in the 200 (OK) response, including any tag.