Kedar Karmarkar wrote: > 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?
See ICE for how to deal with this: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-08.txt > 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 > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
