Re: [Kamailio-Users] [Kamailio-Devel] New module : PURPLE - IM/Presence multi-protocol gateway
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?
Regards.
-- Iñaki Baz Castillo ibc@aliax.net
Kamailio (OpenSER) - Devel mailing list Devel@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/devel http://lists.openser-project.org/cgi-bin/mailman/listinfo/devel
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,
2009/1/29 Victor Pascual Ávila victor.pascual.avila@gmail.com:
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.
Good point. However, note that the response code is choosen in the Kamailio script, it's not hardcoded in the module source, so the only needed change is in the módule documentation example :)
Hello,
On 01/29/2009 04:24 PM, Eric PTAK 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 ?
code will be unfrozen in few weeks. As personal preference, returning code is a more flexible way, as the config writer can chose what to send.
Changing the return code for a function is not a new feature IMO. However, I mean by that to do it with the current design. If I am not wrong there is a pipe communication between sip worker processes and purple worker processes.
You cannot get the error in purple processes and return it in the sip process. What you can do is to have a different reply code if you had an error while building the packet for purple process (e.g., no more memory) and once you send it to purple process return true and the code writer should reply with 202 Message accepted.
Cheers, Daniel
If yes, we may add that limitation in the doc for now.
Eric.
2009/1/29 Iñaki Baz Castillo ibc@aliax.net mailto: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? Regards. -- Iñaki Baz Castillo <ibc@aliax.net <mailto:ibc@aliax.net>> _______________________________________________ Kamailio (OpenSER) - Devel mailing list Devel@lists.kamailio.org <mailto:Devel@lists.kamailio.org> http://lists.kamailio.org/cgi-bin/mailman/listinfo/devel http://lists.openser-project.org/cgi-bin/mailman/listinfo/devel
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
Hello everyone, and thank you for your welcome !
2009/2/3 Daniel-Constantin Mierla miconda@gmail.com
Hello,
code will be unfrozen in few weeks. As personal preference, returning code is a more flexible way, as the config writer can chose what to send.
Changing the return code for a function is not a new feature IMO. However, I mean by that to do it with the current design. If I am not wrong there is a pipe communication between sip worker processes and purple worker processes.
Yes you're right, purple has it's own process.
You cannot get the error in purple processes and return it in the sip process. What you can do is to have a different reply code if you had an error while building the packet for purple process (e.g., no more memory) and once you send it to purple process return true and the code writer should reply with 202 Message accepted.
My problem is that I currently don't know how to return synchronously a reply code from the pipe's other side. Can I use the pipe to write back from the purple process to the "main" process ?
Cheers, Daniel
Hello,
On 02/03/2009 11:46 AM, Eric PTAK wrote:
Hello everyone, and thank you for your welcome !
2009/2/3 Daniel-Constantin Mierla <miconda@gmail.com mailto:miconda@gmail.com>
Hello, code will be unfrozen in few weeks. As personal preference, returning code is a more flexible way, as the config writer can chose what to send. Changing the return code for a function is not a new feature IMO. However, I mean by that to do it with the current design. If I am not wrong there is a pipe communication between sip worker processes and purple worker processes.Yes you're right, purple has it's own process.
You cannot get the error in purple processes and return it in the sip process. What you can do is to have a different reply code if you had an error while building the packet for purple process (e.g., no more memory) and once you send it to purple process return true and the code writer should reply with 202 Message accepted.My problem is that I currently don't know how to return synchronously a reply code from the pipe's other side. Can I use the pipe to write back from the purple process to the "main" process ?
However you cannot wait until the final destination sends back a reply and makes no sense to wait for a reply from purple process. 202 Accepted is the code intended for such cases (gateway).
So, if you don't get any internal error until you put the message on the pipe, return true. If some errors, then you can differentiate via negative reply codes.
Cheers, Daniel
El Martes, 3 de Febrero de 2009, Daniel-Constantin Mierla escribió:
However you cannot wait until the final destination sends back a reply and makes no sense to wait for a reply from purple process. 202 Accepted is the code intended for such cases (gateway).
So, if you don't get any internal error until you put the message on the pipe, return true. If some errors, then you can differentiate via negative reply codes.
Does it mean that a mechanims as "reply_route/failure_route" would be required for this module in order to process the response?
On 02/03/2009 09:50 PM, Iñaki Baz Castillo wrote:
El Martes, 3 de Febrero de 2009, Daniel-Constantin Mierla escribió:
However you cannot wait until the final destination sends back a reply and makes no sense to wait for a reply from purple process. 202 Accepted is the code intended for such cases (gateway).
So, if you don't get any internal error until you put the message on the pipe, return true. If some errors, then you can differentiate via negative reply codes.
Does it mean that a mechanims as "reply_route/failure_route" would be required for this module in order to process the response?
usually when there is protocol gatewaying it is hard to be strict in both sides.
I was authoring the first draft of sip-xmpp interoperability back in 2003. The design is different in in xmpp. You can practically get a message of type <error> long time after you send your <message> - the <error> message includes the body of <message>. XMPP does not follow request-reply model, therefore is hard to map directly on sip.
It is one of the reasons for having 202 Accepted.
Such case could translate in: - sip sends message - gateway sends 202 back - when <error> comes, the gateway generates a message (MESSAGE/INFO) with a body containing relevant information about the error and the original message text. - sip device sends back 200 ok acknowledging the receive of the error info
Now, I am not up to date with latest xmpp specs. I think this is the last combined simple-xmpp draft: http://tools.ietf.org/html/draft-saintandre-xmpp-simple-10
Afterwards it was broken in couple of pieces (core part, media, im, ...). I plan to attend XMPP track at fosdem and get some updates from Peter St. Andre, the guy who is authoring now sip-xmpp hate-love relation.
Cheers, Daniel
-
Daniel-Constantin Mierla -
Eric PTAK -
Iñaki Baz Castillo -
Victor Pascual Ávila