Hello Markus, I think you are right, unless you have already opened pinholes for media before (invite sdp, 183 rel answer). With 183 rel offer, if the far end starts sending media, you will loose some media initially. Paul, what do you think?
Kedar On 4/19/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Hi Kedar, > > I have a question about the one way mode (recv-only) with a firewall. > > Our UAC sends out an INVITE and got a 183 with SDP. Then the UAS starts > to send > early media packets. All packets will discard by the firewall. What must > the > UAC do that the port for RTP packets is open? Is it realy practical to go > into > a "one way mode"? > > Thank you, > Markus > > Am 19.04.2006 schrieb Kedar Karmarkar <[EMAIL PROTECTED]>: > > > This is not a complete answer to your question, but for 183 call > proceeding, > > if you will have one way media (TDM -> IP for example), which means your > > answer could have a one way mode. When the call is completed, you will > > switch over to sendreceive, which means you will need to send an updated > > SDP, does'nt this need SDP with your 200? > > > > Kedar > > > > > > On 4/19/06, Andrea Rizzi <[EMAIL PROTECTED]> wrote: > >> > >> Trying to properly manage interworking with PSTN with early media, and > >> pre-connect free call announcements, I would ask if someone can clarify > my > >> doubts. > >> > >> > >> > >> According to RFC3261: > >> > >> o If the initial offer is in an INVITE, the answer MUST be in a > >> > >> reliable non-failure message from UAS back to UAC which is > >> > >> correlated to that INVITE. For this specification, that is > >> > >> only the final 2xx response to that INVITE. That same exact > >> > >> answer MAY also be placed in any provisional responses sent > >> > >> prior to the answer. The UAC MUST treat the first session > >> > >> description it receives as the answer, and MUST ignore any > >> > >> session descriptions in subsequent responses to the initial > >> > >> INVITE. > >> > >> > >> > >> Considering this RFC only, and assuming the SDP offer is within the > INVITE > >> request, it is not clear if the SDP answer MUST be present in the 2xx > >> response also in the case the SDP answer has already been provided to > the > >> UAC in a provisional response (such as a 183 Session Progress). In case > it > >> is mandatory, it appears the UAC must ignore the "duplicated" answers, > >> behaving as they are missing. > >> > >> > >> > >> When using PRACK, it is not clear if provisional responses may be > >> considered > >> as a "reliable non-failure message" in the sense reported above. If so, > it > >> appears the UAS would no longer be needed to put the "duplicated" > answer > >> in > >> the 2xx response. Is my assumption correct? > >> > >> > >> > >> Finally, things get more complex when media changes before 200 OK by > using > >> the UPDATE method. Consider the following sequence: > >> > >> > >> > >> INVITE (SDP Offer A) -> > >> > >> <- 183 Session progress (SDP Answer A) > >> > >> PRACK -> > >> > >> <- 200 PRACK > >> > >> <- UPDATE (SDP Offer B) > >> > >> 200 UPDATE (SDP Answer B) -> > >> > >> <- 200 INVITE (SDP ???) > >> > >> -> ACK (SDP ???) > >> > >> > >> > >> This is a quite common scenario to manage free call announcements > before > >> 3PCC-based redirection to the final destination. In this case, I'd like > to > >> understand if the SDP in the 200 response to the INVITE is mandatory or > >> not, > >> and if it is, how the SDP has to be filled and how the UAC has to > consider > >> this new SDP (a new offer, or ignore it as RFC3261 says for the basic > >> scenario? > >> > >> > >> > >> Regards > >> > >> > >> > >> Andrea > >> > >> > >> > >> _______________________________________________ > >> Sip-implementors mailing list > >> [email protected] > >> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > >> > > _______________________________________________ > > Sip-implementors mailing list > > [email protected] > > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > > > > > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
