29 Jan
2009
29 Jan
'09
9:48 a.m.
On Thu, Jan 29, 2009 at 3:24 PM, Eric PTAK <eric.ptak.fr(a)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(a)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,
--
Victor Pascual Ávila