On 6/23/15 10:23 PM, isshed wrote:
Hi Paul,
Below is the updated scenario. sorry for confusion by making step2 as
recvonly. now it is fine. The problem here is that after step 9 call
becomes audio only. Video disappears.
UAC1--------------------------------------------------------------------UAC2
1)---------------------INVITE (a=sendrecv)------------------------->
2)<---------------------200-OK(a=sendrecv)-------------------------
3)-------------------------------ACK-------------------------------------->
4)<---------------------INVITE
(a=sendonly)-------------------------(UAC wants to put call on hold
here)
5)---------------------200-OK(a=inactive)------------------------->
6)<---------------------------ACK -----------------------------------------
OK. The above looks *reasonably* normal. It is a little odd for UAC1 to
answer inactive in (5). (Why wouldn't it want to receive if it was
willing to sendrecv? Saying "I won't listen to you if you won't listen
to me" is a little picky. How does it know there isn't something
worthwhile to listen to? I guess it might make sense if it is assuming
that this will be music-or-advertisements-on-hold, but there is no way
for it to know that for certain.)
7)<---------------------INVITE
(a=sendonly)-------------------------(UAC2 wants to resume the call
here)
You say this is for resuming the call, but you show sendonly. Is that a
mistake?
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 respectively.
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 addition to comment above, it is a little hard to understand *why* it
should drop the video at this point. I suppose maybe it is trying to
save the bandwidth for what it supposes is worthless media? But again,
this is a leap of faith, since there is nothing in the signaling that
says "this is MoH". There could be some other reason, where the content
is real but oneway. (E.g. UAC2 had someone enter the room who should not
observe the media from UAC1.)
While resuming call 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.
(Assuming the sendonly in (7) was a mistake and you intended it to be
sendrecv.) Certainly UAC2 *may* include a valid video port. If it is
still wants, and it prepared to, send/receive video then I think it
should. My previous comments to you still apply.
What is happening is UAC2 is sending mline for video as last
used(while holding) with valid port and a=sendonly??
I don't understand what that sentence is trying to say.
Of course you must continue to have the video m-line in some form, so
the question is whether the port is zero or not, and whether sendrecv or
something else. In an offer all those choices are open to the offerer
and so are implementation choice. But some choices are more likely to
lead to desired results than others.
The general approach that I advocate is:
When sending an *offer*, offer what *you* want, without regard to what
you might *think* the answerer will want. In subsequent offers this must
be tempered slightly in that you must retain all the m-lines, and you
should generally (if you can) include at least one codec in common with
what was agreed in the prior o/a for continuity.
When sending an *answer*, same guidelines as for offers, except that you
are more constrained in what "direction" you can put - e.g. you can only
answer recvonly or inactive if the offer had sendonly.
Reducing what you offer because you think (based on prior O/A) doesn't
want something is generally a pathway to a suboptimal experience.
Thanks,
Paul
Does RFC says anything or is it implementation dependent behavior??
Thanks,
On Wed, Jun 24, 2015 at 12:04 AM, Paul Kyzivat <pkyzi...@alum.mit.edu> wrote:
I saw this after replying to the prior message. But I don't see anything
here that alters my reply.
Thanks,
Paul
On 6/23/15 9:16 AM, isshed wrote:
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 (??????)-------------------------
8)---------------------200-OK(????)------------------------->
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??
Thanks,
On Tue, Jun 23, 2015 at 6:43 PM, isshed <isshed....@gmail.com> wrote:
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
-----------------------------------------
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??
Thanks,
_______________________________________________
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
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
