1:1 audio call drops with T103 ~10s after answer despite established SRTP media

[botnick]

Summary

A 1:1 audio call placed with PlanetTransport connects and audio reaches the callee, but LINE ends the call with error T103 roughly 10 seconds after the peer answers. Reproducible on main.

Environment

• linejs main, Deno 2.9
• Android primary auth token, device: "ANDROID"
• 1:1 AUDIO call; callee answering on a mobile (iOS) LINE client

What works

• client.call.acquireRoute({ to, callType: "AUDIO" }) returns a valid CallRoute (fakeCall: false)
• connect() → inviteDetailed() (ringing) → waitForAnswerDetailed({ autoConnRsp: true })
• conn_req is parsed, mediaReady: true, SRTP send/recv contexts are established
• Streaming Opus (48 kHz mono, 20 ms frames, 0x00 payload prefix, timestampStep: 960) with mediaKeyMode: "audio-reverse-stage" — the callee hears the audio, and inbound peer media packets are received and decrypted (2-way at the packet level)

Problem

~10 s after answer, the callee's client shows T103 and the call ends, even though RTP keeps being sent.

Findings during investigation

1. No RTCP is emitted on the 1:1 path. buildRtcpCompound() (rtcp.ts) has no call sites; RTCP is only sent for group calls (#sendGroupRtcpFeedback, gated on #groupJoined). Wiring in a periodic 1:1 RTCP sender report (plaintext, mirroring the group feedback send) did not prevent T103.
2. After conn_req, the relay emits a rapid stream (~100+/s) of Cassini cc messages whose bodyTag is not present in CC_MSG; they surface as planet_msg cc:"" ccTag:0. linejs does not respond to them. The ~10 s T103 timeout is consistent with the relay waiting on a response that is never sent.
3. Non-mobile callee: when the peer answers on a desktop (Windows) LINE client, conn_req.answer is ~248 bytes and decodeNativeSetupOffer produces no keying, so mediaReady stays false. A mobile (iOS, ~275-byte answer) yields mediaReady: true.

Question

Which mid-call Cassini cc message (the unmapped flood that follows conn_req) must be answered to keep a 1:1 call alive past ~10 s and avoid T103? Decoded captures of the unmapped messages can be provided.

[botnick]

Decoded structure of the unmapped mid-call cc flood (finding #2), in case it helps locate the message that must be answered.

After conn_req + our conn_rsp, the relay streams two message shapes on the media/control channel. Both decrypt fine (decrypt_ok) but both surface as planet_msg cc:"" ccTag:0 — their bodyTag isn't in CC_MSG, so linejs never routes them and never replies. The call is torn down ~10 s later (T103).

Shape A — ~100+/s, ~521 B decrypted

Outer frame plain_shape outer:[{tag:3, len:518}]; the cc body decodes as:

cc = {
  1: 16,                       // varint — constant (message type / id 0x10?)
  2: 160723908720035866,       // varint u64 — monotonic, +~10000 per message (~8 ms apart)
  3: 300,                      // varint — constant
  4: <~500-byte blob>          // length-delimited body
}

Field 2 is monotonically increasing across the stream; fields 1 and 3 are constant.

Shape B — periodic, 332 B decrypted

raw_plain head 12c902 0800 10f403 1810 2010 2a12 0880aefcf8dedb3010ccf3ecefb1b1c09d02 2a12 0880a689f9dedb3010d3d6edefb1… decodes as a single field-2 struct (329 B):

{
  1: 0,
  2: 500,                      // octet count?
  3: 16,                       // packet count?
  4: 16,
  5: [ {1:<u64 ts>, 2:<u64 ts>}, {1:<u64 ts>, 2:<u64 ts>}, … ]   // repeated NTP/RTP-like timestamp pairs
}

Shape B looks like a media-statistics / RTCP-equivalent report (counters + timestamp pairs) that the peer expects mirrored or acknowledged.

bodyTag 16 (0x10) is the key unknown — it isn't in CC_MSG (which maps SETUP_REQ / CONN_REQ=5 / INFO_REQ / REL_REQ …). If that maps to a mid-call keepalive / media-status request that needs a response, not answering it is the most likely T103 cause. Happy to attach full raw captures if useful.

[EdamAme-x]

interesting
can you send that captures?

[botnick]

Thanks. I instrumented the release path and got a much cleaner capture — proactive 1:1 AUDIO call, initiator = main/v3.1.5, responder answering on mobile. The picture turned out different from my first guess, so I'll correct the earlier findings too.

The actual release

The responder sends rel_req repeatedly, starting ~10 s after it answers:

rel_req  relCode=511  relPhrase="CONN_REQ_FAIL.timeout"  releaser="responder"

Timeline (t = s from process start, answer at ~t+37):

+36.9  conn_req             (responder answers)
+36.9  media_configured     endpoint="route"  port=28870  pt=96  ssrc=202
+37.4  conn_req   -> conn_rsp_duplicate
+38.4  conn_req   -> conn_rsp_duplicate
+40.4  conn_req   -> conn_rsp_duplicate
+42.4  conn_req   -> conn_rsp_duplicate
+44.4  conn_req   -> conn_rsp_duplicate
+46.4  conn_req   -> conn_rsp_duplicate
+47.0  rel_req    relCode=511  CONN_REQ_FAIL.timeout  releaser="responder"

The responder re-issues conn_req every ~1–2 s. linejs answers each one (waitForAnswerDetailed({ autoConnRsp: true }) + #sendDuplicateConnRsp), but the responder never considers the connection established and eventually times out its own conn_req → CONN_REQ_FAIL.timeout (511). Audio is audible on the callee during that ~10 s window, so SRTP send keying is correct — this is purely the control-plane conn handshake not completing from the responder's side.

Corrections to my earlier comment

• Keepalive is not the cause. The 1:1 setup_rsp returns aliveRptInterval=30, so #startKeepalive does start. I also forced a 1 s keepalive (keepaliveIntervalMs) as a test: the initiator socket then stays up indefinitely, but the responder still releases with 511 at ~10 s. Retracting the RTCP/keepalive angle.
• The "unmapped cc flood" (Shape A) is inbound media, not a control message. cc = {1:16, 2:<monotonic u64>, 3:300, 4:<~500 B>} at ~100/s is the peer's audio on the route/relay path; it stops the instant the responder releases and needs no reply. Retracting finding Create LICENSE #2.

Likely real cause: the peer media endpoint is never learned

media_configured reports endpoint="route", i.e. both addrEndpoint(connReq.mAddr) and addrEndpoint(connReq.uePublicAddr) returned undefined, so #configureMedia fell back to the relay (route.mediaHost / cscfHost). linejs then sends RTP to the relay, never to the responder's advertised endpoint.

My read: the responder's conn_req is an ICE-style connectivity check that only completes once it sees our media/response arrive at the endpoint it advertised. Since we never send there, its check keeps failing and it re-issues conn_req until the ~10 s timeout. Consistent secondary symptom: 13× SRTP auth tag mismatch on inbound rtpPayloadType=98 (the responder's stream), so recv keying for that stream is off as well.

The conn_req envelope decodes as cc:[{1,len 54},{2,len 311}], body [{2,len 308}]. I can decode the inner 308 B and post the mAddr / uePublicAddr / media-field layout — that looks like where endpoint extraction is silently returning undefined, and probably the fix point.

One question so I chase the right thing: for a 1:1 call, is the initiator expected to send its own conn_req to the responder's endpoint (bidirectional connectivity check), or is answering the responder's conn_req with conn_rsp at the correct media endpoint sufficient? That decides whether the fix is endpoint extraction in #configureMedia or an additional outbound conn_req.

[botnick]

Full captures. Setup: proactive 1:1 AUDIO call, initiator = linejs main/v3.1.5 (Android token), responder = iOS. On the responder the call ends with the dialog "Unable to connect call. Please try calling back or wait for the other person to call you. (T103)" — the user-facing form of the relCode=511 CONN_REQ_FAIL.timeout release the responder emits.

1. acquireCallRoute response — control plane, /V4, from a real-app mitm capture

CallRoute field map, secrets redacted:

{
  "1  fromToken":         "H339rxDxxQ",
  "2  callFlowType":      2,
  "3  voipAddress":       "147.92.169.99,147.92.169.35",
  "4  voipUdpPort":       26937,
  "5  voipTcpPort":       10003,
  "6  fromZone":          "sgv",
  "7  toZone":            "sgv",
  "8  fakeCall":          false,
  "9  ringbackTone":      "<token>",
  "12 commParam":         { "mpkey": "<redacted>", "ict": 6000, "uv6b": 4, "ctm": 3000 },
  "13 stid":              { "toIpv6Allowed": false, "fromCs": "LGC", "toCs": "LGC",
                            "fromGcallZone": "sgv", "toGcallZone": "sgv", "caps": [] },
  "16 switchableToVideo": true,
  "18 w2pGw":             "wtp-sg.line-apps.com:12000",
  "19 drCall":            false,
  "20 stnpk":             "<P-256 SPKI, 88 b64 chars>",
  "21 capabilities":      []
}

linejs parses all of these (fakeCall=false, voipAddress/voipUdpPort, commParam, stnpk), so route acquisition itself is fine.

2. Responder conn_req — Cassini, decoded on the initiator

cc bodyTag=5, 435 B. Field inventory:

1  answer        275 B   NativeSetupOffer (usable — mediaReady=true)
2  mChanId       varint
3  netType       1
4  unavailToSec  120
5  oCapas        [1, 2, 3, 6, 7]
8  features      3 x 6 B
9  ua            101 B
10 rCountry      "TH"
51 reqRec        0

There is no field 101 (mAddr) and no field 103 (uePublicAddr) — the responder advertises no media endpoint in conn_req. So #configureMedia's addrEndpoint(connReq.mAddr) ?? addrEndpoint(connReq.uePublicAddr) ?? route always resolves to route (media_configured endpoint="route"), and RTP is sent to the relay (voipAddress:voipUdpPort). Audio does reach the callee that way, so that path works.

3. Timeline (answer at ~t+5s)

+5.0  conn_req (bodyTag5, 435 B) -> media_configured endpoint=route
                                 -> conn_rsp + info_req(exchange_app_str_data)
+5..  conn_req -> conn_rsp_duplicate     (responder re-sends conn_req every ~1-2 s, x6)
+15   rel_req  relCode=511  "CONN_REQ_FAIL.timeout"  releaser="responder"   (repeats until close)

Two inbound RTP streams during the ~10 s window:

• pt=96 ssrc=102 — Opus, decrypts fine (~44 pkts; the audible audio).
• pt=98 ssrc=122, 32-byte packets — fails SRTP auth (auth tag mismatch, x13); the recv key for this second stream is wrong.

Where it's stuck + questions

The responder keeps re-issuing conn_req, never accepts our conn_rsp, and times out its own conn_req (511) ~10 s after answering. #sendConnRsp returns result:0 but does not populate mAddr/uePublicAddr (fields 101/102 exist in CcConnRsp / packCcConnRsp but are left unset).

1. For a 1:1 relay call, what makes the responder treat its conn_req as satisfied — does the initiator's conn_rsp need to carry the initiator's own mAddr/uePublicAddr, or is the initiator expected to send its own conn_req toward the responder?
2. What is the pt=98 / ssrc=122 second inbound stream (SRTCP? a separate media stream?), and which key derivation should decrypt it?

Full conn_req hex and the 275-byte NativeSetupOffer answer are available if they'd help.

[botnick]

Decoded the 275-byte answer (responder NativeSetupOffer) inside conn_req — this resolves the pt=98 question and rules a few things out.

The offer carries three media streams:

A (audio):  rtpId=96,  rtpPort=102,  rtcpId=202
V (video):  rtpId=97,  rtpPort=112,  rtcpId=212
D (data):   rtpId=98,  rtpPort=122,  rtcpId=222

plus the media keying (P-256 mediaPubKey + keyId + 16-byte nonce), which is why audio SRTP is fine and mediaReady=true.

So the earlier pt=98 / ssrc=122 inbound that fails SRTP auth is the data stream — linejs derives the recv context with the audio keying and never sets up a derivePlanetMediaStreamKeying(secret, "DATA") recv context for it, so those packets fail auth. Probably harmless on its own, but it means the data channel is unhandled.

There is no IP/port anywhere in conn_req (only payload-type/rtpPort refs, no address). That confirms the relay model — endpoint is voipAddress:voipUdpPort from acquireCallRoute for both sides — so the endpoint="route" fallback is correct, not a bug.

Net: route, keying, endpoint, and audio all check out. The only unexplained piece is that the responder never treats its conn_req as satisfied by our conn_rsp (which is result:0, no mAddr/uePublicAddr), re-sends every ~1–2 s, and releases with 511 CONN_REQ_FAIL.timeout at ~10 s. That narrows it to the conn_req/conn_rsp handshake acknowledgement itself — happy to run any specific probe on the initiator you'd like.

[botnick]

Update — a few more things ruled out, so the failure is narrower than "conn_rsp missing something".

conn_rsp is correctly addressed. Decoding the cc headers of the responder's conn_req and our conn_rsp:

conn_req.hdr:  srcChanId = R   dstChanId = L   cid = <call uuid>
our srcChanId (from SETUP):    = L            → conn_req.dstChanId == our srcChanId  ✓
conn_rsp.hdr:  srcChanId = L   dstChanId = R                                          ✓ (correct swap)

So the responder addresses our channel correctly and our conn_rsp is targeted back at the responder's channel correctly — this isn't a channel-id / correlation mismatch, and the conn_rsp does reach the relay (SETUP over the same cscf path succeeds).

Tried and did not change anything (still 511 CONN_REQ_FAIL.timeout at ~10 s, releaser responder):

• Populating conn_rsp.mAddr + uePublicAddr with our media relay endpoint (voipAddress:voipUdpPort).
• Forcing a 1 s SC keepalive (keepaliveIntervalMs) — setup_rsp.aliveRptInterval=30 already starts it anyway.

So: conn_rsp is result:0, correctly addressed, reaches the relay, audio is flowing both ways — and the responder still tears its own conn_req down at ~10 s. That points at a follow-up the initiator owes after conn_rsp that I'm not sending, rather than a bad conn_rsp.

Concretely, after answer linejs does: conn_rsp → info_req(exchange_app_str_data), then only answers the responder's repeated conn_req with duplicate conn_rsp. It never emits its own conn_req, and I don't handle any info_rsp/second info exchange from the responder.

Questions:

1. After the responder's conn_req, does the initiator have to send its own conn_req (bidirectional connect), or reach a specific state via the exchange_app_str_data info exchange, before the responder considers the connection up?
2. Is there an expected info_rsp / ack from the responder that must be observed (or a conn confirmation the initiator must send) to stop the responder's conn_req retransmits?

I have conn_req / conn_rsp / info_req raw bytes for a full failed call and can run any specific initiator-side change you want tested against a live device.

[botnick]

Got the real app's working call-OUT on the wire (Frida on sendto/recvmsg, device drove the call). The app placed the same 1:1 AUDIO call to the same peer and it stayed up 3m52s with no T103, so this is a clean initiator-vs-initiator diff against linejs.

Relay = a single 147.92.169.x:port. Transport frames only (bodies are AES-128-CTR, not shown). The app's Cassini control frames (first wire byte d0/d1), by time / frame-seq / wire-len:

setup:      dbab..0602  943   (SETUP, bootstrap)
rsp:    RX  da..0602    548
probes:     d219 x16    541   (pinhole probes = packPinholeProbe {1:KIND=16,2:id,3:MTU=300,4:~500B})
            d01c0410     32
            d0820411    134
-- answer --
conn:       d11f0412    291
            d11e0413    290
            d1530414    343
            d0d80415    220
            d0b50416    185
            d0820417    134
            d1010418    261
periodic:   d0820419    134   (~every 10-15 s: 0419, 041d, 041e, 041f ...)
            d114041a    280
            d0d6041b    218

So after the peer answers, the initiator app emits ~7 distinct control frames (291/290/343/220/185/134/261 B) plus a recurring 134-B frame every ~10–15 s. linejs's initiator path emits only conn_rsp + one info_req(exchange_app_str_data) and then just re-conn_rsps the responder's retransmits — which is exactly when the responder gives up with 511 CONN_REQ_FAIL.timeout.

That strongly suggests the responder is waiting on one (or more) of those post-answer initiator frames that linejs never sends. Two specific questions:

1. What are the initiator's post-conn_req control frames in a 1:1 call — is conn_rsp alone insufficient, and does the initiator additionally send e.g. its own conn_req, an mc_data/media-session frame, a big_data/info exchange, and a periodic alive_rpt?
2. The recurring ~134-B frame every ~10–15 s — is that alive_rpt (CC 22)? linejs currently sends only the SC-layer keepalive, never a CC alive_rpt.

I can hook the native AES-CTR to dump the plaintext of these frames if that's the fastest way to label them — but if you already know the expected initiator sequence, that would save the native dig.

[botnick]

Answering my own questions — I hooked the app's native pln_cassini_* / pln_bepi_* send functions (Frida on libandromeda.so, which has a full symbol table via Module.enumerateSymbols()) and logged the initiator's send sequence for a working 1:1 call:

send_setup
send_ibd x17                       (pinhole probes)
-- peer answers --
send_conn_rsp
send_info                          (exchange_app_str_data)
bepi_channel_send_data_rsp         <-- responds to a peer bepi DATA_REQ
send_info_rsp                      <-- responds to a peer INFO_REQ
-- media channel comes up --
bepi_channel_open
bepi_channel_send_join_rsp         <-- responds to a peer bepi JOIN_REQ
bepi_channel_send_check_rpt
bepi_channel_send_change_rsp       <-- responds to a peer bepi CHANGE_REQ

Two useful conclusions:

1. The initiator does NOT send its own conn_req. pln_cassini_send_conn is never called on this path — only send_conn_rsp. So "the initiator must also emit conn_req" is wrong; please disregard that earlier guess.

2. The missing piece is the BEPI (media) channel handshake. After answer the peer drives a bepi exchange — data_req, join_req, change_req — and the app answers each (bepi_channel_send_data_rsp / send_join_rsp / send_change_rsp) and calls pln_bepi_channel_open. linejs decodes none of these; they show up as the "unmapped cc" frames and go unanswered, so the peer's media/bepi channel never opens and its conn_req times out → 511 CONN_REQ_FAIL.timeout.

So the fix looks like: decode the peer's bepi join_req / data_req / change_req and reply with the matching *_rsp, plus open the bepi channel — rather than anything at the conn layer. Does linejs have the bepi channel message schemas anywhere, or is that the part that's unimplemented for 1:1? I can hook pln_bepi_channel_send_join_rsp etc. to dump the exact rsp payloads if that helps define them.

(Separately, a real bug I hit while testing: ccMsgId(CC_MSG.CONN_REQ) falls through to CASSINI_MSG_ID_CC_BASE + 5 = 0x2145, which is REL_REQ's id — so any conn_req linejs sends is interpreted as a release. It should be 0x2144, paired with CONN_RSP 0x2244.)

[botnick]

Got the full plaintext of a working 1:1 call by correlating each ear_crypto_aes_ctr_do frame with the pln_*_send_* that produced it (per-thread last-send label). So each frame is now labelled + decoded. The post-answer initiator frames and their Cassini message ids:

pln_cassini_send_conn_rsp      msgId 0x2244   CONN_RSP
pln_cassini_send_info          msgId 0x2147   INFO   (exchange_app_str_data {"csv":1})
pln_cassini_send_info_rsp      msgId 0x2247   INFO_RSP
pln_bepi_channel_send_data_rsp msgId 0x3289   (= MC_DATA_RSP, already in linejs)
pln_bepi_channel_open          msgId 0x1102
pln_bepi_channel_send_join_rsp msgId 0x3285
pln_bepi_channel_send_change_rsp msgId 0x3286
pln_bepi_channel_send_check_rpt  msgId 0x328x

So the "BEPI channel" is the MC (media-control) layer: the req/rsp pairs are 0x318x/0x328x — join 0x3185/0x3285, change 0x3186/0x3286, data 0x3189/0x3289. linejs already answers MC_DATA_REQ (0x3189) → MC_DATA_RSP (0x3289), but has nothing for join_req (0x3185) or change_req (0x3186), and never sends bepi_channel_open (0x1102).

Decoded structures (ids/mids redacted):

conn_rsp body (0x2244, wrapCcMsg(CONN_RSP)):

{ 1:0 result, 4:<mChanId>, 5:1 netType, 6:120 unavailToSec,
  7: UA{ "Android","36","A142", <ver>, <ver>, "Nothing" } }

Note conn_rsp.mChanId (field 4) equals the srcChanId used in the cc header of every following MC frame — the app keeps them identical. linejs sets conn_rsp.mChanId = #localMediaChanId but sends the message with cc-header srcChanId = #srcChanId (a different value), and its later MC frames use #localMediaChanId — so the peer can't tie them together.

mc_data_rsp / join_rsp / change_rsp sit in the planet mc slot (field 4):

mc = { 1: mcHdr{ cid, srcChanId=<mChanId>, dstChanId }, 2: body{ 17: {...stream spec...} } }

bepi_channel_open (0x1102, tiny, sc slot): {2:{3:{1:<fixed64 token>}}}.

My read: after conn_rsp the peer starts the MC handshake (data_req, then join_req/change_req) — but only once the initiator's conn_rsp.mChanId and cc-header channel ids are self-consistent. Because linejs's aren't, the peer never opens the MC channel and its conn_req times out (511). The fix looks like: (a) make conn_rsp advertise mChanId == the srcChanId linejs actually uses for MC, and (b) answer join_req (0x3185) / change_req (0x3186) with the 0x3285/0x3286 responses + send bepi_channel_open (0x1102).

Full decoded frames available if useful. Is the MC join/change handshake something linejs has schemas for, or unimplemented for 1:1?

[botnick]

Closing the loop on where the 1:1 initiator path diverges from the native app, after a full structural comparison of decrypted frames (app plaintext via a Frida tap on ear_crypto_aes_ctr_do, linejs via its own packers):

Everything structural matches. Field-for-field, linejs's setup_req, media offer (A/V/D, packOfferCodec incl. the constant field2=3, packOfferPath), and conn_rsp are identical to the app's. So this isn't a missing/extra field.

The responder never opens the media dialog with linejs. In a failing linejs call the only inbound cc/mc is: setup_rsp, conn_req (retransmitted ~6×), rel_req (511), pinhole probes, and one SC media-stats report. The responder sends no MC_DATA_REQ / join_req / info_req at all — whereas against the app it drives that whole exchange. So the responder decides up front not to negotiate media with linejs, from something that isn't in the message structure.

One concrete asymmetry that points at keying: the responder's second media stream (pt=98, the D/data channel) arrives and fails SRTP auth on linejs (auth tag mismatch, ~13×), even though the audio (pt=96) decrypts and is audible. So linejs's send SRTP is right (callee hears audio) but its recv context for the data stream is wrong. If the responder gates "start media negotiation" on the initiator having a working bidirectional (incl. data-channel) key, a bad data-stream key derivation on linejs's side would explain why it never proceeds and times out conn_req (511).

linejs only derives/sends the D data-channel SRTP for group calls (#groupDataSrtpSend / #sendGroupDataRtpControl are gated on #groupJoined); for 1:1 it's never set up, and the recv side can't key pt=98. The app does run the data channel in 1:1.

Question: for 1:1, does the responder require the initiator's data-channel (pt=98) SRTP to be established (send+recv) before it opens the MC join/data handshake — i.e. is the fix to derive derivePlanetMediaStreamKeying(secret,"DATA") send+recv contexts and run the data channel for 1:1, not just group? That's the one place linejs's 1:1 media differs from the capture.

Happy to dump the app's key-derivation (ear_crypto_hkdf) labels for the data/recv streams if that pins it down.

[botnick]

cant call 1:1