On Wed, Jun 16, 2021 at 6:27 AM George Joseph <[email protected]> wrote:
> > > On Wed, Jun 16, 2021 at 12:50 AM Jean Aunis <[email protected]> wrote: > >> Le 15/06/2021 à 15:28, George Joseph a écrit : >> >> [2021-06-15 10:42:49.885] WARNING[5163]: res_pjsip_messaging.c:247 >> >>> insert_user_in_contact_uri: Dest: 'PJSIP/3200@linphone' MSG SEND FAIL: >>> There's already a username in endpoint linphone's contact URI >>> 'sip:[email protected]:5063;line=068b0910396d2ed'. >>> [2021-06-15 10:42:49.885] ERROR[5163]: res_pjsip_messaging.c:1240 >> >> >> >> Yeah that's the expected behavior although I guess I can change it. I >> figured that if there was a user already specified in the contact uri that >> overwriting it with something else was probably not a good idea. Now >> that I think of it though, I was thinking more from sending messages >> upstream to a provider not downstream to a client. >> >> So what should the behavior be? To construct the Request URI replace any >> user in the contact URI with the user or number specified in the >> MessageSend call? >> >> I would be in favour of trusting the dialplan. If someone wants to send a >> message to an endpoint with a specific number, that should be possible. >> That looks more flexible to me. >> > I should have a patch up for that in a few hours. > Changes up in gerrit... https://gerrit.asterisk.org/c/asterisk/+/16068 > > >> By the way, I'm fine with the modification of MessageSend you describe. >> What about applying the same modification to the MessageSend AMI action and >> to the sendMessage / sendMessageToEndpoint requests in ARI ? >> > The Message related AMI and ARI stuff call the same core functions so > they automatically support the "PJSIP/" form of the destination as well as > the refactored parsing code for the rest of the destination forms. Adding > the third "to" parameter that was added to the dialplan app is a little > more problematic for AMI and ARI. Dialplan apps don't have named > parameters so adding the third one was no problem. Both the AMI and ARI > calls have named parameters and the first one is already named "to" so > renaming that one to "destination" and adding "to" would break the contract > in Asterisk 16 and 18. I can, and will, make that change for For Asterisk > 19 however, > > >> -- >> _____________________________________________________________________ >> -- 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 > >
-- _____________________________________________________________________ -- 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
