isshed <isshed....@gmail.com> writes: > UAC1--------------------------------------------------------------------UAC2 > > 1)---------------------INVITE (a=sendrecv)-------------------------> > 2)<---------------------200-OK(a=recvonly)------------------------- > 3)-------------------------------ACK--------------------------------------> > > 4)<---------------------INVITE (a=sendonly)------------------------- > 5)---------------------200-OK(a=inactive)-------------------------> > 6)<---------------------------ACK ----------------------------------------- > > 7)<---------------------INVITE (a=sendonly)------------------------- > 8)---------------------200-OK(a=recvonly)-------------------------> > 9)<---------------------------ACK ----------------------------------------- > > The call is established in step 3. It's an audio and video call. > In step 4 UAC2 puts call on hold by sending (a=sendonly) for both > audio and video media lines. > In step 5 UAC1 responds with a=inactive for both audio and video lines > and along with that it makes video port as 0. > > While resuming in step 7 > > Does UAC2 send video line with valid port or 0 port??? for audio mline > it is sending validn port with a=sendrecv. > > > What is happening is UAC2 is sending mline for video as last > used(while holding) with valid port and a=sendonly?? > > Does RFC says anything or is it implementation dependent behavior??
It's all implementation dependent behavior, so all of this is *valid*. On the other hand, one would not expect UAs to behave this way. The general rule to make an implementation interoperate as well as possible is "offer everything that you are willing to do". Initially, UAC1 offers sendrecv, which is usual. But UAC2 responsds recvonly, which is uncommon unless UAC2 is incapable of sending media. (Perhaps it is a public announcement device?) In step 4, UAC2 offers sendonly, which suggests that it has become able to send, but has also become unable to receive. That change in state corresponds to no use case that I am aware of. Dale _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
