https://vapi.ai/ logo
Join Discord
Powered by
401 SIP Auth Error, followed by 491 Request Pendin...
# support
j
Hello, I am trying to connect via SIP. I have managed to get the endpoint setup from the API etc and I am trying to place a call Initially I am getting a 401 error, I checked some of the existing support request and see that you are requesting a "placeholder" username / password. I have added these as vapi/vapi, after the challenge we send a response with that information contained within, however we are then getting 491 Request Pending How do I fix this?
v
message has been deleted
@Jonathan Hello! It's great to hear that you've set up your SIP endpoint and are making progress with placing a call. The 401 Unauthorized error indicates that the initial request was missing valid authentication credentials, and it seems you've addressed that by providing the placeholder username and password. The 491 Request Pending response indicates that the server has received a request within a dialog that it is unable to process at this time because it is dealing with another request. This is often related to SIP transactions and can occur if you're attempting to send another request while a previous one is still being processed. Here are a few steps you can take to resolve this issue: 1. Ensure that you are not sending multiple requests in quick succession. Wait for the current transaction to complete before initiating a new one. 2. Check your SIP client or device settings to make sure it handles SIP transactions correctly and respects the server's responses. 3. Review the SIP call flow to identify if there are any retransmissions or unnecessary requests being sent. If you continue to experience issues, please provide more details about the SIP call flow or any specific configurations you're using, and I'll be happy to assist you further.
You can continue this conversation by mentioning me in the message.
j
I am not sending in quick succession, the UAC capability at this point is moot, as its a server side final request. retransmissions are standard parts of the specification and should not be avoided. Packet capture confirms that there are no exteranious requests. Additionally on clicking for "Ask For Help" in this chat, I am getting the reply "This interaction failed"
s
Hey @Jonathan apology for the delayed response, can you hep me with a recent call id so I can look into the PCAP file because this would really help me figure out what went wrong!!
j
It looks like it worked when I tried yesterday, so I am guessing it was just a short term error, I’ll update if we see it again, thanks for getting back to me.
Hello, I am getting this problem again, here is a Call-ID: CNX2140_cgZaKlVhPFEAUFM+IREgAVl4V24+BQQDAmx2F3IJCytzaWsLHwEebnMXbQdcdAZoaQI-
Sorry, please use this one: ce276de1-28ea-123e-9783-ea20c2551d61
s
j
That was the Call-ID, we can see it very clearly on our side, I get a pcap of a call now
@Shubham Bajaj This is happening again blocking all calls, so I cant make much progress here.
s
@Jonathan You need to send username and password with basic auth without any encryption after that it will work currently what's happening:- - The first INVITE establishes initial contact but is rejected due to missing authentication. - After including credentials, the second INVITE is sent but gets a 491 Request Pending. - No final session setup occurs in this flow. Further steps would likely involve resolving the sending the correct auth credentials. https://cdn.discordapp.com/attachments/1308742638035406850/1313967900394127502/Screenshot_2024-12-05_at_2.07.14_AM.png?ex=67520f77&is=6750bdf7&hm=fc0ad5fcec319cfdcce5fa22e6378ed7611d6b8d0adc413006b20f772d1dddc3&
j
We are doing that already.
Did you check the second invite in the sip trace?
With regards to the auth credentials, as per configuration previously described, I can use any username and any password. This is true from my testing. If the credentials were wrong it would typically be recieved with a 401 or a 407, not a 491.
Are you just using a bot to reply to me seriously.
I am a telecoms engineer, I know how challenge response works.
There is no issue with the challenge response.
The fault here is the 491.
Look at your own bot generated reply with regards to the 491 which is failing at your side.
s
Sorry Man, it got executed wrong I was testing our bot for files shared and extraction and analyses and gave my account permission which ended up screwing you.
@Jonathan according to your experience, what could have gone wrong here. I wanted to understand so I can dig into more.
FYI: Deleting Bot Generated Messages.
j
Thanks for clarifying that.
Half of the time it returns this 491.
The other half it does not.
These “outages” last at least 30 minutes long.
They affect multiple agents.
s
Yeah i wanted to understand from your side of diagnosis.
j
Then after a while things just work again.
491 would be typically related to a resource exhaustion. So I would suspect there is some back end capacity issue (just a guess)
Or some rate limiting.
I wouldn’t say it’s account level rate limiting as this can happen on a call after the weekend with no other calls before it.
s
ON IT.
j
Thanks very much 👍
s
Digest username="user", realm="sip.vapi.ai", nonce="173316795263500", cnonce="BHN6giuHEj6Dl+ogwlUdYQ", algorithm=MD5, uri="sip:76dbc97c-9a43-4fec-a833-3f1acc7f10ae@sip.vapi.ai", response="1ef8e58097b1f16c2023031506a442b6", qop=auth, nc=00000001 @Jonathan why your sedning 
user
as username?
j
Because as per instructions I read from your side, the credentials themselves are irrelevant.
User was picked arbitrarily.
s
It is working for you other calls or your using it randomly?
j
The scenario is that is works and does not work with no changes on our side.
We have an engineer testing it every 15 minutes and when things start working again, we can demonstrate it to our clients.
When it works, it works for any of the agents, when it breaks, it break for the whole account.
This is even with sample sizes of 20
s
No can you check the user when it works, in one of the PCAP files?
j
as I said, the config is the same
It works with "user", that is fine
There is no observable delta on our side betwen working and not working.
There is no identifiable commonality either
only time dependancy.
s
What's happening is 491 is returned from our http authentication server.
j
that is an uncommon error for HTTP, as its stateless and should have any other blocking requests
s
yeah have to check with team why 491 from our side.
j
Thank you very much 👍
Hello @Shubham Bajaj just wondering if you have any updates for me?
s
Nudged the SIP team again for the response, waiting for their reply.
r
I've got the same problem
Can you help please? @Shubham Bajaj
v
Hey rocha, can you please tag me to your #support ticket.
r
Just did it
2 Views
PreviousNext
Powered by