[Serusers] Multiple Registrations

Greg Fausak greg at august.net
Wed Mar 19 21:19:26 CET 2003


I agree hat the feature is very useful.  However, from
an ISPs point of view, it may be desireable to restrict it.
Most of our customers are only permitted one sip phone
connection.  Same sort of thing with dialup accounts, it is possible for
radius to authenticate multiple connections, but, an ISP may only
wish to allow one dialup connection...this was difficult to do with
radius for quite a long time.  I know I would like to restrict my
customers to just one connection.

Is it possible to call a deregistration function when the register
Perhaps a delete(id) followed by the save(id).  In this way, it would be
guaranteed to only have one registration by a single customer.  E.g.:

		log("ID was not already registered, ignoring");

Greg Fausak

PS. Is anyone going to San Jose (VON) the beginning of April?

> -----Original Message-----
> From: serusers-admin at lists.iptel.org 
> [mailto:serusers-admin at lists.iptel.org] On Behalf Of Jan Janak
> Sent: Wednesday, March 19, 2003 2:02 PM
> To: Juha Heinanen
> Cc: Ricardo Villa; serusers at lists.iptel.org
> Subject: Re: [Serusers] Multiple Registrations
> I agree with Juha. In my opinion possibility to register and use more
> than one contact is very nice feature of SIP and it shouldn't 
> be restricted
> this way.
> It is also possible that user agents will register more than one
> contacts transparently, they may use different port numbers 
> for presence
> and instant messaging (SUBSCRIBE,NOTIFY,MESSAGE) and different port
> number for voice (INVITE, ACK, BYE). Restricting ser to just 
> one contact
> will prohibit such user agents because our registrar doesn't support
> callee preferencies yet. On the other hand right now I am not aware of
> any user agents using multiple ports this way.
> Also user agents capabable of simultaneous use of TCP and UDP 
> might want
> to register 2 contacts, one for UDP and one for TCP transport.
> If I understood your email correctly, the only problem with 
> unregistered
> user agents when IP address changes is that another user agent (which
> was assigned IP address of the previously unregistered user 
> agent) will
> receive calls not targeted to him. Something like this:
> 1) UA1 with IP1 registers
> 2) hang up, UA1 is still registered with IP1
> 3) another user dials in, gets previsously freed IP1 and starts UA2
> 4) UA2 registers (with different address of record)
> 5) UA3 invites UA1 (which is offline already) but the INVITE will be
>    sent to UA2 (which has now IP1)
> I don't know if there is any time window in which a 
> previsously assigned
> IP address must not be reassigned, but I assume no.
> Such a situation cannot be completely avoided, but the 
> probability that
> something like this will happen can be significantly 
> decreased by using
> reasonably short expires intervals. Morover I could extend 
> registrar to
> either: 1) refuse contacts with too long expires parameter
>         2) force shorter expires value if the value provided by user
> 	   agent is too long.
> Shorter expires value will, of course, increase traffic.
> What do you think ? Maybe limited expires value could solve your
> problem ?
> In regards to q parameter: q is preference of contacts (see RFC3261).
> This parameter is provided by user agents when registering 
> contacts and
> can be assigned value from 0.00 to 1.00, where 0 means the 
> lowest and 1
> the highest priority among contacts registered for a single address of
> record.
>   Jan.
> On 19-03 17:02, Juha Heinanen wrote:
> > Ricardo Villa writes:
> > 
> >  > You are absolutely right about  "exiting" the UA agent 
> (our UA agent works
> >  > fine).  But not everybody in the network is going to go 
> through the menu and
> >  > click "log out" every time.  Some people will close it, 
> or some people might
> >  > drop their dial-up connection and redial again right away.
> > 
> > even if you close the UA window, it should still 
> unregister.  droping of
> > connection wihtout the user doing so is of course another thing that
> > very little can be done about.
> > 
> >  > I am just trying to eliminate this scenario as a 
> potential problem.
> > 
> > but at the same time you are removing an extremely valuable 
> feature of
> > sip, i.e., allowing several parallel registrations and 
> forking to them.
> > 
> > may be i didn't understod what the problem actually is.  if 
> i have two
> > registrations for the same uri and one of them is not valid anymore,
> > then, due to forking, the valid one will receive the 
> requests anyhow.
> > 
> > -- juha
> > 
> > _______________________________________________
> > Serusers mailing list
> > serusers at lists.iptel.org
> > http://lists.iptel.org/mailman/listinfo/serusers

More information about the sr-users mailing list