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