Subject: [Sipping] how to transfer hookflash event, e.g. in a 3-way conference call?

From: CheungJenny <[email-masked]>
Date: Tue, 21 Nov 2006 10:39:46 +0000

Hi,
 
I have a question about "hookflash event transfer".
Because DTMF signal can be transfered in 3 ways: INFO, inband and AVT, can hookflash be transfered using the same 3 methods?
What I want to know is, if I hookflash, how does the peer gets to know this?
 
Thanks.
 
_________________________________________________________________
率先尝试 Windows Live Mail。
http://ideas.live.com/programpage.aspx?versionId=5d21c51a-b161-4314-9b0e-4911fb2b2e6d

_______________________________________________
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: Paul Kyzivat <[email-masked]>
Date: Tue, 21 Nov 2006 09:07:59 -0500

Generally in sip you would expect the device to handle the hookflash
locally (because it is a user interface issue), decide it is a request
to transfer, and then initiate the transfer itself. So the hookflash
need not be signaled remotely.

	Paul

CheungJenny wrote:
> Because DTMF signal can be transfered in 3 ways: INFO, inband and AVT, 
> can hookflash be transfered using the same 3 methods?
> ------------------------------------------------------------------------
> Windows Live Safety Center 为您的计算机提供免费的安全扫描服务。 它是免费 
> 的！ <http://safety.live.com/site/ZH-CN/default.htm>
> 
> 
> ------------------------------------------------------------------------
>

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Tue, 21 Nov 2006 10:07:17 -0500

I shuddered to see the concept of stimulus signalling in SIP in some of
the test cases for our recent MultiService Forum interoperability event.
The counter-argument I received is that there is a requirement for such
signalling when black telephones sit behind a SIP-speaking IAD and the
meaning of "flash" in a given context is held in service logic in an
application server. I'll also mention that we are talking about logic
that varies from country to country. At my instigation the MSF is
investigating the requirements as they relate both to architecture and
protocol selection.

---

From: David Robbins <[email-masked]>
Date: Tue, 21 Nov 2006 12:28:02 -0500

What bothers me about including "flash" signaling in SIP is that it  
creates a device dependency that doesn't belong in SIP. It renders the  
flash-dependent services inaccessible to devices other than black  
phones (or devices with equivalent user interface capabilities), or  
else requires devices to emulate the flash (or more generally,  
translate the user's selection of a service into a sequence of  
low-level signaling actions) in order to access such services. Services  
that involve management of multiple calls (which are typically what  
flash is used for, e.g., call waiting, three-way call, call transfer)  
are much better managed in a SIP world by the device itself. SIP  
application servers built by carrying over the PSTN legacy don't like  
to let the SIP device do such things, but really, that's an artifact of  
PSTN legacy thinking. If you want to emulate the PSTN in all of its  
details with a VoIP protocol, choose MGCP or MEGACO, not SIP, for  
communication with the end-user device.

I prefer to revisit the flash-dependent services themselves, identify  
the SIP equivalent, and define the required behavior for a  
black-phone-like device to translate the familiar UI actions into the  
appropriate device-independent SIP signaling. Several SIPPING documents  
have shown the SIP equivalent for most such services (e.g.,  
draft-ietf-sipping-cc-framework).

Given flash-dependent service logic that varies from one place to  
another, my approach requires tailoring the SIP device behavior to the  
environment within which it is used. This can be a complication, which  
I will admit is avoided if we simply transmit a flash in SIP signaling.  
How much variation is there, really? There's a practical limit to what  
you can do with a flash, because it's an unavoidably ambiguous service  
request, and the user must remember, for a given service, a sequence of  
actions that may include multiple flashes and dialed codes. In North  
America, there are really very few services that are directly  
flash-dependent, and they're all easily translated by the device into  
standard SIP signaling.

Rather than just assume that we'll always need to be able to send a  
flash to the server, it would be preferable to understand just how many  
and what flash-dependent services exist throughout the world, and how  
they should be done in SIP. I look forward to the results of the MSF  
investigation Tom has initiated. I already know the answer for North  
American services, but not for the rest of the world.

>>> What I want to know is, if I hookflash, how does the peer gets to  
Dave Robbins
Verizon Laboratories
40 Sylvan Rd.
Waltham, MA 02451-1128

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 21 Nov 2006 14:36:37 -0500

I agree with David here.

For the server to perform the multiple call rearrangement that is
implied when processing the flash, the server must be aware of the
multiple calls. If the calls are anchored in the device, then the server
probably needs to be monitoring the digest event package, and then needs
to loop instructions back to the device about what to do, which is very
convoluted. More likely the server will then want to anchor the calls
itself, acting as a B2BUA for all calls to the device. In effect you are
then doing MGCP over SIP.

	Paul

David Robbins wrote:
> flash-dependent services inaccessible to devices other than black phones 
> (or devices with equivalent user interface capabilities), or else 
> requires devices to emulate the flash (or more generally, translate the 
> user's selection of a service into a sequence of low-level signaling 
> actions) in order to access such services. Services that involve 
> management of multiple calls (which are typically what flash is used 
> for, e.g., call waiting, three-way call, call transfer) are much better 
> managed in a SIP world by the device itself. SIP application servers 
> built by carrying over the PSTN legacy don't like to let the SIP device 
> do such things, but really, that's an artifact of PSTN legacy thinking. 
> If you want to emulate the PSTN in all of its details with a VoIP 
> protocol, choose MGCP or MEGACO, not SIP, for communication with the 
> end-user device.
> 
> environment within which it is used. This can be a complication, which I 
> will admit is avoided if we simply transmit a flash in SIP signaling. 
>             Sipping mailing list
>             https://www1.ietf.org/mailman/listinfo/sipping

---

From: [email-masked]
Date: Tue, 21 Nov 2006 23:08:41 -0500

From: "Tom-PT Taylor" <[email-masked]>

   application server.

It may not be pretty, but it's already standardized:

    RFC 2833

    3.10 DTMF Events

       Table 1 summarizes the DTMF-related named events within the
       telephone-event payload format.

			 Event  encoding (decimal)
			 _________________________
			 0--9                0--9
			 *                     10
			 #                     11
			 A--D              12--15
			 Flash                 16

			 Table 1: DTMF named events

Dale

---

From: David Robbins <[email-masked]>
Date: Tue, 21 Nov 2006 23:40:53 -0500

(I agree, it's not pretty.) This, of course, transmits the flash in the 
media stream, not in the SIP signaling. Works if and only if the app 
server gets the media stream, which is not generally what SIP app 
servers want to do.

This does remind me that in this way SIP can be a device-level 
protocol: just use an INVITE to set up a media stream between device 
and app server, and do everything else as RFC 2833 events and ordinary 
audio in the media stream. Gets SIP pretty much completely out of the 
way, but you can still claim you're using SIP. :-) (I have seen a 
situation where this actually makes sense, but it's not an ordinary use 
of SIP.)

Dave Robbins
Verizon Laboratories
40 Sylvan Rd.
Waltham, MA 02451-1128

---

From: [email-masked]
Date: Wed, 22 Nov 2006 00:23:26 -0500

From: David Robbins <[email-masked]>

OTOH, if the application server is not functioning as a B2BUA (and
thus getting the media), can it really do the call-control actions
that people have been talking about as the goal?

I suppose you could put some sort of indication in an INFO request.

But these things get ugly fast.  How do you implement 3-way calling
without the UA being fully aware that that is what is going on?  Other
than with an application server that is a full B2BUA?

Dale

---

From: "Brian Stucker" <[email-masked]>
Date: Wed, 22 Nov 2006 10:29:43 -0600

Ugh. 2833...

IMHO-- Sending media/2833 to an application server makes it no longer an
application server, but an application gateway. For instance, a PSTN
gateway is an application gateway (access to the PSTN being the
application in question).

We really shouldn't be fixated on the fact that it's a flash event. It's
an event at the UA that occurs during mid-call. It may not even need to
be signaled to another node in the network. For instance, the client may
be able to locally manage the two calls and hitting the hookflash button
on the device tells the client to swap the set of media streams being
rendered.

So looking at this that way...

There's two events in a 3-way conference. The first event is to tell the
UA that you want to make a second call without ending the first one
(first hook-flash). That should be a local UA event (meaning nothing
goes to a SIP server in the network). This event occurs mid-call in the
first call. And typically causes the first call to be placed on hold
while the second call is being established.

The second event is to join the two calls together. This event occurs
mid-call in the second call (the second hook-flash). If the UA is able
to do local conferencing, then this should also be a local event to the
UA: hey UA, start conferencing the two media streams. In this case the
UA simply takes the first call off hold and starts conferencing packets.

If the UA is relying on a network conference server to handle the
conferencing, then the second hook-flash can be used to contact the
conference server, get a conference token, and then REFER the two call
legs to the conference server with the token in the Refer-To URI. The
two calls to be conferenced are now both on hold until the conference is
established.

Now everyone is talking to the conference server to get the media mixed.
The original two calls are dropped, and each UA involved in the
conference only have SIP sessions setup with the conference server. If
you need to know at the conferencing server that this was a '3-way' call
feature invocation, that can be included in the original conference URI.

Here's the server flow:

Party A				Party B		Party C
Conference
|					|			|
|
|					|			|
|
|---INVITE (b)--------------->|			|
|
|<--200 OK--------------------|			|
|
|---ACK---------------------->|			|
|
|					|			|
|
(flash)				|			|
|
|					|			|
|
|---INVITE (b), [HOLD SDP]--->|			|
|
|<--200 OK--------------------|			|
|
|---ACK---------------------->|			|
|
|					|			|
|
|---------INVITE (c)--------------------------->|
|
|<--------200 OK -------------------------------|
|
|---------ACK---------------------------------->|
|
|					|			|
|
(flash)				|			|
|
|---------INVITE (c), [HOLD SDP]--------------->|
|
|<--------200 OK -------------------------------|
|
|---------ACK---------------------------------->|
|
|					|			|
|
|------------INVITE
(conf@...)----------------------------------------------->|
|<-----200 OK,
Contact:sip:conf@...;token...----------------------------------|
|------------ACK--------------------------------------------------------
----->|
|					|			|
|
|---REFER (conf@...;token)--->|			|
|
|<--202-----------------------|			|
|
|---REFER (conf@...;token)--------------------->|
|
|<--202-----------------------------------------|
|
|					|			|
|
|					|----------INVITE
(conf@...;token...)---------->|
|					|<-------200
OK---------------------------------|
|
|--------ACK----------------------------------->|
|					|			|-INVITE
(conf@...;token...)->|
|					|
|<--------200 OK--------------|
|					|
|---------ACK---------------->|
|					|			|
|
|<----NOTIFY (a), [200 OK]----|			|
|
|-----200 OK----------------->|			|
|
|-----BYE (b)---------------->|			|
|
|<----200 OK------------------|			|
|
|					|			|
|
|<----------------------NOTIFY (a), [200 OK]----|
|
|-----------------------200 OK----------------->|
|
|-----------------------BYE (c)---------------->|
|
|<----------------------200 OK------------------|
|
|					|			|
|
|					|			|
|

Regards,
Brian

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Tuesday, November 21, 2006 11:23 PM
> To: [email-masked]
> Subject: Re: [Sipping] how to transfer hookflash event, e.g. 
> in a 3-way conference call?
> 
> OTOH, if the application server is not functioning as a B2BUA 
> (and thus getting the media), can it really do the 
> call-control actions that people have been talking about as the goal?
> 
> But these things get ugly fast.  How do you implement 3-way 
> calling without the UA being fully aware that that is what is 
> going on?  Other than with an application server that is a full B2BUA?
> 
> Dale
> 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 22 Nov 2006 14:03:21 -0500

After having worked on this a bit, I began to see what the issue is:

SIP assumes that the devices are a lot smarter than "traditional" 
devices were, and expects them to carry out features that previously had 
been carried out in the network. And that is fine if the feature 
implementation can be self contained in the device. That depends on the 
device being smart enough, which is easy, and that it have enough UI to 
manage and control the features.

But consider a black phone adapter. Regardless of how smart it is, its 
UI is limited to that black phone. So it has DTMF and audio to work with 
as its UI. And its unlikely to be able to do a whole lot of good audio 
synthesis. Also, there is some expectation about how features should 
work on such a device. Generally they are expected to be invoked with 
star codes, and some of them may have audio feedback of various sorts.

Still, some features, such as transfer, can be done in the device. 
Others still require an in-network implementation, and some might need 
cooperation with some support in the device and some in the network.

This is all possible, but it complicates the implementation, and it 
especially complicates the configuration of the device:
- which interactions are handled locally
- which are handled remotely? and how are they invoked?
- which have local and remote components? How are the
   remote components identified and accessed?

In the end this becomes a complicated distributed application 
implementation. It is certainly doable, but the bar for doing it is 
high, and those of us working on sip specs aren't helping much with it.

So its not too surprising that some may just want to throw in the towel 
and go for an implementation that puts all the smarts in the network and 
makes the devices dumb. In that way the implementation can be similar to 
what has been done before, and it depends only on the lowest common 
denominator capability from the devices.

The configuration framework is a step towards solving this problem, but 
only a step.

	Paul

---

From: "Stephen Sprunk" <[email-masked]>
Date: Wed, 22 Nov 2006 20:02:17 -0600

Thus spake "Paul Kyzivat" <[email-masked]>
> devices were, and expects them to carry out features that previously 
> had been carried out in the network. And that is fine if the feature 
> implementation can be self contained in the device. That depends on 
> the device being smart enough, which is easy, and that it have enough 
> UI to manage and control the features.

SIP takes a lot of horsepower to do correctly.  The extra cycles needed 
to translate a hookflash into some sort of REFER, NOTIFY, or INVITE 
message disappear in the noise.

> But consider a black phone adapter.

Unfortunately, I've run into this request from customers even on 
high-end GUI phones.  I've had a few nearly fail us on acceptance 
testing because we don't use flash for hold/transfer/conference -- and 
we have both softkeys _and_ hardkeys for those functions!

> Regardless of how smart it is, its UI is limited to that black phone. 
> So it has DTMF and audio to work with as its UI. And its unlikely to 
> be able to do a whole lot of good audio synthesis. Also, there is some 
> expectation about how features should work on such a device. Generally 
> they are expected to be invoked with star codes, and some of them may 
> have audio feedback of various sorts.

Star codes do not require device support in any but a few cases* I've 
encountered.  At most, an ATA needs to support complex digit maps to 
determine when to play dial tone(s) or complete the call.  Other than 
that, you usually just need the ability to send an INVITE to the 
star-coded number and let the proxy/b2bua figure out what to do with it.

[*] e.g. I've dealt with one system where if you use a star code to park 
a call, the system needs to return back the orbit number it got parked 
on, since it may be different than the one the user requested (if any).

> cooperation with some support in the device and some in the network.

What examples of hookflash uses require network support to emulate?  The 
only one I can think of is a really dumb device that can't do local 
conferencing, but the device should still be able to figure out a 
conference is desired and request it via a real SIP message (e.g. NOTIFY 
or reINVITE).

If you're stuck with really, really dumb devices, particularly ones that 
are trying to emulate POTS service, it's probably better to go with MGCP 
or Megaco than SIP.  Let's not mess up SIP by overlaying antiquated 
hookflash signalling, no matter how tempting it may be.

S

Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

---

From: David Robbins <[email-masked]>
Date: Thu, 23 Nov 2006 00:00:04 -0500

This has been an interesting discussion, and though we may be beating 
it to death now, it will surely come up again.

Remarks inline ...

On Nov 22, 2006, at 9:02 PM, Stephen Sprunk wrote:

> SIP takes a lot of horsepower to do correctly.  The extra cycles 
> needed to translate a hookflash into some sort of REFER, NOTIFY, or 
> INVITE message disappear in the noise.

Amen! If a SIP device has sufficient resources (processor, memory, 
signal processing) to do SIP correctly, it has enough to do many 
interesting features locally. But nobody will be surprised that I still 
hear people claim that it's too big a burden for a SIP device to do 
these features (as recently as last week).

>> be able to do a whole lot of good audio synthesis. Also, there is 
>> some expectation about how features should work on such a device. 
>> Generally they are expected to be invoked with star codes, and some 
>> of them may have audio feedback of various sorts.
>
> [*] e.g. I've dealt with one system where if you use a star code to 
> park a call, the system needs to return back the orbit number it got 
> parked on, since it may be different than the one the user requested 
> (if any).

Whether a black phone or a SIP phone with the same UI, it is the highly 
constrained UI that dictates the implementation of features in terms of 
flashes, star codes, audio prompts, and additional dialing. Such 
implementations are effective only to the extent that users can 
remember the magic incantation -- I daresay that few, if any, black 
phone users could perform more than a very few of all the available 
features without looking at the cheat sheet.

My experience supports your claim that device support is required in 
only a few cases. Most features can look like simple calls to the 
device, with a server handling the subsequent user interaction. The few 
features that are directly based on the flash can and should be handled 
entirely by the device. Of all the PSTN features (of which, depending 
upon how you count them, there are nearly 100, several hundred, or 
several thousand), there are about a dozen that really, really should 
be done on the device. Many more could be done on the device, but can 
also reasonably be done in a server. This is particularly so when the 
device in question is a single-line black phone or equivalent. More 
sophisticated devices, supporting multiple lines and having a richer UI 
(e.g., buttons, lamps, and a display) can impose more requirements for 
communication and coordination between device and server.

>> Others still require an in-network implementation, and some might 
>> need cooperation with some support in the device and some in the 
>> network.
>
> What examples of hookflash uses require network support to emulate?  
> The only one I can think of is a really dumb device that can't do 
> local conferencing, but the device should still be able to figure out 
> a conference is desired and request it via a real SIP message (e.g. 
> NOTIFY or reINVITE).

I know of no flash-based feature that requires network support to 
emulate. But I make a distinction between a feature that is directly 
based on flash (e.g., call waiting, three-way call, transfer, hold) and 
a feature that is indirectly based on flash (e.g., most features 
invoked mid-call are invoked by what looks to the device like the 
beginning of a three-way call sequence, but do not otherwise require 
coordination between device and server). As you (and Brian earlier in 
this thread) point out, if you have a device with insufficient signal 
processing resources or network bandwidth to do local conferencing, 
there are well-defined SIP procedures for the device to manage a 
conference using network conferencing resources.

> If you're stuck with really, really dumb devices, particularly ones 
> that are trying to emulate POTS service, it's probably better to go 
> with MGCP or Megaco than SIP.  Let's not mess up SIP by overlaying 
> antiquated hookflash signalling, no matter how tempting it may be.

Agreed. With a little imagination, we can map the interesting features 
into SIP by utilizing the resources available at the device and the 
server and distributing functions between the two in a manner that 
maintains SIP's device independence. I believe that I've done exactly 
that for a project I'm currently working on. (And I have encountered 
some resistance to the idea that SIP devices aren't dumb.)

Dave Robbins
Verizon Laboratories
40 Sylvan Rd.
Waltham, MA 02451-1128

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Thu, 23 Nov 2006 09:01:31 +0100

So in summary, the answer to the original question would be: don't 
"transfer" the event, but interpret/convert it to the SIP mechanism that is 
defined for the feature you are implementing (assuming there is an analog 
POTS device with naught but hook flashes and DTMF to do signalling / feature 
activation, and some kind of edge device that converts this into SIP). Does 
this "put the intelligence in the network"?

Regards,
Jeroen

Paul Kyzivat wrote:
> UI is limited to that black phone. So it has DTMF and audio to work
> with as its UI. And its unlikely to be able to do a whole lot of good
> audio synthesis. Also, there is some expectation about how features
> should work on such a device. Generally they are expected to be
> invoked with star codes, and some of them may have audio feedback of
> various sorts.
> So its not too surprising that some may just want to throw in the
> towel and go for an implementation that puts all the smarts in the
> network and makes the devices dumb. In that way the implementation
> can be similar to what has been done before, and it depends only on
> the lowest common denominator capability from the devices.
>
> The configuration framework is a step towards solving this problem,
> but only a step.
>
> Paul
>
> Brian Stucker wrote:
>> Ugh. 2833...
>>
>> IMHO-- Sending media/2833 to an application server makes it no
>> longer an application server, but an application gateway. For
>> instance, a PSTN gateway is an application gateway (access to the
>> PSTN being the application in question).
>>
>> We really shouldn't be fixated on the fact that it's a flash event.
>> It's an event at the UA that occurs during mid-call. It may not even
>> need to be signaled to another node in the network. For instance,
>> the client may be able to locally manage the two calls and hitting
>> the hookflash button on the device tells the client to swap the set
>> of media streams being rendered.
>>
>> There's two events in a 3-way conference. The first event is to tell
>> the UA that you want to make a second call without ending the first
>> one (first hook-flash). That should be a local UA event (meaning
>> nothing goes to a SIP server in the network). This event occurs
>> mid-call in the first call. And typically causes the first call to
>> be placed on hold while the second call is being established.
>>
>> mid-call in the second call (the second hook-flash). If the UA is
>> able to do local conferencing, then this should also be a local
>> event to the UA: hey UA, start conferencing the two media streams.
>> In this case the UA simply takes the first call off hold and starts
>> conferencing packets. If the UA is relying on a network conference server 
>> to handle the
>> conference server, get a conference token, and then REFER the two
>> call legs to the conference server with the token in the Refer-To
>> URI. The two calls to be conferenced are now both on hold until the
>> conference is established.
>>
>> Now everyone is talking to the conference server to get the media
>> mixed. The original two calls are dropped, and each UA involved in
>> the conference only have SIP sessions setup with the conference
>> server. If you need to know at the conferencing server that this was
>> a '3-way' call feature invocation, that can be included in the
>> original conference URI. Here's the server flow:
>>
>> Party A Party B Party C
>> Conference
>>>>>
>>>
>>>>>
>>>
>>> ---INVITE (b)--------------->| |
>>>
>>> <--200 OK--------------------| |
>>>
>>> ---ACK---------------------->| |
>>>
>>>>>
>>>
>> (flash) | |
>>>
>>>>>
>>>
>>> ---INVITE (b), [HOLD SDP]--->| |
>>>
>>> <--200 OK--------------------| |
>>>
>>> ---ACK---------------------->| |
>>>
>>>>>
>>>
>>> ---------INVITE (c)--------------------------->|
>>>
>>> <--------200 OK -------------------------------|
>>>
>>> ---------ACK---------------------------------->|
>>>
>>>>>
>>>
>> (flash) | |
>>>
>>> ---------INVITE (c), [HOLD SDP]--------------->|
>>>
>>> <--------200 OK -------------------------------|
>>>
>>> ---------ACK---------------------------------->|
>>>
>>>>>
>>>
>>> ------------INVITE
>>> <-----200 OK,
>>> ------------ACK--------------------------------------------------------
>>> ----->|
>>>>>
>>>
>>> ---REFER (conf@...;token)--->| |
>>>
>>> <--202-----------------------| |
>>>
>>> ---REFER (conf@...;token)--------------------->|
>>>
>>> <--202-----------------------------------------|
>>>
>>>>>
>>>
>>>> ----------INVITE
>>>> <-------200
>>> --------ACK----------------------------------->|
>>>>> -INVITE
>> (conf@...;token...)->|
>>>>
>>> <--------200 OK--------------|
>>>>
>>> ---------ACK---------------->|
>>>>>
>>>
>>> <----NOTIFY (a), [200 OK]----| |
>>>
>>> -----200 OK----------------->| |
>>>
>>> -----BYE (b)---------------->| |
>>>
>>> <----200 OK------------------| |
>>>
>>>>>
>>>
>>> <----------------------NOTIFY (a), [200 OK]----|
>>>
>>> -----------------------200 OK----------------->|
>>>
>>> -----------------------BYE (c)---------------->|
>>>
>>> <----------------------200 OK------------------|
>>>
>>>>>
>>>
>>>>>
>>>
>>
>>
>> Regards,
>> Brian
>>
>>> call-control actions that people have been talking about as the
>>> goal? I suppose you could put some sort of indication in an INFO 
>>> request.
>>>
>>> going on?  Other than with an application server that is a full
>>> B2BUA? Dale
>>>

---

From: Dean Willis <[email-masked]>
Date: Fri, 24 Nov 2006 17:10:54 -0600

On Nov 21, 2006, at 10:40 PM, David Robbins wrote:

> (I agree, it's not pretty.) This, of course, transmits the flash in  
> the media stream, not in the SIP signaling. Works if and only if  
> the app server gets the media stream, which is not generally what  
> SIP app servers want to do.
>

This is the line of reasoning that led us to develop "A Session  
Initiation Protocol (SIP) Event Package for Key Press Stimulus  
(KPML)" as documented in RFC 4730.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Fri, 24 Nov 2006 17:14:58 -0600

> testing because we don't use flash for hold/transfer/conference --  
> and we have both softkeys _and_ hardkeys for those functions!

I understand that customers initially demanded auxiliary handcranks  
for cars that were designed with electric starters. Eventually, they  
got over it.

--
Dean

---

From: [email-masked]
Date: Mon, 27 Nov 2006 14:20:47 -0500

In my experience, audio processing consumes much more resources than
even SIP processing.

But...

If your real limitation is time-to-market, and hence, development
effort, and you've already got an application server that does the
things you want, it saves a lot of code writing if you can anything
beyond the baseline SIP implementation.

Dale