this invite is not getting a respond but if i take off G722 codec it all works .(the packets got smaller )
what is the problem this size of the packet ?
had it with already now the second time a big codec list gets blocked
what would be the corect tool or way to figure out who and why it is being blocked .
if you resend the original invite with TCP does it work ?
this might help shed some light on the issue as well , it sure sounds like an MTU problem …
I imagine you have exceeded the maximum transmission unit limit somewhere on the path. Either it is misconfigured for your interface, or fragmentation is disabled on not working properly.
The user name seems excessive and you have some rather lang custom headers.
thank you
is there a way in asterisk if packet is bigger then X truncate callerid name or at least a way how to monitor it work on a fix
2. using TCP VS UDP what is the inpact on a asterisk server how much mure CPU does it consume ?
sending-large-sip-request-exceeds-mtu-value-might-not-switch-udp-tcp
Blockquote
Changeover to TCP when sending via UDP
If you turn the “disable_tcp_switch” option off in the pjsip.conf system section it is possible for an automatic switch to TCP to occur when sending a large message out using UDP. If your system has not been configured with a TCP transport this will fail. The sending of the message may also fail if the remote side is not listening on TCP.
any body using thes option does it cause problems ?
does yealink phone know to change udp tcp simultaneously?
;==========================SYSTEM SECTION OPTIONS=========================
[system]
type= system
; SYNOPSIS: Options that apply to the SIP stack as well as other system-wide settings
;timer_t1=500 ; Set transaction timer T1 value milliseconds (default: "500")
;timer_b=32000 ; Set transaction timer B value milliseconds (default: "32000")
compact_headers=yes ; Use the short forms of common SIP header names
; (default: "no")```Your From, Remote-Party-ID and X-PBX headers are unusual long.
i know that but can not change it for now!
looking to hear if these to param are implemented what would the effect be ?
compact_headers=yes
disable_tcp_switch=no
One will enable SIP compact headers[1]. The other disables switching to TCP if the packet size exceeds a certain amount. Exactly as they each state as what they’ll do.
compact_headers=yes
in pjsip need a full asterisk restart chan_sip just needed a reload 
after using this for a few days yealink phone cant send dtmf when set to rfc 2833
is this a asterisk bug or a yealink pronlem ?
The PJSIP stack doesn’t allow you to change things like that at runtime, thus it requires a restart. It’s a PJSIP stack limitation.
As for your question, without any kind of investigation can’t really answer. You haven’t shown a SIP trace, or an RTP trace.
DTMF mode is communicated in SDP, not SIP, so cannot be affected by the use of compact headers.
good compact_headers=no
not good where compact_headers=yes
Based on the limited information showing telephone-event negotiated. It is most likely the Yealink.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.