Re: [Kamailio-Users] [Kamailio-Devel] New module : PURPLE - IM/Presence multi-protocol gateway
29 Jan
2009
29 Jan
'09
3:24 p.m.
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?
Regards.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
_______________________________________________
Kamailio (OpenSER) - Devel mailing list
Devel(a)lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/devel
http://lists.openser-project.org/cgi-bin/mailman/listinfo/devel
29 Jan
29 Jan
3:48 p.m.
New subject: [Kamailio-Users] [Kamailio-Devel] New module : PURPLE - IM/Presence multi-protocol gateway
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
4:11 p.m.
New subject: [Kamailio-Users] [Kamailio-Devel] New module : PURPLE - IM/Presence multi-protocol gateway
2009/1/29 Victor Pascual Ávila <victor.pascual.avila(a)gmail.com>om>:
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 :)
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
3 Feb
3 Feb
9:35 a.m.
New subject: [Kamailio-Users] [Kamailio-Devel] New module : PURPLE - IM/Presence multi-protocol gateway
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(a)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(a)aliax.net <mailto:ibc@aliax.net>>
_______________________________________________
Kamailio (OpenSER) - Devel mailing list
Devel(a)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(a)lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
--
Daniel-Constantin Mierla
http://www.asipto.com
10:46 a.m.
New subject: [Kamailio-Users] [Kamailio-Devel] New module : PURPLE - IM/Presence multi-protocol gateway
Hello everyone,
and thank you for your welcome !
2009/2/3 Daniel-Constantin Mierla <miconda(a)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
2:14 p.m.
New subject: [Kamailio-Users] [Kamailio-Devel] New module : PURPLE - IM/Presence multi-protocol gateway
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(a)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
--
Daniel-Constantin Mierla
http://www.asipto.com
8:50 p.m.
New subject: [Kamailio-Users] [Kamailio-Devel] New module : PURPLE - IM/Presence multi-protocol gateway
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?
--
Iñaki Baz Castillo
9:15 p.m.
New subject: [Kamailio-Users] [Kamailio-Devel] New module : PURPLE - IM/Presence multi-protocol gateway
On 02/03/2009 09:50 PM, Iñaki Baz Castillo wrote:
El Martes, 3 de Febrero de 2009, Daniel-Constantin
Mierla escribió:
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
http://www.asipto.com
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?
5566
days inactive
5571
days old
7 comments
4 participants
participants (4)
-
Daniel-Constantin Mierla -
Eric PTAK -
Iñaki Baz Castillo -
Victor Pascual Ávila