Hi all, RFC3960, gateway model, says basically: once you receive a 180 ringing plays a local ringback UNLESS you are actually already receiving a stream. This should mean that in case an RTP stream is flowing, you have to "ignore" the 180 and continue playing the stream. Note that in field scenarios, the RTP flows might stop regardless the offer/answer exchange has closed (quite often in case of call redirected from/to IVRs). In your case, assuming the RTP is really flowing to the calling party, the sequence 180/no SDP + 183/SDP should generate a local ringback (probably too short to be played I guess) followed by the stream (colored ringback), while the sequence 183/SDP + 180/no SDP shall simply plays the colored ringback. As far as I know, RFC3960 is the only one saying something about this case, and it looks like (almost) nobody take care of it.
Andrea -----Original Message----- From: Franz Edler [mailto:franz.ed...@kabsi.at] Sent: lunedì 31 agosto 2015 18:41 To: 'Paul Kyzivat'; sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] Two provisional responses in one dialog: 180 Ringing and 183 Session Progress Hi Paul, > I don't know ISUP, so I'll ask some followup questions. > > > we have a nasty situation in case of interworking SIP to ISUP. > > The INVITE request is mapped to ISUP/IAM, that's as expected. > > But then on the ISUP side we have a colored ringback tone service. > > This causes in an ISUP ACM message with both flags set: > > - Backward Call Indicator: subscriber free > > - Optional Backward Call Indicator: In-band info or pattern > > available The interworking implementation maps both flags to > > separate messages > > - Backward Call Indicator: subscriber free --> 180 Ringing > > - Optional Backward Call Indicator: In-band info or pattern > > available > > --> > > 183 Session progress. > > What is a "colored ringback tone"? Is that in-band ringback? Yes, it is a callee specific ring-back-tone (e.g. a characteristic music-sound) , which is sent to the caller. Sometimes it is also called PRBT (Personalized Ring-Back Tone). > > The UA client receives both provisional responses and it depends on > > the sequence if the colored ringback tone is rendered. > > The sequence shouldn't affect this (much). But if 180 Ringing is interpreted by the client as "apply local ring-back tone" then it matters, if 180 Ringing comes as the last of the two. > > If 183 Session progress is the last on then the colored ringback > > tone is rendered. > > If 180 Ringing is the last one, then the colored ringback tone is > > followed by the local generated ringing tone, which leads to the > > colored ringback tone not being rendered. > > The 180 doesn't mean that you should generate ringback instead of > playing in-band ringback. > You should treat the 180 as meaning: generate ringback if you are not > receiving in-band media. O.k. understood, but the " ... if you are not receiving in-band media" is nowhere specified, or is it? > Nor does the 183 mean "play in-band media". The 183, by itself, > doesn't mean much of anything. It is simply a vehicle for carrying > stuff that has meaning. In particular, it can carry SDP. > > Even receiving a 183 with SDP doesn't really mean "play in-band media". > If you have already sent an SDP offer, then you *ought* to start > playing in- > band media as soon as you begin receiving it, even if you have not received > an SDP answer. The answer tells you where to *send* media, not really > anything about receiving it. > > At least that is the way the SIP spec was written. That has been "bent" > in a lot of implementations. In particular, some implementations will indeed > delay playing received media until they have received an answer. > And they may only accept received media sent from the IP address given > in the answer. (This means that symmetric RTP is being required.) > > If the environment that you are in wants to apply such a restriction, > then go > ahead and honor that. In that case you will ignore incoming rtp until > you have > received an answer (in any 18x). But then you should treat it as preempting > ringback locally generated due to 180. So, the media received from the network should have priority over the locally generated ring-back tone. > Also note that there is no way to distinguish in-band ringback from > early media from the callee. (The media might arrive before a 200.) So > if you were > to allow local ringback to override in-band ringback you could clip > audio from > the callee. The media in our case comes from an application server. Thanks for the quite elaborated answer. BR Franz _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
