I want two phones to send rtp directly to each other.
but if I set directrtpsetup=yes and directmedia=yes asterisk will send re-INVITES and put itself in the media path. This makes the whole point of directrtpsetup meaningless.
So I set directmedia=no. Now (as expected) asterisk doesn’t re-INVITE the phones. but it’s adding codecs to the SDP. For example Phone A offers PCMU. then asterisk will add all codec capabilities of the peer and send it to Phone B. Adding Codecs is wrong because asterisk cannot transcode since it’s not in the media path.
is this some sort of a bug or am I missing something ?
[quote=“david55”]Asterisk uses directmedia if the conditions allow it. It does not force the conditions to allow directmedia.
Note that there are other reasons besides codec mismatches for why direct media may be rejected (e.g. monitoring, use of DTMF features, etc.)
[/quote]
Even in the testcase in asterisk test suite asterisk is sending re-INVITE’s.
the only missmatch i see is because asterisk adds telephone-event to SDP. But then… why is asterisk adding telephone-event?
[quote=“david55”]If you know that the destination supports the incoming codec, there are channel variables to set that can restrict the codec choice.
[/quote]
I want to setup this in a generic way for different destinations without having asterisk interfere.
And i thought this is what this option is for. That makes your suggestion just to a workaround.
[quote=“david55”]
As far as I know, directrtpsetup is still not considered a production quality feature.[/quote]
So what ? It looks like there is a problem in the way dierectrtpsetup works. And the only way to make it production ready is too find this kind of problems.
What about directmedia ? in what scenario should it be activated (in conjunction with directrtpsetup)? You didn’t say anything about this.
In the testcase of asterisk test suite it’s set to yes. But why is asterisk sending these re-INVITE’s. this is pointless. maybe the testcase is not OK.
There is not enough information to say exactly why you are getting the behaviour you are getting, but:
telephone events means you have specified dtmfmode=rfc2833. That is the best option for most people.
If you want a feature that is not production quality brought up to production quality status, you are welcome to contribute the code to do so. Please remember, though, that chan_sip is a lame duck, given the move to pjsip.
I don’t use directrtpsetup. directmedia, on its own, works if it is safe to use and both peers support it. The initial invite will request media via Asterisk, but there will be a re-invite when the called party answers.
[quote=“david55”]There is not enough information to say exactly why you are getting the behaviour you are getting, but:
telephone events means you have specified dtmfmode=rfc2833. That is the best option for most people.
[/quote]
i am not sure if my english is too bad and I can’t explain myself or if ou aren’t qualified enough.
if you take a look at the testcase in asterisk test suite that I mentioned you will see that asterisk will not add codecs but it add telefone-events. the reason why asterisk doesn’t add codecs is the same reason why it shouldn’t add telefone-event
I am contributing right know while writing in this forum. and i am willing to do more.
But to write a patch at least I have to know how this options is supposed to be setup. I just need a little guidance.
From user perspective it’s not logical to enable both directrtpsetup and directmedia because enabling directmedia will result in asterisk doing re-INVITE’s and this is not what a user wants if he activates directrtpsetup.
But just enabling directrtpsetup will cause asterisk to add codecs to SDP( this doesn’t happen when directmedia is enabled).
So where do i start ?
[quote=“david55”]
I don’t use directrtpsetup. directmedia, on its own, works if it is safe to use and both peers support it. The initial invite will request media via Asterisk, but there will be a re-invite when the called party answers.[/quote]
never doubt it. but it’s not what I want/need.
Unfortunately, you fall halfway between being covered by end user forums and by developer mailing lists… If you want to know what the intended behaviour was (if anyone can remember) you need to ask on the developer mailing list or IRC channel. However, there is a risk that you will be seen as an end user and redirected back here.