[asterisk-dev] Provider requires Delay between OK and ReINVITE

[John R. Covert]

Thanks, Olle.  I definitely want to get directmedia going if possible,
and I appreciate your opinion as the main SIP developer that such a
change would be acceptable for the code base.

Thanks to Mark M as well.  I especially appreciate your opinion
that the provider's equipment is broken (that was my opinion as
well) and that developing a "directmediadelay" option might only
avoid one specific issue and set things up for future problems.

Paul, this is why I wrote to asterisk-dev, not to asterisk-users.

While I am an adamant opponent of "Answer"ing calls before a
"chargeable" event occurs, i.e. if we are going to ring a human
or other destination which might not answer or be busy (and had
already tried "Progress" before the delay with no improvement),
in the _specific_ application _immediately_ at hand, a chargeable
event will always occur (an IVR in either the main or a bridged
machine) so the "Answer" is a workaround until I have a different
application with this provider.

Based on Mark's feedback, I'm going to continue to push on the
provider for them to eventually fix their problem.  I've already
asked them to show me where in the SIP RFC a requirement for any
sort of delay appears.

Thanks to everyone.

Regards/john

------

Olle wrote:

We currently have no delay between the original call setup and
the reinvite process. It could of course be made to a
configurable option like you say and I see no reason why a patch
that does this would not be accepted (unless the code is really
bad=85 :-) )

This option could be like this:

directmediadelay  10    ; Delay from bridge setup to media optimization attempt
                        ; default=0 seconds

You can of course also disable the re-invites (direct media) in
order to be able to use the new SIP trunk, but it sounds from
your mail like this is something you want to happen.

/O

Mark Michelson wrote:

The problem here is that not all reinvites are related to direct
media.

Reinvites may happen due to a switch to T.38 or in order to
update connected line, for example. My assumption here is that
the provider in question would respond to any reinvite in the
same manner, and the problem is not limited to direct media
reinvites. In fact, it would be worth investigating whether the
same problem would occur for other in-dialog requests besides
reinvites.

Depending on the breadth of the problem, the delay may be nearly
impossible to get correct without causing problems elsewhere. In
the end though, you are working with a broken piece of equipment
if it sends an ACK for one INVITE transaction and then responds
with a 491 to a new distinct reinvite transaction.

In the meantime, I suggest trying to address this in your
dialplan.

Answer the incoming call with the Answer() application, and then
put in a small Wait() after the Answer(). I don't believe that
Asterisk will try sending any reinvites to the caller until after
the call is bridged, so your delay in the dialplan should take
care of your issue.

Mark Michelson