Subject: [Sip] Un Register notification

From: [email-masked]
Date: Fri, 9 Sep 2005 12:47:50 -0400

Hi,

If phone does not support RFC 3680 (Event package for Registration), how 
will Call controller notify the phone that your registration had expired 
and you need to re-register ,is there any response for that.

Use case is like that we want every phone to register first before making 
calls.
If a phone does not register and send INVITE with all credentials, 
although it is a valid user but we will not allow him to make call, we 
want to notify him that he needs to register to make calls.

I know RFC 3680 supports this notification but if phone does no tsupport 
that RFC, how can phone be notified?

Thanks,
Udit
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Dean Willis <[email-masked]>
Date: Mon, 12 Sep 2005 13:45:05 -0500

This should probably be kept to sip-implementors, but "REGISTER abuse" 
is such a common design misconcept that I'll keep SIP on the reply 
here.

On Sep 9, 2005, at 11:47 AM, [email-masked] wrote:

>
> Hi,
>
> If phone does not support RFC 3680 (Event package for Registration), 
> how will Call controller notify the phone that your registration had 
> expired and you need to re-register ,is there any response for that.
>

No, there is no RFC-defined way to notify a phone that its registration 
has expired other than the defined-by-RFC-way to notify a phone that 
its registration has expired, RFC 3680. We try not to redundantly say 
things twice.

> Use case is like that we want every phone to register first before 
> making calls.

Why? What does registration state have to do with the ability to make a 
call (other than possibly using REGISTER as a method for obtaining a 
GRUU that will be used as the Contact: in the call)?

> want to notify him that he needs to register to make calls.

In "normal" SIP environs, REGISTER is used only to set a contact for 
calls to be routed TO the phone, and has nothing to do with calls 
coming FROM the phone. Are you just being difficult (like the IMS 
people who actually have a transitive authentication mechanism keyed 
off REGISTER that they built that way BECAUSE they got SIP REGISTER 
confused with GSM Registration -- after all, the names are very 
similar), or is there some real reason for this requirement?

> I know RFC 3680 supports this notification but if phone does no 
> tsupport that RFC, how can phone be notified?
>

That's a little like like asking "How do we NOTIFY something that 
doesn't support NOTIFY and/or hasn't told us it wants to be notified?", 
but I suppose you could send a 403 response with a reason text of 
"Dude, we're a little odd and insist you gotta register first!" in 
response to the INVITE. There might even be a more appropriate 
400-class response, but none comes immediately to mind.

Or, you could proxy the INVITE to a voice-response unit that would then 
send a 200 OK and connect the hapless victim to a voice stream that 
would explain to him in clear language that your service is designed in 
a non-standard way and he should take his business elsewhere, or 
perhaps that he might want to go ahead and force his phone to REGISTER 
to you if he wants to continue using this service.

Or you might look at 3GPP 24.228 and 24.229. I'm sure they've worked 
out what a P-CSCF should do if it gets an INVITE from an 
un-authenticated client (and since they only authenticate REGISTER 
transactions that equates to your problem as I understand it).

--
Dean (NOT acting as chair!)

---

From: Dean Willis <[email-masked]>
Date: Tue, 13 Sep 2005 22:23:20 -0500

On Sep 13, 2005, at 8:22 AM, Theo Zourzouvillys wrote:
>
>
> few reasons of the top of my head that the IMS probably chose to do 
> this:
>
>  * to assign an S-CSCF to the user, which is needed for further 
> messages

Only because they chose to assign the S-CSCF at registration time, 
because that's when GSM assigns the MSC. There are other large SIP 
networks quite happily using a different serving-proxy binding scheme.

>  * for grabbing the filter criterion from the HSS, which are needed to 
> route
>    further messages.

See above.

>  * roaming, where the P-CSCF is located in a visited network - for 
> ensuring
>    the user is allowed to roam with that identity.

Per-request authorization in the home network (or another "strong 
identity mechanism") could provide the same, without requiring the 
transitive-trust-over-IPSEC model of IMS, where the P-CSCF learns (from 
the REGISTER response) about allowed identities and routes, and 
proceeds to enforce them on behalf of the home network. It could be 
argued that this model induces several of the most significant attack 
opportunities on IMS, and it certainly wouldn't have passed IESG 
security review. For example, any compromise of operational security in 
the visited network (like a bad employee in a foreign network who can't 
be prosecuted by the home network operator) opens the window for 
difficult or impossible to track toll fraud. Telco networks run on 
inter-company trust, and it usually works great -- but it only takes 
one or two bad apples to create a big mess. Hence the need for IETF to 
define limited-scope "P-header" extensions for IMS -- we think they're 
suitable for use in heavily-insured limited-liability environments, but 
we're not quite ready to trust them with our secret Swiss account 
numbers or our secret formula for predicting stock prices and Superbowl 
winners (Hint: It won't be Dallas this year).

> I initially thought "what the hell" when reading through the IMS spec, 
> but am
> now starting to appreciate the reasons things have been done the way 
> they
> have while deploying a scarily large SIP network while keeping 
> resources to a
> sane level
>
>

No doubt, IMS is now quite deeply thought-out and documented in amazing 
detail. It's a huge body of work, with a lot of clever, even brilliant 
thinking having gone into it. Of course, it contains a few things I 
would have done differently . . . then again, so do most of the plays 
of William Shakespeare, and I'm not a noted playwright.

But like Shakespeare's plays (as well as those of lesser mortals) 
usually do, it will take a few productions to iron out the bugs in IMS. 
We're still waiting for that first off-Broadway show and hoping not too 
much rotten fruit gets thrown at the cast.

--
Dean