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?
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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
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
At 02:19 PM 3/4/2003, jh@lohi.eng.song.fi wrote:
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.
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
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
At 03:24 PM 3/4/2003, jh@lohi.eng.song.fi wrote:
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.
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
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
On 04-03 18:44, jh@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.
-
Benny Ho -
Jan Janak -
jh＠lohi.eng.song.fi -
Jiri Kuthan