[Jingle] Comments on XEP-0251 standard

Dawid Nowak dawid.nowak at nortel.com
Thu Apr 23 05:36:59 CDT 2009


Hi,
My understanding is that XMPP relies on trust between peers. In order to
be able to send an IM, receive presence notifications or make a call
both peers have to authorize each other. This works fine for simple
calls but it might not necessary work for call transfers.

Caller                 Attendant                 Callee
  |                        |                        |
  |   session-initiate     |                        |
  |----------------------->|                        |
  |   ack                  |                        |
  |<-----------------------|                        |
  |   session-accept       |                        |
  |<-----------------------|                        |
  |   ack                  |                        |
  |----------------------->|                        |
  |   transfer             |                        |
  |<-----------------------|                        |
  |   ack                  |                        |
  |----------------------->|                        |
  |   hold                 |                        |
  |----------------------->|                        |
  |   ack                  |                        |
  |<-----------------------|                        |
  |                 session-initiate                |
  |------------------------------------------------>|
  |                       ack                       |
  |<------------------------------------------------|
  |   terminate            |                        |
  |----------------------->|                        |
  |   ack                  |                        |
  |<-----------------------|                        |
  |                 session-accept                  |
  |<------------------------------------------------|
  |                       ack                       |
  |------------------------------------------------>|
  |                    AUDIO (RTP)                  |
  |<===============================================>|
  |                                                 |
  


I think the main question here is if the Caller is authorized by Callee
to ring him. If both are authorized than everything is well but why
would you need the transfer scenario. Sure Caller could ring Callee
directly. 

If the Caller is not authorized to ring Callee directly and the
Attendant's help is needed I think we will run into a couple of
problems:

1. The XEP0166 says that the error should be returned if :
	"The initiator is unknown to the responder and the responder
does not communicate with unknown entities."

When Callee receives "session-initiate" from an unknown user it might
drop it straight away, but than it will never know that the call has
been transferred as it would have to inspect the packet in order to find
the "transfer" part. 

If we accept that the call should be accepted only if Callee trusts the
person who initiated the transfer (Attendant) than Callee would have to
inspect every "session-initiate" packet in search for the "transfer"
part and reject the call only if the "transfer" part is not present.
This put extra responsibility on the client, is inefficient and
potentially can lead to abuse of trust.

If Callee accepts calls from unknown entities by default, than there is
no real need for the "transfer" part in "session-initiate". Surely, all
it has to happen is that Attendant gives Caller Callee's address.

2. Let's consider scenario in which a very annoyed Caller has saved the
information from the first "session-initiate" and decided to taunt
Callee by sending this message over and over again. Even if Callee does
not trust Caller it still has to search the packet for the "transfer"
part and it should accept the call as Callee trusts Attendant. By
sending the same "session-initiate" packet Caller can seriously degrade
Callee ability to answer other calls.

Another example that the transfer scenario can lead to an abuse of trust
is where Stalker knows that Brad and Agelina are using XMPP and it can
be assumed that they are peers. In order to talk to Angelina it could be
sufficient for Stalker to craft a "session-initiate" packet with
"transfer" part from Brad. Not sure if he switch could detect such a
breach of trust.

3. Lets imagine that Caller, Attendant and Callee are all using Google
clients, Caller has been authorized by Attendant but not Callee, and
Caller seeks revenge on Callee. When Attendant has initiated the
transfer Caller will know Callee's address which in this case is also
its email. Nothing can stop Caller from sending spam, threat, etc. to
Callee's account.


Regards
Dawid








-----Original Message-----
From: jingle-bounces at xmpp.org [mailto:jingle-bounces at xmpp.org] On Behalf
Of Diana Cionoiu
Sent: 17 April 2009 17:34
To: XMPP Jingle
Subject: Re: [Jingle] [Fwd: [Standards] Comments on xep-025 standard]

Hello,

Is normal for a protocol based transfer to tell the number of called to
the caller party. If someone wants to hide that should use an
intelligent jabber server.
Anyway if you want PBX features like IVR you end up using an intelligent
server.

Diana

P.S. SIP has exactly the same behavior.

Peter Saint-Andre wrote:
> FYI regarding XEP-0251: Jingle Session Transfer...
>
>
> -------- Original Message --------
> Subject: 	[Standards] Comments on xep-025 standard
> Date: 	Wed, 15 Apr 2009 18:25:40 +0100
> From: 	Dawid Nowak <dawid.nowak at nortel.com>
> Reply-To: 	XMPP Standards <standards at xmpp.org>
> To: 	<standards at xmpp.org>
>
>
>
> Hi,
> I am no expert in XMPP but have been looking at this standard from a 
> call centre operator perspective and have following comments :
>
> 1. Caller always knows the address of Callee as it gets it from 
> Attendant in the transfer message. I suppose Callee and Attendant know

> about each other but I am not sure if the same could be said about 
> Caller. It is possible to envisage the scenario where Caller is 
> ringing a well known public number, is asked some questions by the IVR

> and transferred to a specific consultant based on hers/his answers.
>
> In the current proposal Attendant seems to pass Callee's address to 
> Caller without Callee's knowledge or permission. This address could 
> later be used to call Caller directly.
>
> 2. I think current proposal gives Caller too much control over the 
> transfer and it should be Attendant who controls the transfer
scenario.
>
> 3. Currently Callee can not indicate to Attendant that it can not 
> accept transfer.
>
>
> I have modified the existing diagram to reflect these points.
>
> Unattended transfer
>
> Caller                 Attendant(IVR,etc)         Callee
>   |                        |                        |
>   |   session-initiate     |                        |
>   |----------------------->|                        |
>   |   ack                  |                        |
>   |<-----------------------|                        |
>   |   session-accept       |                        |
>   |<-----------------------|                        |
>   |   ack                  |                        |
>   |----------------------->|                        |
>   |    AUDIO (RTP)         |                        |
>   |<======================>|                        |
>   |                        |                        |
>   |                 transfer-indication             |
>   |                                |----------------------->|
>   |                        |          ack           |
>   |     transfer           |<-----------------------|
>   |<-----------------------|                        |
>   |       ack              |                        |
>   |----------------------->|                        |
>   |                 session-initiate                |
>   |------------------------------------------------>|
>   |                 session-accept                  |
>   |<------------------------------------------------|
>   |                       ack                       |
>   |------------------------------------------------>|
>   |                    AUDIO (RTP)                  |
>   |<===============================================>|
>
>
> Where transfer-indication is:
>
> <iq from='attendant at office.biz/desk'
>         id='transfer-indication1'
>         to='boss at bigdesk.biz/phone'
>         type='set'>
>         <jingle xmlns='urn:xmpp:jingle:0'
>                 action='session-info'
>                 initiator='caller at world.sun/phone'
>                 responder='attendant at office.biz/desk'
>                 sid='851ba2'>
>         <transfer-indication xmlns='urn:xmpp:jingle:transfer:0'
>         from='caller at world.sun/phone'
> transfer-placeholder='transfer at office.biz/transfer1'
> transfer-id='unique-transfer-id'/>
>         </jingle>
> </iq>
>
>
> Attendant sends Transfer back to Client. This message could also 
> indicate that existing call between Caller and Attendant should be 
> terminated.
>
> <iq from='attendant at office.biz/desk'
>         id='transfer1'
>         to='caller at world.sun/phone'
>         type='set'>
>         <jingle xmlns='urn:xmpp:jingle:0'
>                 action='session-info'
>                 initiator='caller at world.sun/phone'
>                 responder='attendant at office.biz/desk'
>                 sid='851ba2'>
>         <transfer xmlns='urn:xmpp:jingle:transfer:0'
>         to='transfer at office.biz/transfer1'
>                 transfer-id='unique-transfer-id'/>
>
>          </jingle>
> </iq>
>
>
> And Client initiates a new session to a placeholder address which the 
> switch translates into a valid address.
>
> <iq from='attendant at office.biz/desk'
>         id='jingle3'
>         to='transfer at office.biz/transfer1'
>         type='set'>
>         <jingle xmlns='urn:xmpp:jingle:0'
>                 action='session-initiate'
>                 initiator='caller at world.sun/phone'
>                 sid='1a332d'>
>                 <content creator='initiator'
>                 disposition='session'
>                 name='voice'>
>                         <description
xmlns='urn:xmpp:jingle:apps:rtp:0'
>                   media='audio'>
>                         <payload-type id='0' name='PCMU' />
>                         </description>
>                         <transport
> xmlns='urn:xmpp:jingle:transports:ice-udp:0'/>
>                 </content>
>                 <transfer xmlns='urn:xmpp:jingle:transfer:0'
> transfer-id='unique-transfer-id'/>
>         </jingle>
> </iq>
>
> Regards
> Dawid Nowak
>
>
>   



More information about the Jingle mailing list