Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

OS4K as a transit node for SIP traffic

Status
Not open for further replies.

GZgidnick

Technical User
Jan 8, 2015
156
AU
Hi Gents, I know many good 4K resource monitor this forum and hope for some tips and advises as I don't know where to turn to next.

What I have is a simple SIP-4K-CO setup.
This SIP server is a Fax server. Dialogic's RightFax.
I'm attaching the Interop guide used to build the solution here

External incoming calls coming to RightFax from CO no problems.
Rightfax outgoing calls to internal 4K extension no problems.
Rightfax outgoing calls (via 4K) to CO is a no go!

I have tried many thing, used IMPLICIT and used EXPLICIT numbers.
I tried even pushing the calls via TIE codes but no.
All calls coming from RightFax are disconnected by OS4K with "Number not Present"; - as if it is trying match the number against its internal extensions but never tries LDPLN.

Here is a simple trace for you to see what is going on:
Message Sequence:
Line 18685: Incoming CR00B7 (Q.931) (Orig) TYPE: SETUP
Line 18751: Outgoing CR00B7 (Q.931) (Dest) TYPE: CALL PROCEEDING
Line 18803: Outgoing CR00B7 (Q.931) (Dest) TYPE: PROGRESS
Line 18885: Incoming CR00B7 (Q.931) (Orig) TYPE: RELEASE
Line 18940: Outgoing CR00B7 (Q.931) (Dest) TYPE: RELEASE COMPLETE



Message Details:

Incoming CR00B7 (Q.931) (Orig) TYPE: SETUP
IE: 1 ( 3) : (04) Bearer Capability
80 90 A3
CCITT Speech, a-law
IE: 2 ( 1) : (18) Channel identification
A3
Any B-Channel
The channel is preferred
IE: 3 (52) : (1C) QSIG facility
9F AA 06 80 01 00 82 01 00 8B 01 00 A1 26 02 01
02 06 08 2B 0C 02 88 53 02 01 00 30 17 82 15 03
Networking Extension
Network Facility Extensions
Entity - Source: endPinx, Dest: endPinx,
InterpreApdu: discardAnyUnrecogInvokePdu
Invoke
InvokeComp - ID: 02
Component type: Global value
Operation: CorNet-N (0)
CodeSet7 IEs
IE: 1 (19) : (03) Classmarks
00 00 02 10 01 68 00 02 00 00 80 FE 80 01 00 00
1E 00 80
Public Telephone Network
Normal Call
ITR: 0, LCOS: 0
IE: 4 ( 2) : (1E) Progress indicator
81 83
Originator is not ISDN
IE: 5 (13) : (6C) Calling party number
11 80 36 31 33 38 33 34 35 31 32 38 30
International, ISDN, Present. allowed, User provided
61383451280
IE: 6 (10) : (70) Called party number
80 30 39 35 39 34 31 30 35 30
Unknown, Unknown
095941050







Outgoing CR00B7 (Q.931) (Dest) TYPE: CALL PROCEEDING
IE: 1 ( 3) : (18) Channel identification
A9 83 84
B-channel number 4
The channel is exclusive








Outgoing CR00B7 (Q.931) (Dest) TYPE: PROGRESS
IE: 1 ( 2) : (08) Cause
80 81
Cause Code: 1, UNASSIGNED_NR
IE: 2 (35) : (1C) QSIG facility
9F AA 06 80 01 00 82 01 00 8B 01 00 A1 15 02 02
9B 0A 06 08 2B 0C 02 88 53 02 01 06 03 05 00 01
Networking Extension
Network Facility Extensions
Entity - Source: endPinx, Dest: endPinx,
InterpreApdu: discardAnyUnrecogInvokePdu
Invoke
InvokeComp - ID: 9B0A
Component type: Global value
Operation: AdditionalCallProgress (6)
nearEndHoldPossible
IE: 3 (29) : (1C) QSIG facility
9F AA 06 80 01 00 82 01 00 8B 01 00 A1 0F 02 02
9B 19 02 01 55 30 06 82 04 06 04 08 40
Networking Extension
Network Facility Extensions
Entity - Source: endPinx, Dest: endPinx,
InterpreApdu: discardAnyUnrecogInvokePdu
Invoke
InvokeComp - ID: 9B19
Component type: Local value
Operation: CMN_INFORM (85)
Feature Identifiers:
ssCOsupported (Bit:5) - Call Offer Supported
anfCINTcanInterceptImmediate (Bit:13) - Call Interception Immediate
IE: 4 (23) : (1C) QSIG facility
9F AA 06 80 01 00 82 01 00 8B 01 00 A1 09 02 02
9B 28 02 01 03 84 00
Networking Extension
Network Facility Extensions
Entity - Source: endPinx, Dest: endPinx,
InterpreApdu: discardAnyUnrecogInvokePdu
Invoke
InvokeComp - ID: 9B28
Component type: Local value
Operation: ISO_BUSY_NAME (3)
Not Available
IE: 5 (72) : (1C) QSIG facility
9F AA 06 80 01 00 82 01 01 8B 01 00 A1 3A 02 02
9B 37 06 08 2B 0C 02 88 53 02 01 00 30 2A 81 10
Networking Extension
Network Facility Extensions
Entity - Source: endPinx, Dest: anyTypeOfPinx,
InterpreApdu: discardAnyUnrecogInvokePdu
Invoke
InvokeComp - ID: 9B37
Component type: Global value
Operation: CorNet-N (0)
CodeSet0 IEs
IE: 1 (10) : (0C) Connected number
81 30 39 35 39 34 31 30 35 30
Unknown, ISDN
095941050

IE: 2 ( 2) : (74) Redirecting number
00 C0
Unknown, Unknown, Number not available, User provided
CodeSet7 IEs
IE: 3 ( 1) : (01) Private Network Specific Facility
81
PNSF Code: 01h, PNSF_FAC_W_OR_WOB
IE: 4 (14) : (03) Classmarks
00 00 00 00 01 00 00 A0 80 80 05 00 80 7F
Private Network
Normal Call
ITR: 0, LCOS: 127
IE: 5 ( 1) : (63) Redirecting party name
C3
(Not Provided)
IE: 6 ( 2) : (1E) Progress indicator
80 88
In-band information now available














Outgoing CR00B7 (Q.931) (Dest) TYPE: CALL PROCEEDING
IE: 1 ( 3) : (18) Channel identification
A9 83 84
B-channel number 4
The channel is exclusive




















Outgoing CR00B7 (Q.931) (Dest) TYPE: PROGRESS
IE: 1 ( 2) : (08) Cause
80 81
Cause Code: 1, UNASSIGNED_NR
IE: 2 (35) : (1C) QSIG facility
9F AA 06 80 01 00 82 01 00 8B 01 00 A1 15 02 02
9B 0A 06 08 2B 0C 02 88 53 02 01 06 03 05 00 01
Networking Extension
Network Facility Extensions
Entity - Source: endPinx, Dest: endPinx,
InterpreApdu: discardAnyUnrecogInvokePdu
Invoke
InvokeComp - ID: 9B0A
Component type: Global value
Operation: AdditionalCallProgress (6)
nearEndHoldPossible
IE: 3 (29) : (1C) QSIG facility
9F AA 06 80 01 00 82 01 00 8B 01 00 A1 0F 02 02
9B 19 02 01 55 30 06 82 04 06 04 08 40
Networking Extension
Network Facility Extensions
Entity - Source: endPinx, Dest: endPinx,
InterpreApdu: discardAnyUnrecogInvokePdu
Invoke
InvokeComp - ID: 9B19
Component type: Local value
Operation: CMN_INFORM (85)
Feature Identifiers:
ssCOsupported (Bit:5) - Call Offer Supported
anfCINTcanInterceptImmediate (Bit:13) - Call Interception Immediate
IE: 4 (23) : (1C) QSIG facility
9F AA 06 80 01 00 82 01 00 8B 01 00 A1 09 02 02
9B 28 02 01 03 84 00
Networking Extension
Network Facility Extensions
Entity - Source: endPinx, Dest: endPinx,
InterpreApdu: discardAnyUnrecogInvokePdu
Invoke
InvokeComp - ID: 9B28
Component type: Local value
Operation: ISO_BUSY_NAME (3)
Not Available
IE: 5 (72) : (1C) QSIG facility
9F AA 06 80 01 00 82 01 01 8B 01 00 A1 3A 02 02
9B 37 06 08 2B 0C 02 88 53 02 01 00 30 2A 81 10
Networking Extension
Network Facility Extensions
Entity - Source: endPinx, Dest: anyTypeOfPinx,
InterpreApdu: discardAnyUnrecogInvokePdu
Invoke
InvokeComp - ID: 9B37
Component type: Global value
Operation: CorNet-N (0)
CodeSet0 IEs
IE: 1 (10) : (0C) Connected number
81 30 39 35 39 34 31 30 35 30
Unknown, ISDN
095941050
IE: 2 ( 2) : (74) Redirecting number
00 C0
Unknown, Unknown, Number not available, User provided
CodeSet7 IEs
IE: 3 ( 1) : (01) Private Network Specific Facility
81
PNSF Code: 01h, PNSF_FAC_W_OR_WOB
IE: 4 (14) : (03) Classmarks
00 00 00 00 01 00 00 A0 80 80 05 00 80 7F
Private Network
Normal Call
ITR: 0, LCOS: 127
IE: 5 ( 1) : (63) Redirecting party name
C3
(Not Provided)
IE: 6 ( 2) : (1E) Progress indicator
80 88
In-band information now available
\





Incoming CR00B7 (Q.931) (Orig) TYPE: RELEASE
IE: 1 ( 2) : (08) Cause
81 81
Cause Code: 1, UNASSIGNED_NR






Outgoing CR00B7 (Q.931) (Dest) TYPE: RELEASE COMPLETE
IE: 1 ( 2) : (08) Cause
80 90
Cause Code: 16, NORMAL_CLEARING





I think the incoming TON/NPI Unknown/Unknown is messing things up. Tried to address this with KNFOR but it didn't work.
Furthermore, in the trace there is no Node Number passed through neither originating nor destination; - I have however confirmed that KNMAT rules work when applied against the NNO of the TDCSU.

Please have a look and let me know if you got any ideas
 
 https://files.engineering.com/getfile.aspx?folder=021c074e-85a8-4bd8-97bd-3dcea4d6d427&file=Cfg_Guide_SR140_and_Siemens_HiPath_4000.pdf
Hi.

Did you try to make a test with TON/NPI: NATIONAL/ISDN ?

On INC SETUP :
(Q.931) (Orig) TYPE: SETUP
Bearer Capability
CCITT Speech, a-law

Make also a test with:
CHA-ZANDE:OPTFEA,A,530;
for conversion of the Bearer Capability from Speech to 3.1kHz
 
Can you dial the number 095941050 from 4K handset?
What does dis-ldpln:cd,095941050; return?
Can you post dis-tdcsu for that SIP circuit, and the matching dis-cot ?
 
Hi Morendi,

I dial the number from the SIP server TIE-ed with the 4K.
There is a LDPLN matching entry, but call does not proceeds.

I think because it comes with Unknown/Unknown the 4K only searches its internal extension database and disconnects the call as it does not finds a matching entry.
Gives back a "UNASSIGNED_NR" message.

The SIP trunk connecting the Dialogic SIP server (Fax) has been build according the DIalogic's introp guide. I have attached the guide in my initial post.
 
4K will handle unknown/unknown no problem.

>Can you dial the number 095941050 from 4K handset?
You didn't answer
>What does dis-ldpln:cd,095941050; return?
You didn't answer
>Can you post dis-tdcsu for that SIP circuit, and the matching dis-cot ?
You didn't answer.

You can turn on number modification diags with CHA-DIAGS. In path CP2, set S05 to ON. Make your test call. Number diags will be visible in HISTA.
Remember to set S05 to OFF when finished or hista will be flooded.

TRACS trace would be useful, if you are happy to post the content.
 
Not that it's relevant here, but my understanding of how I am planning to do my new RightFax integration is that RightFax communicates with the OTFG 2100 via SIP and the OTFG 2100 communicates with the 4K over a T1. I don't have sip coming in, so that may be a factor, but my current RightFax setup has a TR1034 Fax Board in the server that connects directly to the T1 and provides 24 physical channels to the 4K. In the new world when I go with the VM I will have the gateway in between RightFax and the PBX to convert the SIP into the individual channels for the T1 line. I won't know much about how it works until I go to do it, but supposedly I can connect the gateway to the server out of box, and all I have to do is enter a few parameters into the gateway for the T1 (B8Zs, etc) and then just plug it in - all the trunking and routing is already in the switch and will stay the same. You do have to tell the OTFG (if you have one) what numbers it is routing to the server.

Don Bruechert, Voice Comm Analyst II
CareTech Solutions @ Holy Family Memorial
Manitowoc, WI, USA
 
Don - Our RightFax uses a VMware server with the 2100 Gateway. We have a PRI that plugs right into the 2100. So the 2100 talks SIP to the VMware server. So we took the PBX out of the loop. (Maybe that's what you're saying you're going to do?) Haven't had to touch it since it was installed a few years ago. We had professional services do the install and config, so it was a breeze.

LoPath
Maintain HiPath 4000 V5 & V6, OpenScape Xpert V4 & V6, OpenScape Xpressions V7, OpenScape Contact Center V8, OpenScape Voice V9
 
Yes, but I won't have the PRI direct to the gateway like you do. The PRI (3) are connected to the PBX and I will be using a channelized T1 between the gateway and PBX to route the phone calls. The PBX is set up so all the incoming DID calls for RightFax just get routed to that one T1 trunk, and RightFax has its own trunk group using that T1 for outgoing call routing already. That part should stay exactly the same when I upgrade - it will only be the SIP connection from the gateway to the VM to deal with, and supposedly most of that is set up in the gateway OOB so it will only be setting up the virtual ports on RightFax I guess. I am making it sound easy to keep myself from worrying to death, but it will probably be a PITA! :)


Don Bruechert, Voice Comm Analyst II
CareTech Solutions @ Holy Family Memorial
Manitowoc, WI, USA
 
Are you putting a gateway in just to go T1->SIP Don? Why not go direct to the Rightfax with SIP? Gateway is just another piece of kit to to maintain and go wrong, more traces needed when it doesn't work and somebody else to argue with when they say it's not them. If you have an Access 500 you could just add a vSTMI, STMI4s are still available if you look hard enough.. I think you're V7 R2 so STMIX is not possible. But maybe for the cost of that gateway you could have added a softgate instead and that opens up a load of extra HFA, SIP phone, SIP trunks...
 
Might be worth using Wireshark or similar on the Rightfax server and placing a call, then looking at the SIP messages.
Never used a 2100 Gateway but it may be possible to get a .pcap trace file from them. (You can on the STMI's and DX35XX cards on the old ISDX).

Does the 2100 Gateway have different SIP profiles? (Like the STMI's and DX35XX). Check against any configuration guides.

What version of Rightfax are you running?
There is a bug in some versions of 16.4 where the SIP channels lockup after 24.8 days.(It's actually in the Dialogic SDK).
It was fixed in the latest 16.4 Service Release.

Not a fan of conversion boxes. Still have the mentsl scars from using IQ2000 DPNSS to QSIG converters with Avaya...
 
@Moriendi - Laziness for the most part. The 4K is not set up for SIP (trunking) so I would have to do a board and find someplace to put it. We send a lot of big faxes so the board would have a lot of traffic and finding the right location would be important, plus I would have to buy the board for almost as much as the gateway, and the current T1 and all the routing is already set up and I won't have to do it over - just config the T1 port in the gateway and plug it in, and tell the gateway what extensions I'm passing - I haven't downloaded the manual yet, and I have been here a long time - I won't get excited until February or March when I find out if my request stayed above the budget line or not. :)

Don Bruechert, Voice Comm Analyst II
CareTech Solutions @ Holy Family Memorial
Manitowoc, WI, USA
 
What's your T1 Don? 24 channels? So, not so much traffic. It's crazy to put a protocol convertor in, when you're converting to a protocol that your PBX will already supply. It's a nightmare when it doesn't work properly and you've got this extra box in the middle which you didn't need anyway. And if your routing is already set up for the DIU, then it's already set up for SIP. All you need to do is add the new buend in the existing richt and ldat as step 2, then deactivate or delete step 1. It would take less than 5 minutes to add that SIP trunk. And for the bang for your buck, all the convertor will do is send calls to the rightfax. An STMI would provide your SIP trunk, AND hfa extensions, AND sip extensions. AND it's all manageable from an interface you're familiar with.

If you post a dis-bcsu:tbl; would be interesting to see if there was a location for it - if not then yes it becomes a hassle with a new shelf (although it takes 10 seconds to cable a new shelf, and less to add it in config).
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top