Sumin Seo wrote:
> Hi All,
>
> I have questions regarding signaling flow.
>
> 1.
> UA1 <----------------------> B2BUA <-----------------------------> UA2
> INVITE INVITE
> ------------------------------------>
> --------------------------------------->
> 100 Trying 100 Trying
> <---------------------------------
> <-----------------------------------------
Line art screwed up by email, but I think I know what you mean.
> Let's say UA1 wants to cancel the call at this point.
> Can B2BUA process two call legs separtely?
As far as sip is concerned, yes. All that is required is that it obey
rules as a UA on each leg.
However, depending on what specific functionality the B2BUA is intending
to provide, it may have other constraints it wants to follow.
> i.e Can B2BUA initiate 487 Request Terminated to UA1 after receiving 200 OK
> response to CANCEL from UA1?
Sure it can. It can also send the 487 immediately after sending the
response to the CANCEL, or even before.
> If possible, canceling the call leg between
> B2BUA and UA2 will be process as belows.
> B2BUA sends CANCEL to UA2 and UA2 returns 487 Request Terminated to B2BUA.
> B2BUA doesn't forward the 487 Request Terminated to UA1. B2BUA sends ACK
> to 487 Request Terminated to UA2.
Yes, you can do that.
> 2.
> UA1 B2BUA UA2
>
> INVITE INVITE
> ------------------------------------>
> --------------------------------------->
> 100 Trying 100 Trying
> <---------------------------------
> <-----------------------------------------
> CANCEL
> ------------------------------------>
> 200 OK to CANCEL
> <------------------------------------
> 200 OK to INVITE
>
> <------------------
> CANCEL
> ------------------>
This starts to cover the case I mentioned above. It looks like in this
case you haven't send the 487 to UA1 yet.
> 2.1. Should B2BUA forward 200 OK response to INVITE to UA1 if B2BUA
> receives the 200 OK after sending CANCEL to UA2?
If it hasn't already sent a final response to UA1 it may send a 200 at
this point.
> 2.2 Can B2BUA do the followings?
> B2bUA sends 200 OK response to CANCEL to UA1 followed by 487 Request
> Terminated. And B2bUA sends ACK to 200 OK to UA2 and then send BYE to UA2.
Yes, you can do that.
BUT, this could be particularly troublesome if this B2BUA doesn't
terminate media, and instead simply forwards the SDP offer from UA1 to
UA2. Until UA2 receives the BYE it may be sending media to UA1's media
port, even after UA1 thinks the call is cleared.
Its also possible that UA2 may send some other error response, rather
than 487. But that is less troublesome. Since UA1 wanted to cancel
anyway, ignoring some other error should be ok.
> 3. Can UA1 send BYE before sending final response to INVITE? if that is
> possible, what is the expected behavior of B2BUA?
UA1 may send a BYE if an early dialog has been established, via receipt
of a provisional response containing a To-tag.
Again the *expected* behavior is rather undefined except that it must
behave as a UA on both legs.
> 4. B2BUA had sent CANCEL to UA2. After that, It received BYE from UA1. But
> it hasn't received a final response to INVITE yet. Can B2BUA forward BYE to
> UA2?
In all of these cases it is really improper to talk about the B2BUA
*forwarding* a request. It is better to think of it as sending a related
and similar request on the other dialog.
The B2BUA may send a BYE to UA2 any time it is legal for it, as a UA, to
do so, regardless of what it has received from UA1. As noted above, its
legal to send a BYE if an early dialog has been established with UA2.
> Is it necessary for B2BUA to wait for 200 OK response to CANCEL from
> UA2 when it sends BYE to UA2?
I don't think so.
> 5. If B2BUA receives BYE from UA1 shortly after B2BUA sent BYE to UA1,
> which response should be sent by B2BUA? 200 OK or 491 Request Pending?
See the race-conditions draft.
The bottom line in all of this is that there aren't any general answers
for most of what a B2BUA does. You must *design* the way you want your
B2BUA to operate, with the constraint that in all cases it must follow
the rules for a UA. The rules for UAs are quite well defined.
Paul
> I would appreciate your support.
>
> Regards,
> Sumin
> _______________________________________________
> Sip-implementors mailing list
> [email protected]
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
