Hello Everyone, can anyone help me with it • Previously used LiveKit Cloud with Twilio for SIP/PSTN calling • The Twilio → LiveKit integration was working correctly • Now attempting to replace Twilio with Amazon Chime • LiveKit Cloud is still used for real-time audio/video • Incoming calls are not reaching Amazon Chime SIP Media Application • CloudWatch log group is created, but no log streams or SIP events appear • This indicates calls are not being routed to the SIP Media Application • Unable to detect or forward incoming calls from Chime to LiveKit Need help identifying missing or incorrect Chime configuration (Voice Connector, inbound routing, phone number assignment, SMA setup)

Thanks for reaching out, danish. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.

Voice Connector • Voice Connector in use:

ai-receptionist-vc

• Handles PSTN inbound: Yes • Origination: Disabled (required when using SIP Media Applications) Phone number / inbound routing • Phone number: Chime PSTN Audio number (US) • Provisioned in: Amazon Chime SDK • Assigned to Voice Connector: Yes • Routing to SMA: Currently not active (no enabled SIP Media Application rule) SIP Media Application (SMA) & endpoints • SMA status: Deleted (being recreated) • Previous SMA name:

chime-to-livekit-router

• Endpoint type: AWS Lambda • Forwarding method: Lambda intended to forward audio to LiveKit • Direct SIP forwarding: No Inbound routing / PSTN to SMA mapping • Voice Connector inbound routing: Uses SIP Media Application (not SIP origination) • SIP Media Application Rule: Missing / disabled • Required rule: Trigger type:

Incoming call

Trigger value:

*

Status: Enabled Authentication / SIP credentials • SIP authentication: Not used • Credential-based auth: No • IP ACL: No Network / SIP endpoint reachability • LiveKit SIP endpoint tested: Not yet (calls not reaching Lambda) • Firewall / NAT / TLS / SRTP: Not applicable at current stage CloudWatch evidence • Log group exists: Yes • Log streams created: No • Reason: SIP Media Application is not being invoked Errors / call traces • Caller message when origination disabled: “Not responding” • Meaning: Call reaches Chime, no application answers • Chime console errors: None visible • LiveKit SIP logs: None (no call attempts reach LiveKit)

Thanks — I see the key points: your Voice Connector

ai-receptionist-vc

accepts PSTN, the Chime phone number is assigned to it, but the SMA was deleted/recreated and the required incoming-call SMA rule is missing/disabled. Because the SMA rule is not enabled, Chime never invokes the Lambda and CloudWatch shows no streams — so calls never reach LiveKit. Below are focused, prioritized steps to get calls routing again and verification checks. 1) Recreate and enable the SMA rule (highest priority) • Create or reattach the SIP Media Application (SMA) named e.g.

chime-to-livekit-router

. • Add an SMA Rule: ◦ Trigger type: Incoming call ◦ Trigger value: * ◦ Status: Enabled • Verify the SMA is associated with your Voice Connector (so incoming calls on that VC invoke the SMA). 2) Confirm phone number → Voice Connector mapping • In the phone number settings, ensure the Chime PSTN number is assigned to

ai-receptionist-vc

. • Confirm any phone-number-level routing doesn’t override the VC → SMA path. 3) Verify Lambda target in SMA • Confirm the SMA’s endpoint is the correct Lambda function ARN. • Ensure the Lambda has an execution role with permissions to write CloudWatch logs. • Deploy a simple test version of the Lambda that immediately logs receipt of the incoming event (so you can detect invocation before adding forwarding logic). 4) Check CloudWatch logs after enabling the SMA rule • The SMA invocation should create log streams under the SMA’s CloudWatch log group. If still no log streams: ◦ Confirm the Lambda’s log group exists and Lambda has permission to write. ◦ Confirm the SMA rule is enabled and associated with the Voice Connector. ◦ Confirm the Voice Connector origination/inbound setting is enabled (you earlier noted origination was disabled — origination must be enabled for PSTN → SMA flows). 5) Validate Voice Connector origination settings • Ensure originations are enabled for the Voice Connector. Origination disabled will block PSTN calls from being delivered to SMA. • Check any origination routes (if used) point to the correct SBC or source IP ranges. 6) Quick functional tests • After enabling SMA rule and confirming Lambda logging: ◦ Place a test call to the Chime phone number. ◦ Expectation: CloudWatch log streams appear for the Lambda with the incoming call event. ◦ If logged, next test: have Lambda send an INVITE or SIP re-INVITE to your LiveKit SIP gateway — track logs on both sides. 7) If Lambda invoked but LiveKit not reached • Confirm the Lambda’s forwarding code forms a valid SIP INVITE (correct SIP URI, headers, transport: UDP/TCP/TLS). • From an AWS host or Lambda (if possible), run a SIP OPTIONS or test INVITE to your LiveKit SIP endpoint to confirm reachability. • Confirm LiveKit expects unauthenticated calls (you said no SIP auth/IP ACL). If LiveKit requires mutual TLS or auth, adapt Lambda to meet that. 8) Helpful verification checklist (summary) • SMA exists and enabled • SMA Rule: Incoming call, value

*

, Status: Enabled • SMA associated with Voice Connector

ai-receptionist-vc

• Phone number assigned to

ai-receptionist-vc

• Voice Connector origination/inbound enabled • Lambda ARN correct, Lambda can write CloudWatch logs • Test calls produce CloudWatch log streams If you want, share: • Confirmation that Voice Connector origination has been enabled (you earlier said it was disabled) • SMA name/ARN, Voice Connector ID, and CloudWatch log group name (I’ll point to exact places in the Chime console and the specific log group to watch) I can then give the exact clicks/console paths and a short Lambda test-snippet to produce logs and forward a SIP INVITE to LiveKit.

i guess you asking to add Incoming Call as trigger type in SIP rule but i have just two options in trigger type 1. to phone number 2. Request URI hostname and in Request URI hostname my vc coming and i can connect that but in phone number no number showing even in phone number management i have phone number

Thanks — I’m addressing your point about the missing “Incoming call” trigger and why only “to phone number” and “Request URI hostname” are showing. Quick clarification: when creating a SIP Media Application rule in Chime you should be able to match by phone number OR by Request-URI hostname. The “Incoming call” trigger you expected maps to matching by phone number in the rule. Since your phone number isn’t appearing as an option, Chime isn’t treating that phone number as routable to the SMA/Voice Connector association yet. Please check these specific items and reply with results: 1) Phone number assignment • Confirm the number is assigned to the Voice Connector

ai-receptionist-vc

in the Phone Numbers section. (If it’s assigned elsewhere or not assigned, it won’t appear in the rule.) 2) Voice Connector and SMA association • Confirm the Voice Connector has the SMA attached (Voice Connector → SIP Media Applications). If the SMA is not attached, phone-number matching options won’t surface. 3) Number provisioning type • Confirm the phone number is a Chime SDK phone number (not an externally ported or other type that’s not linked). Which console section shows the number (Phone numbers under Chime SDK)? 4) Region and account • Confirm the phone number, Voice Connector, and SMA are all in the same AWS account and region. Cross-account or cross-region numbers won’t be selectable. 5) When creating the SMA rule • Use the “to phone number” trigger and check the dropdown — it should list numbers assigned to the Voice Connector. If still empty, try typing the E.164 number manually into the rule’s phone-number field (Chime sometimes accepts the literal number). 6) Temp test: use Request-URI hostname • You said Request-URI hostname does match your VC and connects — as a temporary route, enable a rule matching the Request-URI hostname that invokes the Lambda so you can confirm Lambda invocation and CloudWatch logs while you resolve the phone-number selection. If after those checks the phone number still does not appear, please share: • Exact console path you’re using (screenshots help) and the phone number format (E.164). • Confirmation that the SMA is attached to

ai-receptionist-vc

. • Whether you can type the number manually into the “to phone number” field. Once I have that, I’ll give the exact steps (and a quick Lambda test snippet) to validate calls reach CloudWatch and forward to LiveKit.