Subject: [Sipping] RE: [Sip] About the ECMA TR/87 (aka SIP CTI Interface)

From: "Roy, Radhika \(AEAD\)" <[email-masked]>
Date: Tue, 1 Nov 2005 09:53:48 -0500

Hi, Frank:

SIP also carries MIME format in its message body.

Carrying of SDP results so many things: audio, video, and others
streams.

Carrying of XML triggers many other activities.

There is nothing NEW about it in SIP.

But what does SIP standard stand for?

The fundamental thing is this: They all MUST complement the fundamental
objective of session initiation (especially human user in mind).

If anyone wants to extend SIP, let them come in the IETF SIP/SIPPING WG.
They are welcome, and standards are developed for the whole world, not
some abusiveness of standards as done in private arena.

Let them bring contributions in IETF and we can into those, and we will
go from there.

Hope this helps.

BR/Radhika

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, November 01, 2005 2:49 AM
To: Roy, Radhika (AEAD)
Cc: Mariano Stokle; SIP; [email-masked]; SIPPING
Subject: RE: [Sip] About the ECMA TR/87 (aka SIP CTI Interface)

Hi Roy,

I agree that this should be strived for, but I fear that reality
somewhat 
restricts
this idealism. Take the example of SDP being used to put a media stream
on 
hold. 
Although this could be defended as being an example of manipulating 
session parameters,
this is rather arguable. The presence framework is yet another example, 
sending a
piece of XML data results in a response of another piece of XML data. As

far as I am
concernced this is also "protocol tunnelling".

Any thoughts?

Cheers,

Frank

"Roy, Radhika (AEAD)" <[email-masked]> 
Sent by:
[email-masked]
2005-10-31 05:22 PM

To
Frank Derks/HVS/BE/PHILIPS@PHILIPS
"Mariano Stokle" <[email-masked]>
cc
SIP <[email-masked]>
[email-masked]
SIPPING <[email-masked]>
Subject
RE: [Sip] About the ECMA TR/87 (aka SIP CTI Interface)
Classification

The use of other protocols like SDP and others in SIP must NOT need to
be generalized by making a technically "wrong" interpretation such as
"carrying of other protocols."

Technically write interpretation of using SDP and others in SIP is this:

1. SDP and other protocols "complement" the session initiation in SIP.
2. SIP must NOT be used just another "transport" protocol for carrying
other protocols.
3. SIP must NOT be used to carry another protocol suits of "session
establishment" protocols that contradict the very fundamentals for which
SIP has been created as a standard.

If anyone violates the above items, definitely, they are abusing SIP
standards, and it must be stopped immediately.

Any comments?

Best regards,

Radhika R. Roy
SAIC

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Frank Derks
Sent: Monday, October 31, 2005 3:02 AM
To: Mariano Stokle
Cc: SIP; SIPPING; [email-masked]
Subject: Re: [Sip] About the ECMA TR/87 (aka SIP CTI Interface)

Hi Mariano,

I realise that I am treading on dangerous ground here, but I couldn't 
resist answering. 

If you are asking yourself whether SIP is appropriate for carrying
another 
"signalling 
protocol" is like asking "can I use SIP to do something for me". Most,
if 
not all, 
SIP implementations rely on the fact that some other protocol is being 
carried in a SIP
body. SDP and the XML used for IM and presence are good examples of
this. 
The SIP methods
that could be used to convey these protocols, is obviously open for 
discussion, but I
fear that it will be extremely difficult to come to real consensus on 
this. In the CSTA
case, I would say that, depending on what you are doing, both methods 
could be appropriate. 

BTW, Microsoft uses SIP messages with the CSTA XML variant for LCS.

3PCC is not quite as powerful as CSTA. Realise that "CSTA" covers a 
complete suite of 3rd
party call control functionality, whereas 3PCC "just" describes a method

by which a few
3rd party call control services could be realised. Precisely because of 
3PCC's limitations
TR/87 was created.

Cheers,

Frank

Mariano Stokle <[email-masked]> 
Sent by:
[email-masked]
2005-10-28 12:25 PM

To
SIP <[email-masked]>
SIPPING <[email-masked]>
cc

Subject
[Sip] About the ECMA TR/87 (aka SIP CTI Interface)
Classification

Recently I noticed the implementation of TR/87 spec in several SIP
Application Servers. My question (sorry it is out off topic for these
lists) is about if it is a right use of SIP according to the
architectural design principles of SIP and particulary, the use of
INVITE for establish a signalling session. I mean: is SIP the right
choice to transport another signalling protocol as CSTA? If yes, it is
INVITE the right method to transport CSTA information or
SUBSCRIBE-NOTIFY would be a better choice? Finally, do we need CSTA
over SIP when we have RFC 4117 for 3PCC?

Regards,

--
Mariano Stokle

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

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

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

_______________________________________________
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: "Dale R. Worley" <[email-masked]>
Date: Tue, 01 Nov 2005 11:40:49 -0500

On Tue, 2005-11-01 at 16:41 +0100, Frank Derks wrote:
> You are probably right about the process, but the SIP/SIPPING/SIMPLE workgroups
> have not always been co-operative in these efforts. Some of the 3GPP efforts
> demonstrate this. Obviously, that doesn't mean that anybody should then just do 
> their own thing;-)

Or maybe we should make explicit what is implicit is Roy's description:
One brings a *request* to the IETF -- and the IETF might answer "No",
because what one wants to do might be a Bad Idea.  The difficulty with
the 3GPP efforts is that generally, they have come to the IETF with the
tone "This is what we are going to do, and we want you to certify it."

Dale

---

From: Frank Derks <[email-masked]>
Date: Tue, 1 Nov 2005 16:41:55 +0100

Hi Roy,

You are probably right about the process, but the SIP/SIPPING/SIMPLE 
workgroups
have not always been co-operative in these efforts. Some of the 3GPP 
efforts
demonstrate this. Obviously, that doesn't mean that anybody should then 
just do 
their own thing;-)

Cheers,

Frank

[email-masked]
2005-11-01 03:53 PM

To
Frank Derks/HVS/BE/PHILIPS@PHILIPS
cc
"Mariano Stokle" <[email-masked]>
"SIP" <[email-masked]>
<[email-masked]>
"SIPPING" <[email-masked]>
Subject
RE: [Sip] About the ECMA TR/87 (aka SIP CTI Interface)
Classification

Hi, Frank:

Hope this helps.

BR/Radhika

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, November 01, 2005 2:49 AM
To: Roy, Radhika (AEAD)
Cc: Mariano Stokle; SIP; [email-masked]; SIPPING
Subject: RE: [Sip] About the ECMA TR/87 (aka SIP CTI Interface)

Hi Roy,

far as I am

Any thoughts?

Cheers,

Frank

To

Any comments?

Best regards,

Radhika R. Roy
SAIC

-----Original Message-----

Hi Mariano,

by which a few

Cheers,

Frank

To
SIP <[email-masked]>

Subject

Regards,

--
Mariano Stokle