What are your http headers ? And our udh ?
Aarno
On Wednesday, December 4, 2002, at 05:16 PM, Matias Lahti wrote:
Hello!
I'm trying to send a m-notification-ind, which has been the source of plenty of headaches for plenty of people too.. Hopefully Alex releases the FAQ soon :)
Anyway - this
Andreas Fink wrote:
Anyone seen this:
2002-12-05 06:57:53 [10] DEBUG: SMPP[link5]: Got PDU:
2002-12-05 06:57:53 [10] DEBUG: SMPP PDU 0x814fdc8 dump:
2002-12-05 06:57:53 [10] DEBUG: type_name: generic_nack_resp
2002-12-05 06:57:53 [10] DEBUG: command_id: 2147483648 = 0x8000
2002-12-05
Vjacheslav Chekushin wrote:
Hi, Peter.
As I remember current cookies realization doesn't support cookie's delivery
to client(phone). Kannel store it in session machine, so it works only
for connection oriented mode and only for one (current) session.
yep, Vjacheslav is right here.
At the
2002-12-05 06:57:53 [10] DEBUG: SMPP[link5]: Got PDU:
2002-12-05 06:57:53 [10] DEBUG: SMPP PDU 0x814fdc8 dump:
2002-12-05 06:57:53 [10] DEBUG: type_name: generic_nack_resp
2002-12-05 06:57:53 [10] DEBUG: command_id: 2147483648 = 0x8000
2002-12-05 06:57:53 [10] DEBUG: command_status: 88 =
Hi to all.
I started to work with kannel recently, so excuse me for my ignorance, if
I'm wrong.
I'm refering to SAR thread one month ago.
Denzel wrote on Nov. 13.:
Here's a SAR patch we made ( diffrent to Igore's). We tested this with =
an earlier CVS ( may be in sync with gateway1.2.0 ). Nack's
On Donnerstag, Dezember 5, 2002, at 10:56 Uhr, Stipe Tolj wrote:
2002-12-05 06:57:53 [10] DEBUG: SMPP[link5]: Got PDU:
2002-12-05 06:57:53 [10] DEBUG: SMPP PDU 0x814fdc8 dump:
2002-12-05 06:57:53 [10] DEBUG: type_name: generic_nack_resp
2002-12-05 06:57:53 [10] DEBUG: command_id: 2147483648 =
Andreas,
I've fixed the problem in CVS.
the implementation didnt expect to see an error as generic_err_resp but only as
sms_submit_resp
the error was a THROTTLING.
what are the other changes you commited for?!
On Donnerstag, Dezember 5, 2002, at 12:13 Uhr, Stipe Tolj wrote:
Andreas,
I've fixed the problem in CVS.
the implementation didnt expect to see an error as generic_err_resp but only as sms_submit_resp
the error was a THROTTLING.
what are the other changes you commited for?!
Title: RE: SAR
Hi Damir,
You're right, this thing is not implemented,
but the implementation is coming soon
Igor
-Original Message-
From: Damir Salantic [mailto:[EMAIL PROTECTED]]
Sent: Thursday, December 05, 2002 12:06 PM
To: [EMAIL PROTECTED]
Subject: SAR
Hi to all.
I'm vetoing against (-1) for the block:
if(msg-sms.coding == 1)/* dont screw up unicode messages
*/
charset_gsm_to_latin1(msg-sms.msgdata);
because most SMPP SMSC seem to send with data_coding = 0 and use GSM
alphabet as default SMSC alphabet.
This patch would result
On Donnerstag, Dezember 5, 2002, at 03:23 Uhr, Stipe Tolj wrote:
I'm vetoing against (-1) for the block:
if(msg->sms.coding == 1)/* dont screw up unicode messages
*/
charset_gsm_to_latin1(msg->sms.msgdata);
because most SMPP SMSC seem to send with data_coding = 0 and use GSM
Hi
Yup we have. This is what happens when you send above the throughput
allowed by the SMSC you are connecting to for your account.
0x58 is SMPP_ESME_RTHROTTLED
We have also seen SMPP_ESME_RMSGQFUL comming in on a
generic_nack_resp.
Our smsc module is modified for this. Basically we have added
Hi
At 11:10 AM 12/5/02 +0100, Andreas Fink wrote:
I've fixed the problem in CVS.
the implementation didnt expect to see an error as generic_err_resp but
only as sms_submit_resp
the error was a THROTTLING.
Our soln is basically the same but with some minor differences..
Primarily we remove
Title: RE: SAR
Hi Damir/Igor,
As you have seen, my implementation is done based
on State Machine in WTP Response Layer. Also to my knowledge, I implemented all
the functionalities in SAR (Segmentation/Re-Assembly/NACK/ACK).
One thing I like to ask from Igor is is there any
efficiency
14 matches
Mail list logo
