[EMAIL PROTECTED] wrote:
> 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.
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
> BR,
> Jari
>
>
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
> Of ext Alexeitsev, D
> Sent: 10 September, 2008 11:44
> To: [EMAIL PROTECTED]
> Cc: [email protected]
> Subject: Re: [BLISS] Alert-Info URNs
>
> Hi Paul
>
> See inline,
>
> 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.
>
> [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.
>
> 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.
>
> [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
> _______________________________________________
> BLISS mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/bliss
>
_______________________________________________
BLISS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bliss
