[asterisk-dev] Asterisk-11 Trying to get Channel Name related to RTP/SIP Private

[Matthew Jordan]

On Fri, Oct 30, 2015 at 11:46 AM, Mark Murawski <markm-lists at intellasoft.net
> wrote:

> Howdy All,
>
> I'm working on trying to output the channel related to an rtp stream.  I
> found this line in ast_rtp_read()/res_rtp_asterisk.c and this pointed me to
> a starting position:
>
> ast_verb(4, "%p -- Probation passed - setting RTP source address to %s\n",
> rtp, ast_sockaddr_stringify(&addr))
>
> I figured to tried this:
> {
>   struct ast_channel *chan = ast_rtp_instance_get_chan(instance);
>   ast_verb(4, "<%s> %p -- Probation passed - setting RTP source address to
> %s\n", chan ? ast_channel_name(chan) : "NoChannel", rtp,
> ast_sockaddr_stringify(&addr));
> }
>
> Sometimes this works, and sometimes this doesn't and I'm not sure why.
>
> If media is setup "slowly", i'll get this:
> > [2015-10-30 10:58:04.855] > [C-00000000] <NoChannel> 0xb4a94618 --
> Probation passed - setting RTP source address to 192.168.5.125:2222
>
> It appears that if the media is setup "fast" I'll get this output:
>        > [2015-10-30 10:28:54.846]        > [C-0000000a]
> <SIP/6850-00000013> 0x89ffda8 -- Probation passed - setting RTP source
> address to 192.168.5.123:2224
>        > [2015-10-30 10:28:54.846]        > [C-0000000a]
> <SIP/6860-00000015> 0x89ec480 -- Probation passed - setting RTP source
> address to 192.168.5.129:2250
>
> How can I reliably get the channel name here (or pick a better spot to get
> the channel name related to rtp ports)?
>

First, you could just upgrade to 13, which has this feature already.

If that's not an option, then you have to do something along the following
lines:

(1) Inject the channel name into the RTP engine/instance when the RTP
instance is first created. It generally isn't safe or reliable to go the
other direction. While packet to packet bridging does that, it does so in a
very particular way, that I would not recommend doing in Asterisk 11 on
every RTCP read (or at other times).

(2) Whenever a masquerade occurs, where the SIP pvt gets moved from one
channel to another, re-update the RTP instance with the new channel name.
Note: this is why you should just move to Asterisk 13, as a masquerade
generally does not occur where the new channel owning the SIP pvt is
expected to survive for long. (There are exceptions, but FAR fewer than
what you'll find in Asterisk 11.)

Any other approach is liable to not work. You may want to look at the
original patch Jaco Kroon had for this feature on the issue tracker:

https://issues.asterisk.org/jira/browse/ASTERISK-20754

If you read the comments however, you'll note again why you should just do
this in Asterisk 13+, as you're liable to run into a lot of corner cases
where the channel is not around when you think it should be in 11.

-- 
Matthew Jordan
Digium, Inc. | Director of Technology
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20151030/2592d552/attachment.html>