[asterisk-dev] PJSIP messaging : specifying the user portion of the request-URI

[George Joseph]

On Wed, Jun 16, 2021 at 6:27 AM George Joseph <gjoseph at sangoma.com> wrote:

>
>
> On Wed, Jun 16, 2021 at 12:50 AM Jean Aunis <jean.aunis at prescom.fr> 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 at linphone' MSG SEND FAIL:
>>> There's already a username in endpoint linphone's contact URI
>>> 'sip:linphone at 127.0.0.1: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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20210616/9722a95c/attachment.html>