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 -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- Check out the new Asterisk community forum at: https://community.asterisk.org/ New to Asterisk? Start here: https://wiki.asterisk.org/wiki/display/AST/Getting+Started asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
