VoIP Mailing List Archives
Mailing list archives for the VoIP community |
|
| View previous topic :: View next topic |
| Author |
Message |
m1278468 at allmail.net
Guest
|
 Posted: Sun Apr 24, 2016 9:30 pm Post subject: [asterisk-users] Second invite after 100ms (with default t1m |
 |
|
Hello!
I encounter the following problem (asterisk 11 and 13) with Teconisy as
trunk provider with enabled qualify and default t1min (100ms):
Teconisy most often doesn't answer the first invite before asterisk
default t1min ended. Therefore asterisk sends one more invite. This
second invite is answered by Teconisy with
status 486 - Request terminated - Channel limit exceeded.
(The second invite obviously is interpreted as second, new call).
Asterisk therefore cancels the first(!!) call - but Teconisy proceeds
with exactly this first call (which now can't be handled by asterisk any
more).
For me, there are two problems in asterisk at this point:
1. The VoIP standard defines 500ms for t1 - using this standard value
for t1min works fine with Teconisy, too. t1min should be always
500ms - it prevents a completely blocked line!
2. Why does asterisk stop the call completely after the second invite,
which is canceled by Teconisy? It should be ignored because it
means, that the first invite is already processed by Teconisy.
Btw: I can see the same behavior with German Telekom. Asterisk most of
the time sends two invites, too, but here I don't get an error back from
Telekom, because I have two channels and therefore the channel limit
isn't exceeded most of the time. Setting t1min to the VoIP standard of
500ms prevents these unnecessary double invites with German Telekom, too.
Therefore: Please use the standards compliant t1min=500 instead of the
not compliant value of 100, which can cause much trouble and which
creates totally unnecessary network overhead.
Or is there another solution I overlooked?
Thanks,
Michael Maier
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
http://www.asterisk.org/hello
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users |
|
| Back to top |
|
 |
jcolp at digium.com
Guest
|
| Posted: Mon Apr 25, 2016 5:36 am Post subject: [asterisk-users] Second invite after 100ms (with default t1m |
|
|
Michael Maier wrote:
| Quote: | Hello!
I encounter the following problem (asterisk 11 and 13) with Teconisy as
trunk provider with enabled qualify and default t1min (100ms):
Teconisy most often doesn't answer the first invite before asterisk
default t1min ended. Therefore asterisk sends one more invite. This
second invite is answered by Teconisy with
status 486 - Request terminated - Channel limit exceeded.
(The second invite obviously is interpreted as second, new call).
Asterisk therefore cancels the first(!!) call - but Teconisy proceeds
with exactly this first call (which now can't be handled by asterisk any
more).
For me, there are two problems in asterisk at this point:
1. The VoIP standard defines 500ms for t1 - using this standard value
for t1min works fine with Teconisy, too. t1min should be always
500ms - it prevents a completely blocked line!
|
The standard actually allows you to ignore this and use the estimated
round trip time, which chan_sip will derive from the time it takes an
OPTIONS packet to go out and get a response. The t1min just enforces a
minimum.
| Quote: | 2. Why does asterisk stop the call completely after the second invite,
which is canceled by Teconisy? It should be ignored because it
means, that the first invite is already processed by Teconisy.
|
The 486 response code is actually for indicating busy. The 4XX series is
also for client failure, which tear down the session. It can't be
ignored. This would break things.
The retransmission of an INVITE shouldn't result in multiple sessions
being set up, the other side should treat it as a retransmission. This
is a bug on their side. Your adjustment of the T1 just makes it so you
don't allow it to happen.
I'd say the problem isn't with Asterisk but with the remote side. Since
you can configure things to work that's great but I don't see any code
changes we can do.
Cheers,
--
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com & www.asterisk.org
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
http://www.asterisk.org/hello
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users |
|
| Back to top |
|
|
m1278468 at allmail.net
Guest
|
| Posted: Mon Apr 25, 2016 10:46 am Post subject: [asterisk-users] Second invite after 100ms (with default t1m |
|
|
Hello Joshua,
On 04/25/2016 at 12:35 PM, Joshua Colp wrote:
| Quote: | Michael Maier wrote:
| Quote: | Hello!
I encounter the following problem (asterisk 11 and 13) with Teconisy as
trunk provider with enabled qualify and default t1min (100ms):
Teconisy most often doesn't answer the first invite before asterisk
default t1min ended. Therefore asterisk sends one more invite. This
second invite is answered by Teconisy with
status 486 - Request terminated - Channel limit exceeded.
(The second invite obviously is interpreted as second, new call).
Asterisk therefore cancels the first(!!) call - but Teconisy proceeds
with exactly this first call (which now can't be handled by asterisk any
more).
For me, there are two problems in asterisk at this point:
1. The VoIP standard defines 500ms for t1 - using this standard value
for t1min works fine with Teconisy, too. t1min should be always
500ms - it prevents a completely blocked line!
|
The standard actually allows you to ignore this and use the estimated
round trip time, which chan_sip will derive from the time it takes an
OPTIONS packet to go out and get a response. The t1min just enforces a
minimum.
| Quote: | 2. Why does asterisk stop the call completely after the second invite,
which is canceled by Teconisy? It should be ignored because it
means, that the first invite is already processed by Teconisy.
|
The 486 response code is actually for indicating busy. The 4XX series is
also for client failure, which tear down the session. It can't be
ignored. This would break things.
The retransmission of an INVITE shouldn't result in multiple sessions
being set up, the other side should treat it as a retransmission. This
is a bug on their side. Your adjustment of the T1 just makes it so you
don't allow it to happen.
I'd say the problem isn't with Asterisk but with the remote side. Since
you can configure things to work that's great but I don't see any code
changes we can do.
|
thanks for clarification! Besides that - I'm really wondering why others
don't face this problem - I hardly can believe that I'm the only one
affected.
Regards,
Michael
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
http://www.asterisk.org/hello
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users |
|
| Back to top |
|
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
Search
