In response for frequent questions how to configure SER to operate as voicemail2email server, I created an example file. Note that this example operates as a stand-alone UAS, i.e., the configuration does not operate in proxy mode -- it needs a proxy fronting it. (I will try to look at the combined mode too, as soon as time allows.) Also, the example needs to have sems up and running.
The example is on our CVS, see http://cvs.berlios.de/cgi-bin/viewcvs.cgi/*checkout*/ser/sip_router/examples...
-jiri
-- Jiri Kuthan http://iptel.org/~jiri/
Jiri,
Is it possible to run two instances of ser on the same box, one acting as the proxy and the other acting as the voicemail2email server, or are to different boxes required?
Can you comment a little more on how to get SER as a proxy to transfer messages to SER as a UAS, both on a single box [if this is possible], and/or in a two box setup.
I'd really like to do all this on one box as its much more economical.
Thanks, G
Jiri Kuthan jiri@iptel.org wrote: In response for frequent questions how to configure SER to operate as voicemail2email server, I created an example file. Note that this example operates as a stand-alone UAS, i.e., the configuration does not operate in proxy mode -- it needs a proxy fronting it. (I will try to look at the combined mode too, as soon as time allows.) Also, the example needs to have sems up and running.
The example is on our CVS, see http://cvs.berlios.de/cgi-bin/viewcvs.cgi/*checkout*/ser/sip_router/examples...
-jiri
-- Jiri Kuthan http://iptel.org/~jiri/
_______________________________________________ Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
--------------------------------- Do you Yahoo!? The New Yahoo! Shopping - with improved product search
At 04:40 AM 10/11/2003, Gavin Bensom wrote:
Jiri,
Is it possible to run two instances of ser on the same box, one acting as the proxy and the other acting as the voicemail2email server, or are to different boxes required?
I never tried -- it should, but better verify it. Just try two different SER's at two different port numbers. Take stable version from CVS for both SER and voicemail -- I made some recent alignments to better deal with scenarios like these.
Can you comment a little more on how to get SER as a proxy to transfer messages to SER as a UAS, both on a single box [if this is possible], and/or in a two box setup.
That's script fragments for the fronting proxy that should make the job (not verified either):
# does the user wish redirection on no availability? (i.e., is he # in the voicemail group?) -- determine it now and store it in # flag 4, before we rewrite the flag using UsrLoc if (is_user_in("Request-URI", "voicemail")) { setflag(4); }; # native SIP destinations are handled using our USRLOC DB if (!lookup("location")) { # handle user which was not found if f (isflagset(4)) route(4); break; }; # if user is on-line and is in voicemail group, enable redirection if (method == "INVITE" && isflagset(4)) { t_on_failure("1"); };
.... route[4] {
rewritehostport("foo.bar:1234"); t_relay(); } ... failure_route[1] { revert_uri(); lookup("aliases"); rewritehostport("bat.iptel.org:5090"); append_branch(); t_relay(); }
I'd really like to do all this on one box as its much more economical.
I will try to get back to you with a "single-ser" config too -- I just happened to run out of time in the past week and will not be any better off next too weeks.
-jiri
Jiri and all,
ser -V **** ser version info
version: ser 0.8.11 (i386/linux) flags: STATS:Off, USE_IPV6, USE_TCP, DISABLE_NAGLE, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535 @(#) $Id: main.c,v 1.162.2.5 2003/08/27 16:04:35 andrei Exp $ main.c compiled on 21:37:39 Sep 1 2003 with gcc 3.2
OS ************
Red Hat 9 [root@jiffypop html]# uname -a Linux jiffypop 2.4.20-20.9smp #1 SMP Mon Aug 18 11:32:15 EDT 2003 i686 i686 i386 GNU/Linux
I tried implementing voicemail by running SER twice simultaneouly on the same box. The first is running with my ser.cfg [pid 24264 below], and the second is with a slight variation of voicemail.cfg [pid 23911 below] as posted recently by Jiri.
This is all done with the 0.8.11 major release of SER. I didn't take the files from CVS as suggested. I'll try that soon. Are there any changes in CVS which are incompatible with the 0.8.11 database configuration? Are there any other changes which I would have to be careful of with respect to compatibility?
Two instances of SER running on the same box works fairly well. I occasionally get an error via syslog which looks like this:
Oct 13 12:36:07 jiffypop Sems[23889]: Error: while getting return code from Ser
Below is an example of syslog output when a user is part of the voicemail group but has no user locations in the location database.
Oct 13 12:33:50 jiffypop /usr/local/sbin/ser[24264]: no location-uri is in vm group Oct 13 12:33:50 jiffypop /usr/local/sbin/ser[24264]: route[3]:no user location: foward to voicemail Oct 13 12:33:50 jiffypop ser[23911]: t_newtran created Oct 13 12:33:50 jiffypop ser[23911]: **************** vm start - begin ****************** Oct 13 12:33:50 jiffypop ser[23911]: **************** vm start - end ****************** Oct 13 12:33:50 jiffypop /usr/local/sbin/ser[24263]: ACC: transaction answered: from="V11 Main" <si p:info@10.10.10.49>;tag=fcad7738-6281-77bd-a9bd-0c525a6382fa, i-uri=sip:6670@10.10.10.49, method=IN VITE, o-uri=sip:sgaudio@10.10.10.49:5090, code=200 Oct 13 12:33:50 jiffypop /usr/local/sbin/ser[24266]: no location-uri is in vm group Oct 13 12:33:50 jiffypop /usr/local/sbin/ser[24266]: route[3]:no user location: foward to voicemail Oct 13 12:33:50 jiffypop /usr/local/sbin/ser[24266]: ACC: request acknowledged: from="V11 Main" <si p:info@10.10.10.49>;tag=fcad7738-6281-77bd-a9bd-0c525a6382fa, i-uri=sip:sgaudio@10.10.10.49, method =ACK, o-uri=sip:sgaudio@10.10.10.49:5090, code=200 Oct 13 12:33:52 jiffypop /usr/local/sbin/ser[24265]: no location-uri is in vm group Oct 13 12:33:52 jiffypop /usr/local/sbin/ser[24265]: route[3]:no user location: foward to voicemail Oct 13 12:33:52 jiffypop ser[23909]: t_newtran created Oct 13 12:33:52 jiffypop ser[23909]: **************** vm end - begin ****************** Oct 13 12:33:52 jiffypop ser[23909]: **************** vm end - end ****************** Oct 13 12:33:52 jiffypop /usr/local/sbin/ser[24266]: ACC: transaction answered: from="V11 Main" <si p:info@10.10.10.49>;tag=fcad7738-6281-77bd-a9bd-0c525a6382fa, i-uri=sip:sgaudio@10.10.10.49, method =BYE, o-uri=sip:sgaudio@10.10.10.49:5090, code=200
Below is an example of a call that gets transferred to voicemail via a failure_route [timeout or "busy" reply]. Notice that the ****vm end - begin******* and *****vm end - end ****** entries are missing. Essentially, the voicemail instance of SER isn't processing the BYE messages. I'm not sure why. I guess the other instance of SER is processing them.
Oct 13 12:29:07 jiffypop /usr/local/sbin/ser[24264]: failure_route[4] Oct 13 12:29:07 jiffypop /usr/local/sbin/ser[24264]: route[4]:Call tried and failed: forward to voi cemail Oct 13 12:29:07 jiffypop ser[23914]: t_newtran created Oct 13 12:29:07 jiffypop ser[23914]: **************** vm start - begin ****************** Oct 13 12:29:07 jiffypop ser[23914]: **************** vm start - end ****************** Oct 13 12:29:14 jiffypop /usr/local/sbin/ser[24265]: ACC: transaction answered: from=sip:650218888 ;tag=12FB6358-82B"4@10.10.10.5>;tag=12FB6358-82B, i-uri=sip:6633@10.10.10.49:5060;ftag=12FB6358-82B;lr=on, method=BYE , o-uri=sip:gnoah@10.10.10.160:5060, code=200
I think these [above log messages] types of transactions are responsible for the above mentioned SEMS error, but I'm not sure.
What I really need now is a way to deal with the timer issue. Jiri, I don't think I need multiple timers. I never want SER to timeout calls placed to the PSTN. I just want one timer which I can apply to selective transactions. Right now, the timer causes all calls to fail. I understand that I can change processing on failure, and I am doing this, but it would be very nice if the timer could be used only for specific transactions. I think this would involve setting it through a function call instead of a modparam call, but I don't know since I haven't actually looked at any code.
I've also tried to just relay PSTN calls again (re-relay) through a failure route after the timer expires, but that doesn't seem to be working too well. Is this possible?
Also, I think its not necessary to implement the "single-ser" config that is capable of running voicemail if this dual configuration works well. Of cource, the "single-ser" config would make it a little simpler for users.
Thanks, Noah
Jiri Kuthan jiri@iptel.org wrote: At 04:40 AM 10/11/2003, Gavin Bensom wrote:
Jiri,
Is it possible to run two instances of ser on the same box, one acting as the proxy and the other acting as the voicemail2email server, or are to different boxes required?
I never tried -- it should, but better verify it. Just try two different SER's at two different port numbers. Take stable version from CVS for both SER and voicemail -- I made some recent alignments to better deal with scenarios like these.
Can you comment a little more on how to get SER as a proxy to transfer messages to SER as a UAS, both on a single box [if this is possible], and/or in a two box setup.
That's script fragments for the fronting proxy that should make the job (not verified either):
# does the user wish redirection on no availability? (i.e., is he # in the voicemail group?) -- determine it now and store it in # flag 4, before we rewrite the flag using UsrLoc if (is_user_in("Request-URI", "voicemail")) { setflag(4); }; # native SIP destinations are handled using our USRLOC DB if (!lookup("location")) { # handle user which was not found if f (isflagset(4)) route(4); break; }; # if user is on-line and is in voicemail group, enable redirection if (method == "INVITE" && isflagset(4)) { t_on_failure("1"); };
.... route[4] {
rewritehostport("foo.bar:1234"); t_relay(); } ... failure_route[1] { revert_uri(); lookup("aliases"); rewritehostport("bat.iptel.org:5090"); append_branch(); t_relay(); }
I'd really like to do all this on one box as its much more economical.
I will try to get back to you with a "single-ser" config too -- I just happened to run out of time in the past week and will not be any better off next too weeks.
-jiri
--------------------------------- Do you Yahoo!? The New Yahoo! Shopping - with improved product search
At 10:06 PM 10/13/2003, Gavin Bensom wrote:
Jiri and all,
ser -V **** ser version info
version: ser 0.8.11 (i386/linux) flags: STATS:Off, USE_IPV6, USE_TCP, DISABLE_NAGLE, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535 @(#) $Id: main.c,v 1.162.2.5 2003/08/27 16:04:35 andrei Exp $ main.c compiled on 21:37:39 Sep 1 2003 with gcc 3.2
OS ************
Red Hat 9 [root@jiffypop html]# uname -a Linux jiffypop 2.4.20-20.9smp #1 SMP Mon Aug 18 11:32:15 EDT 2003 i686 i686 i386 GNU/Linux
I tried implementing voicemail by running SER twice simultaneouly on the same box. The first is running with my ser.cfg [pid 24264 below], and the second is with a slight variation of voicemail.cfg [pid 23911 below] as posted recently by Jiri.
This is all done with the 0.8.11 major release of SER. I didn't take the files from CVS as suggested. I'll try that soon. Are there any changes in CVS which are incompatible with the 0.8.11 database configuration? Are there any other changes which I would have to be careful of with respect to compatibility?
The stable branch (the one with the special tag) is fully compatible to what we released as 8.11. The same for SEMS. Really better use them as I tested the example I sent over with them.
Two instances of SER running on the same box works fairly well. I occasionally get an error via syslog which looks like this: Oct 13 12:36:07 jiffypop Sems[23889]: Error: while getting return code from Ser
Below is an example of syslog output when a user is part of the voicemail group but has no user locations in the location database.
Oct 13 12:33:50 jiffypop /usr/local/sbin/ser[24264]: no location-uri is in vm group Oct 13 12:33:50 jiffypop /usr/local/sbin/ser[24264]: route[3]:no user location: foward to voicemail Oct 13 12:33:50 jiffypop ser[23911]: t_newtran created Oct 13 12:33:50 jiffypop ser[23911]: **************** vm start - begin ****************** Oct 13 12:33:50 jiffypop ser[23911]: **************** vm start - end ****************** Oct 13 12:33:50 jiffypop /usr/local/sbin/ser[24263]: ACC: transaction answered: from="V11 Main" <si p:info@10.10.10.49>;tag=fcad7738-6281-77bd-a9bd-0c525a6382fa, i-uri=sip:6670@10.10.10.49, method=IN VITE, o-uri=sip:sgaudio@10.10.10.49:5090, code=200 Oct 13 12:33:50 jiffypop /usr/local/sbin/ser[24266]: no location-uri is in vm group Oct 13 12:33:50 jiffypop /usr/local/sbin/ser[24266]: route[3]:no user location: foward to voicemail Oct 13 12:33:50 jiffypop /usr/local/sbin/ser[24266]: ACC: request acknowledged: from="V11 Main" <si p:info@10.10.10.49>;tag=fcad7738-6281-77bd-a9bd-0c525a6382fa, i-uri=sip:sgaudio@10.10.10.49, method =ACK, o-uri=sip:sgaudio@10.10.10.49:5090, code=200 Oct 13 12:33:52 jiffypop /usr/local/sbin/ser[24265]: no location-uri is in vm group Oct 13 12:33:52 jiffypop /usr/local/sbin/ser[24265]: route[3]:no user location: foward to voicemail Oct 13 12:33:52 jiffypop ser[23909]: t_newtran created Oct 13 12:33:52 jiffypop ser[23909]: **************** vm end - begin ****************** Oct 13 12:33:52 jiffypop ser[23909]: **************** vm end - end ****************** Oct 13 12:33:52 jiffypop /usr/local/sbin/ser[24266]: ACC: transaction answered: from="V11 Main" <si p:info@10.10.10.49>;tag=fcad7738-6281-77bd-a9bd-0c525a6382fa, i-uri=sip:sgaudio@10.10.10.49, method =BYE, o-uri=sip:sgaudio@10.10.10.49:5090, code=200
Below is an example of a call that gets transferred to voicemail via a failure_route [timeout or "busy" reply]. Notice that the ****vm end - begin******* and *****vm end - end ****** entries are missing. Essentially, the voicemail instance of SER isn't processing the BYE messages. I'm not sure why. I guess the other instance of SER is processing them.
Oct 13 12:29:07 jiffypop /usr/local/sbin/ser[24264]: failure_route[4] Oct 13 12:29:07 jiffypop /usr/local/sbin/ser[24264]: route[4]:Call tried and failed: forward to voi cemail Oct 13 12:29:07 jiffypop ser[23914]: t_newtran created Oct 13 12:29:07 jiffypop ser[23914]: **************** vm start - begin ****************** Oct 13 12:29:07 jiffypop ser[23914]: **************** vm start - end ****************** Oct 13 12:29:14 jiffypop /usr/local/sbin/ser[24265]: ACC: transaction answered: from=<sip:650218888 mailto:4@10.10.10.5;tag=12FB6358-82B>4@10.10.10.5>;tag=12FB6358-82B, i-uri=sip:6633@10.10.10.49:5060;ftag=12FB6358-82B;lr=on, method=BYE , o-uri=sip:gnoah@10.10.10.160:5060, code=200
I think these [above log messages] types of transactions are responsible for the above mentioned SEMS error, but I'm not sure.
So I don't understand from your description -- is there anything what is not working except some error messages?
What I really need now is a way to deal with the timer issue. Jiri, I don't think I need multiple timers. I never want SER to timeout calls placed to the PSTN. I just want one timer which I can apply to selective transactions.
Well, there is _always_ a timer for every transaction and the timer has always the same value. The only thing which can be made distinctive is how this timer is handled.
Right now, the timer causes all calls to fail. I understand that I can change processing on failure, and I am doing this, but it would be very nice if the timer could be used only for specific transactions. I think this would involve setting it through a function call instead of a modparam call, but I don't know since I haven't actually looked at any code.
The timer can't be removed -- it has a kind of "garbage collection" responsibility and a server without timers would run out of memory very quickly.
What you could do is forwarding to gateway statelessly -- then, there would be indeed no timer involved. I don't think, that makes sense though for a couple of other reasons like accounting and/or tcp2udp forwarding.
I've also tried to just relay PSTN calls again (re-relay) through a failure route after the timer expires, but that doesn't seem to be working too well. Is this possible?
What does it mean "it doesn't seem to be working too well"?
Anyway, I think it really would not work -- it would end up canceling and re-ringing the PSTN destination, which is a kind of undesirable behviour.
So in summary, I don't think there is an easy option for single-instance ser and multiple-timer. A really straight-forward option is support in SER.
Also, I think its not necessary to implement the "single-ser" config that is capable of running voicemail if this dual configuration works well. Of cource, the "single-ser" config would make it a little simpler for users.
I would actually love to have it, it is just a problem of my time.
-jiri
Jiri,
You are correct. Everything is working except for the error messages, which concern me since I don't know why they're occuring or if they might cause instability.
I'll try the CVS version.
Thanks, G.
So I don't understand from your description -- is there anything what is not working except some error messages?
What I really need now is a way to deal with the timer issue. Jiri, I don't think I need multiple timers. I never want SER to timeout calls placed to the PSTN. I just want one timer which I can apply to selective transactions.
Well, there is _always_ a timer for every transaction and the timer has always the same value. The only thing which can be made distinctive is how this timer is handled.
Right now, the timer causes all calls to fail. I understand that I can change processing on failure, and I am doing this, but it would be very nice if the timer could be used only for specific transactions. I think this would involve setting it through a function call instead of a modparam call, but I don't know since I haven't actually looked at any code.
The timer can't be removed -- it has a kind of "garbage collection" responsibility and a server without timers would run out of memory very quickly.
What you could do is forwarding to gateway statelessly -- then, there would be indeed no timer involved. I don't think, that makes sense though for a couple of other reasons like accounting and/or tcp2udp forwarding.
I've also tried to just relay PSTN calls again (re-relay) through a failure route after the timer expires, but that doesn't seem to be working too well. Is this possible?
What does it mean "it doesn't seem to be working too well"?
Anyway, I think it really would not work -- it would end up canceling and re-ringing the PSTN destination, which is a kind of undesirable behviour.
So in summary, I don't think there is an easy option for single-instance ser and multiple-timer. A really straight-forward option is support in SER.
Also, I think its not necessary to implement the "single-ser" config that is capable of running voicemail if this dual configuration works well. Of cource, the "single-ser" config would make it a little simpler for users.
I would actually love to have it, it is just a problem of my time.
-jiri
--------------------------------- Do you Yahoo!? The New Yahoo! Shopping - with improved product search
ok I see, I'm cc-ing the sems author, hopefuly you will get a response soon.
-jiri
At 02:25 AM 10/14/2003, Gavin Bensom wrote:
Jiri,
You are correct. Everything is working except for the error messages, which concern me since I don't know why they're occuring or if they might cause instability.
I'll try the CVS version.
Thanks, G.
So I don't understand from your description -- is there anything what is not working except some error messages?
What I really need now is a way to deal with the timer issue. Jiri, I don't think I need multiple timers. I never want SER to timeout calls placed to the PSTN. I just want one timer which I can apply to selective transactions.
Well, there is _always_ a timer for every transaction and the timer has always the same value. The only thing which can be made distinctive is how this timer is handled.
Right now, the timer causes all calls to fail. I understand that I can change processing on failure, and I am doing this, but it would be very nice if the timer could be used only for specific transactions. I think this would involve setting it through a function call instead of a modparam call, but I don't know since I haven't actually looked at any code.
The timer can't be removed -- it has a kind of "garbage collection" responsibility and a server without timers would run out of memory very quickly.
What you could do is forwarding to gateway statelessly -- then, there would be indeed no timer involved. I don't think, that makes sense though for a couple of other reasons like accounting and/or tcp2udp forwarding.
I've also tried to just relay PSTN calls again (re-relay) through a failure route after the timer expires, but that doesn't seem to be working too well. Is this possible?
What does it mean "it doesn't seem to be working too well"?
Anyway, I think it really would not work -- it would end up canceling and re-ringing the PSTN destination, which is a kind of undesirable behviour.
So in summary, I don't think there is an easy option for single-instance ser and multiple-timer. A really straight-forward option is support in SER.
Also, I think its not necessary to implement the "single-ser" config that is capable of running voicemail if this dual configuration works well. Of cource, the "single-ser" config would make it a little simpler for users.
I would actually love to have it, it is just a problem of my time.
-jiri
Do you Yahoo!? http://shopping.yahoo.com/?__yltc=s%3A150000443%2Cd%3A22708228%2Cslk%3Atext%2Csec%3AmailThe New Yahoo! Shopping - with improved product search
-- Jiri Kuthan http://iptel.org/~jiri/
Jiri Kuthan wrote:
[8<---snip--- Stuff Deleted---8<---snip---]
The stable branch (the one with the special tag) is fully compatible to what we released as 8.11. The same for SEMS. Really better use them as I tested the example I sent over with them.
FYI: I've confirmed with Jiri that the 'special tags' of which he speaks here are "rel_0_8_11" and "ser_rel_0_8_11" for SER and SEMS respectively. You can retrieve these specifically by using the "-r rel_0_8_11" and "-r ser_rel_0_8_11" options after the checkout command in your CVS command line (i.e.: cvs -d:pserver:anonymous@cvs.ser.berlios.de:/cvsroot/ser -z9 co -r rel_0_8_11 sip_router).
- Jim
-
Gavin Bensom -
Jim Burwell -
Jiri Kuthan