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