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 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
