[asterisk-users] Reproducible ReInvites sent by UAS after exactly 900s despite session-timers=refuse

Michael Maier m1278468 at allmail.net
Wed Dec 28 10:36:21 CST 2016

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 just happens with one provider (German Telekom to callee at kabelbw).
> - The incoming ReInvite is answered immediately by asterisk (Status 100
>   / Status 200 - 0.02s). Media stream is ok.
> - 0.04s after sending of Status 200, the media stream from callee is
>   stopped.
> - 0.11s after the Status ok package has been sent, the Ack package of
>   the UAS can be seen.
> - 10s after the arrival of the ack package, UAS sends options packages,
>   every 10s one package. Each of these packages is immediately answered
>   by asterisk with Status 200 ok.
> - After 31s seconds, asterisk drops the call because of lack of rtp
>   stream from callee.
> Used asterisk version is 13.13.1.

Another test showed the following behavior:

- first ReInvite by UAS
- Trying by UAC
- OK SDP by UAC (0.02s after ReInvite)
- ACK by UAS (0.1s after ReInivte)

- 2 rtp packages arrived from callee, afterwards, there can be seen no
  more packages. Caller sends rtp as usual.

- second ReInvite by UAS (0.69s after first ReInivte)
  - doesn't contain the c field
  - m= audio 0 RTP/AVP 8 -> audio is stopped (why!?)
- 488 (Not acceptable here) by UAC (log entry: Insufficient information
  in SDP (c=))
- ACK by UAS

about 2s later the same ReInivte w/o c-field can be seen - procedure as
described for second ReInvite.

- about 9s after the third ReInivte procedure, 3 option packages
  arrive and are acked (200) within 0.01s.

- asterisk ends call by sending bye because of 31s missing rtp stream
  by UAS.

*                                            *
*             BIG FAT QUESTION:              *
*     Why does UAS stop the rtp stream?      *
*                                            *

> Does anybody has any idea about what's going on here? This problem isn't
> just an actual problem, it can be seen since a few weeks now and is
> *always* reproducible (I can provide a trace). I don't think there is a
> network problem, because the audio quality before is really good. There
> isn't any firewall related problem, too - there are no dropped packages
> at all.
> Thanks,
> Michael

More information about the asterisk-users mailing list