Dinoop,
On 5/26/17 4:50 AM, Dinoop wrote:
Thanks Worley and Paul,
My scenario is,
UAC B2BUA UaB
| 1:INVITE(SDP) | |
+----------------------->| |
| 2:100[INV] | |
|<-----------------------+ |
| | 3:INVITE(SDP) |
| +----------------------->|
| | 4:D1.183[INV](SDP) |
| |<-----------------------+
| 5:D1.183[INV](SDP) | |
|<-----------------------+ |
| 6:D1.PRACK | |
+----------------------->| |
| | 7:D1.PRACK |
| +----------------------->|
| | 8:D1.200[INV](SDP) |
| |<-----------------------+
| | 9:D1.200[PRA] |
| |<-----------------------+
Where the 200[INVITE] has reached B2BUA before 200[PRACK]. What should
be the behavior of B2BUA as Ua-Client on right side. Or in general what
handling should be done at Ua-client side when this occurs?. Is there
any standard defined to handle this message crossing?
I don't see any particular issue here. The response to the PRACK is
required to complete its transaction, but the 200 to the INVITE is
evidence that the PRACK had been received and that its 200 will be
forthcoming. You can simply forward the 200 (INV) and the 200 (PRA) as
they are received, or you could synthesize and send a 200 for the PRACK
before forwarding the 200 (INV). Or you *could* hold the 200 (INV) until
you get the 200 (PRA) and reorder them if you wish, though in some
extreme cases that might lead to timing issues.
Thanks,
Paul
On 25 May 2017 at 23:43, Dale R. Worley <wor...@ariadne.com
<mailto:wor...@ariadne.com>> wrote:
Dinoop <dinoop...@gmail.com <mailto:dinoop...@gmail.com>> writes:
> How can a B2BUA handle message crossing of 200OK(invite) over
200OK(PRACK)?
> Is it a correct approach for the implementation to reject the
> 200OK(INVITE) until it receives PRACK response?
>
> I have gone through the RFC 6337, unfortunately nothing is mentioned about
> this scenario.
As Paul says, the B2BUA has to behave correctly "on each side". In your
situation, we would need to see a detailed diagram of the message flow
you are contemplating before we would know exactly what the situation is
and what possible strategies the B2BUA could use.
--
Thanks & Regards
Dinoop p
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
