Re: [PATCH] SMPP data_coding enforcing for UCS-2 messages

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

Re: [PATCH] SMPP data_coding enforcing for UCS-2 messages

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, >

Re: [PATCH] SMPP DLR item scan (old way)

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.

Re: [PATCH] SMPP DLR item scan (old way)

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

RE: [PATCH] SMPP DLR item scan (old way)

+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

[PATCH] SMPP DLR item scan (old way)

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

Re: [PATCH] SMPP command_status as meta-data

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

Re: [PATCH] SMPP command_status as meta-data

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

Re: [PATCH] SMPP command_status as meta-data

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

Re: [PATCH] SMPP command_status as meta-data

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

Re: [PATCH] SMPP command_status as meta-data

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

[PATCH] SMPP command_status as meta-data

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

Re: [PATCH] SMPP command_status as meta-data

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

Re: [PATCH] SMPP box multipart messages

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 a

RE: [PATCH] SMPP box multipart messages

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

[PATCH] SMPP box multipart messages

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

Re: [PATCH] SMPP box multipart messages

Looks good. +1 Nikos - Original Message - From: Rene Kluwen rene.klu...@chimit.nl To: 'Kannel Devel' devel@kannel.org 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 open

Re: [HELP]Patch SMPP Module to Inject Custom TLV

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 order to inject

[HELP]Patch SMPP Module to Inject Custom TLV

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

Re: [PATCH] SMPP: With dlr-mask=24, foreign_id is not set

. Nevertheless this has nothing to do with your patch. +1. BR, Nikos - Original Message - From: Arne K. Haaje a...@drlinux.no To: Nikos Balkanas nbalka...@gmail.com Cc: devel@kannel.org Sent: Thursday, February 19, 2009 5:20 PM Subject: Re: [PATCH] SMPP: With dlr-mask=24, foreign_id

Re: [PATCH] SMPP: With dlr-mask=24, foreign_id is not set

: devel@kannel.org 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 dlr with dlr_add. On Torsdag 19

Re: [PATCH] SMPP: With dlr-mask=24, foreign_id is not set

extra code Cons: function call (but how much costs a function call? ;) ) Nikos - Original Message - From: Alexander Malysh amal...@kannel.org To: Arne K. Haaje a...@drlinux.no Cc: devel@kannel.org Sent: Wednesday, February 25, 2009 3:51 PM Subject: Re: [PATCH] SMPP: With dlr-mask=24

[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 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

Re: [PATCH] SMPP: With dlr-mask=24, foreign_id is not set

: Arne K. Haaje a...@drlinux.no To: devel@kannel.org 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 on the dlr-url for %F when receiving ACK from

Re: [PATCH] SMPP Optional Parameters

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 only

Re: [PATCH] SMPP Optional Parameters

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

Re: [PATCH] SMPP Optional Parameters

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

Re: [PATCH] SMPP Optional Parameters

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:

Re: [PATCH] SMPP Optional Parameters

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:

Re: [PATCH] SMPP Optional Parameters

Call: (Relevant values inserted of courser) $post .= X-Kannel-Meta-Data: ?smpp-tlv?MBbilling=.$bill.MBoperator=.$operatorid.MBcontentType=100MBcommand=STARTMBsubDate=.date('U000').MBserviceId=XXX\r\n; Definitions: (Had all as octstring, switched to nullterm for those with no definite

Re: [PATCH] SMPP Optional Parameters

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:

Re: [PATCH] SMPP Optional Parameters

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?

Re: [PATCH] SMPP Optional Parameters

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

Re: [PATCH] SMPP Optional Parameters

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 =

Re: [PATCH] SMPP Optional Parameters

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 patch. These are

Re: [PATCH] SMPP Optional Parameters

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 parameters :(

Re: [PATCH] SMPP Optional Parameters

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 of previous

Re: [PATCH] SMPP Optional Parameters

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

Re: [PATCH] SMPP Optional Parameters

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!

Re: [PATCH] SMPP Optional Parameters

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 clue on

Re: [PATCH] SMPP Optional Parameters

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 stuff,

Re: [PATCH] SMPP Optional Parameters

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 only

Re: [PATCH] SMPP Optional Parameters

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 =

Re: [PATCH] SMPP Optional Parameters

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

Re: [PATCH] SMPP Optional Parameters

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 able

Re: [PATCH] SMPP Optional Parameters

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

Re: [PATCH] SMPP Optional Parameters

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 :)?

Re: [PATCH] SMPP Optional Parameters

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 -

Re: [PATCH] SMPP Optional Parameters

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

[PATCH] SMPP Optional Parameters

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 =

Re: [PATCH] SMPP Optional Parameters

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

Re: [PATCH] SMPP Optional Parameters

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 it

Re: [PATCH] SMPP Optional Parameters

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 test it with them.

Re: [PATCH] SMPP Optional Parameters

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. First of all,

Re: [PATCH] SMPP Optional Parameters

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

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 could dump a load of messages into the queue and while there was no further activity the queue would drain at the

Re: [Fwd: [PATCH] smpp smsc throttling]

@kannel.org 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 could dump a load

Re: [Fwd: [PATCH] smpp smsc throttling]

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

[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 could dump a load of messages into the queue and while there was no further activity the queue would drain at the

[Fwd: [PATCH] smpp smsc throttling]

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:

Re: [PATCH] smpp relaxed source_addr parsing

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.4.1

[PATCH] smpp relaxed source_addr parsing

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.

Re: [PATCH] SMPP Online time

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.

Re: [PATCH] SMPP Online time

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 any.

[PATCH] SMPP Online time

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 +++

Re: [PATCH] smpp properly shutdown sequence

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

Re: [PATCH] SMPP inactivity+transaction timeouts

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:

Re: [PATCH] SMPP inactivity+transaction timeouts

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 appropriate

Re: [PATCH] SMPP inactivity+transaction timeouts

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 20 August 2003 20:01, Alexander Malysh wrote: Hi all, for the more easily testing

[PATCH] smpp properly shutdown sequence

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 +++---

[PATCH] SMPP inactivity+transaction timeouts

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

Re: [PATCH] SMPP

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 = none, log_lvl = 0 2003-03-27 12:36:18 [0] ERROR: Group 'smsc' may

Re: [PATCH] SMPP sender-prefix ala unified-prefix

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, so

Re: [PATCH] SMPP

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

Re: [PATCH] SMPP

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

Re: [PATCH] SMPP

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

[Fwd: [PATCH] SMPP]

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

Re: [PATCH] SMPP sender-prefix ala unified-prefix

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