Hi

First flow looks fine to play early media ,but 2nd flow should not have
early media from remote as SDP answer not came in 180.
But if RTP coming without having proper SDP answer with P-EarlyMedia header
, means incoming media is not authorized.

Still there is informational RFC 3960 which gives suggestion to play early
media if RTP coming from remote.

   With this in mind, a UAC should develop its local policy regarding
   local ringing generation.  For example, a POTS ("Plain Old Telephone
   Service")-like SIP User Agent (UA) could implement the following
   local policy:

      1. Unless a 180 (Ringing) response is received, never generate
         local ringing.

      2. If a 180 (Ringing) has been received but there are no incoming
         media packets, generate local ringing.

      3. If a 180 (Ringing) has been received and there are incoming
         media packets, play them and do not generate local ringing.

So it depends on UA local policy to decode incoming RTP and play it OR just
play local ringback tone.

Decoding may fail if UAC side decoder is not started for same codec which
UAS has used to encode ,
as offer answer negotiation not completed to finalize common codec .

Although 3gpp recommends to play media only if early media is authorized
and media gateways should
follow Gateway model(PEM) .


Thanks & Regards
Ankur Bansal

On Sat, Dec 10, 2016 at 6:43 PM, Zuñiga, Guillermo <
guillermo.zun...@cwpanama.com> wrote:

> Hi Fellows,
>
> I am having  the following issue with one device that is having one way
> audio.
>
> The Calls is from a SIP UA to PSTN site, when the call is stablishing the
> only way I have audio in both ways is when in the following case:
>
> UA                                    SBC/GW->PSTN
> INVITE----------------->
> TRYING<----------------
> 183 W/SDP<------------
> RTP(RBT)<---------------
> RTP----------------------->(LIKE SILENCE FROM UA)
> 200OK<------------------
> ACK------------------->
> RTP<------------------------>RTP IN BOTH WAYS
>
> What I am seeing in the traces it that UA is just decode the RTP when
> trigger the RTP silent after receive the 183 sdp with the RBT.
> When UA receive a 180 WSDP and RBT is not triggering back the RTP packets
> and can not hear RTP that coming from  the PSTN site. Important RPT are
> arriving to the UA according with my SBC access site.
> Could you help me with this behavior of the UA is correct?
>
>
> Other thing I am try to looking  for is that UA is failing with one way
> audio too is with the following scenarios.
>
> UA                                   SBC/GW->PSTN
> INVITE----------------->
> TRYING<----------------
> 180 WITHOUT/SDP<------------
> RTP(RBT)<---------------
> 200OK<------------------
> ACK------------------->
> RTP<------------------------>RTP IN BOTH WAYS
>
>
> According with him, this could be related cause the GW is sending a
> 180WITHOUT SDP, that indicate that GW should not send early media or RBT,
> cause UA should play local ring back tone correct?, but RTP are coming from
> the GW cause I think PSTN is sending RBT.
> According with my investigation if this happened UA should discard this
> RTP after the 180?
> What should be the behavior of the UA in this case?
> -hear the RBT from the GW, even  if it is receiving a 180 without SDP?
> -play its own Ring back Tone?
> -what could be happened if both Ring Back Tone are trying to be played?
> -this could be cause that UA can not decode the RTP are arriving correctly
> to it?
>
> -I was reading the RFC3398 to try to find where say the UA should discard
> the RBT if it receive a 180 WITHOUT SDP, but I am not get this, if you can
> help me with more tips will be great.
>
> Regards
> Guillermo
>
>
>
>
>
>
>
>
>
> Guillermo Zuniga
> Especialista de Soporte Técnico
> Gerencia de Soporte Técnico
>
> Tel:    +507 263-6671
> Cel:    +507 6670-0481
> Fax:    +507 265-3295
> Email:  guillermo.zun...@cwpanama.com
>
> [cid:image25b485.JPG@c7ed07b0.438c63b6]<http://www.cwpanama.com>
>
> <http://www.cwpanama.com>
>
> <http://www.cwpanama.com>
>
> <http://play.google.com/store/apps/details?id=com.croem.web.cwp>
>
> <http://www.facebook.com/masmovilpanama>
>
> <http://www.cwpanama.com>
>
> <http://bit.ly/MasMovil>
>
> <http://www.facebook.com/masmovilpanama>
>
> <http://www.facebook.com/masmovilpanama>
>
>
>
> <https://play.google.com/store/apps/details?id=com.croem.web.cwp>
>
> <http://www.cwpanama.com>
>
> [cid:image61c8b1.PNG@6c555a2c.47b640b8]<http://www.ereselmaster.com>
>
>
>
> El contenido de este correo es confidencial y puede ser objeto de acciones
> legales.  Es dirigido solo para el o los destinatarios(s) nombrados
> anteriormente. Si no es mencionado como destinatario, no debe leer, copiar,
> revelar, reenviar o utilizar el contenido de este mensaje. Si ha recibido
> este correo por error, por favor notifique al remitente y proceda a borrar
> el mensaje y archivos adjuntos sin conservar copias.
>
> The information contained in this e-mail is confidential and may also be
> subject to legal privilege.  It is intended only for the recipient(s) named
> above.  If you are not named as a recipient, you must not read, copy,
> disclose, forward or otherwise use the information contained in this
> email.  If you have received this e-mail in error, please notify the sender
> immediately by reply e-mail and delete the message and any attachments
> without retaining 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

Reply via email to