The proccess signaling - SIP client vs. Asterisk


#1

Can anyone help to understand how long time the client show in the “sip show peers” after I had disconected it of the network? This is configurated or no?

Name/username             Host                                    Dyn Forcerport Comedia    ACL Port     Status      Description
4701006/Solaris           181.221.133.87                           D  Yes        Yes            47904    OK (37 ms)

#2

From the documentation:

;qualifyfreq=60                 ; Qualification: How often to check for the host to be up in seconds
				; and reported in milliseconds with sip show settings.
                                ; Set to low value if you use low timeout for NAT of UDP sessions
				; Default: 60

Although the actual time may include allowances for retries and the preceding timeout.


#3

David, and if I use qualify=no, is possible I set the timeout to the extensions?


#4

You can set the total call setup timeout, but the SIP response timeout is defined by the protocol.


#5

david551
How can I do it?


#6

https://wiki.asterisk.org/wiki/display/AST/Application_Dial


#7

This timeout is for the application Dial, the time of the call will be ringing, I need to know the timeout about the authentication entry the client and server.


#8

The flow of the call when doesn’t ring in the client destination:

Log in the cli:

  == Using SIP RTP CoS mark 5
    -- Executing [551935177554@incoming:1] Dial("SIP/buydid-1-0000003c", "SIP/4701006,60") in new stack
  == Using SIP RTP CoS mark 5
    -- Called SIP/4701006
  == Spawn extension (incoming, 551935177554, 1) exited non-zero on 'SIP/buydid-1-0000003c'
[Feb  2 13:46:35] NOTICE[20873]: chan_sip.c:28633 handle_request_register: Registration from '<sip:8009@solaristelecom.ddns.net;transport=UDP>' failed for '187.107.128.238:28216' - Wrong password
    -- Registered SIP '4701006' at 181.221.135.180:4100
ip-172-31-23-81*CLI>

The flow of the call when ring in the client destination: (This call wasn’t attended)


#9

The 32 seconds is defined by the SIP protocol, although, as explained in the documentation, it can be modified, and will adapt to the qualify measured time:

;
; -------------------------- SIP timers ----------------------------------------------------
; These timers are used primarily in INVITE transactions.
; The default for Timer T1 is 500 ms or the measured run-trip time between
; Asterisk and the device if you have qualify=yes for the device.
;
;t1min=100                      ; Minimum roundtrip time for messages to monitored hosts
                                ; Defaults to 100 ms
;timert1=500                    ; Default T1 timer
                                ; Defaults to 500 ms or the measured round-trip
                                ; time to a peer (qualify=yes).
;timerb=32000                   ; Call setup timer. If a provisional response is not received
                                ; in this amount of time, the call will autocongest
                                ; Defaults to 64*timert1

#10

david, where can I change this parameters?

thank you


#11

/etc/asterisk/sip.conf


#12

The initial question was about the time that a peer is showing to be active. This is not based on successful call setup responses or even keep-alive responses but only on successful re-registration. Suppose that a peer has registered with an expiry time of 3600 then it needs to re-register before that timer has passed and it will stay visible in the show peers for the whole 3600 secs if it does not reregister in that period - even when calls or keep alive are failing.

Personally I would prefer that the peer becomes unreachable a lot sooner in case that keep-alives fail a few consecutive times, or when the t1 call response timer expires a few consecutive times. That’s the only way to have a better real time view on the real status of the peers. The alternative is to reduce the registration timer, but that’s impacting CPU performance of the endpoint as well as the server…


#13

correction on previous post : timer1 SIP response timer - not the call setup timer - for active peer monitoring. Keep -alive is probably a better criteria.