Subject: Re: [SIP] Second try : Questions about REGISTER

From: Sean Olson <[email-masked]>
Date: Wed, 3 May 2000 12:32:04 -0500 (CDT)

> I'm not sure I see what is gained by adding a user portion. What is the
> semantic of having a user portion in the request URI? This still doesn't
> change how a proxy looks up registrations when an INVITE request is
> received (still based on request URI), which is what Dean is asking for.
> 

But it could open the possibility of changing how the REGISTER request gets routed/handled
based on the user portion of the Request-URI. (The routing I'm speaking of is outside
the realm of SIP, but shouldn't be precluded by the SIP protocol). In other words,
many SIP clients will be configurable as to where to send it's periodic REGISTER messages.
Allowing this configuration to be a full SIP URL including a user should make no
difference to the client, but may make a difference to the registrar. Probably 90% of
the registrars that get deployed won't use the user portion, but there's no reason
why those remaining 10% couldn't. Treating the URL as opaque (from the client perspective)
is a useful service primitive.

> -Jonathan R. 
> -- 
> Jonathan D. Rosenberg                       72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> [email-masked]                     FAX:   (732) 741-4778
> http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
> http://www.dynamicsoft.com

--
Sean Olson <[email-masked]>

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

---

From: Dean Willis <[email-masked]>
Date: Wed, 03 May 2000 14:37:41 -0500

> is a useful service primitive.

Does an INVITE have to be delivered only to the node indicated in the
right-hand-side of the request-URI? No, because we require transitivity
support in a proxy -- that is, we can ask a proxy to resolve something that
we know is not local to that proxy. That's what makes it a proxy, from my
point of view. Similarly, the To: and request-URI can differ due to request
transformations that have occurred in the proxy chain.

This is different from REGISTER. From 4.2.6 "The Request-URI names the
destination of the         registration request, i.e., the domain of the
registrar". Why? So a register can be proxied -- that is, a proxy/registrar
can decide whether the REGISTER was meant for it, and if not resolve the
next hop towards a registrar using the request-URI. Or so that a multidomain
registrar can determine which domain the registration should be valid in. I
argue more granularity is needed.

So, what would be the semantic of (if it were allowed)
	REGISTER [email-masked]
	To: [email-masked]
	Contact:@63.64.250.84

What I want this to mean is "Within the registrar "softarmor.com" there is
an identity "dwillis". Calls directed to this identity which have a "To:"
value of [email-masked] should be diverted to @63.64.250.85". The
registration being changed is the one for the identity
"[email-masked]", NOT the identity "[email-masked]".

This would further imply:

1) Mimicing today's behavior would require moving to To: value to the
request-URI. That is:
	REGISTER [email-masked]
	Contact:@63.64.250.84
   would, in the absence of other registrations and rules, forward any
INVITE with a request-URI of [email-masked] to the UAS @63.64.250.84

2) Traditional behavior would occur with a To: which matches the request-URI
iff the proxy/registrar does not offer To: field matching.

The other question is, what would the implications be for authentication?
Essentially, we would be saying that the registration target is the body of
the request-URI, not the body of the To: I find this far more consistent
with the semantics of INVITE and OPTIONS than the current approach is.

--
Dean

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 03 May 2000 18:24:16 -0400

> "[email-masked]", NOT the identity "[email-masked]".

This is not the semantics of REGISTER as they are today; I would be
unfortable changing the semantics like this because a user portion has
been added to the REGISTER request URI. A proxy would have very
different rules for routing depending on how the registration looked.

If you want non-standard routing, have the clients or administrators
upload CPL or CGI scripts to do these things.

-Jonathan R.