Sigrid Thijs wrote:
> Paul Kyzivat wrote:
>>
>>
>> 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.
>>
>
> I'm afraid we ran into something like that. If our client puts a call
> with a PSTN line on hold (by sending SDP with "inactive" attribute), the
> SDP answer contains no activation attribute (which means "sendrecv").
> The remote party also keeps on sending it's audio data.
In that case I think you have encountered a different problem. Once upon
a time sendrecv, sendonly, and recvonly were defined but inactive was
not. It was added later. So what you have encountered is a device that
does not understand inactive. It may be only 2543 compatible.
If you see such behavior, you then need to fall back to something else
that does work.
Paul
> This is in violation with RFC 3264, 6.1 Unicast Streams:
>
> If an offered media stream is listed as inactive, it MUST be marked
> as inactive in the answer.
>
>
> Although I think this is a bigger violation of RFC 3264, the finger is
> pointed at us because we try to put a stream on hold with the "inactive"
> attribute. But I guess it's all about interpretation ;-)
>
> kind regards,
>
> Sigrid Thijs
>
>> 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
