Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
Home
Discussion Groups
General
General TopicsGSMBluetooth
Providers
AlltelATT WirelessCingularFidoNextelSprint PCST-MobileVerizon
Manufacturers
EricssonNokiaMotorola
Country Specific
Australian GroupUK Group
Related Topics
PocketPCPalmMore Topics ...

Cellular Phone Forum / General / GSM / May 2007

Tip: Looking for answers? Try searching our database.

SMS Lifetime on SMSC

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Brainsludge - 28 May 2007 20:21 GMT
My phone's SMS memory is currently full. I know that there are waiting
SMSs for me on my SMSC, but I would like to backup some important SMSs
before I free up some memory. I use T-Mobile USA.

My questions are:

1) how long is an SMS queued (and retried) on the SMSC before it is
deleted?

2) if it is eventually deleted having gone undelivered, is it billed?

thanks,
B
Christen Fihl - 28 May 2007 20:49 GMT
1) Normally, as I have seen it, the queue time is 3 days, 72 hours
But it is actually up to the sender to specify how long retention they
want on each message.
I have a system myself, where I do specify 20 minutes.
If message not read within 20 minutes, it is too late anyway.

2) Message is discarded then, but still billed, I guess.

Signature

Christen

John Henderson - 28 May 2007 21:36 GMT
> My phone's SMS memory is currently full. I know that there are
> waiting SMSs for me on my SMSC, but I would like to backup
[quoted text clipped - 5 lines]
> 1) how long is an SMS queued (and retried) on the SMSC before
> it is deleted?

As set on the sending phone in the message settings - often
called "validity period" or similiar.  However SMSCs impose
their own upper limit that's well short of the maximum defined
in GSM 03.40 (63 weeks).  In my experience, the SMSC upper
limit is always set somewhere betweeen 3 and 7 days.

> 2) if it is eventually deleted having gone undelivered, is it
> billed?

Yes, that's as certain as death and taxes are.

John
Brainsludge - 28 May 2007 21:51 GMT
hey guys,

Thanks for the replies. I posted my questions only after giving T-
Mobile CSR a try. Nobody there seemed to know the answers. I just gave
CSR another try and found someone in Tier 2 tech support who
supposedly found the answers. As both of you guys mentioned, it seems
the validity period for SMSs on the T-Mobile SMSC is 72 hours.
However, the Rep told me that if the SMS doesn't successfully reach
the phone, it is not charged. It seems that the phone's
acknowledgement of having received the SMS is what triggers billing.

Anybody know for sure the point at which billing is triggered?

Thanks!
B
John Henderson - 28 May 2007 22:17 GMT
> hey guys,
>
[quoted text clipped - 9 lines]
>
> Anybody know for sure the point at which billing is triggered?

I'd be very surprised.  What I do know is that if I sent an SMS
from here in Australia to your T-Mobile phone, it'd be charged
by my carrier at the point of lodgement - end delivery would be
irrelevant.

John
Brainsludge - 28 May 2007 22:46 GMT
> I'd be very surprised.  What I do know is that if I sent anSMS
> from here in Australia to your T-Mobile phone, it'd be charged
> by my carrier at the point of lodgement - end delivery would be
> irrelevant.

We're talking about two different things. Sorry for not being more
clear.

Yes, intuitively, the sender would be charged as soon as the SMS
clears the outgoing server.

My question is with regard to a charge for the incoming party. Perhaps
things are done differently by Australian cellular providers but
American providers, like T-Mobile USA, charge an incoming per-message
tariff for SMS. So my question is: If the message ends up being
undeliverable due to expiration at the SMSC, will the incoming party
be billed for the orphaned message?

Also, just a speculation: if the the SMSC ends up expiring a certain
SMS, it may send an "undeliverable" error back to the outgoing party
(e.g. outgoing server). Perhaps this would wash the charge for the
sender. Just guessing...

Thanks!
B
John Henderson - 28 May 2007 23:17 GMT
> Yes, intuitively, the sender would be charged as soon as the
> SMS clears the outgoing server.
[quoted text clipped - 6 lines]
> SMSC, will the incoming party be billed for the orphaned
> message?

I was wondering about whether you might be charged for incoming
SMSs.  I would think no charge if undelivered, but hopefully
someone can clarify.

> Also, just a speculation: if the the SMSC ends up expiring a
> certain SMS, it may send an "undeliverable" error back to the
> outgoing party (e.g. outgoing server). Perhaps this would wash
> the charge for the sender. Just guessing...

The required mechanism would be much simpler than that.  It's
actually the SMSC of lodgement which delivers the SMS to the
phone on whatever network the addressee uses.  Assuming
different networks, if the SMS addressee is unreachable, their
network is obliged to notify the originator's SMSC when the
addressee's phone next has a network interaction.

John
Brainsludge - 29 May 2007 00:58 GMT
> It's actually theSMSCof lodgement which delivers theSMSto the
> phone on whatever network the addressee uses.

According to what you are saying, my own carrier's SMSC configuration
is irrelevant in answering my question. What I really need to find out
is the validity period for SMS's on the sender's SMSC. And that
requires me to know the carrier of the sender!

Furthermore, according to this logic, if the SMS is undeliverable,
then the originating SMSC should implicitly know so and eventually
wash the charge for the sender, or not bill the sender until the
recipient acknowledges receipt.

Thanks!
B
John Henderson - 29 May 2007 03:39 GMT
> According to what you are saying, my own carrier's SMSC
> configuration is irrelevant in answering my question. What I
> really need to find out is the validity period for SMS's on
> the sender's SMSC. And that requires me to know the carrier of
> the sender!

That's exactly how I understand it.  Telstra, the carrier I
usually lodge with, has a 7-day maximum keep-time (last time I
checked).  But with our wide-open spaces, slower travellers
could spend several days outside coverage areas.

> Furthermore, according to this logic, if the SMS is
> undeliverable, then the originating SMSC should implicitly
> know so and eventually wash the charge for the sender, or not
> bill the sender until the recipient acknowledges receipt.

I think the rationale is that you've used their resources to
lodge it, so they keep your money anyway.  In fact, there are
certain SMSCs which will accept SMS lodgement from anyone (you
can change your SMSC in your message settings).  Telstra charge
you the SMS sending fee even if you use one of these from a
Telstra SIM.

I don't know how your US carriers detect and charge for the
incoming segment of a successful delivery from another carrier.
But there'd be several ways of doing it.

John
Brainsludge - 30 May 2007 19:18 GMT
> Telstra charge
> you theSMSsending fee even if you use one of these from a
> Telstra SIM.

I wonder how they know when you use a different SMSC. From what I
understand, sending an SMS is essentially the same as making a GSM
phone call to the SMSC number.

Also, I tried manually setting the "validity period" on an SMS to 1
hour and also asked for a "delivery report" (some sort of receipt
notification I imagine) using my Nokia 6600. So far it's been 36 hours
and I have not received an "undeliverable" error nor has the delivery
report come back conclusively (it says "pending"). I wonder if my
carrier ignores user-defined validity periods...

-B
Christen Fihl - 30 May 2007 20:50 GMT
Maybe your company does not send reports at all even when asked for one.

In Denmark, not all companies give reports.

Signature

Christen

John Henderson - 30 May 2007 22:04 GMT
> I wonder how they know when you use a different SMSC. From
> what I understand, sending an SMS is essentially the same as
> making a GSM phone call to the SMSC number.

They only need to know that you've used their network for a
successful SMS-submit.  So billing gets triggered by an
interaction at a lower layer than that involving the carrier's
own SMSC.

> Also, I tried manually setting the "validity period" on an SMS
> to 1 hour and also asked for a "delivery report" (some sort of
[quoted text clipped - 3 lines]
> says "pending"). I wonder if my carrier ignores user-defined
> validity periods...

As Christen says, it may be that the SMSC you've used doesn't
support delivery reports.  Most carriers here don't.  The one
which does now charges for them.

Especially with the way outsourced software gets written and
"tested" these days, ignoring user-defined validity periods is
certainly possible, although I've done enough experimentation
here to be confident that our carriers do support shorter
periods.

Another SMS feature seems to have virtually non-existent
support.  That's "reply path" or "direct reply" (by whatever
name).  This is supposed to allow you to send a reply-paid SMS.
If the sender asks for it and their SMSC supports it, then a
flag gets set on the recipient's incoming SMS.  When you reply
(at least the first time), that reply gets lodged with the
original sender's SMSC directly (rather than using the the SMSC
configured in your phone), and reverse-charged.  As per our
earlier discussion, that would certainly result in
double-charging if such a reply was lodged through Telstra.

John
Brainsludge - 31 May 2007 02:56 GMT
Goodness. Knowing which features are and aren't supported and how they
are implemented ends up coming down to a guessing game, because
Customer/Tech Support rarely know these things (and are usually
unwilling to admit it - they'll gladly go in semantic circles with you
before they admit they don't know). I guess that's why this thread
started to begin with. Thanks for imparting all the knowlegde!

-B

> > I wonder how they know when you use a differentSMSC. From
> > what I understand, sending anSMSis essentially the same as
[quoted text clipped - 35 lines]
>
> John
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.