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

Change timeout before sending re-invite #98

Open
ben-rowe opened this issue Aug 26, 2015 · 6 comments
Open

Change timeout before sending re-invite #98

ben-rowe opened this issue Aug 26, 2015 · 6 comments

Comments

@ben-rowe
Copy link

Hi i have an issue where i send an invite and it's taking upwards of 500ms to return which is causing the invite's to be sent again. Is there a way of modifying the re-invite timer in the sip.send() function?

Many Thanks
Ben

@kirm
Copy link
Owner

kirm commented Aug 31, 2015

Do you mean that sip.send blocks for 500ms?

@ben-rowe
Copy link
Author

yes i do i actually modified it my self on a pull request in the end. Unsure if it is usefull to the project?

@ben-rowe
Copy link
Author

fork even*

@kirm
Copy link
Owner

kirm commented Aug 31, 2015

sip.send should not be blocking, it should return immediately. Can you provide some more information?

@ben-rowe
Copy link
Author

Oh no doesnt block i just wanted to modify the timing in the options object. We have a provider giving us LRN and CNAM over SIP. On there dev enviroment they can take over 500ms to complete causing another invite to be sent out. Unfortunatly they dont send out 100 tryings and even though the id sent is the same then then send us back 2 responses. charging us double. I just wanted a way of modifying the timings to prevent this issue i forked and made the modification. didnt know if anyone else had run into this issue or if the mods i made are usefull to anyone else.

@kirm
Copy link
Owner

kirm commented Sep 1, 2015

Well I think i can implement timers configuration in options object you pass to sip.start.
But in my experience fiddling with timers is not a good way to handle a race condition. And given that sip.js uses recommended values of timeouts from sip spec, any client should be experiencing those problems with your provider. So maybe the issue could be resolved some other way? May be your provider need some additional information in INVITEs to map identify them properly?

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