[OpenSER-Devel] [ openser-Patches-1887826 ] [MSILO] Some improvements

[SourceForge.net]

Patches item #1887826, was opened at 2008-02-06 14:01
Message generated for change (Comment added) made by miconda
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=743022&aid=1887826&group_id=139143

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: ver devel
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Iñaki Baz (ibc_sf)
Assigned to: Daniel-Constantin Mierla (miconda)
Summary: [MSILO] Some improvements

Initial Comment:
I've been playing a bit with msilo.c code and changed some things to make it more flexible. The changes are made from SVN rev 3632.


This is my changelog:

- Notification "From" is now the original destination ("registrar" parameter deleted). I think this is better since the sender won't see a new IM window 
from a strange user when OpenSer sends back the notification. Instead he will see it in the same IM window.

- Added "offline_message" parameter allowing HTML. So the admin could set him own notification message in openser.cfg. If not set, the default value is:
  "<em>I'm offline. The message will be delivered when I'm online.</em>"

- Deleted "Contact" header in notification (not necessary in MESSAGE since MESSAGE doesn't establish a dialog).

- Deleted CONTACT* and OFFLINE_MESSAGE* #defines and buf1[1024] (not necessary now).

- Added HEADERS #define to set "Content-Type" header as "text/html". I've not made "Content-Type" as a parameter since "text/html" accepts plain text perfectly, but it could be a new "notification_content_type" parameter.

----------------------------------------------------------------------

>Comment By: Daniel-Constantin Mierla (miconda)
Date: 2008-05-17 10:39

Message:
Logged In: YES 
user_id=1246013
Originator: NO

Please try the latest SVN. I have committed a different version where From
address, Contact header, message body and content type can be controlled
via module parameters and can include pseudo-variables for a dynamic
content. Report any issue here.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2008-02-06 19:52

Message:
Logged In: NO 

I understand now, it was difficult from your notes if you refering to the
"notification sent back to the sender" or the "message being delivered to
the recipient".

I would agree that the default should be the "original to" is now the
"from" in the notification to sender (if you are using that feature).

As long as you don't remove the contact/registrar addr, then smart clients
won't generate (2) offline notifications (one on the 202, the second on
your notification MESSAGE).

----------------------------------------------------------------------

Comment By: Iñaki Baz (ibc_sf)
Date: 2008-02-06 19:37

Message:
Logged In: YES 
user_id=1844020
Originator: YES

> 1. Removing the contact address and the registrar address removes the
> ability for an endpoint client to tell that the message was queued.
(Aside
> from Date header). If the contact address is your registrar (which is
why
> its called that) then your client can know that it was a queued offline
> message.

Ok, the "Contact" could remain as "registrar" while "From" could be,
opcionally, the original destination ("To" header in original MESSAGE).



> 2. Adding the "offline_message" param is not the ideal way to go about
> solving this problem. When a message is queued for delivery a 202 is
> supposed to be returned to the sending client. 202 indicates that this
> message was accepted but unable to be end to end delivered. Proper
clients
> should show the "This user is offline" as a result of the 202.

MSILO module does ALREADY have this feature (sending back a notification
MESSAGE to the sender). Yes, it could be nice if the UAC show in the UI a
response code for a 202, or the content of a "Warning" header, but... any
UAC doing that? what is wrong with, opcionally, allow OpenSer generating a
new MESSAGE as reply? Do you suggest to eliminate this **already**
implemented feature?



> 3. You mention that the Notification "From" is now the original
> destination, do you mean that the original From Uri is now the "To" on 
> the message being delivered from the SILO?

No, I mean that in the generated by OpenSer notification MESSAGE to the
sender, the "From" is now the original destination instead the "registrar"
parameter (opcional). So, if user_A sends a MESSAGE to user_B who is
offline, OpenSer would reply a notification MESSAGE to user_A like:

  MESSAGE sip:user_A
  From: <sip:user_B>   <---- Destination in original MESSAGE from user_A
  To: <sip:user_A>
  Contact: <sip:registrar>  <--- As you suggested in 1)

Is it ok?

----------------------------------------------------------------------

Comment By: Aron Rosenberg (amr42)
Date: 2008-02-06 19:19

Message:
Logged In: YES 
user_id=43318
Originator: NO

Several comments:

1. Removing the contact address and the registrar address removes the
ability for an endpoint client to tell that the message was queued. (Aside
from Date header). If the contact address is your registrar (which is why
its called that) then your client can know that it was a queued offline
message. Counterpath does the wrong thing (they use the Contact address as
the "From" instead of the From Uri)

2. Adding the "offline_message" param is not the ideal way to go about
solving this problem. When a message is queued for delivery a 202 is
supposed to be returned to the sending client. 202 indicates that this
message was accepted but unable to be end to end delivered. Proper clients
should show the "This user is offline" as a result of the 202.

3. You mention that the Notification "From" is now the original
destination, do you mean that the original From Uri is now the "To" on the
message being delivered from the SILO? This seems completely wrong. See #1,
but your workaround while fixing counterpath breaks other compliant SIP
endpoints which referenace the To Uri and From Uri (rather than Contact or
Via or others)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=743022&aid=1887826&group_id=139143