A CANCEL is an attempt to terminate the INVITE transaction which would 
terminate ALL early dialogs. A single BYE cannot be used to terminate ALL early 
dialogs. If the UAC wishes to terminate a specific early dialog, then it would 
send a BYE. The BYE would include the To and From tags which uniquely identify 
the dialog. For example, if the UAC received 18x responses (creating early 
dialogs), and it decided it preferred that the call not continue/complete on 
one of those early dialogs, it could send a BYE and terminate that one dialog.

A CANCEL does not have a to-tag (assuming an initial INVITE), and will 
ultimately reach all UAS's that the INVITE reached.

It should be noted that if the UAC wishes to terminate the INVITE, it should 
send a CANCEL because the UAC cannot know for sure that the INVITE was not 
forked to a UAS that did not send a 18x response.

RFC 3261 does require provisional responses that create dialogs to have a 
Contact header, although it is not real clear about it.

Section 12.1 says:

   Within this specification, only 2xx and 101-199 responses with a To tag,
   where the request was INVITE, will establish a dialog.

Sections 12.1.1 says:

   When a UAS responds to a request with a response that establishes a
   dialog (such as a 2xx to INVITE), the UAS MUST copy all Record-Route
   header field values from the request into the response (including the
   URIs, URI parameters, and any Record-Route header field parameters,
   whether they are known or unknown to the UAS) and MUST maintain the
   order of those values.  The UAS MUST add a Contact header field to
   the response.

If reliable provisional responses are being used, the UAS definitely needs to 
include a Contact for the UAC to use for the PRACK. The majority of 
implementations I have seen do include a Contact in 18x responses. However, it 
would probably be a wise for a UAC not to send BYE when the 18x did not include 
a Contact.

cheers,
(-:bob

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Iñaki Baz 
Castillo
Sent: Friday, August 15, 2008 6:03 PM
To: [email protected]
Subject: [Sip-implementors] Why is allowed a BYE instead of a CANCEL?

Hi, I can't understand why RFC3261 allows the use of a BYE instead of
a CANCEL to end an early-dialog. This is:
During an INVITE transaction the UAC can cancel it by sending a CANCEL or a BYE.

Of course, this is very different since a proxy receiving a CANCEL
replies it automatically (CANCEL is hop by hop) but a BYE would be
forwarded to each parallel location and so.

So imagine the case in which user_A (UAC) calls user_B through a proxy
that does parallel forking to each user_B location:
- user_A receives provisional responses of each user_B location
(different to_Tag so different early-dialogs).
- If user_A want to cancel the transaction it can:
  - Send a single CANCEL (identical to the INVITE) so proxy will
handle it by replying 200 and forking to every user_B locations.
  - Send an in-dialog BYE to *each* user_B location (am I right?).

This last point is impossible since a "180 Ringing" (for example) is
not required to include a "Contact", so how can UAC send the BYE?

RFC 3261 says:

----------------
15 Terminating a Session
   When a BYE is received on a dialog, any session
   associated with that dialog SHOULD terminate.  A UA MUST NOT send a
   BYE outside of a dialog.  The caller's UA MAY send a BYE for either
   confirmed or early dialogs, and the callee's UA MAY send a BYE on
   confirmed dialogs, but MUST NOT send a BYE on early dialogs.
----------------

Also:

---------------
13.2.2.1 1xx Responses
   The early dialog will only be needed if the UAC needs to send a
   request to its peer within the dialog before the initial INVITE
   transaction completes.
---------------

And also:

---------------
15.1.2 UAS Behavior
   A UAS first processes the BYE request according to the general UAS
   processing described in Section 8.2.  A UAS core receiving a BYE
   request checks if it matches an existing dialog.  If the BYE does not
   match an existing dialog, the UAS core SHOULD generate a 481
   (Call/Transaction Does Not Exist) response and pass that to the
   server transaction.
      This rule means that a BYE sent without tags by a UAC will be
      rejected.  This is a change from RFC 2543, which allowed BYE
      without tags.
---------------


So please note: is it allowed an early-dialog if the provisional
response (180|183...) has no "Contact" header?
If it's possible, how to send the BYE to terminate the INVITE
transaction if there is no remote target???

And of course, why the f**k is it allowed to terminate a early-dialog
with a BYE if CANCEL **does** exist?

Thanks a lot.


--
Iñaki Baz Castillo
<[EMAIL PROTECTED]>

_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Reply via email to