Sigrid Thijs wrote:
> Hi,
>
> according to RFC 3264 a stream is put on hold by marking it sendonly:
>
> If the stream to be placed on hold was previously a sendrecv media
> stream, it is placed on hold by marking it as sendonly. If the
> stream to be placed on hold was previously a recvonly media stream,
> it is placed on hold by marking it inactive.
>
> Is it wrong to put a sendrecv media stream on hold by marking it
> inactive? If so, why?
At least in theory it is fine to do that. "HOLD" is a local concept in
sip - it isn't signaled. The use of sendonly or inactive is just a way
to put the media streams in a state that is more convenient while the
call is held. Presumably sendonly indicates that the UA initiating
"hold" still wants to send something (i.e. music), but isn't interested
in receiving anything from the other UA. If the UA initiating hold
doesn't want to send media, then "inactive" is entirely appropriate.
Note that I said "in theory". I hear stories of implementations that
attempt to infer intent from the signaling and do special things. For
instance a PBX that works as a B2BUA. When it sees a reinvite with
sendonly, it decouples that UA from the other one, and initiates music
on hold using its own music source rather than from the initiating UA.
So if you find yourself in an environment where some other party is
attempting to infer the initiation of the "hold" feature based on
examining the signaling, then use of "inactive" rather than "sendonly"
may yield unusual results.
Paul
> kind regards,
> Sigrid Thijs
>
>
> _______________________________________________
> Sip-implementors mailing list
> [email protected]
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
