https://livekit.io logo
Join Slack
Powered by
sometimes livekit saves the s3 file path with %2B ...
# ask-ai
r
sometimes livekit saves the s3 file path with %2B instead of the + sign, which breaks our logic with retrieving them, cause we store in the room name the phone number. I It’s quite sporadic and it only happens for maybe 3% of our conversations. Why?
t
Thanks for reaching out, luisa. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.
Thanks — I’m sorry this is disrupting your retrieval logic. I’m responding to your report that about 3% of S3 file paths save with "%2B" instead of "+" and that breaks your room-name=phone-number lookup. I don’t have a confirmed root cause yet. To investigate, please provide the following so I can pinpoint whether LiveKit or something else is URL-encoding the plus sign: 1. One or two redacted examples showing: ◦ The manifest/webhook field value (if from a webhook) and ◦ The corresponding S3 object key as shown in the S3 console/listing. 1. Tell me where you see the encoded value: in LiveKit webhook fields (e.g., 
egress_ended
/ 
manifestLocation
), in the backup manifest, in the S3 bucket listing, or in presigned URLs you generate. 2. How you create room names: do you pass the phone number with the 
+
directly (e.g., 
+12125551234
), or do you apply any encoding/normalization before calling LiveKit? If possible, paste the API call or code snippet you use to create the room (redact secrets). 3. Which LiveKit flow produced the files (egress recordings, backup egress, SIP dispatch), and whether backup egress is enabled. 4. Any patterns you’ve noticed for the ~3% (specific phone formats, SDK/server versions, regions, timestamps). 5. If available, a webhook payload or S3 PutObject/Access log for a recorded occurrence (timestamps help correlate). With those items I’ll check whether the encoding comes from: • LiveKit webhook/manifest URLs (which may contain percent-encoding in URL contexts), • S3 object key handling or listings, • presigned URLs or intermediate proxies, or • your room-creation code. Send one redacted example (webhook manifest + S3 listing) and the room-creation snippet and I’ll analyze it and recommend a fix or a robust workaround (e.g., normalizing when reading keys or using a deterministic mapping instead of raw room names). Sources: Security Overview | LiveKit | Backup Egress Recordings, with interactive elements
r
Outbound: E.164 with the literal 
+
in the room name — e.g. 
outbound-call-_+12125551234_abc123def0
. Only normalization is 
.strip()
and prepend 
+
if missing. No URL encoding or other transforms. Inbound: LiveKit SIP sets the name (same idea: 
+
in the string between underscores). phone-api doesn’t build tho
the egress recording produces it when saving it into the database
t
Thanks — this is helpful. I’m responding about the egress recordings sometimes saving the room name with 
%2B
instead of 
+
. Quick clarification so I can pinpoint the cause: 1. Where exactly do you observe 
%2B
? (pick one) ◦ In the DB field your system writes from the egress webhook/manifest ◦ In the webhook/manifest payload itself (attach a redacted example) ◦ In the S3 object key as listed in the S3 console ◦ In a presigned URL 1. Please paste one redacted example of: ◦ The webhook/manifest value you receive (or the DB value saved), and ◦ The exact S3 object key or S3 console listing for the same recording. ◦ You can redact IDs/secrets but keep the path/room-name portion intact. 1. Which LiveKit egress flow produced this file? (egress recording, backup egress, SIP egress) 2. LiveKit server version or deployment (self-hosted or LiveKit Cloud) and approximate timestamps for a few occurrences, if available. With those items I’ll analyze whether the percent-encoding happens before LiveKit writes to S3, in the webhook/manifest URLs, or when your code saves the path to the DB, and then recommend a targeted fix (or a robust normalization to avoid breakage). , with interactive elements
2 Views
Open in Slack
PreviousNext
Powered by