[Jingle] Comments on XEP-0251 standard

Unnikrishnan V ukv1977 at gmail.com
Thu Apr 23 14:17:52 CDT 2009


Have look on
http://www.tech-invite.com/Ti-sip-service-5.html

and

http://www.tech-invite.com/Ti-sip-service-4.html

As  a standard, the missing thing may be the notification after
disconnect of the call.

thanx
unni


On Thu, Apr 23, 2009 at 3:36 AM, Dawid Nowak <dawid.nowak at nortel.com> wrote:
> 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