Subject: [Sip] SIP de-registration

From: [email-masked]
Date: Wed, 8 Jan 2003 11:41:42 +0000

All

Is it valid to reject a de-registration request?

For example 'If a  SIP terminal sends a de-registration request to a network
while it still has an active session established, and the network
rejects this request , is this correct behaviour.

Jo Higgens
Orange UK

*******************************************************************************
Important.
Confidentiality: This communication is intended for the above-named person and
may be confidential and/or legally privileged. Any opinions expressed in this
communication are not necessarily those of the company. If it has come to you
in error you must take no action based on it, nor must you copy or show it to
anyone; please delete/destroy and inform the sender immediately.

Monitoring/Viruses
Orange may monitor all incoming and outgoing emails in line with current
legislation.  Although we have taken steps to ensure that this email and
attachments are free from any virus, we advise that in keeping with good
computing practice the recipient should ensure they are actually virus free.

Orange PCS Limited is a subsidiary of Orange SA and is registered in England No
2178917, with its address at St James Court, Great Park Road, Almondsbury Park,
Bradley Stoke, Bristol BS32 4QJ.
*******************************************************************************

_______________________________________________
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: Prasanna Venkatesh <[email-masked]>
Date: Wed, 08 Jan 2003 17:20:38 +0530

Any registrar can reject a de-registration request anytime.  But rejecting a
de-registration for the fact that a session is active is a local
implementation.  In general the registration is used to locate an entity and
theoritically after the session is established, the registration is
immaterial.
Cheers,
Prasanna

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
[email-masked]
Sent: Wednesday, January 08, 2003 5:12 PM
To: [email-masked]
Subject: [Sip] SIP de-registration

All

Jo Higgens
Orange UK

****************************************************************************
***
Important.
Confidentiality: This communication is intended for the above-named person
and
may be confidential and/or legally privileged. Any opinions expressed in
this
communication are not necessarily those of the company. If it has come to
you
in error you must take no action based on it, nor must you copy or show it
to
anyone; please delete/destroy and inform the sender immediately.

Monitoring/Viruses

Orange PCS Limited is a subsidiary of Orange SA and is registered in England
No
2178917, with its address at St James Court, Great Park Road, Almondsbury
Park,
Bradley Stoke, Bristol BS32 4QJ.
****************************************************************************
***

---

From: "Dean Willis" <[email-masked]>
Date: Wed, 8 Jan 2003 16:54:53 -0600

Prasanna said:
>Jo said:
>> For example 'If a  SIP terminal sends a de-registration 
>> request to a network while it still has an active session 
>> established, and the network rejects this request , is this 
>> correct behaviour.

> Any registrar can reject a de-registration request anytime.  
> But rejecting a de-registration for the fact that a session 
> is active is a local implementation.  In general the 
> registration is used to locate an entity and theoritically 
> after the session is established, the registration is 
> immaterial. Cheers, Prasanna

I believe Prasanna is correct here, in general. SIP does not view REGISTER
as a "log on for service" -- rather, it is an address binding function that
makes a temporary association between a (presumbaly temporary) local
instance address and a (presumbaly long-lived) address-of-record. In
particular, SIP does not require that a UA have a current registration or
execute a REGISTER transaction before executing an INVITE transaction
request.

3GPP (and consequently 3GPP2) have however layered some extra roles on top
of the SIP REGISTER transaction. In these environments, REGISTER is a sort
of "log on" operation in that it establishes the security association
between a client and registrar that will be used for (some) future
interactions between that client and registrar. 

Consequently, answering the question that Jo asked requires knowing whether
the 3GPP system discards the security association established by a REGISTER
request if the registration created by that request is destroyed.

The answer, unfortunately, is "I don't know. The IETF doesn't know. Maybe
somebody more conversant with that particular bit of 3GPPP knows (and
they're probably reading this)." But in short, it is an environment specific
question related to a specific implementation having done something just a
bit different from generic SIP. In straight SIP, the registrar can terminate
a registration without impacting any sessions that a UA is participating in.
In fact, the registrar usually doesn't know or care whether a UA has or will
ever have participated in a session.

My guess is that this would probably be implementation-depdendent in the
S-CSCF, and that if I were designing an S-CSCF, I'd have it not discard
SA-state until after all transacations on that SA had terminated. A second
choice would be to design it to use network-initiated-termination procedures
to force-terminate any sessions before discarding the security associations.

--
dean

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 14 Jan 2003 18:39:29 -0500

Catching up after a week of "real work":

I have one bit to add to what Dean is saying. If a registrar should
reject a request because, say, there is an "active session" and the
policy of the registrar prohibits de-registration during an active
session, you really must use an appropriate response code to have a hope
of interop. The appropriate response is a 500 (not any 500 class). The
reason is that the 500 can contain a Retry-After, informing the UA that
it should try again later. Otherwise, when the registration is rejected,
what should it do? Should it try again? When should it try again?

If, however, the intent is that the registration is accepted, but will
take affect later, that is something quite different, and would require
some standardization activity to make interoperable.

Of course, that said, I agree with Dean that the intention of REGISTER
is merely to establish an address binding, and not to be a "log in" in
the sense that it is frequently mis-interpreted.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com