Subject: A few questions on REGISTER

From: [email-masked]
Date: Wed, 22 Sep 1999 14:23:40 +0530

Hi,

with ref. to SIP RFC 2453

1) "Section 4.2.6 says for Cseq : Registrations for same CallID MUST have
inc. Cseq.......
However , Server does not reject out of order requests."

Somewhere else in the RFC its stated that a UAC SHOULD not send a new
REGISTER till it receives
a response to a prev. register (or a timeout, I guess)

But suppose a UAC does, contrary to the reccomendation, send a few
REGISTERs without waiting for a response,
and the Proxy receives and accepts all, then its possible the current
Registration does not reflect the latest registration sent by the client.

I realise that the UAC in the first place is not doing what it should, but
doesnt it make more sense for the Proxy to reject REGISTERs whose CSEq is
lesser than the last processed CSeq for that call ?
By allowing all REGISTERs, what is being acheived ?

2) Section 4.2.6 again:

"Registrations not refreshed after this amt. of time SHOULD be silently
discarded " (context of ttl expiring)

Is there any provision for the server to inform the client that its being
Unregd. ?
The client should be able to have a timer, which should trigger on the
returned Expires hdr from the proxy and re-register if needs be,
but can any analogy be drawn to say H323, which allows the GK to send a URQ
to the EP (especially if Keepalive is not supported by the EP(endpoint)) to
inform him of unregistration ?

Finally, a statement in 4.2.6, last para:

"The server SHOULD return the current list of registrations in the 200
response as Contact hdr fields"

I dont know how many people made the same mistake, but  I initially
interpreted this as the Server returning ALL the registrations of ALL the
registered users in the 200 response - which is why I had assumed that I
can implement the 'Current Users' list  by simply sending a REGISTER to the
server. It was later pointed out that it should only return the requesting
Users registrations and not all.
Maybe the text needs to be specific, or is it just me :-p ?

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: Thu, 23 Sep 1999 01:00:29 -0400

> By allowing all REGISTERs, what is being acheived ?

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

> inform him of unregistration ?

Since the register response contains the updated expires header, this
tells the client when the server will delete the registration. The
client should use this expires header as the timer to trigger a
registration refresh (actually, to be safe, it should refresh a little
sooner). 

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

> Maybe the text needs to be specific, or is it just me :-p ?

Certainly this can be clarified. Sending everyone elses registrations
seems a bit of a security hole, so this is definitely not the intention.

-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