Custom type priority when SRFLX candidates are used

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Feb 18, 2010 at 9:00 AM, Sa?l Ibarra Corretg?
<saul at ag-projects.com> wrote:
> Hi Benny,
>
> While backporting some ICE code from trunk to 1.0 branch I came across this
> piece of code from pjnath/src/pjnath/ice_strans.c:
>
> ?785 ? ? /* If default candidate for components are SRFLX one, upload a
> custom
> ?786 ? ? ?* type priority to ICE session so that SRFLX candidates will get
> ?787 ? ? ?* checked first.
> ?788 ? ? ?*/
> ?789 ? ? if (ice_st->comp[0]->default_cand >= 0 &&
> ?790 ? ? ? ? ice_st->comp[0]->cand_list[ice_st->comp[0]->default_cand].type
> ?791 ? ? ? ? ? ? == PJ_ICE_CAND_TYPE_SRFLX)
> ?792 ? ? {
> ?793 ? ? ? ? pj_ice_sess_set_prefs(ice_st->ice, srflx_pref_table);
> ?794 ? ? }
>
> I can see the priority between host candidates and server reflexive
> candidates are switched, however I can't see any reference to this in the
> draft. Is this something pjsip does for some particular reason?
>
> Also, this change seems incorrect according to section 4.1.2.1 of the draft:
>
> "The type preference for peer reflexive candidates
> ? MUST be higher than that of server reflexive candidates."
>
> because after the change server reflexive will have 126 and peer reflexive
> 110.
>
> Is this a bug or am I missing something?
>

You're right, it's violating the spec. I just fixed this in r3101
(basically swapped the SRFLX and PRFLX priority values).

Thanks
 Benny



[Index of Archives]     [Asterisk Users]     [Asterisk App Development]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [Linux API]
  Powered by Linux