Re: Load balancing MT with preferred SMSC
Its strange but I have a such scheme and it is working for me on my test suite with kannel svn-r5173 :) The only different thig is that I route MT by prefix, not by smsc-id. Nevermind, with smsc-id it will be working too. # fake.conf group = smsc smsc = fake smsc-id = vasgw1 port = 12000 log-file = "/var/log/kannel/vasgw1.log" log-level = 0 allowed-prefix="+791;+798" group = smsc smsc = fake smsc-id = vasgw2 port = 12001 log-file = "/var/log/kannel/vasgw2.log" log-level = 0 allowed-prefix="+791;+798" preferred-prefix="+791;+798" Now. Run some tests for MT: Run in two consoles: ``test/fakesmsc -m 1 -r 12000' and in the other ``test/fakesmsc -m 1 -r 12001'. Let's see http://localhost:13000/status: Box connections: smsbox:(none), IP 127.0.0.1 (0 queued), (on-line 0d 0h 0m 51s) smsbox:nc-prod, IP 127.0.0.1 (0 queued), (on-line 0d 0h 0m 49s) ... vasgw1[vasgw1]FAKE:12000 (online 5s, rcvd: sms 0 (0.00,0.00,0.00) / dlr 0 (0.00,0.00,0.00), sent: sms 0 (0.00,0.00,0.00) / dlr 0 (0.00,0.00,0.00), failed 0, queued 0 msgs) vasgw2[vasgw2]FAKE:12001 (online 20s, rcvd: sms 0 (0.00,0.00,0.00) / dlr 0 (0.00,0.00,0.00), sent: sms 0 (0.00,0.00,0.00) / dlr 0 (0.00,0.00,0.00), failed 0, queued 0 msgs) Now. In my scheme under the opensmppbox I've got ESME nc-prod. Let's send test SMS on +79111077151 by nc-prod. And you see on fakesmsc runned on port 12001 (vasgw2) our SMS - it because of preferred-prefix on vasgw2: [root@kannel kannel]# test/fakesmsc -m 1 -r 12001 2016-09-23 19:49:54 [6868] [0] INFO: Debug_lvl = -1, log_file = , log_lvl = 0 2016-09-23 19:49:54 [6868] [0] INFO: Entering interactive mode. Type your message on the command line 2016-09-23 19:49:54 [6868] [0] INFO: fakesmsc starting 2016-09-23 19:49:54 [6868] [0] DEBUG: Connecting to <127.0.0.1> 2016-09-23 19:55:03 [6868] [0] INFO: Got message 1: <4385 +79111077151 ucs-2 %FE%FF%00t%00e%00s%00t%001> ^C2016-09-23 19:55:23 [6868] [0] INFO: fakesmsc: 0 messages sent and 1 received 2016-09-23 19:55:23 [6868] [0] INFO: fakesmsc: total running time 328.8 seconds 2016-09-23 19:55:23 [6868] [0] INFO: fakesmsc: terminating [root@kannel kannel]# I stopped this fakesmsc, whie another one still working on 12001. Not lets again see Kannel status: vasgw1[vasgw1]FAKE:12000 (online 501s, rcvd: sms 0 (0.00,0.00,0.00) / dlr 0 (0.00,0.00,0.00), sent: sms 0 (0.00,0.00,0.00) / dlr 0 (0.00,0.00,0.00), failed 0, queued 0 msgs) vasgw2[vasgw2]FAKE:12001 (re-connecting, rcvd: sms 0 (0.00,0.00,0.00) / dlr 1 (0.00,0.00,0.00), sent: sms 1 (0.00,0.00,0.00) / dlr 0 (0.00,0.00,0.00), failed 0, queued 0 msgs) Let's do test again on the same number. We must see that nc-prod will send to vasgw1 bacause of vasgw2 is not ready: [root@kannel kannel]# test/fakesmsc -m 1 -r 12000 2016-09-23 19:50:09 [6879] [0] INFO: Debug_lvl = -1, log_file = , log_lvl = 0 2016-09-23 19:50:09 [6879] [0] INFO: Entering interactive mode. Type your message on the command line 2016-09-23 19:50:09 [6879] [0] INFO: fakesmsc starting 2016-09-23 19:50:09 [6879] [0] DEBUG: Connecting to <127.0.0.1> 2016-09-23 20:01:05 [6879] [0] INFO: Got message 1: <4385 +79111077151 ucs-2 %FE%FF%00t%00e%00s%00t%002> See? It's working like a charm! Now see access.log: [root@kannel kannel]# tail -4 /var/log/kannel/access.log 2016-09-23 19:55:02 Sent SMS [SMSC:vasgw2] [SVC:nc-prod] [ACT:] [BINF:CMT] [FID:f176f8ab-812b-4cb6-822b-f883b2bef397] [META:?smpp?] [from:4385] [to:+79111077151] [flags:1:2:-1:0:19] [msg:12:FEFF00740065007300740031] [udh:0:] 2016-09-23 19:55:02 Receive DLR [SMSC:vasgw2] [SVC:nc-prod] [ACT:] [BINF:] [FID:f176f8ab-812b-4cb6-822b-f883b2bef397] [META:?orig_msg?dlr_mask=19&] [from:4385] [to:+79111077151] [flags:-1:-1:-1:-1:1] [msg:0:] [udh:0:] 2016-09-23 20:01:04 Sent SMS [SMSC:vasgw1] [SVC:nc-prod] [ACT:] [BINF:CMT] [FID:4e53838b-9773-4ba7-960d-20f7b54be70d] [META:?smpp?] [from:4385] [to:+79111077151] [flags:1:2:-1:0:19] [msg:12:FEFF00740065007300740032] [udh:0:] 2016-09-23 20:01:04 Receive DLR [SMSC:vasgw1] [SVC:nc-prod] [ACT:] [BINF:] [FID:4e53838b-9773-4ba7-960d-20f7b54be70d] [META:?orig_msg?dlr_mask=19&] [from:4385] [to:+79111077151] [flags:-1:-1:-1:-1:1] [msg:0:] [udh:0:] [root@kannel kannel]# And configuration of my opensmppbox: # opensmppbox.conf group = core dlr-storage = sqlite3 include = "/etc/kannel/dlr-sqlite3.conf" group = opensmppbox opensmppbox-id = local-smpp opensmppbox-port = 1521 bearerbox-host = localhost bearerbox-port = 13001 log-level = 0 log-file = /var/log/kannel/opensmppbox.log our-system-id = local-smpp smpp-logins = "/etc/kannel/smpplogins.txt" So... it's working. May be I don't understood you problem well, write me. -- С уважением, Денис Давыдов 2016-09-17 14:48 GMT+03:00 Davor Spasoski : > Hi, > > > > I’m trying to use opensmppbox and kannel to act as SMPP proxy. The SMSC > operator doesn’t allow direct connections and it has two SMSCs, one of > which is preferred and the other handles traffic if only the preferred > fails. *But, both are
Re: Load balancing MT with preferred SMSC
Thanks. Is it also kannel based? Davor Sent from my iPad > On 22.9.2016, at 19:39, vinayak mv wrote: > > Dear Davor, > > There is also an alternative solution for SMPP Server i.e. vsmppbox ,which > has more features compared to other smpp servers.you can find the details of > that in http://www.evoxtel.com > >> On 22-Sep-2016, at 7:32 PM, Stipe Tolj wrote: >> >> Am 21.09.2016 08:25, schrieb Davor Spasoski: >>> Hi, >>> >>> I realized yesterday that the reason the allowed/preferred trickery >>> doesn’t work is because opensmppbox doesn’t pass smsc-id dynamically. >>> It’s either a static value using the route-to-smsc directive or it’s >>> blank if this is omitted. The whole point of my usecase was to have >>> different ESMEs routed to different smscs and all that by using a single >>> opensmpp instance (IP/port) due to specific circumstances of the case I >>> need to solve. >>> >>> AFAICS, for this to work it needs development. >> >> Hi Davor, >> >> correct, the opensmppbox isn't able to handle such routing internally. For >> the purposes you intend to it's more suitable to use the commercial Kannel >> SMPP v5.0 server (smppbox), which is a true virtual SMSC solution allowing >> the same connection scheme, but with a major benefit in configuration >> ability and flexibility. >> >> Please let me know if you would like to hear more details and we can arrange >> for a test-drive on your own system to get going. >> >> -- >> Best Regards, >> Stipe Tolj >> >> --- >> Düsseldorf, NRW, Germany >> >> Kannel Foundation tolj.org system architecture >> http://www.kannel.org/http://www.tolj.org/ >> >> stolj at kannel.org st at tolj.org >> --- > Disclaimer: one.Vip DOO Skopje This e-mail (including any attachments) is confidential and may be protected by legal privilege. If you are not the intended recipient, you should not copy it, re-transmit it, use it or disclose its contents, but should return it to the sender immediately and delete your copy from your system. Any unauthorized use or dissemination of this message in whole or in part is strictly prohibited. Please note that e-mails are susceptible to change. one.Vip DOO Skopje shall not be liable for the improper or incomplete transmission of the information contained in this communication nor for any delay in its receipt or damage to your system. Please, do not print this e-mail unless it is necessary! Think about saving the environment! Напомена: оне.Вип ДОО Скопје Оваа електронска порака (вклучувајќи ги и прилозите) е доверлива и може да биде заштитена со правни привилегии. Доколку не сте лицето на кое таа му е наменета пораката, не треба да ја копирате, дистрибуирате или да ја откривате нејзината содржина, туку веднаш да ја препратите до испраќачот и да ја избришете оригиналната порака и сите нејзини копии од Вашиот компјутерски систем. Секое неовластено користење на оваа порака во целост или делови од истата е строго забрането. Ве молиме да забележите дека електронските пораки се подложни на промени. оне.Вип ДОО Скопје не презема одговорност за несоодветно или нецелосно пренесување на информациите содржани во оваа комуникација, ниту пак за било какво задоцнување на приемот или оштетувања на вашиот систем. Ве молиме не ја печатете оваа порака освен ако не е неопходно! Зачувајте ја природата!
Re: Load balancing MT with preferred SMSC
Hi Stipe, Thanks for confirming. Yes, I would like to have more details about the mentioned product. Davor Sent from my iPad > On 22.9.2016, at 16:03, Stipe Tolj wrote: > > Am 21.09.2016 08:25, schrieb Davor Spasoski: >> Hi, >> >> I realized yesterday that the reason the allowed/preferred trickery >> doesn’t work is because opensmppbox doesn’t pass smsc-id dynamically. >> It’s either a static value using the route-to-smsc directive or it’s >> blank if this is omitted. The whole point of my usecase was to have >> different ESMEs routed to different smscs and all that by using a single >> opensmpp instance (IP/port) due to specific circumstances of the case I >> need to solve. >> >> AFAICS, for this to work it needs development. > > Hi Davor, > > correct, the opensmppbox isn't able to handle such routing internally. For > the purposes you intend to it's more suitable to use the commercial Kannel > SMPP v5.0 server (smppbox), which is a true virtual SMSC solution allowing > the same connection scheme, but with a major benefit in configuration ability > and flexibility. > > Please let me know if you would like to hear more details and we can arrange > for a test-drive on your own system to get going. > > -- > Best Regards, > Stipe Tolj > > --- > Düsseldorf, NRW, Germany > > Kannel Foundation tolj.org system architecture > http://www.kannel.org/http://www.tolj.org/ > > stolj at kannel.org st at tolj.org > --- Disclaimer: one.Vip DOO Skopje This e-mail (including any attachments) is confidential and may be protected by legal privilege. If you are not the intended recipient, you should not copy it, re-transmit it, use it or disclose its contents, but should return it to the sender immediately and delete your copy from your system. Any unauthorized use or dissemination of this message in whole or in part is strictly prohibited. Please note that e-mails are susceptible to change. one.Vip DOO Skopje shall not be liable for the improper or incomplete transmission of the information contained in this communication nor for any delay in its receipt or damage to your system. Please, do not print this e-mail unless it is necessary! Think about saving the environment! Напомена: оне.Вип ДОО Скопје Оваа електронска порака (вклучувајќи ги и прилозите) е доверлива и може да биде заштитена со правни привилегии. Доколку не сте лицето на кое таа му е наменета пораката, не треба да ја копирате, дистрибуирате или да ја откривате нејзината содржина, туку веднаш да ја препратите до испраќачот и да ја избришете оригиналната порака и сите нејзини копии од Вашиот компјутерски систем. Секое неовластено користење на оваа порака во целост или делови од истата е строго забрането. Ве молиме да забележите дека електронските пораки се подложни на промени. оне.Вип ДОО Скопје не презема одговорност за несоодветно или нецелосно пренесување на информациите содржани во оваа комуникација, ниту пак за било какво задоцнување на приемот или оштетувања на вашиот систем. Ве молиме не ја печатете оваа порака освен ако не е неопходно! Зачувајте ја природата!
Re: Load balancing MT with preferred SMSC
Dear Davor, There is also an alternative solution for SMPP Server i.e. vsmppbox ,which has more features compared to other smpp servers.you can find the details of that in http://www.evoxtel.com > On 22-Sep-2016, at 7:32 PM, Stipe Tolj wrote: > > Am 21.09.2016 08:25, schrieb Davor Spasoski: >> Hi, >> >> I realized yesterday that the reason the allowed/preferred trickery >> doesn’t work is because opensmppbox doesn’t pass smsc-id dynamically. >> It’s either a static value using the route-to-smsc directive or it’s >> blank if this is omitted. The whole point of my usecase was to have >> different ESMEs routed to different smscs and all that by using a single >> opensmpp instance (IP/port) due to specific circumstances of the case I >> need to solve. >> >> AFAICS, for this to work it needs development. > > Hi Davor, > > correct, the opensmppbox isn't able to handle such routing internally. For > the purposes you intend to it's more suitable to use the commercial Kannel > SMPP v5.0 server (smppbox), which is a true virtual SMSC solution allowing > the same connection scheme, but with a major benefit in configuration ability > and flexibility. > > Please let me know if you would like to hear more details and we can arrange > for a test-drive on your own system to get going. > > -- > Best Regards, > Stipe Tolj > > --- > Düsseldorf, NRW, Germany > > Kannel Foundation tolj.org system architecture > http://www.kannel.org/http://www.tolj.org/ > > stolj at kannel.org st at tolj.org > --- >
Re: Load balancing MT with preferred SMSC
Am 21.09.2016 08:25, schrieb Davor Spasoski: Hi, I realized yesterday that the reason the allowed/preferred trickery doesn’t work is because opensmppbox doesn’t pass smsc-id dynamically. It’s either a static value using the route-to-smsc directive or it’s blank if this is omitted. The whole point of my usecase was to have different ESMEs routed to different smscs and all that by using a single opensmpp instance (IP/port) due to specific circumstances of the case I need to solve. AFAICS, for this to work it needs development. Hi Davor, correct, the opensmppbox isn't able to handle such routing internally. For the purposes you intend to it's more suitable to use the commercial Kannel SMPP v5.0 server (smppbox), which is a true virtual SMSC solution allowing the same connection scheme, but with a major benefit in configuration ability and flexibility. Please let me know if you would like to hear more details and we can arrange for a test-drive on your own system to get going. -- Best Regards, Stipe Tolj --- Düsseldorf, NRW, Germany Kannel Foundation tolj.org system architecture http://www.kannel.org/http://www.tolj.org/ stolj at kannel.org st at tolj.org ---
RE: Load balancing MT with preferred SMSC
Hi,
I realized yesterday that the reason the allowed/preferred trickery doesn’t
work is because opensmppbox doesn’t pass smsc-id dynamically. It’s either a
static value using the route-to-smsc directive or it’s blank if this is
omitted. The whole point of my usecase was to have different ESMEs routed to
different smscs and all that by using a single opensmpp instance (IP/port) due
to specific circumstances of the case I need to solve.
AFAICS, for this to work it needs development.
BR,
Davor
Davor Spasoski
From: DHC Admin [mailto:dhcad...@gmail.com]
Sent: 21 September 2016 04:16
To: Davor Spasoski
Cc: users@kannel.org
Subject: Re: Load balancing MT with preferred SMSC
Of course you have removed the # form those lines, right? Other than that, I
cannot tell why it's not working for you.
On Sat, Sep 17, 2016 at 8:48 AM, Davor Spasoski
mailto:davor.spaso...@onevip.mk>> wrote:
Hi,
I’m trying to use opensmppbox and kannel to act as SMPP proxy. The SMSC
operator doesn’t allow direct connections and it has two SMSCs, one of which is
preferred and the other handles traffic if only the preferred fails. But, both
are always active, i.e. bearerbox is normally bound to both.
I have a dozen of ESMEs that should connect to opensmppbox with a single bind
and then bearerbox should make two connections to smsc1 and smsc2 for each and
every esme. To simplify, the flow with one ESME would look like this:
___ _
ESME1 --> | Opensmppbox | --> | Bearerbox |---> |SMSC1|
| || | -
|___|| |---> |SMSC2|
|___| -
For each new ESME there would be a new set of binds from bearerbox to SMSCs and
the system-id of the esme should distinguish the rotue in bearerbox.
Hence, use-systemid-as-smsboxid is set to true in opensmppbox.conf
At the moment, I have two fake SMSCs with same SMSC-id and they share the load
as expected. However, no matter what I try with directives like
preferred-smsc-id and allowed-smsc-id, I can’t make a confgiration to make
bearerbox route all MT SMS to SMSC1 only and route to SMSC2 if only SMSC1 is
down.
This is part of my bearerbox configuration:
group = smsc
smsc = fake
port = 12000
smsc-id = vasgw
#allowed-smsc-id = "vasgw"
#preferred-smsc-id = "vasgw"
group = smsc
smsc = fake
port = 12001
smsc-id = vasgw
#allowed-smsc-id = "vasgw"
Also, bearebox should accept MO SMS from any of the SMSC1 and SMSC2
Any ideas how to achieve this?
BR,
Davor
Disclaimer: one.Vip DOO Skopje
This e-mail (including any attachments) is confidential and may be protected by
legal privilege. If you are not the intended recipient, you should not copy it,
re-transmit it, use it or disclose its contents, but should return it to the
sender immediately and delete your copy from your system. Any unauthorized use
or dissemination of this message in whole or in part is strictly prohibited.
Please note that e-mails are susceptible to change. one.Vip DOO Skopje shall
not be liable for the improper or incomplete transmission of the information
contained in this communication nor for any delay in its receipt or damage to
your system.
Please, do not print this e-mail unless it is necessary! Think about saving the
environment!
Напомена: оне.Вип ДОО Скопје
Оваа електронска порака (вклучувајќи ги и прилозите) е доверлива и може да биде
заштитена со правни привилегии. Доколку не сте лицето на кое таа му е наменета
пораката, не треба да ја копирате, дистрибуирате или да ја откривате нејзината
содржина, туку веднаш да ја препратите до испраќачот и да ја избришете
оригиналната порака и сите нејзини копии од Вашиот компјутерски систем. Секое
неовластено користење на оваа порака во целост или делови од истата е строго
забрането. Ве молиме да забележите дека електронските пораки се подложни на
промени. оне.Вип ДОО Скопје не презема одговорност за несоодветно или нецелосно
пренесување на информациите содржани во оваа комуникација, ниту пак за било
какво задоцнување на приемот или оштетувања на вашиот систем.
Ве молиме не ја печатете оваа порака освен ако не е неопходно! Зачувајте ја
природата!
Disclaimer: one.Vip DOO Skopje
This e-mail (including any attachments) is confidential and may be protected by
legal privilege. If you are not the intended recipient, you should not copy it,
re-transmit it, use it or disclose its contents, but should return it to the
sender immediately and delete your copy from your system. Any unauthorized use
or dissemination of this message in whole or in part is strictly prohibited.
Please note that e-mails are susceptible to change. one.Vip DOO Skopje shall
not be liable for the improper or incomplete transmission of the information
contained in this communication nor for any delay in its receipt or dam
Re: Load balancing MT with preferred SMSC
Of course you have removed the # form those lines, right? Other than that, I cannot tell why it's not working for you. On Sat, Sep 17, 2016 at 8:48 AM, Davor Spasoski wrote: > Hi, > > > > I’m trying to use opensmppbox and kannel to act as SMPP proxy. The SMSC > operator doesn’t allow direct connections and it has two SMSCs, one of > which is preferred and the other handles traffic if only the preferred > fails. *But, both are always active*, i.e. bearerbox is normally bound to > both. > > I have a dozen of ESMEs that should connect to opensmppbox with a single > bind and then bearerbox should make two connections to smsc1 and smsc2 for > each and every esme. To simplify, the flow with one ESME would look like > this: > > > > ___ _ > > ESME1 --> | Opensmppbox | --> | Bearerbox |---> |SMSC1| > > | || | - > > |___|| |---> |SMSC2| > > |___| - > > > > For each new ESME there would be a new set of binds from bearerbox to > SMSCs and the system-id of the esme should distinguish the rotue in > bearerbox. > > Hence, use-systemid-as-smsboxid is set to true in opensmppbox.conf > > > > At the moment, I have two fake SMSCs with same SMSC-id and they share the > load as expected. However, no matter what I try with directives like > preferred-smsc-id and allowed-smsc-id, I can’t make a confgiration to make > bearerbox route *all MT SMS to SMSC1 only and route to SMSC2 if only > SMSC1* is down. > > > > This is part of my bearerbox configuration: > > > > group = smsc > > smsc = fake > > port = 12000 > > smsc-id = vasgw > > #allowed-smsc-id = "vasgw" > > #preferred-smsc-id = "vasgw" > > > > group = smsc > > smsc = fake > > port = 12001 > > smsc-id = vasgw > > #allowed-smsc-id = "vasgw" > > > > Also, bearebox should accept MO SMS from any of the SMSC1 and SMSC2 > > > > Any ideas how to achieve this? > > > > BR, > > *Davor* > > > > -- > > Disclaimer: one.Vip DOO Skopje > This e-mail (including any attachments) is confidential and may be > protected by legal privilege. If you are not the intended recipient, you > should not copy it, re-transmit it, use it or disclose its contents, but > should return it to the sender immediately and delete your copy from your > system. Any unauthorized use or dissemination of this message in whole or > in part is strictly prohibited. Please note that e-mails are susceptible to > change. one.Vip DOO Skopje shall not be liable for the improper or > incomplete transmission of the information contained in this communication > nor for any delay in its receipt or damage to your system. > Please, do not print this e-mail unless it is necessary! Think about > saving the environment! > > Напомена: оне.Вип ДОО Скопје > Оваа електронска порака (вклучувајќи ги и прилозите) е доверлива и може да > биде заштитена со правни привилегии. Доколку не сте лицето на кое таа му е > наменета пораката, не треба да ја копирате, дистрибуирате или да ја > откривате нејзината содржина, туку веднаш да ја препратите до испраќачот и > да ја избришете оригиналната порака и сите нејзини копии од Вашиот > компјутерски систем. Секое неовластено користење на оваа порака во целост > или делови од истата е строго забрането. Ве молиме да забележите дека > електронските пораки се подложни на промени. оне.Вип ДОО Скопје не презема > одговорност за несоодветно или нецелосно пренесување на информациите > содржани во оваа комуникација, ниту пак за било какво задоцнување на > приемот или оштетувања на вашиот систем. > Ве молиме не ја печатете оваа порака освен ако не е неопходно! Зачувајте > ја природата! >
