[asterisk-dev] Regarding SIP direct media (new topic)

[Brian Candler]

On Mon, Oct 16, 2006 at 03:18:20PM -0500, Kevin P. Fleming wrote:
> I believe the method mentioned in the other
> thread is the solution... send the 'direct media INVITE' to the second
> endpoint, and if it responds with a final response that indicates a bad
> codec selection (can we rely on that?) re-send it with the entire list of
> codecs and no direct media path.

As regards "can we rely on that?": I've just tested it between the Tulip
ATAs, configured for a direct call. What happens is that the destination
replies 403 Forbidden rather than 606 Not Acceptable. I guess they're
interpreting the RFC where it says:

     "If the particular UI allows for the user to reject a
      call before its answered, a 403 (Forbidden) is a good way to
      express that."

So it looks like there may be more than one result code we could see in this
situation.

Another way to think about it is: if we call a phone, offering only codecs
that it doesn't implement, and it doesn't respond with an error code, what's
the worst that could happen? I guess if it's really broken you might get:

- phone crashing
- the INVITEs being blackholed and ignored
- a bad media stream set up (non-functioning audio)

However you can always work around this by setting canreinvite=no on such
broken phones. So I don't think that's a reason not to try this approach.

If you want finer grained control, you could have a new flag to control this
two-stage INVITE, e.g. codecprobe=no. When you send an INVITE to a phone
which has codecprobe=no, you would use the old Asterisk behaviour of setting
up a two-leg call offering all possible codecs. Afterwards you could still
use re-INVITE to stitch the two legs together (as long as both legs have
canrevinite=yes and the first phone accepts the codec chosen by the second)

This would also address the needs of people who do not want to see an
INVITE-fail-INVITE exchange (e.g. because in their situation, transcoding is
the rule rather than the exception)

Enumerating, this gives four possible sets of behaviour when placing the
second leg of a SIP to SIP call:

(1) canreinvite=no, codecprobe=no

- send INVITE with SDP pointing at self and offering all codecs allowed
  by Asterisk

- always proxy media, transcoding if required (i.e. if first phone didn't
  offer codec chosen by second phone)

(2) canreinvite=yes, codecprobe=no

- send INVITE with SDP pointing at self and offering all codecs allowed
  by Asterisk

- when call is successful, if the other leg has canreinvite=yes and both
  legs are using the same codec then re-INVITE to join together
  (= Asterisk 1.2 behaviour), otherwise continue to proxy/transcode

(3) canreinvite=no, codecprobe=yes

- send INVITE with SDP pointing at self and offering only codecs which
  were in the first phone's SDP offer (minus disallowed codecs)

- if this is rejected, send a new INVITE with SDP pointing at self and
  offering all codecs allowed by Asterisk

- always proxy media, transcoding if required

(This option differs from current behaviour by making it more likely that a
common codec will be chosen end-to-end, avoiding transcoding, even though
Asterisk will always proxy the RTP packets)

(4) canreinvite=yes, codecprobe=yes

- send INVITE with SDP pointing at first phone and offering only codecs
  which were in the first phone's SDP offer (minus disallowed codecs)

- if this is rejected, send a new INVITE with SDP pointing at self and
  offering all codecs allowed by Asterisk. Proxy and transcode.

Regards,

Brian.