>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 PROTECTED]> wrote: > 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 protected] > https://www.ietf.org/mailman/listinfo/bliss
_______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss
