Hi all,
I would like to add users to the MySql database of SER using an ODBC link.
What I'm asking is not the way to do this, since I already have it working, but if this method is correct and would not cause problems later.
I'm writing in "subscriber" table
username domain password email
So I'm missing all the "strange stuff" like phplib_id, ha1, ha1b
Any suggestion will be greatly appreciated, as usual!
Hello,
On 10-11 16:01, Alessio Focardi wrote:
Hi all,
I would like to add users to the MySql database of SER using an ODBC link.
What I'm asking is not the way to do this, since I already have it working, but if this method is correct and would not cause problems later.
It is correct.
I'm writing in "subscriber" table
username domain password email
So I'm missing all the "strange stuff" like phplib_id, ha1, ha1b
phplib_id is a unique key for the php library (used by serweb).
ha1 contains an MD5 hash of username domain and password. You can use gen_ha1 utility to generate it. ha1b is the same only the username is in form username@domain.
ha1 and ha1b columns are used only if you have calculate_ha1 parameter of auth_db module off.
Jan.
Hello Jan,
What I'm asking is not the way to do this, since I already have it working, but if this method is correct and would not cause problems later.
JJ> It is correct.
So I can go on, it seems me ....
I'm writing in "subscriber" table
JJ> phplib_id is a unique key for the php library (used by serweb).
Is that used by the server ? is the only data that I can't write using ODBC from a Windows pc.
JJ> ha1 contains an MD5 hash of username domain and password. You can use JJ> gen_ha1 utility to generate it. ha1b is the same only the username is JJ> in form username@domain.
JJ> ha1 and ha1b columns are used only if you have calculate_ha1 JJ> parameter of auth_db module off.
That's not my case ....
I would like to ask another question to everyone involved in SER:
I'm experimenting with Grandstream IP Phones, that are allowing only numbers for calling out.
That'is a big problem when you want to call someone outside your domain .... for instance 11111111@iptel.org
I think that the right way to handle this situation is to use a numeric prefix for every domain that our ser proxy should convert to domain names for uri rewriting.
Finally the question:
Is a prefix/domain standard conversion table avalaible somewhere ?
something like ...
addline 1-747-474 (real prefix, I guess).
Again, tnx !
On 10-11 16:20, Alessio Focardi wrote:
Hello Jan,
What I'm asking is not the way to do this, since I already have it working, but if this method is correct and would not cause problems later.
JJ> It is correct.
So I can go on, it seems me ....
I'm writing in "subscriber" table
JJ> phplib_id is a unique key for the php library (used by serweb).
Is that used by the server ? is the only data that I can't write using ODBC from a Windows pc.
It is used by serweb.
I would like to ask another question to everyone involved in SER:
I'm experimenting with Grandstream IP Phones, that are allowing only numbers for calling out.
That'is a big problem when you want to call someone outside your domain .... for instance 11111111@iptel.org
I think that the right way to handle this situation is to use a numeric prefix for every domain that our ser proxy should convert to domain names for uri rewriting.
Finally the question:
Is a prefix/domain standard conversion table avalaible somewhere ?
something like ...
addline 1-747-474 (real prefix, I guess).
Check out pdt module (prefix to domain translation).
Jan.
Hello Jan,
JJ> Check out pdt module (prefix to domain translation).
I'm missing that, is it in the standard 8.11 rpm ?
No, the module is not included in the rpms. You will have to compile it from sources.
Jan.
On 10-11 16:56, Alessio Focardi wrote:
Hello Jan,
JJ> Check out pdt module (prefix to domain translation).
I'm missing that, is it in the standard 8.11 rpm ?
-- Best regards, Alessio mailto:alessiof@interconnessioni.it
Hello Jan,
Monday, November 10, 2003, 5:06:16 PM, you wrote:
JJ> No, the module is not included in the rpms. You will have to compile it JJ> from sources.
got it, no way to build it without rebuilding all SER, right ?
On 10-11 17:43, Alessio Focardi wrote:
Hello Jan,
Monday, November 10, 2003, 5:06:16 PM, you wrote:
JJ> No, the module is not included in the rpms. You will have to compile it JJ> from sources.
got it, no way to build it without rebuilding all SER, right ?
Unfortunatelly not right now.
Jan.
On (10.11.03 16:20), Alessio Focardi wrote:
Is a prefix/domain standard conversion table avalaible somewhere ?
something like ...
addline 1-747-474 (real prefix, I guess).
You are asking for the VoIP equivalent of the hosts file. Those files have been obsoleted long ago, and i'm pretty sure that prefix lists will not have much chance in the long run, too, because:
There is already a DNS based number-to-URI lookup protocol/mechanism: ENUM
For example, my phone can be reached by doing an ENUM lookup for the E.164 number "+4359966366001" which, from the DNS point of view, looks like:
graham:~# host -t NAPTR 3.0.0.6.6.3.6.6.9.9.5.3.4.e164.arpa. 3.0.0.6.6.3.6.6.9.9.5.3.4.e164.arpa NAPTR 100 10 "u" "E2U+sip" "!^.*$!sip:e001-366003@enum.at43.at!" .
SER features a module which can be used to do call routing using ENUM.
cheers
axelm
Hello Alexander,
I'm sorry to be so ignorant ... I first heard of SIP 2 weeks ago :)
E.164 ?
Will I need money to obtain a E.164 compliant prefix for my server ?
Thank you for helping me out !
AM> For example, my phone can be reached by doing an ENUM lookup for the AM> E.164 number "+4359966366001" which, from the DNS point of view, looks like:
AM> graham:~# host -t NAPTR 3.0.0.6.6.3.6.6.9.9.5.3.4.e164.arpa. AM> 3.0.0.6.6.3.6.6.9.9.5.3.4.e164.arpa NAPTR 100 10 "u" "E2U+sip" AM> "!^.*$!sip:e001-366003@enum.at43.at!" .
AM> SER features a module which can be used to do call routing using ENUM.
AM> cheers
AM> axelm
On (10.11.03 16:42), Alessio Focardi wrote:
E.164 ?
sorry for my ignorance, E.164 is the ITU-T recommendation for the format of phone numbers. So, an E.164 number is simply a phone number.
Will I need money to obtain a E.164 compliant prefix for my server ?
If you're talking about ENUM entries:
You would need to have phone numbers for your users plus a ENUM DNS infrastructure in your country. If you have already a phone number, you could give your users extensions behind that number.
Unfortunately, there is no ENUM trial going on in Italy yet, so you won't be able to publish ENUM records for your users in the public DNS in that case, so other users would not be able to find your users via ENUM.
But, you could still use ENUM for finding other ENUM users, a currently small, but rapidly growing community. You won't need to keep a "prefix to domain" list for all the other VoIP providers, and your users won't have to remember "which prefix to dial for which provider?"
to see a rough sketch how it works, take a look at our presentation at
http://enum.nic.at/documents/AETP/Presentations/Austria/0017-2003-07_ENUM-De...
I'm happy to supply you with more detail in private mail, i consider that being already quite off topic on the SER users list. Feel free to contact me.
cheers
axelm
On 10-11 17:05, Alexander Mayrhofer wrote:
I'm happy to supply you with more detail in private mail, i consider that being already quite off topic on the SER users list. Feel free to contact me.
Feel free to keep it on the list. ENUM could be quite interesting for people here, I think.
Jan.
Hello Alexander,
so, if I'm getting it right:
I have 2 possibilities now:
use "prefix to domain" rewriting
there is a ser module for doing that, but in my opinion it looks pretty lame to keep up to date the association between prefix and phone numbers; when you will have 2.000.000 sip domains who is going to save you ? :)
That's the reason why I was asking for a centralized prefix/domains translation table:
its seems obvious to me that if everybody is going to decide is own associations things are going to be very funny in a few.
use the "ENUM" method
That's something like a "dns of phone numbers/sip domains" that's also compatible with the pstn numbering plan for better integration.
You resolve the "fake pstn" phone number to obtain a SIP address, complete with domain.
The only problem could be that you dont have to remember SIP addresses but very long phone numbers .... :)
Am I on the right way to undestand the matter ?
Beside this I'm wondering why Italy is out of this interesting ENUM trial ... no one was willing ? Maybe you have find someone here ! :)
Monday, November 10, 2003, 5:05:08 PM, you wrote:
AM> On (10.11.03 16:42), Alessio Focardi wrote:
E.164 ?
AM> sorry for my ignorance, E.164 is the ITU-T recommendation for the format AM> of phone numbers. So, an E.164 number is simply a phone number.
Will I need money to obtain a E.164 compliant prefix for my server ?
AM> If you're talking about ENUM entries:
AM> You would need to have phone numbers for your users plus a ENUM DNS AM> infrastructure in your country. If you have already a phone number, you AM> could give your users extensions behind that number.
AM> Unfortunately, there is no ENUM trial going on in Italy yet, so you AM> won't be able to publish ENUM records for your users in the public DNS AM> in that case, so other users would not be able to find your users via AM> ENUM.
AM> But, you could still use ENUM for finding other ENUM users, a currently AM> small, but rapidly growing community. You won't need to keep a "prefix AM> to domain" list for all the other VoIP providers, and your users won't AM> have to remember "which prefix to dial for which provider?"
AM> to see a rough sketch how it works, take a look at our presentation at
AM> http://enum.nic.at/documents/AETP/Presentations/Austria/0017-2003-07_ENUM-De...
AM> I'm happy to supply you with more detail in private mail, i consider AM> that being already quite off topic on the SER users list. Feel free to AM> contact me.
AM> cheers
AM> axelm
On (10.11.03 17:36), Alessio Focardi wrote:
use "prefix to domain" rewriting
there is a ser module for doing that, but in my opinion it looks pretty lame to keep up to date the association between prefix and phone numbers; when you will have 2.000.000 sip domains who is going to save you ? :)
exactly. You've hit the point. It's quite easy for you right now to configure a prefix table, and it's quite easy for your users to remember 3 prefixes. Once you get beyond about 10 prefixes, everyone will carry around small notes with a "prefix-howto" list. Once you get beyond 30 prefixes, people will not use the prefix list anymore.
That's the reason why I was asking for a centralized prefix/domains translation table:
its seems obvious to me that if everybody is going to decide is own associations things are going to be very funny in a few.
It's not only about keeping a centralized prefix directory. It's also about getting those prefixes to the users.
And, the best of all, there are already guys managing a list of prefixes: the international numbering plan. I don't think that many people are willing to learn yet another prefix list ... so reusing the international numbering plan for VoIP seems just logical. It's transparent to the user, they don't need to change their behaviout when placing calls ...
People who sit behind a PBX are probably more used to prefixes (pressing "0" to dialling out, pressing "1" for the colleagues in the daughter company just aquired), but that's probably not the majority, and simply does not scale.
use the "ENUM" method
That's something like a "dns of phone numbers/sip domains" that's also compatible with the pstn numbering plan for better integration.
You resolve the "fake pstn" phone number to obtain a SIP address, complete with domain.
The only problem could be that you dont have to remember SIP addresses but very long phone numbers .... :)
Well, people are already used to remember/keep numbers. It simply depends. I'll probably print sip:axelm@nic.at43.at on my business card, but i'll put +4359966366003 into my mobile phone.
Am I on the right way to undestand the matter ?
yep, you're perfectly on track.
Beside this I'm wondering why Italy is out of this interesting ENUM trial ... no one was willing ? Maybe you have find someone here ! :)
I'm currently not aware of the activities in Italy. I'll try to find out, please stay tuned.
cheers
axelm
The only problem could be that you dont have to remember SIP addresses but very long phone numbers .... :)
AM> Well, people are already used to remember/keep numbers. It simply AM> depends. I'll probably print sip:axelm@nic.at43.at on my business card, AM> but i'll put +4359966366003 into my mobile phone.
Am I on the right way to undestand the matter ?
Every answer rises a question :)
Lets imagine 2 situations:
someone is calling you from pstn, he rings your number, your pbx directs the call to your desk. Thats plain old telco style, even if you have an ip pbx.
Then I compose your number in my grandtec phone, my server is configured to ask for the translation of your number to a SIP address using ENUM.
The "central authority" resolves the number because he knows that "+435996636" is "nic.at43.at" phone, and 6003 is the extension of "axelm".
Thats looks a lot like "lcr" with autofallback, user EVERY time someone calls out from an Ip PBX or SIP server, great stuff.
BUT:
I checked and it looks like +878 is the "international prefix" for IP telephony.
What is it for if you are using your usual phone number ?
Maybe for "pure ip" services, no pstn at all ?
Thank you, I'm more involved into this now ....
AM> yep, you're perfectly on track.
Beside this I'm wondering why Italy is out of this interesting ENUM trial ... no one was willing ? Maybe you have find someone here ! :)
AM> I'm currently not aware of the activities in Italy. I'll try to find AM> out, please stay tuned.
Tnx, it looks very interesting, by the way I'm tryng to steer my company to this field very soon.
AM> cheers
AM> axelm
On (10.11.03 18:28), Alessio Focardi wrote:
Thats looks a lot like "lcr" with autofallback, user EVERY time someone calls out from an Ip PBX or SIP server, great stuff.
BUT:
That's it, exactly.
I checked and it looks like +878 is the "international prefix" for IP telephony.
oops, i forgot to mention, my phone is reachable by dialing +878102843366003 as well ;)
What is it for if you are using your usual phone number ?
Maybe for "pure ip" services, no pstn at all ?
+878 could, for example, be an option for people who currently don't have an ENUM trial active in their country... got it?
The downside of that is that +878 is currently not reachable from the PSTN, so even if you had interconnect and that all, no PSTN user would be able to reach you (or, to be more precise: only users of Telekom Austria would be able to reach you).
But, you're right, those are _real_ phone numbers as like as every other "common" country code.
cheers
axelm
AM> oops, i forgot to mention, my phone is reachable by dialing AM> +878102843366003 as well ;)
your business card is becoming a little oversized, isnt'it ? :)
What is it for if you are using your usual phone number ?
Maybe for "pure ip" services, no pstn at all ?
AM> +878 could, for example, be an option for people who currently don't AM> have an ENUM trial active in their country... got it?
On to the pratical question:
I want to launch a free sip directory here in Italy.
what could be the next logical step to that my numbering plan will be coerent to future scenarios ?
I'm going to assign every user a 6 digits username, that's pretty plain.
Beside this, I'm pretty confused:
sipphone.com states that his prefix is 1-747-474, so if they are not partecipating in ENUM it seems logical to me to use uri conversion to append "@sipphone.com" to every number that begins with "1-747-474".
What for addaline.com that does not state any prefix ? I have to choose one that I like ?
And for my future plans ...
Do I have to apply now (if possibile) for an +878xxxx prefix or I can just invent one, hoping that when they will become public avalaible I will retain mine?
In this case .. how many digits will xxxx be ?
Again, tnx, If you will ever come to Florence you will have someone to show you the city ! :)
On (10.11.03 19:04), Alessio Focardi wrote:
AM> +878 could, for example, be an option for people who currently don't AM> have an ENUM trial active in their country... got it?
On to the pratical question:
I want to launch a free sip directory here in Italy.
what could be the next logical step to that my numbering plan will be coerent to future scenarios ?
I'm going to assign every user a 6 digits username, that's pretty plain.
Ok, from my opinion:
Don't hand out any numbers starting with 0 (access code), 1 (service numbers in EU) and probably 9 (US service numbers). Your users will probably ask for vanity numbers, so if you decide to hand out such numbers, "9" cannot be excluded easily ("WXYZ" map to "9").
Beside this, I'm pretty confused:
sipphone.com states that his prefix is 1-747-474, so if they are not partecipating in ENUM it seems logical to me to use uri conversion to append "@sipphone.com" to every number that begins with "1-747-474".
If they have the same numbering scheme for PSTN and SIP access, yes. If not, it's not that easy. if, e.g. a user using 1-747-474-1234 as PSTN number and using 4321@sipphone.com as URI, it does not work out...
What for addaline.com that does not state any prefix ? I have to choose one that I like ?
I'd choose one which doesn't clash with any country code. But keep in mind that your users will probably some day use the same dialing plan as the're used to on their regular phones, so it's not that easy. If you think of a dial plan as like as:
2-9: Dial to other users 0: Dial out to national PSTN destinations 00: Dial out to international PSTN destinations
you have not much space left for prefixes. Using "1" could be dangerous, because it clashes with service numbers (EU emergency calls 112, white pages 118xxx, and so on...).
An option could be to use the Asterisk "*" to signal prefixes, e.g.:
*01*xxxxx -> sipphone *02*xxxxx -> addaline
Thats obviously only good enough for 100 prefixes ...
We're using the "mobile phone" dialing plan here, so you cannot dial any other "extension". You have always to dial the area code as well ("059966366003" from one phone to another instead of just "366003"). That gives huge opportunities in the dial plan (uses only 10% of the dial plan space, but is only possible if you have numbers which are valid in the PSTN as well (otherwise they would clash with dialout to PSTN numbers). And best of all, people are used to that dial plan, because everybody uses mobiles ...
And for my future plans ...
Do I have to apply now (if possibile) for an +878xxxx prefix or I can just invent one, hoping that when they will become public avalaible I will retain mine?
The number space "below" +87810 is exactly 15 digits, so you would have something like:
+87810xxxxyyyyyy
I'm not too familiar with the VisionNG policies, but i can direct you to someone if you're interested.
Again, tnx, If you will ever come to Florence you will have someone to show you the city ! :)
will remember that, was in Siena last year. Never visited Florence, though ...
cheers
axelm
At 04:20 PM 11/10/2003, Alessio Focardi wrote:
Hello Jan,
What I'm asking is not the way to do this, since I already have it working, but if this method is correct and would not cause problems later.
JJ> It is correct.
So I can go on, it seems me ....
I'm writing in "subscriber" table
JJ> phplib_id is a unique key for the php library (used by serweb).
Is that used by the server ? is the only data that I can't write using ODBC from a Windows pc.
JJ> ha1 contains an MD5 hash of username domain and password. You can use JJ> gen_ha1 utility to generate it. ha1b is the same only the username is JJ> in form username@domain.
JJ> ha1 and ha1b columns are used only if you have calculate_ha1 JJ> parameter of auth_db module off.
That's not my case ....
I would like to ask another question to everyone involved in SER:
I'm experimenting with Grandstream IP Phones, that are allowing only numbers for calling out.
That'is a big problem when you want to call someone outside your domain .... for instance 11111111@iptel.org
I think that the right way to handle this situation is to use a numeric prefix for every domain that our ser proxy should convert to domain names for uri rewriting.
There is the pdt module which can handle the prefix-to-domain translations for you. There is a small webpage too which allows you to ask to query domains and get existing or newly generated prefixes for them.
--jiri
Jan Janak wrote:
Hello,
On 10-11 16:01, Alessio Focardi wrote:
Hi all,
I would like to add users to the MySql database of SER using an ODBC link.
What I'm asking is not the way to do this, since I already have it working, but if this method is correct and would not cause problems later.
It is correct.
I'm writing in "subscriber" table
username domain password email
The subscriber table can be written to directly _outside_ the control of SER? I go out of my way to do a 'add user' in serctl instead of inserting into the table. I have experienced caching problems.
Can the subscriber and location tables be uncached? Such that I can insert into either table and any running copy of SER will query the database instead of the in memory cache?
---greg Greg Fausak
Greg,
On 10-11 10:12, Greg Fausak wrote:
The subscriber table can be written to directly _outside_ the control of SER? I go out of my way to do a 'add user' in serctl instead of inserting into the table. I have experienced caching problems.
Currently there is no cache for subscriber table, so it can be updated directly. Location and domain tables are cached.
Can the subscriber and location tables be uncached? Such that I can insert into either table and any running copy of SER will query the database instead of the in memory cache?
Subscriber table is uncached right now. The possibility to disable cache for location table will be included in the next release.
Jan.
Jan Janak wrote:
Greg,
On 10-11 10:12, Greg Fausak wrote:
The subscriber table can be written to directly _outside_ the control of SER? I go out of my way to do a 'add user' in serctl instead of inserting into the table. I have experienced caching problems.
Currently there is no cache for subscriber table, so it can be updated directly. Location and domain tables are cached.
ah. version 0.8.11 has uncached subscriber table.
was subscriber cached in 0.8.10?
the next version is 0.8.12? any eta? I can test the cvs stuff if it is in there. i hope there is a 'check the cache and if the location isn't registered there then check the database' mode. Upon further reflection this may be problematic...should probably always check the database.
Thanks,
---greg
Can the subscriber and location tables be uncached? Such that I can insert into either table and any running copy of SER will query the database instead of the in memory cache?
Subscriber table is uncached right now. The possibility to disable cache for location table will be included in the next release.
Jan.
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Greg,
On 10-11 10:44, Greg Fausak wrote:
ah. version 0.8.11 has uncached subscriber table.
was subscriber cached in 0.8.10?
No, subscriber table has never been cached.
the next version is 0.8.12? any eta? I can test the cvs stuff if it is in there. i hope there is a 'check the cache and if the location isn't registered there then check the database' mode. Upon further reflection this may be problematic...should probably always check the database.
ETA is middle of January. I wouldn't recommend unstable stuff right now because it contains many untested changes.
Jan.
Jan Janak wrote:
Greg,
On 10-11 10:44, Greg Fausak wrote:
ah. version 0.8.11 has uncached subscriber table.
was subscriber cached in 0.8.10?
No, subscriber table has never been cached.
That is weird.
I know I've had problems with this in the past. We had to jump through major hoops to use the serctl adduser gear instead of a simple table insert. I'll revisit that approach again, maybe I got it confused with the location table.
Thanks, ---greg
On 10-11 11:12, Greg Fausak wrote:
That is weird.
I know I've had problems with this in the past. We had to jump through major hoops to use the serctl adduser gear instead of a simple table insert. I'll revisit that approach again, maybe I got it confused with the location table.
That was probably location table (serctl ul add)
Jan.
-
Alessio Focardi -
Alexander Mayrhofer -
Greg Fausak -
Jan Janak -
Jiri Kuthan