مجله ایرانیکاسرورآموزش سرور، هاست، وردپرس و شبکه
آموزشی

راه‌اندازی VoIP روی IPv6؛ حذف NAT چه تغییری در SIP و RTP ایجاد می‌کند؟

VoIP روی IPv6 از نظر SIP و RTP شدنی و در بسیاری از شبکه‌ها حتی ساده‌تر از IPv4 است، اما «فقط روشن‌کردن IPv6» کافی نیست. مهم‌ترین تغییر این است که دیگر لازم نیست برای…

راه‌اندازی VoIP روی IPv6؛ حذف NAT چه تغییری در SIP و RTP ایجاد می‌کند؟
خلاصه سریع این آموزش

VoIP روی IPv6 از نظر SIP و RTP شدنی و در بسیاری از شبکه‌ها حتی ساده‌تر از IPv4 است، اما «فقط روشن‌کردن IPv6» کافی نیست. مهم‌ترین تغییر این است که…

۱۳ دقیقه مطالعه ۰ دیدگاه ۲۸ مهر ۱۴۰۵ آخرین به‌روزرسانی

VoIP روی IPv6 از نظر SIP و RTP شدنی و در بسیاری از شبکه‌ها حتی ساده‌تر از IPv4 است، اما «فقط روشن‌کردن IPv6» کافی نیست. مهم‌ترین تغییر این است که دیگر لازم نیست برای هر تماس با NAT44، Port Forward و Rewrite آدرس خصوصی به عمومی درگیر شوید؛ در عوض باید DNS، SIP URI، SDP، Firewall و سازگاری Provider را برای IPv6 درست طراحی کنید.

در IPv6، Endpoint می‌تواند یک Global IPv6 واقعی داشته باشد و SIP و RTP مستقیم‌تر Route شوند. این موضوع بسیاری از دردسرهای NAT را کم می‌کند، اما امنیت را خودکار بهتر نمی‌کند؛ چون اگر Firewall درست نباشد، همان Endpoint یا PBX می‌تواند مستقیماً از اینترنت قابل‌دسترسی باشد.

در این راهنما تفاوت‌های عملی VoIP IPv6 را بررسی می‌کنیم: رکوردهای AAAA، فرمت SIP URI با IPv6، SDP و RTP روی IP6، تنظیم PJSIP در Asterisk، Dual Stack، Firewall و ICMPv6، حذف NAT، و مهم‌تر از همه اینکه وقتی Provider هنوز فقط IPv4 است چه معماری‌ای باید استفاده کنیم.

جواب کوتاه: برای VoIP روی IPv6 باید هم Signaling و هم Media واقعاً IPv6 را پشتیبانی کنند. داشتن AAAA Record برای PBX کافی نیست؛ SIP Server، Endpoint، Firewall و Provider باید مسیر IPv6 را بپذیرند و SDP هم آدرس IPv6 قابل‌دسترسی اعلام کند.

فهرست مطالب

در VoIP روی IPv6 چه چیزی واقعاً تغییر می‌کند؟

سه لایه را جدا ببینید:

لایه در IPv4 معمول در IPv6
DNS A Record AAAA + در Dual Stack همچنان A
SIP Signaling IPv4 Address/Hostname IPv6 Literal یا Hostname دارای AAAA
RTP/SDP c=IN IP4 c=IN IP6
NAT رایج و اغلب دردسرساز برای Global IPv6 معمولاً لازم نیست
Firewall NAT گاهی ناخواسته نقش فیلتر دارد باید صریح و درست طراحی شود
Provider تقریباً همیشه پشتیبانی می‌شود باید جداگانه تأیید شود

AAAA Record؛ نقطه شروع DNS برای SIP روی IPv6

اگر SIP Server شما با IPv6 قابل‌دسترسی است، FQDN آن باید AAAA Record داشته باشد.

نمونه:

sip.example.com. 300 IN AAAA 2001:db8:1200::20

اگر همان سرویس هم IPv4 و هم IPv6 دارد، Dual Stack بهتر است:

sip.example.com. 300 IN A    198.51.100.20
sip.example.com. 300 IN AAAA 2001:db8:1200::20

RFC 6157 برای محیط‌های Dual Stack توصیه می‌کند Proxyها و سرویس‌های SIP هم IPv4 و هم IPv6 را پشتیبانی کنند و DNS نیز A و AAAA مناسب داشته باشد. Client IPv4 فقط A را استفاده می‌کند، Client IPv6 فقط AAAA را می‌بیند و Client Dual Stack می‌تواند بر اساس Reachability یکی را انتخاب کند.

SRV و NAPTR هنوز مهم‌اند

SIP فقط با A/AAAA کار نمی‌کند. RFC 3263 برای پیدا کردن SIP Server از DNS NAPTR و SRV نیز استفاده می‌کند تا Transport، Port و Server مناسب تعیین شود.

برای مثال:

_sip._udp.example.com. 300 IN SRV 10 10 5060 sip1.example.com.
_sip._tcp.example.com. 300 IN SRV 10 10 5060 sip1.example.com.
_sips._tcp.example.com. 300 IN SRV 10 10 5061 sip1.example.com.

sip1.example.com. 300 IN A    198.51.100.20
sip1.example.com. 300 IN AAAA 2001:db8:1200::20

مزیت این طراحی این است که SIP URI شما به یک Domain وابسته می‌ماند و لازم نیست IPv4 یا IPv6 را داخل تمام Endpointها Hardcode کنید.

SIP URI با IPv6 چه شکلی است؟

اگر به‌جای Hostname، خود IPv6 Literal را داخل SIP URI بنویسید، IPv6 باید داخل براکت قرار گیرد. RFC 3261 این فرمت را به‌عنوان IPv6 Reference تعریف می‌کند.

درست:

sip:1001@[2001:db8:1200::20]:5060

با Transport:

sip:1001@[2001:db8:1200::20]:5061;transport=tls

اشتباه:

sip:1001@2001:db8:1200::20:5060

بدون براکت، جداکردن بخش Address و Port مبهم می‌شود.

پیشنهاد عملی: حتی روی IPv6 بهتر است Endpointها را با FQDN تنظیم کنید، نه Literal IP. این کار تغییر Provider، Failover و جابه‌جایی Address را ساده‌تر می‌کند.

SDP و RTP روی IPv6 چه تغییری می‌کنند؟

SIP تماس را ایجاد می‌کند، اما آدرس Media داخل SDP قرار می‌گیرد. در SDP جدید، Address Type می‌تواند IP4 یا IP6 باشد.

نمونه IPv4:

v=0
o=- 123 123 IN IP4 198.51.100.20
s=-
c=IN IP4 198.51.100.20
t=0 0
m=audio 18000 RTP/AVP 0 8

نمونه IPv6:

v=0
o=- 123 123 IN IP6 2001:db8:1200::20
s=-
c=IN IP6 2001:db8:1200::20
t=0 0
m=audio 18000 RTP/AVP 0 8

RFC 8866 برای Connection Information صریحاً IP4 و IP6 را تعریف می‌کند. بنابراین فقط SIP Transport کافی نیست؛ اگر SIP روی IPv6 است ولی SDP هنوز IPv4 غیرقابل‌دسترسی اعلام کند، Media می‌تواند شکست بخورد.

آیا روی IPv6 دیگر NAT نداریم؟

در سناریوی استاندارد Global IPv6 معمولاً NAT44 لازم نیست. هر Interface می‌تواند Global Unicast Address قابل Route داشته باشد و Firewall مشخص کند چه Trafficی مجاز است.

این تغییر برای SIP و RTP مهم است، چون بسیاری از مشکلات کلاسیک VoIP از Rewrite نشدن Contact، Via و SDP پشت NAT می‌آیند.

IPv4 typical:
Phone -> Private IPv4 -> NAT -> Public IPv4 -> PBX

IPv6 typical:
Phone -> Global IPv6 -> Firewall -> PBX

اما حذف NAT مساوی حذف Firewall نیست. NAT یک Security Feature کامل نیست، ولی در شبکه IPv4 خیلی وقت‌ها باعث می‌شود اتصال ورودی بدون Port Forward عملاً به Host نرسد. در IPv6 باید Firewall ورودی را آگاهانه تنظیم کنید.

Global IPv6 به معنی «همه پورت‌ها باز» نیست

اگر PBX آدرس Global دارد، فقط پورت‌های لازم را باز کنید و Source را تا جای ممکن محدود کنید.

برای مثال با UFW:

ufw default deny incoming
ufw default allow outgoing

ufw allow from 2001:db8:5000::/48 to any port 5061 proto tcp
ufw allow from 2001:db8:5000::/48 to any port 10000:20000 proto udp

Range بالا فقط نمونه مستنداتی است و باید با Prefix واقعی Provider یا Site خودتان جایگزین شود.

اگر Endpointهای Remote از Prefixهای متغیر می‌آیند، ACL تنها بر اساس IP ممکن است کافی نباشد و باید TLS، Authentication، SBC یا VPN را هم وارد معماری کنید.

ICMPv6 را کورکورانه Block نکنید

یکی از اشتباه‌های رایج مهاجرت IPv4 به IPv6 این است که Admin همان Policy قدیمی «همه ICMP را ببند» را روی IPv6 اجرا می‌کند.

RFC 4890 تأکید می‌کند ICMPv6 بخشی اساسی از عملکرد IPv6 است و Filtering بیش‌ازحد می‌تواند ارتباط را خراب کند. پیام‌هایی مانند Packet Too Big برای Path MTU Discovery لازم‌اند.

این موضوع در VoIP هم مهم است؛ مخصوصاً وقتی SIP/TLS، VPN، SRTP یا Tunnel دارید و MTU مسیر کوچک‌تر از چیزی است که تصور می‌کنید.

نتیجه: ICMPv6 را به‌صورت Policy-aware فیلتر کنید، نه اینکه همه آن را Drop کنید. Packet Too Big و پیام‌های ضروری Neighbor/Path Discovery باید طبق طراحی شبکه عبور کنند.

MTU در IPv6 کمی جدی‌تر است

RFC 8200 حداقل MTU لینک IPv6 را ۱۲۸۰ بایت تعیین می‌کند و استفاده از Path MTU Discovery را توصیه می‌کند. اگر Packet بزرگ‌تر از MTU مسیر باشد، Source باید با کمک ICMPv6 Packet Too Big اندازه مناسب را پیدا کند.

برای RTP صوتی معمولی Packetها کوچک‌اند، اما این مشکلات ممکن است در این موارد دیده شوند:

🔹 SIP Message بزرگ روی UDP.

🔹 TLS.

🔹 VPN یا Tunnel.

🔹 WebRTC/DTLS/SRTP.

🔹 IPv6 Extension Headerها.

Asterisk PJSIP را چطور روی IPv6 فعال کنیم؟

مستند رسمی Asterisk برای IPv6 پیشنهاد می‌کند Transport جداگانه IPv6 بسازید.

UDP روی تمام Interfaceهای IPv6:

[transport-udp6]
type=transport
protocol=udp
bind=::

TLS روی IPv6:

[transport-tls6]
type=transport
protocol=tls
bind=[2001:db8:1200::20]:5061

cert_file=/etc/asterisk/keys/fullchain.pem
priv_key_file=/etc/asterisk/keys/privkey.pem

Endpoint:

[ipv6-phone]
type=endpoint
transport=transport-tls6
context=from-internal

disallow=all
allow=opus,ulaw

Asterisk توضیح می‌دهد وقتی Endpoint از IPv6 برای Signaling استفاده می‌کند، RTP نیز بدون تنظیم پیچیده اضافی می‌تواند بر اساس Address Family مربوطه روی IPv6 کار کند.

برای Dual Stack یک Transport مشترک نسازید

در Asterisk/PJSIP بهتر است IPv4 و IPv6 Transportهای جدا داشته باشید:

[transport-udp4]
type=transport
protocol=udp
bind=0.0.0.0:5060

[transport-udp6]
type=transport
protocol=udp
bind=[::]:5060

مستند Asterisk هشدار می‌دهد که استفاده از Wildcard IPv6 برای پوشش هم‌زمان IPv4 و IPv6 می‌تواند به IPv4-mapped IPv6 Address منجر شود که PJSIP پشتیبانی نمی‌کند و ممکن است SIP Parsing را خراب کند.

Dual Stack بهترین مسیر مهاجرت است

اگر امروز همه تلفن‌ها و Providerها IPv6 نیستند، IPv4 را حذف نکنید. Dual Stack معمولاً امن‌ترین مسیر مهاجرت است.

Phones
  |
  | IPv4 or IPv6
  v
Dual-Stack PBX / SBC
  |
  +--> IPv6 Provider
  |
  +--> IPv4-only Provider

RFC 6157 نیز Dual Stack Proxy و User Agent را در دوره مهاجرت توصیه می‌کند؛ چون Signaling و Media باید هر دو بتوانند Address Family سازگار پیدا کنند.

اگر DNS هم A و هم AAAA دارد چه می‌شود؟

سیستم‌عامل و Application بر اساس Address Selection Policy تصمیم می‌گیرند کدام Address را ترجیح دهند. RFC 6724 الگوریتم انتخاب Source و Destination را برای Dual Stack توضیح می‌دهد؛ بنابراین تصور نکنید وجود AAAA یعنی همه Clientها حتماً IPv6 را انتخاب می‌کنند.

در VoIP باید هر دو مسیر را جدا تست کنید:

dig A sip.example.com
dig AAAA sip.example.com

ping -4 sip.example.com
ping -6 sip.example.com

اگر SIP Signaling روی IPv6 و Provider فقط IPv4 باشد چه کنیم؟

این یکی از مهم‌ترین سناریوهای واقعی است. ممکن است شبکه داخلی و PBX شما IPv6 داشته باشند، ولی Carrier هنوز IPv4-only باشد.

در این حالت یک Dual-Stack SBC یا Proxy بین دو سمت قرار دهید:

IPv6 Phones
     |
     v
Dual-Stack SBC
 IPv6 + IPv4
     |
     v
IPv4-only SIP Provider

SBC می‌تواند Signaling و در صورت نیاز Media را بین دو Address Family Interwork کند.

Provider Compatibility را حدس نزنید

اینکه Provider یک Hostname دارد یا Website آن روی IPv6 باز می‌شود، به معنی پشتیبانی SIP Trunk از IPv6 نیست. باید مستندات Signaling و Media همان محصول را بررسی کنید.

نمونه واقعی در زمان بررسی این مقاله: Help Center رسمی Twilio صریحاً اعلام می‌کند Endpointهای Programmable Voice SIP Domains و Elastic SIP Trunking آن در حال حاضر فقط IPv4 Connectivity دارند و برای SIP Clientهای IPv6 استفاده از Dual-Stack SBC را پیشنهاد می‌کند.

یعنی این Architecture:

Asterisk IPv6-only
       |
       X direct connection
       |
Twilio SIP endpoint (IPv4-only)

باید به چیزی شبیه این تبدیل شود:

Asterisk IPv6
      |
      v
Dual-Stack SBC
      |
      v
IPv4 SIP Provider

این محدودیت ممکن است در Provider دیگر متفاوت باشد؛ قبل از Cutover هم Signaling و هم Media Range را تست کنید.

Link-Local IPv6 برای SIP Trunk اینترنتی مناسب نیست

IPv6 آدرس‌های مختلفی دارد. fe80::/10 Link-Local است و Router نباید آن را به Link دیگر Forward کند. بنابراین برای SIP Server اینترنتی یا Trunk بین Siteها از Link-Local استفاده نکنید.

نمونه Link-Local:

fe80::a00:27ff:fe12:3456

برای ارتباط Routeable از Global IPv6 یا در شبکه خصوصی از Prefix مناسب طراحی‌شده استفاده کنید.

چه چیزهایی از NAT Troubleshooting حذف می‌شوند؟

در یک مسیر IPv6 End-to-End واقعی، مشکلات زیر معمولاً کمتر می‌شوند:

🔹 Contact Rewrite به‌خاطر Private IPv4.

🔹 SIP ALG برای ترجمه NAT.

🔹 Port Forward برای RTP.

🔹 NAT Mapping Timeout.

🔹 Symmetric RTP صرفاً برای NAT traversal.

اما مشکلات جدید یا مهم‌تر عبارت‌اند از:

🔹 Firewall IPv6 اشتباه.

🔹 AAAA Record ناسالم.

🔹 Provider IPv4-only.

🔹 انتخاب Address Family اشتباه در Dual Stack.

🔹 ICMPv6 Filtering.

🔹 MTU/PMTUD.

چک‌لیست تست قبل از مهاجرت SIP به IPv6

تست انتظار
AAAA Lookup IPv6 صحیح Server برگردد
SIP REGISTER Contact/Via IPv6 معتبر
تماس خروجی INVITE و پاسخ روی IPv6
SDP c=IN IP6 با Address قابل Route
RTP دوطرفه Audio در هر دو جهت
Firewall فقط SIP/RTP لازم باز باشد
ICMPv6 پیام‌های ضروری مسدود نشده باشند
Dual Stack IPv4 و IPv6 جداگانه کار کنند
Provider پشتیبانی IPv6 Signaling/Media تأیید شده باشد
Failover در خرابی IPv6 مسیر جایگزین مشخص باشد

دستورهای ساده برای عیب‌یابی

بررسی IPv6 Server:

ip -6 addr
ip -6 route

DNS:

dig AAAA sip.example.com
dig SRV _sip._udp.example.com

Listening Port:

ss -lntup | grep -E '5060|5061'

Asterisk:

asterisk -rvvv
pjsip show transports
pjsip show endpoints
pjsip set logger on

Packet Capture IPv6 SIP:

tcpdump -ni any -s0 \
  -w /tmp/sip-ipv6.pcap \
  'ip6 and (udp port 5060 or tcp port 5060 or tcp port 5061)'

اشتباه‌های رایج

🔹 اضافه‌کردن AAAA بدون تست واقعی SIP و RTP.

🔹 فرض اینکه حذف NAT یعنی Firewall لازم نیست.

🔹 استفاده از Link-Local برای Trunk Routeable.

🔹 قراردادن Literal IPv6 بدون براکت در SIP URI.

🔹 استفاده از Wildcard IPv6 به‌عنوان Transport مشترک IPv4/IPv6 در PJSIP.

🔹 Block کردن کامل ICMPv6.

🔹 فرض اینکه Provider چون Website IPv6 دارد، SIP Trunk آن هم IPv6 است.

🔹 تست فقط Signaling و فراموش‌کردن SDP/RTP.

IPv6 می‌تواند NAT را حذف کند، اما طراحی SIP و Firewall همچنان مهم است

برای راه‌اندازی Asterisk یا SBC روی IPv6 کمک می‌خواهید؟

اگر Provider، Endpointها و شبکه شما مشخص باشند، می‌توان Dual Stack، DNS، Firewall، PJSIP و Media Path را طوری طراحی کرد که هم IPv4 و هم IPv6 بدون One-Way Audio و Registration Failure کار کنند.

ایرانیکاسرور می‌تواند VPS و زیرساخت مناسب برای Asterisk، SBC و سرویس‌های VoIP را فراهم کند.

تماس با پشتیبانی ایرانیکاسرور: 021-91302467

پرسش‌های رایج

آیا SIP روی IPv6 کار می‌کند؟

بله. SIP از IPv6 پشتیبانی می‌کند و در SIP URI نیز IPv6 Literal داخل براکت قرار می‌گیرد. DNS AAAA و Transport مناسب باید درست تنظیم شوند.

آیا RTP هم روی IPv6 کار می‌کند؟

بله. در SDP از addrtype برابر IP6 استفاده می‌شود و RTP می‌تواند مستقیم روی IPv6 جابه‌جا شود، به شرط اینکه هر دو سمت Media IPv6 را پشتیبانی کنند.

آیا روی IPv6 دیگر NAT لازم نیست؟

در مسیر Global IPv6 معمولاً NAT44 لازم نیست؛ اما Firewall همچنان ضروری است و باید SIP، RTP و ICMPv6 موردنیاز را دقیق کنترل کند.

برای SIP Server روی IPv6 باید A Record را حذف کنیم؟

نه در مهاجرت معمول. بهتر است Dual Stack داشته باشید و A و AAAA را هم‌زمان نگه دارید تا Clientهای IPv4 و IPv6 هر دو سرویس بگیرند.

اگر Provider فقط IPv4 باشد چه کنیم؟

یک Dual-Stack SBC یا Proxy بین PBX IPv6 و Provider IPv4 قرار دهید. این لایه می‌تواند Signaling و در صورت نیاز Media را بین دو Address Family Interwork کند.

چرا Link-Local برای SIP Trunk مناسب نیست؟

آدرس‌های fe80::/10 فقط روی همان Link معتبرند و Router آن‌ها را به Link دیگر Forward نمی‌کند. برای Trunk اینترنتی باید Address Routeable داشته باشید.

آیا می‌توان ICMPv6 را کامل بست؟

توصیه نمی‌شود. بعضی پیام‌های ICMPv6 برای Path MTU Discovery و عملکرد صحیح IPv6 ضروری‌اند. Filtering باید هدفمند باشد.

آیا Asterisk از IPv6 پشتیبانی می‌کند؟

بله. res_pjsip از IPv6 پشتیبانی می‌کند و مستند رسمی Asterisk نحوه ساخت Transportهای IPv6 و Dual Stack را توضیح می‌دهد.

جمع‌بندی

VoIP روی IPv6 به‌خودی‌خود پیچیده نیست؛ بسیاری از پیچیدگی‌های NAT حذف می‌شوند و Endpointها می‌توانند با Global Address واقعی ارتباط داشته باشند.

اما DNS و SIP URI باید IPv6-aware باشند، SDP باید آدرس IP6 درست بدهد، Firewall باید صریح طراحی شود و ICMPv6 نباید کورکورانه Block شود.

برای مهاجرت، Dual Stack معمولاً بهترین انتخاب است. IPv4 را تا زمانی که همه Endpointها، SBCها و Providerها واقعاً IPv6 را پشتیبانی نکرده‌اند حذف نکنید.

و مهم‌تر از همه، Provider Compatibility را مستند و آزمایش کنید. پشتیبانی IPv6 روی Website یا API یک شرکت، تضمین‌کننده IPv6 بودن SIP Trunk آن نیست.

منابع و مستندات
SIP روی IPv6، AAAA، SIP URI، SDP، Dual Stack، PJSIP، ICMPv6 و Provider Compatibility این مقاله با منابع رسمی تا ۲۰ اکتبر ۲۰۲۶ بررسی شده‌اند.
RFC SIP
مرجع فرمت IPv6 Reference داخل SIP URI و Syntax اصلی SIP.
RFC SIP/IPv6
مرجع Dual Stack SIP Proxy/User Agent، A/AAAA و Interworking بین IPv4 و IPv6 در Signaling و Media.
RFC SIP DNS
مرجع DNS SRV/NAPTR و انتخاب SIP Server.
RFC SDP
مرجع c=IN IP6 و Address Typeهای IP4/IP6 در SDP.
Asterisk IPv6
مرجع Transport IPv6، bind روی :: و استفاده RTP روی IPv6 در PJSIP.
Asterisk Dual Stack
مرجع Transportهای جداگانه IPv4/IPv6 و هشدار درباره IPv4-mapped IPv6 Address.
RFC ICMPv6
مرجع اهمیت ICMPv6 و پیام‌های ضروری مانند Packet Too Big برای ارتباط صحیح IPv6.
RFC IPv6
مرجع حداقل MTU IPv6، Fragmentation در Source و Path MTU Discovery.
Provider Example
نمونه واقعی Provider که در زمان بررسی، SIP Trunk Endpoint آن IPv4-only است و Dual-Stack SBC را برای Clientهای IPv6 پیشنهاد می‌کند.
اشتراک‌گذاری مقاله
گفت‌وگو درباره آموزش

دیدگاه‌ها (۰)

هنوز دیدگاهی ثبت نشده است.

دیدگاه یا سؤال خود را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *