Richard wrote: > Hi all, > > Suppose caller A wants to initiate a video call with B. He sends an > INVITE to B and B accepts the call and then sends back 200 OK with SDP. > According to RFC 3264, practically caller B will send the audio and > video RTP packet to caller A immediately. Since SIP messages and RTP > packets take different paths to the destination, the media data usually > arrive to caller A first before the 200OK. It's okay for audio data > because voice decoder can decode individual RTP payloads even the first > few packets are skipped (e.g. G.711, G.729). However, it's not case in > video. Take H.263 as an example. Usually the first encoded video frame > is I-frame, and the next few frames are P-frames. If the first I-frame > are skipped, caller A cannot decode the video packet properly until he > gets next I-frames. There would cause significant delays for caller A to > see the caller B. How to solve it? Thanks in advance. > > Caller A Caller B > Invite w SDP(audio & video) > |----------------------------------->| > 200OK w SDP(audio & video) > |<-----------------------------------| > <--B start sending audio and > video data > > ACK > |----------------------------------->|
Well, I see two possible solutions: 1. UAS can wait for the ACK before starting streaming video. 2. UAC can queue several video packets hoping 200 OK will come soon instead of rejecting them immediately. 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
