当前库发送的 SDP，不间断会让 Kurento 服务器崩溃❌

[Chujie-cre]

How often does this bug occurs?

often

Expected behavior

Hi ， 我又来了 Mr.TempoTian ，我在用esp32向kms服务发送sdp时经常会出现如下报错，但app端就从来不会让服务崩，我搜索了他说是客户端发送的sdp问题。
联通方面没什么问题，只要服务不崩，很快就连上了，但很多时候当向kms发送sdp时会崩溃，我根据报错，尝试把ice从sdp里删掉，毕竟也是设备去连服务，给不给ice都无所谓，但是，服务端依然会出现这个报错：

1:39:04.870470513     1 0x7f7d88001560 WARN         kmsicecandidate kmsicecandidate.c:108:kms_ice_candidate_update_values:<KmsIceCandidate@0x7f7d84014bc0> Cannot parse from 'candidate:remote1 2 UDP -43452938 192.168.66.55 54631 typ prflx'
Segmentation fault (thread 140176953157312, pid 1)
Stack trace:

表面说是ice的问题，但我ice都剔除了，还是报这个崩溃，所以我们百思不得其解，AI说的也让人摸不着头脑，这个服务器那边我也提交了issue，向您请教是什么问题导致了这样的问题。

[TempoTian]

用example code会有问题吗？感觉和Server的版本还有关系。可以打印下看完整的SDP是什么样的

[Chujie-cre]

@TempoTian hi ， 最近倒是没有了崩溃的问题，所以一直排不出来；

但是有一点我想问一下您，就是esp_peer库是否直接使用底层socket绕过网络抽象层？

我如果不使用wifi，使用ML307 4G 模块 去连接，AT命令的方式，在建立点对点连接时是否走得通？

[TempoTian]

理论上没啥差别，我换ethernet也是OK的，换netif socket相关的是不用改的

[Chujie-cre]

candidate:2007293736 1 udp 2122260223 192.168.66.23 42529 typ host generation 0 ufrag CKCi network-id 3 network-cost 10
kmsicecandidate kmsicecandidate.c:108:kms_ice_candidate_update_values:<KmsIceCandidate@0x74e018006540> Cannot parse from 'candidate:remote1 1 UDP -22316088 113.84.3.143 23413 typ prflx'
Segmentation fault (thread 128505404577472, pid 1)

Hi , @TempoTian ，这个问题又出现了，我们目前推测是，库里是不是有接收这个ice中随机生成的“-22316088”的这么一个参数，是否是 int 类型？由于很多时候kms生成的ice的这个值大于 int 类型的最大值，所以导致了后台崩溃，是否能将其改为uint_64或许能够解决？

[TempoTian]

能看到esp32生成的candidates是什么样的吗我看代码应该不会生成超过负数的
// priority = (2^24)(type preference) + (2^8)(local preference) + (256 - component ID)
candidate->priority = (1 << 24) * ice_candidate_type_preference(candidate->type) + (1 << 8) * ice_candidate_local_preference(candidate) + (256 - candidate->component);

[Chujie-cre]

长这样：

v=0
o=- 7801614086411001801 2 IN IP4 0.0.0.0
s=-
t=0 0
a=msid-semantic: esp-webrtc
a=group:BUNDLE 0
m=audio 9 UDP/TLS/RTP/SAVP 111
a=rtpmap:111 opus/48000/2
a=ssrc:6 cname:webrtc-opus
a=ssrc:6 msid:esp_stream a0
a=sendrecv
a=mid:0
a=msid:esp_stream a0
c=IN IP4 0.0.0.0
a=rtcp-mux
a=fingerprint:sha-256 8E:62:2E:0A:D6:05:44:F8:70:07:21:23:69:8D:A4:1C:38:14:A5:FC:CB:CB:04:EF:E5:BB:DB:E7:DB:10:B8:A9
a=setup:active
a=ice-ufrag:WwUl
a=ice-pwd:Pd9ZwfQgpeN3WiStdYMx5Ru0
a=candidate:0 1 UDP 2129029631 10.10.10.157 58985 typ host
a=candidate:1 1 UDP 1692822015 116.25.249.0 58985 typ srflx raddr 0.0.0.0 rport 0
a=candidate:2 1 UDP 1692822015 116.25.249.0 58985 typ srflx raddr 0.0.0.0 rport 0
a=candidate:3 1 UDP 15178751 118.145.160.189 59291 typ relay raddr 0.0.0.0 rport 0

[Chujie-cre]

我拷贝kms到本地，咨询claude他是这么说的：

[TempoTian]

可以升级server吗libnice吗？或者你改下candidate的priority字段
GPT推荐用下面的代码试试, 不过目前的代码应该逻辑是类似的

static int parse_u32(const char *s, uint32_t *out)
{
    char *end = NULL;
    errno = 0;

    unsigned long v = strtoul(s, &end, 10);
    if (errno != 0 || end == s || v > 0xFFFFFFFFUL)
        return -1;

    *out = (uint32_t)v;
    return 0;
}

static uint32_t regen_priority_from_old(uint32_t old_prio)
{
    uint32_t type_pref  = (old_prio >> 24) & 0xFF;
    uint32_t local_pref = (old_prio >> 8)  & 0xFFFF;
    uint32_t component  = old_prio & 0xFF;

    /* Clamp to safe RFC / libnice range */
    if (type_pref > 126) type_pref = 126;
    if (local_pref > 65535) local_pref = 65535;
    if (component == 0 || component > 256) component = 1;

    /* Rebuild using unsigned math only */
    return (type_pref << 24) |
           (local_pref << 8) |
           (256 - component);
}

int ice_candidate_fix_priority(char *line, size_t line_len)
{
    char *p = line;

    /* Must start with a=candidate: */
    if (strncmp(p, "a=candidate:", 12) != 0)
        return -1;

    /* Skip: a=candidate:<foundation> <component> <transport> */
    for (int i = 0; i < 3; i++) {
        p = strchr(p, ' ');
        if (!p) return -1;
        p++; /* move past space */
    }

    /* p now points to priority */
    char *prio_start = p;
    char *prio_end = strchr(prio_start, ' ');
    if (!prio_end) return -1;

    /* Parse old priority safely */
    uint32_t old_prio;
    if (parse_u32(prio_start, &old_prio) != 0)
        return -1;

    /* Regenerate priority */
    uint32_t new_prio = regen_priority_from_old(old_prio);

    /* Convert to string */
    char new_prio_str[16];
    int new_len = snprintf(new_prio_str, sizeof(new_prio_str),
                           "%u", new_prio);
    if (new_len <= 0)
        return -1;

    size_t old_len = (size_t)(prio_end - prio_start);

    /* In-place replacement */
    if (new_len <= old_len) {
        /* overwrite + shift left if shorter */
        memcpy(prio_start, new_prio_str, new_len);
        memmove(prio_start + new_len,
                prio_end,
                strlen(prio_end) + 1);
    } else {
        /* need space */
        size_t tail_len = strlen(prio_end) + 1;
        if ((prio_start - line) + new_len + tail_len > line_len)
            return -1; /* not enough buffer */

        memmove(prio_start + new_len,
                prio_end,
                tail_len);
        memcpy(prio_start, new_prio_str, new_len);
    }

    return 0;
}

[Chujie-cre]

改了依然不行，还是会有负数的报错
升级了后端的那个库后一直打包失败，他们就没有继续

不过我跟后端试了把它发给我的大于2131000000的ice候选给屏蔽掉，效果就好了很多，连接成功率也上升了，很大概率是esp32只接受32位的数据，超过就会返回后端一个负数值？我们一致认为应该把这个32位改成64位，这样连接才稳定

[TempoTian]

正常应该是ESP32 send sdp, server answer sdp吧。目前sdp的内容都是直接生成的，不会参考对端的priority的设定。并且从log看也不会大于32变为负值。目前支持的三种是local, srflex, relay。
prflx是server自己构造的一个candidate，应该构造的时候出现负值了。

[Chujie-cre]

不可能呐，如果是这样，那app连接时也肯定会出现这种状况，可是app连接从来没有出现过这种情况，只有esp32才会

[TempoTian]

有crash匹配的log吗可以发下看，看生成的里面有没有负数

[Chujie-cre]

就是上面那个，后台日志报

esp32日志只有报连接失败

[TempoTian]

这个就比较尴尬了如果SDP没有负数的话那么肯定是server端计算出错了才会产出负数，不行把esp32 sdp里面的priority都右移2位看看