Hi all,
Got some stuck here with understanding of how systems include terminator for address signals (F-filler). Some just insert it for called party like 84 10 36 99 69 27 40 32 0f (this is called party), some do not. The problem is how to understand rules for inserting this terminator into calling or called party numbers. I have a feeling this is up to design to make address length even or odd...lost here ;)
Can someone give a hint here?
Alex.
Hi Alex,
the odd/even indicator is used for this purpose.. here is the decoding of given hexa string according to ITU-T Q.763:
0x84 -> 1000 0100
1--- ---- Odd/Even indicator => 1, odd number of digits
-000 0100 Nature of Address indicator => 4, international number
0x10 -> 0001 0000
0--- ---- Internal Network Number indicator
-001 ---- Numbering plan indicator => ISDN NP
---- 0000 spare
the rest are address signals + filler:
639996720423f0,
0xf is ST signal (end of dialing - number is complete)
0x0 is the filler
639996720423f -> 13 address signals, this corresponds to odd/even indicator
0 -> since we have odd number of address signals filler 0 is used
Hope this helps,
Tomas
Hi Tomas!
Yes, this party clarifies my thoughts, but still, why do we need to state what the number is complete for the called party address? For example, this is not the case for calling party address as I observed from the pcap logs.
My idea is like there can be a gap or multiple packets between BTS and MSC (or something around - fix me ;) ) so called party can be miss collected digits and when SSF requires F as indication what all dialed digits are collected from subscriber unlike calling party where MSISDN is a part of user profile.
Does it bring a rule always to end called party with F and add 0-filler in case of even number. (or just add F in case of odd number)???
Simply, calling party or redirect party does not require F as complete number indication, but dialed address (called party) DOES REQUIRE it since it was dialed by a subscriber.
Hi Alex,
indication of the end of dialing is a relict from the fixed-line environment. ISUP protocol may use during call set-up two ways to send CldPN digits (ITU-T Q.764):
en-bloc (CldPN is sent at once in the IAM message)
overlap (CldPN is sent in the IAM message and in SAM messages)
Overlap way was used mainly for old analogue devices where it took long time to dial and to collect all digits for CldPN. Thus if exchange collected enough digits to route the IAM message it would sent IAM without ST and further digits would follow in the SAM messages...
GSM-MSC receives all digits of CldPN in the SETUP message from the Mobile (you have to enter all digits before you press dial button). Thus MSC can operate always the en-bloc way. But since MSC must be compatible with ISUP protocol it uses ST signal to tell receiving exchange no additional digits follow.
And yup - all calling Party digits or redirecting digits are know during the call set-up therefore so ST(0xf) makes sense only for the CldPN to signal if further digits might be sent.
Tomas
Perfect explanation!
I am dealing with CAMEL and INAP. Is this applicable for both of them?
And one more bullet here, I could not find any words related to things you described here. I did not search ISUP, but if you could just point to the document I can read about this terminator - it would be just perfect.
Anyway, I have a plan to execute now! )))
MSC might support both INAP and CAMEL. The connection with ISUP is that both INAP and CAMEL might follow the same formatting as ISUP. For instance INAP-CS1 OP:IDP defined in the INAP standard has these arguments:
InitialDPArg ::= SEQUENCE {
serviceKey [0] ServiceKey OPTIONAL,
dialledDigits [1] CalledPartyNumber OPTIONAL,
calledPartyNumber [2] CalledPartyNumber OPTIONAL,
// etc
...
}
But when you check CalledPartyNumber data type you will see it follows Q.763 ISUP standard:
CalledPartyNumber ::= OCTET STRING (SIZE (minCalledPartyNumberLength..maxCalledPartyNumberLength))
-- Indicates the Called Party Number. Refer to Recommendation Q.763 for encoding.
About the 0xF:
download this doc: http://www.itu.int/rec/T-REC-Q.764-199912-I/en
There you can find paragraph related to successful call set-up - "Actions required at the originating exchange". It is detailed both for en-bloc and for overlap:
for en-bloc see:
b) Address information sending sequence
for overlap see:
c) Content of initial and subsequent address messages
Many thanks!
I am only have a doubt about this:
"
In automatic working, the end-of-pulsing (ST) signal will be sent whenever the originating
exchange is in a position to know, by digit analysis, that the final digit has been sent. Digit
analysis may consist of an examination of the country code and counting the maximum (or
fixed) number of digits of the national number. In other cases, the end-of-pulsing signal is
not sent and the end-of-address information is determined by the receipt of the address
complete message or connect message from the incoming exchange."
and mostly about "In other cases, the end-of-pulsing signal is not sent".
I am expecting "automatic working" covers GSM cases and "other cases" are not applicable for my case. What do you think?
GSM covers "automatic working" and "other cases" are not applicable for you... Text you cited applies to overlap signaling only - this is not used in GSM at all. Overlap is applicable for instance for exchange where are connected fixed line phones. There were times when phones did not have a specific button to signal end of dialed digits (these days # button is used for this purpose for fixed line phones). Imagine you have this situation: number starting with 123 needs 5 digits to route a call and might have minimum 8 digits and max 9 digits. Someone starts dialing digits. At the point when originating exchange received 123** it sends IAM without ST with 5 digits. The problematic point is when the eighth digits is received - exchange does not know if number is complete or if further digit would come. So the SAM is sent without ST:
IAM(123**)
SAM(*)
SAM(*)
SAM(*)
In case further digit comes before inter-digit timer expires exchange might automatically insert ST after the last digit in the SAM:
IAM(123**)
SAM(*)
SAM(*)
SAM(*)
SAM(*F).
In case inter-digit timer expires and no further digit comes exchange is waiting for the ACM msg (AddressCompleteMessage) from the terminating exchange.
In GSM world you do not need to do this - for MO calls you get always complete number. For MT calls GMSC has to make sure it has complete number before query for actual location to HLR is done (SendRoutingInformation).
Thanks a lot for a great discussion!
Hi,
Sorry for reply to this old post. I've seen using the ST digit for MT calls in a country with variable digits length. So the GMSC included the ST digit when triggering an IN service for the MT subscriber.
Could you please explain what you mean by saying "In GSM world you do not need to do this"? Do you think that this ST digit is avoidable in such scenario?
Regards
Recent comments