Thanks Paul. For details reply. Please find my response inline. On Wed, Jun 24, 2015 at 8:45 PM, Paul Kyzivat <pkyzi...@alum.mit.edu> wrote: > 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=sendrecv)-------------------------(UAC2 wants to resume the call >> here) > > > You say this is for resuming the call, but you show sendonly. Is that a > mistake? <#ISSHED#> Yes this is again typo. it is sendrecv. But for video mline UAC2 is sending sendonly. (same SDP which was used while putting call on hold) > >> 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. > <#ISSHED#> That means it is implimentation dependent. there is not RFC which defines the behaviour?? Am I right? >> UAC2 is sending mline for video as last >> used(while holding the call) 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.
<#ISSHED#> As the other party has already rejected mline by making port 0. Is it good to put valid port in the same mline again? > > 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. > <#ISSHED#> This piece of information is worth for me. > 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
