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

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.


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

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.

I tested the exactly same call with another provider (Easybell).
Easybell doesn't support timer at all.

Via Easybell, the call is dropped after 15 minutes, too, but now, it is
ended with RTCP 203 (Good bye) by the callee. 10s later, the callee
sends a SIP bye.

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

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
>

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