RE: [Sipping] New Service Examples I-D

["Steve Fisher" <[e-mail]>]

Adam,

While I agree with you for the most part, in that SIP clearly is not a
stimulus protocol like MGCP and thus relies on the UA to provide much of
the functionality, I'm not sure some of these features can be dismissed
so easily. Behind your answers there appear to be a couple of
assumptions:

1) Each SIP address maps to a single device, and not to a user who may
have multiple devices.

2) This device is always on.

Consider, for example, Call Return (*69 in the PSTN). While SIP
terminals may of course very easily implement a version of this feature
by simply keeping a call log and calling back the last INVITE received,
consider the following cases:

1) When the last person called, no terminals were registered.

2) When the last person called, a terminal was registered (say, in the
home), but not the terminal that the intended recipient is actually
using (say, a laptop or mobile phone).

In both of these cases there might be value in a network-based Call
Return feature that would enable the intended recipient place a return
call using any device. On rich clients this could be implemented, for
example, using a call log in a web browser, while on dumb terminals this
could be implemented by *69. In either case, the recipient can now
easily call the last caller back, while if the feature had been
implemented only in the terminal, that would not be the case.

As another example, consider Facilitated Calling - Redial (*66 in the
PSTN). Again, if the user only has one terminal this can easily be
implemented by the terminal continually retrying the number. Consider,
however, if the caller originally placed the call from one terminal
(say, at home), and then left home, a terminal based solution would be
of no help. If Redial was implemented in the network, however, and the
caller had two terminals registered, then the feature would still have
value, since the caller could be connected via this second terminal
(say, a mobile phone).

Since in my view one of the primary benefits of SIP is its ability to
allow addresses to be associated with users, rather than devices, and to
allow any number of devices to be dynamically bound to that address, I
thought it might be worth pointing out that in some cases this ability
limits the value of features implemented solely by the terminal.

Steve


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf
Of Adam Roach
Sent: Wednesday, July 24, 2002 10:07 PM
To: 'Avella, Alejandro'; 'Alan Johnston'; [e-mail]
Subject: RE: [Sipping] New Service Examples I-D


Unfortunately, most of the proposed services either
don't apply to SIP or don't show up in call flows.

> Call Progress Tone - Busy

This is a terminal decision. Many phone-shaped terminals may choose to
implement this on receipt of a 486 or 603. Many terminals, especially
those not shaped like phones, will indicate "Busy" in some other way.

> Call Progress Tone - Fast Busy

This is a terminal decision. Many phone-shaped terminals may choose to
implement this on receipt of an unrecoverable failure response. Many
terminals, especially those not shaped like phones, will indicate
failure in some other way.

> Call Progress Tone -- Offhook Warning

This is a terminal decision. Some phone-shaped terminals might choose to
play an offhook warning tone, although it is not immediately obvious
why. Historically, offhook warning tones have been used because (a) an
offhook PSTN phone cannot be made to ring, and (b) offhook phones tie up
resources at the CO/EO/RT (as applicable). Neither applies to SIP
terminals, so the utility of an offhook warning tone is extremely
dubious.

Non-phone shaped terminals don't even have a concept of "offhook".

All of that notwithstanding, there would be no conceivable callflow
associated with this situation.

> Play SIT tone

This is a terminal decision. Many phone-shaped terminals may choose to
implement this on receipt of an unrecoverable failure response. Many
terminals, especially those not shaped like phones, will indicate
failure in some other way.

> Re-route call to announcement server

This seems of limited utility. Sending an appropriate SIP error response
instead of playing an announcement allows terminals to render error
information in a format appropriate for their user. Announcements won't
always be applicable. Consider an INVITE meant to establish an instant
messaging session -- redirecting such a call to an announcement server
would be annoying at best; and, for non-voice clients, it would be a
complete failure.

> Caller ID - Onhook with Ringing        

This is a terminal decision. The information to present arrives in SIP
headers ("From" if you don't care about validation, and the headers
defined by the identity work, if you do). There is no call flow
associated with this serivice.

> Caller ID - Off hook with Call Waiting

This is a terminal decision. The information to present arrives in SIP
headers ("From" if you don't care about validation, and the headers
defined by the identity work, if you do). There is no call flow
associated with this serivice.

> Block Caller ID

This is a terminal decision. If you don't want the recipient
to know who you are, don't tell them. There is no interesting call flow
associated with this serivice; 3261 already shows "From" headers
containing the word "anonymous".

> Message Waiting Lamp (Visual Message Waiting Indication - VMWI)

Now, this *is* an interesting service. It is covered in
http://www.ietf.org/internet-drafts/draft-ietf-sipping-mwi-00.txt
and doesn't really need reiteration elsewhere.

>Feature Invocation or Cancellation      
> From Onhook - Invocation/Cancellation with Dial-Code Only      
> From Onhook - Invocation with Dial-Code and Destination Address
> From Offhook - Invocation/Cancellation with Flash hook and Dial-Code
Only 
> From Offhook - Invocation with Flash hook, Dial-Code and Destination
Address 

All feature invocation are local implementation decisions made by
the terminal. It would be technically possible to design phone-shaped
terminals that use 12-button keypads and a hookflash to invoke
services; however, as it is rather difficult to imagine a *less*
intuitive interface, I doubt any such products will ever be sold.

Regardless, there are no callflows associated with such invokation,
aside from execution of the services themselves.

> Facilitated Calling - Automatic Dialing (local) 

This is a terminal implementation decision, and will not
appear in callflows.

> Facilitated Calling - Speed Dial 

This might be worth discussing; however, its implementation
is rather obvious and straighforward, so I don't necessarily
support adding it at this time.

> Facilitated Calling - Redial   

This is a terminal implementation decision, and will not
appear in callflows.

> Facilitated Calling - Call Return      

This is a terminal implementation decision, and will not
appear in callflows.

> Facilitated Calling - Hot Line 

This is a terminal implementation decision, and will not
appear in callflows.

> Facilitated Calling - Automatic Callback       

This is covered in section 2.17

> Distinctive ringing    

This is a terminal implementation decision, and will not
appear in callflows.

> Multiple DNs on Device 

This is a matter of registering two AORs with the same
contact. This might be worth discussing; however, its
implementation is rather obvious and straighforward,
so I don't necessarily support adding it at this time.

> Intercom Dialing  -- Abbreviated Dialing -- 4-digit dialing 

There is no real concept of abbreviated dialling in SIP; 4 digit
dialling is just a normal call. 

> Coverage and Voice Mail (on busy and no Answer) 

This is a terminal decision about whether and when to send
a 300-class response to a request. The mechanisms to
effect it are already covered in sections 2.7 and 2.8.

> Simultaneous Ring      

RFC 3261 covers request forking already. Reiterating it here
would serve no purpose.

>  Call Retrieve (Flash) 

This is a terminal implementation decision, and will not
appear in callflows (except in the form of taking parties
on and off hold, covered in sections 2.1 - 2.3).

>  Disconnect after Hold 

This is a terminal implementation decision, and will not
appear in callflows (except in the form of sending
BYE to tear down a call, which is already well documented).

>  Disconnect after Being Held   

This is a terminal implementation decision, and will not
appear in callflows (except in the form of sending
BYE to tear down a call, which is already well documented).

>  Call Waiting Indication      

This is a terminal implementation decision, and will not
appear in callflows.

>  Call Waiting - Distinctive Tone(s)    

This is a terminal implementation decision, and will not
appear in callflows.

>  Call Waiting - Hold and Answer        

This is a terminal implementation decision, and will not
appear in callflows (except in the form of taking parties
on and off hold, which is covered in sections 2.1 - 2.3).

>  Call Waiting - Drop and Answer        

This is a terminal implementation decision, and will not
appear in callflows (except in the form of sending
BYE to tear down a call, which is already well documented).

>  Transfer - Blind      

This is covered in section 2.4

>  Transfer - Consultation Transfer      

This is covered in section 2.5

>  Conference - N-Way - to external bridge       

This behavior is not yet defined. There is a vigorous ongoing
effort to form a unified view of how conferencing works in SIP.

Three-way conferencing is described in sections 2.9 and 2.10.

>Modem 

I'm not sure this has been discussed; nor has it (to my knowledge)
surfaced as a requirement before. Perhaps you can write up an
internet-draft requirements document and socialize the idea.

>FAX pass-trough  
>FAX relay (T.38)

Both of these services are described in
draft-ietf-sipping-realtimefax-00.txt. They are also
shown in draft-ietf-sipping-call-flows, section 3.1.7.

/a

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP


_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP