On 12/09/2014 12:42 PM, Mark Michelson wrote:
<snip>
5. If we are responding to a media_offer, and there is either no
configured media_address on the endpoint or the media_address is of a
different IP address family than the offerer's media address for the
given stream, and the signaling address for the call is of the same
address family as the offerer's media address for the given stream,
then we will bind the RTP stream to the signaling address for the call.
This is proving to be more difficult than I had anticipated when the
signaling address is itself a wildcard IP address. Let's revisit the
situation that the original e-mail was about, but change the
configuration to have a wildcard address for the transport. Let's say I
have the following configuration:
[my_transport]
type = transport
protocol = udp
bind = 0.0.0.0:5060
[sipp]
type = endpoint
media_address = 127.0.0.1
Let's walk through what happens here.
When creating a UDP transport in PJSIP and binding a wildcard IP address
to it, PJSIP does some immediate magic to determine a single published
address for the transport. In my case, PJSIP always chooses to publish
the address 10.24.20.249.
SIPp places a call into Asterisk, sending its INVITE request from
127.0.0.2:5061 to 127.0.0.1:5060.
The INVITE arrives into Asterisk, and Asterisk needs to create a new UAS
dialog. Asterisk determines the local contact URI for the dialog based
on the IP address of the transport on which the INVITE arrived. In this
case, the transport on which the INVITE arrived is the PJSIP UDP
transport we created based on the my_transport settings. This means
that, due to the previous determination of a published address on the
transport, Asterisk tells the UAS dialog to use the contact URI
sip:10.24.20.249:5060.
Now comes the time when we need to determine what IP address to bind RTP
to. At the point that we are handling an incoming SDP stream, the best
we can do to determine a signaling address is to examine the local
contact URI of the dialog. After all, that's where SIP traffic is to be
sent, so it makes sense that that would be the signaling address, right?
So going by the cited rule, we would bind the RTP stream to 10.24.20.249.
The problem now is that because of the media_address option, the 200 OK
Asterisk sends to SIPp will contain SDP instructing SIPp to send RTP
traffic to 127.0.0.1, but Asterisk is listening for media on
10.24.20.249. This will result in one-way audio since Asterisk will not
be reading the audio sent by SIPp.
With that media_address, you'd have a one-way audio problem, but what if
you didn't have a media_address specified at all? Then you might have
two-way audio, but you'd have a less-than-ideal situation where you are
communicating across different interfaces. In a test environment, this
doesn't matter so much, but in a production environment, this could be
very bad. And if anything, this is a step backwards compared to previous
behavior.
So why can't I get a signaling address other than the dialog's contact
address? The simple reason is that nothing better is actually available
to me. I can't see what the transport is actually bound to because I
don't have access to the transport at this point [1]. I can't see what
address the incoming INVITE was sent to because that isn't stored
anywhere either.
"But Mark," you may say, "I just set this up and when I did, the 200 OK
that Asterisk sends to SIPp has 127.0.0.2 in the Contact header, not my
externally-facing IP address!" This is because the res_pjsip_multihomed
module modifies the Contact header because the transport in use on the
outbound packet was bound to a wildcard address. As I said before, I
don't have access to the transport when handling the incoming SDP offer,
so I can't do anything similar. Plus, even if I did, it would have the
exact same effect as if I had bound RTP to a wildcard address, which was
what I was trying to avoid in the first place!
So because I lack the following information in the res_pjsip_sdp_rtp code:
* The transport in use for the dialog
* The IP address on which the INVITE was received
I can't make a reasonable assumption for an address to bind on other
than a wildcard address. Unless someone can point me to something I'm
missing that would allow for me to bind to a more appropriate address
than a wildcard, please let me know.
[1] pjsip_dialog has a pjsip_tpselector on it, but its type is
PJSIP_TPSELECTOR_NONE at the point where we are handling the incoming
SDP offer.
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
