Subject: Re: [Sipping] Call Waiting - who does the tone (round 2)

From: [email-masked]
Date: Mon, 23 Jun 2003 12:02:38 EDT

In a message dated 6/23/2003 4:59:41 AM Eastern Standard Time, 
[email-masked] writes:

> A call stateful proxy can decide to forward or not to forward an INVITE to 
> a UA that is already in another call. The decision can be based on anything 
> including charging ( a user has payed for call forwarding). If the proxy 
> decides to forward the INVITE, it is the UA that plays the tone when it receives 
> the INVITE.
> 
> Network controls the service, UA DOES the tone.
> 
> Did I miss anything?
> 

I believe you have it correct. But the question always comes down to, if the 
UA itself generates the tone (under control of the network), what if the 
network wants to introduce a new service or feature which requires a new tone. Can 
it be assured that every existing UA can generate that new tone? Conversely, 
if the UA controls the services, it would certainly be the case that old UAs 
could not handle a new service.

Mike Pierce

---

From: Michael Hammer <[email-masked]>
Date: Mon, 23 Jun 2003 15:24:04 -0400

Assuming that .wav files or such can be forwarded to the phone, no reason 
why a UA could not play the new tone.

Similarly, if you want to upgrade the phone with new services.

The unstated element of MLPP that might get lost is the ability to force 
the UA to do something if its user programs it to refuse new tones, 
services, or requests.  But, I would expect that if the General's call 
didn't preempt the lower ranking person's call due to some "local" 
programming, organizational remedies would take place.

Mike H.

At 12:02 PM 6/23/2003 -0400, [email-masked] wrote:
>>A call stateful proxy can decide to forward or not to forward an INVITE 
>>to a UA that is already in another call. The decision can be based on 
>>anything including charging ( a user has payed for call forwarding). If 
>>the proxy decides to forward the INVITE, it is the UA that plays the tone 
>>when it receives the INVITE.
>>
>I believe you have it correct. But the question always comes down to, if 
>the UA itself generates the tone (under control of the network), what if 
>the network wants to introduce a new service or feature which requires a 
>new tone. Can it be assured that every existing UA can generate that new 
>tone? Conversely, if the UA controls the services, it would certainly be 
>the case that old UAs could not handle a new service.
>
>Mike Pierce

---

From: "weng zhiqiang" <[email-masked]>
Date: Tue, 24 Jun 2003 09:40:51 +0800

hi :
 I think  mayhy's new draft http://www.softarmor.com/sipping/drafts/draft-mahy-sipping-tones-00.txt , give a good solution to this problem. it use an extended MIME type to carry tone description in XML to notify sip terminal of tone's type. 
  but it need sip terminal make a change to support it.

Johny Weng
  ----- Original Message ----- 
  From: [email-masked] 
  To: [email-masked] 
  Cc: [email-masked] 
  Sent: Tuesday, June 24, 2003 12:02 AM
  Subject: Re: [Sipping] Call Waiting - who does the tone (round 2)

  In a message dated 6/23/2003 4:59:41 AM Eastern Standard Time, [email-masked] writes: 

    A call stateful proxy can decide to forward or not to forward an INVITE to a UA that is already in another call. The decision can be based on anything including charging ( a user has payed for call forwarding). If the proxy decides to forward the INVITE, it is the UA that plays the tone when it receives the INVITE. 

    Did I miss anything? 

  I believe you have it correct. But the question always comes down to, if the UA itself generates the tone (under control of the network), what if the network wants to introduce a new service or feature which requires a new tone. Can it be assured that every existing UA can generate that new tone? Conversely, if the UA controls the services, it would certainly be the case that old UAs could not handle a new service. 

  Mike Pierce

---

From: "Shu-Lin CHen" <[email-masked]>
Date: Fri, 27 Jun 2003 14:46:39 -0400

Hi:
 
Is there any history reason that TLS is selected for SIP security
instead of IPSec?
Just curious as a new comer in SIP area.
 
Thanks.
 
shu-lin

---

From: "James Undery" <[email-masked]>
Date: Sat, 28 Jun 2003 00:10:08 +0100

MessageHi,

The main problem with IPSec is that it's a touch difficult to know when it's being used (and how) at the application level, TLS is more obvious to applications.

That said it's a bit of a religious argument on most other points, and some SIP architectures use IPSec (3GPP IIRC) at certain points of the network.

James
  ----- Original Message ----- 
  From: Shu-Lin CHen 
  To: [email-masked] 
  Sent: Friday, June 27, 2003 7:46 PM
  Subject: [Sipping] TLS vs IPSec

  Hi:

  Is there any history reason that TLS is selected for SIP security instead of IPSec?
  Just curious as a new comer in SIP area.

  Thanks.

  shu-lin