Daniel Tryba
2011-Sep-02 14:31 UTC
[asterisk-users] QSIG-SIP overlap dialing and Asterisk (RFC4497)
P.H.B. is insisting on having the ability to create a transparant SIP tunnel between old style ISDN telephony PBX with overlap dialing: PBX - ISDN - IAD - SIP - * - DAHDI - PRI The idea is that dialed numbers a the PBX are transmitted to the PRI as they are typed, whenever the PRI gets the signal that the number is complete the dialer instantly gets a ringing. This behavior is described in RFC 4497. Section A.2.3. SIG to SIP, using overlap procedures on both QSIG and SIP. Ideally this should be possible with a simple context: [progresstrunk] exten => anonymous,1,Dial(dahdi/g1) The SIP and DAHDI conversation goes as follows, user picks up a phone and tries to dial a number. SIP > SIP/SDP Request: INVITE sip:anonymous at asterisk:5060, with session description DAHDI > Message Type: SETUP (5) DAHDI > [04 03 80 90 a3] DAHDI > Bearer Capability (len= 5) [ Ext: 1 Q.931 Std: 0 Info transfer capability: Speech (0) DAHDI > Ext: 1 Trans mode/rate: 64kbps, circuit-mode (16) DAHDI > User information layer 1: A-Law (35) DAHDI > [18 03 a1 83 81] DAHDI > Channel ID (len= 5) [ Ext: 1 IntID: Implicit Other(PRI) Spare: 0 Preferred Dchan: 0 DAHDI > ChanSel: As indicated in following octets DAHDI > Ext: 1 Coding: 0 Number Specified Channel Type: 3 DAHDI > Ext: 1 Channel: 1 Type: CPE] DAHDI > [6c 0b 00 80 34 30 32 39 33 38 36 36 31] DAHDI > Calling Number (len=13) [ Ext: 0 TON: Unknown Number Type (0) NPI: Unknown Number Plan (0) DAHDI > Presentation: Presentation permitted, user number not screened (0) '123456789' ] DAHDI > [70 01 80] DAHDI > Called Number (len= 3) [ Ext: 1 TON: Unknown Number Type (0) NPI: Unkn own Number Plan (0) '' ] DAHDI < Protocol Discriminator: Q.931 (8) len=14 DAHDI < TEI=0 Call Ref: len= 2 (reference 9/0x9) (Sent to originator) DAHDI < Message Type: SETUP ACKNOWLEDGE (13) DAHDI < [18 03 a9 83 81] DAHDI < Channel ID (len= 5) [ Ext: 1 IntID: Implicit Other(PRI) Spare: 0 Exclusive Dchan: 0 DAHDI < ChanSel: As indicated in following octets DAHDI < Ext: 1 Coding: 0 Number Specified Channel Type: 3 DAHDI < Ext: 1 Channel: 1 Type: CPE] DAHDI < [1e 02 82 88] DAHDI < Progress Indicator (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) 0: 0 Location: Public network serving the local user (2) DAHDI < Ext: 1 Progress Description: Inband information or appropriate pattern now available. (8) ] SIP < SIP Status: 100 Trying SIP < SIP Status: 100 Trying DAHDI < Message Type: CALL PROCEEDING (2) DAHDI < [18 03 a9 83 81] DAHDI < Channel ID (len= 5) [ Ext: 1 IntID: Implicit Other(PRI) Spare: 0 Exclusive Dchan: 0 DAHDI < ChanSel: As indicated in following octets DAHDI < Ext: 1 Coding: 0 Number Specified Channel Type: 3 DAHDI < Ext: 1 Channel: 1 Type: CPE] DAHDI < Protocol Discriminator: Q.931 (8) len=13 DAHDI < TEI=0 Call Ref: len= 2 (reference 1/0x1) (Sent to originator) DAHDI < Message Type: DISCONNECT (69) DAHDI < [08 02 80 9c] DAHDI < Cause (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) Spare: 0 Location: User (0) DAHDI < Ext: 1 Cause: Invalid number format (28), class = Normal Event (1) ] DAHDI < [1e 02 80 88] DAHDI < Progress Indicator (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) 0: 0 Location: User (0) DAHDI < Ext: 1 Progress Description: Inband information or appropriate pattern now available. (8) ] SIP < SIP Status: 503 Service Unavailable SIP > SIP Request: ACK sip:anonymous at asterisk:5060 If the context is changed to: [progresstrunk] exten => anonymous,1,Answer() exten => anonymous,1,Dial(dahdi/g1) The user picking up the phone get a asterisk generated dialtone and keypresses are send using the configured DTMF transport: SIP > SIP/SDP Request: INVITE sip:anonymous at asterisk:5060, with session description SIP < SIP Status: 100 Trying SIP < SIP/SDP Status: 200 OK, with session description SIP > SIP Request: ACK sip:anonymous at asterisk SIP > SIP Request: INFO sip:anonymous at asterisk SIP < SIP Status: 200 OK SIP > SIP Request: INFO sip:anonymous at asterisk SIP < SIP Status: 200 OK As soon as the PRI thinks the dialed number is complete the phone RINGS. DAHDI > Protocol Discriminator: Q.931 (8) len=9 DAHDI > TEI=0 Call Ref: len= 2 (reference 7/0x7) (Sent from originator) DAHDI > Message Type: INFORMATION (123) DAHDI > [70 02 80 38] DAHDI > Called Number (len= 4) [ Ext: 1 TON: Unknown Number Type (0) NPI: Unknown Number Plan (0) '8' ] DAHDI > Protocol Discriminator: Q.931 (8) len=9 DAHDI > TEI=0 Call Ref: len= 2 (reference 7/0x7) (Sent from originator) DAHDI > Message Type: INFORMATION (123) DAHDI > [70 02 80 35] DAHDI > Called Number (len= 4) [ Ext: 1 TON: Unknown Number Type (0) NPI: Unknown Number Plan (0) '5' ] DAHDI < Protocol Discriminator: Q.931 (8) len=10 DAHDI < TEI=0 Call Ref: len= 2 (reference 7/0x7) (Sent to originator) DAHDI < Message Type: CALL PROCEEDING (2) DAHDI < [18 03 a9 83 81] DAHDI < Channel ID (len= 5) [ Ext: 1 IntID: Implicit Other(PRI) Spare: 0 Exclusive Dchan: 0 DAHDI < ChanSel: As indicated in following octets DAHDI < Ext: 1 Coding: 0 Number Specified Channel Type: 3 DAHDI < Ext: 1 Channel: 1 Type: CPE] DAHDI < Protocol Discriminator: Q.931 (8) len=9 DAHDI < TEI=0 Call Ref: len= 2 (reference 7/0x7) (Sent to originator) DAHDI < Message Type: ALERTING (1) DAHDI < [1e 02 80 88] DAHDI < Progress Indicator (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) 0: 0 Location: User (0) DAHDI < Ext: 1 Progress Description: Inband information or appropriate pattern now available. (8) ] So the Asterisk - DAHDI - PRI part works. The problem is in the fact Asterisk responds with a TRYING to the empty INVITE. It should respond with a SIP 484 (Address Incomplete) the let the IAD know more input is required. The reason for me asking is http://svnview.digium.com/svn/asterisk/team/oej/sip-compliance/asterisk-sip.txt which mentions: 3. PSTN Internetworking ----------------------- ... - RFC 4497: Interworking between the Session Initiation Protocol and QSIG Supported I can't seem to find any other references to rfc 4497 and Asterisk. Is this setup possible or should I just emulate it with DISA or simply configure the IAD to collect the digits and just bear with the numbercomplete timeout (which is always either to short or to long and users don't seem to remember terminating with a # will speedup dialing). The IAD used to test is a Patton SmartNode 4638 (running the older SmartWare 5.2) and an old fashioned ISDN telephone. The Patton should be able to work like requested. -- Daniel Tryba
Maybe Matching Threads
Wisdom of the Ancients
