[SIP-XMPP] bar BOF report

[Peter Saint-Andre]

We held a bar BOF at IETF 73 today. The following people participated:

Joe Hildebrand, Cisco
Peter Saint-Andre, Cisco
Salvatore Loreto, Ericsson
Markus Isomaki, Nokia
Zoltan Ordogh, Nokia
Simo Veikkolainen, Nokia
Scott Lawrence, Nortel
Xavier Marjou, Orange/FT
Ben Campbell, Tekelec
Adam Roach, Tekelec
Dan York, Voxeo

Topics discussed, in no particular order:

1. Service federation via gateways -- this is addressed by the current
drafts, see http://xmpp.org/internet-drafts/ and look for the I-Ds
called draft-saintandre-sip-xmpp-* and send feedback to this list. We
may try to hold a BOF at IETF 74 about these I-Ds as a forcing function
to get feedback.

2. Sharing presence between SIP UAs and XMPP clients within a domain /
PBX (e.g., take call on IP phone and automatically change presence in
Jabber client, or vice-versa). This may be an implementation and
deployment issue, but may also turn on item #3.

3. Identity mapping -- we may be able to use XEP-0152 (Reachability
Addresses) and SIP Redirect (is that 305 or 380?). We also discussed the
possibility of using enum etc. Xavier mentioned an older I-D by Henning
Shulzrinne on a related topic and may post that to this list.

4. Other topics to discuss for future mapping work: file transfer,
capabilities, "poke", emoticons, [X]HTML, typing indicators.

I'm writing this in a hurry before I leave for the airport, so please
let me know if I've missed anything.

Thanks for participating!

Peter

[Xavier Marjou]

The draft was the following one:
http://tools.ietf.org/html/draft-schulzrinne-sipping-id-relationships-00

It was discussed during IETF63:
http://www.ietf.org/proceedings/05aug/sipping.html

Cheers,
Xavier

On Wed, Nov 19, 2008 at 4:23 PM, Peter Saint-Andre <stpeter (AT) stpeter (DOT) im> wrote:
> We held a bar BOF at IETF 73 today. The following people participated:
>
> Joe Hildebrand, Cisco
> Peter Saint-Andre, Cisco
> Salvatore Loreto, Ericsson
> Markus Isomaki, Nokia
> Zoltan Ordogh, Nokia
> Simo Veikkolainen, Nokia
> Scott Lawrence, Nortel
> Xavier Marjou, Orange/FT
> Ben Campbell, Tekelec
> Adam Roach, Tekelec
> Dan York, Voxeo
>
> Topics discussed, in no particular order:
>
> 1. Service federation via gateways -- this is addressed by the current
> drafts, see http://xmpp.org/internet-drafts/ and look for the I-Ds
> called draft-saintandre-sip-xmpp-* and send feedback to this list. We
> may try to hold a BOF at IETF 74 about these I-Ds as a forcing function
> to get feedback.
>
> 2. Sharing presence between SIP UAs and XMPP clients within a domain /
> PBX (e.g., take call on IP phone and automatically change presence in
> Jabber client, or vice-versa). This may be an implementation and
> deployment issue, but may also turn on item #3.
>
> 3. Identity mapping -- we may be able to use XEP-0152 (Reachability
> Addresses) and SIP Redirect (is that 305 or 380?). We also discussed the
> possibility of using enum etc. Xavier mentioned an older I-D by Henning
> Shulzrinne on a related topic and may post that to this list.
>
> 4. Other topics to discuss for future mapping work: file transfer,
> capabilities, "poke", emoticons, [X]HTML, typing indicators.
>
> I'm writing this in a hurry before I leave for the airport, so please
> let me know if I've missed anything.
>
> Thanks for participating!
>
> Peter
>

[Adam Roach]

On 11/19/08 4:23 PM, Peter Saint-Andre wrote:
>
> 3. Identity mapping -- we may be able to use XEP-0152 (Reachability
> Addresses) and SIP Redirect (is that 305 or 380?). We also discussed the
> possibility of using enum etc. Xavier mentioned an older I-D by Henning
> Shulzrinne on a related topic and may post that to this list.

To be clear, we discussed a number of approaches that could be used
here. I'll try to summarize a handful of them, focusing primarily on
what we would need to do to contact an XMPP client from a SIP client.

One is the use of XMPP URIs as Request URIs in SIP messages. There are
many variations on this theme. In one of them, the client performs
standard XMPP SRV record lookups, and then routes the SIP message to the
resulting address -- this requires a SIP server to be co-located with
the XMPP server for the parting being contacted. (I'm eliding the XMPP
server in this diagram)

SIP Client XMPP Server XMPP SIP Gateway XMPP Client
SIP Name Mapper
| | | |
| | | |
| | | |
|(1) INVITE xmpp:adam (AT) jabber (DOT) example.com| |
|------------------>| | |
|(2) 301 Contact: <sip:FE436B07 (AT) gw (DOT) example.com> |
|<------------------| | |
|(3) INVITE sip:FE436B07 (AT) gw (DOT) example.com | |
|-------------------------------------->| |
|(4) MSRP Session Established | |
|.......................................| |
| | |(5) XMPP Session
Established
| | |...................|
| | | |



An alternate approach is simply provisioning an "XMPP Resolving Proxy"
into the client, to which all XMPP URIs are routed.


SIP Client SIP Server XMPP SIP Gateway XMPP
Server XMPP Client
| | |
| |
| | |
| |
| | |
| |
|(1) INVITE xmpp:adam (AT) jabber (DOT) example.com|
| |
|------------------>| |
| |
| |(2) XEP-0152 Resolution
| |
|
|.......................................| |
|(3) 301 Contact: <sip:FE436B07 (AT) gw (DOT) example.com>
| |
|<------------------| |
| |
|(4) INVITE sip:FE436B07 (AT) gw (DOT) example.com |
| |
|-------------------------------------->|
| |
|(5) MSRP Session Established |
| |
|.......................................|
| |
| | |(6) XMPP Session
Established |
| |
|...................| |
| | |
|(7) XMPP Session Established
| | |
|...................|
| | |
| |
| | |
| |



Additionally, the SIP thing that the client contacts may well elect to
simply proxy the request forward to the appropriate SIP/XMPP gateway
instead of sending a 301 response. This would be at its discretion, and
not something we'd need to standardize.

Yet another approach would be the use RFC 3404 mechanism at the SIP
client to translate the XMPP URI into a SIP URI; something like:

SIP Client DNS XMPP SIP Gateway XMPP Client
| | | |
| | | |
| | | |
|(1) NAPTR xmpp:adam (AT) jabber (DOT) example.com | |
|------------------>| | |
|(2) Continues 3404 procedures | |
|...................| | |
|(3) sip:adam (AT) gw (DOT) example.com | |
|<------------------| | |
|(4) INVITE sip:adam (AT) gw (DOT) example.com | |
|-------------------------------------->| |
|(5) MSRP Session Established | |
|.......................................| |
| | |(6) XMPP Session
Established
| | |...................|
| | | |
| | | |


Honestly, my understanding of 3404 is a bit too loose to completely
explain steps 1 through 3, but I'm relatively certain that functionality
like this is actually supported by 3404.

/a