Subject: Re: SIP multicast

From: Sean Olson <[email-masked]>
Date: Sat, 11 Sep 1999 10:01:01 -0500 (CDT)

> 
> Let's say my Registration server is expecting authorization. And it
> listens for request to All SIP  servers multicast address 224.0.1.75.
> 
> Now if the server receives a request through the multicast address, and
> since it cannot send any response other than 2xx or 6xx, what should it
> do...
> 
> Same with Invitations. For a client registered to listen at a multicast
> address (239.1.1.1) and is accepting invitations from only authorized
> clients. What should it do when it receives invitation with no
> Authorization header?    Send a 603 Decline response?
> 

It seems a very unusual choice to use multicast signalling for a point to 
point relationship like authorization/authentication as defined in the SIP 
spec. Multicast security requires a different approach. (See
draft-irtf-smug-gsadef-00.txt). In any event, if there is anything wrong
with a multicast request (lack of Authorization header included), I would
recommend simply dropping the request.

> Thank you,
> Vipul.
> 
> --
> 
> Vipul J. Patel
> dynamicsoft
> 200 Executive Drive
> West Orange, NJ 07052
> mailto:[email-masked]
> 
> Office:         + 1 732.741.7244
> FAX:            + 1 732.741.4778
> www:            http://www.dynamicsoft.com

-----------------------------------------------------------------
Sean Olson            E-mail: [email-masked]
Ericsson Inc.         Voice: (972) 583-5472 
                      FAX: (972) 669-0154

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 13 Sep 1999 00:45:20 -0400

> recommend simply dropping the request.

The problem is that the client may be attempting to discover the SIP
server through a multicast registration. In this case, it may require
authorization (next time around through unicast, in fact). So, it should
send a 401 response, and then the UAC resubmits the request with
credentials.

Note that here is also a case where record-routes/contact is very useful
in a non-200 response (we've discussed this before in other contexts).
You really want a Contact header in the 401 indicating the URL to use
for actual registration.

-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: Mon, 13 Sep 1999 11:38:24 +0100

> You really want a Contact header in the 401 indicating the URL to use

This means clients must interpret Contact headers in responses to
REGISTER  requests differently depending on the status code: 2xx and
Contacts are current addresses of address-of-record and otherwise
they're addresses of the registrar itself. This is what rfc 1543 says
and that's fine.

This 'overloading' of the Contact header means that a registrar cannot
give its own actual address in a Contact header in a 2xx.  A server can,
however, first redirect to its own non-multicast address and then
respond to the redirected request with a 2xx (or 401 for that matter). 
Maybe the spec should explicitly recommend this extra step, i.e. avoid
responding with 2xx to any multicast'ed message.

Cheers,
Anders

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 13 Sep 1999 11:50:32 -0400

> responding with 2xx to any multicast'ed message.

This is an excellent point, and its something I have come to realize as
well. Contact definitely has two meanings, as you describe. 

I like your suggestion for the first stage redirect, followed by a
normal unicast registration.  

-Jonathan R.