On 12/28/2016 at 05:36 PM Michael Maier wrote:
> On 12/27/2016 at 07:54 PM Michael Maier wrote:
>> Hello!
>>
>> I'm facing ReInvites as caller from UAS despite configured
>> session-timers=refuse (which can be seen in the SIP trace) always after
>> 900s. (The behav
On 12/14/2016 at 06:22 PM, Luca Bertoncello wrote:
> Hi list!
>
> I already had the problem last year, then it would be solved (surely from
> some technician by Deutsche Telekom on their servers), and now I have the
> problem again (but I didn't changed my Asterisk configuration).
>
> The
On 12/27/2016 at 07:54 PM Michael Maier wrote:
> Hello!
>
> I'm facing ReInvites as caller from UAS despite configured
> session-timers=refuse (which can be seen in the SIP trace) always after
> 900s. (The behavior is the same if session-timers is set to accept).
>
> This
On 12/27/2016 at 07:54 PM, Michael Maier wrote:
> Hello!
>
> I'm facing ReInvites as caller from UAS despite configured
> session-timers=refuse (which can be seen in the SIP trace) always after
> 900s. (The behavior is the same if session-timers is set to accept).
>
> This
Hello!
I'm facing ReInvites as caller from UAS despite configured
session-timers=refuse (which can be seen in the SIP trace) always after
900s. (The behavior is the same if session-timers is set to accept).
This just happens with one provider (German Telekom to callee at kabelbw).
- The
Derek Bolichowski wrote:
HI Michael,
You can set this in sip.conf:
session-timers=refuse
I know of this option - it doesn't help, because the provider ignores it
(on some calls) and the call is dropped anyway.
Normally, there is no problem with the timers. And the problem which
occurred
Hello all!
I can see a strange problem during invite in dialog in the context of
timer handling.
Given is the following incoming call from provider at 8.195.88.234 (2@2)
to my asterisk at 28.19.57.152 (1@1):
After 900s suddenly *asterisk* starts the timer reinvite - I would have
expected the
Hello!
Sometimes, I can see here the following scene:
Asterisk sends 11 SIP OPTIONS-packages (qualify=120) and they are all
ignored by the peers - but the 12. package is answered immediately as
expected (I'm sure there is no network related problem).
I can see this on trunks via Internet and
On 06/06/2016 at 04:40 PM Richard Mudgett wrote:
> On Sun, Jun 5, 2016 at 3:48 AM, Michael Maier <m1278...@allmail.net> wrote:
>
>> Hello!
>>
>> I occasionally can see warnings like these during *idle* times in
>> asterisk log (asterisk 13.7.2):
>>
>
On 06/06/2016 at 04:40 PM, Richard Mudgett wrote:
> On Sun, Jun 5, 2016 at 3:48 AM, Michael Maier <m1278...@allmail.net> wrote:
>
>> Hello!
>>
>> I occasionally can see warnings like these during *idle* times in
>> asterisk log (asterisk 13.7.2):
>>
>
Hello!
I occasionally can see warnings like these during *idle* times in
asterisk log (asterisk 13.7.2):
[2016-06-05 06:11:51] WARNING[27817] pjsip: sip_transactio Unable to
register REGISTER transaction (key xists)
[2016-06-05 06:11:51] WARNING[27817] pjsip: sip_transactio Unable to
On 05/12/2016 at 11:54 AM Joshua Colp wrote:
> Michael Maier wrote:
>> Hello!
>>
>> Today, I tried to switch from asterisk 13.7.2 to 13.9, but I'm getting
>> strange problem w/ the registering of all of my extensions. It looks
>> like that:
>
> This has alr
ion):
[2016-05-12 09:09:58] VERBOSE[4406] res_pjsip/pjsip_configuration.c:
Contact 107/sip:107@192.168.15.73:5060 is now Reachable. RTT: 23.332 msec
-> nothing more!
What's going on in asterisk 13.9? Why does it suddenly behave completely
different?
Thanks,
Michael
On 05/03/2016 at 09:16 PM Joshua Colp wrote:
> Eric Wieling wrote:
>> I don't know the default setting for progressinband in the code, but it
>> is documented in Asterisk 11's sip.conf.sample as defaulting to never.
>> Maybe the docs were fixed since Asterisk 11.
>
> The behavior change to
On 05/03/2016 at 05:43 PM Joshua Colp wrote:
> Michael Maier wrote:
>> On 05/03/2016 at 04:50 PM Joshua Colp wrote:
>>> Michael Maier wrote:
>>>> Hello Joshua!
>>>>
>>>>
>>>> I attached the sip debug without the progressinband=
ng a trunk to a ring
group or an extension?
Puzzled,
regards,
Michael Maier
--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
Hello Joshua,
On 04/25/2016 at 12:35 PM, Joshua Colp wrote:
> Michael Maier wrote:
>> Hello!
>>
>> I encounter the following problem (asterisk 11 and 13) with Teconisy as
>> trunk provider with enabled qualify and default t1min (100ms):
>>
>> Teconisy mos
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
101 - 118 of 118 matches
Mail list logo
