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

[Michael Maier]

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

Meanwhile I "solved" the problem by switching to pjsip. Using pjsip, the
behavior of session-timers is default (=active) and the session is
properly checked using UPDATE and not REINVITES (chan_sip doesn't
support UPDATE).
I could successfully verify (and see) it in both directions w/ formerly
customers of kabelbw, which now are belonging to unitymedia.

I'm not the only one facing this problem. Other Asterisk users complain
too, because it seems to be a problem w/ all of the (private!) customer
ports of unitymedia (calling from Deutsche Telekom via asterisk).



Regards,
Michael