Subject: Re: A few questions on REGISTER

From: [email-masked]
Date: Thu, 23 Sep 1999 16:24:39 +0530

Jonathan Rosenberg <[email-masked]> on 09/23/99 10:30:29 AM

jonathan> Your suggestion would require the registrar to keep lists of CSeq
and
jonathan> CallID values, and its not clear when the registrar would be able
to
jonathan> destroy them (remember, there can be different Call-IDs for each
jonathan> registration, as they may originate from different hosts). Since
the
jonathan> ordering cannot be guaranteed across Call-IDs, guaranteeing them
within
jonathan> a single Call-ID doesn't appear that useful. Furthermore, its
much
jonathan> simpler in a registrar to not have to worry about ordering;
pushing this
jonathan> burden to the UAC helps the scalability a little bit. Granted,
its not a
jonathan> major issue, but I don't see whats gained by changing this?

Well, the problem was that since we are saying (according to the RFC) that
REGISTER messages are not rejected (ie no bad request is given), then in
the case when the REGISTRAR gets two messages from a UAC (the UAC did not
wait for a reply for register), 1st one is with Expires 0 and Contact * and
the following one is Expires <xx> and Contact abc, that means the client
wanted to remove all exisitng rgistrations and start afresh.
However, if they arrive out of order, that would mean add abc to the
register list and then remove all of them - something which was not
intended, but will happen since the registrar does not care about CSeq
ordering.

So if we are saying that since the client itself did not wait for the first
response, it should be ready for unpredicatable results, then the registrar
need not worry - but I did think it would just be safer if the registrar
did.

jonathan>  There is no way for the server to inform the client of a
forceful
jonathan> deregistration before the expiry time, as we have discussed in
the past.
jonathan> The only argument put forward on the usage for this was to handle
jonathan> backups, but there seemed consensus that SRV record manipulation
was a
jonathan> much more scalable and reasonable solution to this. A large
server, with
jonathan> thousands of registrations, would have to send a lot of forceful
jonathan> unregisters, not to mention that it couldn't handle clients who
weren't
jonathan> currently registered anyway.

Well, again, a server is given an option to send something similar to URQ -
it is not mandatory,
hence it is the server's discretion to send it. This is typically useful if
a particular EPs registration has to be cancelled due to policy (and it
might not be right to wait for the EP to discover this unregistration after
the next failed operation)
And certainly very useful if we are proving a 323-SIP gateway where the GK
wants to forcibly
remove a users registration (due to say the admin removing him for some
reason), so the GK now sends a URQ to the Endpoint (EP). However, incase
the same message has to go across to a terminal which is SIP based , the
gateway has no way to convert the GK oriented URQ to something like
UNREGISTER - the EP would simply have to wait till it sends its next
INVITE.

Regds
Arjun

--
Arjun Roychowdhury @ Hughes Software Systems
Off: Prestige Opal,146 Infantry Road,Blore - 560001  Ph:+91-080-2286390/1/2

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 27 Sep 1999 00:25:19 -0400

> intended, but will happen since the registrar does not care about CSeq

If the client wants to ensure thats its registrations are ordered
correctly, it should follow the rules about not sending one after the
other. Someone has to worry about enforcing ordering. The server can do
it by rejecting out of order requests, or the client can shoulder the
burden by making sure it gets a response to one before submitting the
next. As I mentioned, pushing this function to the client seems to scale
better.
\
> the next failed operation)

Why not? Lets say the registration is forcefully expired because of
policy, but the UA is not informed. What behavior in the UA is changed
because of this expiration? (I'd like to avoid feature creep in SIP, so
unless there is an absolutely clear need with a real application, I'm
not convinced).

> UNREGISTER - the EP would simply have to wait till it sends its next

Whilst I agree that interoperability would be facilitated by this, and
that interoperability is a good thing, the argument to add features
since H.323 has them is a slippery slope. The URQ from GK to terminal
(note there is an equivalent of URQ from terminal to GK in SIP) is only
one of many messages/fields in H.323 not in SIP (consider all the
admission and bandwidth control messages in RAS). By your argument, we
should add those too to facilitate interoperability. If we do this, the
end result is nothing but a protocol that is semantically equivalent to
H.323, but different only in syntax. H.323 does what it does - we don't
need another version thats just text encoded. That is certainly not the
point of SIP. 

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: [email-masked]
URL: http://www.cs.columbia.edu/~jdrosen