On Sat, 19 Aug 2006 22:12:22 +0200
Stipe Tolj <[EMAIL PROTECTED]> wrote:
Denis V. Gudtsov wrote:
I'm using kannel 1.4.0 to connect to SMSCs by SMPP v3.4. My operator uses
optional parameters sar_* for a long message indication. How i can pass
this parametrs to my script? Without this i have to send 2 sms messages
back to sender in a reply to one long his message.
Is is possible to extract this fields from original messages and pass it
to my application? Or maybe can kannel assemble this messages to one and
push it to me?
there is no such way to "extract" the SMPP specific optional parameters for
the upside application layer. Kannel tries to capsulate as much abstraction
to all supported SMSC protocols as possible. This is "known" and it's still a
discussion thing about how we can get the maximum set of features supported
for SMPP, even MO side.
may be we should to add several ESC sequences to push some additional
parametrs for exec? e.g. sar_* so as msgid. everything tokens wich can help to
understand parts of splitted message.
Kannel does neither assemble MO concat messages. This hsa been a feature
request some time ago, but none has offered a patch for this.
@developers:
If someone is interested in getting his/her (actually did we ever had a
female sending patches? :/) I have a version fron Netikos (Kalle Marjola)
that does MO concating. This could be used as scratch for getting it into CVS
version. Obviously Kalles version is out of cvs sync.
Kannel does MT concat splitting. Obviously the point is that you need to get
the MO concat transported to your application, right?
yes, my operator requires from me to pass splitted messages as one message.
so, if user sends long message, it's splitted to 2 msg, but my service must
sends only one reply to it.
@others:
BTW, how are things with MOs if unicode is used? SMSCs obviously split then
160 char messages to 2 concat MOs, right? So this means we "don't support"
unicode MO messages, right?
(I cross-post this one, since it's a questionary for devel@ but may reside
in users@ still).
--
