The caller SHOULD play ring back tone in this case (since he detects he is getting no RTP packets from remote towards RBT).
Regards Satya T -----Original Message----- From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Miguel Oreilly Sent: Thursday, August 06, 2009 5:20 PM To: Abhishek Dhammawat Cc: sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] 180 Ringing after 183 Session progress In addition to this; Do you think there should be a RBT or no? In the case that I am investigating there is no RBT. 2009/8/6 Miguel Oreilly <miguel.orei...@gmail.com> > for clarification; > 183 ( with SDP ) and 180 ( without SDP ) were coming from same UAS. > > > > 2009/8/6 Abhishek Dhammawat <abhishek.dhamma...@aricent.com> > >> Hi >> >> I would request you not to remove the original question from the mail >> chain for better understanding of the issue I am putting the question >> by Miguel orielly again >> >> >> "I am wondering if the below scenario is valid or not. >> >> <-- 183 (with SDP) then, >> <-- 180 (without SDP) >> >> >> Thanks in advance, >> >> >> Miguel" >> >> The above question does not specify that 183 and 180 are received >> from single UAS or different. The answer mentioned in my response was >> considering the scenario when same UAS has sent 183 with SDP followed >> by 180 without SDP. >> >> regards >> Abhishek Dhammawat >> >> >> -----Original Message----- >> From: sip-implementors-boun...@lists.cs.columbia.edu [mailto: >> sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Iñaki >> Baz Castillo >> Sent: Thursday, August 06, 2009 4:23 PM >> Cc: sip-implementors@lists.cs.columbia.edu >> Subject: Re: [Sip-implementors] 180 Ringing after 183 Session >> progress >> >> 2009/8/6 Abhishek Dhammawat <abhishek.dhamma...@aricent.com>: >> > The below is valid scenario. >> > >> > Also RFC 3261 section 13.2.1 mentions >> > >> > "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." >> >> >> This is fully incorrect in the case above since what you have pasted >> is just referred to ONE (early) dialog. >> If there is parallel forking, the UAC could receive various different >> SDP from each early dialog. But inside a early-dialog, the SDP cannot >> change. >> >> -- >> Iñaki Baz Castillo >> <i...@aliax.net> >> >> _______________________________________________ >> Sip-implementors mailing list >> Sip-implementors@lists.cs.columbia.edu >> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors >> >> "DISCLAIMER: This message is proprietary to Aricent and is intended >> solely for the use of the individual to whom it is addressed. It may >> contain privileged or confidential information and should not be >> circulated or used for any purpose other than for what it is >> intended. If you have received this message in error,please notify >> the originator immediately. If you are not the intended recipient, >> you are notified that you are strictly prohibited from using, >> copying, altering, or disclosing the contents of this message. >> Aricent accepts no responsibility for loss or damage arising from the >> use of the information transmitted by this email including damage from >> virus." >> >> _______________________________________________ >> Sip-implementors mailing list >> Sip-implementors@lists.cs.columbia.edu >> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors >> > > _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
