Subject: Re: [BLISS] Alert-Info URNs

From: "Alexeitsev, D" <[email-masked]>
Date: Tue, 9 Sep 2008 11:59:52 +0200

Hi,

I have a bad experience with the SIP response codes in the telephony
environment from the SIP - ISUP interworking times. Basically the lesson
I've learned was that the SIP responses have SIP relevance (sounds
trivial) and can hardly be reused for the telephony services. That is
why we have Reason header with Q.850 values and only some basic
interworking between SIP responses and ISUP release codes. Specifically
182 has no telephony relevance, as it is applicable to any SIP request
such as SUBSCRIBE, PUBLISH, etc.

My preference is a clear separation between SIP as a session initiation
protocol independent from the overlying service and telephony
application with it's specific parameters that sits on top of the SIP.

In line with this model I think, that having explicit URNs for the
telephony service is a much cleaner design that overloading underlying
SIP responses. 

Greetings,
Denis Alexeitsev

_______________________________________________
BLISS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/bliss

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 09 Sep 2008 11:55:48 -0400

There is a fine line here. If the goal is only to support tunneling, 
then tunneling the codes from another protocol is fine. But if we are 
talking about features that make sense in all-sip networks, all-ISUP 
networks, and in interworking cases, then the representation needs to be 
provided that makes sense in the all-sip case. AFAIK we have been 
dealing with those things on a case-by-case basis. And there are a 
variety of ways to code those things. Response codes are one 
alternative. Alert-Info URNs would be another way. I think its a 
subjective matter of whether the concept being communicated rises to the 
level of a response type.

IMO it seems inappropriate to assign a distinct provisional response for 
each nuance of user feedback we would like to convey. But I can see how 
this can be argued the other way.

	Thanks,
	Paul

Alexeitsev, D wrote:
> ------------------------------------------------------------------------
>

---

From: Henry Sinnreich <[email-masked]>
Date: Tue, 09 Sep 2008 16:48:47 -0500

>My preference is a clear separation between SIP as a session initiation
protocol independent
>from the overlying service and telephony application with it's specific
parameters that sits on top of the SIP.

This is a great insight!
Besides telephony applications there are other, such as Rich Internet
Applications (RIA) with completely different models than telephony. It is
for this reason why we have proposed the use of SIP only as a rendezvous
service and for session initiation, leaving the applications in the
endpoints for the RIA scenario. See

http://www.ietf.org/internet-drafts/draft-sinnreich-sip-tools-03.txt

I believe we share the view that applications should be separated from SIP,
be it for telephony or RIA or any other, and also no matter if the services
are Œin the network¹ or are endpoint applications.
Or do we?

Henry

On 9/9/08 4:59 AM, "Alexeitsev, D" <[email-masked]> wrote:

> environment from the SIP - ISUP interworking times. Basically the lesson I've
> learned was that the SIP responses have SIP relevance (sounds trivial) and can
> hardly be reused for the telephony services. That is why we have Reason header
> with Q.850 values and only some basic interworking between SIP responses and
> ISUP release codes. Specifically 182 has no telephony relevance, as it is
> applicable to any SIP request such as SUBSCRIBE, PUBLISH, etc.
> 
> protocol independent from the overlying service and telephony application with
> it's specific parameters that sits on top of the SIP.
> 
> In line with this model I think, that having explicit URNs for the telephony
> service is a much cleaner design that overloading underlying SIP responses.
> 
> Greetings, 
> Denis Alexeitsev 
> 
> 
>

---

From: "Alexeitsev, D" <[email-masked]>
Date: Wed, 10 Sep 2008 10:44:26 +0200

Hi Paul

See inline,

provided that makes sense in the all-sip case. 

[DA] I see your point and entirely agree with it. What I was trying to
say is not that the tunnelling solution with Reason/Q.850 is the way to
go. My point was, that SIP alone is not enough for telephony and should
not be overloaded. SIP is not only telephony, although telephony may be
the biggest part of the SIP at the moment.

[DA] I don't think that assigning every telephony nuance to the SIP
responses, than any presence nuance, than any other application's
nuance, would make SIP more understandable and easy to implement. Aside
from the overhead attached to define a new response versus defining a
new URN.

Greetings,
Denis

---

From: <[email-masked]>
Date: Wed, 10 Sep 2008 13:00:28 +0300

Hello,

On the other hand, I don't see what is different in 182 with 181. 181
notifies the caller that the callee has forwarded the request, this is
also a "nuance" of a telephony appplication, and already successfully
implemended in existing SIP clients. The question seems to be, does the
second nuance (call waiting) indicate that there is a need for a generic
telephony framework to carry the telephony nuances, or could we still
follow the same principle as with the first nuance. 

BR,
Jari  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of ext Alexeitsev, D
Sent: 10 September, 2008 11:44
To: [email-masked]
Cc: [email-masked]
Subject: Re: [BLISS] Alert-Info URNs

Hi Paul

See inline,

Greetings,
Denis

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 10 Sep 2008 09:33:55 -0400

> follow the same principle as with the first nuance. 

This is a judgment call. The inclusion of 182 might have been a mistake 
and bad precedent, especially since its purpose isn't clear.

My take is that *if* we think there are a small number of such nuances, 
and that they are all of broad relevance, then it might make sense to 
define response codes for them. If that is not the case, then some other 
mechanism, such as the URN, would be more appropriate.

BTW, there is no reason there can only be one kind of URN used with 
Alert-Info. I'm not entirely convinced that a single URN scheme for 
services and tones is a good thing. It may be better for a tone URN to 
be defined by an organization that has a bunch of tones that need to be 
denoted.

	Thanks,
	Paul

---

From: "Alexeitsev, D" <[email-masked]>
Date: Fri, 12 Sep 2008 15:18:36 +0200

[DA] Agree, I think that Minneapolis would be the right place to get a
broader view on the tones issue. There could be some ATIS
representatives, that might be interested in the tones.

Greetings,
Denis Alexeitsev