Hi Joshua! No it does not concern audio in this case, it is a change in media for video. Initially the call is established with a=recvonly (or even a=inactive) that then changes to a=sendrecv (when the camera is activated on the linphone).
Von: asterisk-dev <asterisk-dev-boun...@lists.digium.com> im Auftrag von "Joshua C. Colp" <jc...@sangoma.com> Antworten an: Asterisk Developers Mailing List <asterisk-dev@lists.digium.com> Datum: Mittwoch, 12. Jänner 2022 um 15:35 An: Asterisk Developers Mailing List <asterisk-dev@lists.digium.com> Betreff: [External] Re: [asterisk-dev] How to debug reinvites not getting forwarded to other call leg (pjsip) CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. On Wed, Jan 12, 2022 at 10:17 AM Floimair Florian <f.floim...@commend.com<mailto:f.floim...@commend.com>> wrote: Hi everybody! I am currently facing an issue with SIP reINVITEs (with changed media direction) being acknowledged by Asterisk but not forwarded to the second call leg. My setup is as follows: Device A -> Kamailio -> Asterisk (18.9.0 chan_pjsip) -> Kamailio -> Device B Device A sends a reinvite through Kamailio (Proxy & Registrar) to Asterisk, which answers with 200 OK. Asterisk is configured with mohpassthrough option so any change in SDP media direction should be forwarded from A to B or vice versa. This works in almost all cases but I do have an edge case where a linphone client sends the reinvite and Asterisk more or less silently discards it. I tried ramping up debug level verbosity (to 5) but was unable to spot anything in regards to reinvites or any other error/mismatch as to why it is not forwarded. So my question is: What can I do to analyze this better, maybe even add debug messages myself to the source code, but I have no clue where the appropriate location for this would be (maybe even in libpjsip? • I’m using bundled version). Thanks for your help in advance. You'll need to be specific. Is this strictly for an audio stream for music on hold? If so, it doesn't strictly get forwarded. It would be handled as part of the normal music on hold handling[1][2] so debug would need to go there initially, and disabling passthrough and ensuring MOH actually occurs locally would narrow it down. If it doesn't do MOH even with it disabled then it's probably SDP level and you'd need to compare the new SDP to the previous, specifically the version and make sure it was incremented properly. [1] https://github.com/asterisk/asterisk/blob/master/res/res_pjsip_sdp_rtp.c#L2186<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fasterisk%2Fasterisk%2Fblob%2Fmaster%2Fres%2Fres_pjsip_sdp_rtp.c%23L2186&data=04%7C01%7Cf.floimair%40commend.com%7C296b4d52b57c493b1c1b08d9d5d895be%7C13b1ddb756454e7fbe663171548559da%7C0%7C0%7C637775949398355799%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=ToQuK8qLzj7PMEdi1zyzmxQVLX6BgF63vCx2KBEuGwA%3D&reserved=0> [2] https://github.com/asterisk/asterisk/blob/master/channels/chan_pjsip.c#L1754<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fasterisk%2Fasterisk%2Fblob%2Fmaster%2Fchannels%2Fchan_pjsip.c%23L1754&data=04%7C01%7Cf.floimair%40commend.com%7C296b4d52b57c493b1c1b08d9d5d895be%7C13b1ddb756454e7fbe663171548559da%7C0%7C0%7C637775949398355799%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=70bhkA%2BNlwZ%2FE4z1YEH052JusK7U3nqRHt%2FFOaIfu24%3D&reserved=0> -- Joshua C. Colp Asterisk Technical Lead Sangoma Technologies Check us out at www.sangoma.com<https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.sangoma.com%2F&data=04%7C01%7Cf.floimair%40commend.com%7C296b4d52b57c493b1c1b08d9d5d895be%7C13b1ddb756454e7fbe663171548559da%7C0%7C0%7C637775949398355799%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=PlFq%2B2tH%2FmPVQzwaL42Wehwl1yclCd35iejsv1%2FLYOc%3D&reserved=0> and www.asterisk.org<https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.asterisk.org%2F&data=04%7C01%7Cf.floimair%40commend.com%7C296b4d52b57c493b1c1b08d9d5d895be%7C13b1ddb756454e7fbe663171548559da%7C0%7C0%7C637775949398355799%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=hzQmSIqMHAe85qAG9KJXjJplBplo%2FoluwnGWxtZDR5k%3D&reserved=0>
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
