Subject: [SIP] Second try : Questions about REGISTER

From: Shail Bhatnagar <[email-masked]>
Date: Mon, 01 May 2000 13:05:43 -0400

In section 16.1 of RFC2543bis there is an example of Registration. I
have
a couple of questions about this scenario. I would appreciate any
responses.

1) What would be the To header of the REGISTER that T. Watson sends to
the registrar at example.com. Would it be [email-masked] or
[email-masked] ?? As per the description in section 4.2.6, To
header
domain could be different from the domain of the Request-URI in the
REGISTER.

2) Let us say [email-masked] (From: [email-masked]) sends an INVITE to
the
proxy at bell-tel.com and the Request-URI is INVITE [email-masked].
As per the latest registration, the Contact is [email-masked], so 
the proxy at bell-tel.com rewrites the Request-URI and sends it to the
proxy at example.com - INVITE [email-masked]. Now what is the
search
key at the registrar - is it user@domain or simply user. If it is simply
user,
then domain of To header in REGISTER is meaningless. If it is
user@domain,
then To header of the REGISTER sent to the registrar at example.com must
be
[email-masked].

3) What if there already exists a user tawatson at the domain
example.com.
Should the registrar at example.com reject the registration ?? If yes,
what response code should be used ??

Thanks,
Shail

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 02 May 2000 00:57:32 -0400

> domain could be different from the domain of the Request-URI in the

Most likely [email-masked]. This is because if some UAC or proxy
wants to send a request to [email-masked], it will use DNS to find
the SIP server for example.com, and forward the request there. As a
result, watson will want to register [email-masked] with the
server for which requests to example.com will be routed. The spec does
not prohibit registering [email-masked] with example.com.
However, example.com is not likely to receive requests with domains of
bell-tel.com in the request URI.

> then To header of the REGISTER sent to the registrar at example.com must

Thats your choice. If your proxy only handles a single domain, using
user alone as a lookup key into your database is fine. If your proxy
handles multiple domains, you will want to use the complete user@host.

> what response code should be used ??

No, the new Contact would be added to the existing registration. 

-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

---

From: Shail Bhatnagar <[email-masked]>
Date: Tue, 02 May 2000 13:18:24 -0400

Jonathan, Appreciate your responses. See embedded .
Shail

> bell-tel.com in the request URI.

This is exactly my point of confusion. The text in 4.2.6 is actually
raising
more questions than answering. I cannot think of a case when a mismatch
in
the domain of To header and Request-URI would be useful. If the proxy
services
more than 2 domains, the domain in To header and Request-URI would still
be
same or may be I am missing something.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 02 May 2000 17:57:19 -0400

> same or may be I am missing something.

I think this text just requires additional clarification. There are
cases where this can work (namely, when there is specialized routing
logic at a server), but we need to give an example and the limitations.
For 99% of the applications, the domain in the request URI and To field
will be identical.

-Jonathan R.

---

From: Dean Willis <[email-masked]>
Date: Tue, 02 May 2000 17:24:49 -0500

> For 99% of the applications, the domain in the request URI and To field

True, it is unlikley that an original UAC will generate a request with
variant fields.

However, I might suggest that a mismatch between request-URI and To: field
will inevitably occur if a previous proxy in the path has applied routing
logic that results in a new request-URI being applied.

For example, let's say my work proxy forwards to my home proxy:

So an original INVITE might contain:

INVITE sip:[email-masked] SIP/2.0
To: Dean Willis <sip:[email-masked]>

and after leaving the wcom.com proxy (which, based on time-of-day, forwards
to my house)

INVITE sip:[email-masked] SIP/2.0
TO: Dean Willis <sip:[email-masked]>

So the destination UAS (my trusty sip-phone) would see an INVITE in which
the request-URI does not match the To: field.

--
Dean

---

From: Shail Bhatnagar <[email-masked]>
Date: Tue, 02 May 2000 18:53:12 -0400

I was referring to REGISTER request, not to other requests.

---

From: Dean Willis <[email-masked]>
Date: Tue, 02 May 2000 18:22:29 -0500

Pardon me for not carrying the thought out. I committed premature sending
again. Need keyboard viagra or something.

Ok, we've seen from my previous example how an INVITE with a To: that does
not match the request-URI can show up at my home proxy.

What does my home proxy DO with that INVITE?

It could follow the usual wisdom, and simply process the INVITE according to
the rules applicable to the entity specified by the request-URI.

What if I wanted a little more power in my call handling? For example, I
might want my home proxy to divert calls that are To:
[email-masked] to be diverted to my cell phone, and calls that
are To: [email-masked] (calls forwarded from work) to ring my desk
phone, then be diverted to my unified messaging box if there is no answer.

This implies logic processing in the home proxy based on the value of the
To: header. How do I provision this logic?

One possibility would be to put it in the proxy's config file as a script or
action table.

What if I wanted to use dynamic registration, perhaps with a CPL upload, to
change proxy behavior?

How would I specify that one register affects a different logical target or
"To:" than another?

Two possibilities:

1) There is only one registration, and the singular uploaded CPL includes
To: differentiation logic.

2) I use a register message which indicates second logical destination in
the To: field, and have some other way of indicating a request-chaining
logic.

As Jonathan says, 99%+ of all registers will have a request-URI that matches
a To:. I think, however, there are services that have not been completely
defined which would take advantage of REGISTER messages which have different
request-URI and To: fields.

Personally, I wonder why we didn't just go ahead and include the user part
in the request-URI. This would allow my request-chaining REGISTER to be
fairly explicitly stated and solve lots of messiness.

--
Dean

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, May 02, 2000 5:53 PM
> To: Dean Willis
> Cc: Jonathan Rosenberg; SIP IETF
> Subject: Re: [SIP] Second try : Questions about REGISTER
>
>