Re: [asterisk-users] chan_pjsip ignoring endpoint device state (qualify) on dial

[Jacek Konieczny]

On 2016-08-10 11:53, Joshua Colp wrote:

Jacek Konieczny wrote:

On 2016-08-09 10:06, Faheem Muhammad wrote:

trip time and Call Setup time of SIP Requests.
In case of GSM Network with high delay you need to set the T1 timer a
higher value like 1000ms (500 ms default). Similarly you can reduce the
Call setup time by configuring 'T2' upto you choice as per you telephony
network. Configure t1min, timert1 and timerb according to your network.


No, that won't work.

First – 't1min', 'timert1' and 'timerb' are chan_sip, not pjsip options.

Second – the 'timer_t1' and 'timer_b' settings available in 'pjsip.conf'
are global and not per-endpoint. I cannot change T1 for trunks, as they
might not be fast enough to respond and I cannot set it for phones only.

It seems I need to bring back the chan_sip behaviour – 'do not bother
with INVITE to Unreachable devices'.


I'd suggest filing an issue on the issue tracker[1] for this. It's
reasonable behavior.


Done:
https://issues.asterisk.org/jira/browse/ASTERISK-26281

I just wanted to make sure I am not missing something, first.

Jacek

--
_
-- 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

Re: [asterisk-users] chan_pjsip ignoring endpoint device state (qualify) on dial

[Joshua Colp]

Jacek Konieczny wrote:

On 2016-08-09 10:06, Faheem Muhammad wrote:

trip time and Call Setup time of SIP Requests.
In case of GSM Network with high delay you need to set the T1 timer a
higher value like 1000ms (500 ms default). Similarly you can reduce the
Call setup time by configuring 'T2' upto you choice as per you telephony
network. Configure t1min, timert1 and timerb according to your network.


No, that won't work.

First – 't1min', 'timert1' and 'timerb' are chan_sip, not pjsip options.

Second – the 'timer_t1' and 'timer_b' settings available in 'pjsip.conf'
are global and not per-endpoint. I cannot change T1 for trunks, as they
might not be fast enough to respond and I cannot set it for phones only.

It seems I need to bring back the chan_sip behaviour – 'do not bother
with INVITE to Unreachable devices'.


I'd suggest filing an issue on the issue tracker[1] for this. It's 
reasonable behavior.


[1] https://issues.asterisk.org/jira

--
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

Re: [asterisk-users] chan_pjsip ignoring endpoint device state (qualify) on dial

[Jacek Konieczny]

On 2016-08-09 10:06, Faheem Muhammad wrote:

trip time and Call Setup time of SIP Requests.
In case of GSM Network with high delay you need to set the T1 timer a
higher value like 1000ms (500 ms default). Similarly you can reduce the
Call setup time by configuring 'T2' upto you choice as per you telephony
network. Configure t1min, timert1 and timerb according to your network.


No, that won't work.

First – 't1min', 'timert1' and 'timerb' are chan_sip, not pjsip options.

Second – the 'timer_t1' and 'timer_b' settings available in 'pjsip.conf' 
are global and not per-endpoint. I cannot change T1 for trunks, as they 
might not be fast enough to respond and I cannot set it for phones only.


It seems I need to bring back the chan_sip behaviour – 'do not bother 
with INVITE to Unreachable devices'.



Jacek


On Tue, Aug 9, 2016 at 12:03 PM, Jacek Konieczny > wrote:

Hi,

We have been migrating our PBX system from Asterisk 1.8 and chan_sip to
Asterisk 13 and chan_pjsip. Things are mostly, ok, but now I have
stumbled on a behaviour difference I don't like.

With chan_pjsip when a phone went unexpectedly offline (Ethernet cable
disconnected) Asterisk would detect this quickly (through the 'qualify'
pings), mark the phone as 'Unavailable' and fail immediately with
'CHANUNAVAIL' when dialling this phone.

With Asterisk 13 and chan_pjsip qualify still works for determining
current phone availability (endpoint shown as 'Unavailable' shortly
after disconnecting the cable), but the phone is being dialled like
nothing is wrong – Asterisk sends the INVITE and waits for the response,
until SIP timeout (a bit more than 30s total). That is much longer time
until 'CHANUNAVAIL' than I expect. It is also longer than the dial
timeout in some cases, so I would get 'NOANSWER' instead of
'CHANUNAVAIL' which breaks my dialplan logic.

Is that that the expected behaviour, a bug or a configuration problem?
Am I supposed to check for device availability in my dialplan?

Greets,
Jacek

--
_
-- 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








--
_
-- 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

Re: [asterisk-users] chan_pjsip ignoring endpoint device state (qualify) on dial

[Jacek Konieczny]

On 2016-08-09 10:06, Faheem Muhammad wrote:

Jacek,
This might be a bug or configuration issue, but you need to understand
the SIP Session Timers. With Session Timers you can control the round
trip time and Call Setup time of SIP Requests.


I don't think you really mean SIP Session Timers 
(https://tools.ietf.org/html/rfc4028) these do not affect RTT or call 
setup, but provide kind of 'keepalive' and session expiration for 
established calls.



In case of GSM Network with high delay you need to set the T1 timer a
higher value like 1000ms (500 ms default). Similarly you can reduce the
Call setup time by configuring 'T2' upto you choice as per you telephony
network. Configure t1min, timert1 and timerb according to your network.
Also set session-type=uas.


Yes, tweaking the T1 and T2 timers may work for me. I'll try that, 
though the old 'qualify' magic with chan_sip was quite convenient. I 
wonder why it doesn't work with chan_pjsip.


Jacek

--
_
-- 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

Re: [asterisk-users] chan_pjsip ignoring endpoint device state (qualify) on dial

[Faheem Muhammad]

Jacek,
This might be a bug or configuration issue, but you need to understand the
SIP Session Timers. With Session Timers you can control the round trip time
and Call Setup time of SIP Requests.
In case of GSM Network with high delay you need to set the T1 timer a
higher value like 1000ms (500 ms default). Similarly you can reduce the
Call setup time by configuring 'T2' upto you choice as per you telephony
network. Configure t1min, timert1 and timerb according to your network.
Also set session-type=uas.


Regards,
Muhammad Faheem

On Tue, Aug 9, 2016 at 12:03 PM, Jacek Konieczny  wrote:

> Hi,
>
> We have been migrating our PBX system from Asterisk 1.8 and chan_sip to
> Asterisk 13 and chan_pjsip. Things are mostly, ok, but now I have
> stumbled on a behaviour difference I don't like.
>
> With chan_pjsip when a phone went unexpectedly offline (Ethernet cable
> disconnected) Asterisk would detect this quickly (through the 'qualify'
> pings), mark the phone as 'Unavailable' and fail immediately with
> 'CHANUNAVAIL' when dialling this phone.
>
> With Asterisk 13 and chan_pjsip qualify still works for determining
> current phone availability (endpoint shown as 'Unavailable' shortly
> after disconnecting the cable), but the phone is being dialled like
> nothing is wrong – Asterisk sends the INVITE and waits for the response,
> until SIP timeout (a bit more than 30s total). That is much longer time
> until 'CHANUNAVAIL' than I expect. It is also longer than the dial
> timeout in some cases, so I would get 'NOANSWER' instead of
> 'CHANUNAVAIL' which breaks my dialplan logic.
>
> Is that that the expected behaviour, a bug or a configuration problem?
> Am I supposed to check for device availability in my dialplan?
>
> Greets,
> Jacek
>
> --
> _
> -- 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
-- 
_
-- 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

[asterisk-users] chan_pjsip ignoring endpoint device state (qualify) on dial

[Jacek Konieczny]

Hi,

We have been migrating our PBX system from Asterisk 1.8 and chan_sip to
Asterisk 13 and chan_pjsip. Things are mostly, ok, but now I have
stumbled on a behaviour difference I don't like.

With chan_pjsip when a phone went unexpectedly offline (Ethernet cable
disconnected) Asterisk would detect this quickly (through the 'qualify'
pings), mark the phone as 'Unavailable' and fail immediately with
'CHANUNAVAIL' when dialling this phone.

With Asterisk 13 and chan_pjsip qualify still works for determining
current phone availability (endpoint shown as 'Unavailable' shortly
after disconnecting the cable), but the phone is being dialled like
nothing is wrong – Asterisk sends the INVITE and waits for the response,
until SIP timeout (a bit more than 30s total). That is much longer time
until 'CHANUNAVAIL' than I expect. It is also longer than the dial
timeout in some cases, so I would get 'NOANSWER' instead of
'CHANUNAVAIL' which breaks my dialplan logic.

Is that that the expected behaviour, a bug or a configuration problem?
Am I supposed to check for device availability in my dialplan?

Greets,
Jacek

--
_
-- 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