I'm not certain, but I suspect there is a misunderstanding here.
The presence of SDP in a 1xx response permits the establishment of a
media stream from the UAC to the UAS. It doesn't matter what sort of 18x
it appears in - 180, 183, etc. It really has *nothing* to do with
rendering ringback. Also, while not really part of SIP, it is fairly
common for middle boxes to forbid media toward the UAC until SDP from
the UAS is seen. So there is some incentive for the UAS to send SDP
early to get things ready even if it doesn't intend to send any media to
the UAC immediately.
A 183 (with or without SDP) indicates that the UAS is aware of the call,
but otherwise contains no sense of the state of the UAS. A 180 indicates
that the UAS is being alerted. A 181 or 182 indicate other things about
the state of call or the UAS.
The UAC may, according to its policy or design, wish to inform the
caller regarding what it knows about the state of the call or UAS.
Locally generating and rendering audio to the caller is one common way
of accomplishing this. If done this way, there is then a potential
conflict between rendering this locally generated audio and rendering
audio that is received from the callee. A typical strategy here is to
only render locally generated audio when there is no renderable audio
being received from the callee.
This is all local policy. If you have some other way (e.g. a screen, or
vibrator) to render the status of the call then you may be able to do
that even when rendering received audio.
The policy choices made here can be important to satisfying the customer
of your product, even though they are not issues of standards compliance.
In the case at hand in this thread, IMO it is the responsibility of the
UAC to do the right thing. I haven't heard anything that suggests to me
that the UAS has done anything wrong.
Thanks,
Paul
On 9/24/16 3:01 AM, Md Faruk Apel Chowdhury wrote:
I would like share some experience on the reported issue. As you mentioned
that Volte users sending 183 SDP. So I suppose it is not related to ring back
tone for CPE user since it is only intimation of session progress for CPE or
playing tone from Volte user if there is any early media.
In Other case, Volte user may need to send 183 SDP if there is any pre-
Alerting SRVCC implentation is required in the network. In this case ring back
tone to CPE also not required.
Local ring back tone to CPE only seems to be related to 180.
If the Volte user send 180 SDP in that case it may be issue for the CPE unable
to provide ring back tone to CPE user since most of the CPE configured ring
back tone only 180 w/o SDP.
Again Volte user may need to send 180 SDP if there is requirement for Alerting
SRVCC implementation in the Network.
If Alerting SRVCC is required, Volte user need to send 180 SDP for bearer
setup during ringing to initiate HO. In that case CPE must be modified to
accept 180with SDP to provide local ring back tone instead of currently
configured local Ring back tone 180 w/o SDP.
Otherwise as a whole, without Alerting / pre-alerting SRVCC , Volte user can
send 180 Without SDP to tell CPE to play ring back tone locally.
Thanks
Sent from my BlackBerry 10 smartphone.
Original Message
From: Dale R. Worley
Sent: Friday, 23 September 2016 22:38
To: Tarun Gupta
Cc: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] No RBT Fixed IMS CPE's
Tarun Gupta <tarun.gu...@ericsson.com> writes:
It has been observed whilst testing our WiFi/VoLTE solution that when
a Fixed IMS service (such as Broadband voice or SIP Trunking) CPE
calls one of our WiFi/VoLTE subs, they do not hear any ring back tone
as call setup progresses. It transpires that this is because our VoLTE
UE's always reliably send an SDP in the 183 Session Progress which
means that the Fixed IMS service CPE's sit there waiting for the
remote endpoint to provide early media ring back tone which of course
will never come from the VoLTE UE's.
Has anyone experienced this in their deployments and if yes, what
solutions were put in place to fix this? (for example network provided
RBT? removing preconditions?)
I would suggest adjusting the VoLTE UE's to not send SDP (establish a
session) until they are prepared to send media, either ring-back tone or
user media. Otherwise the CPE has to test the provided media to see if
it is silent.
Dale
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
________________________________
The content of this email together with any attachments, statements and
opinions expressed herein contains information that is private and confidential
are intended for the named addressee(s) only. If you are not the addressee of
this email you may not copy, forward, disclose or otherwise use it or any part
of it in any form whatsoever. If you have received this message in error please
notify postmas...@etisalat.ae by email immediately and delete the message
without making any copies.
_______________________________________________
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
