You can view this as a limitation or a feature.
Its a limitation in that you can't in general communicate that you are
carrying out some particular feature.
Its a feature because it allows interoperation when there is no
standardization of features. (E.g. you don't need to know about HOLD.
All you need is the ability to cope with a sendonly, recvonly, or
inactive data stream - regardless of why you got it.) So sip isn't
limited to support of a fixed set of standardized features.
The new BLISS WG is going to be working on clarifying how to achieve
feature interoperation, hopefully without doing much standardization of
features themselves. You might want to check it out.
Paul
Andrea Rizzi wrote:
> Paul,
>
> Just a note about your answer
>
> .........
> SIP has no mechanism that tells the other party that the HOLD feature
> has been invoked. The sendonly/recvonly/inactive mechanism can be *used*
> when HOLD has been invoked locally, to optimize the use of the media
> path. But the same mechanisms are also used for other purposes. So it is
> incorrect to assume the HOLD feature has been invoked when you receive
> an offer with sendonly.
>
> Paul
> ...........
>
> [AR] From SIP RFCs I might agree with you, and actually this sounds to me as
> a limitation when you have to interwork with other non-SIP network. For
> instance, ITU Q.1912.5 assumes that receiving a re-INVITE/UPDATE with
> a=sendonly has to be considered as a hold request, so that it is interworked
> with a suspend ISUP indication. On the other hand, nothing is said in case
> you receive a=inactive, which is basically a hold request too.
> In other words, the limitation is that a call signaling (hold request) has
> not an equivalent call signaling in SIP (as a media signaling is used
> instead)
>
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
