[Kamailio-Users] [Kamailio-Devel] New module : PURPLE - IM/Presence multi-protocol gateway

[Daniel-Constantin Mierla]

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
http://www.asipto.com