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 PROTECTED] 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)?
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.
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!)
_______________________________________________
Sip-implementors mailing list
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
