sr-users December 2022

sr-users@lists.kamailio.org

54 participants
59 discussions

Rtpengine: no audio after kernelization.

by Michel Pelletier

Hello, I am proxying all RTP through RTPEngine. Everything works fine until about 5 seconds into the call, when rtpengine enters kernelization, after which all RTP forwarding ceases. I've checked the required iptables entries, and all looks good. Here is a description of my environment: # cat os-release PRETTY_NAME="Debian GNU/Linux 11 (bullseye)" NAME="Debian GNU/Linux" VERSION_ID="11" VERSION="11 (bullseye)" VERSION_CODENAME=bullseye ID=debian HOME_URL="https://www.debian.org/" SUPPORT_URL="https://www.debian.org/support" BUG_REPORT_URL="https://bugs.debian.org/" # kamailio -v version: kamailio 5.6.2 (x86_64/linux) 54a9c1 flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST, HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: 54a9c1 compiled on 16:02:49 Dec 1 2022 with gcc 10.2.1 # rtpengine -v Version: 11.1.1.3-1~bpo11+1 Michel Pelletier

3 days, 16 hours

enable topology hiding on one side or dynamic ip in topoh module Contact and Via Header

by Patrick Karton

Hello , im using kamailio with two interfaces external and internal. i need a way either to : * enable topoh hiding only when outgoing interface is external ( mask contact and Via ip only when ougoing interface is external * or if it is not possible to enable it only in one direction.i want to know how to configure dynamic(for example in xavp or avp) ip to put in Contact and Via when topoh is enabled. i see that the 'mask_ip' parameter of topoh module is a string. so we can not set a dynamic value here unfortunately. Thanks

1 month, 1 week

Kamailio not responding after stress test

by Igor Olhovskiy

Hello, I'm continuing investigations on Kamailio and stress test. Got it again in the state where it's not accepting any new TCP/TLS connections (UDP still works though), but all looks good from lsof/netnstat part, like system is not reporting any zombie connections. Restart of Kamailio process helps This time I got output of kamctl trap Put it here: https://pastebin.com/iYrNZ8U9 kamailio --version version: kamailio 5.6.2 (x86_64/linux) 54a9c1 flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST, HAVE_RESOLV_RES ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: 54a9c1 compiled on 14:01:01 Oct 18 2022 with gcc 4.8.5 It's statically linked with tlsa pointing on openssl-1.1.1q Settings related to TLS are: fork=yes children=4 tcp_children=12 enable_tls=yes tcp_accept_no_cl=yes tcp_max_connections=63536 tls_max_connections=63536 tcp_accept_aliases=no tcp_async=yes tcp_connect_timeout=10 tcp_conn_wq_max=63536 tcp_crlf_ping=yes tcp_delayed_ack=yes tcp_fd_cache=yes tcp_keepalive=yes tcp_keepcnt=3 tcp_keepidle=30 tcp_keepintvl=10 tcp_linger2=30 tcp_rd_buf_size=80000 tcp_send_timeout=10 tcp_wq_blk_size=2100 tcp_wq_max=10485760 open_files_limit=63536 Can you please help to read gdb output and understand where I missed in config? Thanks in advance! -- Best regards, Ihor (Igor)

2 months

How to have Kamailio retry backends

by Unai Rodriguez

Dear List, We’re using Kamailio to load balance MRCP requests to multiple backend groups with a configuration as follows: # kamailio.cfg ... ... route[DISPATCH] { if($ua=="mrcp_backend_1") { if(!ds_select_dst("1", "4")) { send_reply("404", "No destination"); exit; } } if($ua=="mrcp_backend_2") { if(!ds_select_dst("2", "4")) { send_reply("404", "No destination"); exit; } } xlog("L_DBG", "--- SCRIPT: going to <$ru> via <$du>\n"); t_on_failure("RTF_DISPATCH"); route(RELAY); exit; } ... ... # dispatcher.list 1 sip:mrcp01.server.int:8060;transport=tcp 1 sip:mrcp02.server.int:8060;transport=tcp 2 sip:mrcp03.server.int:8060;transport=tcp 2 sip:mrcp04.server.int:8060;transport=tcp With this configuration, Kamailio load balances the initial SIP INVITE among the MRCP servers. After the INVITE, the service communicates directly to the MRCP servers via SIP (for hanging up the call), MRCPv2 (for sending speech control messages), and RTP (for sending audio). We would like to implement a configurable number of retries, so that if a particular backend times out, Kamailio would retry X times to other backend(s). In short, something equivalent to HAProxy’s retries, but for Kamailio. This probably implies having Kamailio always as part of our communication (not just load balancing the initial SIP INVITE). I haven’t been able to find much information about this, could someone provide some pointers? Thank you so much With best wishes, Unai Rodriguez

2 months, 3 weeks

Recover call in ringing state

by Devang Dhandhalya

Hello All I have below setup : SBC -> kamailio -> Media server(remote) -> web-client Call comes from sbc to kamilio and it relays to Remote server to end user, In Ringing state if remote server goes down then in kamailio there is any way to Recover that ringing call like we can generate new invite for other Remote server which is active state, for relaying call i am using dispatcher module.. I tried with tm.cancel RPC command but it works only if the remote server is running , when I crash the remote server at that time tm.cancel is not generating cancel to remote server. Please suggest if there is any other way to generate INVITE. Regards Devang Dhandhalya -- * <https://www.ecosmob.com/> * *Disclaimer* In addition to generic Disclaimer which you have agreed on our website, any views or opinions presented in this email are solely those of the originator and do not necessarily represent those of the Company or its sister concerns. Any liability (in negligence, contract or otherwise) arising from any third party taking any action, or refraining from taking any action on the basis of any of the information contained in this email is hereby excluded. *Confidentiality* This communication (including any attachment/s) is intended only for the use of the addressee(s) and contains information that is PRIVILEGED AND CONFIDENTIAL. Unauthorized reading, dissemination, distribution, or copying of this communication is prohibited. Please inform originator if you have received it in error. *Caution for viruses, malware etc.* This communication, including any attachments, may not be free of viruses, trojans, similar or new contaminants/malware, interceptions or interference, and may not be compatible with your systems. You shall carry out virus/malware scanning on your own before opening any attachment to this e-mail. The sender of this e-mail and Company including its sister concerns shall not be liable for any damage that may incur to you as a result of viruses, incompleteness of this message, a delay in receipt of this message or any other computer problems.

2 months, 3 weeks

Localy generate BYE message from ims_charging

by masoud96＠mail.ru

Hello! I have a problem with writing the BYE message from the ACC module to the database, because the messages are generated locally by the ims_charging module at the end of the credit and the flag will not work. You can help catch such local messages and make a record in the database.

2 months, 4 weeks

Question about UAC and PUA modules routing behavior

by Jean-Francois Lemieux

Hello, I have some trouble to figure out how routing works when the request coming from the kamailio itself (used as a user agent per example) .I try to use presence PUA... modules. The issue I have is the NOTIFY requests aren't sent to the good destination; it doesn't seems to obey to the contact or other informations when the device did a SUBSCRIBE. I don't want to ask to troubleshoot the presence module directly I just want to know how Kamailio deals with request coming from Kamailio itself (in the case of a NOTIFY generated by PUA_... modules My mains questions are: Does the pua modules when generating request like NOTIFY will pass through request_route ? Does the pua modules when generating request like NOTIFY will be sent only when t_relay() is used or UA kamailio based request bypass all the logic of the Kamailio proxy behavior ? I'm trying to understand if I can modify the NOTIFY request to change destination before the "routing decision" is made by Kamailio Kamailio 5.6.0 used as : -proxy to remote pbx for call dialog -registrar/location server -media relaying and nat management -...and I try to use it as a presence server instead to use the pbx behind kamailio

2 months, 4 weeks

Re: Direct Routing, SIP, INVITE TO TEAMS (400 BAD REQUEST)

by Lewis Hutchinson

Hi Brandon Apologies if you have provided this but do you have a PCAP of the INVITE / 400 Bad Request rather than the Pastebin of the INVITE The last time I had this was because of a missing /r/n on the SDP granted it was not with teams but still difficult to track down. Also, what is the MTU Size, have you checked to see if the is causing packet fragmentation and manifesting in a Bad Request. Are there any clues in the Teams - Call Analytics. Regards Lewis -----Original Message----- From: sr-users-request(a)lists.kamailio.org <sr-users-request(a)lists.kamailio.org> Sent: 29 December 2022 20:17 To: sr-users(a)lists.kamailio.org Subject: sr-users Digest, Vol 211, Issue 67 Send sr-users mailing list submissions to sr-users(a)lists.kamailio.org To subscribe or unsubscribe via email, send a message with subject or body 'help' to sr-users-request(a)lists.kamailio.org You can reach the person managing the list at sr-users-owner(a)lists.kamailio.org When replying, please edit your Subject line so it is more specific than "Re: Contents of sr-users digest..." Today's Topics: 1. Re: Direct Routing, SIP, INVITE TO TEAMS (400 BAD REQUEST) (Brandon Armstead) 2. Re: Direct Routing, SIP, INVITE TO TEAMS (400 BAD REQUEST) (Brandon Armstead) ---------------------------------------------------------------------- Message: 1 Date: Thu, 29 Dec 2022 12:15:16 -0800 From: Brandon Armstead <brandon(a)cryy.com> Subject: [SR-Users] Re: Direct Routing, SIP, INVITE TO TEAMS (400 BAD REQUEST) To: Henning Westerholt <hw(a)gilawa.com> Cc: "Kamailio (SER) - Users Mailing List" <sr-users(a)lists.kamailio.org> Message-ID: <CABAX3EoF+hfruLiV2Nh_g117_q8diaKxVEyp5hMFO=wyKbQidQ(a)mail.gmail.com> Content-Type: multipart/alternative; boundary="0000000000005692d905f0fd2538" Henning, There was no reply (reason) available in my case. - Brandon On Thu, Dec 29, 2022 at 11:48 AM Henning Westerholt <hw(a)gilawa.com> wrote: > Hello, > > > > as mentioned before, have a look to the 400 reply reason phrase. This > was done quite good from their side, better than many other vendors. > > Usually, Teams is not too bad if you are using a defined > infrastructure that do not introduce too many variables. We are > usually using a B2BUA in our customer projects for that purpose. > > > > Cheers, > > > > Henning > > > > -- > > Henning Westerholt - > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fskal > atan.de%2Fblog%2F&data=05%7C01%7Clewis.hutchinson%40missionlabs.co.uk% > 7Ce1670c8a21444edf0ed408dae9f91fac%7C97c26f550a7a4661bd8f7b43b50d3f2b% > 7C0%7C0%7C638079553431377130%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM > DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdat > a=QU%2BzOgPdbmRYh51a9PvptIvVjnTZrGxT8z1G7b2RRGQ%3D&reserved=0 > > Kamailio services - > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgila > wa.com%2F&data=05%7C01%7Clewis.hutchinson%40missionlabs.co.uk%7Ce1670c > 8a21444edf0ed408dae9f91fac%7C97c26f550a7a4661bd8f7b43b50d3f2b%7C0%7C0% > 7C638079553431377130%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQI > joiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=PuDqkZ > QCj2IlxvRsLQGoKFv19K3uVE5RBxvcPKPODwQ%3D&reserved=0 > > > > *From:* Brandon Armstead <brandon(a)cryy.com> > *Sent:* Thursday, December 29, 2022 7:52 PM > *To:* Kamailio (SER) - Users Mailing List > <sr-users(a)lists.kamailio.org> > *Subject:* [SR-Users] Re: Direct Routing, SIP, INVITE TO TEAMS (400 > BAD > REQUEST) > > > > Alex & Kaufman, > > > > Appreciate the feedback. The pastebin is one example of about > 1000+ iterations literally of changes. So I'm finally reaching out > :). I haven't tested the socket attribute in record-route change, I > will try this now. As for the angle brackets I've tried with and > without, etc (already) to no effect. The SDP unknown media type seems > to be a Poly thing, so I > *want* to rule this out as its not in my other SDP's and still receive > 400 bad request. > > One more iteration here we go... please feel free to let me know if > you have any other thoughts on the matter :). > > > > Thanks! > > > > - Brandon > > > > On Thu, Dec 29, 2022 at 8:08 AM Alex Balashov > <abalashov(a)evaristesys.com> > wrote: > > Yeah, the grammar says that rr-params are just generic-params, in > which case it's not. I didn't see that -- nicely spotted! > > I think that may be the basis of the 400 Bad Request. I'd be shocked > if it weren't. > > The broken clock of "Microsoft SIP" can still be right twice a day. > > > On Dec 29, 2022, at 10:31 AM, Kaufman <bkaufman(a)bcmone.com> wrote: > > > > In your top Record-Route you have: > > > > socket=; > > > > Not sure if that is legal. > > > > Kaufman > > > > -----Original Message----- > > From: Alex Balashov <abalashov(a)evaristesys.com> > > Sent: Thursday, December 29, 2022 9:02 AM > > To: Kamailio (SER) - Users Mailing List > > <sr-users(a)lists.kamailio.org> > > Subject: [SR-Users] Re: Direct Routing, SIP, INVITE TO TEAMS (400 > > BAD > REQUEST) > > > > Sorry to hear you're having to interoperate with Teams. It's a > > unique > form of sadism I wouldn't wish upon anyone. > > > > A few theories: > > > > 1) Microsoft doesn't like the "bare" Contact header-value here: > > > > Contact: > sip:+MY_FROM_PHONE_NUMBER_HERE@MY_FQDN_WAS_HERE:5061;transport=tls > > > > Unlike the careted one right above: > > > > P-Asserted-Identity: > > <sip:+MY_FROM_PHONE_NUMBER_HERE@MY_FQDN_WAS_HERE> > > > > A bare URI absent other header-params is of course completely legal, > > but > I'm really trying to get inside the imaginary world of antisocial > "Microsoft SIP" here. > > > > 2) Could it be that antisocial "Microsoft SIP" sends 400 as a way of > objecting to something in the SDP, e.g. where a non-demented SIP stack > would send "488 Not Acceptable Here" or "415 Unsupported Media Type"? > > > > I know you've said you tried multiple clients to rule that out, but > > I > wonder if the thing it's objecting to hasn't been ruled out that way. > > > > 3) I saw this media line in the SDP: > > > > m=application 41356 <unknown media type> > > > > What's that? > > > > -- Alex > > > >> On Dec 29, 2022, at 9:51 AM, Brandon Armstead <brandon(a)cryy.com> wrote: > >> > >> Outbound calls from my SBC into Teams (Polycom -> SBC -> Teams) > >> always > result in a 400 BAD REQUEST. > >> Example invite below: > >> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fn > >> am11.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%25 > >> 2Fpast&data=05%7C01%7Clewis.hutchinson%40missionlabs.co.uk%7Ce1670c > >> 8a21444edf0ed408dae9f91fac%7C97c26f550a7a4661bd8f7b43b50d3f2b%7C0%7 > >> C0%7C638079553431377130%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDA > >> iLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sda > >> ta=5v20CvNnmdiHwfWMBX6tgjMlE1i2aKpFgTnuVFfpyl0%3D&reserved=0 > >> ebin.com%2FF1G1Ce59&data=05%7C01%7Cbkaufman%40bcmone.com%7C55672dbf > >> 739 > >> a4ff447f008dae9b0c9b2%7Cafc1818e7b6848568913201b9396c4fc%7C1%7C0%7C > >> 638 > >> 079242759152531%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjo > >> iV2 > >> luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Cbff6B4g > >> Nr8 > >> A9zs89smJ129y8IyNM9%2B3zVkGhlzpa54%3D&reserved=0 > >> I've taken care to make sure numbers are all E.164 format in > From/To/Contact. I've also taken care to make sure that FQDN is used > in Contact and Record-Route header. > >> I've tried many different variations and have followed the SIP > information here: > >> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fn > >> am11.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%25 > >> 2Flear&data=05%7C01%7Clewis.hutchinson%40missionlabs.co.uk%7Ce1670c > >> 8a21444edf0ed408dae9f91fac%7C97c26f550a7a4661bd8f7b43b50d3f2b%7C0%7 > >> C0%7C638079553431377130%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDA > >> iLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sda > >> ta=ELk0UD1Pleq%2FG9j1%2BT18tiuFe0yjflimR9ztnW%2F7oPM%3D&reserved=0 > >> n.microsoft.com%2Fen-us%2Fmicrosoftteams%2Fdirect-routing-protocols > >> -si > >> p&data=05%7C01%7Cbkaufman%40bcmone.com%7C55672dbf739a4ff447f008dae9 > >> b0c > >> 9b2%7Cafc1818e7b6848568913201b9396c4fc%7C1%7C0%7C638079242759152531 > >> %7C > >> Unknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6I > >> k1h > >> aWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=GO26A9FOOoS42yMCWPPGo5PkKo > >> 75c > >> kjSJSkjAeYRsU0%3D&reserved=0 I've also tried several different > >> clients (Bria, Polycom CCX 600, Grandstream, etc) to see if maybe > >> it was > something in the SDP or otherwise causing an issue. > >> SIP Transport is TLS, RTP is SRTP > >> I might also add that OPTION pings are active and Direct Routing > Endpoint is active, so this is successful. I also am able to receive > calls FROM teams to my IP phone(s) without issue. It is only when I > try and call INTO teams (INVITE -> Microsoft Teams) that I always > receive a 400 BAD REQUEST to my INVITE. > >> Any help is appreciated, thank you! > >> > >> - Brandon > >> > >> __________________________________________________________ > >> Kamailio - Users Mailing List - Non Commercial Discussions To > >> unsubscribe send an email to sr-users-leave(a)lists.kamailio.org > >> Important: keep the mailing list in the recipients, do not reply > >> only > to the sender! > >> Edit mailing list options or unsubscribe: > > > > -- > > Alex Balashov | Principal | Evariste Systems LLC > > > > Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) > > Web: > https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.e > varistesys.com%2F&data=05%7C01%7Clewis.hutchinson%40missionlabs.co.uk% > 7Ce1670c8a21444edf0ed408dae9f91fac%7C97c26f550a7a4661bd8f7b43b50d3f2b% > 7C0%7C0%7C638079553431377130%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM > DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdat > a=hbww6wEEztE85YqxcN92bpMR%2BkiI9%2BE3jF1i6fQpjEk%3D&reserved=0, > > https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.c > srpswitch.com%2F&data=05%7C01%7Clewis.hutchinson%40missionlabs.co.uk%7 > Ce1670c8a21444edf0ed408dae9f91fac%7C97c26f550a7a4661bd8f7b43b50d3f2b%7 > C0%7C0%7C638079553431377130%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD > AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata > =4E7a5ZxSvttBiMxl1VTtolmTvS4T5VGZHA00CsbPR2c%3D&reserved=0 > > > > __________________________________________________________ > > Kamailio - Users Mailing List - Non Commercial Discussions To > unsubscribe send an email to sr-users-leave(a)lists.kamailio.org > > Important: keep the mailing list in the recipients, do not reply > > only to > the sender! > > Edit mailing list options or unsubscribe: > > __________________________________________________________ > > Kamailio - Users Mailing List - Non Commercial Discussions To > > unsubscribe send an email to sr-users-leave(a)lists.kamailio.org > > Important: keep the mailing list in the recipients, do not reply > > only to > the sender! > > Edit mailing list options or unsubscribe: > > -- > Alex Balashov | Principal | Evariste Systems LLC > > Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) > Web: > https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.e > varistesys.com%2F&data=05%7C01%7Clewis.hutchinson%40missionlabs.co.uk% > 7Ce1670c8a21444edf0ed408dae9f91fac%7C97c26f550a7a4661bd8f7b43b50d3f2b% > 7C0%7C0%7C638079553431377130%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM > DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdat > a=hbww6wEEztE85YqxcN92bpMR%2BkiI9%2BE3jF1i6fQpjEk%3D&reserved=0, > https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.c > srpswitch.com%2F&data=05%7C01%7Clewis.hutchinson%40missionlabs.co.uk%7 > Ce1670c8a21444edf0ed408dae9f91fac%7C97c26f550a7a4661bd8f7b43b50d3f2b%7 > C0%7C0%7C638079553431377130%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD > AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata > =4E7a5ZxSvttBiMxl1VTtolmTvS4T5VGZHA00CsbPR2c%3D&reserved=0 > > __________________________________________________________ > Kamailio - Users Mailing List - Non Commercial Discussions To > unsubscribe send an email to sr-users-leave(a)lists.kamailio.org > Important: keep the mailing list in the recipients, do not reply only > to the sender! > Edit mailing list options or unsubscribe: > >

3 months

Direct Routing, SIP, INVITE TO TEAMS (400 BAD REQUEST)

by Brandon Armstead

Outbound calls from my SBC into Teams (Polycom -> SBC -> Teams) always result in a 400 BAD REQUEST. Example invite below: https://pastebin.com/F1G1Ce59 I've taken care to make sure numbers are all E.164 format in From/To/Contact. I've also taken care to make sure that FQDN is used in Contact and Record-Route header. I've tried many different variations and have followed the SIP information here: https://learn.microsoft.com/en-us/microsoftteams /direct-routing-protocols-sip I've also tried several different clients (Bria, Polycom CCX 600, Grandstream, etc) to see if maybe it was something in the SDP or otherwise causing an issue. SIP Transport is TLS, RTP is SRTP I might also add that OPTION pings are active and Direct Routing Endpoint is active, so this is successful. I also am able to receive calls FROM teams to my IP phone(s) without issue. It is only when I try and call INTO teams (INVITE -> Microsoft Teams) that I always receive a 400 BAD REQUEST to my INVITE. Any help is appreciated, thank you! - Brandon

3 months

Remove all Via Header or create custome Via Header

by Benoit Panizzon

Hi out there! While experimenting with the listen and adverize 'hostname' option I came across a voice switch, which I suppose fails if the Via header is not an IPv4 address. There is a record_route_advertised_address(address) in the RR module, to set a customer Record-Route Header. Is there something similar for the Via header so I could try if having an IP address instead of a hostname in the top-most Via would solve the issue? Or is there a way to remove all via header? Remove_hf("Via") in the branch route trigger garbles the From: HF. Mit freundlichen Grüssen -Benoît Panizzon- -- I m p r o W a r e A G - Leiter Commerce Kunden ______________________________________________________ Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 Pratteln Fax +41 61 826 93 01 Schweiz Web http://www.imp.ch ______________________________________________________

3 months

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

sr-users December 2022