URS not seeing UData values

[nonny]

It's late so I've probably missed a newbie thing but I can see UData values (GSW_CAMPAIGN_NAME) etc in the SIP Server log, but I'm unable to call those values within URS (route point on same switch/SIP Server). 

I've set the userdata-map-filter to "*" on SIP Server.  I assume consult-user-data and merged-user-data don't apply for routing from SIP to URS basically (not through GVP).

[Kubig]

Any error within the log or the value is just a null?

[nonny]

all nulls in URS log

[Kubig]

Post the fragment of URS log covering the whole tree of KVP(UserData) and the block where the UData function is used.

[nonny]

Scenario:  Outbound call answered and transferred to RP 22705.

URS:
[url=https://www.dropbox.com/s/9yggj5ckj8o18xm/ursproblem.txt?dl=0]https://www.dropbox.com/s/9yggj5ckj8o18xm/ursproblem.txt?dl=0[/url]

Trying to access GSW_CAMPAIGN_GROUP_NAME by using UData['GSW_CAMPAIGN_GROUP_NAME']

SIP:
[url=https://www.dropbox.com/s/pvbbwxh7ltr4lzh/ursproblemsiplog.txt?dl=0]https://www.dropbox.com/s/pvbbwxh7ltr4lzh/ursproblemsiplog.txt?dl=0[/url]

[Kubig]

In this case, the option "userdata-map-filter" should have impact. Could you, please, post the log where this option is configured with "*" value? Or you can use "SIP_HEADERS" functions within the routing strategy/URS.

PS: Did you try to change this option "userdata-map-invite-after-refer"?

[nonny]

No haven't changed userdata-map-invite-after-refer so it's still at the default value of false (option doesn't exist currently).

Not sure what you mean exactly by posting the log where the userdata-map-filter option is set at *. 

In a URS centric environment, does that userdata-map-filter need to be set on any other object other than SIP-S?

[Kubig]

Within the posted logs there are no userdata mapping between T-Lib and SIP - so, it seems like the option was not configured to "*" (all) or some specific KVP.

[nonny]

I can see the GSW attached data items in the call flow.  However OCS makes a RequestSingleStepTransfer to the Route Point to play the Outbound strategy.  At that point the GSW attached data items are not present in the call.

[cavagnaro]

OCS? URS you should try to say. Check URS logs on that call

Enviado de meu C6602 usando Tapatalk

[nonny]

From the SIP Server log.  22705 is the VTD/URS route point set for the Campaign:

11:40:44.534 Trc 04541 RequestSingleStepTransfer received from [628] (00000006 outbound_contact_server_cd 10.14.131.197:60224)
message RequestSingleStepTransfer
AttributeThisDN 'OCS'
AttributeConnID 01a00269773a0042
AttributeOtherDN '22705'
AttributeReferenceID 224
11:40:44.534 Int 04543 Interaction message "RequestSingleStepTransfer" received from 628 ("outbound_contact_server_cd")
@11:40:44.5340 [ISCC] destination_location substituted by local
@11:40:44.5340 [ISCC] destination_location substituted by local
11:40:44.534  -- created: CRequest@322b890 RequestSingleStepTransfer-outbound_contact_server_cd[628]/224
11:40:44.534: $+TLIB:CTI:Unknown:0:15394655
11:40:44.534 +++ CIFace::Request +++
  -- new invoke
  -- thisCall by party
  Parsed: RequestSingleStepTransfer
  From: outbound_contact_server_cd[628]/224
  Numbers: +<OCS> +<22705>
  Calls: 3224950:1 none
  Parties: OCS.2fc3100-3224950: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@322b890 RequestSingleStepTransfer-outbound_contact_server_cd[628]/224
  -- aTmCall 01a00269773a0042 SetCause: SingleStepTransfer to 22705
  FinishRequest CRequest@322b890 RequestSingleStepTransfer-outbound_contact_server_cd[628]/224
  IFace stats: q=0 s=0
  -- complete
11:40:44.534: ResolveCallInfo: set flag DIAL_PLAN_PROCESSING
11:40:44.534: SIPTR(547): Begin step 0 - SipTransactionResolveCallInfoByDialPlan(548)
11:40:44.534: DialPlan:Begin: DEVICE[OCS] using AOR OCS instead
11:40:44.534: DialPlan:Not Found for dest 22705
11:40:44.534: DialPlan: DialPlan found, but no rule defined for destination 22705.
11:40:44.534: DialPlan: No rule applied, using original destination '22705'.
11:40:44.534: DialPlan: clear flag DIAL_PLAN_PROCESSING
11:40:44.534: ProcessDialPlanResult: Connecting to DEVICE(491,22705).
11:40:44.534 SIPCONN(10212215857): re-invite-connected
11:40:44.534: transfer refer
11:40:44.534: SIPCALL(66): add party '22705'
  -- created party_info_tspp 25f17f0
  -- created aTmParty 3116dd0
  SetRole: Destination for 22705.3116dd0-3224950:1
  -- AddParty to 3224950: 22705.3116dd0-3224950:1
  -- new TSCP call leg 3
  -- call leg created leg_id=3
  CreateParty new internal: 22705.3116dd0-3224950:1

[cavagnaro]

Wait, ISCC?
So, I do remember a scenario where ISCC outbound calls didn't match on the other TServer as they were identified as Inbound and not Outbound.
On TServer 8.1 and new ones it has a feature to force those calls identification.
Can't remember the functionality.
As they don't match the call type the Voice continued but the ISCC data doesn't. I guess it works fine for Inbound calls right? Your ISCC general config is OK, I assume

[Kubig]

From my point of view, all pointed to the bad configuration of VoIP service object for MediaServer intergration - just add the "userdata-map-filter" option where the specified KVP should be used as the value.

[nonny]

The site has the DN range 2XXXXX on SIP Server.  The Cisco switch has the DN ranges 3XXXX and 6XXXX for AD positions.  The ERPs are all 6XXXX.  The problem seems to have been there was only one Trunk DN pointing to CUCM but with prefix of 3.

Sent from my SM-N9005 using Tapatalk

[cavagnaro]

Well, seems my assumption was incorrect then, good you fixed. Remember all objects involved on ISCC must be accessible

Enviado de meu C6602 usando Tapatalk