I was wondering if you could guide me on something that would help in some development. Currently I am working on a feature for our product that needs to talk to a T1 or SIP type IVR. I am able to talk to a T1 type IVR and that works, but I'm stuck on how a SIP IVR differentiates between all its active calls? An IVR with a T1 has a one-to-one mapping between its lines/ports, but this is not true with a IVR implemented as SIP.

I currently identify calls on a T1 type IVR via its Trunk Grouping and Member, but cannot apply the same logic to a SIP type IVR.

Thanks,

Rich.

From what perspective are you asking?

The SIP IVR uses SIP Call-ids.
Communication Manger has both a SIP Call-id and a trunk group/member at s disposal to differentiate... but it uses the SIP CallID and the internal communication manager callID for message association to the right call.

I don't think I have the full context for the problem you are trying to solve here.

I'm guessing you are trying to use TSAPI to monitor a call on Communication Manager that is ultimately delivered to a SIP IVR, and then want to tie data you have to the call that is offered to the SIP IVR.... UCID would be the mechanism to do that. UCID is sent to a SIP trunk by Communication Manager when it is properly configured to do so. I think I put up a TSAPI FAQ on how to provision Communication Manager to make this happen.

Hi John,

I am asking from the perspective of the IVR because we have an application running there too. Its job is to queue calls and it communicates to tell our Product which call in the IVR to deal with, which is why we need to tie data with a particular call.

Am i correct in assuming that the IVR can find and send our Product a CallID such as "Call-ID: a84b4c76e66710@pc33.atlanta.com"?
Looking at the SIP Spec, i dont see any other way an IVR can identify more than one call simultaneously without using the generic SIP Call ID, unless its Avaya specific.

However, i am trying to find something generic because i write less code, and also because clients are not always a perfect scenario (having Avaya equipment installed throughout their whole site). As I have worked before with sites that have a mixture, such as an Avaya Switch but a non-Avaya IVR.

Thanks.

John,

I found that TSAPI FAQ that you mentioned, It describes how to enable sending UCID over the Trunk. So other readers dont have to find it, i will paste it here:
To receive Universal Call Identification (UCID) information in the events, the following system parameters must be correctly set.

Type the command 'change system-parameters features' on Avaya Site Administrator command window. Enable the following features on the CM in order to get UCID in service initiated event:
Create Universal Call ID (UCID) to 'y' (Setting to 'y' indicates that UCID will be generated for each call)
UCID network Node ID to 1 (or any number between 1 to 32767 and unique to the switch in the network)
Send UCID to ASAI to 'y' (Setting to 'y' enable transmission of UCID information)


Type the command 'change trunk-group N' on Avaya Site Administrator command window and enable the 'Send UCID' field from page 3 for each trunk group that is used for communication between CM systems. This field specifies whether or not the trunk should transmit Universal Call IDs. Sending UCIDs in a network of CMs allows an application server that interworks with all of them to realize it already has handled a call when it is transferred to an agent on another switch.
----------------------------------------------

Is there any way i can do this without using UCID?
I am still stuck with my previous posting, about how our queuing application running on a SIP IVR (Avaya/3rd party)can idenify each of the many active calls to our passive CTI Product?

As this part of our feature is designed to work with SIP, when i finish writing this i plan for it to work on any SIP environment.

Thanks.

Yes The originator of a SIP INVITE uses the sip callid header to identify the call uniquely. I.e. "Call-ID: a84b4c76e66710@pc33.atlanta.com". Each call at the interface will have a unique Call-ID (the information before the "@pc33.atlanta.com" will vary).
For a generic handle to differentiate calls at a specific SIP interface (IP+port), the sip Call-ID header information should be used. The issue I typically get asked about is how do you tie together information you are getting from different sources (i.e. the SIP trunk, and a call terminating at a station monitored with CTI). Since Communication Manager operates as a back to back UA, and it supports non-SIP devices. This can be non-trivial. The typical question I get in this space is how to do that binding... the first easist method is to use UCID or UUI, hence the FAQ reference. UCID is the only answer when the call is originated manually from a device and it routes to a SIP trunk.

Hi John, When you enable the UCID, can you tell us which part of the SIP header does this information is passed on. Can you also help us with a sample SIP trace that has UCID value in it.

Also is it mandatory to enable send UUI IE with the setting to Shared mode to receive UCID on the SIP header?

User-To-User: 00FA08269400D45113E39D;encoding=hex


UCID is 269400D45113E39D


User-To-User: 04C80A31323334353637383930FA08269400D55113E3AC;encoding=hex
UCID is 269400D55113E3AC
In this second example there is a UUI value of ASCII 1234567890 at teh begining of the User-to-User header.

INVITE sip:32130@avaya.com SIP/2.0

From: "Dieter Eisenlohr" <sip:anonymous@anonymous.invalid>;tag=0c6a0976c7ee21cb1251414f500

To: <sip:32130@avaya.com>

Call-ID: 0c6a0976c7ee21cc1251414f500

CSeq: 1 INVITE

Max-Forwards: 71

Via: SIP/2.0/TLS 135.9.231.41;branch=z9hG4bK0c6a0976c7ee21cd1251414f500

Supported: 100rel,histinfo,join,replaces,sdp-anat,timer

Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,SUBSCRIBE,NOTIFY,REFER,INFO,PRACK,PUBLISH

User-Agent: Avaya CM/R016x.00.1.510.1

Contact: "Dieter Eisenlohr" <sip:135.9.231.41:5061;transport=tls>

Route: <sip:135.9.231.229:5061;transport=tls;lr;phase=terminating>

Accept-Language: en

Alert-Info: <cid:internal@avaya.com>;avaya-cm-alert-type=internal

History-Info: <sip:32130@avaya.com>;index=1

History-Info: "32130" <sip:32130@avaya.com>;index=1.1

Min-SE: 1200

P-Asserted-Identity: "Dieter Eisenlohr" <sip:avaya.com>

Record-Route: <sip:135.9.231.41:5061;transport=tls;lr>

Session-Expires: 1200;refresher=uac

Privacy: id

User-To-User: 04C80A31323334353637383930FA08269400D55113E3AC;encoding=hex

Content-Type: application/sdp

Content-Length: 232



v=0

o=- 1360257964 1 IN IP4 135.9.231.41

s=-

c=IN IP4 135.9.231.207

b=AS:64

t=0 0

a=avf:avc=n prio=n

a=csup:avf-v0

m=audio 2128 RTP/AVP 0 8 127

a=rtpmap:0 PCMU/8000

a=rtpmap:8 PCMA/8000

a=rtpmap:127 telephone-event/8000



Relative to shared being manditory, I encourage you to experment in the einvornment you are deploying in. While some documentation says that 'shared' is manditory, other does not and my testing shows variability on my CM 6.0 system.