What I could think with respect to whether SDP is received in provisional response or not is to check in your application for RTP stream.
I believe in having a check in application to check whether any RTP stream is still there or not after receiving 181 or 182 with SDP. You can't ensure that remote gateway would always connect and play media if SDP answer is sent in provisional response. If no RTP is coming even after SDP answer, then some sort of tone viz routing tone can be played locally else RTP receiving from remote end should be honored. However, routing tone needs to be played locally only if provisional response is not having SDP answer. Best Regards, Vivek Batra -----Original Message----- From: Sunita Bhagwat [mailto:sunita_bhag...@infosys.com] Sent: Tuesday, March 02, 2010 5:53 PM To: Vivek Batra; sip-implementors@lists.cs.columbia.edu Subject: RE: [Sip-implementors] Ringback on SIP 181 Call forward / 182 Queued Thanks Vivek. You are right, the choice of actual tone could be either configurable or something other than RBT. But the other aspect of the problem is to be prepared to play early media inband (if a prior 183 or current 181 contain SDP) by cutting through media or playing a specific tone - something similar to the scenario RFC3960? I wonder if implementations really set up the media path immediately after sending out the INVITE (say, with OFFER) and without receiving an ANSWER, as required by 3960. Am I missing something here? Regards, Sunita -----Original Message----- From: Vivek Batra [mailto:vivek.ba...@matrixtelesol.com] Sent: Tuesday, March 02, 2010 5:12 PM To: Sunita Bhagwat; sip-implementors@lists.cs.columbia.edu Subject: RE: [Sip-implementors] Ringback on SIP 181 Call forward / 182 Queued Playing RBT on receipt of 181 (Call is being forwarded) or 182 (Call Queued) does not seems a good choice since 181/182 does not give any indication whether call has been placed to called party and called party is ringing. I would prefer playing Routing Tone or some sort of local announcement. RBT should be played only when called device is ringing. I believe that gateway should get 180 Ringing (after 181 Call is being forwarded) when called mobile phone starts ringing and RINGING message is received from GSM network. Once this occurs, then only RBT should be played. Best Regards, Vivek Batra -----Original Message----- From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Sunita Bhagwat Sent: Tuesday, March 02, 2010 4:49 PM To: sip-implementors@lists.cs.columbia.edu Cc: Sunita Bhagwat Subject: [Sip-implementors] Ringback on SIP 181 Call forward / 182 Queued Hi all, I'd like to know if a SIP gateway receiving a 181 (Call is being forwarded) or a 182 (call Queued) from SIP peer should play local ringback towards the originating endpoint (say PSTN/ISDN). RFC 3960 mentions early media and ring-back only when a 180 Ringing is received. However I'm seeing a customer scenario involving a Microsoft OCS network forwarding calls to cell phones and sending a 181 to the gateway - expecting the originating gateway to play a ringing tone to calling party. I think it makes sense to play ringing tone and be prepared to play inband media if received, but such a scenario does not seem to be covered in rfc 3960. Appreciate your inputs. Thanks, Sunita _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors Email Scanned for Virus & Dangerous Content by : www.CleanMailGateway.com **************** CAUTION - Disclaimer ***************** This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system. ***INFOSYS******** End of Disclaimer ********INFOSYS*** Email Scanned for Virus & Dangerous Content by : www.CleanMailGateway.com _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
