Author |
Message |
|
|
MarcusHuang
Joined: Feb 25, 2014
Messages: 157
Offline
|
Does anyone have a sample of how to get User to User Info from a SIP request or from the SIP headers? I searched, could not really find anything.
|
|
|
|
|
JoelEzell
Joined: Nov 15, 2013
Messages: 780
Offline
|
Hi Marcus, in the Breeze API we called that Context ID. Call.getContextId() will return you the value of ASAI UUI, and setContextId() will let you set this value.
|
|
|
|
|
MarcusHuang
Joined: Feb 25, 2014
Messages: 157
Offline
|
Ok thanks. I am a little familiar with that from engagement designer. I thought you could do something different like get the sip header info and see what the hex value of uui is on the incoming sip request. Do you know if that is possible?
|
|
|
|
|
JoelEzell
Joined: Nov 15, 2013
Messages: 780
Offline
|
Yes, if you actually want to look at the value of the User-to-User header, you can do so using the IncomingSipMessageListener. Beware though: that header is ugly. There's a whole lot of information encoded into it. Is there any particular reason you need to get at the hex encoded header value instead of just getting UUI and UCID from the higher level methods? Do you need access to one of the more arcane fields in the header?
|
|
|
|
|
MarcusHuang
Joined: Feb 25, 2014
Messages: 157
Offline
|
In the past, using Engagement Designer, there was no clean way to parse the contextId, but i guess, w/ the API that may be different. For example, i have a UUI of 96 char, with about 12 values that are "comma separated" I could not parse the UUI in Engagement Designer using the default functions and the ContextId, had other info. I will try the ContextId though. Do you have anything that samples IncomingSipListener? The Dev guide does not have any info on it.
|
|
|
|
|
JoelEzell
Joined: Nov 15, 2013
Messages: 780
Offline
|
Yeah, EngagementDesigner is good at a lot of things; string parsing is not one of them. It's definitely easier to do that in Java code. I don't have any examples of use of IncomingSipMessageListener, but it's pretty straightforward. Just create a class that implements that Interface and has an annotation of IncomingMessageListener. Something like this. You can then use SipRequest.getHeader() to get the value of the header. The attributes in the callAttributes map are the same as the attributes accessible through the Call interface.
@IncomingMessageListener
public class MySipMessageListener
{
void requestReceived(SipRequest request, Map callAttributes)
{
}
void responseReceived(SipResponse response, Map callAttributes)
{
}
}
|
|
|
|
|
MarcusHuang
Joined: Feb 25, 2014
Messages: 157
Offline
|
Thanks. Appreciate the info.
|
|
|
|
|
MichaelNorman
Joined: Jun 3, 2015
Messages: 448
Offline
|
I attempted to use GetcontextID, but receive the following error:
Could not execute GETCONTEXTID:com.avaya.collaboration.call.async.AsyncCallSipImpl incompatible with com.avaya.collaboration.call.Call
How can I obtain this from the web service side, using the below code?
Call call = CallFactory.getCall(request.ucid());
|
|
|
|
|
JoelEzell
Joined: Nov 15, 2013
Messages: 780
Offline
|
Let me check with some folks on the team to see waht might cause this. The main guy that I'd ask is out of the office until Monday. In the meantime, since this is slightly different than the original purpose of this post, would you mind posting the question again in a new thread? Thanks.
|
|
|
|
|
MichaelNorman
Joined: Jun 3, 2015
Messages: 448
Offline
|
Sure no problem, thanks.
|
|
|
|
|
Wilder
Joined: Aug 6, 2018
Messages: 29
Offline
|
JoelEzell wrote:Yeah, EngagementDesigner is good at a lot of things; string parsing is not one of them. It's definitely easier to do that in Java code. I don't have any examples of use of IncomingSipMessageListener, but it's pretty straightforward. Just create a class that implements that Interface and has an annotation of IncomingMessageListener. Something like this. You can then use SipRequest.getHeader() to get the value of the header. The attributes in the callAttributes map are the same as the attributes accessible through the Call interface.
@IncomingMessageListener
public class MySipMessageListener
{
void requestReceived(SipRequest request, Map callAttributes)
{
}
void responseReceived(SipResponse response, Map callAttributes)
{
}
}
Joel,
I tried this, and I am able to see the incoming sip but the callAttributes is empty. why is that? here is how I check:
void requestReceived(SipRequest request, Map callAttributes)
{
logger.info(request.toString());
if (callAttributes.isEmpty()) {
logger2.info("Empty \n\n\n");
} else {
logger2.info("Not EMPTY \n\n\n");
}
}
thanks
|
|
|
|
|
JoelEzell
Joined: Nov 15, 2013
Messages: 780
Offline
|
Is this the dialog establishing INVITE? If so, it would be expected that callAttributes would be empty. This set of name/value pairs is there for your application to use for your own use. The platform will never populate anything there on its own. The SIP headers are available through the SipMessage interface, if that's what you were going for.
|
|
|
|
|
Wilder
Joined: Aug 6, 2018
Messages: 29
Offline
|
JoelEzell wrote:Is this the dialog establishing INVITE? If so, it would be expected that callAttributes would be empty. This set of name/value pairs is there for your application to use for your own use. The platform will never populate anything there on its own. The SIP headers are available through the SipMessage interface, if that's what you were going for.
Yes, the dialog is establishing Invite
Since I need some information about the call, in this case I have to use the OutgoingMessageListener which calls the sendingOut() method after the call is intercepted and the call object is instantiated. I had a problem with the OutgoingMessageListener as the call was getting blocked and forcing a call.allow made everything work.
thanks
|
|
|
|
|
JoelEzell
Joined: Nov 15, 2013
Messages: 780
Offline
|
OK. So at this point, you're all good, right?
|
|
|
|
|
Wilder
Joined: Aug 6, 2018
Messages: 29
Offline
|
JoelEzell wrote:OK. So at this point, you're all good, right?
yes, everything is good. But I think to say that call.allow is called by default is not always true. Something happens in the background in the SDK where the call gets suspended/blocked. For now there is a work around and I will explicitly call call.allow .
I am leaving this information in-case another developer comes across the same issue in the future.
thanks for the assistance
|
|
|