This sounds like far-end NAT traversal detection at work, together with draft-comedia style NAT'd media detection. This type of detection waits to observe the real source port of an incoming RTP packet before responding, and distrusts the SDP ports advertised in the offer from the endpoint in question.
On 12/28/2009 02:47 AM, 이성우 wrote: > Dear > > Have you ever experienced cases that you can not receive any rtp packets even > after finishing offer/answer negotiation is done, and can receive packets > only after sending out your first to the remote party? Provided there is no > fault in SIP signaling perspective, in what circumstances could we possibly > meet cases like this? Wouldn't be NAT configuration or SBC policy in SIP > carrier side? If so, will there be any specific reasons for this? > > happy holiday. > > Lee, Sungwoo > > > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors -- Alex Balashov - Principal Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
