http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1652
palos@xxxxxxxxxxxxx changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|INVALID |
------- Comment #2 from palos@xxxxxxxxxxxxx 2007-06-20 00:59 GMT -------
(In reply to comment #1)
> I do not see a bug, the Called Party Number is correctly dissected.
> 04 is Odd + Nature of Address
> 08 is INN + Numbering Plan + Spare
> and 82 90 10 99 00 00 00 00 are the digits.
> Moreover, the Numbering plan is "Unknown" in the given Called Party Number.
CAP_CONNECT is defined in 3GPP TS 29.078 as follows.
=========================================================================
CAP-gsmSSF-gsmSCF-ops-args {itu-t(0) identified-organization(4) etsi(0)
mobileDomain(0) umts-network
(1) modules(3) cap-gsmSSF-gsmSCF-ops-args(101) version4(3)}
DEFINITIONS IMPLICIT TAGS ::= BEGIN
....
ConnectArg ::= SEQUENCE { => 0x30 tag
destinationRoutingAddress [0] DestinationRoutingAddress , => 0xa0 tag
alertingPattern [1] AlertingPattern OPTIONAL,
...
}
DestinationRoutingAddress ::= SEQUENCE SIZE(1) OF CalledPartyNumber =>IMPLICIT
(no tag)
CalledPartyNumber ::= OCTET STRING (SIZE(minCalledPartyNumberLength ..
maxCalledPartyNumberLength)) => 0x04 tag
minCalledPartyNumberLength INTEGER ::= 2
maxCalledPartyNumberLength INTEGER ::= 18
============================================================
And the raw data is
"30 0c a0 0a 04 08 82 90 10 99 00 00 00 00".
so, I think the above raw data is decoded as follows.
30 => ConnectArg ::= SEQUENCE ...
0c => length
a0 => destinationRoutingAddress [0] DestinationRoutingAddress
0a => length
04 => CalledPartyNumber ::= OCTET STRING ...
08 => length
82 => odd/even and NoA
90 => INN and NPI
10 99... => digits
thanks in advance.
--
Configure bugmail: http://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.