Vikram Chhibber wrote:
> As per RFC 3264, a missing direction attribute in offer SDP default is
> sendrecv. What is the default considered in case of Answer SDP?
> I assume that it should be again sendrecv and the default does not
> change whether it is offer or answer.
There are some issues because it is possible that the answerer doesn't
support the directionality attributes. If the offer is sendrecv and the
answer has no directionality attribute then assuming sendrecv in the
answer works whether the answerer supports them or not. But if the offer
included sendonly/recvonly/inactive, and the answer includes no
directionality you should assume the answerer didn't understand you -
rather than assuming he did and explicitly returned an invalid answer.
> If the hold answer comes without direction attribute but with
> connection line IP 0.0.0.0, should I consider this a valid hold
> answer?
It would be unusual for an answer to initiate hold if a hold wasn't
already in place, though it is legal to do so.
The 0.0.0.0 could be used for a variety of reasons, hold being only one
of them. You shouldn't try too hard to figure out why. But you should
dealt with this valid response.
> I am asking this question because in my inter-operation testing, one
> of the UE sends answer without direction attribute when I send offer
> with a=sendonly.
That is exactly my point above. In this case, you wanted hold and the
answerer didn't support the way you did it. If you want to make the hold
work, then you have a couple of options:
- fall back to the old method by sending another reinvite using
c=0.0.0.0
- you could just drop received media without rendering it.
Paul
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
