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

[Jonathan Rose]

On Fri, 2011-07-01 at 16:30 -0500, Mark Michelson wrote:

> As Kevin already pointed out, this is broooooooooooken. A UAC should 
> never send an ACK in response to a provisional response.

Broken as it may be, this seems to just be what the SNOM360 does.

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

The audio can come app_queue, musiconhold, sayalpha... a number of apps
which play audio files really.  Background and Playback I think were

> 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 is correct, I meant that there is media, not that the 200 OK has
been sent and the connection actually 'established' so to speak.

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

Disabling the sending of options had no effect on the call.


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

There is no SDP showing up in debug, so I assume it's not sending one,
so that makes sense.

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



Well, it's playing gsm audio files and occasionally making quips about 
[2011-07-0514:25:16] WARNING[32384]: translate.c:162 framein: no samples
for gsmtolin

In this case though, the peer has been explicitly configured to disallow
all, allow gsm.  Going on that, I'm going to say the audio is probably
gsm.

And notion about the lack of SDP causing the ringing seems to be
correct, forcing the SDP to be sent in this case does not trigger the
ringing problem on the SNOM 360.

Other noteworthy stuff... when I tested the same stuff with the Blink
softphone, there was no audio (again, with gsm forced) and when the 183
Session progress was sent with the SDP, the audio started playing on the
softphone and from that point the call wouldn't disconnect at the
regular timeout like it did before.  Blink also stayed in
'Connecting...' mode the whole time until an answer.

I guess I'll start working on making this change conditional contingent
on the stuff you suggested above.

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