Thanks for response Dale. there is a typo fro 2nd message. read it as a=sendrecv. Meaning call get Successfully connected with audio and video.
On Wed, Jun 24, 2015 at 8:44 AM, Dale R. Worley <wor...@ariadne.com> wrote: > 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
