Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

createUAC or library is canceling INVITE after 3 mins - Need to extend the time #105

Open
NiccAtNyte opened this issue Apr 17, 2021 · 14 comments

Comments

@NiccAtNyte
Copy link

hello. I have a situation where I need the drachtio library to not cancel the invite after 3 mins and allow me to specify a new timeout or turn off the timeout. Here is my example code that works but somewhere in the library a timeout is being sent. I have verified it's not the sip server that is initiating this cancel. How would I add a timeout to this code below exactly? thanks for the assistance.

const inviteRequest = async function (contactId: string, erp: string): Promise {
// sip:[email protected]:5060
let uri = sip:${erp}@${process.env.T_SERVER_IP}:${process.env.T_SERVER_PORT};
srf
.createUAC(uri, {})
.then((uac: any) => {
console.log(Call connected to primary destination ${process.env.T_SERVER_IP} for contactId: ${contactId} and erp: ${erp});
console.log(
Dialog established for contactId: ${contactId} and erp: ${erp}, with call-id: ${uac.sip.callId},
);
openDialogs[contactId] = uac;
uac.on("destroy", (msg: any, reason: any) => {
console.log(Called party hung up for contactId: ${contactId} and erp: ${erp});
const openDialog = openDialogs[contactId];
if (openDialog) {
delete openDialogs[contactId];
console.log(*** END *** Dialog destroyed for contactId: ${contactId} and erp: ${erp});
} else {
console.log(Dialog not opened for contactId: ${contactId} and erp: ${erp});
}
});
})
.catch((err: any) => {
console.error(INVITE rejected for contactId: ${contactId} and erp: ${erp} with status: ${err});
});
};

@davehorton
Copy link
Collaborator

could you please include a drachtio server log with loglevel debug and sofia loglevel at 9 ?

@NiccAtNyte
Copy link
Author

I must be doing something wrong because I don't see any logs in either the container or the host os. this is what I ran to start up the docker container:

docker run -d --rm --name drachtio --net=host -v /tmp/log:/var/log/drachtio drachtio/drachtio-server drachtio --contact "sip:*;transport=tcp,udp" --loglevel debug --sofia-loglevel 9

@davehorton
Copy link
Collaborator

perhaps just send the logs to stdout by removing the -d option, and tee it to a file

@NiccAtNyte
Copy link
Author

drachtio_log_niccatnyte.txt

here are some tests I just made a few mins ago.

@davehorton
Copy link
Collaborator

davehorton commented Apr 17, 2021

The issue is that sip timer C by default is set to 3 minutes. It cancels the invite if no final response has been received in that time. I've not heard of a use case for setting it longer than 3 minutes before, could you describe your scenario under which this is needed?

@NiccAtNyte
Copy link
Author

NiccAtNyte commented Apr 17, 2021

so for my company, we are building a bridge process between amazon connect and Genesys SIP Server. Our client uses the Genesys platform. The media is not traversed via sip while the signaling is. The audio is delivered via an external route point in Genesys to Connect via a TFN. But, our client requires we use Genesys to provide them real time stats/events such when the calls makes it to the connect queue, when an agent gets the calls, when the agent if online, offline,etc. And some of these events are for CTI integration. But not the point. So what we are seeing is when the calls are queue in connect, we must be continuing to ring and ring then that timer kicks and sends a CANCEL before an agent can become available. So maybe we are going about it the wrong way. Hopefully this makes sense. If you would like to have a deeper convo, I can be availalbe via a Teams invite I can send out

@NiccAtNyte
Copy link
Author

i'm sorry but which src file has the sip timer? been digging through it haven't found it yet.

@davehorton
Copy link
Collaborator

it is in the sofia sip library

@NiccAtNyte
Copy link
Author

We actually have everything working except this timeout piece that was discovered during our testing. So this just may a one off thing for our solution where we need to increase the timeout which may or may not have side effects. Not sure what to do exactly but I could try increasing the timeout value and recompiling and make some tests.

@davehorton
Copy link
Collaborator

It seems that you are saying when you send an INVITE to Amazon connect it does not answer the call (with a 200 OK) until it actually reaches an agent, and that the whole time it is in queue it stays in a ringing state? Is that so?

@NiccAtNyte
Copy link
Author

the call is in connect queue, we see that event come in from connect and then send an INVITE to the Genesys SIP Server. And yes, while in queue it's basically ringing the whole time. Maybe we shouldn't do an invite and try a notify? I'm not sure. I'm not a SIP expert.

@NiccAtNyte
Copy link
Author

still trying to track down the where the actual timeout integer is set in the sofia library. There's a lot to it. any chance you tell me the specific file and line number? I did find sip_time.c but looks like the function receives the timeout value from somewhere else.

@davehorton
Copy link
Collaborator

First, I don't know where in sofia it is without looking.

Before I spend my time looking I want to understand if the way you are doing this makes sense.

I still don't understand your scenario. I note in your log file that you are sending an INVITE with no body. So it seems like this INVITE is not attempting to establish a call at all. It seems your call between Genesys and Connect is established by other means, is that correct? And you are somehow trying to pass events of some nature? Can you explain, because I am not sure the way you are going is the best way to achieve what you want

@NiccAtNyte
Copy link
Author

let me meeting with my teammate this evening see if I can provide a better explanation and explain why we are performing the sip INVITE when the call is in queue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants