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
