On 7/16/12 3:22 PM, Kumar, Puneet (Puneet) wrote:
> 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?
The above applies to a single dialog. It didn't envision the case of a
UA responding on two dialogs. Your B2BUA is responding using two
different dialogs. (This is equivalent to the request having been forked
by a proxy, to two different UAs.) In effect to-tag t1 and to-tag t11
identify two different UAs.
Thanks,
Paul
> 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
