Amir Jabbari
برای تماس مرورگری با Asterisk لازم نیست کاربر تلفن سخت‌افزاری داشته باشد. مرورگر می‌تواند به‌عنوان یک SIP/WebRTC Client به Asterisk متصل شود، اما این اتصال با SIP معمولی روی UDP/5060 فرق دارد. مرورگر برای Signaling معمولاً به WSS، برای Media به DTLS-SRTP و برای عبور از NAT به ICE/STUN/TURN نیاز دارد؛ علاوه بر این، خود صفحه وب باید HTTPS باشد تا مرورگر اجازه استفاده از میکروفن را بدهد.
در این راهنما یک سناریوی عملی می‌سازیم: Asterisk با PJSIP روی سرور اجرا می‌شود، کاربر صفحه Web Phone را با مرورگر باز می‌کند، از طریق wss://pbx.example.com:8089/ws رجیستر می‌شود و تماس صوتی را بدون IP Phone فیزیکی برقرار می‌کند. سپس مرحله‌به‌مرحله TLS، WSS، DTLS-SRTP، ICE، STUN/TURN، Firewall و Permission مرورگر را بررسی می‌کنیم.
برای نصب جدید در اکتبر ۲۰۲۶، مبنای مناسب Production شاخه Asterisk 22 LTS است و آخرین نسخه پایدار عمومی آن 22.11.0 است. شاخه 22 تا اکتبر ۲۰۲۸ Full Support دارد. Asterisk 24 در زمان بررسی این مقاله هنوز در مرحله Release Candidate است؛ بنابراین برای این آموزش از شاخه پایدار 22 استفاده می‌کنیم.
خلاصه معماری: HTTPS صفحه وب → WSS برای SIP Signaling → PJSIP در Asterisk → ICE برای پیدا کردن مسیر Media → DTLS-SRTP برای رمزنگاری صدا → RTP/RTCP Multiplexing برای Media مرورگر.
WebRTC روی Asterisk دقیقاً یعنی چه؟
WebRTC مجموعه‌ای از فناوری‌های مرورگر برای برقراری ارتباط صوتی و تصویری بلادرنگ است. در سناریوی Asterisk، مرورگر نقش Endpoint را دارد؛ درست مثل یک IP Phone، اما به‌جای SIP روی UDP/TCP معمولی از WebSocket امن برای Signaling و از Media رمزنگاری‌شده WebRTC استفاده می‌کند.
سه مسیر را از هم جدا ببینید:
🔹 HTTPS: صفحه Web Phone از طریق اتصال امن در مرورگر باز می‌شود.
🔹 WSS: پیام‌های SIP مثل REGISTER و INVITE از WebSocket امن عبور می‌کنند.
🔹 DTLS-SRTP: صدای واقعی تماس روی مسیر Media رمزنگاری می‌شود.
بنابراین اگر WSS وصل شود ولی DTLS/ICE مشکل داشته باشد، ممکن است داخلی Registered دیده شود اما تماس بدون صدا باشد. برعکس، اگر Certificate WSS معتبر نباشد، مرورگر حتی قبل از رسیدن به مرحله REGISTER اتصال را Block می‌کند.
Browser
|
| HTTPS
v
Web Phone UI
|
| WSS / SIP
v
Asterisk PJSIP
|
| ICE + DTLS-SRTP
v
Encrypted Audio Mediaپیش‌نیازهای WebRTC روی Asterisk
مستند رسمی Asterisk برای WebRTC وجود چند ماژول را ضروری می‌داند. قبل از تنظیم فایل‌ها مطمئن شوید این ماژول‌ها روی Build شما وجود دارند:
🔹 res_crypto برای قابلیت‌های رمزنگاری.
🔹 res_http_websocket برای WebSocket Server.
🔹 res_pjsip_transport_websocket برای PJSIP روی WS/WSS.
🔹 codec_opus اختیاری است، اما برای WebRTC صوتی انتخاب بسیار خوبی است.
ماژول‌ها را بررسی کنید:
asterisk -rx "module show like websocket"
asterisk -rx "module show like res_crypto"
asterisk -rx "module show like opus"اگر Opus ندارید، برای تست اولیه می‌توانید از ulaw استفاده کنید؛ اما در WebRTC جدید معمولاً Opus انتخاب مطلوب‌تری است.
مرحله ۱: دامنه و Certificate معتبر آماده کنید
برای Production از یک نام دامنه مثل pbx.example.com استفاده کنید و Certificate معتبر عمومی بگیرید. Asterisk صراحتاً هشدار می‌دهد که مرورگرها با Certificate خودامضا روی WSS مشکل دارند و برای استفاده واقعی Certificate مورداعتماد بسیار مطمئن‌تر است.
فرض کنیم فایل‌ها در این مسیر هستند:
/etc/asterisk/keys/fullchain.pem
/etc/asterisk/keys/privkey.pemدو TLS متفاوت داریم: Certificate مربوط به WSS در http.conf برای Signaling استفاده می‌شود؛ DTLS-SRTP مربوط به Media است. سالم بودن یکی به معنی سالم بودن دیگری نیست.
مرحله ۲: HTTPS و WebSocket امن Asterisk را فعال کنید
Asterisk برای WebSocket از HTTP Server داخلی خودش استفاده می‌کند. فایل /etc/asterisk/http.conf را تنظیم کنید:
[general]
enabled=yes
bindaddr=0.0.0.0
bindport=8088
tlsenable=yes
tlsbindaddr=0.0.0.0:8089
tlscertfile=/etc/asterisk/keys/fullchain.pem
tlsprivatekey=/etc/asterisk/keys/privkey.pemسپس Asterisk را Reload یا Restart کنید و وضعیت HTTP Server را ببینید:
asterisk -rx "http show status"باید HTTPS روی Port موردنظر و URI زیر را ببینید:
/ws => Asterisk HTTP WebSocketآدرس نهایی WebSocket در این مثال:
wss://pbx.example.com:8089/wsمرحله ۳: Transport نوع WSS در PJSIP بسازید
در /etc/asterisk/pjsip.conf:
[transport-wss]
type=transport
protocol=wss
bind=0.0.0.0نکته‌ای که در مستند رسمی Asterisk آمده این است که کار اصلی WebSocket را HTTP Server انجام می‌دهد و Transport نوع WSS در PJSIP فقط مسیر PJSIP را به WebSocket متصل می‌کند.
بعد از Restart:
asterisk -rx "pjsip show transports"مرحله ۴: داخلی WebRTC در PJSIP بسازید
یک داخلی به نام 1001-web می‌سازیم. Password نمونه را حتماً در Production با مقدار طولانی و تصادفی جایگزین کنید.
[1001-web]
type=aor
max_contacts=2
remove_existing=yes
[1001-web]
type=auth
auth_type=userpass
username=1001-web
password=CHANGE_THIS_TO_A_LONG_RANDOM_PASSWORD
[1001-web]
type=endpoint
aors=1001-web
auth=1001-web
context=webrtc-internal
webrtc=yes
disallow=all
allow=opus,ulawگزینه webrtc=yes فقط یک Label نیست. در Asterisk این گزینه چند تنظیم لازم برای WebRTC را به‌صورت پیش‌فرض فعال می‌کند، از جمله:
🔹 rtcp_mux=yes
🔹 use_avpf=yes
🔹 ice_support=yes
🔹 media_use_received_transport=yes
🔹 media_encryption=dtls
🔹 dtls_verify=fingerprint
🔹 dtls_setup=actpass
اگر Certificate DTLS جدا تعیین نکرده باشید، Asterisk می‌تواند با dtls_auto_generate_cert=yes Certificate لازم Media را تولید کند.
مرحله ۵: یک Dialplan آزمایشی بسازید
در /etc/asterisk/extensions.conf یک Context ساده ایجاد کنید:
[webrtc-internal]
exten => 200,1,Answer()
same => n,Playback(demo-congrats)
same => n,Hangup()
exten => 1001,1,Dial(PJSIP/1001-web,30)
same => n,Hangup()Reload:
asterisk -rx "dialplan reload"
asterisk -rx "pjsip reload"مرحله ۶: Permission میکروفن در مرورگر را درست مدیریت کنید
مرورگر بدون رضایت کاربر اجازه دسترسی به Microphone را نمی‌دهد. API استاندارد getUserMedia() فقط در Secure Context در دسترس است؛ یعنی صفحه باید روی HTTPS یا محیط امنی مثل localhost اجرا شود.
یک تست ساده برای Permission:
async function testMicrophone() {
try {
const stream = await navigator.mediaDevices.getUserMedia({
audio: true,
video: false
});
console.log('Microphone access OK');
stream.getTracks().forEach(track => track.stop());
} catch (error) {
console.error('Microphone permission failed:', error.name, error.message);
}
}
testMicrophone();اگر navigator.mediaDevices وجود ندارد، قبل از Asterisk دنبال مشکل بگردید: صفحه احتمالاً از HTTP ناامن باز شده یا Browser Policy دسترسی را مسدود کرده است.
اگر Web Phone داخل iframe است: Permission میکروفن می‌تواند به Permissions Policy و تنظیمات iframe وابسته باشد. ممکن است کاربر اصلاً Prompt اجازه میکروفن را نبیند، حتی اگر کد شما درست باشد.
مرحله ۷: ICE، STUN و TURN را درست بفهمید
WebRTC برای پیدا کردن مسیر Media از ICE استفاده می‌کند. ICE Candidateها معمولاً سه نوع مهم دارند:
| Candidate | معنی | نمونه کاربرد |
|---|---|---|
| host | IP محلی Endpoint | داخل LAN |
| srflx | Public Mapping کشف‌شده با STUN | NAT معمولی |
| relay | Media از TURN Server عبور می‌کند | NAT سخت یا شبکه محدود |
STUN Media Relay نیست. STUN فقط کمک می‌کند Public Mapping کشف شود. اگر دو طرف نتوانند مستقیم Media ردوبدل کنند، TURN به‌عنوان Relay وارد مسیر می‌شود.
STUN و TURN در سمت Asterisk
تنظیمات ICE سطح RTP در Asterisk داخل /etc/asterisk/rtp.conf قرار می‌گیرند. برای نمونه:
[general]
stunaddr=stun.example.net
turnaddr=turn.example.net
turnport=3478
turnusername=asterisk-relay
turnpassword=CHANGE_THIS_SECRETاین تنظیمات Candidate Gathering سمت Asterisk را پوشش می‌دهند. اما Browser Client نیز ICE Configuration خودش را لازم دارد. اگر از SIP.js، JsSIP یا WebRTC Library دیگری استفاده می‌کنید، STUN/TURN آن Client باید در تنظیمات همان برنامه تعریف شود.
نمونه عمومی WebRTC در مرورگر:
const peerConnection = new RTCPeerConnection({
iceServers: [
{
urls: 'stun:stun.example.net:3478'
},
{
urls: 'turn:turn.example.net:3478',
username: 'web-user',
credential: 'TURN_PASSWORD'
}
]
});در Production از Credential ثابت و عمومی داخل JavaScript برای TURN استفاده نکنید. بهتر است Credential کوتاه‌عمر یا مکانیزم احراز هویت مناسب TURN داشته باشید.
مرحله ۸: Firewall را برای Signaling و Media جدا تنظیم کنید
برای مثال این مسیرها را در نظر بگیرید:
| کاربرد | پورت نمونه | پروتکل |
|---|---|---|
| HTTPS/WSS Asterisk | 8089 | TCP |
| RTP/SRTP | 10000-20000 | UDP |
| TURN | 3478 یا 5349 | بسته به TURN Config |
Port Range RTP را از rtp.conf خودتان بخوانید؛ اعداد بالا مثال رایج هستند و نباید بدون بررسی Config سرور کپی شوند.
اگر Reverse Proxy جلوی WSS قرار می‌دهید، Port 8089 لازم نیست برای کل اینترنت مستقیم باز باشد؛ Proxy می‌تواند روی 443 Terminate کند و WSS را به Asterisk برساند. در این حالت Upgrade Header و Timeout اتصال‌های WebSocket باید درست تنظیم شوند.
مرحله ۹: داخلی WebRTC را از CLI بررسی کنید
ابتدا Endpoint:
asterisk -rx "pjsip show endpoint 1001-web"Contact:
asterisk -rx "pjsip show contacts"اگر Browser متصل است باید Contact مربوط به داخلی را ببینید.
برای عیب‌یابی کوتاه‌مدت SIP:
asterisk -rvvv
pjsip set logger onبعد از تست خاموش کنید:
pjsip set logger offمشکل ۱: WebSocket اصلاً وصل نمی‌شود
اول این سه مورد را بررسی کنید: DNS دامنه، Certificate و Port WSS.
در مرورگر Developer Tools → Network باید اتصال WebSocket دیده شود. اگر قبل از SIP REGISTER اتصال Fail می‌شود، معمولاً مشکل در TLS/WSS است نه PJSIP Password.
سمت Asterisk:
asterisk -rx "http show status"
ss -lntp | grep 8089مشکل ۲: Registered است ولی صدا نداریم
این یکی از رایج‌ترین سناریوهاست. چون Registration روی WSS انجام شده، Signaling سالم است؛ مشکل احتمالاً Media است.
این موارد را بررسی کنید:
🔹 ICE Candidateها در SDP وجود دارند؟
🔹 DTLS Fingerprint در Offer/Answer هست؟
🔹 RTP Port Range در Firewall باز است؟
🔹 Asterisk پشت NAT است و Public Candidate درست دارد؟
🔹 Browser مجبور به TURN شده ولی TURN Credential/Port مشکل دارد؟
🔹 Codec مشترک مثل Opus یا ulaw بین دو سمت وجود دارد؟
برای تست کوتاه Media:
rtp set debug onاین Debug در سرور پرترافیک بسیار پرحجم است؛ فقط برای مدت کوتاه استفاده کنید و بعد خاموش کنید.
مشکل ۳: میکروفن در مرورگر کار نمی‌کند
اگر تماس Signaling جلو می‌رود ولی Browser Audio Track ندارد، این موارد را بررسی کنید:
🔹 صفحه با HTTPS باز شده باشد.
🔹 Permission میکروفن روی Block نباشد.
🔹 مرورگر Device درست را انتخاب کرده باشد.
🔹 سیستم‌عامل اجازه Microphone را برای Browser بسته نکرده باشد.
🔹 اگر داخل iframe هستید، Permissions Policy اجازه Audio Capture بدهد.
خطاهای رایج JavaScript:
| خطا | معنی محتمل |
|---|---|
| NotAllowedError | کاربر یا Browser Policy دسترسی را رد کرده |
| NotFoundError | Microphone مناسب پیدا نشده |
| NotReadableError | Device وجود دارد ولی قابل استفاده نیست |
مشکل ۴: تماس فقط در بعضی شبکه‌ها کار می‌کند
اگر روی اینترنت خانگی کار می‌کند ولی روی شبکه شرکتی یا دیتای موبایل مشکل دارد، معمولاً ICE/TURN را جدی‌تر بررسی کنید.
شبکه‌های محدود ممکن است UDP مستقیم را Block کنند. در چنین شرایطی Relay Candidate از TURN می‌تواند مسیر Media را نجات دهد. STUN به‌تنهایی برای همه NATها کافی نیست.
یک تست خوب این است که تماس را در سه وضعیت امتحان کنید:
🔹 Browser و Asterisk روی شبکه نزدیک.
🔹 Browser پشت NAT معمولی.
🔹 Browser روی شبکه‌ای که UDP مستقیم محدود است و TURN لازم می‌شود.
آیا برای WebRTC حتماً RTPengine لازم است؟
خیر. Asterisk خودش ICE، DTLS-SRTP، WebSocket و WebRTC Endpoint را پشتیبانی می‌کند و برای یک PBX کوچک یا متوسط می‌تواند مستقیم با Browser کار کند.
RTPengine زمانی جذاب‌تر می‌شود که معماری شما چند Asterisk، چند SIP Proxy، NAT پیچیده، WebRTC پرترافیک یا نیاز به جداسازی Media Plane داشته باشد. در آن حالت Kamailio/OpenSIPS و RTPengine می‌توانند WebRTC Edge را از Backend PBX جدا کنند.
SIP.js یا JsSIP؛ کدام را برای Frontend انتخاب کنیم؟
Asterisk شما را مجبور به یک JavaScript Library خاص نمی‌کند. کافی است Client بتواند SIP over WebSocket و WebRTC Media را درست پیاده‌سازی کند.
دو گزینه رایج در پروژه‌های Web Phone عبارت‌اند از:
🔹 SIP.js: کتابخانه شناخته‌شده برای SIP/WebRTC در JavaScript.
🔹 JsSIP: گزینه دیگر برای SIP over WebSocket و WebRTC.
انتخاب بین این دو بیشتر به API، Framework Frontend، Maintenance و تجربه تیم شما بستگی دارد. مهم‌تر از نام Library این است که WSS، ICE Serverها، Microphone Permission و Call State را درست مدیریت کنید.
برای Production چه چیزهایی را سخت‌گیری کنیم؟
🔹 Certificate معتبر عمومی برای HTTPS/WSS.
🔹 Password قوی و یکتا برای هر داخلی WebRTC.
🔹 محدودکردن Context هر Endpoint به شماره‌های مجاز.
🔹 Rate Limit و Fail2Ban یا Edge Security مناسب.
🔹 TURN Credential امن و ترجیحاً کوتاه‌عمر.
🔹 مانیتورینگ Registration، Call Failure، ICE و Media.
🔹 تست روی Chrome، Firefox، Edge و مرورگرهای موبایل موردنیاز پروژه.
Web Phone عمومی را با داخلی دارای دسترسی نامحدود بین‌الملل روی اینترنت رها نکنید. مهاجم در صورت دسترسی به Credential می‌تواند مستقیماً هزینه تماس ایجاد کند.
مطلب مرتبط: اگر بعد از WebRTC می‌خواهید صدای تماس را به STT یا مدل هوش مصنوعی متصل کنید، راهنمای Voice AI روی VPS را هم ببینید.
چک‌لیست نهایی قبل از تحویل Web Phone
| بررسی | نتیجه مورد انتظار |
|---|---|
| HTTPS سایت | Certificate معتبر بدون Warning |
| WSS | اتصال به /ws برقرار شود |
| PJSIP Transport | transport-wss در CLI دیده شود |
| REGISTER | Contact داخلی WebRTC ثبت شود |
| Microphone | Permission و Audio Track سالم |
| DTLS-SRTP | Media رمزنگاری‌شده Negotiation شود |
| ICE | Candidate Pair موفق انتخاب شود |
| TURN | روی شبکه محدود Relay کار کند |
| Codec | Opus یا Codec مشترک Negotiation شود |
| Firewall | WSS و Media Range لازم باز باشد |
برای راه‌اندازی WebRTC روی Asterisk کمک می‌خواهید؟
اگر دامنه، Certificate، Asterisk و داخلی‌های PJSIP آماده باشند، می‌توان WSS، DTLS-SRTP، ICE و TURN را مرحله‌به‌مرحله تست کرد و یک Web Phone مرورگری برای تیم فروش، پشتیبانی یا مرکز تماس ساخت.
ایرانیکاسرور می‌تواند برای تهیه VPS، نصب و تنظیم Asterisk، TLS/WSS، PJSIP و زیرساخت شبکه موردنیاز WebRTC کمک کند.
تماس با پشتیبانی ایرانیکاسرور: 021-91302467
پرسش‌های رایج
آیا Asterisk مستقیماً از WebRTC پشتیبانی می‌کند؟
بله. Asterisk با PJSIP از WebSocket/WSS، ICE، DTLS-SRTP، RTCP-MUX و WebRTC Endpoint پشتیبانی می‌کند و برای سناریوی ساده لازم نیست حتماً Media Proxy جدا داشته باشید.
WSS در Asterisk چه کاری انجام می‌دهد؟
WSS همان WebSocket رمزنگاری‌شده است که SIP Signaling مرورگر مانند REGISTER و INVITE را به Asterisk می‌رساند. صدای تماس از WSS عبور نمی‌کند.
DTLS-SRTP چیست؟
DTLS برای توافق کلیدهای رمزنگاری Media استفاده می‌شود و SRTP بسته‌های صوتی یا تصویری تماس را رمز می‌کند. گزینه webrtc=yes در PJSIP تنظیمات پایه لازم را فعال می‌کند.
STUN و TURN چه تفاوتی دارند؟
STUN کمک می‌کند Public Mapping و Candidate مناسب کشف شود، اما Media Relay نیست. TURN زمانی استفاده می‌شود که مسیر مستقیم Media برقرار نمی‌شود و ترافیک باید از Relay عبور کند.
چرا مرورگر میکروفن را نمی‌دهد؟
getUserMedia فقط در Secure Context در دسترس است و کاربر نیز باید Permission میکروفن را قبول کند. HTTP ناامن، Block شدن Permission یا محدودیت iframe می‌تواند مانع شود.
برای WebRTC چه Portهایی باید باز باشند؟
Port WSS/HTTPS و Range مربوط به RTP/SRTP باید مطابق Config سرور قابل‌دسترسی باشند. در مثال رسمی Asterisk WSS روی TCP/8089 است، اما Reverse Proxy می‌تواند آن را پشت 443 منتشر کند.
آیا Certificate خودامضا برای WSS کافی است؟
برای تست ممکن است با Exception مرورگر قابل استفاده باشد، اما Asterisk برای استفاده عملی Certificate مورداعتماد عمومی را توصیه می‌کند؛ مرورگرها معمولاً اتصال WSS با Certificate خودامضا را Block می‌کنند.
اگر داخلی Registered است ولی صدا ندارد، از کجا شروع کنیم؟
ICE Candidateها، DTLS Fingerprint، RTP Port Range، NAT، TURN و Codec مشترک را بررسی کنید. Registered بودن فقط سلامت Signaling را ثابت می‌کند، نه Media را.
جمع‌بندی
برای ساخت Web Phone روی Asterisk چهار بخش باید هم‌زمان سالم باشند: HTTPS صفحه وب، WSS برای SIP Signaling، DTLS-SRTP برای Media امن و ICE برای پیدا کردن مسیر قابل‌دسترسی بین Browser و PBX.
گزینه webrtc=yes در PJSIP بخش بزرگی از تنظیمات Endpoint را ساده می‌کند، اما Certificate، WSS Transport، Firewall، STUN/TURN و Browser Permission همچنان باید جداگانه درست شوند.
اگر REGISTER موفق است ولی صدا ندارید، تمرکز را از Password و SIP Auth بردارید و سراغ ICE/DTLS/RTP بروید. اگر حتی WebSocket وصل نمی‌شود، ابتدا Certificate، HTTPS Server و Port WSS را بررسی کنید.
برای یک PBX کوچک، Asterisk به‌تنهایی WebRTC را پوشش می‌دهد. وقتی تعداد Browserها، NATها یا Backendها زیاد شد، می‌توانید در مرحله بعد Kamailio/OpenSIPS و RTPengine را برای Edge و Media Scaling به معماری اضافه کنید.
برای راه‌اندازی Asterisk WebRTC کمک می‌خواهید؟
اگر Asterisk و دامنه آماده باشند، می‌توان ابتدا HTTPS/WSS، سپس PJSIP Registration و در نهایت ICE/DTLS-SRTP را تست کرد تا محل خطا دقیق مشخص شود.
تماس با پشتیبانی ایرانیکاسرور: 021-91302467
دیدگاه‌ها (۰)