Genesys CTI User Forum
Genesys CTI User Forum => Genesys CTI Technical Discussion => Topic started by: janesh22 on August 14, 2015, 12:55:28 AM
-
Hi,
This will be very basic considering other questions that you guys get. I am a starter with genesys. I am working on a lab environment here and I have one sip server configured on one host and an Avaya Tserver connected to avaya switch simulator on another host. I have been trying to make a call from x-lite phone connected to sip server to IWS who is connected to Avaya Tserver. But has been unsuccessful so far.
I will let you know what I have done so far.
I have got connection to Tserver from sip server and vice versa. I have added Switch access code to both . Is there anything else that i require ? I am able to make calls within the sip environment and also from avaya to avaya.
I tried reading the manuals but it has already confused me more. so just thought if any of you can give me some idea what i am missing here.
The logs in sip server looks like this :
16:21:00.161 Int 04543 Interaction message "RequestMakeCall" received from 560 ("IWS_MAngelou")
@16:21:00.1610 [ISCC] destination_location substituted by local
@16:21:00.1610 [ISCC] destination_location substituted by local
16:21:00.161 -- created: CRequest@2b69a58 RequestMakeCall-IWS_MAngelou[560]/6
16:21:00.161: $+TLIB:CTI:Unknown:0:79806995
16:21:00.161 +++ CIFace::Request +++
-- new invoke
Parsed: RequestMakeCall
From: IWS_MAngelou[560]/6
Numbers: +<8002> -<6002>
Status: parsed:1 queued:0 sent:0 acked:0 preevent:0 event:0 context:0 transferred:0
-----
-- validate
-- state check: ok
CIFace: Sent CRequest@2b69a58 RequestMakeCall-IWS_MAngelou[560]/6
FinishRequest CRequest@2b69a58 RequestMakeCall-IWS_MAngelou[560]/6
IFace stats: q=0 s=0
-- complete
16:21:00.161: ResolveCallInfo: set flag DIAL_PLAN_PROCESSING
16:21:00.161: SIPTR(16): Begin step 0 - SipTransactionResolveCallInfoByDialPlan(17)
16:21:00.161: DialPlan: No dialplan defined for 8002.
16:21:00.161: DialPlan: No rule applied, using original destination '6002'.
16:21:00.161: DialPlan: clear flag DIAL_PLAN_PROCESSING
16:21:00.161: Number:[6002] is not internal, looking for service
16:21:00.161: Number:6002 did not find any gateway with matching prefix to send this call to
16:21:00.161: Unable to resolve number for DN:6002
16:21:00.161: SIPDM: failed to get registration info for 6002
16:21:00.161: SIPDM: failed to get registration info for 6002
16:21:00.161: Call connect failed with error WRONG_NUMBER, no DialPlan script condition - rejecting call.
16:21:00.161: ERROR: 10000029, DialPlanHandleConnect(scenario, trData,result,*instruction), SipCallManagerDialPlan.cpp,2128
16:21:00.161: SIPTR(17): failed
16:21:00.161: SIPTR(16): Step 0 - SipTransactionResolveCallInfoByDialPlan(17) failed
16:21:00.161: SIPTR(16): failed
16:21:00.161: SIPCM: transaction SipScenario failed
16:21:00.161: CALLSTATE: empty, delete the call 5
16:21:00.161: OnRequestFailed
16:21:00.161 Trc 36002 Request rejected: error code 71(Invalid Called Dn)
@16:21:00.1610 [0] 8.1.101.17 send_to_client: message EventError
(Invalid Called Dn)
AttributeEventSequenceNumber 0000000000000036
AttributeTimeinuSecs 161000
AttributeTimeinSecs 1439446860 (16:21:00)
AttributeExtensions [2] 00 00..
AttributeErrorCode 71
AttributeErrorMessage 'Invalid Called Dn'
AttributeMakeCallType 0 (MakeCallRegular)
AttributeOtherDN '6002'
AttributeLocation ''
AttributeUserData [106] 00 02 00 00..
'IW_CaseUid' '4843571c-77a8-4e6d-b888-2c7d9fea0807'
'IW_BundleUid' '5f938e3e-b954-4902-ab19-0be6197530d5'
AttributeThisDN '8002'
AttributeReferenceID 6
AttributeClientID 5
It looks like saying "no dial plan ". Do i need dial plan configured for tserver to tserver calls ? If so , what needs to be done ?
Thanks,
J
-
It is not about DialPlan, but about incorrect configuration of dest DN. This may be caused by failed registration of remote/dest DN or incorrect configuration of trunks to the Gateway(Avaya)
-
Hi Kubig,
Thanks for your response. Can you be more specific ?
Configuration of destination DN - How is this done ? by configuring access codes ?
incorrect configuration of trunks to gateway (Avaya) - is this access code on the switch as well ?
Thanks,
J
-
Create trunks for each prefix also on remote Avaya extension or VDN. Any object to be routed to.
Enviado de meu C6602 usando Tapatalk
-
Hi Cavagnaro,
Sorry for being so stupid. But I still cannot get the call from sip to avaya working.
I have done the following :
-Added access code to both the sip and avaya switch
-Added External route point and trunk to both the switches
-Added access number in the External route point
Still does not work
Log for sip server :
@location -a = 'AvayaSwitch'
backup-type = not-specified <DM>
state = enabled
protocol = 'addp'
addp-timeout = 100
addp-remote-timeout = 100
addp-trace = 'off' <DM>
app-type = 1
access-code -a = '-N/A-'
backup-for = NULL <DM>
primary-for = NULL <DM>
options list <M>
reconnect-tout = '5 sec' <DM>
cast-type = 'route direct-callid reroute direct-uui direct-ani direct-notoken dnis-pool direct-digits pullback route-uui direct-network-callid' <DM>
timeout = '1 min'
request-tout = '20 sec' <DM>
default-dn = NULL <DM>
extrouter list <M>
default-cast-type -a = route
backward-cast-type -a = (undef)
inbound-transaction-parameters -a = NULL <D>
inbound-cof-parameters -a = 'match-callid, match-flexible=true, inbound-only=true' <D>
outbound-transaction-parameters -a = 'propagate=yes' <D>
outbound-cof-parameters -a = NULL <D>
cluster-role = off <DM>
proxy-name = NULL <DM>
ReportingStatServer [120] list {aux} <+M>
@location -a = 'ReportingStatServer' <+>
backup-type = not-specified <+D>
state = enabled <+>
protocol = 'default' <+D>
addp-timeout = 0 <+D>
addp-remote-timeout = 0 <+D>
addp-trace = 'off' <+D>
app-type = 2 <+>
access-code -a = NULL <+D>
backup-for = NULL <DM>
primary-for = NULL <DM>
options list <D>
reconnect-tout = '5 sec' <DM>
cast-type = 'route direct-callid reroute direct-uui direct-ani direct-notoken dnis-pool direct-digits pullback route-uui direct-network-callid' <DM>
timeout = '60 sec' <DM>
request-tout = '20 sec' <DM>
default-dn = NULL <DM>
extrouter list <DM>
default-cast-type -a = default <DM>
backward-cast-type -a = route <DM>
inbound-transaction-parameters -a = NULL <DM>
inbound-cof-parameters -a = 'match-callid, match-flexible=true, inbound-only=true' <DM>
outbound-transaction-parameters -a = 'propagate=yes' <DM>
outbound-cof-parameters -a = NULL <DM>
cluster-role = off <DM>
proxy-name = NULL <DM>
AgentLogin array
[167] login-id = '1801' state = enabled
[168] login-id = '1802' state = enabled
[169] login-id = '1803' state = enabled
[170] login-id = '1804' state = enabled
[171] login-id = '1805' state = enabled
[172] login-id = '1806' state = enabled
[173] login-id = '1807' state = enabled
[174] login-id = '1808' state = enabled
[175] login-id = '1809' state = enabled
[176] login-id = '1810' state = enabled
DN array
8001 [199] dn = '8001' type = Extension xtype = DN cfgtype = 1 sstype = 1 reg-mode = 0x21 = +force register-flag = true
8002 [200] dn = '8002' type = Extension xtype = DN cfgtype = 1 sstype = 1 reg-mode = 0x21 = +force register-flag = true
8003 [201] dn = '8003' type = Extension xtype = DN cfgtype = 1 sstype = 1 reg-mode = 0x21 = +force register-flag = true
8004 [202] dn = '8004' type = Extension xtype = DN cfgtype = 1 sstype = 1 reg-mode = 0x21 = +force register-flag = true
8005 [203] dn = '8005' type = Extension xtype = DN cfgtype = 1 sstype = 1 reg-mode = 0x21 = +force register-flag = true
8006 [204] dn = '8006' type = Extension xtype = DN cfgtype = 1 sstype = 1 reg-mode = 0x21 = +force register-flag = true
8007 [205] dn = '8007' type = Extension xtype = DN cfgtype = 1 sstype = 1 reg-mode = 0x21 = +force register-flag = true
8008 [206] dn = '8008' type = Extension xtype = DN cfgtype = 1 sstype = 1 reg-mode = 0x21 = +force register-flag = true
8009 [207] dn = '8009' type = Extension xtype = DN cfgtype = 1 sstype = 1 reg-mode = 0x21 = +force register-flag = true
8010 [208] dn = '8010' type = Extension xtype = DN cfgtype = 1 sstype = 1 reg-mode = 0x21 = +force register-flag = true
8011 [209] dn = '8011' type = Extension xtype = DN cfgtype = 1 sstype = 1 reg-mode = 0x21 = +force register-flag = true
8801 [212] dn = '8801' type = ACDQ xtype = Queue cfgtype = 3 sstype = 1 register-flag = true
8802 [213] dn = '8802' type = ACDQ xtype = Queue cfgtype = 3 sstype = 1 register-flag = true
SIP_to_Avaya [218] dn = 'SIP_to_Avaya' type = TRUNK xtype = Trunk cfgtype = 14 sstype = 1 ext = '6' register-flag = true
DN/EXR array
8881 [214] *cdn = '8881' type = RtQueue xtype = RouteDN cfgtype = 19 sstype = 1 auxdata = '8881'
access-list array
[107] location = 'sc_server_p' number = '8881' source = 1
[120] location = 'ReportingStatServer' number = '8881' source = 1
linked-resources array register-flag = true
8882 [215] *cdn = '8882' type = RtQueue xtype = RouteDN cfgtype = 19 sstype = 1 auxdata = '8882'
access-list array
[107] location = 'sc_server_p' number = '8882' source = 1
[120] location = 'ReportingStatServer' number = '8882' source = 1
linked-resources array register-flag = true
8883 [222] cdn = '8883' type = RtQueue xtype = RouteDN cfgtype = 19 sstype = 1 ext = '8' override = '8883' reg-mode = 0x11 = +force
access-list array
[105] location = 'AvayaSwitch' number = '8' source = 2
linked-resources array register-flag = true
[-1] cdn = 'direct' type = N/A reg-mode = 0x0 =
access-list array
[107] location = 'sc_server_p' source = 1
[120] location = 'ReportingStatServer' source = 1
linked-resources array
@11:26:56.1210 [TCONF] Location updated:
sc_server_p [107] list {aux} <+M>
@location -a = 'sc_server_p'
backup-type = not-specified <+DM>
state = enabled
protocol = 'default' <D>
addp-timeout = 0 <D>
addp-remote-timeout = 0 <D>
addp-trace = 'off' <D>
app-type = 43
access-code -a = NULL <D>
backup-for = NULL <DM>
primary-for = NULL <DM>
options list <DM>
reconnect-tout = '5 sec' <DM>
cast-type = 'route direct-callid reroute direct-uui direct-ani direct-notoken dnis-pool direct-digits pullback route-uui direct-network-callid' <DM>
timeout = '60 sec' <DM>
request-tout = '20 sec' <DM>
default-dn = NULL <DM>
extrouter list <DM>
default-cast-type -a = default <DM>
backward-cast-type -a = route <DM>
inbound-transaction-parameters -a = NULL <DM>
inbound-cof-parameters -a = 'match-callid, match-flexible=true, inbound-only=true' <DM>
outbound-transaction-parameters -a = 'propagate=yes' <DM>
outbound-cof-parameters -a = NULL <DM>
cluster-role = off <DM>
proxy-name = NULL <DM>
@11:26:56.1210 [ISCC] (server-configuration (application-name AvayaTserver_p) (dbid 119) (change))
addp-trace off
(addp_reconfig) local 100000 msec, remote 100000 msec, trace off
@11:26:56.1210 [ISCC] Location AvayaSwitch: available cast types (route direct-callid reroute direct-uui direct-ani direct-notoken dnis-pool direct-digits pullback route-uui direct-network-callid)
@11:26:56.1210 [ISCC] Location AvayaSwitch: default cast type route
@11:26:56.1210 [ISCC] Location AvayaSwitch: default-dn
@11:26:56.1210 [ISCC] Inbound Transaction parameters: NULL
@11:26:56.1210 [ISCC] Outbound Transaction parameters: ("propagate"="yes")
@11:26:56.1210 [ISCC] Inbound COF parameters: ("match-callid","match-flexible"="true","inbound-only"="true")
@11:26:56.1210 [ISCC] Outbound COF parameters: NULL
@11:26:56.1210 [ISCC] Location AvayaSwitch: dnis-tail 0
@11:26:56.1210 [ISCC] Location AvayaSwitch: Propagation Control (+udata, +party)
@11:26:56.1210 [ISCC] Location AvayaSwitch: COF: match-flexible(1)
@11:26:56.1210 [ISCC] Location AvayaSwitch: COF: match-callid(1) 1
@11:26:56.1210 [ISCC] Location AvayaSwitch: COF: match-ani(0) 0
@11:26:56.1210 [ISCC] Location AvayaSwitch: COF: inbound-only true
@11:26:56.1210 [ISCC] (server-configuration (application-name AvayaTserver_p) (dbid 119) (change complete))
@11:26:56.1210 [TCONF] Location updated:
AvayaTserver_p [119] list {aux} <+M>
@location -a = 'AvayaSwitch'
backup-type = not-specified <DM>
state = enabled
protocol = 'addp'
addp-timeout = 100
addp-remote-timeout = 100
addp-trace = 'off' <+D>
app-type = 1
access-code -a = '-N/A-'
backup-for = NULL <DM>
primary-for = NULL <DM>
options list <M>
reconnect-tout = '5 sec' <DM>
cast-type = 'route direct-callid reroute direct-uui direct-ani direct-notoken dnis-pool direct-digits pullback route-uui direct-network-callid' <DM>
timeout = '1 min'
request-tout = '20 sec' <DM>
default-dn = NULL <DM>
extrouter list <M>
default-cast-type -a = route
backward-cast-type -a = (undef)
inbound-transaction-parameters -a = NULL <D>
inbound-cof-parameters -a = 'match-callid, match-flexible=true, inbound-only=true' <D>
outbound-transaction-parameters -a = 'propagate=yes' <D>
outbound-cof-parameters -a = NULL <D>
cluster-role = off <DM>
proxy-name = NULL <DM>
@11:26:56.1210 [TCONF] Location updated:
ReportingStatServer [120] list {aux} <+M>
@location -a = 'ReportingStatServer'
backup-type = not-specified <+DM>
state = enabled
protocol = 'default' <D>
addp-timeout = 0 <D>
addp-remote-timeout = 0 <D>
addp-trace = 'off' <D>
app-type = 2
access-code -a = NULL <D>
backup-for = NULL <DM>
primary-for = NULL <DM>
options list <DM>
reconnect-tout = '5 sec' <DM>
cast-type = 'route direct-callid reroute direct-uui direct-ani direct-notoken dnis-pool direct-digits pullback route-uui direct-network-callid' <DM>
timeout = '60 sec' <DM>
request-tout = '20 sec' <DM>
default-dn = NULL <DM>
extrouter list <DM>
default-cast-type -a = default <DM>
backward-cast-type -a = route <DM>
inbound-transaction-parameters -a = NULL <DM>
inbound-cof-parameters -a = 'match-callid, match-flexible=true, inbound-only=true' <DM>
outbound-transaction-parameters -a = 'propagate=yes' <DM>
outbound-cof-parameters -a = NULL <DM>
cluster-role = off <DM>
proxy-name = NULL <DM>
@11:26:56.1210 [TCONF] READER: status: [3]->[3]
@11:26:56.1210 [TCONF] READER: status: [3]->[3]
11:26:56.121 -- AgnEmu: parameter login state taken from global value
11:26:56.121 -- AgnEmu: parameter wrap-up-time taken from global option
11:26:56.121 -- AgnEmu: parameter legal-guard-time taken from global option
-AR[t/o:100000,trace]-<-532 @11:26:56.1210
-Ar[t/o:100000]->-532 @11:26:56.1210
-Ar[t/o:100000]-<-532 @11:26:56.1210
common: ConnTimerQueue option 'conn-timers-warning-processing-timeout' is set to the value '300' milliseconds
common: ConnTimerQueue option 'conn-timers-maximum-processing-timeout' is set to the value '1000' milliseconds
common: ConnTimerQueue option 'conn-timers-break-processing-loop' is set to the value 'false'
common: ConnTimerQueue option 'conn-timers-enable-extended-processing' is set to the value 'false'
11:27:31.775: $+NET:SIP::0:0
11:27:31.775: SIPTR: Received [0,UDP] 871 bytes from 10.191.45.70:40408 <<<<<
INVITE sip:66001@10.191.45.72:5060 SIP/2.0
Via: SIP/2.0/UDP 10.191.45.70:40408;branch=z9hG4bK-d87543-4d0c3460ba005469-1--d87543-;rport
Max-Forwards: 70
Contact: <sip:8003@10.191.45.70:40408>
To: "66001"<sip:66001@10.191.45.72:5060>
From: "8003"<sip:8003@10.191.45.72:5060>;tag=d916d51c
Call-ID: NGJmNjM5YjhmMDc1MzYyODA1ZTVkYTc5ZDU0YWZhYjU.
CSeq: 1 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
Content-Type: application/sdp
User-Agent: X-Lite release 1006e stamp 34025
Content-Length: 325
v=0
o=- 5 2 IN IP4 10.191.45.70
s=CounterPath X-Lite 3.0
c=IN IP4 10.191.45.70
t=0 0
m=audio 47810 RTP/AVP 107 119 0 98 8 3 101
a=alt:1 1 : 41GjunOz 1Cv06Aqn 10.191.45.70 47810
a=fmtp:101 0-15
a=rtpmap:107 BV32/16000
a=rtpmap:119 BV32-FEC/16000
a=rtpmap:98 iLBC/8000
a=rtpmap:101 telephone-event/8000
a=sendrecv
11:27:31.775: CallMatcher: no call match attributes found
11:27:31.775: ResolveCallInfo: set flag DIAL_PLAN_PROCESSING
11:27:31.775: SIPTR(46): Begin step 0 - SipTransactionCreateCall(47)
11:27:31.775 SIPCONN(8003): Create dialog
11:27:31.775: SipDialog: set monitor 037e24bc
11:27:31.775 SIPCONN(8003): refer dialog 037dbab8 initiated
11:27:31.775 SIPCONN(8003): change transaction 0 -> 0
11:27:31.775: SipDialog: set monitor 037e24bc
11:27:31.775 SIPCONN(8003): ClrMediaPeer
11:27:31.775: SIPDLG[15]: register TRN[15]
11:27:31.775: SIPDLG[15]: TRN[15] flags set to 0x1
11:27:31.775: SipDialog: event INVITE, t=15, s=1, r=5, m=037e24bc
11:27:31.775 SIPCONN(8003): HandleSipDialogEvent(INVITE)
11:27:31.775 SIPCONN(8003): Capabilities 19d
11:27:31.775 SIPCONN(8003): new transaction
11:27:31.775 SIPCONN(8003): store remote content
11:27:31.775 SIPCONN(8003): verify sdp
11:27:31.775 SIPCONN(8003): sdp state SDP_STATE_NULL, event SDP_EVENT_SDP
11:27:31.775 SIPCONN(8003): new sdp state SDP_STATE_OFFER_RECEIVED, event SDP_EVENT_SDP
11:27:31.775 SIPCONN(8003): state e:10,p:0,s:1,c:9,rc:0,m:0
11:27:31.775: SIPTR(47): complete
11:27:31.775: SIPTR(46): Step 0 - SipTransactionCreateCall(47) complete
11:27:31.775: SIPTR(46): Begin step 1 - SipTransactionResolveCallInfoByDialPlan(48)
11:27:31.775: DialPlan: No dialplan defined for 8003.
11:27:31.775: DialPlan: No rule applied, using original destination '66001'.
11:27:31.775: DialPlan: clear flag DIAL_PLAN_PROCESSING
11:27:31.775: Number:[66001] is not internal, looking for service
11:27:31.775: GetTheBestNode: no eligible service found for 66001
11:27:31.775: Number:66001 prefix: gateway list not empty, but none can be selected now
11:27:31.775: Unable to resolve number for DN:66001
11:27:31.775: SIPDM: failed to get registration info for 66001
11:27:31.775: SIPDM: failed to get registration info for 66001
11:27:31.775: Call connect failed with error WRONG_NUMBER, no DialPlan script condition - rejecting call.
11:27:31.775: SIPTR(48): complete
11:27:31.775: SIPTR(46): Step 1 - SipTransactionResolveCallInfoByDialPlan(48) complete
11:27:31.775: SIPTR(46): Begin step 2 - SipTransactionRejectCall(49)
11:27:31.775 SIPCONN(8003): re-invite-called-initiated
11:27:31.775: Sending [0,UDP] 371 bytes to 10.191.45.70:40408 >>>>>
SIP/2.0 404 Not Found
Via: SIP/2.0/UDP 10.191.45.70:40408;branch=z9hG4bK-d87543-4d0c3460ba005469-1--d87543-;rport;received=10.191.45.70
To: "66001"<sip:66001@10.191.45.72:5060>;tag=2FE171E2-AA20-4303-89D2-51854ABDC831-13
From: "8003"<sip:8003@10.191.45.72:5060>;tag=d916d51c
Call-ID: NGJmNjM5YjhmMDc1MzYyODA1ZTVkYTc5ZDU0YWZhYjU.
CSeq: 1 INVITE
Content-Length: 0
-
Paste a screenshot of your trunk configuration from SIP to Avaya.
-
[URL=https://imageshack.com/i/idV6oUeJp][IMG]http://imagizer.imageshack.us/v2/xq90/661/V6oUeJ.png[/img][/URL]
[URL=https://imageshack.com/i/eyxmkdanp][IMG]http://imagizer.imageshack.us/v2/xq90/538/xmkdan.png[/img][/URL]
[URL=https://imageshack.com/i/ipKqbTzDp][IMG]http://imagizer.imageshack.us/v2/xq90/673/KqbTzD.png[/img][/URL]
-
What is DN (called nr) 66001? According to your configuration and logs, it seems that this number does not exists within Genesys env.
-
I had added access number "6" to call the avayaswitch, so to call DN 6001 adding 6 to it :66001
-
Try removing that access code (leave it blank), and check that you have the prefix 6 configured on the Trunk SIP_to_Avaya. Show us the Annex tab of that Trunk configuration.
-
[URL=https://imageshack.com/i/pb6fAYvpp][IMG]http://imagizer.imageshack.us/v2/640x480q90/911/6fAYvp.png[/img][/URL]
How do i add prefix ?
-
Prefix option. Check sip server guide on how to create trunks....
Enviado de meu C6602 usando Tapatalk
-
Hi Cavagnaro ,
the sip server deployment guide does not give a proper step by step instruction on how to create trunk and add prefix to it. (Maybe I have not been able to find the correct info)
I only need to make a direct call from one extension DN to the other extension DN on different sip servers. I have added ISCC to both end . added trunk on both end and added prefix with '0' in one and '1' in the other .
Is this how it is to be configured. When I try to make call to other extension DN it gives the following error in logs :
16:07:28.947: Number:[18001] is not internal, looking for service
16:07:28.947: GetTheBestNode: no eligible service found for 18001
16:07:28.947: Number:18001 prefix:1 gateway list not empty, but none can be selected now
16:07:28.947: Unable to resolve number for DN:18001
16:07:28.947: SIPDM: failed to get registration info for 18001
16:07:28.947: SIPDM: failed to get registration info for 18001
16:07:28.947: Call connect failed with error WRONG_NUMBER, no DialPlan script condition - rejecting call.
-
Change the contact value to be sip:10:191.45.71:10003 (assuming 10003 is the listening port for your Avaya TServer, and this is the correct IP for that host/NIC).
You have specified the external routing point in your current value, which is not correct. ISCC will make use of ERP as part of it's process as needed without you needing to specify those.
Add in a new option called prefix but make the prefix value 6 (that is what your Avaya DNs start with).
-
Sorry that should be sip:10.191.45.71:10003
Sent from my SM-N9005 using Tapatalk
-
Hi everyone,
Thanks for the help . Got it going at last . :)
-
Hi,
I am not sure whether i am posting under the right topic or i need to create a new topic.
From what i have read in this topic, the issue which i am facing seems to be similar.
I have a Geneys SIP server and Avaya Session Manager. I had created one trunk for both incoming [b]from Avaya SM to Genesys SIPS[/b] and [b]outgoing to Avaya SM from SIP server.[/b] However, my issue is that when i try to dial from Genesys Workspace to Avaya, i get an error "Invalid Called DN-Media Error(71)-voice (1000@SIP_Switch)"
The trunk has been configured with the following options where 192.168.10.144 is the IP address of the Session Manager.
[TServer]
contact = sip:192.168.10.144:5060
oos-check = 30
oos-force = 10
oosp-transfer-enabled = true
prefix = 9
refer-enabled = false
replace-prefix =
When checking the SIP logs i can find that the Trunk is going Out of Service. OOS Forced.
[b]Below is the excerpt from the SIP logs[/b]
-----------------------------------------------------------------------------
10:19:44.138: GSProxyRegistrar:ActiveTransport In Service for dn 'msml-dn' '192.168.10.193:5060:1'
10:19:44.138: $-NET:SIP::0:79
-AP[4]-<-552 @10:19:44.4350
-Ap[4]->-552 @10:19:44.4350
10:19:46.638: Sending [0,UDP] 398 bytes to 192.168.10.144:5060 >>>>>
OPTIONS sip:JCCI_Trunk@192.168.10.144:5060 SIP/2.0
From: <sip:JCCI_Trunk@192.168.10.191:5060>;tag=B617F1C8-22E3-484B-A8F7-B6384DB9F0DF-7
To: <sip:JCCI_Trunk@192.168.10.191:5060>
Call-ID: 4AE3A5FC-D235-45DE-A305-1B891E4A770B-7@192.168.10.191
CSeq: 1456730379 OPTIONS
Content-Length: 0
Via: SIP/2.0/UDP 192.168.10.191:5060;branch=z9hG4bK3C0C5CD6-78F9-4148-A1ED-CF11655D61BE
Max-Forwards: 0
10:19:49.138: TRANSPCHK[JCCI_Trunk:192.168.10.144:5060]:OOS FORCED
10:19:49.138: TRANSPCHK[JCCI_Trunk:192.168.10.144:5060]:DETECTED OUT OF SERVICE
10:19:49.138: GSProxyRegistrar:ActiveTransport Out Of Service for dn 'JCCI_Trunk' '192.168.10.144:5060:1'
10:19:49.138: SetDnInService: DN JCCI_Trunk Out of Service
@10:19:49.1380 [0] 8.1.101.91 distribute_event: message EventDNOutOfService
AttributeEventSequenceNumber 00000000000001b8
AttributeTimeinuSecs 138000
AttributeTimeinSecs 1456730389 (10:19:49)
AttributeThisDN 'JCCI_Trunk'
2016-02-29T10:19:49.138 Trc 04542 EventDNOutOfService sent to [636] (00000004 ICON 192.168.10.191:62582)
2016-02-29T10:19:49.138 Trc 04542 EventDNOutOfService sent to [660] (00000005 ORS 192.168.10.191:62583)
10:19:49.138: GSDNChecker: JCCI_Trunk OutOfService due to a communication failure (ACTIVE CHECK)
2016-02-29T10:19:49.138 Std 52000 Device 'JCCI_Trunk' is out of service.
10:19:49.138: GSDNChecker:[JCCI_Trunk]:DETECTED OUT OF SERVICE
10:19:49.138: Sending [0,UDP] 391 bytes to 192.168.10.193:5060 >>>>>
OPTIONS sip:msml-dn@192.168.10.193:5060 SIP/2.0
From: <sip:msml-dn@192.168.10.191:5060>;tag=B617F1C8-22E3-484B-A8F7-B6384DB9F0DF-10
To: <sip:msml-dn@192.168.10.191:5060>
Call-ID: 4AE3A5FC-D235-45DE-A305-1B891E4A770B-10@192.168.10.191
CSeq: 1456730389 OPTIONS
Content-Length: 0
Via: SIP/2.0/UDP 192.168.10.191:5060;branch=z9hG4bK55937962-C139-4D42-9695-8D34C9C251D7
Max-Forwards: 0
10:19:49.138: $+NET:SIP::0:0
10:19:49.138: SIPTR: Received [0,UDP] 382 bytes from 192.168.10.193:5060 <<<<<
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.10.191:5060;branch=z9hG4bK55937962-C139-4D42-9695-8D34C9C251D7
From: <sip:msml-dn@192.168.10.191:5060>;tag=B617F1C8-22E3-484B-A8F7-B6384DB9F0DF-10
To: <sip:msml-dn@192.168.10.191:5060>;tag=5A54F106-4338-45AE-70B2-1ABE8E1175CB
CSeq: 1456730389 OPTIONS
Call-ID: 4AE3A5FC-D235-45DE-A305-1B891E4A770B-10@192.168.10.191
Content-Length: 0
10:19:49.138: GSProxyRegistrar:ActiveTransport In Service for dn 'msml-dn' '192.168.10.193:5060:1'
10:19:49.138: $-NET:SIP::0:83
-AP[5]-<-664 @10:19:49.4350
-Ap[5]->-664 @10:19:49.4350
-AP[5]-<-668 @10:19:49.6380
-Ap[5]->-668 @10:19:49.6380
-AP[5]-<-672 @10:19:50.4660
-Ap[5]->-672 @10:19:50.4660
-AP[6]->-484 @10:19:51.0130
-Ap[6]-<-484 @10:19:51.0130
-AP[5]-<-552 @10:19:51.4510
-Ap[5]->-552 @10:19:51.4510
10:19:54.138: Sending [0,UDP] 391 bytes to 192.168.10.193:5060 >>>>>
OPTIONS sip:msml-dn@192.168.10.193:5060 SIP/2.0
From: <sip:msml-dn@192.168.10.191:5060>;tag=B617F1C8-22E3-484B-A8F7-B6384DB9F0DF-11
To: <sip:msml-dn@192.168.10.191:5060>
Call-ID: 4AE3A5FC-D235-45DE-A305-1B891E4A770B-11@192.168.10.191
CSeq: 1456730394 OPTIONS
Content-Length: 0
Via: SIP/2.0/UDP 192.168.10.191:5060;branch=z9hG4bKF92A3D40-7489-40F5-8F1A-5B7F45A89865
Max-Forwards: 0
10:19:54.138: $+NET:SIP::0:0
10:19:54.138: SIPTR: Received [0,UDP] 382 bytes from 192.168.10.193:5060 <<<<<
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.10.191:5060;branch=z9hG4bKF92A3D40-7489-40F5-8F1A-5B7F45A89865
From: <sip:msml-dn@192.168.10.191:5060>;tag=B617F1C8-22E3-484B-A8F7-B6384DB9F0DF-11
To: <sip:msml-dn@192.168.10.191:5060>;tag=9939FCC3-8A57-4F54-B29C-31A69516BFDD
CSeq: 1456730394 OPTIONS
Call-ID: 4AE3A5FC-D235-45DE-A305-1B891E4A770B-11@192.168.10.191
Content-Length: 0
10:19:54.138: GSProxyRegistrar:ActiveTransport In Service for dn 'msml-dn' '192.168.10.193:5060:1'
10:19:54.138: $-NET:SIP::0:81
-AP[1]->-636 @10:19:54.4040
-AP[1]->-660 @10:19:54.4040
-Ap[1]-<-636 @10:19:54.4040
-Ap[1]-<-660 @10:19:54.4040
-AP[6]-<-664 @10:19:56.4350
-Ap[6]->-664 @10:19:56.4350
-AP[6]-<-668 @10:19:56.6540
-Ap[6]->-668 @10:19:56.6540
-AP[6]-<-672 @10:19:57.4660
-Ap[6]->-672 @10:19:57.4660
-AP[7]->-484 @10:19:58.0130
-Ap[7]-<-484 @10:19:58.0130
-AP[6]-<-552 @10:19:58.4660
-Ap[6]->-552 @10:19:58.4660
10:19:59.138: Sending [0,UDP] 391 bytes to 192.168.10.193:5060 >>>>>
OPTIONS sip:msml-dn@192.168.10.193:5060 SIP/2.0
From: <sip:msml-dn@192.168.10.191:5060>;tag=B617F1C8-22E3-484B-A8F7-B6384DB9F0DF-12
To: <sip:msml-dn@192.168.10.191:5060>
Call-ID: 4AE3A5FC-D235-45DE-A305-1B891E4A770B-12@192.168.10.191
CSeq: 1456730399 OPTIONS
Content-Length: 0
Via: SIP/2.0/UDP 192.168.10.191:5060;branch=z9hG4bK118F9DB3-90DF-4E12-8D15-CF8DCF931BFA
Max-Forwards: 0
10:19:59.138: $+NET:SIP::0:0
10:19:59.138: SIPTR: Received [0,UDP] 382 bytes from 192.168.10.193:5060 <<<<<
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.10.191:5060;branch=z9hG4bK118F9DB3-90DF-4E12-8D15-CF8DCF931BFA
From: <sip:msml-dn@192.168.10.191:5060>;tag=B617F1C8-22E3-484B-A8F7-B6384DB9F0DF-12
To: <sip:msml-dn@192.168.10.191:5060>;tag=A303F26C-CACF-4FB4-C8AB-51C8CDCC3D06
CSeq: 1456730399 OPTIONS
Call-ID: 4AE3A5FC-D235-45DE-A305-1B891E4A770B-12@192.168.10.191
Content-Length: 0
10:19:59.138: GSProxyRegistrar:ActiveTransport In Service for dn 'msml-dn' '192.168.10.193:5060:1'
10:19:59.138: $-NET:SIP::0:86
-AP[5]-<-660 @10:20:01.4040
-Ap[5]->-660 @10:20:01.4040
-AP[5]-<-636 @10:20:01.4040
-Ap[5]->-636 @10:20:01.4040
-AP[7]-<-664 @10:20:03.4350
-Ap[7]->-664 @10:20:03.4350
-AP[7]-<-668 @10:20:03.6700
-Ap[7]->-668 @10:20:03.6700
10:20:04.138: Sending [0,UDP] 391 bytes to 192.168.10.193:5060 >>>>>
OPTIONS sip:msml-dn@192.168.10.193:5060 SIP/2.0
From: <sip:msml-dn@192.168.10.191:5060>;tag=B617F1C8-22E3-484B-A8F7-B6384DB9F0DF-13
To: <sip:msml-dn@192.168.10.191:5060>
Call-ID: 4AE3A5FC-D235-45DE-A305-1B891E4A770B-13@192.168.10.191
CSeq: 1456730404 OPTIONS
Content-Length: 0
Via: SIP/2.0/UDP 192.168.10.191:5060;branch=z9hG4bKFE2ADAB1-26C5-4AD5-8A31-00201D17CF77
Max-Forwards: 0
10:20:04.138: $+NET:SIP::0:0
10:20:04.138: SIPTR: Received [0,UDP] 382 bytes from 192.168.10.193:5060 <<<<<
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.10.191:5060;branch=z9hG4bKFE2ADAB1-26C5-4AD5-8A31-00201D17CF77
From: <sip:msml-dn@192.168.10.191:5060>;tag=B617F1C8-22E3-484B-A8F7-B6384DB9F0DF-13
To: <sip:msml-dn@192.168.10.191:5060>;tag=A0AF611F-0B3F-4B1D-B2BC-487C1C7806FE
CSeq: 1456730404 OPTIONS
Call-ID: 4AE3A5FC-D235-45DE-A305-1B891E4A770B-13@192.168.10.191
Content-Length: 0
10:20:04.138: GSProxyRegistrar:ActiveTransport In Service for dn 'msml-dn' '192.168.10.193:5060:1'
10:20:04.138: $-NET:SIP::0:78
-AP[7]-<-672 @10:20:04.4670
-Ap[7]->-672 @10:20:04.4670
-AP[8]->-484 @10:20:05.0130
-Ap[8]-<-484 @10:20:05.0130
-AP[7]-<-552 @10:20:05.4980
-Ap[7]->-552 @10:20:05.4980
-AP[6]-<-660 @10:20:08.4040
-Ap[6]->-660 @10:20:08.4040
-AP[6]-<-636 @10:20:08.4040
-Ap[6]->-636 @10:20:08.4040
GLM_CO(tserver_sdn:switch_101,0,2)=4
10:20:09.138: Sending [0,UDP] 391 bytes to 192.168.10.193:5060 >>>>>
OPTIONS sip:msml-dn@192.168.10.193:5060 SIP/2.0
From: <sip:msml-dn@192.168.10.191:5060>;tag=B617F1C8-22E3-484B-A8F7-B6384DB9F0DF-14
To: <sip:msml-dn@192.168.10.191:5060>
Call-ID: 4AE3A5FC-D235-45DE-A305-1B891E4A770B-14@192.168.10.191
CSeq: 1456730409 OPTIONS
Content-Length: 0
Via: SIP/2.0/UDP 192.168.10.191:5060;branch=z9hG4bKF9BD3E73-52B5-4FD1-A5BE-6F0B2D6B99DE
Max-Forwards: 0
10:20:09.138: $+NET:SIP::0:0
10:20:09.138: SIPTR: Received [0,UDP] 382 bytes from 192.168.10.193:5060 <<<<<
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.10.191:5060;branch=z9hG4bKF9BD3E73-52B5-4FD1-A5BE-6F0B2D6B99DE
From: <sip:msml-dn@192.168.10.191:5060>;tag=B617F1C8-22E3-484B-A8F7-B6384DB9F0DF-14
To: <sip:msml-dn@192.168.10.191:5060>;tag=4AFB6A69-6157-45EB-6EA9-4A110CDB85EB
CSeq: 1456730409 OPTIONS
Call-ID: 4AE3A5FC-D235-45DE-A305-1B891E4A770B-14@192.168.10.191
Content-Length: 0
10:20:09.138: GSProxyRegistrar:ActiveTransport In Service for dn 'msml-dn' '192.168.10.193:5060:1'
10:20:09.138: $-NET:SIP::0:85
GLM_EV(op=1,res=0,ud=1)
2016-02-29T10:20:10.045 Std 07101 Feature 'tserver_sdn': 10 licenses checked out
LICENSE: seat=10
-AP[8]-<-664 @10:20:10.4350
-Ap[8]->-664 @10:20:10.4350
-AP[8]-<-668 @10:20:10.6850
-Ap[8]->-668 @10:20:10.6850
-AP[8]-<-672 @10:20:11.4820
-Ap[8]->-672 @10:20:11.4820
-AP[9]->-484 @10:20:12.0130
-Ap[9]-<-484 @10:20:12.0130
-AP[8]-<-552 @10:20:12.4980
-Ap[8]->-552 @10:20:12.4980
10:20:14.138: Sending [0,UDP] 391 bytes to 192.168.10.193:5060 >>>>>
OPTIONS sip:msml-dn@192.168.10.193:5060 SIP/2.0
From: <sip:msml-dn@192.168.10.191:5060>;tag=B617F1C8-22E3-484B-A8F7-B6384DB9F0DF-15
To: <sip:msml-dn@192.168.10.191:5060>
Call-ID: 4AE3A5FC-D235-45DE-A305-1B891E4A770B-15@192.168.10.191
CSeq: 1456730414 OPTIONS
Content-Length: 0
Via: SIP/2.0/UDP 192.168.10.191:5060;branch=z9hG4bK71C16E56-3478-4FFD-BEFC-C5BDF1844BDC
Max-Forwards: 0
10:20:14.138: $+NET:SIP::0:0
10:20:14.138: SIPTR: Received [0,UDP] 382 bytes from 192.168.10.193:5060 <<<<<
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.10.191:5060;branch=z9hG4bK71C16E56-3478-4FFD-BEFC-C5BDF1844BDC
From: <sip:msml-dn@192.168.10.191:5060>;tag=B617F1C8-22E3-484B-A8F7-B6384DB9F0DF-15
To: <sip:msml-dn@192.168.10.191:5060>;tag=E92AC570-468A-4A64-0EB6-588DFA13B152
CSeq: 1456730414 OPTIONS
Call-ID: 4AE3A5FC-D235-45DE-A305-1B891E4A770B-15@192.168.10.191
Content-Length: 0
10:20:14.138: GSProxyRegistrar:ActiveTransport In Service for dn 'msml-dn' '192.168.10.193:5060:1'
10:20:14.138: $-NET:SIP::0:81
-AP[7]-<-636 @10:20:15.4040
-Ap[7]->-636 @10:20:15.4040
-AP[7]-<-660 @10:20:15.4200
-Ap[7]->-660 @10:20:15.4200
-AP[9]-<-664 @10:20:17.4350
-Ap[9]->-664 @10:20:17.4350
-AP[9]-<-668 @10:20:17.7010
-Ap[9]->-668 @10:20:17.7010
-AP[9]-<-672 @10:20:18.4820
-Ap[9]->-672 @10:20:18.4820
-AP[10]->-484 @10:20:19.0130
-Ap[10]-<-484 @10:20:19.0130
10:20:19.138: Sending [0,UDP] 400 bytes to 192.168.10.144:5060 >>>>>
OPTIONS sip:JCCI_Trunk@192.168.10.144:5060 SIP/2.0
From: <sip:JCCI_Trunk@192.168.10.191:5060>;tag=B617F1C8-22E3-484B-A8F7-B6384DB9F0DF-16
To: <sip:JCCI_Trunk@192.168.10.191:5060>
Call-ID: 4AE3A5FC-D235-45DE-A305-1B891E4A770B-16@192.168.10.191
CSeq: 1456730419 OPTIONS
Content-Length: 0
Via: SIP/2.0/UDP 192.168.10.191:5060;branch=z9hG4bK94A6F91B-555F-42D4-8838-179C63F71C44
Max-Forwards: 0
10:20:19.154: Sending [0,UDP] 391 bytes to 192.168.10.193:5060 >>>>>
OPTIONS sip:msml-dn@192.168.10.193:5060 SIP/2.0
From: <sip:msml-dn@192.168.10.191:5060>;tag=B617F1C8-22E3-484B-A8F7-B6384DB9F0DF-17
To: <sip:msml-dn@192.168.10.191:5060>
Call-ID: 4AE3A5FC-D235-45DE-A305-1B891E4A770B-17@192.168.10.191
CSeq: 1456730419 OPTIONS
Content-Length: 0
Via: SIP/2.0/UDP 192.168.10.191:5060;branch=z9hG4bKFBA738E3-C850-4378-B0C4-4FACFE1040EA
Max-Forwards: 0
10:20:19.154: $+NET:SIP::0:0
10:20:19.154: SIPTR: Received [0,UDP] 382 bytes from 192.168.10.193:5060 <<<<<
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.10.191:5060;branch=z9hG4bKFBA738E3-C850-4378-B0C4-4FACFE1040EA
From: <sip:msml-dn@192.168.10.191:5060>;tag=B617F1C8-22E3-484B-A8F7-B6384DB9F0DF-17
To: <sip:msml-dn@192.168.10.191:5060>;tag=E0D47F31-AD8C-4786-20BC-0C927C19F3CB
CSeq: 1456730419 OPTIONS
Call-ID: 4AE3A5FC-D235-45DE-A305-1B891E4A770B-17@192.168.10.191
Content-Length: 0
10:20:19.154: GSProxyRegistrar:ActiveTransport In Service for dn 'msml-dn' '192.168.10.193:5060:1'
10:20:19.154: $-NET:SIP::0:86
-AP[9]-<-552 @10:20:19.5140
-Ap[9]->-552 @10:20:19.5140
10:20:19.639: Sending [0,UDP] 400 bytes to 192.168.10.144:5060 >>>>>
OPTIONS sip:JCCI_Trunk@192.168.10.144:5060 SIP/2.0
From: <sip:JCCI_Trunk@192.168.10.191:5060>;tag=B617F1C8-22E3-484B-A8F7-B6384DB9F0DF-16
To: <sip:JCCI_Trunk@192.168.10.191:5060>
Call-ID: 4AE3A5FC-D235-45DE-A305-1B891E4A770B-16@192.168.10.191
CSeq: 1456730419 OPTIONS
Content-Length: 0
Via: SIP/2.0/UDP 192.168.10.191:5060;branch=z9hG4bK94A6F91B-555F-42D4-8838-179C63F71C44
Max-Forwards: 0
10:20:20.639: Sending [0,UDP] 400 bytes to 192.168.10.144:5060 >>>>>
OPTIONS sip:JCCI_Trunk@192.168.10.144:5060 SIP/2.0
From: <sip:JCCI_Trunk@192.168.10.191:5060>;tag=B617F1C8-22E3-484B-A8F7-B6384DB9F0DF-16
To: <sip:JCCI_Trunk@192.168.10.191:5060>
Call-ID: 4AE3A5FC-D235-45DE-A305-1B891E4A770B-16@192.168.10.191
CSeq: 1456730419 OPTIONS
Content-Length: 0
Via: SIP/2.0/UDP 192.168.10.191:5060;branch=z9hG4bK94A6F91B-555F-42D4-8838-179C63F71C44
Max-Forwards: 0
-AP[8]-<-636 @10:20:22.4040
-Ap[8]->-636 @10:20:22.4040
-AP[8]-<-660 @10:20:22.4350
-Ap[8]->-660 @10:20:22.4350
10:20:22.639: Sending [0,UDP] 400 bytes to 192.168.10.144:5060 >>>>>
OPTIONS sip:JCCI_Trunk@192.168.10.144:5060 SIP/2.0
From: <sip:JCCI_Trunk@192.168.10.191:5060>;tag=B617F1C8-22E3-484B-A8F7-B6384DB9F0DF-16
To: <sip:JCCI_Trunk@192.168.10.191:5060>
Call-ID: 4AE3A5FC-D235-45DE-A305-1B891E4A770B-16@192.168.10.191
CSeq: 1456730419 OPTIONS
Content-Length: 0
Via: SIP/2.0/UDP 192.168.10.191:5060;branch=z9hG4bK94A6F91B-555F-42D4-8838-179C63F71C44
Max-Forwards: 0
10:20:24.154: Sending [0,UDP] 391 bytes to 192.168.10.193:5060 >>>>>
OPTIONS sip:msml-dn@192.168.10.193:5060 SIP/2.0
From: <sip:msml-dn@192.168.10.191:5060>;tag=B617F1C8-22E3-484B-A8F7-B6384DB9F0DF-18
To: <sip:msml-dn@192.168.10.191:5060>
Call-ID: 4AE3A5FC-D235-45DE-A305-1B891E4A770B-18@192.168.10.191
CSeq: 1456730424 OPTIONS
Content-Length: 0
Via: SIP/2.0/UDP 192.168.10.191:5060;branch=z9hG4bK80AF9D51-2CB8-4608-821C-944E046BFA27
Max-Forwards: 0
10:20:24.154: $+NET:SIP::0:0
10:20:24.154: SIPTR: Received [0,UDP] 382 bytes from 192.168.10.193:5060 <<<<<
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.10.191:5060;branch=z9hG4bK80AF9D51-2CB8-4608-821C-944E046BFA27
From: <sip:msml-dn@192.168.10.191:5060>;tag=B617F1C8-22E3-484B-A8F7-B6384DB9F0DF-18
To: <sip:msml-dn@192.168.10.191:5060>;tag=0DD04A20-3CAE-4352-2F9D-6F2F1DFB44C9
CSeq: 1456730424 OPTIONS
Call-ID: 4AE3A5FC-D235-45DE-A305-1B891E4A770B-18@192.168.10.191
Content-Length: 0
-----------------------------------------------------------------------------------
[b]When try to make a call to an extension 7050 with prefix 9[/b]
2016-02-29T10:28:30.339 Trc 04541 RequestMakeCall received from [676] (00000009 Workspace_Agent1 192.168.10.192:55529)
message RequestMakeCall
AttributeReferenceID 6
AttributeThisDN '1000'
AttributeUserData [106] 00 02 00 00..
'IW_CaseUid' '58b2871f-c9fb-4e7f-bf43-1715d5f75681'
'IW_BundleUid' 'f64984eb-8b0c-4d2d-9334-c1f68945e76e'
AttributeLocation ''
AttributeOtherDN '97050'
AttributeMakeCallType 0 (MakeCallRegular)
2016-02-29T10:28:30.339 Int 04543 Interaction message "RequestMakeCall" received from 676 ("Workspace_Agent1")
@10:28:30.3390 [ISCC] destination_location substituted by local
@10:28:30.3390 [ISCC] destination_location substituted by local
2016-02-29T10:28:30.339 -- created: CRequest@31b6b60 RequestMakeCall-Workspace_Agent1[676]/6
10:28:30.339: $+TLIB:CTI:Unknown:0:31859173
2016-02-29T10:28:30.339 +++ CIFace::Request +++
-- new invoke
Parsed: RequestMakeCall
From: Workspace_Agent1[676]/6
Numbers: +<1000> -<97050>
Status: parsed:1 queued:0 sent:0 acked:0 preevent:0 event:0 context:0 transferred:0
-----
-- validate
-- state check: ok
CIFace: Sent CRequest@31b6b60 RequestMakeCall-Workspace_Agent1[676]/6
FinishRequest CRequest@31b6b60 RequestMakeCall-Workspace_Agent1[676]/6
IFace stats: q=0 s=0
-- complete
10:28:30.339: ResolveCallInfo: set flag DIAL_PLAN_PROCESSING
10:28:30.339: SIPTR(0): Begin step 0 - SipTransactionResolveCallInfoByDialPlan(1)
10:28:30.339: DialPlan: No dialplan defined for 1000.
10:28:30.339: GetRegistration::Unable to resolve number for DN:97050
10:28:30.339: DialPlan: No rule applied, using original destination '97050'.
10:28:30.339: DialPlan: clear flag DIAL_PLAN_PROCESSING
10:28:30.339: Number:[97050] is not internal, looking for service
10:28:30.339: GetTheBestNode:: server list for 97050 exists, but has no validated entries
10:28:30.339: Number:97050 prefix:9 gateway list not empty, but none can be selected now
10:28:30.339: Unable to resolve number for DN:97050
10:28:30.339: SIPDM: failed to get registration info for 97050
10:28:30.339: SIPDM: failed to get registration info for 97050
10:28:30.339: Call connect failed with error WRONG_NUMBER, no DialPlan script condition - rejecting call.
10:28:30.339: ERROR: 10000029, DialPlanHandleConnect(scenario, trData,result,*instruction), SipCallManagerDialPlan.cpp,2376
10:28:30.339: SIPTR(1): failed
10:28:30.339: SIPTR(0): Step 0 - SipTransactionResolveCallInfoByDialPlan(1) failed
10:28:30.339: SIPTR(0): failed
10:28:30.339: SIPCM: transaction SipScenario failed
10:28:30.339: CALLSTATE: empty, delete the call 16777217
10:28:30.339: SipCallManager::OnTransactionFailure: Internal context, doesn't notify10:28:30.339: OnRequestFailed
2016-02-29T10:28:30.339 Trc 36002 Request rejected: error code 71(Invalid Called Dn)
@10:28:30.3390 [0] 8.1.101.91 send_to_client: message EventError
(Invalid Called Dn)
AttributeEventSequenceNumber 00000000000001c5
AttributeTimeinuSecs 339000
AttributeTimeinSecs 1456730910 (10:28:30)
AttributeErrorCode 71
AttributeErrorMessage 'Invalid Called Dn'
AttributeMakeCallType 0 (MakeCallRegular)
AttributeOtherDN '97050'
AttributeLocation ''
AttributeUserData [106] 00 02 00 00..
'IW_CaseUid' '58b2871f-c9fb-4e7f-bf43-1715d5f75681'
'IW_BundleUid' 'f64984eb-8b0c-4d2d-9334-c1f68945e76e'
AttributeThisDN '1000'
AttributeReferenceID 6
AttributeClientID 9
2016-02-29T10:28:30.339 Int 04545 Interaction message "EventError" sent to 676 ("Workspace_Agent1")
2016-02-29T10:28:30.339 Trc 04542 EventError sent to [676] (00000009 Workspace_Agent1 192.168.10.192:55529)
10:28:30.339: call1 16777217 idle
2016-02-29T10:28:30.339 --- CIFace::Request ---
2016-02-29T10:28:30.339 -- deleted: CRequest@31b6b60 RequestMakeCall-Workspace_Agent1[676]/6
10:28:30.339: $-TLIB:CTI:Unknown:0:2409
10:28:34.277: Sending [0,UDP] 393 bytes to 192.168.10.193:5060 >>>>>
OPTIONS sip:msml-dn@192.168.10.193:5060 SIP/2.0
From: <sip:msml-dn@192.168.10.191:5060>;tag=B617F1C8-22E3-484B-A8F7-B6384DB9F0DF-130
To: <sip:msml-dn@192.168.10.191:5060>
Call-ID: 4AE3A5FC-D235-45DE-A305-1B891E4A770B-128@192.168.10.191
CSeq: 1456730914 OPTIONS
Content-Length: 0
Via: SIP/2.0/UDP 192.168.10.191:5060;branch=z9hG4bK8931E6A1-266B-4534-85AD-6777DCA66115
Max-Forwards: 0
Appreciate if anyone can help me out on what am i missing.
Thank You
Best Regards
-
You seem to have incorrectly configured your dial plan, see here:
***
10:28:30.339: Number:97050 prefix:9 gateway list not empty, but none can be selected now
10:28:30.339: Unable to resolve number for DN:97050
10:28:30.339: SIPDM: failed to get registration info for 97050
10:28:30.339: SIPDM: failed to get registration info for 97050
10:28:30.339: Call connect failed with error WRONG_NUMBER, no DialPlan script condition - rejecting call.
***
Fra
-
Hi Fra,
Thanks for the response.
I haven't created a dial plan at the Genesys end for routing the call from Genesys->Avaya SM->Avaya CM. But there is a dial plan in SM to route it to the CM extension.
I have configured a trunk in Genesys and i am expecting Genesys to use this trunk when dialed from Workspace using this prefix 9.
From the wireshark traces running on SIP server, i can see that SIP OPTION messages are sent to the Avaya Session Manager. However, the SM did not receive it. And after the OOS timeout for not receiving the SIP 200 OK, it forces the trunk to go OUT OF SERVICE. I believe this is why, the call is not going out from the trunk.
Correct me if i am wrong.
Thank You
Best Regards
-
I saw that too. Check your network, maybe a firewall is blocking some traffic.
Check on Avaya sip logs if it receives the Info messages.
-
You have to fixed that:
[quote]From the wireshark traces running on SIP server, i can see that SIP OPTION messages are sent to the Avaya Session Manager. However, the SM did not receive it. And after the OOS timeout for not receiving the SIP 200 OK, it forces the trunk to go OUT OF SERVICE. I believe this is why, the call is not going out from the trunk.[/quote]
-
Hi Kubig/Cavagnaro,
Thanks for the response
As per the client, there is no firewall between the Genesys SIPS and Avaya SM.
This option messages are not reaching at all to the Avaya SM from the Genesys SIPS. However, the OPTION messages from Avaya SM is reaching Genesys SIPS and responding back with 200 OK.
Since the customer is sticking that there is no firewall between the two. The questions which are running over the head is
1) Why is the OPTION messages not reaching Avaya SM? But from SM to Genesys SIPS it reaches.
2) If i remove the [b]oos-check[/b] and [b]oos-force[/b] from the Trunk configuration options. Then SIPS sends the INVITE message, but even the INVITE message is not reaching Avaya SM.
What can be the other reasons why the OPTION messages or the INVITE messages are not reaching the Avaya SM?
Thank You
Best Regards
-
[list type=decimal]
[li]Network[/li]
[li]Firewall[/li]
[li]Operating System[/li]
[/list]
-
Hi Kubig,
For sure, its not Genesys end?
Anything to do with [b]Request-URI, or SIP headers etc[/b].. I am least knowledgeable on SIP related things. Spare me if am asking something lame.
For Genesys to connect to Avaya CM using Avaya Session Manager, we just have to create a Trunk DN at the Genesys end with the options which i have mentioned? And a dial plan at the Avaya SM right?
Thank You
Best Regards
Rashid
-
Did you configure the "request-uri" on trunk DN related to the AvayaSM? If yes, what is the current configuration and why this options was configured?
-
See SIP logs, to where are these packets being sent? Something must be wrong on your configuration or network.
Conf: bad ip, bad port
Net: something blocking traffic. as per ISO layers you know that software doesn't handle transport, what does it? Yeah...physical layer, meaning? LAN. So check your LAN. Only way software can affect if by a firewall or a bad network configuration like a bad gateway.
Can you telnet Avaya SIP port from Genesys server?
-
Does the host where the sip server resides has a route to the avaya sm subnet, on the signaling network card?
-
[quote author=Kubig link=topic=9043.msg42439#msg42439 date=1456751784]
Did you configure the "request-uri" on trunk DN related to the AvayaSM? If yes, what is the current configuration and why this options was configured?
[/quote]
Hi Kubig,
No i haven't configured "request-uri" on trunk DN. The trunk DN configuration is as below
[TServer]
contact = sip:192.168.10.144:5060
oosp-transfer-enabled = true
prefix = 9
refer-enabled = false
replace-prefix =
As per the Avaya SM engineer, they use a Domain name. But how do we configure that domain name in the Genesys trunk DN?
[quote author=cavagnaro link=topic=9043.msg42441#msg42441 date=1456756432]
See SIP logs, to where are these packets being sent? Something must be wrong on your configuration or network.
Conf: bad ip, bad port
Net: something blocking traffic. as per ISO layers you know that software doesn't handle transport, what does it? Yeah...physical layer, meaning? LAN. So check your LAN. Only way software can affect if by a firewall or a bad network configuration like a bad gateway.
Can you telnet Avaya SIP port from Genesys server?
[/quote]
Hi Cavagnaro,
The SIP request is as follows INVITE sip:7050@192.168.10.144:5060.
Here 7050 is the DN in the Avaya CM which i am trying to dial from Genesys and 192.168.10.144 is the Avaya SM which is configured in the trunk as mentioned above.
Both Genesys server and the Avaya SM are on the same subnet and as per the client, there is no firewall between these. However, i shall double check and verify with the network team again.
Yes i am able to telnet Avaya SIP port 5060 from the Genesys SIP server.
[quote author=hsujdik link=topic=9043.msg42443#msg42443 date=1456762260]
Does the host where the sip server resides has a route to the avaya sm subnet, on the signaling network card?
[/quote]
Hi,
Yes both of them are on the same subnet.
Thank You
Best Regards
-
Wait, number is 7050 and prefix is 9???? Create another trunk with prefix 7
-
Hi Cavagnaro,
Prefix 9 is set on the trunk and i have also set the option [b]replace-prefix[/b] to remove it while passing out of Genesys. That is why when i dial 97050 from the Genesys workspace, the INVITE message is only passing 7050.
Correct me if i am wrong. And also, i have Genesys routing points starting with 7, so is it good to create a trunk with prefix 7?
Thank You
Best Regards
-
??? Replace by no value? Guys help here, never did such thing.
And first rule of interconnectivity, never overlap dialing plans. You can't have 7XXX objects on both sides. If you do somehow you will have to assign a range. like 7[0-4] for Avaya and 7[5-9] for SIP Server...still ranges end up being very short unless you increment the 4 digit range.
For me that is the problem.
-
Replace by no value works fine usually (at least I have used it a lot without problems). But still, if he cant see the OPTION method on both sides and assuming he has oos-check and oos-force (or dont have a recovery-timeout), it might be network related or firewall related.
-
Hummm...well yeah you are right. OPTIONS will travel to the contact IP and port.
Insist on network and don't trust customer. 99% of times, network guys will tell "not my problem" and then "opps...it was my problem".
Don't doubt or ask them, demand to check with you.
-
[quote author=cavagnaro link=topic=9043.msg42460#msg42460 date=1456838857]
??? Replace by no value? Guys help here, never did such thing.
And first rule of interconnectivity, never overlap dialing plans. You can't have 7XXX objects on both sides. If you do somehow you will have to assign a range. like 7[0-4] for Avaya and 7[5-9] for SIP Server...still ranges end up being very short unless you increment the 4 digit range.
For me that is the problem.
[/quote]
Hi Cavagnaro,
Yes even we have felt that the range should have been different like you said. If Genesys has a range starting with 7xxx then Avaya should have started with something else. However, this replace-prefix option works very well for removing the prefix. So ideally, if anyone from Genesys dials out using the prefix 9 then it should go out through the trunk.
If Genesys looks internally for this DN 7050 then i guess we shall get some message like [b]"Invalid Called DN"[/b].
Yesterday in our all day troubleshooting, we were able to notice something positive. Let me explain
1) A customer when dialing through the PSTN reaches the Avaya CM through Avaya Session Manager, and is routed to Genesys Route Point. Customer then hears the treatments from the Application loaded on the Route Point. When No agents are available to transfer the call, we have given a ForceRoute Block and to route the call to 97050 which is in Avaya. And this WORKS ! ! ! :)
2) The second scenario is the one which i explained earlier also. When a agent logs into Genesys Workspace and dials 97050 out from the Genesys Workspace. The INVITE doesn't reach Avaya. :(
The only difference between the two is, in the first scenario, a SIP REFER message is sent from Genesys to Avaya. And Avaya get's this message and responds back.
However, in the second scenario, a SIP INVITE message is sent, but it does not reach Avaya.
So literally, its like Genesys is telling to Avaya that "If you talk to me, i will respond back. But don't expect me to start the talk". This is what we see from the SIP OPTION message and the INVITE message. Both of which is initiated by Genesys and it is not reaching Avaya.
Now like you said, OPTIONS should travel to the IP and port if everything is clear, but something in the OPTION message or the INVITE message is not taking it to Avaya. ???
But by the REFER message, it does reach Avaya. I have the SIP log for both these test call scenarios, and i couldn't understand the SIP messages much. ??? ???
I am actually looking a way to attach the log here, not pasting it. But attach the file. ::) How do i attach a file?
Thank You
Best Regards
-
Doesn't seems logic because even the TRoute command will need to use the trunk...
Post logs
-
Upload to a third party server and share the link only here
-
Do you have an example of incoming message from Avaya? Maybe it uses tcp as transport and thus sip server can reply over the existing connection? Just a ling shot guess though
-
[quote author=hsujdik link=topic=9043.msg42492#msg42492 date=1456925990]
Do you have an example of incoming message from Avaya? Maybe it uses tcp as transport and thus sip server can reply over the existing connection? Just a ling shot guess though
[/quote]
Hi,
BRILLIANT CATCH !!!! :) :) :) :)
That's the point. TCP was the one making us crazy.
When Genesys is sending INVITE it is in UDP, because the trunk is configured with [b]contact[/b] option [b]sip:192.168.10.144:5060[/b]
------------------When Agent Dials 97050 from Workspace------------------------
12:24:19.933: Sending [b][0,UDP][/b] 625 bytes to 192.168.9.103:5060 >>>>>
INVITE sip:1000@192.168.9.103:5060 SIP/2.0
From: <sip:7050@192.168.10.191:5060>;tag=D497B6DA-A58D-4CB6-8F08-D61C4EFC8F65-517
To: sip:1000@192.168.10.191:5060
Call-ID: DB7CADC9-73AA-4D18-8976-9D4A1F82B73F-506@192.168.10.191
CSeq: 1 INVITE
Content-Length: 0
Via: SIP/2.0/UDP 192.168.10.191:5060;branch=z9hG4bK00FE621C-C046-4E2F-8833-CA2309376ADE-119
Contact: <sip:97050@192.168.10.191:5060>
Allow: ACK, BYE, CANCEL, INFO, INVITE, MESSAGE, NOTIFY, OPTIONS, PRACK, REFER, UPDATE
Max-Forwards: 70
X-Genesys-CallUUID: SF094SFU7P2IB49IMTUL1CK9AS000008
Session-Expires: 1800;refresher=uac
Min-SE: 90
Supported: timer
--------------------------------------------------------------------------------------
However, Avaya is communicating with TCP.
--------------------When Call is transferred from Genesys Application to Avaya------------
12:25:33.901: Sending [b] [240,TCP][/b] 991 bytes to 192.168.10.144:5060 >>>>>
REFER sip:112172412@192.168.10.123:5061;transport=tls;gsid=80fe019d-bbf1-4501-a5a1-56d00d670000 SIP/2.0
From: <sip:7002@jcci.com>;tag=D497B6DA-A58D-4CB6-8F08-D61C4EFC8F65-531
To: <sip:112172412@jcci.com>;tag=80fe19dbbf1e5167a156d0d6700
Call-ID: 80fe19dbbf1e5168a156d0d6700
CSeq: 1 REFER
Content-Length: 0
Via: SIP/2.0/TCP 192.168.10.191:5060;branch=z9hG4bK00FE621C-C046-4E2F-8833-CA2309376ADE-132
Contact: <sip:192.168.10.191:5060;transport=tcp>
X-Genesys-CallInfo: routed
Refer-To: <sip:7050@192.168.10.144:5060>
Referred-By: sip:7002@jcci.com
X-Genesys-CallUUID: SF094SFU7P2IB49IMTUL1CK9AS000009
Max-Forwards: 58
Route: <sip:204fa3d5@192.168.10.144;transport=tcp;lr>
Route: <sip:192.168.10.143:15060;transport=tcp;ibmsid=local.1456049537490_375367_375630;lr;ibmdrr>
Route: <sip:192.168.10.143:15061;transport=tls;ibmsid=local.1456049537490_375367_375630;lr;ibmdrr>
Route: <sip:204fa3d5@192.168.10.144;transport=tls;lr>
Route: <sip:192.168.10.123:5061;transport=tls;lr>
-------------------------------------------------------------------
So i changed the trunk configuration by explicitly adding the transport=TCP
[b]contact=sip:192.168.10.144:5060;transport=TCP[/b]
Appreciate the support of everyone to help find this out. Especially hsujdik and cavagnaro (Sorry don't know both of your's actual name :) :) )
Thank You
Best Regards
-
Avaya -- OMG :)
Genesys SIP allows to accept SIP messages transported via both protocol - UDP/TCP. Of course, the default protocol is UDP as is designed. Great, the solution was found.
Prerequisities like these elementary default network and application configuration should be checked and filled before integrate/deploy anything to the live environment.
-
And why on earth did the TRoute worked then??? O.o
-
It is probable because when RequestRouteCall is sent to SIP Server, it would reuse the existing TCP connection when talking back to Avaya
-
??? Not buying that one buddy...That would send a new INVITE, must be something else
-
That probably would depend on the oosp-transfer-enabled option being set to true or false (and, I suppose it is set to true, because it works and because he mentioned REFER being used). So, SIP Server would reply back 302/Moved Temporarily on the same dialog instead of starting a new dialog.
-
Hummm makes sense... ;D