Thanks Paul,

RFC 3262 says:

3 UAS Behavior
.......
   After the first reliable provisional response for a request has been
   acknowledged, the UAS MAY send additional reliable provisional
   responses.  The UAS MUST NOT send a second reliable provisional
   response until the first is acknowledged.  After the first, it is
   RECOMMENDED that the UAS not send an additional reliable provisional
   response until the previous is acknowledged.  The first reliable
   provisional response receives special treatment because it conveys
   the initial sequence number.  If additional reliable provisional
   responses were sent before the first was acknowledged, the UAS could
   not be certain these were received in order.

Hence I thought B2BUA can't send 200OK on dialog f1+c1+t1 because PRACK
is pending on dialog f1+c1+t11.
Since both dialogs are part of same session I think above statement will
hold true.

Am I correct?

Thanks,
Puneet


-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of
Paul Kyzivat
Sent: Monday, July 16, 2012 9:29 PM
To: [email protected]
Subject: Re: [Sip-implementors] PRACK + Active Forking

I see that Brett already answered, and I have no argument with is reply.
But here are some thoughts of mine.

On 7/16/12 3:56 AM, Kumar, Puneet (Puneet) wrote:
> Sending again with proper formatting.
> -------
> Hi All,
>
> Let's assume a scenario where B2BUA forks the incoming call for a user
> to two UA's, UA2&  UA3.
>
> SIP message flow for this is:
>
> UA1                B2BUA                  UA2         UA3
> ---------INVITE---------->
>         (Call-ID=c1)
>         (From tag=f1)
>                       ----------INVITE-------->
>                       (Call-ID=c2)
>                            (From tag=f2)
>                       ------------------INVITE------------------>
>
>                               (Call-ID=c3)
>                                   (From tag=f3)
>                       <-----------------180----------------------
>                                   (Call-ID=c3)
>                                   (From tag=f3)
>                                   (To tag=t3)
> <----------180------------
>        (Call-ID=c1)
>        (From tag=f1)
>        (To tag=t1)
>                       <---------180------------
>                             (Call-ID=c2)
>                             (From tag=f2)
>                             (To tag=t2)
>                             (Require=100rel)
> <----------180------------
>       (Call-ID=c1)
>       (From tag=f1)
>       (To tag=t11)
>       (Require=100rel)
>                       <-----------------200----------------------
>                                   (Call-ID=c3)
>                                   (From tag=f3)
>                                   (To tag=t3)
>                        --------CANCEL--------->
>                       (Call-ID=c2)
>                             (From tag=f2)
>                             (To tag=t2)
>                       <--------200--------------
>
> As per our internal design after receiving final response from UA3,
> B2BUA will CANCEL the call towards UA2.
> But we can't send 200OK to UA1 as a PRACK is pending on
> dialog(c1+f1+t11).

Why? You have two early dialogs going - f1+c1+t1 and f1+c1+t11. You can 
send a 200 on f1+c1+t1.

> Thus I have few queries on it:
> 1) Can B2BUA send a CANCEL to UA2 before PRACK transaction is over?

Yes.

> 2) If answer to above question is "yes" then how can B2BUA send 200OK
> for dialog(c1+f1+t1) to UA1?

Just do it. The two early dialogs are independent of one another.

UA1 still owes a PRACK on f1+c1+t11, but that is a separate issue. The 
issues that remain are:

- the B2BUA keeping enough state to handle the PRACK when it arrives.

- the B2BUA sending a PRACK to UA2 for the 180 already received.

- in spite of the CANCEL, UA2 could still send additional 1xx and/or
   a 2xx response. The B2BUA must be prepared to deal with these.

The fundamental implementation decision to make here is whether to 
continue to couple f1+c1+t11 with f2+c2+t2, or to manage them 
independently. You can make either of them work. And either one will 
require the B2BUA to keep some state.s

        Thanks,
        Paul

> Are there any alternate&  better way to handle this call flow?
>
> Thanks,
> Puneet
>
>
> _______________________________________________
> 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

_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Reply via email to