[Home]

Summary:ASTERISK-22924: PJSIP MESSAGE support does not present the contact information on outbound messages
Reporter:Anthony Messina (amessina)Labels:
Date Opened:2013-11-27 10:10:59.000-0600Date Closed:2014-01-09 17:37:05.000-0600
Priority:MinorRegression?
Status:Closed/CompleteComponents:Resources/res_pjsip_messaging
Versions:12.0.0-beta1 Frequency of
Occurrence		Constant
Related
Issues:
Environment:Fedora 19 x86_64Attachments:( 0) asterisk_transaction_MESSAGE_2013-12-31_no_from_domain.txt
( 1) asterisk_transaction_MESSAGE_2014-01-01.txt
( 2) pjsip_message_fromdomain.txt
Description:When processing SIP MESSAGE requests, PJSIP does not add/retain the contact information of the sender on the outbound message, which makes it difficult for clients to display messages in a usable fashion.  Primarily, the "User Name" portion of the callerid is removed from the "From" header, and the fromdomain/from_domain is replaced with the IP addr of the AOR.  Also, it modifies "sip" to "sips".

{code}
From: <sips:testuser@10.1.2.204>;tag=d3df0476-9b58-4565-b300-8cb7bad5f514
{code}

I'll attach pjsip logs for one inbound/outbound circuit where I'm simply sending a MESSAGE to myself.
Comments:By: Anthony Messina (amessina) 2013-12-15 17:20:53.066-0600

Doing some additional research, it appears that Asterisk should at minimum
# Include the username in the To header of the outbound MESSAGE, if present in the inbound MESSAGE: To: "To User" <touser@to.domain>
# Include the username in the From header of the outbound MESSAGE if present in the inbound MESSAGE: From: "From User" <fromuser@from.domain>

Additionally, according to [RFC 5876|http://tools.ietf.org/html/rfc5876], Asterisk should also make use of the P-Asserted-Identity headers with regard to inbound and outbound PJSIP MESSAGE requests (as set by the PJSIP endpoint's preferences for trust_id_inbound, trust_id_outbound, and send_pai).

I'm only making these comments as at some point some one will fixup the code and hopefully ti can all be done in one swoop ;)
By: Kevin Harwell (kharwell) 2013-12-27 13:02:42.150-0600

Hi Anthony, it is correct behaviour for it to replace what is in the To/From header(s) with what is specified on the AOR/Contact for an endpoint.  If you want the display and/or domain name to show those can be specified in a permanent AOR/Contact option as well: contact="name" <sip:name@domain>

However there were a few items with regard to this issue that needed "fixing up", including propagating the display name given in a To/From header under certain circumstances (if the To/From contains a display name and are used as the to/from fields in the MessageSend app).  Those are currently being reviewed if you like to take a look and/or have comments: https://reviewboard.asterisk.org/r/3094/

Also, I have been unable to reproduce the translation from sip: to sips: issue you mentioned.  If what's on the AOR/Contact is sips: then that might explain why it is being replaced as explained above.  If it is not specified on the aor/contact then if you have more info that might shed some light onto why that is happening it would be appreciated (if possible can you attach your pjsip.conf).

Thanks!
By: Kevin Harwell (kharwell) 2013-12-27 13:06:45.121-0600

As a note the addition of P-Asserted headers with regards to PJSIP MESSAGE(s) might be a bit more involved than first thought, so that issue will be resolved at a later time either under this issue or a newly created one.

For now though, the other items mentioned on the issue, namely inclusion of display names in the To/From headers, are currently under review: https://reviewboard.asterisk.org/r/3094/
By: Anthony Messina (amessina) 2013-12-28 00:33:14.696-0600

Thanks Kevin.  I think I understand what you mean when you say that "it is correct behavior."  Perhaps what we're talking about is the same thing, but your suggestion to specify domain name etc. in a permanent AOR contact AFAIK won't work at all for dynamically registered endpoints, which is what I use.

Basically I have a bunch of CSipSimple phones that MESSAGE each other via Asterisk.  I've been doing this throughout Asterisk 11 with great success.  Without looking at the code, Asterisk 11 either copied information from a SIP peer's callerid OR propagated the information from the incoming MESSAGE request to the outgoing MessageSend.  That way, the CSipSimple clients could see who the messages are from in the "User Name" <alias@domain.com> format.

I think this is what you are referring to in [https://reviewboard.asterisk.org/r/3094/].

Thanks for taking this up.
By: Kevin Harwell (kharwell) 2013-12-30 11:42:10.196-0600

Hello Anthony, you are correct in that dynamically registered endpoints won't contain the "user name" portion of a sip uri.  With the patch currently on reviewboard I made it so if the to/from fields (of MessageSend) contain a "user name" then that portion will be used on the outgoing message.  However, since in Asterisk 12 all incoming/outgoing messages must use some kind of endpoint it will use that endpoint's, if located, registered contact information to build the rest of the uri.

Thanks for your help in working out these issues!
By: Anthony Messina (amessina) 2013-12-31 03:45:09.791-0600

This attachment details a simple message from "A User" <auser@example.com> to "B User" <buser@example.com>.  Thankfully with the patch posted in the Reviewboard, the From: and To: usernames are no longer stripped.

However, Asterisk still needs to respect the from_domain parameter when sending MESSAGEs via MessageSend, as it did in Asterisk 11.

Without proper from_domain support, when <buser> receives this message, its SIP client can only display the message as being from "A User" <sips:auser@10.77.79.204>.  When <buser> tries to "Reply" to <auser>, the message *may* not be sent back via Asterisk (depending on the UAC).  In addition, this creates a new contextual dialog on <auser>'s UAC.

The from_domain support allows UACs to group MESSAGEs logically in a sort of "conversation" between two endpoints.

I realize that MESSAGE support doesn't support true dialog-type converstations and that each MESSAGE is independent, but from_domain support allows PJSIP MESSAGEing to function as it had in Asterisk 11, and also support what the end user would expect when sending and receiving SIP MESSAGEs from their UACs.

It should also be noted that this example also demonstrates the change from "sip" to "sips", which also hampers a UAC's ability to group messages logically.

I my case both UACs are CSipSimple, which also use PJSIP as the SIP stack.
By: Kevin Harwell (kharwell) 2013-12-31 16:43:07.340-0600

Hi Anthony,

You are again correct that the 'from_domain' (and 'from_user') options should be respected.  The res_pjsip_messaging module was overcomplicating things with regards to the "from" portion.  I have updated the review (https://reviewboard.asterisk.org/r/3094/) and hopefully have come closer to resolving some of your issues.

I'm still unsure what is going on with regards to sip->sips.  I noticed that in the message(s) you send/receive you are using TLS for the transport.  It looks like it comes in on TLS, but with a "sip:" uri and then Asterisk notices that the transport is TLS and writes "sips:" upon sending the message.  At least that is my best guess as to what might be happening.  What happens if you use another transport like UDP?
By: Anthony Messina (amessina) 2014-01-01 08:55:55.647-0600

Thanks, Kevin.  You are correct with regard to the sip vs. sips.  These particular connections are via TLS.  Even so, I am not sure that Asterisk needs to rewrite sip -> sips.  It did not do this in Asterisk 11.

On another note, I have applied your update patch and the from_domain works perfectly, except now the username portion of the From: "A User" <auser@example.com> is an internal PJSIP guid:

f: "A User" <sips:542f1557-197b-4849-ae02-6fa50bafd3b3@example.com>

I have attached another example message sent from <auser> to <buser>.

Thanks again for your help and Happy New Year!
By: Anthony Messina (amessina) 2014-01-01 09:04:21.993-0600

Sorry, hit send too fast.  The reason I'm not sure why sip -> sips rewrite needs to occur is that the MessageSend is using

{code}
[ Context 'test-messaging' created by 'pbx_config' ]
 's' =>            1. Verbose(1, Incoming MESSAGE from ${MESSAGE(from)} to ${MESSAGE(to)}) [pbx_config]
                   2. Set(TO=${CUT(MESSAGE(to),:,3)})            [pbx_config]
                   3. MessageSend(pjsip:${CUT(TO,@,1)}, ${MESSAGE(from)}) [pbx_config]
                   4. Hangup()                                   [pbx_config]
{code}

in my dialplan.  It seems to me it should use what it's given:

{code}
Executing [s@test-messaging:3] MessageSend("Message/ast_msg_queue", "pjsip:buser, "A User" <sip:auser@example.com>") in new stack
{code}

Perhaps I don't really understand the need (regardless of Asterisk) why there needs to be SIP vs SIPS, especially since (in the case of Asterisk), it's going to lookup its own contact via the AOR and use the proper transport anyway:

{code}
Contact:  auser/sip:auser@10.77.79.204:45006;transport=TLS
{code}
By: Kevin Harwell (kharwell) 2014-01-03 11:53:20.543-0600

I got a bit delete happy :-) and removed too much code that dealt with the 'From' portion.  That's hopefully fixed now (updated the review).

The username portion however does get generated as a GUID, but can be overridden using the 'from_user' option (similar to 'from_domain').  The way it is working now is the 'From' header gets created in res_pjsip using the defaults (username = GUID or 'from_user' if specified, domain = asterisk ip or 'from_domain' if specified).  Those values are used if no 'from' parameter is used in MessageSend.  If however a valid uri is specified in the 'from' parameter then the messaging code overwrites the default values for display name, username, and domain and that is what will be used in the outgoing 'From' header.

Hopefully that is acceptable.  Also the sip: to sips: issue should be resolved as well in the patch under review.  Thanks again for the feedback and testing this out!
By: Anthony Messina (amessina) 2014-01-03 15:34:50.903-0600

Thank you, Kevin!  This works perfectly!

One change I noticed however that doesn't seem that helpful in terms of the dialplan is that with the following

{code}
[ Context 'test-messaging' created by 'pbx_config' ]
 's' =>            1. Verbose(1, Incoming MESSAGE from ${MESSAGE(from)} to ${MESSAGE(to)}) [pbx_config]
                   2. Set(TO=${CUT(MESSAGE(to),:,3)})            [pbx_config]
                   3. MessageSend(pjsip:${CUT(TO,@,1)}, ${MESSAGE(from)}) [pbx_config]
                   4. Hangup()                                   [pbx_config]
{code}

The MESSAGE(to) is formatted as

{code}
pjsip:<sip:auser@example.com>
{code}

which seems a little redundant.  Is there any reason why it couldn't be formatted like the following which could accomodate all three types of MESSAGE uses in Asterisk and save us a CUT(MESSAGE(to),:,3)?

{code}
PJSIP
pjsip:auser@example.com

CHAN_SIP
sip:auser@example.com

XMPP:
xmpp:auser@example.com
{code}

If not, it's no problem.  Now on to the P-Asserted-Identity and [RFC 5876|http://tools.ietf.org/html/rfc5876]!  Thanks again!
By: Kevin Harwell (kharwell) 2014-01-06 12:54:39.089-0600

Glad to hear things are working better now!  I have also cleaned up the message formatting a bit as you suggested (uploaded to review).  The redundant formatting has been changed.  However, since all messages to be handled by the res_pjsip_messaging module have to begin with 'pjsip' when including the display name the following format is still used pjsip:"name" <sip:user@domain>.
By: Anthony Messina (amessina) 2014-01-07 13:06:03.784-0600

Thank you very much, Kevin.  The changes you have made to this point work perfectly.  It seems to me like it's ready to be pushed into branches/12.
By: Kevin Harwell (kharwell) 2014-01-08 15:43:29.506-0600

Anthony: Good to hear! And thanks to you for all your help and testing.
By: Kevin Harwell (kharwell) 2014-01-08 15:44:32.032-0600

I went ahead and created another issue for the P-Asserted-Identify stuff: [ASTERISK-23126]
By: Anthony Messina (amessina) 2014-01-08 16:15:32.088-0600

Thanks.  When do you anticipate this first part (Not the P-Asserted/Preferred-Identity) making it into branches/12?
By: Kevin Harwell (kharwell) 2014-01-08 17:07:21.359-0600

If no one else comments on the review then I'll hopefully get it committed tomorrow.