[asterisk-bugs] [JIRA] (PRI-175) Asterisk Send wrong operation vaule in facility IE for ECT Explicit call transfer

[Richard Mudgett (JIRA)]

    [ https://issues.asterisk.org/jira/browse/PRI-175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=221180#comment-221180 ] 

Richard Mudgett commented on PRI-175:
-------------------------------------

This is not a bug.  Your equipment is decoding the values incorrectly for some reason.  I suspect that the equipment does not support decoding OID values and instead treats the encoding as if it were a simple integer encoded value.  In addition, you are looking at the wrong specification because of the incorrect decoding done by the equipment.

{noformat}
PRI Span: 1   operationValue OID(6 0x06) = 4.0.369.1.4
PRI Span: 1   operationValue = ROSE_ETSI_EctLinkIdRequest
{noformat}

The complete encoded value in question is {{06 06 04 00 82 71 01 04}} which decodes as follows.
06 - The item is an OID encoded value
06 - It is six octets in length
04 00 82 71 01 - OID object identifier (ccitt identified-organization etsi(0) 369 operations-and-errors(1))
04 - Operation (ectLinkIdRequest-operation(4))


The way you are interpreting the value it would be encoded as a simple integer as {{02 01 04}}.


>From EN 300 369-1 V1.2.4 (1998-10) Section 7.1 Table 1 (at the end of the table):
{noformat}
eCTOID OBJECT IDENTIFIER ::=
    {ccitt identified-organization etsi(0) 369 operations-and-errors(1)}

ectExecute         EctExecute         ::= localValue 6

explicitEctExecute ExplicitEctExecute ::= globalValue {eCTOID explicitEctExecute-operation(1)}
requestSubaddress  RequestSubaddress  ::= globalValue {eCTOID requestSubaddress-operation (2)}
subaddressTransfer SubaddressTransfer ::= globalValue {eCTOID subaddressTransfer-operation(3)}
ectLinkIdRequest   EctLinkIdRequest   ::= globalValue {eCTOID ectLinkIdRequest-operation  (4)}
ectInform          EctInform          ::= globalValue {eCTOID ectInform-operation         (5)}
ectLoopTest        EctLoopTest        ::= globalValue {eCTOID ectLoopTest-operation       (6)}
{noformat}


Does the ISDN call leg get connected line updated when the SIP parties transfer the call to another SIP party?


> Asterisk Send wrong operation vaule in facility IE for ECT Explicit call transfer
> ---------------------------------------------------------------------------------
>
>                 Key: PRI-175
>                 URL: https://issues.asterisk.org/jira/browse/PRI-175
>             Project: LibPRI
>          Issue Type: Bug
>      Security Level: None
>         Environment: sip phone -->Asterisk-->EuroISDN-->Local_TDM_Exchange
>            Reporter: mehdi Shirazi
>            Assignee: Richard Mudgett
>         Attachments: analyzer1.png, PABXtrace2.txt, q950.png, sigtrace.txt, T-REC-Q[1].950-200006-I!!PDF-E.pdf
>
>
> sip phone(A) call B  and put call on hold then transfer call to C, A disconnect and B and C connect to each other , Asterisk tries to bypass the call to Local exchange but Local exchange reject by invalid call state.
> first failure report send to Local exchange manufacturer, R&D responed after investigation that PBX(Asterisk)  send wrong operation vaule in facility IE, instead of 06 asterisk send 04, this is operation value for Begin3PTY !.
> I checked with Triton PRI Analyzer , it also shows Asterisk sends 04  according to Q.950 and Q952 06 is for eCTRequest.
> from Asterisk log:
> PRI Span: 1 > [1c 15 91 a1 12 02 01 0b 06 06 04 00 82 71 01 05 30 05 0a 01 01 82 00]
> it seems (...06 06 04...) 04 is wrong and 06 is for eCTRequest and  93 is for ECTLINKIDREQUEST



--
This message was sent by Atlassian JIRA
(v6.2#6252)