Dinoop <dinoop...@gmail.com> writes: > 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?
It seems that the key to this is in section 3 of RFC 3262: The UAS MAY [...] unless the final response is 2xx and any of the unacknowledged reliable provisional responses contained a session description. In that case, it MUST NOT send a final response until those provisional responses are acknowledged. UaB follows this rule, because message 4 is acknowledged (UaB receives message 7) before UaB sends the 200 (message 9). Similarly, at the end of this sequence, B2BUA can send a 200 for message 1, having received message 6. Reading this section, it doesn't seem that there is any constraint regarding when a UAS has to send 200 for PRACK compared to any other messages. Dale _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
