This is our old Q&A Site. Please post any new questions and answers at

Dear all,

what is the purpose of TTL on the Internet Protocol message? it live which conversation.



asked 25 Jun '13, 20:24

Hafiz's gravatar image

accept rate: 0%

edited 27 Jun '13, 02:31

grahamb's gravatar image

grahamb ♦

Hafiz, can you explain what is the flow/test that you are performing, and the error generated to your HS and ussd app? Also, transaction id's would be appreciated (related to the trace you have provided).

(26 Jun '13, 05:20) Edmond

TTL indicates the remaining life time of a packet when it is floating on a network.

If a packet arrives at a router with TTL Value 1 then that router should discard(as TTL becomes 0) it and send back ICMP Type 11 and Code 0 message(Time to live exceeded).

One advantage/purpose i can think of is to avoid Looping at Layer3 .If there is any packet loop in the network and each time it hits a routing interface it's value will be decremented and eventually this unhealthy packet perishes.

Moreover TraceRoute make use of this TTL mechanism.

permanent link

answered 25 Jun '13, 20:53

krishnayeddula's gravatar image

accept rate: 6%

edited 25 Jun '13, 21:25

Dear Krishnayeddula,

thanks from your support and help.

my issue is in a GSM network and below is my scenario.

{{{{{{Mobile Station====> (MSC=TTL=63)====>(STP=TTL=255)====>(HLR=TTL=62)====>(STP=TTL=255)====>USSD}}}}}}

                                   on the revert path

{{{{{(USSD=TTL=62)====>(STP=TTL=255)====>(HLR=TTL=62)====>STP=TTL=255)====>MSC=-------===>Mobile Station}}}}}}

MS send *303# to USSD USSD send back to MS please enter you facebook ID/// while i am typing my facebook on the screen of mobile my transection disconnecting. as i check on the trace release is coming from Mobile side. but i don't know to blame which platform.

best Regards,

Hafiz AWCC Afghanistan

i don't know how to attached my trace.

(25 Jun '13, 23:51) Hafiz

The IP TTL is a time-to-live at the IP layer to prevent packet destined for an undeliverable address from looping through the network forever. It is defined as:

Time to Live:  8 bits

This field indicates the maximum time the datagram is allowed to
remain in the internet system.  If this field contains the value
zero, then the datagram must be destroyed.  This field is modified
in internet header processing.  The time is measured in units of
seconds, but since every module that processes a datagram must
decrease the TTL by at least one even if it process the datagram in
less than a second, the TTL must be thought of only as an upper
bound on the time a datagram may exist.  The intention is to cause
undeliverable datagrams to be discarded, and to bound the maximum
datagram lifetime.

(see: RFC 791 page 14)

I believe the hops you are drawing in your response to @krishnayeddula are hop at the application layer and not at the IP layer. Between these application layer hops are routers to get the IP packet from one server to the other. Each of these routers will decrement the IP TTL, but each server will create a new IP packet, with a new TTL value.

(You can share traces by uploading the trace to and then paste the link to the trace here)

permanent link

answered 26 Jun '13, 00:02

SYN-bit's gravatar image

SYN-bit ♦♦
accept rate: 20%

(26 Jun '13, 02:13) Hafiz

kindly please put some more light on:(each server will create a new IP packet, with a new TTL value)in my network

(26 Jun '13, 02:16) Hafiz

Consider the following setup:

srvA -> rtr1 -> rtr2 -> srvB -> rtr3 -> srvC

Different systems use different initial TTL values (mostly 64, 128 or 255), for now, assume they all use 64.

A message from srvA to srvB will have the following headers:

mac-srvA -> mac-rtr1, ip-srvA -> ip-srvB, TTL=64 (arriving at rtr1)
mac-rtr1 -> mac-rtr2, ip-srvA -> ip-srvB, TTL=63 (arriving at rtr2)
mac-rtr2 -> mac-srvB, ip-srvA -> ip-srvB, TTL=62 (arriving at srvB)

Then if srvA has an application that somehow forwards the message to srvC, the following headers can be seen:

mac-srvB -> mac-rtr3, ip-srvB -> ip-srvC, TTL=64 (arriving at rtr3)
mac-rtr3 -> mac-srvC, ip-srvB -> ip-srvC, TTL=63 (arriving at srvC)

So you need to make a distinction in your analysis between routing hops and application hops. I believe you were mentioning application hops in your example.

In your example capture, made on you can see that it communicates with 3 other systems:

Packets from have a TTL of 63, which means there is one router in between and (assuming the 64 start value of the IP TTL).

Packets from have a TTL of 62, which means there are two routers in between and (assuming the 64 start value of the IP TTL).

Packets from have a TTL of 62, which means there are two routers in between and (assuming the 64 start value of the IP TTL).

The problem you are researching is not at the IP layer but in one of your application layers. I have very little knowledge of the mobile networking protocols. But I see an error in frame 17 with a 60 second delta, this looks like a timeout on that server to me. Could that be your problem source?

(26 Jun '13, 03:10) SYN-bit ♦♦

Thanks Mr. SYN,

TTL is now cleared for me. appreciate for your support.

I looking to the other part of trace if faced any confusion i will come to you.


Hafiz AWCC Afghanistan

(26 Jun '13, 06:21) Hafiz

Thanks Mr. Edmond,

my test scenario is:

from MS i am sending *303# toward USSD getway USSD getway replaying press 1 to confirm from MS i press 1 and send to USSD USSD replay enter you Facebook ID while i am typing my Facebook ID its not waiting for some more secounds its disconnecting after 45 secound before i complete my ID.

our USSD team is saying that they have increased this time to 2 minutes. our HLR/MSC and STP teams are saying we don't have timer for this.

{{{{{{Mobile Station====> ((MSC=TTL=63)SPC=5300)====>((STP=TTL=255)SPC=7100 or 7200)====>((HLR=TTL=62)SPC=5001)====>((STP=TTL=255)====>(USSD=SPC=5252)}}}}}}

                               on the revert path


there are many different packets in one transaction i don't know how to describe it, i attached an snapshoot of sorting the trace by time on the image place of YOUR ANSWER box.

(26 Jun '13, 07:25) Hafiz

also, note that ICMP embeds the original packet inside the ICMP data. So the IP address that you see in Wireshark is the actual device that sent you the ICMP type 11 code 0 (TTL Exceeded) message. So it's pretty easy to figure out who sent you the error message and why. It has nothing to do with your problem, and Sake (syn-bit) already explained some of this for you. But in case others are wondering, ICMP's ability to embed the original pkt header can be quite useful.

(26 Jun '13, 19:21) hansangb
showing 5 of 6 show 1 more comments

National laws may vary, but those are public point codes in that trace file and you have subscriber IMSIs in there, including their mobility procedures and an SMS delivery. That includes SMS text payload, which looks like it might be clear-text though it doesn't decode well into this alphabet. I just want you to be very aware of that before proceeding further - Since you're including all TCAP transactions within a given IP packet toward an STP in that trace (even if you're just searching for the one subscriber), you are including all of your IN traffic, your SMSC signaling and potentially sensitive/compromising data for the carrier and subscribers.

Having said that, a couple things to be clarified: The path you have drawn is not the path of any single routed IP packet, but rather they are paths that individual signaling messages in a call flow will take between the systems you are talking about, as SYN-Bit correctly surmised. Since this is SS7 over IP, you may be routing at a point code or GT level but the SS7 messages that the STP is routing are going to get their own separate IP packets. Between end points in each M3UA association there is a new IP packet, from this perspective. Also there is a separate IP packet between RNC/BSC and MSC (RANAP packet), and between base station and RNC/BSC (NBAP packet), each carrying this same USSD/NAS message along its way. Different IP packet, different TTL.

So now, finally, for your actual signaling problem :)

We can see in the trace that the USSD message got routed across the STP just fine and got sent to HLR. The invoke goes through and gets a response. The problem is that the return at packet 17 for TCAP transaction 0003bc30 (this USSD invoke) is a return error, with code 34 (System Failure). Therefor the question is:

  • Why does the HLR with point code 5001 return the USSD invoke with error 34 (System Failure)? I'm guessing the 60 seconds it takes between invoke and return has something to do with it (timeout between HLR and USSD system)? The problem seems to be between HLR and USSD which doesn't appear in that trace file as far as I can tell.

My suggestion is to step back from the noise in that trace file and focus here on packets 14 and 17, where the invoke is sent to HLR, it receives it, waits 60 seconds, then returns the error. So, focus on the content of TCAP transaction 0003bc30 ("tcap.tid == 00:03:bc:30" filter in Wireshark) and why it failed.

permanent link

answered 26 Jun '13, 20:46

Quadratic's gravatar image

accept rate: 13%

edited 26 Jun '13, 21:03

Thanks Sir Quadratic and All,

actually the packet follows are correct i don't have complain.the issue is that while i am typing my Facebook ID on the screen of phone the connection shuld waite utill to i sumit my Facebook ID, but my connection intrupting after 45 second before to i submit my Facebook ID.

And as i check on the trace the release starting from Mobile phone not any other network node.

if you kindly tell me that do we can change TTL value in any kindly of Platforms?

Best Regards,


(26 Jun '13, 23:51) Hafiz

Look at TCAP transaction 0003BC30 in packet number 17 in the trace file. In that message, we see a return on the USSD transaction after 60 seconds with a return error for system failure. Compare with the transaction of the same number in packet 14 and see that the error was indeed a response for the USSD invoke, so in my mind you have a clear error returned by HLR after a 60 second timeout. In that call flow, HLR should be sending to your USSD system at that point but tht is not in the trace file.

For TTL, I really think you're looking at the wrong thing here. If there was an issue with IP TTL, you'd see it decrement down to 1 and you would not see a return message sent in response to your invokes between MSC and HLR. The fact that you see the SS7 routing between point codes proves that each IP packet is being sent and received correctly between MsC and zsTP, and between STP and HLR.

For the MS-initiated release you're talking about, what protocol are you referring to? For sure the user device will eventually release RRC control and time out at the NAS layer if it has to (in this case) wait a whole minute and not see anything, but the question at hand is why you see a 60-second delay between invoke and return, why the return is system failure and really what is happening between HLR and USSD system. Why do you believe there is any TTL problem, or IP level problem at all? Is there any request not responded to at MAP level? It does not appear so in that trace.

(27 Jun '13, 03:41) Quadratic

I am very sorry, that i did not provide all details at first. On the previous trace it was really correct that HLR send Error toward USSD and we took a wireshark trace from HLR there we saw that error is coming from MS and we took a trace from MSC its format is different i couldn’t attached it to cloudshark there the error is coming from BSS side with (Radio Interface Failure)

At this point USSD team expanded the time to 2 minutes but NSS STP and HLR teams are not accepting the error on there side According to the traces as far as i know on BSS there is no timer. so i was thinking that TTL is any kind of timer which is Releasing the connection, thanks to all that cleared my mind about it specially Mr.Quadratic last comment.

new attached trace details

At packet number 10 on the TCAP message Transaction ID=08240705 show an (abort by user) from MSC while you can see the MSC GT (93702993007) at SCCP message above the mentioned TCAP message.

And on packet 3 we can see the HLR-GT(93702980007) forward the error message which is coming from MSC side toward USSD-GT(93702992006) and we took a trace from MSC its format is different i couldn't attached it to cloudshark. there Mentioned that the error is coming from BSS side with (Radio Interface Failure) Error.

at this point if anyone have idea about timer expansion on NSN MSC, Hwawei STP, and NSN HLR or BSS kindly help and comment.

Best Regards,


(29 Jun '13, 22:52) Hafiz

Ah, I see thanks for clearing that up. If the system failure in the trace is being caused by MS-initiated abort then it sounds to me like something that needs to be handled at the USSD application level. While the systems in this call flow can have timeout timers at a TCAP transaction level, and at a MAP level for invoke/return exchanges, the end-to-end session would be controlled by the USSD application at the MS and USSD gateway.

Is the device timing out at a USSD level? The RRC connection on the radio side is also stateful (thus could potentially time out), as would the MS' mobility state with the serving MSC technically, but really this sounds like a USSD, application-specific timer problem.

Also for the final question on TTL, the IP protocol itself is stateless. There is no "session" at an IP level and no timer that can expire.

(30 Jun '13, 13:03) Quadratic
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here



Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text]( "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:


question asked: 25 Jun '13, 20:24

question was seen: 61,677 times

last updated: 30 Jun '13, 13:03

p​o​w​e​r​e​d by O​S​Q​A