Greg Burrow wrote: > Thanks all for the information, I should have included the callflow in > the original message. > > |628.190 | INVITE SDP ( g729 telephone-event) > | |(5060) ------------------> (5060) > |628.190 | 100 Trying > | |(5060) <------------------ (5060) > |639.480 | 183 Session Progress SDP ( g729) > | |(5060) <------------------ (5060) > |647.015 | 200 OK SDP ( g729) > | |(5060) <------------------ (5060) > |647.040 | BYE > | |(5060) ------------------> (5060) > |648.354 | 200 OK SDP ( g729) > | |(5060) <------------------ (5060) > |650.358 | 200 OK SDP ( g729) > | |(5060) <------------------ (5060) > > > As you can see the UAC never sends an ACK. The UAC vendor has confirmed > this is due to the contents of the SDP received in the 200 OK. The > consensus seems to be that the UAC is "clearly broken". The UAS > eventually sends a BYE after a number of retransmissions.
In a good implementation the SDP content problem should not prevent UAC from sending ACK, since ACK only confirms receipt of the message, not the fact that UA understands or accepts the SDP. > The case where the ACK and BYE are reversed in transit is interesting. > If the UAS receives BYE then ACK would the UAS state machine transition > to the Confirmed/Established state and rely on a retransmission of the > BYE from the UAC to terminate the dialog? The only way for UAS INVITE transaction to go to the confirmed state is to receive ACK or hit 64*T1 timeout. Since RFC3261 also allows UAC to send BYE on early dialogs, the UAS dialog state machine probably need to have separate state for the dialog that has been terminated but with INVITE transaction not yet confirmed. Regards, -- Maksym Sobolyev Sippy Software, Inc. Internet Telephony (VoIP) Experts T/F: +1-646-651-1110 Web: http://www.sippysoft.com MSN: [email protected] Skype: SippySoft _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
