Subject: [Sipping] New Service Examples I-D

From: Alan Johnston <[email-masked]>
Date: Wed, 10 Jul 2002 08:41:57 -0500

All,

There is a new version of the the Service Examples draft.  It has not yet 
appeared in the IETF archives.  Until it does, it is available at:

      http://ee.wustl.edu/~alan/draft-ietf-sipping-service-examples-02.txt

The main changes relate to two new call flows for transitioning a 2-party 
call to a 3-party call (2.9 3-way Conference – Third Party is Added and 
2.10 3-way Conference – Third Party Joins) which use a conference URI.

As always, comments and feedback are greatly appreciated.

Thanks,
Alan Johnston
sip:[email-masked]

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

---

From: Adam Roach <[email-masked]>
Date: Wed, 24 Jul 2002 21:07:17 -0500

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

---

From: "Avella, Alejandro" <[email-masked]>
Date: Fri, 26 Jul 2002 09:50:52 -0600

Adam,

About the modem.  Here are two things that require softswitch intervention
(I think)

1.- If codec compression is enabled (G.726 or G.729) for a channel, then it
is desirable to switch to G.711 for the modem call to achieve a good bit
rate.

2.- Disable Call Waiting (e.g *70), so that modem call is not dropped when
Call Waiting tones are sent to the FXS port.

Thanks for your responses on everyting else.  On MGCP, most of these
situations appear on the call flows as part of the parameters of the
messages.  In other words, I have call flows defined for each of these
services using MGCP.  I am trying to understand what is different with
SIP...

Alejandro

-----Original Message-----
From: Adam Roach [mailto:[email-masked]]
Sent: Wednesday, July 24, 2002 8:07 PM
To: 'Avella, Alejandro'; 'Alan Johnston'; [email-masked]
Subject: RE: [Sipping] New Service Examples I-D

Address 

/a

*************************************************************************
This e-mail transmission, and any documents, files, or previous
e-mail messages attached to it may contain information that is 
confidential or legally privileged.  If you are not the intended 
recipient, or a person responsible for delivering it to the 
intended recipient, you are hereby notified that you must not 
read this transmission and that any disclosure, copying, printing,
distribution, or use of any of the information contained in or 
attached to this transmission is strictly prohibited.  If you have 
received this transmission in error, please immediately notify the 
sender by telephone or return e-mail and delete the original 
transmission and its attachments without reading or saving them 
in any manner.  Thank you.
*************************************************************************