[help needed] SDP

Hi! I have a question to ask regarding of SDP.

How does the caller and callee know each other’s IP address to send RTP directly after session has been established.

By example:

Alice Asterisk Bob
INVITE |
-----------> |
| INVITE
| ------------>
| 200 OK
| <------------
200 OK |
<----------- |
ACK |
------------> |
| ACK
| -------------->
RTP
<------------------------------------->

When Alice wants to call Bob, only asterisk knows the IP address of Alice and Bob. After the session has been established, how Alice and Bob know where to send RTP? I thought it should be included in SDP. However, I can’t find any information about the other party’s IP. How should it work?

Thanks for it!

asterisk handles that, it takes the media IPs from each side of the convo and reinvites them to each other.
If asterisk is behind a NAT you will need to set externip= and localnet= as well as forward udp port 5060 and (whatever range you have set in rtp.conf). You also need to use nat=yes / nat=no as needed.

If the remote end is behind a NAT, it will need STUN to discover its external IP.

Generally reinvites are not NAT-friendly so it is best to set canreinvite=no for all SIP peers outside the NAT that * is on, or define canreinvite=no in general (sip.conf) to turn off reinvites entirely.

Thanks for your kindly reply! : )

So simply say, RTP package will be sent to Asterisk and Asterisk will forward them to the other party. Is that right? Why I can’t see it from ethereal when I tested it with windows messenger? From ethereal, it seems the RTP packages are sending directly to the other party.

In SDP, what does rtpmap and fmtp do? Especiall what does the following do ?
rtpmap:101 telephone-event
fmtp:101 0-16

Thanks!

it depends on if you are using reinvites.

If not, then both legs of the call (caller to , * to callee) are set up on their own with their own SDP and the media path is caller--callee.

if you are using reinvites, then once the call is setup * looks at the SDPs of both legs and sends out new SDPs to each side, telling them to send RTP media directly to each other. This can save bandwidth on the * side but creates havoc with NAT firewalls. Thus, canreinvite=no will disable this behavior.

yeah. You are right. I’m using reinvite in sip.conf. But when I disable it, which meas when I set canreinvite=no, windows messenger can’t talk with each other. If I set canreinvite=yes, it’s working for windows messenger. Any configuration I need do to make caller-*-callee work? I’m using the default rtp.conf of *.

Thanks!

is the problem limited to windows messenger? ie do other IP phones work? also are the RTP ports (set them in rtp.conf) firewalled?

I don’t know. I use windows messenger to test it. Actually I use MjSip to do my implementation. None of them works when I set canreinvite=no. But it works for windowns messenger when I set canreinvite=yes. I don’t know how windows messenger handles it since it’s black box to me. For MjSip (open source), it sends RTP package to * when canreinvite=yes. Caller and callee can’t hear each other with MjSip.

Thanks for your repond!

RTP ports are not firewalled

I forgot to mention that.

For Windows Messenger, with canreinvite=yes, in RTP session, caller – callee (observed by etheral). Communication sets up.

For MjSip, with canreinvite=yes, in RTP session, caller -* / callee - * (observed by ethereal). Communication fails.

set canreinvite=no, and then do rtp debug with *. Do you get two way rtp communication when a phone calls *? what about when phones call each other?

Are you very, very sure RTP is not blocked some how? I had nearly the exact same problem a while back and it turned out the default firewall on CentOS was blocking RTP. I had changed the config but not set ports, so some (not all) of my RTP ports were blocked. This gave me a very similar problem.

Try turning off iptables- service iptables stop at the linux command line

Also check NAT settings. You may have to set nat=no…

May I ask how to set RTP ports in rtp.conf?
And how to turn off iptables?

Thanks!

It’s working now. Thanks a lot. It’s the firewall problem. I really appreciate your help. :smile: