On 6/23/15 9:13 AM, isshed wrote:
I seem to have made a career for myself discussing questions like this!
Hi All,
Below is the scenario..
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 -----------------------------------------
IMO both UAs are acting illogically. (I might change my mind if I knew
more about the motivations for the behavior.)
The call is established in step 3. It's an audio and video call.
Why did UAC2 reply with recvonly? I guess that could be ok if it is some
special device that has nothing to send, though it would be difficult
for a caller to deal with such a device.
Does it matter that it is audio and video? are these attributes being
negotiated identically for both streams?
In step 4 UAC2 puts call on hold by sending (a=sendonly) for both
audio and video media lines.
While this is allowed, and would make sense for a device that had been
previously recvonly, it seems odd to me in this situation that it is
offering sendonly. Does it suddenly have something to send, when up till
now it didn't? If it still has nothing to send, and still doesn't want
to receive, they it would be better for it to offer inactive.
In step 5 UAC1 responds with a=inactive for both audio and video lines
and along with that it makes video port as 0.
In (1) UAC1 was willing to both send and receive. Unless this has
changed, why isn't it responding with recvonly rather than inactive? (Is
it unwilling to receive if it can't send?)
Rejecting video seems independent. It can do so if it wants. But it
seems odd that it would do so simply because it was asked to be recvonly.
While resuming in step 7
Resuming what? It is offering exactly the same as in (4). If it were
resuming back to a "normal" state then it would offer sendrecv. If it
were attempting to get back to *it's* initial state from (1) (recvonly)
then it would offer that.
Does UAC2 send video line with valid port or 0 port??? for audio mline
it is sending validn port with a=sendrecv.
If it still wants video, then it should include a valid port. If *it* no
longer wants video then it can offer port 0. It should not make this
decision based on what it thinks UAC1 wants, since it has imperfect
knowledge of what that is.
Potentially there is a cost to UAC2 to continuing to offer video. (It
may have released the video resources and need to reclaim them.) So it
*can* decide based on what it observed from UAC1, that continuing to try
video is not in its best interest. But it then loses the possibility
that video might now be possible.
What is happening is UAC2 is sending mline for video as last
used(while holding) with valid port and a=sendonly??
Certainly that is ok.
Does RFC says anything or is it implementation dependent behavior??
There are several RFCs that touch on this. Take a look at RFC6337, which
tries to pull everything together, including stuff that must be inferred.
But in the end much of this is implementation dependent. There are
sometimes good reasons to do something unusual. But more often than not
odd behavior is simply a sign of a poor implementation.
Thanks,
Paul
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
