On 01/08/2011 11:33 AM, Iñaki Baz Castillo wrote: > 2011/1/8 Kevin P. Fleming<kpflem...@digium.com>: >> Maybe I'm missing something obvious (it is Saturday morning after all), >> but why does the UAS need to send an SDP *at all* in order to play >> announcements? If the UAC included an SDP offer in the initial INVITE, >> then it is prepared to receive media on any sessions in that offer that >> are either 'active' or 'recvonly', whether it receives an answer or not. > > The UAC publishes its media address for that dialog in its SDP > (INVITE). Does it mean that the UAC must accept RTP in that address > coming from anywhere? IMHO it shouldn't. But in case the UAS has > published a SDP (i.e. in 183) then UAC already knows where it can > accept RTP from.
According to the RFC, the answer is *yes*. The SDP offer is an offer to receive media, and the offer is valid as soon as it is delivered to the recipient. The offer does not restrict the source of the media in any way (again, according to the RFC). Now of course common practice is to wait for the answer and attempt to use the answer's SDP as the proposed 'source address' of the media streams, but in NAT situations without ICE/TURN/STUN/etc. that doesn't work anyway and implementations are forced to use comedia mode. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA skype: kpfleming | jabber: kflem...@digium.com Check us out at www.digium.com & www.asterisk.org _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
