[asterisk-users] QSIG-SIP overlap dialing and Asterisk (RFC4497)
Daniel Tryba
daniel at tryba.nl
Fri Sep 2 09:31:28 CDT 2011
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
More information about the asterisk-users
mailing list