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

[George Joseph]

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.


> 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/5f493031/attachment.html>