Please provide the complete request, as copied and pasted directly from the log file, as this is malformed (should not have the second @192.168.244.153.
This would be a fatal violation of the SIP standards, as tag= is a mandatory part of the From header in all requests and responses.
RFC 3261:
The From field MUST contain a new “tag” parameter, chosen by the UAC.
See Section 19.3 for details on choosing a tag.
Even ignoring the conflict between your example (no tag) and narrative (customised tag), the RFC also says:
When a tag is generated by a UA for insertion into a request or
response, it MUST be globally unique and cryptographically random
with at least 32 bits of randomness.
Whilst appending a non-unique, non-random, value doesn’t actually compromise the uniqueness and randomness, as long as it is independent of the unique and random part, it is clearly a breach of the spirit of how tag is intended to be used.
As Joshua says, please explain what you are trying to achieve at a very high level, not the fine details of how you thought you would achieve it.
This is not a valid value. 192.168.244.154 is a domain, not a user, and the remaining items are URI parameters, not parts of the user. Moreeover, user=phone indicates that the suer part is in the form of a phone number, which 192.168.244.145 clearly is not.
that is broken
to get the “user=phone” you need to use this option “user_eq_phone”
also transport=udp is a separate config option and do not belong in from_user