[asterisk-users] Explicit Call Transfer(ECT)
babak
bk1379 at yahoo.com
Sat Jul 12 07:15:16 CDT 2014
Hi
Other side is a Huawei C&C08 Local Exchange.
I compared Asterisk Trace with C&C08 Trace
Asterisk side I see ROSE_ETSI_EctInform then ROSE_ETSI_EctLinkIdRequest then Invalid Call State
At C&C08 I see "OPERATION.........Begin3PTY" and then Invalid Call State
My Asterisk version !.8.11.0 and Libpri 1.4.12
If I enable 3PTY( 3 party call supplementary service on C&C08) will help?
Regards
babak
On Monday, June 16, 2014 10:11 PM, Richard Mudgett <rmudgett at digium.com> wrote:
On Mon, Jun 16, 2014 at 4:05 AM, babak <bk1379 at yahoo.com> wrote:
Hi
>I have done everything richard told to enable ECT .
>
>below is my trace, anyone can help ?
> -- DAHDI/i1/09123278669-4 answered DAHDI/i1/88050048-3
> -- Native bridging DAHDI/i1/88050048-3 and DAHDI/i1/09123278669-4
>PRI Span: 1 Adding facility ie contents to send in FACILITY message:
>PRI Span: 1 ASN.1 dump
>PRI Span: 1 Context Specific/C [1 0x01] <A1> Len:11 <0B>
>PRI Span: 1 Integer(2 0x02) <02> Len:1 <01>
>PRI Span: 1 <04> - "~"
>PRI Span: 1 OID(6 0x06) <06> Len:6 <06>
>PRI Span: 1 <04 00 82 71 01 04> - "~~~q~~"
>PRI Span: 1 ASN.1 end
>PRI Span: 1 INVOKE Component Context Specific/C [1 0x01]
>PRI Span: 1 invokeId Integer(2 0x02) = 4 0x0004
>PRI Span: 1 operationValue OID(6 0x06) = 4.0.369.1.4
>PRI Span: 1 operationValue = ROSE_ETSI_EctLinkIdRequest
>PRI Span: 1
>PRI Span: 1 > DL-DATA request
>PRI Span: 1 > Protocol Discriminator: Q.931 (8) len=21
>PRI Span: 1 > TEI=0 Call Ref: len= 2 (reference 3/0x3) (Sent from originator)
>PRI Span: 1 > Message Type: FACILITY (98)
>PRI Span: 1 TEI=0 Transmitting N(S)=14, window is open V(A)=12 K=7
>PRI Span: 1
>PRI Span: 1 > Protocol Discriminator: Q.931 (8) len=21
>PRI Span: 1 > TEI=0 Call Ref: len= 2 (reference 3/0x3) (Sent from originator)
>PRI Span: 1 > Message Type: FACILITY (98)
>PRI Span: 1 > [1c 0e 91 a1 0b 02 01 04 06 06 04 00 82 71 01 04]
>PRI Span: 1 > Facility (len=16, codeset=0) [ 0x91, 0xA1, 0x0B, 0x02, 0x01, 0x04, 0x06, 0x06, 0x04, 0x00, 0x82, 'q', 0x01, 0x04 ]
>PRI Span: 1
>PRI Span: 1 < Protocol Discriminator: Q.931 (8) len=16
>PRI Span: 1 < TEI=0 Call Ref: len= 2 (reference 3/0x3) (Sent to originator)
>PRI Span: 1 < Message Type: FACILITY (98)
>PRI Span: 1 < [1c 09 91 a3 06 02 01 03 02 01 07]
>PRI Span: 1 < Facility (len=11, codeset=0) [ 0x91, 0xA3, 0x06, 0x02, 0x01, 0x03, 0x02, 0x01, 0x07 ]
>PRI Span: 1 Received message for call 0xa9519f8 on link 0xa83ef9c TEI/SAPI 0/0
>PRI Span: 1 -- Processing IE 28 (cs0, Facility)
>PRI Span: 1 -- Delayed processing IE 28 (cs0, Facility)
>PRI Span: 1 ASN.1 dump
>PRI Span: 1 Context Specific/C [3 0x03] <A3> Len:6 <06>
>PRI Span: 1 Integer(2 0x02) <02> Len:1 <01>
>PRI Span: 1 <03> - "~"
>PRI Span: 1 Integer(2 0x02) <02> Len:1 <01>
>PRI Span: 1 <07> - "~"
>PRI Span: 1 ASN.1 end
>PRI Span: 1 ERROR Component Context Specific/C [3 0x03]
>PRI Span: 1 invokeId Integer(2 0x02) = 3 0x0003
>PRI Span: 1 errorValue Integer(2 0x02) = 7 0x0007
>PRI Span: 1 errorValue = General: Invalid Call State
>PRI Span: 1 ROSE RETURN ERROR:
>PRI Span: 1 INVOKE ID: 3
>PRI Span: 1 ERROR: General: Invalid Call State
>PRI Span: 1
>PRI Span: 1 < Protocol Discriminator: Q.931 (8) len=16
>PRI Span: 1 < TEI=0 Call Ref: len= 2 (reference 3/0x3) (Sent to originator)
>PRI Span: 1 < Message Type: FACILITY (98)
>PRI Span: 1 < [1c 09 91 a3 06 02 01 04 02 01 07]
>PRI Span: 1 < Facility (len=11, codeset=0) [ 0x91, 0xA3, 0x06, 0x02, 0x01, 0x04, 0x02, 0x01, 0x07 ]
>PRI Span: 1 Received message for call 0xa9519f8 on link 0xa83ef9c TEI/SAPI 0/0
>PRI Span: 1 -- Processing IE 28 (cs0, Facility)
>PRI Span: 1 -- Delayed processing IE 28 (cs0, Facility)
>PRI Span: 1 ASN.1 dump
>PRI Span: 1 Context Specific/C [3 0x03] <A3> Len:6 <06>
>PRI Span: 1 Integer(2 0x02) <02> Len:1 <01>
>PRI Span: 1 <04> - "~"
>PRI Span: 1 Integer(2 0x02) <02> Len:1 <01>
>PRI Span: 1 <07> - "~"
>PRI Span: 1 ASN.1 end
>PRI Span: 1 ERROR Component Context Specific/C [3 0x03]
>PRI Span: 1 invokeId Integer(2 0x02) = 4 0x0004
>PRI Span: 1 errorValue Integer(2 0x02) = 7 0x0007
>PRI Span: 1 errorValue = General: Invalid Call State
>PRI Span: 1 ROSE RETURN ERROR:
>PRI Span: 1 INVOKE ID: 4
>PRI Span: 1 ERROR: General: Invalid Call State
>PRI Span: 1
>PRI Span: 1 < Protocol Discriminator: Q.931 (8) len=13
>PRI Span: 1 < TEI=0 Call Ref: len= 2 (reference 4/0x4) (Sent to originator)
>PRI Span: 1 < Message Type: DISCONNECT (69)
>PRI Span: 1 < [08 02 80 90]
>PRI Span: 1 < Cause (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) Spare: 0 Location: User (0)
>PRI Span: 1 < Ext: 1 Cause: Normal Clearing (16), class = Normal Event (1) ]
>PRI Span: 1 < [1e 02 82 88]
>PRI Span: 1 < Progress Indicator (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) 0: 0 Location: Public network serving the local user (2)
>PRI Span: 1 < Ext: 1 Progress Description: Inband information or appropriate pattern now available. (8) ]
>PRI Span: 1 Received message for call 0xa9760b8 on link 0xa83ef9c TEI/SAPI 0/0
>PRI
>
>Regards
>Maani
>
>> This is best asked on the asterisk-users mailing list for the benefit of
>> other people and for list archive searches.
>
>> You haven't mentioned which Asterisk/libpri versions are involved so the
>> functionality may not be available. Only ETSI(EuroISDN) and Q.SIG really
>> support what you are talking about on currently supported Asterisk and libpri
>> versions. Several North American switch types blindly just send a request
>> message to do this but I don't know if it actually works.
>
>> However, there are several reasons why it may not work:
>
>> 1) Asterisk must be configured to do it. The channels in the ISDN span must
>> have transfer=yes, facilityenable=yes, and switchtype=euroisdn or qsig
>> configured in the chan_dahdi.conf file.
>
>> 2) Asterisk must not have any reason to remain in the middle. i.e., The call
>> must be over the same ISDN span with no local channels in the path, no DTMF
>> features enabled on the call (Dial tT type options), and no audio-hooks or
>> frame-hooks attached for things like call recording.
>
>> 3) The peer must be provisioned to allow the feature.
>
>> 4) The peer may not accept the transfer request at the time for other reasons.
>
Asterisk is attempting to push the tromboned call back to the telco switch.
However, as shown in the fragment of the call, the peer is rejecting the transfer
request. Either the peer is not provisioned to allow it or it just does not support
the functionality.
Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20140712/c7898687/attachment.html>
More information about the asterisk-users
mailing list