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
