-Original Message-
From: Stipe Tolj [mailto:[EMAIL PROTECTED]]
Angel Fradejas wrote:
Not true in multi-operator links.
if your multi-operator incoming link tells you the
original SMSC the
message comes from (passing the %i) then youre back in business. If
Since the smsc_id in the MO is set by the driver, and this only applies
to custom/proprietery or future drivers, I think that setting the smsc_id
of the MO to something that represents the mcc/mnc will suffice (maybe a
concatenation of their values), and is a good solution.
Yes Oded, that was
In this case I suggest you're backend system should know the prefix of
the MO message, hence your backend system has to figure out from which
network the request is coming by parsing the prefix number value.
Yes Stipe, but this is mainly guessing, because of mobile number
portability. Here in
Aquestion for all developers,
What do you
think about having kannel pass mnc and mcc information to applications?
Sometimes applications need to know the operator for the incoming MO (a logo
download applicationbeing the typical example), and kannel is the closer
elementto the operator
Title: Re: [RFC] mcc and mnc
Aquestion for all developers,
What
do you think about having kannel pass mnc and mcc information to
applications? Sometimes applications need to know the operator for the
incoming MO (a logo download applicationbeing the typical
example), and kannel is the closer
Title: Re: [RFC] mcc and mnc
smsc-id is almost as good, but not completely.mcc and mnc are
normalized values, and when you have for example 20 connections to the same
operator (as I do, one emi2 link for each short code), if you use smsc-id you'll
have to translate this value in every
Title: RE: [RFC] mcc and mnc
smsc-id is almost as good, but not
completely.mcc and mnc are normalized values, and when you have
for example 20 connections to the same operator (as I do, one emi2
link for each short code), if you use smsc-id you'll have to translate
this value in every
Andreas Fink wrote:
You can do that by adding mnc=xxxmcc=yyy inside the service
definition passing those values as a constant string. So you would
have an entry for every logo cgi for every SMSC connection. Or you
could simply use the %i which is the smsc name. Kannel has no way of
knowing
Angel, what you want to do is to allow to forward mcc and mnc values
that have to be entered by the system admin by hand to each smsc
group, which means Kannel is only storing and forwarding still
statical information. This blows only unnecessary the code of Kannel
up.
You can distunguish in
Angel, what you want to do is to allow to forward mcc and mnc values
that have to be entered by the system admin by hand to each smsc
group, which means Kannel is only storing and forwarding still
statical information. This blows only unnecessary the code of Kannel
up.
You can distunguish in
Not true in multi-operator links.
if your multi-operator incoming link tells you the original SMSC the
message comes from (passing the %i) then youre back in business. If
you implement mnc and mcc and the multi-operator link doesnt tell you
this, you're back to square one, hence the original
Angel Fradejas wrote:
Not true in multi-operator links.
if your multi-operator incoming link tells you the original SMSC the
message comes from (passing the %i) then youre back in business. If
you implement mnc and mcc and the multi-operator link doesnt tell you
this, you're back to
12 matches
Mail list logo
