Subject: RE: [SIP] Solving the REFER retransmit issue

From: Rohan Mahy <[email-masked]>
Date: Tue, 02 Jan 2001 10:06:47 -0800

At 01:54 PM 12/29/00 , Ben Campbell wrote:
>> From: Billy Biggs [mailto:[email-masked]]
>> Sent: Friday, December 29, 2000 3:31 PM
>> To: Ben Campbell
>> Cc: Jonathan Rosenberg; Henning G. Schulzrinne; Rohan Mahy; Robert
>> Sparks; SIP List; Sean Olson
>> Subject: Re: [SIP] Solving the REFER retransmit issue
>>
>>
>> Ben Campbell ([email-masked]):
>>
>> > I realize this creates additional message overhead in the case where
>> > the REFER-or cares about the results. However, if present day PSTN
>> > stuff is an example, I fully expect the vast majority of REFER
>> > applications to _not_ care about the results (e.g. blind transfer or
>> > similar). In this case, the implied subscription actually creates
>> > additional message overhead. [...]
>>
>>   Attended transfer (call handoff) is the primitve necessary for most
>> advanced phone services.  Say B is in a 3-way call:
>
>I do not suggest that attended transfer is unimportant, merely that blind
>transfers will probably happen more often in the SIP world at large. 

I disagree.  Attended transfer is used much more often than you imply in
the PBX and PSTN worlds, and with the built-in redirection without
answering, and forking funtionality of SIP, many more current uses of blind
transfer can be avoided.  remember that the problem blind transfer was
trying to solve was to get rid of the call.  REFER with implicit NOTIFY
(and Billy's proposal for that matter) gets rid of the call, and you can
blissfully ignore any NOTIFYs you get.

>While
>attended transfer is a primitive of advanced services, blind transfer is an
>extremely commonly used _simple_ service. I prefer to optimize for the
>simple case, and make the advanced case do a bit more work than the other
>way around. The timing expectations for an attended transfer may be tight,
>but they are even tighter for an unattended transfer.

hogwash.  the timing expectations are identical.  attended transfer is
*HARDLY* an advanced case.   For example: screening your incoming voicemail
is a more advanced feature which uses more than one primitive working
together.  if we cripple our primitives now, we will have call flows worthy
of H.323v1, huge message counts, and the services everyone keeps promising
will not appear.  (I counted over 100 messages for a fairly straightforward
call screening example with the REFER, SUB, NTFY method).  God forbid if we
add manyfolks QoS to any of these flows, or security....

fundamentally we need to initiate, terminate, move, join, split, and get
status of call-legs.  THESE are the types of primitives we need.  An
inherent part of moving call legs is being able to find out what happened;
it is not optional.

thanks,
-rohan

>
>>
>>                        A       C
>>                          \   /
>>                            B
>>
>>   B needs to know when A has successfully contacted C so it can
>> terminate its calls.
>>
>>   In any reasonable phone system, the handoff has to be close to
>> instantaneous.  This is at odds with suggestions that:
>>
>>  - B SUBSCRIBE'ing to A before getting back a response.
>>  - A sending a NOTIFY before a re-INVITE or BYE.
>>  - ...
>>
>>   Please, consider implementation pain and message verbosity.
>>
>
>I did not see any proposal that said B _must_ wait for the notify to send a
>BYE. I suspect that would be a common implementation, but B _could_ send a
>bye immediately, then if it later received a NOTIFY indicating failure, it
>could notify the user, invite A to a new call, or whatever behavior makes
>the most sense in the situation.
>
>

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: Rick Dean <[email-masked]>
Date: Fri, 5 Jan 2001 16:41:03 -0600

> inherent part of moving call legs is being able to find out what happened;

For supervised call transfer, you will have problems 
if you want the remote device to do
the audio mixing.  

If you mix in the local device, then the
only primative you need 
is glueing together the two call legs at the end of
the conference stage.  Thus, you effectively excuse
yourself from the back-to-back UA functionality 
(a.k.a. Rosenberg 3rd party call control).
This is the simple primative I want.  Let us be
able to reduce the number of network devices
the signalling snakes through, thus making the
call more reliable, signaling faster, etc.

As much as I prefer smart end points,
and hate stateful network ones,
I predict remote back-to-back UA's will eventually
be popular, because this is what a PBX is.   
Many of the features are inharently server based.  
Also, If you want to build a reliable system
(and trust me telephony places a high
premium on reliability)  then your 
back-to-back UA PBX will hide everything
from the outside world.  

Using only the basics of SIP has some precedent.  
The best web sites (Yahoo, Amazon, eBay, eGroups, 
McGlen, etc) use simple HTML (no JavaScript).  
The processing and state is in the server.
Testing is much easier.

Now, that I have said this, the obvious question
is how to command the smart back-to-back UA PBX
without using the 12 DTMF keys.  Each feature
is unique.  Try designing call park.

For generalized features,
sending the requests isn't the hard part,
but displaying it to the user is.  Ultimately,
the solution will look more like a text based
web browser in the phone.

--
Rick
[email-masked]

P.S. Please forgive me if this has already been
discussed on the list.  I have only been following
it until recently via proxy.