Subject: [SIP] CANCEL and stateless proxies

From: [email-masked]
Date: Tue, 17 Oct 2000 13:04:53 +0300

Hi,

A CANCEL request for a previous INVITE follows the same path as
the INVITE. This 
way the CANCEL request arrives to the same set of hosts as the
INVITE.

Stateful proxies storing transaction state perform this routing
fine.

What about stateless proxies? The CANCEL might be routed in a
different way than 
the previous INVITE.

This issue is somehow related to the "BYE after a INVITE"
issue. It is 
preferable to send a CANCEL rather than a BYE after a INVITE
because stateful 
proxies storing transaction state will route the CANCEL
properly. The BYE might 
be routed in a wrong way.

My question is: the same way proxies storing just transaction
state (not call 
state) might route a BYE to a different host than the previous
INVITE, a 
stateless proxy might route a CANCEL in a wrong way. What am I
missing?

Thanks,

Gonzalo

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: "Hisham Khartabil" <[email-masked]>
Date: Tue, 17 Oct 2000 14:14:11 +0300

Hi,
The INVITE and the CANCEL are independent transactions.  It doesn't really
matter if they follow the same routing path or not.  It is the UAS that
needs to know that a request is being cancelled.  The 487 response, for the
INVITE, returned by the callee (UAS) upon reception of the CANCEL will
traverse back using the Via headers in the INVITE.  The 200 for the CANCEL
does the same.  The solves the statefull proxy problem.  Stateless proxies
don't keep state anyway.

Regards,
Hisham
Hotsip

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of [email-masked]
Sent: Tuesday, 17 October 2000 1:05 PM
To: [email-masked]
Subject: [SIP] CANCEL and stateless proxies

Hi,

Thanks,

Gonzalo

---

From: [email-masked]
Date: Tue, 17 Oct 2000 17:02:32 +0300

Hi again,

I will give a particular example of the general question I
asked in my previous 
mail.

We have a sales department with two persons working: Bob and
Alice.
They have a staless SIP proxy server.

Bob works from 8:00 to 12:00 and Alice from 12:00 to 16:00.

Therefore, all the incoming INVITEs with Request-URI
[email-masked] are 
routed to [email-masked] from 8 to 12 and to
[email-masked] from 12 
to 16.

An INVITE arrives to this stateless SIP server right before
12:00. It is routed 
to Bob. Then, a CANCEL arrives, but it is routed to Alice. (If
instead of a 
CANCEL a BYE would have sent we have the same problem).

Now we have Bob's UAS ringing all the day because we cannot
stop it.

I hope this example clarifies my previous question (see
previous mail),

Thanks,

Gonzalo

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 17 Oct 2000 19:24:38 +0300

Hi,

"Vijay K. Gurbani" wrote:
> Gonzalo:
> 
> Just to be sure, I think your issue is different than the one I am
> currently battling with, correct?  Your issue appears to be sending a
> BYE (or CANCEL) after a successful INVITE (i.e. UAC got 200 OK).  Mine
> is terminating the INVITE before getting a final response.

If the UAC has already gotten a 200 OK there is no issue, because BYE
will be routed based on the Record-Route header received.

The issue I describe here (see another mail in this thread for an
example) appears when the UAC does not have a Record-Route header + a
tag in the To field to route the call.

Actually this is very much related to your "battle".

Best regards,

Gonzalo

> > state (not call state) might route a BYE to a different host than the
> > previous INVITE, a stateless proxy might route a CANCEL in a wrong
> > way. What am I missing?
> 
> A BYE, following a successful INVITE transaction will follow the route
> established in the 200 OK (bis, Section 11.2, Callee Issues Response,
> "...The UAS MUST add a Contact header in the response.  It contains the
> address where the callee would like to be contacted for subsequent
> transactions.").  So it appears to me that the BYE, even if processed
> by a stateless proxy, should end up at a consistent destination due to
> the Contact (or Route list, if a proxy Record-Route'd) headers.
> 
> You may be right about the CANCEL wandering to a different host if
> routed through a stateless proxy.  Thus, after a successful INVITE, BYE
> IS the way to go, not CANCEL.
> 
> Regards,
> 
> - vijay
> --
> Vijay K. Gurbani  [email-masked] [email-masked] [email-masked]
> Internet Software Group/Intelligent Network and Messaging Systems
> Lucent Technologies/Bell Labs Innovations, 263 Shuman Blvd, Rm 1A-413
> Naperville, Illinois 60566  Voice: +1 630 224 0216 Fax: +1 630 713 0184

-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 31 18
FIN-02420 Jorvas          Email :  [email-masked]
Finland

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 17 Oct 2000 10:57:31 -0500

[email-masked] wrote:
> the INVITE. This way the CANCEL request arrives to the same set of 
> hosts as the INVITE.
> 
> different way than the previous INVITE.
> 
> This issue is somehow related to the "BYE after a INVITE" issue. It is
> preferable to send a CANCEL rather than a BYE after a INVITE because 
> stateful proxies storing transaction state will route the CANCEL
> properly. The BYE might be routed in a wrong way.

Gonzalo:

Regards,

- vijay