Amir Jabbari
اما WebRTC فقط این نیست که یک داخلی SIP بسازیم و آدرس آن را داخل مرورگر وارد کنیم. مرورگر برخلاف یک تلفن SIP معمولی، برای Signaling از WebSocket امن، برای Media از DTLS-SRTP، برای عبور از NAT از ICE و معمولاً STUN/TURN و برای دسترسی به میکروفن از Permissionهای امنیتی خود مرورگر استفاده می‌کند.
اگر یکی از این زنجیره‌ها درست نباشد، نتیجه می‌تواند یکی از این حالت‌ها باشد: داخلی Register نمی‌شود، WSS وصل نمی‌شود، مرورگر میکروفن را باز نمی‌کند، تماس زنگ می‌خورد ولی صدا ندارد، تماس فقط یک‌طرفه است یا ICE روی Checking می‌ماند.
در این آموزش Asterisk 22 را برای WebRTC آماده می‌کنیم، WSS و TLS را فعال می‌کنیم، یک داخلی PJSIP مخصوص مرورگر می‌سازیم، DTLS-SRTP و ICE را بررسی می‌کنیم، تفاوت STUN و TURN را توضیح می‌دهیم و در پایان یک روش مرحله‌به‌مرحله برای عیب‌یابی تماس مرورگری ارائه می‌کنیم.
نسخه مبنای این آموزش: در ۱۷ اکتبر ۲۰۲۶، Asterisk 22.11.0 آخرین نسخه پایدار LTS است. Asterisk 24 هنوز در مرحله Release Candidate قرار دارد؛ بنابراین برای یک نصب Production جدید، شاخه 22 LTS انتخاب محافظه‌کارانه‌تری است.
WebRTC روی Asterisk دقیقاً چگونه کار می‌کند؟
یک تلفن SIP سخت‌افزاری معمولاً مستقیماً با UDP، TCP یا TLS به Asterisk متصل می‌شود.
مرورگر اجازه چنین دسترسی مستقیمی به UDP/5060 را به JavaScript نمی‌دهد.
به همین دلیل Signaling از مسیر زیر عبور می‌کند:
Browser
|
| SIP over WSS
v
Asterisk HTTP/WebSocket Server
|
v
PJSIP Endpointاما Media مسیر دیگری دارد:
Browser
|
ICE + DTLS-SRTP
|
v
Asterisk RTP Engineشش جزء اصلی WebRTC روی Asterisk
🔹 HTTPS: صفحه Web Phone باید در یک Context امن اجرا شود.
🔹 WSS: SIP Signaling بین مرورگر و Asterisk.
🔹 TLS Certificate: مرورگر باید Certificate سرور را معتبر بداند.
🔹 DTLS-SRTP: رمزنگاری Media مرورگر.
🔹 ICE/STUN/TURN: پیدا کردن مسیر مناسب RTP از میان NAT و Firewall.
🔹 Browser Permissions: اجازه دسترسی به Microphone و در تماس ویدئویی Camera.
WSS با TLS و DTLS-SRTP یکی نیست
این سه مفهوم بسیار با هم اشتباه گرفته می‌شوند.
| بخش | وظیفه | نمونه |
|---|---|---|
| HTTPS/TLS | امن‌کردن Web Server | https://phone.example.com |
| WSS | SIP Signaling مرورگر | wss://pbx.example.com:8089/ws |
| DTLS-SRTP | رمزنگاری صدای تماس | Browser ↔ Asterisk Media |
پس ممکن است WSS کاملاً سالم باشد ولی DTLS-SRTP مشکل داشته باشد و تماس بدون صدا بماند.
پیش‌نیازهای Asterisk WebRTC
قبل از تغییر Configuration مطمئن شوید Moduleهای اصلی وجود دارند.
asterisk -rvvvسپس:
module show like res_crypto
module show like res_http_websocket
module show like res_pjsip_transport_websocket
module show like codec_opusسه Module اول برای WebRTC اهمیت مستقیم دارند.
`codec_opus` برای تماس صوتی باکیفیت WebRTC بسیار مفید است، ولی Asterisk می‌تواند بسته به Build و Codec Negotiation با Codecهای دیگر مثل G.711 نیز کار کند.
مرحله ۱: یک دامنه واقعی برای PBX داشته باشید
به‌جای اتصال مرورگر به IP خام، یک Hostname مانند:
pbx.example.comبسازید.
DNS باید Public IP واقعی Asterisk یا Reverse Proxy جلوی آن را Resolve کند.
برای Production بهتر است TLS Certificate معتبر نیز دقیقاً برای همین Hostname صادر شود.
چرا Self-Signed Certificate دردسرساز می‌شود؟
Asterisk از Certificate خودامضا پشتیبانی می‌کند، اما Browser ممکن است WSS را Reject کند؛ حتی وقتی خود SIP Configuration درست است.
برای همین در محیط واقعی بهتر است از Certificate معتبر عمومی مانند Let’s Encrypt استفاده شود.
نشانه رایج این مشکل:
WebSocket connection failed
ERR_CERT_AUTHORITY_INVALID
TLS handshake failedمرحله ۲: HTTPS Server داخلی Asterisk را فعال کنید
فایل:
/etc/asterisk/http.confرا باز کنید.
نمونه Configuration:
[general]
enabled=yes
bindaddr=0.0.0.0
bindport=8088
tlsenable=yes
tlsbindaddr=0.0.0.0:8089
tlscertfile=/etc/letsencrypt/live/pbx.example.com/fullchain.pem
tlsprivatekey=/etc/letsencrypt/live/pbx.example.com/privkey.pemمسیر Certificate را مطابق Server خود تغییر دهید.
آیا Port 8088 را هم باید Public کنیم؟
برای WebRTC Production اگر فقط WSS امن استفاده می‌کنید، الزام عملی برای Public کردن HTTP غیررمزنگاری‌شده 8088 ندارید.
Firewall را بر اساس معماری واقعی باز کنید و Port بدون نیاز را روی اینترنت قرار ندهید.
وضعیت HTTP Server را بررسی کنید
داخل Asterisk CLI:
http show statusباید HTTPS Server و URI مربوط به WebSocket را ببینید.
مسیر WebSocket معمولاً:
/wsاست.
پس WebSocket URL ما می‌شود:
wss://pbx.example.com:8089/wsقبل از SIP، Certificate را از Browser تست کنید
یک اشتباه رایج این است که بلافاصله سراغ PJSIP برویم.
ابتدا در Browser باز کنید:
https://pbx.example.com:8089/wsقرار نیست یک صفحه Web کامل ببینید؛ هدف این است که Browser از نظر TLS برای این Host هشدار Certificate نداشته باشد.
مرحله ۳: WSS Transport در PJSIP بسازید
در:
/etc/asterisk/pjsip.confاضافه کنید:
[transport-wss]
type=transport
protocol=wss
bind=0.0.0.0در WSS، HTTP Server داخلی Asterisk بخش اصلی TLS/WebSocket را مدیریت می‌کند.
بعد از تغییر Transport فقط Reload کافی است؟
Transportهای PJSIP به‌طور پیش‌فرض محدودیت Reload در Runtime دارند.
برای همین هنگام ایجاد یا تغییر Transport جدید، Restart کنترل‌شده Asterisk معمولاً قابل پیش‌بینی‌تر است؛ مگر اینکه دقیقاً `allow_reload` و اثر آن را در معماری خود مدیریت کرده باشید.
وضعیت Transport را ببینید
pjsip show transportsباید Transport با Protocol برابر WSS دیده شود.
مرحله ۴: داخلی WebRTC بسازید
فرض کنیم داخلی مرورگر شماره 6001 است.
AOR
[6001]
type=aor
max_contacts=3
remove_existing=yesAuthentication
[6001]
type=auth
auth_type=userpass
username=6001
password=CHANGE_TO_A_LONG_RANDOM_PASSWORDرمز نمونه را عیناً استفاده نکنید.
Endpoint
[6001]
type=endpoint
aors=6001
auth=6001
context=webrtc-internal
disallow=all
allow=opus,ulaw
webrtc=yes
direct_media=nowebrtc=yes چه کاری انجام می‌دهد؟
در Asterisk فعلی این گزینه یک Shortcut بسیار مهم است.
با فعال‌شدن آن، گزینه‌های موردنیاز WebRTC مانند موارد زیر تنظیم می‌شوند:
rtcp_mux=yes
use_avpf=yes
ice_support=yes
media_use_received_transport=yes
media_encryption=dtls
dtls_verify=fingerprint
dtls_setup=actpassاگر `dtls_cert_file` تعریف نشده باشد، `webrtc=yes` همچنین می‌تواند DTLS Certificate را خودکار تولید کند.
چرا direct_media=no گذاشتیم؟
در یک Setup اولیه WebRTC معمولاً بهتر است Media از Asterisk عبور کند.
اگر Direct Media را زود فعال کنید، Browser و Endpoint مقابل باید بتوانند مستقیماً ICE/DTLS/RTP را با یکدیگر برقرار کنند و NAT Troubleshooting سخت‌تر می‌شود.
پس ابتدا تماس پایدار از طریق Asterisk بسازید؛ بعد اگر برای معماری خاص خود واقعاً به Direct Media نیاز دارید، جدا Benchmark و آزمایش کنید.
DTLS Certificate اختصاصی یا Auto Generate؟
برای تست ساده می‌توانید از:
dtls_auto_generate_cert=yesاستفاده کنید.
اگر Policy شما نیاز به Certificate مدیریت‌شده دارد، گزینه‌های:
dtls_cert_file=
dtls_private_key=
dtls_ca_file=نیز در PJSIP موجودند.
Certificate مربوط به WSS/HTTPS و Certificate مورد استفاده DTLS دو نقش متفاوت دارند؛ آن‌ها را از نظر مفهومی یکی ندانید.
مرحله ۵: Dialplan آزمایشی بسازید
در:
/etc/asterisk/extensions.confبرای تست Echo:
[webrtc-internal]
exten => 9000,1,Answer()
same => n,Echo()
same => n,Hangup()بعد:
dialplan reload
pjsip reloadاگر Transport جدید ساخته‌اید و در وضعیت مورد انتظار ظاهر نمی‌شود، Restart کنترل‌شده انجام دهید.
مرحله ۶: وضعیت Endpoint را بررسی کنید
pjsip show endpoint 6001بعد از Register مرورگر:
pjsip show aor 6001
pjsip show contactsباید Contact مربوط به Browser/WebSocket را ببینید.
Web Phone را با چه Library بسازیم؟
در سمت Browser می‌توانید از SIP Libraryهایی مانند SIP.js یا JsSIP استفاده کنید.
این Libraryها SIP را روی WebSocket پیاده‌سازی می‌کنند و WebRTC API مرورگر را برای Media به کار می‌گیرند.
در هر Library نام Optionها کمی متفاوت است، اما اطلاعات اصلی معمولاً همین‌هاست:
SIP URI:
sip:6001@pbx.example.com
Username:
6001
Password:
YOUR_STRONG_PASSWORD
WebSocket:
wss://pbx.example.com:8089/wsصفحه Web Phone هم باید HTTPS باشد
حتی اگر WSS روی Asterisk کاملاً معتبر باشد، صفحه‌ای که JavaScript WebRTC از آن اجرا می‌شود نیز باید در Secure Context قرار داشته باشد.
مثلاً:
https://phone.example.comنه:
http://phone.example.comچرا Browser اجازه Microphone نمی‌دهد؟
مرورگر هنگام اولین تماس یا هنگام اجرای `getUserMedia()` از کاربر اجازه Microphone می‌خواهد.
اگر کاربر Block را انتخاب کند، Asterisk هیچ کاری برای برگرداندن این Permission از سمت Server نمی‌تواند انجام دهد.
در Browser باید Permission همان Site بررسی شود.
یک تست ساده Microphone در JavaScript
navigator.mediaDevices
.getUserMedia({
audio: true,
video: false
})
.then(stream => {
console.log("Microphone OK", stream);
})
.catch(error => {
console.error(error.name, error.message);
});خطاهای Browser Permission چه معنی دارند؟
| خطا | علت محتمل |
|---|---|
| NotAllowedError | Permission رد شده، HTTPS نیست یا Permissions Policy مانع است |
| NotFoundError | Microphone سازگار پیدا نشده |
| TypeError | ممکن است Context امن نباشد یا درخواست نامعتبر باشد |
اگر Web Phone داخل iframe است چه؟
در این حالت Permission پیچیده‌تر می‌شود.
ممکن است لازم باشد iframe اجازه Microphone داشته باشد:
<iframe
src="https://phone.example.com"
allow="microphone">
</iframe>همچنین Headerهای Permissions Policy وب‌سایت را بررسی کنید.
ICE چیست و چرا بدون آن WebRTC دردسر دارد؟
ICE مخفف Interactive Connectivity Establishment است.
هدف آن این است که Browser و Asterisk بهترین مسیر Media را از میان Candidateهای مختلف پیدا کنند.
Candidate ممکن است:
🔹 IP محلی دستگاه باشد.
🔹 Public Mapping کشف‌شده با STUN باشد.
🔹 Relay Address متعلق به TURN باشد.
STUN چه کاری می‌کند؟
STUN به Endpoint کمک می‌کند بفهمد از دید بیرون NAT با چه Public IP و Port دیده می‌شود.
در بسیاری از شبکه‌های معمولی همین اطلاعات برای ساخت مسیر Media کافی است.
TURN چه کاری می‌کند؟
TURN فقط آدرس Public را کشف نمی‌کند؛ خودش Media Relay می‌شود.
یعنی وقتی Browser و Asterisk به‌دلیل NAT یا Firewall سخت نمی‌توانند مسیر مستقیم مناسبی بسازند، Media از TURN Server عبور می‌کند.
این حالت معمولاً Bandwidth بیشتری روی TURN Server مصرف می‌کند.
پس STUN و TURN جای هم نیستند
| فناوری | وظیفه |
|---|---|
| ICE | انتخاب مسیر اتصال Media |
| STUN | کشف Public Mapping پشت NAT |
| TURN | Relay کردن Media وقتی مسیر مستقیم کار نمی‌کند |
تنظیم STUN در Asterisk
تنظیمات ICE سطح RTP در:
/etc/asterisk/rtp.confقرار می‌گیرند.
نمونه:
[general]
rtpstart=10000
rtpend=20000
stunaddr=stun.example.netبرای Production بهتر است به یک STUN Service قابل‌اعتماد که واقعاً در اختیار یا مورد اعتماد شماست متکی باشید، نه یک Host تصادفی از مقاله‌های قدیمی اینترنت.
تنظیم TURN در Asterisk
اگر معماری شما نیاز به TURN دارد:
[general]
turnaddr=turn.example.net
turnport=3478
turnusername=ASTERISK_TURN_USER
turnpassword=CHANGE_THIS_SECRETCredential واقعی را داخل Repository عمومی یا Screenshot منتشر نکنید.
آیا حتماً باید روی Asterisk هم STUN/TURN تنظیم کنیم؟
نه در همه معماری‌ها.
اگر Asterisk Public IP مستقیم و Routing مشخص دارد، ممکن است Host Candidate خودش کافی باشد.
همچنین Browser Client معمولاً ICE Serverهای خودش را نیز در `RTCPeerConnection` دارد.
اینکه STUN/TURN در سمت Browser، Asterisk یا هر دو لازم باشد به Network Topology بستگی دارد.
چه زمانی TURN واقعاً ضروری می‌شود؟
نشانه‌های مهم:
🔹 کاربران پشت CGNAT یا Symmetric NAT هستند.
🔹 Firewall شبکه UDP Peer-to-Peer را محدود کرده است.
🔹 ICE فقط Candidate محلی پیدا می‌کند.
🔹 تماس در برخی ISPها کار می‌کند و در برخی نه.
🔹 Browser روی `checking` می‌ماند و Pair موفق شکل نمی‌گیرد.
TURN را همیشه برای همه تماس‌ها Force کنیم؟
معمولاً نه.
اگر مسیر مستقیم امن و پایدار در دسترس است، Relay اجباری می‌تواند:
🔹 Latency را افزایش دهد.
🔹 Bandwidth سرور TURN را مصرف کند.
🔹 یک Failure Point اضافه کند.
TURN معمولاً باید مسیر جایگزین برای ICE باشد، مگر اینکه Policy امنیتی یا شبکه‌ای شما Media Relay اجباری بخواهد.
مرحله ۷: Firewall را درست باز کنید
برای Setup مستقیم Asterisk معمولاً حداقل این مسیرها را باید با معماری خود تطبیق دهید:
| بخش | پورت نمونه | پروتکل |
|---|---|---|
| WSS / HTTPS Asterisk | 8089 | TCP |
| RTP / SRTP | 10000-20000 | UDP |
| TURN در صورت استفاده | 3478 یا Port تنظیم‌شده | UDP/TCP بر اساس TURN |
اگر Nginx یا Load Balancer جلوی Asterisk قرار داده‌اید، Public Port می‌تواند 443 باشد و WSS در Backend به 8089 Proxy شود.
کل Firewall را خاموش نکنید
اگر WebRTC کار نمی‌کند، غیرفعال‌کردن کامل Firewall راه‌حل Production نیست.
بهتر است ابتدا با Packet Capture مشخص کنید چه Packetی Block شده و فقط همان مسیر موردنیاز را باز کنید.
مرحله ۸: اول Registration را تست کنید
قبل از تماس Media، مطمئن شوید SIP Signaling سالم است.
در Asterisk:
pjsip set logger onBrowser را Register کنید.
Flow معمولاً باید چیزی شبیه این باشد:
REGISTER
401 Unauthorized
REGISTER + Authorization
200 OK401 اول در Digest Authentication معمولاً بخشی از روند طبیعی Challenge است؛ مشکل زمانی است که چرخه 401/403 ادامه پیدا کند.
اگر WSS اصلاً وصل نمی‌شود
به این ترتیب بررسی کنید:
نشانه: هیچ REGISTER داخل Asterisk دیده نمی‌شود.
بررسی ۱: Browser DevTools → Network → WS.
بررسی ۲: Certificate Hostname و Chain.
بررسی ۳: Port 8089 یا Reverse Proxy.
بررسی ۴: `http show status`.
بررسی ۵: `pjsip show transports`.
اگر WebSocket وصل است ولی REGISTER شکست می‌خورد
این مرحله دیگر بیشتر SIP است تا WebRTC.
بررسی کنید:
🔹 Username درست است.
🔹 Auth Object درست به Endpoint وصل شده است.
🔹 Realm و Authorization با Client سازگار است.
🔹 Password اشتباه نیست.
🔹 SIP URI Domain درست است.
اگر Register شده ولی تماس برقرار نمی‌شود
در این مرحله INVITE را بررسی کنید.
pjsip set logger onبه Response Code توجه کنید.
مثلاً:
🔹 401/407: Authentication
🔹 403: Policy/Auth
🔹 404: Extension یا Route
🔹 488: Media/SDP/Codec مشکل دارد
🔹 503: Service/Route/Backend در دسترس نیست
اگر تماس برقرار می‌شود ولی صدا نداریم
حالا تمرکز را از SIP به Media منتقل کنید.
داخل Asterisk:
rtp set debug onاگر RTP/SRTP Debug هیچ Trafficی نشان نمی‌دهد، احتمالاً مسیر ICE، Firewall، SDP یا NAT مشکل دارد.
SDP را چه چیزهایی بررسی کنیم؟
در WebRTC Offer معمولاً باید نشانه‌هایی مانند موارد زیر ببینید:
a=ice-ufrag:
a=ice-pwd:
a=candidate:
a=fingerprint:
a=setup:
a=rtcp-muxنبودن یا ناسازگاری این بخش‌ها می‌تواند نشانه مشکل WebRTC Media Negotiation باشد.
ICE Candidateها چه می‌گویند؟
در SDP ممکن است Candidateهایی با نوع‌های مختلف ببینید.
| Candidate | معنی ساده |
|---|---|
| host | آدرس Interface محلی |
| srflx | Public Mapping کشف‌شده با STUN |
| relay | آدرس Relay متعلق به TURN |
اگر کاربر پشت NAT سخت است و هیچ Candidate قابل‌دسترسی ندارد، نبود Candidate از نوع Relay می‌تواند دلیل شکست ارتباط باشد.
Chrome WebRTC Internals ابزار بسیار مفیدی است
برای Chrome/Chromium می‌توانید اطلاعات PeerConnection را از ابزارهای WebRTC داخلی Browser بررسی کنید.
موارد مهم:
🔹 ICE Connection State
🔹 Selected Candidate Pair
🔹 Local Candidate
🔹 Remote Candidate
🔹 Codec
🔹 Packets Sent/Received
🔹 Jitter
🔹 Packet Loss
اگر ICE روی checking گیر می‌کند
مسیر تشخیص:
نشانه: SIP Call Setup جلو می‌رود ولی Media Connection تشکیل نمی‌شود.
بررسی: Candidate Pair انتخاب‌شده وجود دارد؟
علت محتمل: NAT سخت، STUN ناقص، TURN در دسترس نیست یا RTP Portها بسته‌اند.
رفع: مسیر Candidateها و Firewall را اصلاح کنید؛ در شبکه‌های محدود TURN Relay اضافه کنید.
تست مجدد: ICE State باید به `connected` یا `completed` برسد.
اگر DTLS Handshake شکست می‌خورد
این خطا معمولاً بعد از ساخته‌شدن مسیر ICE رخ می‌دهد.
بررسی کنید:
🔹 `media_encryption=dtls` فعال است.
🔹 Fingerprint در SDP وجود دارد.
🔹 `dtls_setup` دو طرف سازگار است.
🔹 Certificate/Key DTLS قابل خواندن است.
🔹 ساعت Server بسیار اشتباه نیست.
ساعت غلط Server می‌تواند دردسر ایجاد کند
Certificate Validation و TLS به زمان وابسته‌اند.
اگر ساعت Asterisk چند ساعت یا چند روز اشتباه باشد، Certificate معتبر ممکن است از نظر Server یا Client هنوز معتبر نشده یا Expire شده دیده شود.
پس قبل از عیب‌یابی پیچیده TLS:
timedatectl statusرا هم بررسی کنید.
Codec؛ چرا Opus مهم است؟
Opus Codec اصلی و محبوب WebRTC برای صوت است.
اگر Browser Opus پیشنهاد دهد و Asterisk یا سمت مقصد Codec مشترکی نداشته باشند، ممکن است SDP Negotiation به مشکل بخورد یا Transcoding لازم شود.
برای Endpoint WebRTC:
disallow=all
allow=opus,ulawنقطه شروع خوبی است.
اگر SIP Trunk فقط PCMA دارد چه؟
ممکن است تماس Browser با Opus وارد Asterisk شود و سمت Trunk با PCMA ادامه پیدا کند.
در این حالت Asterisk باید Transcoding انجام دهد.
این مسئله روی CPU مهم است و در سامانه پرترافیک باید Benchmark شود.
برای کاهش Transcoding چه کنیم؟
اگر تمام مسیر از یک Codec مشترک پشتیبانی می‌کند، اجازه‌دادن Codec مشترک می‌تواند Transcoding را حذف کند.
اما صرفاً برای کاهش CPU کیفیت یا Compatibility WebRTC را قربانی نکنید.
Reverse Proxy با Nginx؛ لازم است؟
خیر، برای WebRTC پایه Asterisk می‌تواند مستقیماً HTTPS/WSS ارائه دهد.
اما در Production ممکن است بخواهید:
🔹 Public Port استاندارد 443 داشته باشید.
🔹 TLS Certificate را روی Nginx مدیریت کنید.
🔹 Web Application و WebSocket را پشت یک Domain قرار دهید.
🔹 Rate Limit یا Access Policy اضافه کنید.
در Reverse Proxy مهم‌ترین نکته WebSocket Upgrade است
Proxy باید WebSocket Connection را Upgrade کند؛ وگرنه Browser ممکن است HTTPS معمولی را باز کند اما WSS شکست بخورد.
اگر Reverse Proxy اضافه کردید، ابتدا بدون آن Setup پایه را سالم کنید و سپس Proxy را وارد معماری کنید؛ این کار عیب‌یابی را ساده‌تر می‌کند.
امنیت WebRTC داخلی روی اینترنت
بازشدن WSS به اینترنت یعنی SIP Authentication شما در دسترس Botها نیز قرار می‌گیرد.
حداقل این موارد را جدی بگیرید:
🔹 Passwordهای طولانی و تصادفی
🔹 TLS معتبر
🔹 Fail2Ban یا سیستم تشخیص Brute Force مناسب
🔹 محدودکردن Context داخلی
🔹 جلوگیری از Dial Patternهای پرهزینه و غیرضروری
🔹 Monitoring تلاش‌های Registration
WebRTC Client را داخل context عمومی قرار ندهید
مثلاً Endpoint Browser را مستقیم داخل Contextی که امکان Dial بین‌الملل بدون محدودیت دارد قرار ندهید.
یک Context اختصاصی مانند:
context=webrtc-internalبسازید و فقط مقصدهای موردنیاز را در آن مجاز کنید.
آیا Credential SIP را داخل JavaScript قرار دهیم؟
اگر Web Application عمومی است، Hardcode کردن Password ثابت داخل فایل JavaScript انتخاب خوبی نیست؛ هر کاربری می‌تواند Source یا Network Requestها را بررسی کند.
بهتر است Web Phone بخشی از سامانه Authentication واقعی شما باشد و Credential Lifecycle با معماری سرویس هماهنگ شود.
یک روش تشخیص استاندارد Asterisk WebRTC
مرحله ۱ — Browser HTTPS: آیا صفحه Web Phone با HTTPS معتبر باز می‌شود؟
مرحله ۲ — Microphone: آیا `getUserMedia()` موفق است؟
مرحله ۳ — WSS: آیا WebSocket در DevTools با Status مناسب باز می‌شود؟
مرحله ۴ — REGISTER: آیا Asterisk REGISTER و 200 OK را می‌بیند؟
مرحله ۵ — INVITE: آیا تماس از Dialplan عبور می‌کند؟
مرحله ۶ — SDP: آیا ICE، Fingerprint و RTCP-MUX دیده می‌شوند؟
مرحله ۷ — ICE: آیا Candidate Pair موفق انتخاب می‌شود؟
مرحله ۸ — DTLS: آیا DTLS Handshake کامل می‌شود؟
مرحله ۹ — SRTP: آیا Packetهای Media ارسال و دریافت می‌شوند؟
مرحله ۱۰ — Codec: آیا Codec مشترک یا Transcoding سالم وجود دارد؟
جدول سریع تشخیص مشکل
| نشانه | اول کجا را بررسی کنیم؟ |
|---|---|
| صفحه به میکروفن دسترسی ندارد | HTTPS و Browser Permission |
| WSS Failed | TLS Certificate، 8089، Reverse Proxy |
| REGISTER نمی‌رسد | WebSocket Path و WSS Transport |
| 401 تکرار می‌شود | Username/Password/Auth |
| 403 | Authentication یا Policy |
| 488 | SDP، Codec، DTLS/SRTP |
| تماس وصل می‌شود ولی بی‌صداست | ICE، RTP Port، Firewall |
| صدای یک‌طرفه | NAT و Candidate Pair |
| فقط در بعضی ISPها خراب است | STUN/TURN و NAT Type |
| ICE روی Checking می‌ماند | Candidate Connectivity و TURN |
Packet Capture برای مرحله آخر
اگر هنوز مشخص نیست مشکل کجاست، Signaling و Media را جدا Capture کنید.
WSS/TLS:
tcpdump -ni any tcp port 8089Media:
tcpdump -ni any udp portrange 10000-20000اگر Port Range خودتان را تغییر داده‌اید، دستور دوم را با همان Range اجرا کنید.
آیا برای WebRTC حتماً RTPengine لازم است؟
خیر.
Asterisk خودش WebRTC، ICE و DTLS-SRTP را پشتیبانی می‌کند و برای یک PBX مستقل می‌تواند کاملاً کافی باشد.
RTPengine زمانی جذاب‌تر می‌شود که:
🔹 چند Asterisk دارید.
🔹 Kamailio/OpenSIPS جلوی PBX است.
🔹 Media باید مستقل Scale شود.
🔹 WebRTC-to-SIP Interworking پرترافیک دارید.
🔹 Media Topology Hiding مهم است.
برای ۱۰ کاربر و ۱۰۰۰ کاربر معماری یکسان نسازید
برای یک شرکت کوچک:
Browser → WSS → Asterisk
می‌تواند کافی باشد.
برای سرویس Hosted:
Browser → Kamailio/OpenSIPS → Asterisk Pool + RTPengine Pool
معماری قابل Scaleتری است.
پرسش‌های رایج
Asterisk WebRTC چیست؟
Asterisk WebRTC یعنی اتصال Browser یا Web Application به Asterisk برای تماس صوتی یا تصویری با استفاده از WebSocket، ICE و Media امن WebRTC، بدون نیاز به تلفن سخت‌افزاری.
برای WebRTC روی Asterisk به چه پورتی نیاز داریم؟
در Configuration رسمی Asterisk، HTTPS/WSS معمولاً روی TCP 8089 اجرا می‌شود و RTP/SRTP نیز از Range تعریف‌شده در rtp.conf استفاده می‌کند. اگر Reverse Proxy دارید، Public Port می‌تواند 443 باشد.
آیا WSS همان SRTP است؟
خیر. WSS برای SIP Signaling است. SRTP برای Media صوتی یا تصویری استفاده می‌شود و در WebRTC معمولاً Key Negotiation از DTLS انجام می‌شود.
webrtc=yes در Asterisk چه کاری می‌کند؟
این گزینه مجموعه‌ای از تنظیمات موردنیاز WebRTC از جمله AVPF، ICE، RTCP-MUX، DTLS Media Encryption و تنظیمات مرتبط با دریافت Media Transport را فعال می‌کند.
چرا مرورگر Microphone را باز نمی‌کند؟
معمولاً صفحه HTTPS نیست، Permission توسط کاربر Block شده، Microphone پیدا نشده یا Permissions Policy وب‌سایت دسترسی را محدود کرده است.
STUN و TURN چه تفاوتی دارند؟
STUN کمک می‌کند Public Mapping پشت NAT کشف شود، اما TURN خودش Media Relay می‌شود. TURN برای شبکه‌هایی که مسیر مستقیم ICE برقرار نمی‌شود اهمیت دارد.
آیا بدون TURN هم WebRTC کار می‌کند؟
بله، در بسیاری از شبکه‌ها Host و STUN Candidate کافی هستند. TURN برای سناریوهای NAT و Firewall دشوار مسیر جایگزین فراهم می‌کند.
چرا تماس برقرار می‌شود ولی صدا نداریم؟
اگر Signaling کامل شده ولی Media وجود ندارد، ICE Candidate، RTP Firewall، NAT، DTLS Handshake و SRTP را بررسی کنید.
چرا فقط برخی کاربران مشکل WebRTC دارند؟
این حالت معمولاً به تفاوت NAT، CGNAT، Firewall سازمانی یا ISP مربوط می‌شود. بررسی Candidate Pair و اضافه‌کردن TURN می‌تواند علت را روشن کند.
آیا Asterisk به RTPengine نیاز دارد؟
برای WebRTC پایه خیر. Asterisk خودش WebRTC را مدیریت می‌کند. RTPengine بیشتر برای معماری‌های چندسروره، Media Scaling و NAT/WebRTC پیچیده کاربرد دارد.
جمع‌بندی
برای راه‌اندازی تماس مرورگری روی Asterisk باید چهار لایه را هم‌زمان درست کنید: Web Application امن، WSS Signaling، PJSIP WebRTC Endpoint و Media مبتنی بر ICE و DTLS-SRTP.
در سمت Asterisk، HTTPS Server داخلی و مسیر `/ws` ارتباط WebSocket را فراهم می‌کنند و PJSIP Transport با `protocol=wss` SIP را به Browser متصل می‌کند. در Endpoint نیز `webrtc=yes` بخش بزرگی از تنظیمات ضروری WebRTC را فعال می‌کند.
اگر Registration سالم است ولی صدا ندارید، دیگر مشکل را در Username و Password جست‌وجو نکنید؛ وارد ICE، STUN/TURN، SDP، DTLS و RTP Portها شوید.
اگر حتی REGISTER به Asterisk نمی‌رسد، ابتدا TLS Certificate، WSS، Browser DevTools و `http show status` را بررسی کنید.
و اگر Browser حتی Microphone را نمی‌بیند، قبل از دست‌زدن به Asterisk مطمئن شوید صفحه HTTPS است و کاربر Permission میکروفن را Block نکرده است.
بهترین روش عیب‌یابی WebRTC این است که مسیر را به ترتیب HTTPS → WSS → REGISTER → INVITE → SDP → ICE → DTLS → SRTP جلو ببرید؛ این ترتیب مانع از آن می‌شود که برای یک مشکل ساده Certificate یا Browser Permission ساعت‌ها روی RTP و Dialplan وقت بگذارید.
می‌خواهید کاربران فقط با مرورگر به مرکز تلفن شما وصل شوند؟ زیرساخت WebRTC را قبل از ورود کاربران واقعی تست کنید
برای یک Web Phone پایدار، فقط نصب Asterisk کافی نیست. WSS باید Certificate معتبر داشته باشد، RTP/SRTP Portها بدون Packet Loss در دسترس باشند و سرور برای تماس‌های هم‌زمان، Opus و در صورت نیاز Transcoding منابع کافی داشته باشد.
می‌توانید Asterisk 22 را روی یک سرور مجازی ایرانیکاسرور با IP ثابت راه‌اندازی کنید و ابتدا داخلی WebRTC، HTTPS/WSS، ICE، STUN/TURN و تماس مرورگری را در یک محیط مستقل تست کنید. اگر پروژه شما بعداً بزرگ‌تر شد، همین معماری را می‌توان به Kamailio و RTPengine گسترش داد.
مشاوره Asterisk، WebRTC، WSS و TURN: 021-91302467
دیدگاه‌ها (۰)