Re: [Enum] requesting reviewers for draft-ietf-enum-xmpp..

   From: Duane <duane@e164.org>

   I've had a re-think on this, at least to a limited extent, take for
   example jingle/xmpp integration into Asterisk/FreeSwitch etc, asterisk
   obviously can't text message (unless you wanted to go into text to
   speech/speech to text), and a client like gaim can't handle voice, so I
   guess this is where listing type of services available in DNS comes in
   so clients don't need to handshake to indicate what they can accept.
   Although I guess the down side to not listing is of course lagged
   initial setup, but would this be detrimental?

Actually, I think this is not the problem it appears to be.  Consider
if I've registered my SIP AOR in the ENUM database for my E.164
number.  And consider that that AOR routes to two UAs:  one is my desk
phone, which can handle audio media, and one is my IM client, which
can handle (whatever the SIP IM conversation media name is).

If someone attempts to call me with an audio device, it will send an
INVITE to the AOR, and the proxy will fork it to both of my UAs.  But
the SDP negotiation with the IM client will fail becuase there's no
common media type, whereas the SDP negotiation with the phone will
progress to an early dialog and ring my phone.

The reverse happens if someone attempts to connect to my E.164 number
using a SIMPLE IM client.

The reason this works is that although, as you say, this requires
clients "to handshake to indicate what they can accept", SIP *already*
does the handshaking to determine which UA can accept what.

(Asterisk, perhaps, cannot handle text messaging, but that would be
because Asterisk isn't a real SIP proxy.  Whereas sipX, SER, etc. can
handle text messaging transparently.)

Dale

_______________________________________________
enum mailing list
enum@ietf.org
https://www1.ietf.org/mailman/listinfo/enum