Subject: RE: [SIP] Informing UA after network initiated deregistration?

From: Baniel Uri-CUB001 <[email-masked]>
Date: Sun, 1 Apr 2001 08:33:31 -0500

What you guys say in this mail thread mostly makes sense.

[1] It is a good catch to notice that a user may actually "spawn" other user
entities. 
I would say that from credentials and services perspectives we may want to
have a "root" profile for the subscriber (which mostly contained his
credentials and some basic identifiers),
as well as a "sub profile" for each of this possible spawned entities. These
sub profiles would define the limits and capabilities that each of this
entities is allowed to have/use.

[2] Incoming/outgoing (or if you will in PSTN terms
originations/terminations) is more than helpful. It is essential to make
this distinction, even giving that in the SIP world you seemingly have the
ability to collapse it to just invitation to a multicast/unicast conference.
As you, Dean, hinted there may be all kind of situations in which we may
loose lots of essential information regarding the network behavior as well
as the end points if we obscure everything to be regarded as just
Invitation.

[3] I still like to discuss (under a new mail thread with a different
subject line) the very sensitive issues of a 3G mobile being able to bypass
the IMS network by getting VOIP services from an external network (via the
Access and the Packet Switch networks). If I remember correctly, it was
brought up as a side affect discussion regarding the case of a stolen mobile
in context of Informing UA after network initiated deregistration.

[4]My understanding is that in Minneapolis it has been decided/approved to
Inform a UA after network initiated deregistration. My questions to you guys
are:
[4.1] Has it been decided to go for implicit subscription for notification
in the Registration request? or to specify it in a dedicated header?
[4.2] Has any distinction been made between 'administrative' network
initiated deregistration to 'reg. interval timer expiration' network
initiated deregistration?
(in the 3G cellular world there are possible rational for making these
distinction, but let's keep it for later mails on the topic)

Uri

-----Original Message-----
From: Dean Willis [mailto:[email-masked]]
Sent: Saturday, March 31, 2001 7:29 PM
To: [email-masked]
Cc: Baniel Uri-CUB001; 'Bob Penfield'; Sriram Parameswar; 'Romeo Zwart';
'Stephen Terrill'; 'Igor Slepchin'; 'William Marshall'; Chen
Bonnie-BCHEN1; Xu Lang-LXU1; sip
Subject: Re: [SIP] Informing UA after network initiated deregistration?

Interesting point. One might take it even further --  the user may be
represented by multiple identities, each of which may be participating in
one or more sessions, each of which may have been instantiated by the user,
another participant in the session, or by a non-participating third party.

Some devices may be only be able to originate invitations. Some may be able
only to respond to invitations. Some may do both, or their abilities may be
dictated by the set of identities involved in the given context. Some
devices will support multiple identities simultaneously. Others will not.

One might choose to model the "meet me call" as a unique identity,
instantiated for the duration of the "call", which participates in numerous
"call legs" on a pairwise basis with each of the other participants. I
believe a similar technique can be applied to all multiparty calling modes.
In fact, I think Sparks and Campbell did an internet-draft illustrating that
point.

But "inbound" vs "outbound" is still a useful distinction, inasmuch as one
or the other of the parties at each end of each call leg performed the
signaling that instantiated that leg -- and the other party reacted to that
signal. To paraphrase Einstein, I refuse to embrace a conceptuality without
causality . . .

--
Dean

----- Original Message -----
From: "Brian F. G. Bidulock" <[email-masked]>
To: "Dean Willis" <[email-masked]>
Cc: "Baniel Uri-CUB001" <[email-masked]>; "'Bob Penfield'"
<[email-masked]>; "Sriram Parameswar"
<[email-masked]>; "'Romeo Zwart'" <[email-masked]>;
"'Stephen Terrill'" <[email-masked]>; "'Igor Slepchin'"
<[email-masked]>; "'William Marshall'" <[email-masked]>;
"Chen Bonnie-BCHEN1" <[email-masked]>; "Xu Lang-LXU1"
<[email-masked]>; "sip" <[email-masked]>
Sent: Saturday, March 31, 2001 6:48 PM
Subject: Re: [SIP] Informing UA after network initiated deregistration?

> Dean,
>
> People on this WG say how SIP is so different from
> PSTN; yet, you cling to this artificial distinction
> between inbound and outbound call?  These are circuit
> switched network concepts.
>
> Clinging to the concept of inbound and outbound is
> why the PSTN had so much difficulty with services
> like Meet-Me conferencing, Call Waiting and other
> such stuff.
>
> Consider that the user is a participant in a
> communications session whose establishment is
> independent of its participants.
>
> Being able to give out invitations without also being
> able to receive them severly limits the scope of
> dependencies between sessions which can be expressed
> by the protocol.  Proxies wishing to provide this
> wider scope of service offering should be permitted
> to track registration and deregistration as it affects
> the offering of this wider service range than just
> incoming and outgoing.
>
> --brian
>
> Dean Willis wrote:                              (Sat, 31 Mar 2001
17:58:45)
> >
> > I really don't think I understand this whole argument.
> >
> > When I turn on the SIP phone on my desk, it sends register messages to
three
> > different registrars.
> >
> > Optionally, each registration could be authenticated with separate
> > credentials. None of those credentials has anything whatsover to do with
> > authorizing my phone to talk to the network.
> >
> > And NONE of those registrations have anything whatsoever to do with
whether
> > that phone can make a call. They influence only INBOUND calls to the
> > identities associated with the registrations.
> >
> > Whether or not the phone has registered HAS ABSOLULTELY NO IMPACT on
whether
> > that phone has "access" to the network. In fact, it has to have access
to
> > the network BEFORE it can register. Registration is an application, not
an
> > access control mechanism.
> >
> > I think we're getting layer 2, 3, and 4 horribly confused.
> >
> > --
> > Dean
> >
>
> --
> Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
> [email-masked]    ¦ world; the unreasonable one persists in  ¦
> http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
>                         ¦ Therefore  all  progress  depends on the ¦
>                         ¦ unreasonable man. -- George Bernard Shaw ¦
>

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to 
[email-masked] with "subscribe" in the body.

---

From: Baniel Uri-CUB001 <[email-masked]>
Date: Mon, 2 Apr 2001 05:49:30 -0500

First, it is no one's hobby to change and complicate the spec every other day. Even in a case when a change/addition seems to be in place, I wouldn't want to be the programmer, who will have to go backward and update a SIP client/server code. (Maybe we should assume this work as a punishment to the person, who offers the change, and we will make him/her do it in assembly after the second pass of compilation to the original code)

Anyhow one question is whether a Subscribe-Notify for a deregistration event may be on a registration cycle basis or per subscriber profile. For instance, say the Chief Scientist of dynamicsoft is waiting for a very important incoming call on his SIP phone and the call never comes. He may be upset to realize it happened (or as a matter of fact, did not happen), because his SIP phone had been deregistered (for whatever reason) already 20 minutes ago, and he had no idea about it.

I totally agree that if the notification for deregistration is on a per subscriber basis, then the subscription may be done either by filling in a web page application form and shipping it off to the server, or by meeting the admin at the local pub and ask him/her to do it as a favor.

If/when the notification for deregistration is on a per registration cycle basis, then if the client could hint the registrar (as part of the Registration request) about the wish to be notified either by winking his eye or by any other mean it could have been helpful.

It is true that the SUBSCRIBE-NOTIFY mechanism is already out there, and now implementers may want to use some creativity in utilizing it, rather than changing the existing spec.

Uri.

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Monday, April 02, 2001 2:37 AM
To: 'Baniel Uri-CUB001'; 'Dean Willis'; [email-masked]
Cc: 'Bob Penfield'; Sriram Parameswar; 'Romeo Zwart'; 'Stephen Terrill';
Igor Slepchin; 'William Marshall'; Chen Bonnie-BCHEN1; Xu Lang-LXU1; sip
Subject: RE: [SIP] Informing UA after network initiated deregistration?

> From: Baniel Uri-CUB001 [mailto:[email-masked]]
> Sent: Sunday, April 01, 2001 9:34 AM
> To: 'Dean Willis'; [email-masked]
> Subject: RE: [SIP] Informing UA after network initiated 
> deregistration?
>

More headers in registrations. I love it. When are we going to get the "by
the way, I am interested in knowing when I have exactly  15 dollars left in
my account, the one I set up with Mastercard". I propose:

Mastercard-Balance-Subscription: 15;currency=dollar

Just in case there are those who like this idea (and since sarcasm by email
is sometimes missed) - no, we are NOT having a new header in registrations.

Some have debated whether or not the presence spec allows or disallows
"implicit" registrations. This fits into the growing category of things that
"the SIP spec doesn't, nor shouldn't, say". SIP for presence specifies a way
to create subscriptions, and a way to generate notifications for
subscriptions. It does not say that when you build a system, the ONLY way to
get subscriptions in there is to use the SUBSRIBE method. I think a web form
is a perfectly fine way to create subscriptions. We then use our
notification mechanisms to generate notifies for them. How the lifetimes of
these subscriptions are managed is also an implementation issue.

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

---

From: Baniel Uri-CUB001 <[email-masked]>
Date: Tue, 3 Apr 2001 17:10:43 -0500

Bob

I think I said it already, but just in case, I totally agree!
Another way of doing it is per Jonathan's suggestion, which is... any other
way, which would not affect the existing spec.
Specifically in a world of subscriptions and users/subscribers profiles
(such as for instance the cellular 3G world) the subscription for
notification in the event of unregisteration (deregistration in the 3GPP
Nomen clature) may be done in profile update time, for instance when the
admin happens to be also your local neighborhood bar tender. (No one has
laughed before, so I have no choice but to repeat my silly joke)

I am trying to push this (with Bonnie Chen and Mimi Xu) through the 3GPP
channels, so there will be alignment with the 'pure' SIP.

Thanks,

Uri.

===========================================
[email-masked], 
Tel: (847) 632 4616; Fax: (847) 632 3963; 
===========================================

> From: Bob Penfield [mailto:[email-masked]]
> Sent: Monday, April 02, 2001 12:46 PM
> To: Jonathan Rosenberg; 'Baniel Uri-CUB001'; 'Dean Willis';
> [email-masked]
> Cc: Sriram Parameswar; 'Romeo Zwart'; 'Stephen Terrill'; Igor 
> Slepchin;
> 'William Marshall'; Chen Bonnie-BCHEN1; Xu Lang-LXU1; sip
> I don't think that it is necessary to add more headers. The 
> Event header
> should be used for implicit subscription just like it is used 
> for explicit
> subscriptions.
> 
> Bob
> d:-)
> 
> 
> Robert F. Penfield
> Chief Software Architect
> Acme Packet, Inc.
> 130 New Boston Street
> Woburn, MA 01801
> (781) 933-6166
> [email-masked]
> 
> From: "Jonathan Rosenberg" <[email-masked]>
> To: "'Baniel Uri-CUB001'" <[email-masked]>; "'Dean Willis'"
> <[email-masked]>; <[email-masked]>
> Cc: "'Bob Penfield'" <[email-masked]>; "Sriram Parameswar"
> "'Stephen Terrill'" <[email-masked]>; "Igor Slepchin"
> Sent: Monday, April 02, 2001 3:36 AM
> > the way, I am interested in knowing when I have exactly  15 
> dollars left
> in
> > Just in case there are those who like this idea (and since 
> sarcasm by
> email
> > "implicit" registrations. This fits into the growing 
> category of things
> that
> > "the SIP spec doesn't, nor shouldn't, say". SIP for 
> presence specifies a
> way
> > subscriptions. It does not say that when you build a 
> system, the ONLY way
> to
> > get subscriptions in there is to use the SUBSRIBE method. I 
> think a web
> form
> > notification mechanisms to generate notifies for them. How 
> the lifetimes
> of

---

From: "Sriram Parameswar" <[email-masked]>
Date: Wed, 4 Apr 2001 08:34:58 -0500

Uri,

Interesting! sorry for being a little dense - what exactly are you looking
to push in 3GPP? I ask because the implicit registration stuff (see my
original email) is already in 3GPP via a contribution from Nokia. (By the
way I did get the joke - the first time!).

Regards,

Sriram

__________________________________________
Sriram Parameswar              Phone: 972-685-8540
Wireless IP MultiMedia (WIPMM)   Fax: 972-685-3563
Nortel Networks, Richardson USA  Email: [email-masked]

-----Original Message-----
From: Baniel Uri-CUB001 [mailto:[email-masked]]
Sent: Tuesday, April 03, 2001 5:11 PM
To: 'Bob Penfield'; Jonathan Rosenberg; Baniel Uri-CUB001; 'Dean
Willis'; [email-masked]
Cc: Parameswar, Sriram [NGB:B658:EXCH]; 'Romeo Zwart'; 'Stephen
Terrill'; Igor Slepchin; 'William Marshall'; Chen Bonnie-BCHEN1; Xu
Lang-LXU1; sip
Subject: RE: [SIP] Informing UA after network initiated deregistration?

Bob

Thanks,

Uri.

---

From: Baniel Uri-CUB001 <[email-masked]>
Date: Wed, 4 Apr 2001 09:52:13 -0500

Well, sadly I am not perfectly familiar with the spec process, but there
were few things there I did not like in the Nokia contribution, and I am
proposing some changes.
I think Nortel customers would be happier as well if they get a product,
which is based on specifications, which make sense.
Bonnie is our spec person, and she is the one who will make sure that things
which should be heard and viewed will.
I am aware of having a well organized process for contributions, reviews
etc. Thus I am trying to get my proposals via this process with Bonnie's
help.
 
Uri
 
========================================== 
[email-masked], 
Tel: (847) 632 4616; Fax: (847) 632 3963; 
=========================================== 

-----Original Message-----
From: Sriram Parameswar [mailto:[email-masked]]
Sent: Wednesday, April 04, 2001 8:35 AM
To: 'Baniel Uri-CUB001'; 'Bob Penfield'; Jonathan Rosenberg; 'Dean Willis';
[email-masked]
Cc: 'Romeo Zwart'; 'Stephen Terrill'; Igor Slepchin; 'William Marshall';
Chen Bonnie-BCHEN1; Xu Lang-LXU1; sip
Subject: RE: [SIP] Informing UA after network initiated deregistration?

Uri, 

Regards, 

Sriram 

-----Original Message----- 
From: Baniel Uri-CUB001 [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Tuesday, April 03, 2001 5:11 PM 
To: 'Bob Penfield'; Jonathan Rosenberg; Baniel Uri-CUB001; 'Dean 
Willis'; [email-masked] 
Cc: Parameswar, Sriram [NGB:B658:EXCH]; 'Romeo Zwart'; 'Stephen 
Terrill'; Igor Slepchin; 'William Marshall'; Chen Bonnie-BCHEN1; Xu 
Lang-LXU1; sip 
Subject: RE: [SIP] Informing UA after network initiated deregistration? 

Bob 

Thanks, 

Uri. 

> From: Bob Penfield [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> > > From: Baniel Uri-CUB001 [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> > http://www.cs.columbia.edu/~jdrosen
<http://www.cs.columbia.edu/~jdrosen>          PHONE: (973) 952-5000 
> > http://www.dynamicsoft.com <http://www.dynamicsoft.com>  
> > 
> >