Amir Jabbari
خطای SIP 488 Not Acceptable Here معمولاً یعنی طرف مقابل خود تماس را پیدا کرده، اما SDP پیشنهادی را با شرایط فعلی قابل‌قبول نمی‌داند. به زبان ساده، Signaling تا مقصد رسیده است، اما دو سمت روی Media به توافق نرسیده‌اند. این اختلاف می‌تواند از Codec باشد، اما فقط Codec نیست؛ نوع RTP، الزام SRTP، DTLS، T.38 Fax، Media Type، پارامترهای SDP و حتی Policy مربوط به Transcoding هم می‌توانند 488 بسازند.
برای همین، وقتی 488 می‌بینید نباید فقط allow=ulaw را عوض کنید و امیدوار باشید مشکل حل شود. روش درست این است که SDP Offer را با چیزی که Endpoint، PBX یا Provider واقعاً قبول می‌کند مقایسه کنید. در Asterisk/PJSIP هم اگر نتیجه مذاکره Codec به یک Media Topology خالی برسد، خود Asterisk می‌تواند تماس را با 488 رد کند.
در این راهنما از خود پیام SIP شروع می‌کنیم، Offer/Answer را می‌خوانیم، Codecها را تطبیق می‌دهیم، تفاوت RTP و SRTP را بررسی می‌کنیم، T.38 Fax را جدا می‌کنیم و در پایان مشخص می‌کنیم چه زمانی Transcoding راه‌حل است و چه زمانی فقط مشکل اصلی را پنهان می‌کند.
جواب کوتاه: SIP 488 بیشتر از آنکه «خطای شبکه» باشد، یک خطای Media Negotiation است. اول SDP را ببینید. اگر Codec مشترک ندارید، Codec/Transcoding را اصلاح کنید. اگر Codec مشترک هست اما RTP Profile یا SRTP/DTLS دو سمت متفاوت است، مشکل امنیت Media است. اگر 488 هنگام Fax یا re-INVITE ظاهر می‌شود، T.38 و UDPTL را جدا بررسی کنید.
SIP 488 Not Acceptable Here دقیقاً یعنی چه؟
RFC 3261 توضیح می‌دهد پاسخ 488 معنی مشابه 606 Not Acceptable دارد، اما فقط برای همان Resource مشخص‌شده در Request-URI اعمال می‌شود. همچنین پاسخ می‌تواند توضیحی از Media Capabilityهای قابل‌قبول طرف مقابل داشته باشد.
نکته مهم‌تر این است که 488 معمولاً در یکی از این دو نقطه دیده می‌شود:
🔹 INVITE اولیه: طرف مقابل SDP اولیه را قبول نمی‌کند و Call Setup متوقف می‌شود.
🔹 re-INVITE داخل تماس: تغییر جدید Media قبول نمی‌شود؛ طبق RFC 3261 خود تماس موجود می‌تواند با Media قبلی ادامه پیدا کند.
INVITE + SDP Offer
|
v
SIP/2.0 488 Not Acceptable Here
|
+--> Codec?
+--> RTP profile?
+--> SRTP/DTLS?
+--> T.38?
+--> unsupported media?
+--> transcoding policy?قبل از هر تغییر، SDP Offer را از Trace بیرون بکشید
روی Asterisk/PJSIP:
asterisk -rvvv
core set verbose 4
core set debug 4
pjsip set logger onتماس خراب را یک بار تکرار کنید و سپس Logger را خاموش کنید:
pjsip set logger offدر INVITE یا re-INVITE بخش SDP معمولاً شبیه این است:
v=0
o=- 1720000000 1720000000 IN IP4 203.0.113.10
s=Asterisk
c=IN IP4 203.0.113.10
t=0 0
m=audio 17824 RTP/AVP 111 0 8
a=rtpmap:111 opus/48000/2
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=sendrecvبرای خطای 488، این بخش‌ها از همه مهم‌ترند:
🔹 خط m=audio یا m=video.
🔹 RTP Profile مثل RTP/AVP، RTP/SAVP یا UDP/TLS/RTP/SAVPF.
🔹 Payload Typeها بعد از Profile.
🔹 خطوط a=rtpmap و a=fmtp.
🔹 خطوط SRTP/DTLS مثل a=crypto یا a=fingerprint.
🔹 برای Fax، خط m=image و image/t38.
SDP Offer/Answer چطور کار می‌کند؟
RFC 3264 مدل Offer/Answer را تعریف می‌کند. یک سمت Media Streamها، Codecها، IP و Port موردنظرش را پیشنهاد می‌دهد و سمت دیگر باید Answer سازگاری برگرداند. برای تماس Unicast، دو طرف باید روی مجموعه‌ای مشترک از Media Capabilityها توافق کنند.
برای Codec، ساده‌ترین مثال این است:
Caller offers:
Opus, PCMU
Callee supports:
PCMA, G729
Intersection:
EMPTY
Result:
No acceptable audio format
-> 488 possibleRFC 3264 نیز صریحاً توضیح می‌دهد در تماس Unicast مجموعه Codec نهایی از هم‌پوشانی Capabilityهای دو طرف به دست می‌آید.
علت اول: هیچ Codec مشترکی وجود ندارد
این رایج‌ترین توضیح برای 488 است، اما باید با Trace ثابت شود.
مثلاً Provider فقط PCMA می‌پذیرد:
Provider:
PCMA / payload 8
Asterisk endpoint:
Opus / payload 111
PCMU / payload 0
Common codec:
Noneدر Asterisk Endpoint:
[provider]
type=endpoint
disallow=all
allow=alaw,ulawبرای بررسی Codecهای Endpoint:
asterisk -rx "pjsip show endpoint provider"در Asterisk، Topology خالی می‌تواند مستقیماً 488 بسازد
مستند رسمی Advanced Codec Negotiation در Asterisk یک سناریوی دقیق توضیح می‌دهد: اگر Codecهای Offer ورودی با Codecهای مجاز Endpoint هیچ Intersection قابل‌استفاده‌ای نداشته باشند و Media Topology حل‌شده خالی شود، Asterisk می‌تواند Call را فوراً با 488 Not Acceptable Here تمام کند.
Asterisk برای کنترل مذاکره Codec چند نقطه تنظیم دارد:
🔹 codec_prefs_incoming_offer
🔹 codec_prefs_outgoing_offer
🔹 codec_prefs_incoming_answer
🔹 codec_prefs_outgoing_answer
مثال:
codec_prefs_incoming_offer =
prefer: pending,
operation: intersect,
keep: all,
transcode: allowدر Production این گزینه‌ها را فقط زمانی تغییر دهید که دقیقاً می‌دانید Offer ورودی و Policy مطلوب شما چیست؛ تغییر تصادفی ترتیب Codecها می‌تواند Interop را بدتر کند.
علت دوم: Codec مشترک دارید، اما RTP Profile دو سمت فرق دارد
وجود PCMU در هر دو سمت کافی نیست. نوع Transport Media هم باید قابل‌قبول باشد.
| SDP Profile | کاربرد معمول |
|---|---|
RTP/AVP |
RTP معمولی بدون SRTP |
RTP/SAVP |
Secure RTP |
RTP/AVPF |
RTP با Feedback Profile |
UDP/TLS/RTP/SAVPF |
DTLS-SRTP، رایج در WebRTC |
مثلاً Provider فقط RTP معمولی می‌پذیرد اما Endpoint شما Offer امن اجباری می‌فرستد:
m=audio 17824 RTP/SAVP 0 8اگر سمت مقابل فقط RTP/AVP را قبول کند، مشکل از Codec نیست؛ Media Security Profile ناسازگار است.
علت سوم: SRTP یا DTLS دو طرف با هم سازگار نیست
در PJSIP، Asterisk سه حالت اصلی برای media_encryption دارد:
| مقدار | معنی |
|---|---|
no |
Media بدون Encryption |
sdes |
SRTP با Key داخل SDP |
dtls |
DTLS-SRTP |
مثال Endpoint با SDES-SRTP:
[secure-provider]
type=endpoint
media_encryption=sdes
disallow=all
allow=alaw,ulawمثال WebRTC/DTLS:
[browser]
type=endpoint
webrtc=yes
disallow=all
allow=opus,ulawاگر یک سمت SDES می‌خواهد و سمت دیگر DTLS-SRTP، وجود Codec مشترک مشکل را حل نمی‌کند. یا باید PBX/Media Proxy بین این دو Profile Bridge کند یا Policy Media را تغییر دهید.
چطور بفهمیم مشکل SRTP است نه Codec؟
اگر در Offer و Answer Codec مشترک واضح دارید، بعد Profile و Attributeهای Security را مقایسه کنید.
SDES معمولاً چیزی شبیه این دارد:
m=audio 17824 RTP/SAVP 0 8
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:...DTLS-SRTP معمولاً Attributeهای Fingerprint و Setup دارد:
m=audio 17824 UDP/TLS/RTP/SAVPF 111 0
a=fingerprint:sha-256 ...
a=setup:actpassاگر Provider اعلام کرده SRTP را پشتیبانی نمی‌کند اما شما RTP/SAVP می‌فرستید، 488 پاسخ منطقی‌تری از تغییر Codec است.
علت چهارم: پارامترهای Codec یا SDP با Policy مقصد سازگار نیست
دو طرف ممکن است نام Codec مشترک داشته باشند اما پارامترهای آن یکسان نباشد. این موضوع بیشتر در Codecهای Dynamic و Mediaهای پیچیده دیده می‌شود.
مثال Opus:
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10;useinbandfec=1همچنین SDP ممکن است Media Stream یا Profileی پیشنهاد دهد که مقصد اصلاً قبول نمی‌کند؛ مثلاً Video به Gateway صوتی، یا Multiple Media Stream به تجهیز Legacy.
RFC 4566 تعریف می‌کند هر Media Stream در SDP با خط m= مشخص می‌شود و Payload Typeهای Dynamic باید با a=rtpmap توضیح داده شوند.
علت پنجم: 488 هنگام Fax؛ T.38 را جدا بررسی کنید
یکی از مهم‌ترین سناریوهای 488 این است که تماس صوتی برقرار شده، Fax Tone تشخیص داده می‌شود و یک re-INVITE برای تغییر Media از Audio/RTP به T.38 ارسال می‌شود؛ طرف مقابل T.38 را قبول نمی‌کند و 488 برمی‌گرداند.
T.38 در SDP با Media Type image/t38 شناخته می‌شود. RFC 3362 این MIME Type را برای انتقال Fax بلادرنگ تعریف می‌کند.
نمونه ساده:
m=image 4000 udptl t38
a=T38FaxVersion:0
a=T38MaxBitRate:14400در Asterisk PJSIP:
[fax-provider]
type=endpoint
t38_udptl=yes
t38_udptl_nat=yes
t38_udptl_ec=redundancyاگر Provider یا ATA اصلاً T.38 را پشتیبانی نمی‌کند، فعال‌کردن آن فقط در Asterisk کافی نیست.
Portهای T.38 با RTP یکی نیستند
Asterisk برای UDPTL فایل تنظیم جداگانه udptl.conf دارد. در مستند فعلی، Range پیش‌فرض UDPTL از 4000 تا 4999 است.
[general]
udptlstart=4000
udptlend=4999اگر T.38 Negotiation موفق شود ولی UDPTL Range در Firewall بسته باشد، ممکن است 488 نگیرید اما Fax Media شکست بخورد. پس Signaling و Media را با هم قاطی نکنید.
آیا Transcoding خطای 488 را حل می‌کند؟
فقط وقتی مشکل واقعاً «نبود Codec مشترک بین دو Leg» باشد و Asterisk یا Media Server Codecهای لازم را بتواند Transcode کند.
مثال:
Phone leg:
Opus
Provider leg:
PCMA
Asterisk:
Opus <-> PCMA transcodingاما Transcoding این مشکلات را حل نمی‌کند:
🔹 Provider SRTP را قبول نمی‌کند ولی شما SRTP اجباری می‌فرستید.
🔹 SDP Profile اشتباه است.
🔹 T.38 unsupported است.
🔹 Video یا Media Type غیرقابل‌قبول ارسال شده است.
🔹 Provider Policy خاصی روی ptime یا fmtp دارد.
اگر Transcoding را Prevent کرده باشید، 488 ممکن است طبیعی باشد
در Advanced Codec Negotiation، Asterisk اجازه می‌دهد Transcoding را برای بعضی نقاط مذاکره محدود کنید.
مثال:
codec_prefs_outgoing_offer =
prefer: configured,
operation: intersect,
keep: all,
transcode: preventاگر هیچ Codec مشترک باقی نماند، ردشدن تماس از اینکه Asterisk Transcoding ناخواسته انجام دهد منطقی‌تر است. بنابراین قبل از تغییر transcode: prevent، دلیل Policy خودتان را بررسی کنید.
488 روی INVITE اولیه با 488 روی re-INVITE فرق دارد
| محل خطا | برداشت | موارد محتمل |
|---|---|---|
| INVITE اولیه | Session اولیه قابل‌قبول نیست | Codec، RTP Profile، SRTP، Media Type |
| re-INVITE بعد از Answer | تغییر جدید Media رد شده | T.38، Hold/Resume، SRTP change، Codec renegotiation |
| re-INVITE Fax | Audio → T.38 رد شده | T.38/UDPTL unsupported یا incompatible |
طبق RFC 3261، اگر re-INVITE با 488 رد شود، Session موجود لزوماً قطع نمی‌شود و می‌تواند با مشخصات قبلی ادامه پیدا کند.
مثال ۱: Provider فقط G.711 قبول می‌کند
Offer شما:
m=audio 17824 RTP/AVP 111
a=rtpmap:111 opus/48000/2Provider فقط PCMA/PCMU دارد و 488 می‌دهد. اگر Trunk نیاز دارد G.711 را Offer کنید:
disallow=all
allow=alaw,ulawاگر Phone سمت داخلی Opus است، Asterisk در صورت داشتن Codec و اجازه Policy می‌تواند بین دو Leg Transcode کند.
مثال ۲: Codec مشترک هست، اما SRTP اجباری است
Offer:
m=audio 17824 RTP/SAVP 0 8
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:...Provider:
Supported:
RTP/AVP 0 8
Unsupported:
RTP/SAVPدر این حالت هر دو سمت PCMU/PCMA دارند، اما 488 همچنان منطقی است. مشکل Media Encryption است نه Codec.
مثال ۳: تماس صوتی سالم است، Fax re-INVITE با 488 رد می‌شود
Call established:
m=audio ... RTP/AVP 0
Fax detected:
re-INVITE
m=image ... udptl t38
Remote side:
SIP/2.0 488 Not Acceptable Hereاین Trace نشان می‌دهد مشکل تماس صوتی نیست. T.38 Capability، UDPTL و Provider Fax Policy را بررسی کنید.
روش تشخیص سریع SIP 488
| گام | چه چیزی را ببینیم؟ | اگر ناسازگار بود |
|---|---|---|
| ۱ | INVITE اولیه یا re-INVITE؟ | نوع Failure Scenario را مشخص کنید |
| ۲ | Codec مشترک وجود دارد؟ | allow/disallow یا Transcoding |
| ۳ | RTP Profile یکسان است؟ | RTP/SRTP Policy |
| ۴ | SDES یا DTLS مورد انتظار است؟ | media_encryption |
| ۵ | rtpmap/fmtp قابل‌قبول است؟ | Codec Parameters |
| ۶ | m=image / T.38 وجود دارد؟ | t38_udptl و Fax Policy |
| ۷ | Asterisk Topology خالی شده؟ | Codec Negotiation Policy |
| ۸ | Warning/Reason در 488 چیست؟ | Evidence سمت مقصد |
از Provider چه Traceای بخواهیم؟
اگر 488 از Provider می‌آید، فقط Screenshot پیام خطا نفرستید. این اطلاعات را همراه Ticket بدهید:
🔹 Timestamp دقیق تماس.
🔹 Call-ID.
🔹 INVITE کامل با SDP Offer.
🔹 پاسخ 488 کامل و Warning Header در صورت وجود.
🔹 Codecهای مجاز Trunk.
🔹 نوع Media Encryption مورد انتظار.
🔹 اینکه تماس Voice است یا Fax/T.38.
🔹 اگر re-INVITE است، SDP قبل و بعد از تغییر.
از Provider بخواهید مشخص کند SDP به کدام دلیل رد شده است: Codec، Secure RTP، Fax، ptime/fmtp، Media Type یا Policy دیگری.
اشتباه‌هایی که عیب‌یابی 488 را طولانی می‌کنند
🔹 فرض اینکه هر 488 فقط Codec است.
🔹 اضافه‌کردن همه Codecها به allow بدون نگاه‌کردن به SDP.
🔹 نادیده‌گرفتن RTP/AVP در برابر RTP/SAVP یا DTLS-SRTP.
🔹 بررسی نکردن اینکه 488 روی INVITE اولیه است یا re-INVITE.
🔹 فعال‌کردن T.38 فقط در PBX بدون بررسی Provider/ATA.
🔹 فعال‌کردن Transcoding سنگین برای مشکلی که اصلاً Codec نیست.
🔹 تغییر هم‌زمان چند Setting و از دست‌دادن علت واقعی.
روی Trunk یا Asterisk خطای SIP 488 دارید؟
اگر INVITE و SDP کامل در دسترس باشد، می‌توان مشخص کرد مشکل از Codec، SRTP/DTLS، T.38 یا Policy مذاکره Media است و به‌جای آزمون‌وخطای تنظیمات، همان لایه اصلاح شود.
ایرانیکاسرور می‌تواند برای تهیه VPS، نصب Asterisk، تنظیم SIP Trunk، Codec Policy، SRTP و عیب‌یابی SDP کمک کند.
تماس با پشتیبانی ایرانیکاسرور: 021-91302467
پرسش‌های رایج
SIP 488 Not Acceptable Here یعنی چه؟
یعنی Endpoint یا Server درخواست SIP را دریافت کرده اما Session Description یا Media پیشنهادی برای همان مقصد قابل‌قبول نیست. Codec، RTP Profile، SRTP، T.38 یا پارامترهای SDP می‌توانند علت باشند.
آیا SIP 488 همیشه به‌خاطر Codec است؟
خیر. نبود Codec مشترک رایج است، اما ناسازگاری RTP/AVP با RTP/SAVP، SDES با DTLS-SRTP، T.38، Media Type یا Codec Parameters هم می‌تواند 488 ایجاد کند.
چطور بفهمم Codec مشترک وجود دارد؟
SDP Offer و Answer را مقایسه کنید و Payload Typeها و خطوط a=rtpmap را ببینید. در Asterisk نیز pjsip show endpoint فهرست Codecهای مجاز Endpoint را نشان می‌دهد.
آیا SRTP می‌تواند باعث 488 شود؟
بله. اگر یک سمت Media Encryption را اجباری کند و سمت دیگر RTP Profile یا روش SRTP موردنظر را نپذیرد، حتی با Codec مشترک هم SDP می‌تواند رد شود.
چرا هنگام Fax خطای 488 می‌گیریم؟
ممکن است re-INVITE برای تبدیل Audio به T.38 ارسال شده باشد و سمت مقابل image/t38 یا پارامترهای UDPTL را قبول نکند. T.38 را روی PBX، Provider و ATA با هم بررسی کنید.
آیا Transcoding مشکل 488 را حل می‌کند؟
فقط وقتی علت واقعی نبود Codec مشترک بین دو Call Leg باشد. Transcoding مشکل SRTP، T.38 یا Media Profile ناسازگار را حل نمی‌کند.
اگر re-INVITE با 488 رد شود تماس قطع می‌شود؟
نه لزوماً. RFC 3261 توضیح می‌دهد در صورت ردشدن تغییر Session با 488، تماس موجود می‌تواند با Media Parameters قبلی ادامه پیدا کند.
اولین دستور برای عیب‌یابی 488 در Asterisk چیست؟
در CLI دستور pjsip set logger on را موقتاً فعال کنید و INVITE، SDP Offer و پاسخ 488 را کنار هم بررسی کنید؛ سپس Logger را خاموش کنید.
جمع‌بندی
SIP 488 Not Acceptable Here را باید به‌عنوان خطای مذاکره Session و Media بررسی کنید، نه صرفاً یک خطای Codec. بهترین Evidence همان SDP Offer/Answer است.
اول ببینید 488 روی INVITE اولیه آمده یا re-INVITE. سپس Codecهای مشترک، RTP Profile، SRTP/DTLS و Media Type را مقایسه کنید. اگر خطا فقط هنگام Fax رخ می‌دهد، T.38 و UDPTL را از Voice جدا بررسی کنید.
Transcoding زمانی مفید است که دو Call Leg Codec مشترک ندارند و PBX می‌تواند بین آن‌ها تبدیل انجام دهد؛ اما اگر مشکل از SRTP یا T.38 باشد، افزایش Codecها فقط عیب‌یابی را پیچیده‌تر می‌کند.
با یک Trace تمیز و مقایسه دقیق خطوط m=، a=rtpmap، a=fmtp و Attributeهای Security معمولاً می‌توان علت واقعی 488 را بدون آزمون‌وخطای گسترده پیدا کرد.
برای عیب‌یابی SIP 488 و Media Negotiation کمک می‌خواهید؟
با INVITE و SDP کامل می‌توان مشخص کرد 488 از Codec، RTP/SRTP، DTLS، T.38 یا Policy مذاکره Media ایجاد شده است.
تماس با پشتیبانی ایرانیکاسرور: 021-91302467
دیدگاه‌ها (۰)