4 Mar
2003
4 Mar
'03
1:36 p.m.
Dear all,
SIP is allow multiple ua to register under one uri?
How could I disable this?
I mean only one ua can login under one user account?
4 Mar
4 Mar
1:51 p.m.
Hi Benny,
Yes, several UAs can register with the same account and currently there
is no way in ser how to prevent it. Do you really need such a
restriction ? If you do that, users will be unable to register several
phones or user agents and utilize forking, for example.
regards, Jan.
On 04-03 20:36, Benny Ho wrote:
Dear all,
SIP is allow multiple ua to register under one uri?
How could I disable this?
I mean only one ua can login under one user account?
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
2:19 p.m.
Jan Janak writes:
Yes, several UAs can register with the same account
and currently there
is no way in ser how to prevent it. Do you really need such a
restriction ? If you do that, users will be unable to register several
phones or user agents and utilize forking, for example.
yes, i agree that allowing many uas to register the same uri is very
useful. the only problem that i see in ser regarding it is that ser
doesn't yet implement sequential forking based on the q value. it would
we great if first my sip ua would ring and it that times out, then my
mobile phone would ring.
-- juha
3:06 p.m.
At 02:19 PM 3/4/2003, jh(a)lohi.eng.song.fi wrote:
Jan Janak writes:
I put it on our long-term to-do list. I'm thinking of some lookup filters
like lookup("table", "q<.5") ... t_on_negative("1"); ...
reply_route[1] { lookup("table", "q>=.5") ...
-jiri
Yes, several UAs can register with the same
account and currently there
is no way in ser how to prevent it. Do you really need such a
restriction ? If you do that, users will be unable to register several
phones or user agents and utilize forking, for example.
yes, i agree that allowing many uas to register the same uri is very
useful. the only problem that i see in ser regarding it is that ser
doesn't yet implement sequential forking based on the q value. it would
we great if first my sip ua would ring and it that times out, then my
mobile phone would ring.
3:24 p.m.
Jiri Kuthan writes:
I put it on our long-term to-do list. I'm thinking
of some lookup filters
like lookup("table", "q<.5") ... t_on_negative("1");
...
reply_route[1] { lookup("table", "q>=.5") ...
that could be a good start although it may be hard to control the
granularity of q values users are using.
-- juha
5:19 p.m.
At 03:24 PM 3/4/2003, jh(a)lohi.eng.song.fi wrote:
Jiri Kuthan writes:
Well -- that's imho solely user's responsibility to assign q properly
in his phone, or in his web application. He needs to know what the
threshold value is, and assign priorities to his devices then.
-Jiri
I put it on our long-term to-do list. I'm
thinking of some lookup filters
like lookup("table", "q<.5") ... t_on_negative("1");
...
reply_route[1] { lookup("table", "q>=.5") ...
that could be a good start although it may be hard to control the
granularity of q values users are using.
5:44 p.m.
Jiri Kuthan writes:
Well -- that's imho solely user's
responsibility to assign q properly
in his phone, or in his web application. He needs to know what the
threshold value is, and assign priorities to his devices then.
yes. we would then need to tell to the users that we support
so-and-so many different q value ranges and what the limit values are.
of course it would be nicer if the proxy could automatically sort the
contacts into a priority list and then try one level at a time from
highest to lowest without any effect in the configuration file.
by the way, now if the contact doesn't have any q value, ser seems to
use default = 0.0. 0.5 might be a better default, since it would allow
uas to place them selves both higher and lower than the default.
-- juha
6:03 p.m.
On 04-03 18:44, jh(a)lohi.eng.song.fi wrote:
by the way, now if the contact doesn't have any q
value, ser seems to
use default = 0.0. 0.5 might be a better default, since it would allow
uas to place them selves both higher and lower than the default.
It can be configured, registrar has default_q parameter which is
default q value multiplied by 1000 (so set it to 500 for default
q=0.5).
regards, Jan.
7950
days inactive
7950
days old
7 comments
4 participants
participants (4)
-
Benny Ho -
Jan Janak -
jh＠lohi.eng.song.fi -
Jiri Kuthan