Our Telephony dashboard shows:
• 13 total calls
• 12 calls with issues
However, the Calls table is completely empty, so there are no calls to click into and no way to access a PCAP.
Is this expected behaviour, or should failed SIP calls still appear in the Calls list?
Hi Kevin, that looks like a bug with the dashboard. As a workaround, you should be able to select ‘past 30 days’ in the drop-down on the top right to see the failing calls.
Alternatively, you can find the call from the session view. On the sessions dashboard select the session, then under the ‘Subscribers’ table there is a ‘used features’ column with a link to the SIP details page there.
I didn’t look too deeply into the call failures, it looks like the provider is rejecting the connection on the default port so no PCAP is being generated.
Hey Darryn
Thanks, that’s very helpful.
When you say “the provider is rejecting the connection on the default port”, could you clarify exactly what you mean?
Specifically:
• Which destination host is LiveKit attempting to connect to?
• Which port is it using (5060, 5061, or another)?
• Which transport is it using (UDP, TCP or TLS)?
• Is the TCP/TLS connection itself being rejected, or is a SIP response being returned?
Knowing the host, port and transport will help us verify that our SIP provider is configured to accept the connection.
I was just going by the error message I saw for your calls:
transport dial err=dial tcp :9267->:5060: connect: connection refused
5060 is the default SIP port.
Looking at your trunk configuration, it’s using SIP_TRANSPORT_TCP and I also see that reflected in the ‘Call details’ section.
There is something wrong with your configuration that is causing the outbound call to be rejected, the first thing I recommend trying is to switch to UDP in case the provider does not accept TCP on that port. You would do that by modifying your SIP trunk. Your provider might also have error logs why they refused the call.
Hey Darryn
ICUK have checked their SIP logs but can’t currently see our connection attempts.
Could you please tell us the source IP address (or addresses) that LiveKit Cloud used for the outbound SIP connection for the following SIP Call IDs?
SCL_pSLH94GWbWtg
SCL_RvkdP5bGTzgz
If possible, could you also confirm:
ICUK will use this information to filter their firewall and SIP server logs.
Many thanks.
The destination IP address that cloudwireless.intervoip.co.uk resolved to
It did not resolve to a valid host. I can also run nslookup on that address and I don’t get an answer.
I tried to check your trunk config, but I think you might be dynamically generating the trunk since I can’t find the used trunk details stored (ST_y7THHf2W9yMS) .
Thanks. The trunk you checked, ST_y7THHf2W9yMS, was a temporary diagnostic clone and was automatically deleted after the test, which explains why you cannot now find it.
The configured gateway cloudwireless.intervoip.co.uk uses DNS SRV records and intentionally has no direct A record.
The highest-priority UDP SRV target is:
IP: 80.209.159.50
I am creating a persistent diagnostic outbound trunk pointing directly to that host and port over UDP, and I will leave it stored so you can inspect it.
I will send you the new trunk ID and SIP Call ID as soon as the test has run.
I’ve now created a persistent diagnostic trunk and left it in place for you to inspect.
Trunk ID:
ST_Cj2Pb7wTMMSn
Configuration:
I also placed a single outbound test call.
SIP Call ID:
SCL_b5SsoLrCjKEM
CreateSIPParticipant completed successfully.
If it helps, I can also provide the participant ID and room ID, but hopefully the trunk ID and SIP Call ID are sufficient for you to inspect the SIP transaction from your side.
Many thanks.
It’s managing to connect, and it looks like it authenticates, but then we’re being sent a 403from your provider. This is typically a credentials issue. We have a docs page here:
Hey Darryn
ICUK devs are asking for ether the IP address or the packet capture, are you able to provide this for me please?
Sure, the pcap is available from your dashboard:
https://cloud.livekit.io/projects/p_/telephony/SCL_b5SsoLrCjKEM/outbound
Hi Darryn
Could you please let me know does LiveKit support DNS SRV record lookups for outbound SIP trunks, or does it only resolve A/AAAA records?
We do not support DNS SRV record lookups. The team are currently working on support but I don’t have a timeline for when this feature would release I’m afraid.
Could that be the reason for the failed outbound calls? I haven’t come across a customer using intervoip in the past.
Hi Darryn
ICUK have provided an example of the SIP INVITE they expect to receive for outbound calls.
Could you please compare this with the INVITE that LiveKit generates and let me know if there are any differences that would explain the 403 Forbidden responses we’re seeing?
In particular, could you confirm whether LiveKit supports generating the following correctly:
Request-URI:
can’t give you this because you’re not accepting links;user=phone
From:
can’t give you this because you’re not accepting links
To:
can’t give you this because you’re not accepting links
Authorization realm:
can’t give you this because you’re not accepting links
Authorization URI:
sip:cloudwireless.intervoip.co.uk
P-Asserted-Identity
user=phone parameter
ICUK have also advised that their preferred configuration is:
Host / registration address:
80.209.159.50
Outbound proxy:
Register using outbound proxy:
Enabled (if supported)
Below is the example INVITE provided by ICUK.
ICUK [Alan]
15:06
One other thing. It might help if you give LiveKit this example outbound call SIP packet. This is what we’re expecting for an outbound call:
INVITE sip:{{DIALLED_NUMBER}}@{{ACCOUNT_NAME}}.{{REALM}};user=phone SIP/2.0
Via: SIP/2.0/UDP {{LOCAL_IP}}:5060;branch=z9hG4bK-5ac94c1c905f6783aed8c7d6ab9e0426;rport
From: “{{PRESENTATION_NUMBER}}” sip:{{USERNAME}}@{{ACCOUNT_NAME}}.{{REALM}};tag=688897630
To: sip:{{DIALLED_NUMBER}}@{{ACCOUNT_NAME}}.{{REALM}}
Call-ID: unique-string-identifier
CSeq: 9188 INVITE
Max-Forwards: 69
Contact: sip:{{USERNAME}}@{{PUBLIC_IP}}:5060;transport=udp
Allow-Events: refer
Supported: 100rel, replaces, norefersub
Allow: INVITE, ACK, CANCEL, BYE, REFER, PRACK, INFO, UPDATE
Accept: application/sdp
User-Agent: Your-PBX-Name
Authorization: Digest username=“{{USERNAME}}”,realm=“{{ACCOUNT_NAME}}.{{REALM}}”,nonce=“example-nonce”,uri=“sip:{{ACCOUNT_NAME}}.{{REALM}}”,response=“hashed-password”,algorithm=MD5
P-Asserted-Identity: “{{NETWORK_NUMBER}}” sip:{{NETWORK_NUMBER}}@{{ACCOUNT_NAME}}.{{REALM}}
Content-Type: application/sdp
Content-Length: 238
Could you let me know whether LiveKit can generate an INVITE matching this format, or whether there are any limitations that would prevent it?
I don’t seem to be able to paste everything in here because it’s blocking the links so If you can provide me with a way of communicating with you without the links getting blocked, I can give you everything as it should be, like the URI, the From, the To, and the Authorisation realm.
Many thanks, Kevin
Hi Kevin,
Could you please compare this with the INVITE that LiveKit generates and let me know if there are any differences that would explain the 403 Forbidden responses we’re seeing?
Did ICUK say why they were rejecting the invite? Which field was missing or incorrect?
It feels like we are going back and forth on this, so adding @CWilson who understands the protocol a lot better than myself.
But, to answer your specific question… Looking at the pcap for the session I linked above:
Request-URI:
can’t give you this because you’re not accepting links;user=phone
There is a request-URI in the pcap that seems to match the expected format, except for the lack of user=phone
From:
can’t give you this because you’re not accepting links
There is a From field that appears to match what you expect
To:
can’t give you this because you’re not accepting links
There is a to field that appears to match what you expect
Authorization realm:
can’t give you this because you’re not accepting links
This is part of the proxy-authorization header, ***.sip.livekit.cloud,
Authorization URI:
sip:cloudwireless.intervoip.co.uk
This is also part of the authorization header, but does not match your expected format.
P-Asserted-Identity
This is absent from the pcap
user=phone parameter
This is absent from the pcap
Thanks, that’s really helpful.
From what you’ve described, there appear to be several differences between the INVITE LiveKit generates and what ICUK expects:
ICUK believe these may be contributing to the 403 response.
Could you clarify whether these are:
If they’re fixed or unsupported, that would help us determine whether this is a compatibility limitation rather than a configuration issue.
Thanks for adding @CWilson as well.
Hey Darryn
I appreciate you adding @cWilson but we’ve not had a response from him just yet, would it be possible to get some answers on this ASAP?
I let my 3cx system lapse on the first of July, and we’ve had no working phones since. I’ve been spending all my time desperately trying to get this to work, and I really don’t want to go into another week with it still not working.
If it’s not able to work via LiveKit, then that’s absolutely fine. I’ll try some other routes, but I’m in limbo at the moment until I get your answers.
Thanks, Kevin
It’s not possible for us to test with all providers, and I haven’t come across an integration with ICUK in the past. Some providers have requirements that we don’t meet for one reason or another, and in such cases most customers will use a service such as Asterisk to proxy requests for LiveKit.
I was trying to find a recent post about this, to give you some context, and I found this: Has Anyone successfully integrated livekit sip with Airtel Sip · Issue #517 · livekit/sip · GitHub. Note that the issue described there relates to user=phone being absent, so quite possibly that is the same root cause since that was one of the fields mentioned above, but I can’t authoritatively say that is why ICUK is rejecting the call.
Hey Darryn.
I’m completely with you on that, fully appreciated.
I will go ahead and explore some other options, but if you are able to get C Wilson to come back to us, that would be really helpful, as we would like to continue using you guys.
Thanks, Kevin.
If you used a proxy such as Asterisk you would still be using LiveKit, the calls would just be routed:
LiveKit ↔ Asterisk ↔ ICUK