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