Hi
Here are quite a few patches for the SMPP module. Hope they are usefull.
1. using smpp_pdu_get_opt to get if optional params if set and ver = 0x34.
For now only looking at the message_payload in MO msgs and the
receipted_message_id in a submit_sm_resp
2. SSL support: smsc config var: is-ssl
Hi everyone,
Here is a patch I have created for SMPP throttling. To easily
duplicate the bug you can take the following actions:
-- Configure SMPP bind with very low throughput (ie: 0.1)
-- Send 100 messages in quick succession
What you can see from the debug output times is that when
send_messa
Hi Nisan,
I've applied your two patches (smsc_smpp.c, smpp_pdu.c) to current cvs
tree, but getting errors regarding to new configuration directives
dump-pdu and pack-7bit:
2003-03-27 12:36:18 [0] INFO: Debug_lvl = 0, log_file = , log_lvl = 0
2003-03-27 12:36:18 [0] ERROR: Group 'smsc' may not c
Hi
At 12:39 PM 3/27/03 +0400, David Chkhartishvili wrote:
Hi Nisan,
I've applied your two patches (smsc_smpp.c, smpp_pdu.c) to current cvs
tree, but getting errors regarding to new configuration directives
dump-pdu and pack-7bit:
agh.. i forgot to add the diffs for gwlib/cfg.def... comming up.
Hi
At 12:39 PM 3/27/03 +0400, David Chkhartishvili wrote:
Hi Nisan,
I've applied your two patches (smsc_smpp.c, smpp_pdu.c) to current cvs
tree, but getting errors regarding to new configuration directives
dump-pdu and pack-7bit:
missing patch piece
nisan
--- ../cvs/gateway/gwlib/cfg.def
Nisan,
sorry to be nastly, but could you please resend the "whole" patch in
*one* diff file and at email attachement rather then enbedding in the
email body.
Thanks.
Stipe
[EMAIL PROTECTED]
---
Wapme Systems AG
Vogelsanger Weg 80
forwarding this to the list.
Stipe
[EMAIL PROTECTED]
---
Wapme Systems AG
Vogelsanger Weg 80
40470 Düsseldorf
Tel: +49-211-74845-0
Fax: +49-211-74845-299
E-Mail: [EMAIL PROTECTED]
Internet: http://www.wapme-systems.de
All,
I was performing some checks on smpp throttling and found the same
behaviour as vincent found below but this time in smsc_smpp.c.
Specific behaviour I found was that I could dump a load of messages into
the queue and while there was no further activity the queue would drain
at the requi
Hello all,
as promised I rebased my SMPP TLV patch and post is here for review.
Please anybody if possible, write a userguide because I don't have time to
do it and without userguide this patch will not get into mainline.
Short description...
In the config
group = smpp-tlv
name = some-na
Hi,
yes, your patch seems to fix gwthread_wakeup but it's wrong too because
we _may_ not sleep on transceiver bind because we could take too long to
respond to dlr/mo. I have patch here for throttling, will try to rebase
it...
Thanks,
Alex
Donald Jackson schrieb:
Hi everyone,
Here is a pa
Hi,
try attached patch... main loop in smpp module should be fixed as well
but this another story...
Thanks,
Alex
smpp_throttling.patch
Description: Binary data
Am 10.02.2009 um 14:40 schrieb Alexander Malysh:
Hi,
yes, your patch seems to fix gwthread_wakeup but it's wrong too
beca
Hi Alex,
I'm not sure I understand your comment entirely, you say this patch might
cause us to take too long to respond to a DLR/MO, which I understand, BUT
this scenario is already possible if there are no other events calling the
thread to wake up?
Thanks,
Donald
2009/2/10 Alexander Malysh
>
Hi Donald,Am 12.02.2009 um 15:28 schrieb Donald Jackson:Hi Alex,I'm not sure I understand your comment entirely, you say this patch might cause us to take too long to respond to a DLR/MO, which I understand, BUT this scenario is already possible if there are no other events calling the thread to wa
Hi Alex,
It's not a work around for the problem you mentioned, its a fix for the
throughput sleep time. The potential side effect as you say is it might just
increase the likelihood of a MO/DLR timeout (but still highly unlikely),
which is an unrelated/outside problem relating to the transceiver b
I'd like to resubmit my patch to smsc_smpp.c. We've had this running in
a productive environment for some time now, and it works well. The
process has been running for 14 days straight now, and correctly handles
most types of MO traffic. In particular, we have been able to
successfully forward
Hi
Patch to fix the SMPP online times bug.
conn->connect_time is a share variable amongst threads and is not protected.
This patch works for us. (FYI the large online times one sees is the unix
timestamp time)
Nisan--- ../cvs/gateway/gw/smsc/smsc_smpp.c Mon Feb 16 22:26:34 2004
+++ gw/smsc/smsc
Hi,
attached you can find patch with new version of optional params handling in
smpp pdu. With this version Dict* is killed and all opt. params are treated
the same as mandatory and could be easier accessed. Now pack/unpack for int
values works too.
Note: not available in pdu opt. params are in
Hi,
attached is a patch that implements relaxed source_addr checks in SMPP and
adds additionally error reporting why kannel rejected this MO.
Comments & votes please!
P.S. IMO: this patch should go into 1.4.1 because some SMSC doesn't work
with 1.4.0 anymore though they worked fine with 1.2.1.
Hi list,
forwarded Stuart's patch in order to detach from mail message reference... A lot
of us use fancy MUAs that dispay cascaded threads via reference and this message
got to Vincent's comment from 2006-06-12, and hence a tooo far away from the
"top of the list" :)
A reminder to all:
Plea
Alexander.
First of all, many many thanks for this :)
Long awaited patch!
I will be setting up a test SMPP connection with OpenMarket from the US, I
hope this week, so I'll test it with them.
Will let you know about the results!!!
Question, will it compile against Kannel 1.4.1 or needs
Hi,
Juan Nin wrote:
> Alexander.
>
> First of all, many many thanks for this :)
> Long awaited patch!
>
> I will be setting up a test SMPP connection with OpenMarket from the US, I
> hope this week, so I'll test it with them.
> Will let you know about the results!!!
>
> Question, will
On 8/6/07, Alexander Malysh <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> Juan Nin wrote:
>
> > Alexander.
> >
> > First of all, many many thanks for this :)
> > Long awaited patch!
> >
> > I will be setting up a test SMPP connection with OpenMarket from the US,
> I
> > hope this week, so I'll te
I think I can do the mods if Martin is too busy.
Alex, _great_ job and thanks a lot for making this a reality.
Regards,
Alejandro
On 8/6/07, Juan Nin <[EMAIL PROTECTED]> wrote:
>
> On 8/6/07, Alexander Malysh <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > Juan Nin wrote:
> >
> > > Alexander.
> > >
So far I've tested the sendsms -> SMSC portion using Logica SMSC
simulator and it works like a charm! Great job Alex!
I've also made a patch for Sqlbox-standalone (already sent to dev list).
I'll test the SMSC -> Kannel portion as soon as I can get a hand on a
SMSC and/or Simulator capable of sen
Hi,
any progress on testing and userguide :)?
Alejandro Guerrieri wrote:
> So far I've tested the sendsms -> SMSC portion using Logica SMSC
> simulator and it works like a charm! Great job Alex!
>
> I've also made a patch for Sqlbox-standalone (already sent to dev list).
>
> I'll test the SMSC
Hi Alex!
Unfortunately I haven't been able to test it yet... :(
I'm opening a new company, and starting this monday, so I've been very busy!
Compiled Kannel with the patch with no problem
On tuesday a partner of mine from the US is comming down here, so
during the week I'll make tests with his
Hi,
If this is known to somebody, please tell:
Will this patch work for capturing optional parameters presend in
DLR messages ? That is can I use &meta-data=%D in my DLR-URL?
Thanks,
Kyriacos Sakkas
Alexander Malysh wrote:
> Hi,
>
> any progress on testing and userguide :)?
>
> Al
Hi,
yes, the format is OK. I'm not sure whether the value of HTTP header should
be url-encoded?
If it doesn't work post the whole debug log (smsbox + bearerbox).
Kyriacos Sakkas wrote:
> Hi,
> Anybody has some extra info on how to us with post?
> (X-Kannel-Meta-Data). I am trying but not ab
Hi,
Anybody has some extra info on how to us with post?
(X-Kannel-Meta-Data). I am trying but not able it seems to get the
proper format.
Would this be considered ok?
X-Kannel-Meta-Data: ?smpp?mytag=12
Definition is:
group = smpp-tlv
name = mytag
tag = 0x1521
type = octetstring
length = 32
Th
Hi!
3 months have passed by, and just today I was able to start testing this!!!
Haven't been able to test too much yet though
I've sent some premium messages, making them billable and setting it's
pricepoints via TLVs and everything went ok
Tomorrow I'm going to make more tests, I want to test it
Hi Alexander!
I've made some tests with your patch.
These are the Optional SMPP parameters I've configured:
# Specifies if message must or not be billed
group = smpp-tlv
name = charge_type
tag= 0x2151
type = integer
length = 1
# Specifies amount to be billed
group = smpp-tlv
name =
any feedback on this?
thnx again!
Juan
On Nov 8, 2007 3:17 PM, Juan Nin <[EMAIL PROTECTED]> wrote:
> Hi Alexander!
>
> I've made some tests with your patch.
> These are the Optional SMPP parameters I've configured:
>
>
> # Specifies if message must or not be billed
> group = smpp-tlv
> name
Hi,
seems I just forgot about DLRs and data_sm :)
Please try attached patch instead of previous one.
Juan Nin wrote:
> any feedback on this?
>
> thnx again!
>
> Juan
>
>
> On Nov 8, 2007 3:17 PM, Juan Nin <[EMAIL PROTECTED]> wrote:
>> Hi Alexander!
>>
>> I've made some tests with your patc
On Nov 9, 2007 11:54 AM, Alexander Malysh <[EMAIL PROTECTED]> wrote:
> Hi,
>
> seems I just forgot about DLRs and data_sm :)
>
> Please try attached patch instead of previous one.
cool! :)
I just tried it, and now it's passing it!
BUT, it's not passing back all of the received optional parameter
Hi again,
in metadata you will receive only vendor specific TLVs.
It could be expanded to all TLVs if needed.
Juan Nin wrote:
> On Nov 9, 2007 11:54 AM, Alexander Malysh <[EMAIL PROTECTED]> wrote:
>> Hi,
>>
>> seems I just forgot about DLRs and data_sm :)
>>
>> Please try attached patch instead
oks, can u give me any clue on how to expand it to all TLVs?
not sure if I'll be able to do it, I'm not too much of a C programmer,
but if not much has to be touched, maybe I can do it...
thnx again!
Juan
On Nov 9, 2007 12:55 PM, Alexander Malysh <[EMAIL PROTECTED]> wrote:
> Hi again,
>
> in m
It's easier for me todo it myself instead of write how to do it :)
Juan Nin wrote:
> oks, can u give me any clue on how to expand it to all TLVs?
>
> not sure if I'll be able to do it, I'm not too much of a C programmer,
> but if not much has to be touched, maybe I can do it...
>
> thnx again!
oks, great! :)
to be able to plan my stuff, when do you think you can have some time to do it?
thnx again
On Nov 9, 2007 1:31 PM, Alexander Malysh <[EMAIL PROTECTED]> wrote:
> It's easier for me todo it myself instead of write how to do it :)
>
>
> Juan Nin wrote:
>
> > oks, can u give me any c
Hi,
I will try to look into this when I have some spare time but it was not the
intention of the patch. The patch was only to allow operator specific TLVs.
TLVs from SMPP spec. should be handled by kannel on regular basis (IMHO).
Juan Nin wrote:
> oks, great! :)
>
> to be able to plan my stuf
i agree
doing it separately as to integrate it with the kannel regular code
would be more difficult?
On Nov 9, 2007 3:02 PM, Alexander Malysh <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I will try to look into this when I have some spare time but it was not the
> intention of the patch. The patch was o
Minus attachments.
Kyriacos Sakkas wrote:
> Hi,
> Trying to compile against cvs, I segfault. Diring compile the only
> "error" is:
>
> gw/meta_data.c: In function âmeta_data_set_valueâ:
> gw/meta_data.c:338: warning: passing argument 2 of âdict_putâ discards
> qualifiers from pointer target t
Hi,
the warnings while compile are OK.
When kannel segfaults? when compile or starting kannel? If when starting
kannel please provide backtrace.
Kyriacos Sakkas wrote:
> Minus attachments.
>
>
> Kyriacos Sakkas wrote:
>> Hi,
>> Trying to compile against cvs, I segfault. Diring compile the
Hi Alexander,
So us to be clear, me programing credential are not great, so I will
give the backtrace a go, but if you thing some specials parameters to
gdb would help, please let me know.
Anyway the segfault is at run time, I will try and post a backtrace shortly.
Kyriacos Sakkas
Alexander Mal
Hi,
I just recompiled, and it looks stable, the difference was that up
to now I had been using "--with-mysql" on the configure, which to be
honest I did not need in this instance, just a force of habit. Anyway I
will now test and if anything comes up I will let you know, but it does
look like
If my packet capturing is correct, everything is parsed ok, but the TLVs
do not get added to the PDU.
Also my log file:
2007-11-26 15:58:08 [4930] [6] DEBUG: SMPP PDU 0x667eb0 dump:
2007-11-26 15:58:08 [4930] [6] DEBUG: type_name: enquire_link_resp
2007-11-26 15:58:08 [4930] [6] DEBUG: comman
Hi,
I suppose you didn't defined TLVs in the config and group in meta_data named
smpp instead of smpp-tlv. Example:
In the config
group = smpp-tlv
name = MBbilling
tag = 0x1601
type = integer|nulterminated|octetstring
length = 4
meta_data=?smpp?MBbilling=XXX&...
Kyriacos Sakkas wrote:
>
Call: (Relevant values inserted of courser)
$post .= "X-Kannel-Meta-Data:
?smpp-tlv?MBbilling=".$bill."&MBoperator=".$operatorid."&MBcontentType=100&MBcommand=START&MBsubDate=".date('U000')."&MBserviceId=XXX\r\n";
Definitions: (Had all as octstring, switched to nullterm for those with
no d
That's what Alexandar just said...
You're using:
?smpp-tlv?MBbilling=
and it should be:
?smpp?MBbilling=
regards,
Juan
On Nov 26, 2007 12:33 PM, Kyriacos Sakkas <[EMAIL PROTECTED]> wrote:
> Call: (Relevant values inserted of courser)
>$post .= "X-Kannel-Meta-Data:
> ?smpp-tlv?MBbillin
Please read carefully :)
Kyriacos Sakkas wrote:
> Call: (Relevant values inserted of courser)
>$post .= "X-Kannel-Meta-Data:
> ?smpp-tlv?MBbilling=".$bill."&MBoperator=".
^^ group should be ?smpp? instead if ?smpp-tlv?
>
$operatorid."&MBcontentType=100&MBcommand=START&MBsubDate=
hi All,
That seems to have sorted the parameters missing from PDU error, but
as seen below something dies after I submit one or two messages. looking
into it, as I had some minor issues still pending here with some TLVs,
but if something pops to mind please let me know
2007-11-26 16:46:33 [51
Okay, to comply with Kannel's common practices, hereby I send in a patch for
open smppbox that allows for all parts of multipart messages to be sent via
the same smsc (letting bearerbox split the message up).
The patch applies to current svn trunk of smppbox.
Known issue: This patch submits a del
> I'd like to resubmit my patch to smsc_smpp.c. We've had this running in
> a productive environment for some time now, and it works well. The
> process has been running for 14 days straight now, and correctly handles
> most types of MO traffic. In particular, we have been able to
> successfully fo
Hi All
A small patch to get the values of the optional SMPP params.
Added: smpp_pdu_get_opt(SMPP_PDU *pdu, unsigned long opt_tag);
Nisan--- ../../cvs/gateway/gw/smsc/smpp_pdu.cMon Mar 17 07:29:56 2003
+++ ../../gateway-clickcvs/gw/smsc/smpp_pdu.c Wed Mar 26 16:48:47 2003
@@ -310,6 +310,5
Hi all,
for the more easily testing of smpp timeout patches, here is the combined one.
for more details, what every patch does, please see appropriate mail threads:
1) [Patch] To add timeouts to SMPP connections
2) [PATCH] adds wait-ack to smpp
Please review and test it. Comments
Hi List,
attached patch should fix a shutdown sequence for smpp driver. The problem is
that smpp module should read as long no unbind_resp received otherwise we
will missing #max-pending-submits ack's from smsc.
smpp_properly_shutdown.diff:
smsc/smsc_smpp.c | 22 +++---
smsccon
Nisan Bloch wrote:
>
> Patch to fix the SMPP online times bug.
> conn->connect_time is a share variable amongst threads and is not protected.
>
> This patch works for us. (FYI the large online times one sees is the unix
> timestamp time)
+1, while also the global conn status variable has to be l
Hi
part two of this patch:
setting smpp->conn->connect_time = -1 in io_thread is a problem as well -
one can then end up with an onlinetime of time() - (-1)
the smscconn functions do this anyway
nisan
At 07:26 PM 2004/03/11, you wrote:
Nisan Bloch wrote:
>
> Patch to fix the SMPP online times bug
> setting smpp->conn->connect_time = -1 in io_thread is a problem as well -
> one can then end up with an onlinetime of time() - (-1)
> the smscconn functions do this anyway
nop, there is no "time() - (-1)" anywhere in the smpp module code, or
am I missing something? Please drop me the lines if an
Hi
Ok this is what happens
in smpp_smsc:io_thread(.
smpp->conn->connect_time = -1
then in the smscconn modules
smscconn.c:int smscconn_info
infotable->online = time(NULL) - conn->connect_time;
So this is a odd race condition - also none of the other smsc modules
explicitly s
Hi,
have you notice in bb_smscconn.c:bb_smscconn_status(...):
switch (info.status) {
case SMSCCONN_ACTIVE:
case SMSCCONN_ACTIVE_RECV:
sprintf(tmp3, "online %lds", info.online);
break;
case SMSCCONN_DISCONNECTED:
that mean
Hi,
no objections were there , commited to cvs...
On Tuesday 23 March 2004 15:06, Alexander Malysh wrote:
> Hi,
>
> attached you can find patch with new version of optional params handling in
> smpp pdu. With this version Dict* is killed and all opt. params are treated
> the same as mandatory an
Hi,
as no objection were here, commited to cvs.
Alexander Malysh wrote:
> Hi,
>
> attached is a patch that implements relaxed source_addr checks in SMPP and
> adds additionally error reporting why kannel rejected this MO.
>
> Comments & votes please!
>
> P.S. IMO: this patch should go into 1.
All,
I was performing some checks on smpp throttling and found the same
behaviour as vincent found below but this time in smsc_smpp.c.
Specific behaviour I found was that I could dump a load of messages into
the queue and while there was no further activity the queue would drain
at the requi
el Development list"
Sent: Friday, September 29, 2006 3:17 PM
Subject: Re: [Fwd: [PATCH] smpp smsc throttling]
All,
I was performing some checks on smpp throttling and found the same
behaviour as vincent found below but this time in smsc_smpp.c.
Specific behaviour I found was that I cou
Vincent CHAVANIS wrote:
I need that we have to think about a global resolution of this issue.
The patch i've submited for emi/ucp smsc need to be implemented
in a higher level than inside the smsc driver.
yep, agree'ing here.
Stipe
Looks good. +1
Nikos
- Original Message -
From: "Rene Kluwen"
To: "'Kannel Devel'"
Sent: Thursday, June 17, 2010 9:25 PM
Subject: [PATCH] SMPP box multipart messages
Okay, to comply with Kannel's common practices, hereby I send in a patch
for
ope
Rene,
Looks good. +1
Though i dont like the "for (;;) {" approach in catenate_msg very much... it
looks stressing before going through the code in detail ;)
I'd rather have a do { .. } while(++max > total) -> and then instead of
unreachable return do a failure code...
But then again it seems like
I changed it. It does look tidier.
== Rene
From: konstan...@appcell.net [mailto:konstan...@appcell.net] On Behalf Of
Konstantin Vayner
Sent: vrijdag 18 juni 2010 9:04
To: Rene Kluwen
Cc: Kannel Devel
Subject: Re: [PATCH] SMPP box multipart messages
Rene,
Looks good. +1
And right away committed to svn (earlier), since there were no objections.
== Rene
From: devel-boun...@kannel.org [mailto:devel-boun...@kannel.org] On Behalf Of
Rene Kluwen
Sent: vrijdag 18 juni 2010 15:05
To: 'Konstantin Vayner'
Cc: 'Kannel Devel'
Subject: RE: [PATCH
Hi,
Attached is a patch that allows passing the command_status on SMPP as
meta-data, on the smpp_error_code parameter, so on the logs (and dlr-url)
you'd get something like:
*[META:?smpp?smpp_error_code=72&]*
*
*
This would be command status value (which is 0 for accepted messages and a
positive
Hi list, Alex
any bad behaviour with these patches?
please vote for commiting...
On Wednesday 20 August 2003 20:01, Alexander Malysh wrote:
> Hi all,
>
> for the more easily testing of smpp timeout patches, here is the combined
> one. for more details, what every patch does, please see appropria
IL PROTECTED]>
Cc: "Alex Judd" <[EMAIL PROTECTED]>
Sent: Tuesday, September 02, 2003 9:44 AM
Subject: Re: [PATCH] SMPP inactivity+transaction timeouts
> Hi list, Alex
>
> any bad behaviour with these patches?
>
> please vote for commiting...
>
> On Wednesday
this patch has been commited by Alexander to cvs.
Stipe
[EMAIL PROTECTED]
---
Wapme Systems AG
Vogelsanger Weg 80
40470 Düsseldorf
Tel: +49-211-74845-0
Fax: +49-211-74845-299
E-Mail: [EMAIL PROTECTED]
Internet: http://www.wapme-sy
Hi,
FYI: just applied to cvs...
On Tuesday 02 September 2003 17:06, Alexander Malysh wrote:
> Hi List,
>
> attached patch should fix a shutdown sequence for smpp driver. The problem
> is that smpp module should read as long no unbind_resp received otherwise
> we will missing #max-pending-submits
Something that I was thinking after that discussion we had today, is the
following:
It sounds good idea to me to add the protocol on the ACK/NACK DLRs text for
the mentioned reason.
Now, on regular DLRs we might be missing a similar approach...
This is a sample DLR log:
2012-10-24 22:18:17 Recei
Hi Alex,
this patch is no go, because you put SMPP specific handling into abstract
bb_smscconn.
As to the discussion itself. We use error codes in our apps as well and we were
never in the
situation that we have to know protocol from the meta-data or message itself.
We have mapping
of SMSC nam
Hi!
Yesterday we were talking about the same thing, that an ACK is an ACK, so
you don't really need the error code there.
But IMHO it anyway makes it more tidy to use the same approach for both ACK
and NACK, providing the same syntax on both.
It won't provide any real benefit to anyone, but looks
Alex,
I didn't expect the patch to be accepted, it was more of a "conversation
starter". Anyway, perhaps it could prove useful for some people or at least
as a guide (even about how NOT to do things) ;)
Passing the error code on ACK was more about consistency than anything
else. The protocol, as
Hi Alex,
I'm relieved to hear that :-)
Ok what we could do is the following:
ACK/PROTO///
NACK/PROTO/ERRCODE/ERR DESCR/
With this format we easy split DLR message on / and we have all the infos.
Meta-data hack would be too fragile for me...
I'm not sure that we need error code for ACK but will
What about the protocol on regular DLRs which are submitted by the remote
SMSC on a deliver_sm?
Wouldn't a new parameter %whatever be a good idea?
That way we could use it on both cases and avoid modifying the current
ACK/NACK formats
Juan
On Fri, Oct 26, 2012 at 8:32 AM, Alexander Malysh wrote:
Hi list,
we had a case recently with an SMSC that provided the following SMPP DLR
payload:
id:2516372655 submit date:1604131525 done date:1604131525 stat:DELIVRD
which of course doesn't comply with the official DLR format of SMPP v3.4
spec. Nevertheless, we have a way to scan for needed it
Those of you connected to a large multinational SMSC who does not
support NATIONAL TON... ;-) ... may find this patch useful where you want
users to be able to set their originator / source address in national
format.
It is based on the unified prefix code.
--
Benjamin Lee
Level 2 71-75 City Rd
Hi List,
I know that current version with meta-data has the ability to inject custom TLV
but as we know that the version is not fully compatible yet it. So I want to
patch SMPP Module to inject custom TLV. I already add custom variable in smsbox
and integrate it with SQLBox. The next plan is to
+1 from me.
-Oorspronkelijk bericht-
Van: devel [mailto:devel-boun...@kannel.org] Namens Stipe Tolj
Verzonden: woensdag 27 april 2016 14:05
Aan: devel@kannel.org
Onderwerp: [PATCH] SMPP DLR item scan (old way)
Hi list,
we had a case recently with an SMSC that provided the following SMPP
Hi,
looks ok, +1.
Alex
> Am 27.04.2016 um 14:04 schrieb Stipe Tolj :
>
> Hi list,
>
> we had a case recently with an SMSC that provided the following SMPP DLR
> payload:
>
> id:2516372655 submit date:1604131525 done date:1604131525 stat:DELIVRD
>
> which of course doesn't comply with the o
Am 27.04.2016 14:04, schrieb Stipe Tolj:
Hi list,
we had a case recently with an SMSC that provided the following SMPP DLR
payload:
id:2516372655 submit date:1604131525 done date:1604131525 stat:DELIVRD
which of course doesn't comply with the official DLR format of SMPP v3.4
spec. Nevertheless
Hi list,
we already support "forcing" the SMPP defined 'data_coding' values to be
proxied via the meta-data construct, in order to allows converting from
UTF-8 to any designated target encoding for the SMPP based upstream.
But we couldn't handle the same for input that was presented with
cod
Hi,
why not make this global available as unified-prefix is ?
On Tuesday 25 March 2003 17:28, Benjamin Lee wrote:
> Those of you connected to a large multinational SMSC who does not
> support NATIONAL TON... ;-) ... may find this patch useful where you want
> users to be able to set their origin
I think it is SMSC specific... some SMSCs may have no problem with NATIONAL
TON... and anyway, the option was already there as SMSC specific for cimd2
and oisd... don't see it needing to be moved...
On Wednesday, 2003-03-26 at 03:47:28 AM, Alexander Malysh scribbled:
Content-Description: signed da
Benjamin Lee wrote:
>
> Those of you connected to a large multinational SMSC who does not
> support NATIONAL TON... ;-) ... may find this patch useful where you want
> users to be able to set their originator / source address in national
> format.
>
> It is based on the unified prefix code.
hmm,
LV but as we know that the version is not fully compatible yet it. So I want
> to patch SMPP Module to inject custom TLV. I already add custom variable in
> smsbox and integrate it with SQLBox. The next plan is to add it smpp module.
> But I still have no clue which part should I add in o
Hi,
I don’t get why we need this? if you would like to send not in UCS2 then
convert to UTF-8 (which is our internal coding) and force
via metadata data_coding. All chars in UCS2 are present in UTF-8.
Thanks,
Alex
> Am 08.11.2017 um 14:12 schrieb Stipe Tolj :
>
> Hi list,
>
> we already supp
Am 08.11.2017 15:37, schrieb amal...@kannel.org:
Hi,
I don’t get why we need this? if you would like to send not in UCS2 then
convert to UTF-8 (which is our internal coding) and force
via metadata data_coding. All chars in UCS2 are present in UTF-8.
Hi Alex,
yes, you're right, makes total se
If you have dlr-mask=24, to only receive ACK or NACK, then foreign_id is not
set on the dlr-url for %F when receiving ACK from the operator.
This small patch should set it.
Arne
--
Arne K. Haaje | www.drx.no
T: 69 51 15 52 | M: 92 88 44 66
---
you
getting a DLR at all?
BR,
Nikos
- Original Message -
From: "Arne K. Haaje"
To:
Sent: Thursday, February 19, 2009 4:51 PM
Subject: [PATCH] SMPP: With dlr-mask=24, foreign_id is not set
If you have dlr-mask=24, to only receive ACK or NACK, then foreign_id is
not
set
t; Nikos
> - Original Message -
> From: "Arne K. Haaje"
> To:
> Sent: Thursday, February 19, 2009 4:51 PM
> Subject: [PATCH] SMPP: With dlr-mask=24, foreign_id is not set
>
> > If you have dlr-mask=24, to only receive ACK or NACK, then foreign_id is
> &g
To: "Nikos Balkanas"
Cc:
Sent: Thursday, February 19, 2009 5:20 PM
Subject: Re: [PATCH] SMPP: With dlr-mask=24, foreign_id is not set
Yes,
bb_smscconn_sent(smpp->conn, msg, NULL) (just outside context in the
patch)
sends this using create_dlr_from_msg, so avoids creating a d
dd for
> all.
>
> Nevertheless this has nothing to do with your patch. +1.
>
> BR,
> Nikos
> - Original Message -
> From: "Arne K. Haaje"
> To: "Nikos Balkanas"
> Cc:
> Sent: Thursday, February 19, 2009 5:20 PM
> Subject:
: Thursday, February 19, 2009 5:20 PM
Subject: Re: [PATCH] SMPP: With dlr-mask=24, foreign_id is not set
Yes,
bb_smscconn_sent(smpp->conn, msg, NULL) (just outside context in the
patch)
sends this using create_dlr_from_msg, so avoids creating a dlr with
dlr_add.
On Torsdag 19 februar 2009 16:
Hi Alex,
I think that in such case it would be an extra function call and the
architecture would be less obvious.
Nikos
- Original Message -
From: "Alexander Malysh"
To: "Arne K. Haaje"
Cc:
Sent: Wednesday, February 25, 2009 3:51 PM
Subject: Re: [PATCH] SM
1 - 100 of 107 matches
Mail list logo
