" /> Call fail after PlayApplication with GVP/URS - Genesys CTI User Forum

Author Topic: Call fail after PlayApplication with GVP/URS  (Read 6271 times)

Offline cavagnaro

  • Administrator
  • Hero Member
  • *****
  • Posts: 7641
  • Karma: 56330
Call fail after PlayApplication with GVP/URS
« on: December 15, 2012, 04:10:14 AM »
Advertisement
Hi guys,
So I'm doing this deployment and facing a strange issue...
I send the call to SIP Server and it executes GVP Application via PlayApplication object on IRD, so far ok. As on this scenario GVP can't transfer directly I attach a KVP and return to URS strategy so it can use a TRoute function. But this won't work...
If I route without going to GVP it does work...pretty strange as GVP already left the call...

Working SIP message:

[code]
01:51:52.595: GetRegistration::Unable to resolve number for DN:102560
01:51:52.595: Number:[102560] is not internal, looking for service
01:51:52.595: Selected for Dn 102560(geo-loc[]:partitionId[]:cpdCapability[]): Service OXE_192.168.26.94 (geo-loc[], priority[0], capacity 0 (0% of -2))
01:51:52.595: Number:[102560] is not internal, looking for service
01:51:52.595: Selected for Dn 102560(geo-loc[]:partitionId[]:cpdCapability[]): Service OXE_192.168.26.94 (geo-loc[], priority[0], capacity 0 (0% of -2))
01:51:52.595 SIPCONN(5195589070): re-invite-called-initiated
01:51:52.595: transfer oosp
01:51:52.595: SIPTR(42): Begin step 0 - SipTransactionRefer(43)
01:51:52.595 SIPCONN(5195589070): re-invite-called-initiated
01:51:52.595: GetReferTo:+OOSP[0]: >> <sip:102560@192.168.26.94:5060> >>
01:51:52.595: refer 102560[lc] to 5195589070[lc] : 1=>1=>1
01:51:52.595: Sending  [0,UDP] 459 bytes to 192.168.26.94:5060 >>>>>
SIP/2.0 302 Moved Temporarily
To: <sip:103301@172.20.80.67:5080;user=phone>;tag=5850CAE5-446E-4D46-A9BE-722107CB270A-6
From: "5195589070" <sip:5195589070@core3;user=phone>;tag=13f9c9ee09e217dadcb0117efe90d5ed
Call-ID: b91a68a256ad16cefb8f990c6d3d412a@192.168.26.94
CSeq: 1965207627 INVITE
Via: SIP/2.0/UDP 192.168.26.94;branch=z9hG4bK9d950fad2274eb172dba7d8499764c50;received=192.168.26.94
Contact: <sip:102560@192.168.26.94:5060>
Content-Length: 0


01:51:52.595: SipDialog: event CALLED_RESREJECT, t=1057, s=9, r=5, m=0499b234
01:51:52.595 SIPCONN(5195589070): HandleSipDialogEvent(CALLED_RESREJECT) - filtered
01:51:52.595: SIPTR(43): complete
01:51:52.595: SIPTR(42): Step 0 - SipTransactionRefer(43) complete
01:51:52.595: SIPTR(42): Begin step 1 - SipTransactionClearParty(44)
01:51:52.595: SIPCALL(4): add party '102560'
  -- created party_info_tspp 4995fa0
  -- created aTmParty 4973bd0
  SetRole: Destination for 102560.4973bd0-4945ea8:1
  -- AddParty to 4945ea8: 102560.4973bd0-4945ea8:1 after 103301.4973d28-4945ea8:1
  CreateParty new external: 102560.4973bd0-4945ea8:1
01:51:52.595: Call 4 dn 102560 SetPartyId 9
01:51:52.595: routing dialog '8' terminated
01:51:52.595: Adding OtherTrunkName(OXE_192.168.26.94): done
[/code]

Not working:
[code]
01:45:49.535: GetRegistration::Unable to resolve number for DN:8562
01:45:49.535: Number:[8562] is not internal, looking for service
01:45:49.535: Selected for Dn 8562(geo-loc[]:partitionId[]:cpdCapability[]): Service OXE_82_192.168.26.94 (geo-loc[], priority[0], capacity 0 (0% of -2))
01:45:49.535: Number:[8562] is not internal, looking for service
01:45:49.535: Selected for Dn 8562(geo-loc[]:partitionId[]:cpdCapability[]): Service OXE_82_192.168.26.94 (geo-loc[], priority[0], capacity 0 (0% of -2))
01:45:49.535 SIPCONN(5195589070): re-invite-connected
01:45:49.535: transfer oosp
01:45:49.535: SIPTR(31): Begin step 0 - SipTransactionRefer(32)
01:45:49.535 SIPCONN(5195589070): re-invite-connected
  -- deleted: CRequest@4283da0 RequestApplyTreatment-URS[460]/185065
01:45:49.535: GetReferTo:+OOSP[0]: >> <sip:8562@192.168.26.94:5060> >>
01:45:49.535: refer 8562[lc] to 5195589070[lc] : 1=>1=>1
01:45:49.535: add party info '5195589070' state 1.
01:45:49.535: SIPDLG[5]: register TRN[705]
01:45:56.295: WARNING: gethostbyname(core3) FALSE duration 6760 ms
01:45:56.295: SIPTR(31): step 0, initialization of SipTransactionRefer(32) failed
01:45:56.295: cannot execute scenario 31, rc=ffffffff
01:45:56.295: PI: 00 S[IN]D[5195589070]C[*D[5195589070]]P[-]
01:45:56.295: PI: 00 S[QN]D[103301]E[-]
  Response (50): for CRequest@4283e60 RequestRouteCall-URS[460]/185067
  -- thisCall by party
01:45:56.295 Trc 36002 Request rejected: error code 50(Unspecified error)
@01:45:56.2950 [0] 8.1.001.10 send_to_client: message EventError
(Unspecified error)
AttributeEventSequenceNumber 000000000000003e
AttributeTimeinuSecs 295000
AttributeTimeinSecs 1355543156 (01:45:56)
AttributeExtensions [41] 00 02 00 00..
'CUSTOMER_ID' 'Resources'
'SWITCH' 'SIP'
AttributeErrorCode 50
AttributeErrorMessage 'Unspecified error'
AttributeReferenceID 185067
AttributeReason [14] 00 01 01 00..
'RTR' 120
AttributeRouteType 6 (RouteTypeDirect)
[/code]


The big difference I see is this:
01:45:49.535 SIPCONN(5195589070): re-invite-connected (KO)

vs

01:51:52.595 SIPCONN(5195589070): re-invite-called-initiated (OK)

Trunk settings are the same
same RP tested
out of ideas...any help would be great :D

Thanks!


Offline Flávio

  • Newbie
  • *
  • Posts: 32
  • Karma: 0
Re: Call fail after PlayApplication with GVP/URS
« Reply #1 on: December 15, 2012, 12:21:08 PM »
Hi cavagnaro,

i can see from the logs that the call working is going throuth DN:102560,

after that SipServer act as proxy and move the call to have the treatment. 'SIP/2.0 302 Moved Temporarily'. so far so good.

you are calling the number 103301 correct? that message you post is from RM correct? (port 5080)

in the wrong call you are using the DN:8562

Does the DN 8562 have 'contact' ??

i'm assuming you are using the same GVP application to make those tests, you are using REFER to make the transfer but that is using 'blind', 'bridge' or 'consultation' transfer type ?

Why you want to use the TRoute instead of doing everything inside your GVP application?

there must be some difference in the call flow or in the call if you are using the same Trunk, RP and Application for your tests.

PLease let me know those answers so i can help more.

cheers,

Offline cavagnaro

  • Administrator
  • Hero Member
  • *****
  • Posts: 7641
  • Karma: 56330
Re: Call fail after PlayApplication with GVP/URS
« Reply #2 on: December 15, 2012, 02:07:30 PM »
Yes, same strategy even, only different number

Why not use transfer from GVP app? Because documentation states it and when I tried just in case it was worst...

[quote]
Note: This VoiceXML application mustbe voice self-service only. The <transfer>block is unavailable for URS-controlled applications.
Routing to assisted service must be done in the strategy, as no transfer capability exists for this type of voice application.
[/quote]

Offline cavagnaro

  • Administrator
  • Hero Member
  • *****
  • Posts: 7641
  • Karma: 56330
Re: Call fail after PlayApplication with GVP/URS
« Reply #3 on: December 15, 2012, 02:27:53 PM »
Yes! Success! Issue was here:

WARNING: gethostbyname(core3) FALSE duration 6760 ms
Added to hosts file (must be DNS actually) and now it works... :D

Offline Flávio

  • Newbie
  • *
  • Posts: 32
  • Karma: 0
Re: Call fail after PlayApplication with GVP/URS
« Reply #4 on: December 15, 2012, 02:37:16 PM »
Congrats...

what was the issie? you had to add what to hosts??

Offline cavagnaro

  • Administrator
  • Hero Member
  • *****
  • Posts: 7641
  • Karma: 56330
Re: Call fail after PlayApplication with GVP/URS
« Reply #5 on: December 15, 2012, 04:10:56 PM »
the ip address of core3 server...it is an OXE so no DNS for it...
have to add it manually

Offline bublepaw

  • Sr. Member
  • ****
  • Posts: 283
  • Karma: 10
Re: Call fail after PlayApplication with GVP/URS
« Reply #6 on: December 17, 2012, 09:04:40 AM »
Is it appliance/CPU or INTIP card? If INTIP card it would mean You probably have to add names of all INTIP cards on OXE side.

Offline cavagnaro

  • Administrator
  • Hero Member
  • *****
  • Posts: 7641
  • Karma: 56330
Re: Call fail after PlayApplication with GVP/URS
« Reply #7 on: December 17, 2012, 11:40:45 AM »
No because SIP with Spatial Redundancy uses the CPU name only as host, not the INTIP boards IP addresses...imagine a huge network with that configuration on SIP...would be useless