Daniel Pocock wrote:
On 01/04/13 22:06, Joshua Colp wrote:
Daniel Pocock wrote:
Thanks for the fast reply. I agree backporting full support for AVPF
would not be justified for many use cases (including my own). What I
was more curious about is whether the F can be tolerated (in other
words, ignored or silently removed), as described here:
From a code perspective, it could. Still not something I would be
comfortable with putting in Asterisk 1.8.
http://www.ietf.org/mail-archive/web/rtcweb/current/msg01145.html
"1) RTCWEB end-point will always signal AVPF or SAVPF. I signalling
gateway to legacy will change that by removing the F to AVP or SAVP."
and whether such behavior is possible even without setting avpf=yes on a
per-peer basis?
This is fine for incoming but what about outgoing to a device?
Excellent question... I've seen one of my Polycom devices reboot itself
each time it receives a raw SDP from WebRTC, so if such a hack is
implemented, I'd guess that stripping the F is better than ignoring it.
Asterisk doesn't forward SDP through, each leg is completely
independent. Without configurability of avpf then if you call a device
you have to either not offer it, offer it only, or offer both. Doing
both will probably make many devices unhappy, as you have mentioned. So
to have stuff really be functional you have to backport AVPF.
Cheers,
--
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: www.digium.com & www.asterisk.org
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
http://www.asterisk.org/hello
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
