On Thu, Jan 29, 2009 at 3:24 PM, Eric PTAK eric.ptak.fr@gmail.com wrote:
I agree with you, the module needs improvements on that point. It's a really old point I missed when we decided to reuse and to reverse that module. I think about two manners in order to solve it :
- implement a return code for purple_send_message
- sending a reply directly in the module
Regarding the design of the module, I think both possibilities needs a lot of mod. I'm not sure how to consider that mod as it's not a bug but a limitation. Is it a new feature I'll code when the trunk will be unfreezed ? If yes, we may add that limitation in the doc for now.
Eric.
2009/1/29 Iñaki Baz Castillo ibc@aliax.net
Why is needed to reply "200"? doesn't this module act as a proxy waiting for a response from downstread (i.e. MSN network) and mapping that response to the appropiate SIP code?
This is: if I send a MESSAGE to a MSN account not online (or not existing) I will receive "200" anyway, shouldn't I receive a 480 or 404?
First of all, Eric thanks indeed for the new module :-)
If we are to live with such a limitation I would suggest sending back a 202 response instead. It doesn't make a big difference but the return code might be relevant in some scenarios:
-If the UAC receives a 200 OK response it may assume the message has been delivered to the final destination -If the UAC receives a 202 Accepted response it may assume the message has been delivered to a gateway but has no information whether the message has been delivered to the final destination or not.
Cheers,