Or alternatively, you could use a range of MSISDNs for the outbound,
log what MSISDN you are sending to user2 from, so when they reply you
route that message back to user1 with a from number of the MSISDN.
Keep that record of what MSISDN you used for the conversation for
those two users for a predetermined amount of time - eg four weeks -
so any replies back to that MSISDN get routed to the correct
recipient.
It's better explained here:
http://www.wirelessbrasil.org/wirelessbr/secoes/sec_smpp/sec_smpp.html
- I've pasted the relevent section below:
Overview
An ESME wishes to develop an application that will allow a dialogue of
messages to take place between the ESME and a mobile user. For
application purposes, it is necessary to correlate each reply from the
mobile user with the original request from the ESME.. how is this
accomplished?.. Can the user_message_reference TLV be used?.. Can
sequence_number be used?
Solution
The sequence_number field is used to correlate SMPP PDUs and not end
to end messages. The sequence number is in fact lost when the message
is delivered to the mobile.
The user_message_reference TLV will not be echoed in the reply message
if the network technology is GSM. In ANSI-41 (CDMA & TDMA), this
reference is returned in a reply message but only if the message is a
deliver or manual ACK.. and both of these are not reply messages,
rather ackowledgements of delivery.
So there is no quick easy answer to the problem.. its not a failing of
SMPP.. its a limitation of GSM and ANSI-41 technologies.
One way of performing the relationship is to use different source
addresses for each ESME message sent to the destination mobile, such
that any given reply will use a different destination address instead
of the fixed short code of your application.
55501 -> mobile
55502 -> mobile
55503 -> mobile
55504 - mobile
etc.
if the mobile replies to any one message, then the destination address
will be 55503 or 55502 etc.. you now have your correlation data
between original request and response.
For this to work, your carrier would have to configure you ESME Rx to
accept messages beginning with your short code prefix as opposed to a
fixed address.. that should be no problem with most SMSCs
To manage dialogues across different mobile users, the ESME should
correlate a reply not only on the given short code, but on the source
address of the message:
55501 -> mobile1
55502 -> mobile1
55501 -> mobile2
55501 - mobile3
in the above example, the same short code was used for three different
destinations.. if any of these messages receives a reply:
mobile2 -> 55501
then we will know the original subscriber as well as the target short
code and can deduce the actual message being answered.
The only rule to follow is that for each message sent to a subscriber,
the ESME should increment the short code and correlate messages to
their reply messages by the destination address and source address.
On 8/31/06, Rodrigo Cremaschi <[EMAIL PROTECTED]> wrote:
Hi Raul,
You will have to implement some kind of "state handling" within
you own application to accomplish this. Kannel can't do this for you.
For example, you may instruct your users to start their SMS with an ID
"karl: hi there" goes to user1-phone
"mary: good day" goes to user3-phone
then you continue sending messages to the same user, unless the ID
is changed.
Just an idea.
Regards,
Rodrigo.
On 8/30/06, Raul Martinez <[EMAIL PROTECTED]> wrote:
> My app will work as a middle-man.
>
> diagram:
>
> (1.1) user1-phone -> [smsc1] -> MYAPP -> [smsc2] -> user2-phone
> (1.2) user2-phone <- [smsc1] <- MYAPP <- [smsc2] <- user2-phone
>
>
> (2.1) user3-phone -> [smsc1] -> MYAPP -> [smsc2] -> user2-phone
> (2.2) user3-phone <- [smsc1] <- MYAPP <- [smsc2] <- user2-phone
>
>
>
> Is there a way to getting some sort of identification or sequence
> numbers so that I can identify whose number to send a messages coming
> from another number. Like in the diagram above, I will know that
> whenever user2-phone sends a reply (without special commands, just
> normal reply text) to a message sent by user3-phone it is user3-phone
> that will really receives it and not user1.
>
>
>
>
