Brett Tate wrote:
>>> I have some odd test scenario where initial call establishment
>> happens with
>>> recv only / sendony. After the establishment of the call caller
>> reinvites
>>> with "0.0.0.0" and direction attribute recvonly. I understand that
>> this is a
>>> invalid case, but would like to get comments in this case how callee
>> should
>>> behave?. Does callee rejects the offer?
>> What makes you think this is an invalid case?
>
> My assumption is that Suresh is interpreting the following RFC 3264 section 8
> text normatively and still applicable when ("no longer recommended") 0.0.0.0
> is used for hold:
>
> "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."
>
> "RFC 2543 [10] specified that placing a user on hold was accomplished by
> setting the connection address to 0.0.0.0. Its usage for putting a call on
> hold is no longer recommended, since it doesn't allow for RTCP to be used
> with held streams, doesn't work with IPv6, and breaks with connection
> oriented media."
Maybe that's his assumption. But
- the above is not normative
- we don't know that the UAC is "placing the user on hold".
It may have some other motivation for doing this.
Since its at the beginning of the call, I'm inclined to guess
that it isn't hold as that is normally understood.
Its really not the job of the UAS to understand *why* this is happening.
Its job is simply to respond in the best way it can given its own
circumstances.
Thanks,
Paul
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
