[SIPForum-discussion] Re-Invite without SDP, No Audio Issue (closed)

[Harshal Patel]

Hello Abin Matthew/Brian Tate/Tomasz Czyzew/Dale Worley/Ellen Lee,

 

Thank you everyone for the excellent feedback and response you provided for our question. We have a good agreement within our team and we will make the necessary changes. We see that the ACK of Re-INVITE has a valid SDP and we should restart audio session according to the new SDP, this way we will use the new Media IP and Port provided. Now the CSAT audio should be heard to the caller.

 

Please mark this ticket as closed. Following are the response that we received for the reference:

 

TICKET: Re-Invite without SDP (No Audio Issue)

 

RESPONSES FROM FORUM

 

Abin Matthew:

So you are redirecting the caller to another application which plays audio?(Yes) The reinvite should  definitely have the new SDP.

It would actually depend on the call flow. Is the same gateway playing the audio when application changes?(IVR plays the audio) If not then SDP change is not required. Perhaps you need to look into the application, the path defined for the media file and the gateway that plays it.
When Agent enters extension and doesn't hear audio then it indicates an SDP issue. There should be a new INVITE with SDP to setup the new RTP .i.e. Agent hears enter agent I'd.

There should also be a reinvite back to the caller when agent enter the extension to put the caller on hold. Usually a hold music is played so that portion needs to be implemented on the application. When the agent has entered the agent Id, there should be another reinvite with SDP to connect the caller with the new destination.

Brian Tate:

1. no.

2. no.

“the re-INVITE will contain the offer” is “in regards to audio.”

The SIP IVR should respond to the re-INVITE with a non-faliure response (i.e. 1xx or 2xx code), and contain an SDP offer. 

And the SIP IVR should expect the subsequent ACK sent back from the Avaya to contain the SDP answer, based on the offer/answer model detailed in RFC 3264.

 

Tomasz Czyzew:

I am not sure if I understand correctly the call scenario you described, but I think that the UAS should respond with provisional 1xx containing SDP for this session, so none of the above answers is correct.

SDP-less INVITE is sent by UAC to "pull the SDP out of the UAS". In practice SDP-less INVITE is used for third party call control (3PCC) - to establish a call in someone else's behalf.

Please take a look into RFC6337 (3.1.2. INVITE Request without SDP).

Dale R Worley:

The SIP IVR must (in its 200 response to the re-INVITE) send an SDP offer.  This SDP must be a legitimate update of the SDP that it previously sent within the dialog; in particular, media format numbers that have been used previously must not be re-used for different codecs than before.  It should also offer all codecs and media types that it is willing to support (at this time), not just the ones that it is using in the current media session.

 

The peer will send an ACK, which must contain an SDP answer to the SDP offer that the SIP IVR sent in the 200.  At this point, the SIP IVR must reconfigure its media processing to utilize the newly-negotiated media session.

 

Ellen Lee:

Re-Invite is to put caller on/off hold during call transfer. Not hearing the CSAT survey indicates SIP/RTP setup issues between Avaya and IVR.  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.sipforum.org/pipermail/discussion/attachments/20170928/1829b1fd/attachment-0001.html>