Sanjay,
Thank you for sending me a call flow to clarify your description.
(Sorry to others, I'm not attaching it because is PDF and not polite to send big stuff
to a list. This reply may not make sense without it.)
Your call flow shows that the entire call setup is completed between A & B before A
ever sends an invite to C. So this isn't a valid case of forking. So I think it is
sufficient to discuss the call between A & B, ignoring C & D.
Remaining commments below.
Paul
Sanjay Sinha wrote:
>
> Hi,
>
> Please consider following parallel forking scenario:
>
> A has been forked to B, C, D.
> A gets 183 from B, C, D, sends PRACK, gets 200 OK to PRACK.
> A sends UPDATE (with hold sdp) to B & C.
> B answers the call, it's UA sends 200 OK with SDP to A.
>
> UPDATE with a new offer has been accepted by B means that initial
> offer-answer exchange is complete and UPDATE/200 OK completes the next
> set of offer-answer exchanges.
> So when B's UA sends SDP with 200 OK to INVITE, for A that's a new offer
> which has to be answered in ACK and the media path will be sendrecv.
>
> My questions are:
>
> 1) Will the callee's UA wait for ACK for 200 Ok, before it starts to
> stream media? If it does, there will be some clipping initially.
Assuming your scenario, this is no different than a hold/unhold in the middle of a
session. The callee is on hold, and must not start streaming media until it receives
SDP indicating it should stop holding.
>
> 2) Will 200 OK to INVITE always have SDP, since INVITE/18x/PRACK
> completes Invite's offer-answer exchange, so the callee may not send SDP
> in 200 OK?
I don't believe the scenario is valid as you have drawn it. It is A that requested
hold. There is no reason why B should initiate another offer/answer exchange in the
200 OK. All it can do is offer the same SDP it did before, and it has no reason to
believe this will result in removing hold. It is up to A to send an offer removing
hold. If it decides to do this before the 200 OK arrives it could do it with another
UPDATE. But once the OK is received it is stuck sending the ACK and then doing a
reINVITE or UPDATE later.
I also don't understand why the hold was initiated in the first place. The only reason
I can see is anticipation of forking and desire to avoid multiple incoming early media
streams. If this is the case, then why not leave A alone and plan on inviting the
other legs on hold? But even then there is no way to avoid clipping if one of the
phones that is on hold is the one that answers first.
Paul
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
