Hi Jim,
I have no facts, but a couple of guesses/questions/hints.
When a UAC receives a negative answer (in your case 503), will it proceed the
call and play the sound? Or will it terminate the dialog/transaction?
Is the SDP in the 503 answer existing and correct? Can opensips/rtpproxy add
SDP? Normally it changes an existing SDP.
I would start troubleshooting by sending "183 progress" instead of 503.
If the SDP is correct, I guess it should work.
If SDP is missing or incorrect, you can add an UAS (eg. asterisk and make it
play the anouncement using progress() before playback(file, noanswer)
Good luck.
Kristian Høgh
On Thursday 10 March 2016 06:26:57 Jim DeVito wrote:
> So it seems I have not had any luck getting rtpproxy to play an
> announcement upon receipt of the initial INVITE with SDP.
>
> Here is what I have when processing the initial invite from the client.
>
> rtpproxy_offer("r","");
> rtpproxy_stream2uac("/var/rtpproxy/audio/calling-area-error", "2");
> send_reply("503","No Routes");
>
> rtpproxy debug shows this on the INVITE before any reply is sent to the
> client.
>
> DBUG:get_command:GLOBAL: received command "19394_5 Uc0,101
> [email protected]:5060 66.228.40.119 10148
> as1d2ea467;1"
> INFO:rtpp_command_ul_handle:GLOBAL: new session
> [email protected]:5060, tag as1d2ea467;1
> requested, type strong
> INFO:rtpp_command_ul_handle:[email protected]:5
> 060: new session on a port 37018 created, tag as1d2ea467;1
> INFO:rtpp_command_ul_handle:[email protected]:5
> 060: pre-filling caller's address with 66.228.40.119:10148
> DBUG:rtpc_doreply:GLOBAL: sending reply "37018
> "
> DBUG:get_command:GLOBAL: received command "19394_6 P2
> [email protected]:5060
> /var/rtpproxy/audio/calling-area-error session as1d2ea467;1 "
> INFO:handle_play:[email protected]:5060: 2
> times playing prompt /var/rtpproxy/audio/calling-area-error codec 0
> DBUG:rtpc_doreply:GLOBAL: sending reply "0
>
> Looks like it gets the Address and port from the INVITE SDP and sets
> them just fine. Then it even looks like it is playing the file. But no
> RTP is ever sent to the client and the next line that sends the 503 is
> immediately processed ending the call.
>
> Then rtpproxy will timeout like so.
>
> INFO:process_rtp:[email protected]:5060:
> session timeout
> INFO:remove_session:[email protected]:5060:
> RTP stats: 0 in from callee, 0 in from caller, 0 relayed, 0 dropped
> INFO:remove_session:[email protected]:5060:
> RTCP stats: 0 in from callee, 0 in from caller, 0 relayed, 0 dropped
> INFO:remove_session:[email protected]:5060:
> session on ports 37018/0 is cleaned up
>
> Any insight as to what I may be doing wrong would be a big help.
>
> Thanks!!
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
