[asterisk-users] ICE Candidate collision on dualstack hosts?
Hi I'm attempting to use ICE to be able to present all possible RTP transports to peers. 16.28.0~dfsg-0+deb11u2 (I know it's old, but unfortunately Asterisk was removed from debian 'stable' and the version in 'sid' is just broken (opus + voicemail don't work anymore). But I ran into an issue when the peer is running rtpengine: Asterisk offers: a=candidate:H9da13901 1 UDP 2130706431 157.161.57.1 13104 typ host a=candidate:H1054cffa 1 UDP 2130706431 2001:4060:dead:beef::1 13104 typ host a=candidate:He9b56028 1 UDP 2130706431 fe80::5054:ff:fea2:9057 13104 typ host a=candidate:H9da13901 2 UDP 2130706430 157.161.57.1 13105 typ host a=candidate:H1054cffa 2 UDP 2130706430 2001:4060:dead:beef::1 13105 typ host a=candidate:He9b56028 2 UDP 2130706430 fe80::5054:ff:fea2:9057 13105 typ host To me this looks like every candidate is duplicated on port +1 rtpengine complains: [ice] Priority collision between candidate pairs sKy64vK5pY86kc9w:H9da13901:2 and sKy64vK5pY86kc9w:H9da13901:2 - ICE will likely fail And indeed RTP starts on IPv6 as proposed by H1054cffa but as soon as a re-invite is processed rtpengine switches to I guess H9da13901 and rtp dies. Why is asterisk proposing two ports per ip protocol? Is there a way to configure this more precisely? -- Mit freundlichen Grüssen -Benoît Panizzon- @ HomeOffice und normal erreichbar -- I m p r o W a r e A G-Leiter Commerce Kunden __ Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 PrattelnFax +41 61 826 93 01 Schweiz Web http://www.imp.ch __ -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- Check out the new Asterisk community forum at: https://community.asterisk.org/ New to Asterisk? Start here: https://wiki.asterisk.org/wiki/display/AST/Getting+Started asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
[asterisk-users] Opus: No translation path after upgrade ubuntu focal => jammy
Hey! I just upgraded our machines from Ubuntu focal to jammy. A separate package asterisk-opus does not exist any more. https://launchpad.net/ubuntu/+source/asterisk-opus/+changelog It looks like this is now included in the default packages. Required modules are loaded: *CLI> module show like opus Module Description Use Count Status Support Level format_ogg_opus_open_source.so OGG/Opus audio 0 Running core res_format_attr_opus.soOpus Format Attribute Module 1 Running core *CLI> module show like resample Module Description Use Count Status Support Level codec_resample.so SLIN Resampling Codec0 Running core Core show codecs shows: 31 audio opus opus (Opus Codec) *CLI> core show translation paths opus Shows no translation path to/from any other codec. What could I be missing? -- Mit freundlichen Grüssen -Benoît Panizzon- @ HomeOffice und normal erreichbar -- I m p r o W a r e A G-Leiter Commerce Kunden __ Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 PrattelnFax +41 61 826 93 01 Schweiz Web http://www.imp.ch __ -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- Check out the new Asterisk community forum at: https://community.asterisk.org/ New to Asterisk? Start here: https://wiki.asterisk.org/wiki/display/AST/Getting+Started asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
[asterisk-users] Asterisk translates 200 OK + SDP into 488 not acceptable here after both side agreed on codec.
Hi List Asterisk 16.28.0 in use. PJSIP in use Two endpoints Both using IPv6 One Endpoint on UDP, the other via TLS. Both with: t38_udptl=yes ;fax_detect=yes ;fax_detect_timeout=30 rtp_ipv6=yes Both sides are T.38 capable and detect fax tone so no need for fax detection on asterisk. Voice calls between the two work fine. But on a Fax call, I see this situation: A <=> Asterisk <=> B A: INVITE + Audio SDP => Asterisk => (same SDP) => B B: 200 OK + Audio SDP => Asterisk => (same SDP) => A * B Detects Fax-Tone! B: Re-Invite + UDPTL => Asterisk => (same SDP) => A A: 200 OK + UDPTL => Asterisk => 488 => B I tweakted the udptl setting in various ways, but I am unable to figure out, why Asterisk is sending a 488 to B, after it first happily forwarded the SDP to A and got confirmation from A it was happy to accept that DSP. Any hint? -- Mit freundlichen Grüssen -Benoît Panizzon- @ HomeOffice und normal erreichbar -- I m p r o W a r e A G-Leiter Commerce Kunden __ Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 PrattelnFax +41 61 826 93 01 Schweiz Web http://www.imp.ch __ -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- Check out the new Asterisk community forum at: https://community.asterisk.org/ New to Asterisk? Start here: https://wiki.asterisk.org/wiki/display/AST/Getting+Started asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Asterisk chan_sip removing ptime from DSP?
Also figured that out. For chan sip, specifying the ptime in the allow statement allow=g722:20,alaw:20 made the ptime header be present and the SBC happy. -- Mit freundlichen Grüssen -Benoît Panizzon- @ HomeOffice und normal erreichbar -- I m p r o W a r e A G-Leiter Commerce Kunden __ Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 PrattelnFax +41 61 826 93 01 Schweiz Web http://www.imp.ch __ -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- Check out the new Asterisk community forum at: https://community.asterisk.org/ New to Asterisk? Start here: https://wiki.asterisk.org/wiki/display/AST/Getting+Started asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
[asterisk-users] Asterisk chan_sip removing ptime from DSP?
Hi List Just ran into another weird issue... In Swiss Telephone Interconnection, ptime=20 is a requirement. So on our SBC we enforce the presence of ptime=20 to avoid issues. I have an asterisk with chan_sip in the LAB which behaves weirdly... Inbound SDP audio part: m=audio 15542 RTP/AVP 9 8 3 101 a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:4hJMPvZmRA03KxLg8Hp+aHqeIhnmYBSQtwlT+Vkr a=rtpmap:9 G722/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:3 GSM/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20 a=maxptime:150 a=sendrecv Outbound SDP audio part m=audio 18802 RTP/AVP 8 9 101 a=rtpmap:8 PCMA/8000 a=rtpmap:9 G722/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=maxptime:150 a=sendrecv Why is ptime missing on the outbound leg? Our SBC answers 415 -- Mit freundlichen Grüssen -Benoît Panizzon- @ HomeOffice und normal erreichbar -- I m p r o W a r e A G-Leiter Commerce Kunden __ Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 PrattelnFax +41 61 826 93 01 Schweiz Web http://www.imp.ch __ -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- Check out the new Asterisk community forum at: https://community.asterisk.org/ New to Asterisk? Start here: https://wiki.asterisk.org/wiki/display/AST/Getting+Started asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] PJSIP Codec Negotiation Issue
Hi Joshua > What is the specific issue that is happening? If it's that one call > leg negotiated at opus and the other at alaw, that is currently the > way things still work. Each call leg is still ultimately negotiated > independently so the A leg can be opus, and the B leg can be alaw. I > hope that we're able to eventually return to codec negotiation work > to improve that with the foundation put into place previously, but I > don't know when that will happen. It looks like I had some other misconfiguration also causing some weird effects. Well wheat I wonder is how codec negotiation should work in this situation. I am aware, the SDP defines what the device can send, not what it is able to receive. But can't we assume this is the same? Device A <=> Asterisk <=> TSP Trunk <=> [WORLD] <=> Device B Let's assume Device B is alaw only, but we don't know, it could also be possible of better quality codecs. Device A support opus,g711,alaw So towards Device A I would define !all,opus,g722,alaw And towards the TSP Trunk the same. But when Device B replies with an SDP containing 'only' alaw, shouldn't this SDP be passed to Device A which then hopefully use the same codec? Of course Device A can receive alaw and send opus. But device B might not understand opus. And I just realized, this advanced codec negotiation is only available on Asterisk 18. I'm still on 16 :-) -- Mit freundlichen Grüssen -Benoît Panizzon- @ HomeOffice und normal erreichbar -- I m p r o W a r e A G-Leiter Commerce Kunden __ Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 PrattelnFax +41 61 826 93 01 Schweiz Web http://www.imp.ch __ -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- Check out the new Asterisk community forum at: https://community.asterisk.org/ New to Asterisk? Start here: https://wiki.asterisk.org/wiki/display/AST/Getting+Started asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
[asterisk-users] PJSIP Codec Negotiation Issue
Hi List I have come over a codec negotiation issue. A (asterisk) is sending in INVITE containing * opus (type 107) * g722 * alaw (type 8) B answers with 183 containing SDP * alaw a=sendrecv B then answer the call with 200 and NO SDP I suppose that result in B telling us, it only support alaw. But 'set rtp debug on' show B sending type 8 and A sending type 107. As the remote only announced to be capable of 8, shouldn't asterisk send type 8? Or even send a Re-Invite to tell it switches to alaw? Also reading: https://wiki.asterisk.org/wiki/display/AST/PJSIP+Advanced+Codec+Negotiation does not explain what I see. -- Mit freundlichen Grüssen -Benoît Panizzon- @ HomeOffice und normal erreichbar -- I m p r o W a r e A G-Leiter Commerce Kunden __ Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 PrattelnFax +41 61 826 93 01 Schweiz Web http://www.imp.ch __ -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- Check out the new Asterisk community forum at: https://community.asterisk.org/ New to Asterisk? Start here: https://wiki.asterisk.org/wiki/display/AST/Getting+Started asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
[asterisk-users] Confusion about Hangupcause, how to get asterisk to reply with 480 or 409?
Hi List We want to be able to reject some pjsip calls with a 'temporary' failure so that the PBX of the caller plays an announcement in the language of the caller, that the call can temporarily not reach the destination. https://wiki.asterisk.org/wiki/display/AST/Hangup+Cause+Mappings Case 41 seems right... Haugup(41) causes the call to be rejected with '603' causing the message 'your call has been administratively barred' to be played. Hangup(19) is also a candidate, as it would return 480. Nope, 504 is being sent, also playing the wrong message to the caller. How can I more precisely define what SIP code I want to returned to the caller? How do the documented hangup causes not match with my observation? -- Mit freundlichen Grüssen -Benoît Panizzon- @ HomeOffice und normal erreichbar -- I m p r o W a r e A G-Leiter Commerce Kunden __ Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 PrattelnFax +41 61 826 93 01 Schweiz Web http://www.imp.ch __ -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- Check out the new Asterisk community forum at: https://community.asterisk.org/ New to Asterisk? Start here: https://wiki.asterisk.org/wiki/display/AST/Getting+Started asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
[asterisk-users] RFC4733 (2833) payload during early audio 183?
Hi Gang Not a specific Asterisk Question. But I wonder, if the called party replies with 183 + SDP indicating support for telephony-event. Should the caller be able to send DTFM Tones? Swiss Railways uses an IVR that kicks in before the call is answered. So far I have found no SIP Phone which would allow sending RFC4733 during the early audio phase (so I cannot test if Asterisk would forward them) rendering the IVR unuseable. But the RFC itself suggests that there is no restriction on which SDP (183 or 200) the telephony-event is announced. -- Mit freundlichen Grüssen -Benoît Panizzon- @ HomeOffice und normal erreichbar -- I m p r o W a r e A G-Leiter Commerce Kunden __ Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 PrattelnFax +41 61 826 93 01 Schweiz Web http://www.imp.ch __ -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- Check out the new Asterisk community forum at: https://community.asterisk.org/ New to Asterisk? Start here: https://wiki.asterisk.org/wiki/display/AST/Getting+Started asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
