On 8/30/15 3:18 PM, Franz Edler wrote:
Dear SIP-ISUP experts,
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?
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).
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.
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.
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.
Thanks,
Paul
I think the interworking implementation should not provide both provisional
responses (180 Ringing and 183 Session Progress) which are somehow
contradicting.
In case of colored ringback tone a single 183 Session Progress should be
used.
The interworking specification (3GPP TS 29.163) does not clarify the
behavior when both flags in an ACM are set.
What do you think?
BR
Franz Edler
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
