As all mentioned its all possible to send any direction till UE follows offer-answer model but its lacking actual use-case and seems ill-logical. Just want to share one point regarding step 4 , where UAC2 sending sendonly and it seems UAC2 suddenly have something to send which he was not having in original answer(recvonly). It seems that UAC2 trying to provide possibility of playing Hold tone to remote user in case it has provision of playing holdtone in associated TAS .So actually UAC2 himself dont have anything to send all of sudden.
On Wed, Jun 24, 2015 at 9:39 AM, isshed <isshed....@gmail.com> wrote: > 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 > _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
