[asterisk-dev] chan_sip allowing early media in error? (bug, possible fix)

[Steve Davies]

Hi,

As with most of my stuff, I have found this in 1.6.x but have checked
the trunk source, and it behaves the same. I will attach a patch
against trunk for your consideration. If you think this has legs I
will upload/disclaim the patch, so please feed-back if you want me to
do that.

We run chan_sip with:
    prematuremedia=yes     (Prevent "183 Progress" being sent even if
media is detected)
    progressinband=never    (Always send "180 ringing")
This is because we have cases where the early-media is present but
silent, or a 183 is sent down a legacy trunk when there is no early
media to play. It is more reliable to have the "known situation" where
early media is ignored, and 180 is sent for ringing.

With the above, there should be NO early media in the SIP stream, but
tcpdump tells us otherwise. The 2 cases I have where media is
incorrectly sent early are:

1) The dialplan has a Wait(1) in it - This generates 1 second of
silent RTP before the 180 or 183 have been sent.
2) An ISDN line provides early media - The media is forwarded to the
RTP stream even though the 183 has been blocked by prematuremedia.

Until recently, this has not been an issue, but we now have 2 buggy
devices where the "early media with no 183" combination causes a
headache. One device goes silent, and one of them plays both ring
indications simultaneously.

I patched it in Asterisk as per the attached patch by modifying
sip_write so that any AUDIO/VIDEO/TEXT frames that arrive before we
are advanced enough in the call will not be sent onward. Basically, if
we are beyond the EARLY_MEDIA stage, definitely pass frames, and if we
are in EARLY_MEDIA, pass it if prematuremedia or progressinband
settings do not disallow it.

Does this make sense? Thoughts on what it might break?

Thanks,
Steve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sip_early_media.patch
Type: application/octet-stream
Size: 2033 bytes
Desc: not available
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20120418/a77168e5/attachment.obj>