" /> URS RequestRouteCall format is not correct - Genesys CTI User Forum

Author Topic: URS RequestRouteCall format is not correct  (Read 1961 times)

Offline abdel

  • Newbie
  • *
  • Posts: 24
  • Karma: 0
URS RequestRouteCall format is not correct
« on: July 08, 2019, 09:17:55 AM »
Advertisement
Hi,

Agent is not able to receive calls due the behavior of URS sending RequestRouteCall with incorrect format, I think 'ACCESS' should have the extension value, not the agent value?, so the same for SIPCONN  (SIPCONN(B2B_6002)).

any help is appreciated.

@10:55:50.2550 [BSYNC] Trace: Sent
10:55:50.255 Trc 04541 RequestRouteCall received from [544] (00000009 URS_Backup 10.76.50.6:59024)
message RequestRouteCall
AttributeThisDN '904'
AttributeConnID 00bb02e1c3740322
AttributeOtherDN 'B2B_6002'
AttributeExtensions [178] 00 08 00 00..
'CUSTOMER_ID' 'Resources'
'AGENT' 'B2B_6002'
'PLACE' 'Place_B2B_1003'
'DN' '1003'
'ACCESS' 'B2B_6002'
'SWITCH' 'SIPSwitch'
'NVQ' 13
'TARGET' '?:SaveDeskTest > 0@StatServer_URS.GA'
AttributeRouteType 0 (RouteTypeUnknown)
AttributeReason [14] 00 01 01 00..
'RTR' 161
AttributeReferenceID 4646169
10:55:50.255 Int 04543 Interaction message "RequestRouteCall" received from 544 ("URS_Backup")
10:55:50.255  -- created: CRequest@481b7b0 RequestRouteCall-URS_Backup[544]/4646169
10:55:50.255:(1) SIPS:LOGBLOCK:BEGIN:REQUEST:[
10:55:50.255 +++ CIFace::Request +++
  -- new invoke
  -- thisCall by party
  Parsed: RequestRouteCall
  From: URS_Backup[544]/4646169
  Numbers: +<904> -<B2B_6002>
  Calls: 482b8f0:1 none
  Parties: 904.55f6aa0-482b8f0:1
          none
  Status: parsed:1 queued:0 sent:0 acked:0 preevent:0 event:0 context:0 transferred:0
  -----
  -- validate
  -- state check: ok
  CIFace: Sent CRequest@481b7b0 RequestRouteCall-URS_Backup[544]/4646169
  -- aTmCall 00bb02e1c3740322 SetCause: Distributed to B2B_6002
  FinishRequest CRequest@481b7b0 RequestRouteCall-URS_Backup[544]/4646169
  IFace stats: q=0 s=0
  -- complete
  -- NAData ClRq removed
  TNAEmulator::NotifyBackup()
@10:55:50.2550 [BSYNC] Trace: Send to backup (SIPServer8) [584]:
message EventUserEvent
attr_#1005 0
attr_#1004 255
attr_#1003 1562579750
attr_#1002 85882
attr_#1001 5
attr_#1000 131072
AttributeAgentWorkMode 0 (Unknown)
AttributeAgentStateReasonUnused 1
AttributeThisDN '904'
@10:55:50.2550 [BSYNC] Trace: Sent
10:55:50.255:(1) GetRegistration::Unable to resolve number for DN:B2B_6002
10:55:50.255:(1) Number:[B2B_6002] is not internal, looking for service
10:55:50.255:(1) Selected for Dn B2B_6002(geo-loc[]:partitionId[]:cpdCapability[]): Service TrunkSIPSToALA5020_Test (geo-loc[], priority[1], capacity 0 (0% of -2))
10:55:50.255 SIPCONN(+212617465810): re-invite-called-initiated
10:55:50.255:(1) transfer re-INVITE
10:55:50.255 SIPCONN(B2B_6002): set monitor 05a04480, 05b94e7c
10:55:50.255:(1) SIPCALL(4897): add party 'B2B_6002'
  -- created party_info_tspp 562efd0
  -- created aTmParty 5ab9828
  SetRole: Destination for B2B_6002.5ab9828-482b8f0:1
  -- AddParty to 482b8f0: B2B_6002.5ab9828-482b8f0:1 after 904.55f6aa0-482b8f0:1
  CreateParty new external: B2B_6002.5ab9828-482b8f0:1
10:55:50.255:(1) Call 4897 dn B2B_6002 SetPartyId 12137
10:55:50.255:(1) SIPTR(56333): Begin step 0 - SipTransactionGetOffer(56334)
10:55:50.255 SIPCONN(+212617465810): re-invite-called-initiated
10:55:50.255 SIPCONN(+212617465810): GetOffer
10:55:50.255 SIPCONN(+212617465810): GetOffer::ReturnOffer
10:55:50.255 SIPCONN(+212617465810): NotifyOnOffer
10:55:50.255:(1) SIPTR(56334): complete
10:55:50.255:(1) SIPTR(56333): Step 0 - SipTransactionGetOffer(56334) complete
10:55:50.255:(1) SIPTR(56333): Begin step 1 - SipTransactionTransferCall(56335)
10:55:50.255 SIPCONN(B2B_6002): re-invite-null
10:55:50.255:(1) SipDialog: set monitor 05a044f4
10:55:50.255 SIPCONN(B2B_6002): main dialog 0 created
10:55:50.255 SIPCONN(B2B_6002): Local contact: '<sip:+212617465810@10.80.104.28:5060>'
10:55:50.255 SIPCONN(B2B_6002): InitiateDialog: preparing a 3pcc request
10:55:50.255:(1) add party 'B2B_6002' state
@10:55:50.2550 [BSYNC] Trace: Send to backup (SIPServer8) [584]:

Marked as best answer by abdel on August 31, 2023, 09:39:09 PM

Offline abdel

  • Newbie
  • *
  • Posts: 24
  • Karma: 0
Re: URS RequestRouteCall format is not correct
« Reply #1 on: July 08, 2019, 04:48:22 PM »
Hi,

Solved, the issue was that the option use_agentid in URS was set to true, now, while routing to the target, AttributeOtherDN and ACCESS attributes use the extension instead of the agentid.

=========================Logs =============================   



message RequestRouteCall

    AttributeThisDN    '904'

    AttributeConnID    00bb02e1c374607f

    AttributeOtherDN    '1003'

    AttributeExtensions    [174] 00 08 00 00..

        'CUSTOMER_ID'    'Resources'

        'AGENT'    'B2B_6002'

        'PLACE'    'Place_B2B_1003'

        'DN'    '1003'

        'ACCESS'    '1003'

        'SWITCH'    'SIPSwitch'

        'NVQ'    13

        'TARGET'    '?:SaveDeskTest > 0@StatServer_URS.GA'

    AttributeRouteType    0 (RouteTypeUnknown)

    AttributeReason    [14] 00 01 01 00..

        'RTR'    161

    AttributeReferenceID    5103751

18:22:16.756 Int 04543 Interaction message "RequestRouteCall" received from 544 ("URS_Backup")

18:22:16.756  -- created: CRequest@4818330 RequestRouteCall-URS_Backup[544]/5103751

18:22:16.756:(1) SIPS:LOGBLOCK:BEGIN:REQUEST:[

18:22:16.756 +++ CIFace::Request +++

  -- new invoke

  -- thisCall by party

  Parsed: RequestRouteCall

  From: URS_Backup[544]/5103751

  Numbers: +<904> +<1003>

  Calls: 48274f0:1 none

  Parties: 904.5e28768-48274f0:1

          none

  Status: parsed:1 queued:0 sent:0 acked:0 preevent:0 event:0 context:0 transferred:0

  -----

  -- validate

  -- state check: ok

  CIFace: Sent CRequest@4818330 RequestRouteCall-URS_Backup[544]/5103751

  -- aTmCall 00bb02e1c374607f SetCause: Distributed to 1003

  FinishRequest CRequest@4818330 RequestRouteCall-URS_Backup[544]/5103751

  IFace stats: q=0 s=0

  -- complete

  -- NAData ClRq removed

  TNAEmulator::NotifyBackup()

@18:22:16.7560 [BSYNC] Trace: Send to backup (SIPServer8) [584]:

message EventUserEvent

    attr_#1005    0

    attr_#1004    756

    attr_#1003    1562606536

    attr_#1002    629542

    attr_#1001    5

    attr_#1000    131072

    AttributeAgentWorkMode    0 (Unknown)

    AttributeAgentStateReasonUnused    1

    AttributeThisDN    '904'

@18:22:16.7560 [BSYNC] Trace: Sent

18:22:16.756 SIPCONN(+212617465810): re-invite-called-initiated

18:22:16.756:(1) transfer re-INVITE

18:22:16.756 SIPCONN(1003): set monitor 0625c218, 0651989c

18:22:16.756:(1) SIPCALL(28769): add party '1003'

  -- created party_info_tspp 580f0e0

  -- created aTmParty 5e28620

  SetRole: Destination for 1003.5e28620-48274f0:1

  -- AddParty to 48274f0: 1003.5e28620-48274f0:1 after 904.5e28768-48274f0:1

  CreateParty new internal: 1003.5e28620-48274f0:1

18:22:16.756:(1) Call 28769 dn 1003 SetPartyId 84060

18:22:16.756:(1) SIPTR(427758): Begin step 0 - SipTransactionTransferCall(427759)

18:22:16.756 SIPCONN(1003): re-invite-null

18:22:16.756:(1) SipDialog: set monitor 0625c28c

18:22:16.756 SIPCONN(1003): main dialog 0 created

18:22:16.756 SIPCONN(1003): Local contact: '<sip:+212617465810@10.80.104.28:5060>'

18:22:16.756 SIPCONN(1003): InitiateDialog: preparing a 3pcc request

18:22:16.756:(1) add party '1003' state

@18:22:16.7560 [BSYNC] Trace: Send to backup (SIPServer8) [584]:

message EventUserEvent

    attr_#1005    0

    attr_#1004    756

    attr_#1003    1562606536

    attr_#1002    629543

    attr_#1001    1

    attr_#1000    131072

    attr_#15999    0

    attr_#16000    1

    attr_#16500    [81] 31 3d 31 0d..

    AttributeUserEvent    [16099]

@18:22:16.7560 [BSYNC] Trace: Sent

18:22:16.756:(1) HA:MESSAGE:TYPE[2]: SYNCED

18:22:16.756:(1) SIPDLG[106134]: register TRN[527276]

18:22:16.756:(1) SIPDLG[106134]: TRN[527276] flags set to 0x6

18:22:16.756:(1) Sending  [588,UDP] 1013 bytes to 10.180.90.27:5060 >>>>>

INVITE sip:1003@10.180.90.27:5060 SIP/2.0

From: 212617465810 <sip:+212617465810@10.80.104.28:5060;transport=udp;user=phone>;tag=7DCB9B93-2BD5-43E7-9DA1-A2C7562E395C-211255

To: <sip:904@10.80.104.28:5060>

Call-ID: 614E4CF2-F0CC-4DDC-85CE-80CB88F9053F-173249@10.80.104.28

CSeq: 1 INVITE

Content-Length: 195

Content-Type: application/sdp

Via: SIP/2.0/UDP 10.80.104.28:5060;branch=z9hG4bK7493D4E2-062A-4194-8AB4-5969CABC56AB-362865

Contact: <sip:+212617465810@10.80.104.28:5060>

X-Genesys-CallInfo: routed

Allow: ACK, BYE, CANCEL, INFO, INVITE, MESSAGE, NOTIFY, OPTIONS, PRACK, REFER, UPDATE

P-Charging-Vector: icid-value=mgcf--20190708172253-100020101100000121766

Max-Forwards: 67

X-Genesys-CallUUID: GFDJGTBQ4L7JNEODGA953079E0000S31

Session-Expires: 1800;refresher=uac

Min-SE: 90

Supported: uui,timer

v=0

o=- 1563472567 1 IN IP4 10.104.76.4

s=SBC call

c=IN IP4 10.104.76.4

t=0 0

m=audio 43432 RTP/AVP 8 18 101

a=sendrecv

a=ptime:20

a=rtpmap:101 telephone-event/8000

a=fmtp:18 annexb=no

18:22:16.756:(1) SipDialog: event SEND_INVITE, t=527276, s=2, r=7, m=0625c28c

18:22:16.756 SIPCONN(1003): HandleSipDialogEvent(SEND_INVITE) - filtered

18:22:16.756 SIPCONN(1003): sdp state SDP_STATE_NULL, event SDP_OFFER_SENT

18:22:16.756 SIPCONN(1003): new sdp state SDP_OFFER_SENT, event SDP_OFFER_SENT

18:22:16.756 --- CIFace::Request ---

18:22:16.756:(1) 18:22:16.756:(1) SIPS:LOGBLOCK:END:REQUEST:]

18:22:16.756:(1) SIPS:LOGBLOCK:BEGIN:SIPDATA:[

18:22:16.756:(1) Received [588,UDP] 555 bytes from 10.180.90.27:5060 <<<<<

SIP/2.0 180 Ringing

From: 212617465810 <sip:+212617465810@10.80.104.28:5060;transport=udp;user=phone>;tag=7DCB9B93-2BD5-43E7-9DA1-A2C7562E395C-211255

To: <sip:904@10.80.104.28:5060>;tag=2F763707-0333-4629-A945-6C5FBF072C2E-5

Call-ID: 614E4CF2-F0CC-4DDC-85CE-80CB88F9053F-173249@10.80.104.28

CSeq: 1 INVITE

Via: SIP/2.0/UDP 10.80.104.28:5060;branch=z9hG4bK7493D4E2-062A-4194-8AB4-5969CABC56AB-362865;received=10.80.104.28

User-Agent: Genesys-SIPendpointSDK/9.0.010.04 (Windows 10.0.17134)

Contact: <sip:1003@10.180.90.27:5060>

Content-Length: 0

18:22:16.756:(1) SipDialog: event CALLING_RESPROV, t=527276, s=2, r=5, m=0625c28c

18:22:16.756 SIPCONN(1003): HandleSipDialogEvent(CALLING_RESPROV)

18:22:16.756 SIPCONN(1003): Capabilities 60013f

18:22:16.756 SIPCONN(1003): reliable=0

18:22:16.756 SIPCONN(1003): store remote content

18:22:16.756 SIPCONN(1003): skip SDP pocessing [0/SDP_OFFER_SENT]

18:22:16.771:(1) routing dialog '84059' terminated

18:22:16.771  -- thisCall by party

18:22:16.771 SetContext: for party 904.5e28768-48274f0:1

18:22:16.771 +++ CIFace::Event +++

Offline cavagnaro

  • Administrator
  • Hero Member
  • *****
  • Posts: 7641
  • Karma: 56330
Re: URS RequestRouteCall format is not correct
« Reply #2 on: July 08, 2019, 06:09:30 PM »
Thanks for sharing
Be sure to follow your TServer guide for some options and behavior