[Home]

Summary:ASTERISK-02885: chan_mgcp does not send correct ip in sdp until reloaded
Reporter:nording (nording)Labels:
Date Opened:2004-11-24 15:40:33.000-0600Date Closed:2005-04-05 04:12:46
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:chan_mgcp sends incorrect "IN IP4 0.0.0.0" in CRCX command while establishing channel in "bindaddr" option in mgcp.conf is set.
However issuing "mgcp reload" command from CLI completely resolves this bug until next asterisk coldstart.
Comments:By: nording (nording) 2004-11-26 10:16:58.000-0600

note: reverse applying this patch:
http://bugs.digium.com/file_download.php?file_id=3101&type=bug
resolves this bug
By: Mark Spencer (markster) 2004-12-01 00:41:43.000-0600

what is your bindaddr set to?
By: nording (nording) 2004-12-01 07:28:27.000-0600

bindaddr in mgcp.conf is set to = xxx.xxx.xxx.64, while primary system ip is xxx.xxx.xxx.14 and by defaut rtp binds to last.
And one more note: unsetting bindaddr in mgcp.conf (or setting it to 0.0.0.0) also resolves this bug.
By: Olle Johansson (oej) 2004-12-13 02:05:04.000-0600

Any updates?

---housekeeping
By: Mark Spencer (markster) 2004-12-26 17:59:03.000-0600

Can you try latest CVS, too?
By: alric (alric) 2005-01-04 18:55:23.000-0600

Have you had a chance to try latest CVS, if so were there any changes?
By: nording (nording) 2005-01-05 14:26:34.000-0600

Sorry for the delay. Yes, I have tried latest CVS (CVS-HEAD-01/05/05-10:48:59) with the following results:

Asterisk issues CRCX with "c=IN IP4 xxx.xxx.xxx.14" (main system IP, not the one, which is set to be bindaddr in mgcp.conf), while listening on correct IP. This prevents sound to thavel from mgcp device to asterisk (sound from asterisk to mgcp device travels well).

And a couple of strange things is observed by the way:
1) synchronously with the correct RTP socket binding Asterisk creates one more UDP binging with IP 0.0.0.0 and port greather by one (i don't confuse it with outbound chan_sip's binding or something else - it is created almost synchronously with the correct chan_mgcp one - shortly after L/hd event)
2) "RQNT" is issued in a triple after every "NTFY D/x"

debug transcript with comments, that illustrating mentioned is placed here:
http://nording.ru/asterisk/bug0002937_note1.txt

edited on: 01-05-05 17:08
By: Andrey S Pankov (casper) 2005-01-06 08:54:04.000-0600

You need to look through add_sdp function in chan_mgcp.c and add debug output there to see where we set dest.sin_addr value and why it is set this way. As I know there are still problems even in SIP channel on multihomed systems.

It would be more helpful if you include full debug output, not stripped... Thanks.

Other thing here... Are you sure everything is set up correctly? Could you show us "ifconfig", "route -n", "ip ro get x.x.x.26" (if available) output?

edited on: 01-06-05 09:01
By: nording (nording) 2005-01-08 13:33:19.000-0600

Shown debug output is full (all, that "ngrep -W byline -d eth0.16 '' port 2427" shows)

Yes, i am sure the setup is correct.

$ ip addr show
1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue
   link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
   inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
   inet xxx.xxx.xxx.64/32 scope global lo
      valid_lft forever preferred_lft forever
(cut)
17: eth0.16: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue
   link/ether 00:0c:f1:e8:9b:be brd ff:ff:ff:ff:ff:ff
   inet xxx.xxx.xxx.14/27 brd xxx.xxx.xxx.31 scope global eth0.16
      valid_lft forever preferred_lft forever
(cut)

$ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
xxx.xxx.xxx.0   0.0.0.0         255.255.255.224 U     0      0        0 eth0.16
(cut)
0.0.0.0         xxx.xxx.xxx.1   0.0.0.0         UG    0      0        0 eth0.16

$ ip ro get xxx.xxx.xxx.26
xxx.xxx.xxx.26 dev eth0.16  src xxx.xxx.xxx.14
   cache  mtu 1500 advmss 1460

device is quite reacheable (it's cisco ata186 and 70ms delay is okay for it):

$ ping -c 1 xxx.xxx.xxx.26
PING xxx.xxx.xxx.26 (xxx.xxx.xxx.26) 56(84) bytes of data.
64 bytes from xxx.xxx.xxx.26: icmp_seq=0 ttl=250 time=70.2 ms

--- xxx.xxx.xxx.26 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 70.201/70.201/70.201/0.000 ms, pipe 2

Since, I don't think this is multihomed- or routing- relatad problems.

I'll try to get more debug around add_sdp in chan_mgcp.c
By: Andrey S Pankov (casper) 2005-01-18 09:09:17.000-0600

Any updates?
By: Mark Spencer (markster) 2005-02-04 00:22:14.000-0600

I cannot duplicate this problem.  Can you please attach your mgcp.conf file?  Do you see the problem when you go off hook with your MGCP device or only when you call it?
By: Mark Spencer (markster) 2005-03-08 23:58:05.000-0600

Unable to duplicate and no response from bug placer.