Subject: Re: Question on multicast for SIP

From: Sean Olson <[email-masked]>
Date: Wed, 30 Jun 1999 15:51:34 -0500 (CDT)

> Hi all,
> 
> I have a question on multicast for SIP. In section 10.2.2 of SIP RFC
> 2543, it says following:
> 
> >>>>>>>
> 
> "Servers do not respond to CANCEL requests received via multicast to
> avoid request implosion. A proxy or UAC SHOULD send a CANCEL on
> receiving the first 2xx or 6xx response to a multicast request.
> 
> ........... The CANCEL, instead provides a simpler and more standard way
> to perform response suppression. It is for this reason that the use of
> CANCEL here is a SHOULD".
> 
> <<<<<<<
> 
> 
> Let's say client A sends a unicast SIP request (INVITE), and it is
> received by proxy P. Proxy P sends that request to multicast address,
> and it is received by proxy P and clients B, C and D. Client B sends a
> 200 OK response, and proxy P and clients B, C and D will receive this
> response. Proxy P will send a CANCEL, and it will be received by proxy P
> and clients B, C and D.
> 
> How should client B, C and D treat that CANCEL request?
> 

First, I would recommend that you configure your multicast socket so that
the sender does NOT receive a copy of the packets that it sends out. 

For unicast, I believe client B would send a "481" since the transaction that
the CANCEL was sent for no longer exists for B (it has sent a final response;
the ACK is not part of the INVITE transaction)

For multicast I believe it would be appropriate for client B to silently
discard any CANCEL received via multicast. Either way, the call at client B
is not affected. This should be clarified in the spec.

For clients C and D, they should return a 200 response to the CANCEL
(distinguished by the method in the CSeq)

> How does the CANCEL sent by proxy P (in this case) differ from CANCEL of
> a INVITE sent by client A (in general)?
> 

For clients B,C, and D it doesn't. The CANCEL will have the same To,From,
Call-Id, and CSeq whether sent by the proxy P or the client A. The main
difference will be in the Via headers. But behaviorally it should be treated
identically.

> - Vipul.  :-)
> 
> --
> 
> Vipul J. Patel
> dynamicsoft
> 200 Executive Drive
> West Orange, NJ 07052
> mailto:[email-masked]
> 

-----------------------------------------------------------------
Sean Olson            E-mail: [email-masked]
Ericsson Inc.         Voice: (972) 583-5472 
                      FAX: (972) 669-0154
> Office:         + 1 732.741.7244
> FAX:            + 1 732.741.4778
> www:            http://www.dynamicsoft.com
> 
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 30 Jun 1999 22:25:27 -0400

Sean Olson wrote:

> the ACK is not part of the INVITE transaction)

Well, it will probably be waiting for the ACK and thus does know about
the transaction, so it could send a 200. Doesn't matter.

> (distinguished by the method in the CSeq)

This leads to an implosion for large numbers of receivers. The spec
doesn't say it, but it might be a good idea for multicast CANCELs to not
be responded to. Of course, this means the proxy has no way of knowing
if the CANCEL was received. We could either just follow current
operation, and let it get retransmitted a few times (eventually it will
give up), or specify some small number of times to be used for multicast
CANCEL only. It would be a good thing if the behavior wasn't different
from unicast in terms of retransmissions, but its a lot of packets (11).

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: [email-masked]
URL: http://www.cs.columbia.edu/~jdrosen

---

From: Anders Kristensen <[email-masked]>
Date: Thu, 01 Jul 1999 10:39:11 +0100

> > > How should client B, C and D treat that CANCEL request?

B should ignore it and C and D should terminate processing of the
request. Noone should respond.

> be responded to.

The spec does say it, actually. Requoted from Vipuls original email:

  "Servers do not respond to CANCEL requests received via multicast
  to avoid request implosion." [10.2.2]

> Of course, this means the proxy has no way of knowing

It seems wrong to retransmit when no response is expected. How about
sending the CANCEL just once and hope for the best. Multicast is
probably not going to be used on a wide-area scale anyway. And a good
proxy might want to listen in on other receivers multicast responses
too, which gives it an extra shot at terminating its own request
processing.

Anders

-- 
Anders Kristensen <[email-masked]>,
http://www-uk.hpl.hp.com/people/ak/
Hewlett-Packard Labs, Bristol, UK