[asterisk-dev] 'prematuremedia = yes' causes odd behavior on SNOM360 with early media.

[Mark Michelson]

On 07/01/2011 03:55 PM, Jonathan Rose wrote:
>
> I was tracking an issue reported by Steve Pitts against an issue which
> involves chan_sip's premature media filter which was added in a commit
> by oej some time ago, and I was looking for an opinion...  here's the
> scenario.
>
> User calls in to Asterisk from basically any SIP phone.
>
> Phone to Asterisk: INVITE
> Asterisk to Phone: 401 Unauthorized
> Phone to Asterisk: ACK
> Phone to Asterisk: INVITE (with credentials)
> Asterisk to Phone: 100 Trying
> Phone to Asterisk: ACK
>
As Kevin already pointed out, this is broooooooooooken. A UAC should 
never send an ACK in response to a provisional response.

> At this point, the call is connected and depending on the codec used, it
> will hear audio from what I can only assume is earlymedia.  The phone
> for the sake of this walk through is a SNOM360.  I've also tested this
> with Blink softphone.  The behavior at the phone end is different, but
> the SIP messages are essentially the same.
>

I'm a bit confused by this part, specifically "will hear audio from what 
I can only assume is earlymedia." Where is the audio coming from? Is it 
from something outside of Asterisk or is it something like a file 
playback in the dialplan? Can you provide the dialplan you're using when 
you call into Asterisk?

> Once the call is connected, a 183 session progress is scheduled to be
> sent to the phone once per minute due to another patch oej was involved
> with.

I assume you use the word "connected" here meaning that you're hearing 
media, not that a 200 OK has already been sent from Asterisk to the 
phone. If it is the latter, then sending a 183 on a connected dialog is 
brooooooooken.
>
> This next bit might be a little unrelated, but around 42 seconds into
> the call,
>
> At around 42 seconds, the following small conversation:
>
> Asterisk to Phone: OPTIONS
> Phone to Asterisk: 200 OK
>
> The only significance I can think of that is that the SNOM phone is
> sending a 200 OK... but again, I don't really believe this part was
> important.

You can tell for sure if this is related by disabling Asterisk from 
sending OPTIONS to the phone and seeing if the issue still occurs.

> Finally, at 60 seconds the prescheduled 183 Session Progress is sent,
> and this causes different behavior depending on the receiving device.
> In the case of the SNOM360, the phone will start generating a ring and
> will continue to do so until the call is answered.  In the case of
> Blink, nothing immediately special will happen, but a minute or two
> later (I haven't timed it), Blink will give up on the call and say it
> failed to connect.

What is in the SDP of the 183 sent from Asterisk? I suspect the SNOM is 
ringing because it interprets a 183 with no SDP to be the same as a 180, 
so it starts ringing. My assumption with Blink is that it eventually 
times the call out because it does not receive a 200 OK within a certain 
amount of time. Blink would probably give up sooner if it had not 
received a 100 Trying from Asterisk to begin with.

If the 183 has no SDP in it, then I would suspect that the solution may 
be to change the provisional keepalive to have a 183 with SDP instead of 
one without. In sip_write, in the scenario where we receive an 
AST_FRAME_VOICE prior to having sent a progress indication, you may need 
to call update_provisional_keepalive and set the "with_sdp" parameter to 
TRUE. This way the scheduled keepalive will be sent with an SDP.

Alternatively, looking at the sip.conf.sample file, it appears that 
setting prematuremedia=yes is supposed to prevent early media from 
reaching the phone without putting an explicit Progress() call in the 
dialplan. So one problem may be the fact that you're able to hear any 
early media at all in this scenario. In fact, I'd be interested to know 
what sort of media Asterisk is sending since it hasn't negotiated what 
codecs to use at this point in the call.

Also, for the record, having an option called "prematuremedia" that when 
set to "yes" prevents premature media from being sent seems incredibly 
backwards.

> If I set sip.conf to have 'prematuremedia=no', then instead of Asterisk
> sending a 100 trying and then getting an ACK, Asterisk sends a 100
> trying and a 183 Session Progress which according to what I've read,
> indicates immediately that we are in early media mode and everything
> works as expected.
>
> So anyway, I have read over some commit logs, and I'm aware that there
> are good reasons for having prematuremedia mode act the way it does and
> for it to be set by default.  I talked with David Vossel, and he seems
> to agree with my current leanings... that it isn't appropriate to send
> 183 60 seconds later if we didn't send it at the start of the call.  At
> the same time, I think we still need to warn the connected device that
> there is a need to keep the connection alive, and so I wanted to ask
> asterisk-dev if there was anyone who knew what, if anything should be
> sent in this situation.
>
> ~Jonathan Rose, still fairly newish Asterisk developer.
>
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>     http://lists.digium.com/mailman/listinfo/asterisk-dev