>>> On 5/20/2009 at 9:55 AM, in message <c5d7630b5adb7744adfebc167bc04a43647...@lonsbs-onrel01.onrelay.local>, "Gabor Paller" <gabor.pal...@onrelay.com> wrote: > Hi, > > I have a seemingly very simple configuration with SipX 4.0 (sipxbridge > activated), an authenticated SIP trunk and a firewall. IP addresses are > the following (not actual addresses): > 1.2.3.4: IP address of the SipX box, also hosting sipxbridge > 1.2.3.40: A SIP endpoint on the internal network, same domain as > 1.2.3.4. > 10.20.30.40: Public IP address of the SipX box, on the other side of the > firewall. > 40.30.20.10: Address of the SIP trunk > > Now there is an INVITE initiated at 1.2.3.40, going through 1.2.3.4 and > to the trunk. Excerpt from the sipxbridge log (debug, message log at the > end of the mail). The c= line in SDP is correctly set to 1.2.3.40. > > > Sipxbridge bridges the request. The outgoing request (message log at the > end of the mail), however, has c= line with the address of 1.2.3.4. What > is even more surprising is that the call works but in some scenarios, I > have problems with the media. Shouldn't c= be 10.20.30.40? How to > configure sipxbridge so that the public IP address is sent in SDP? I am > not aware of any additional SBCs, just the firewall. > > Regards, > Gabor > >>>>>>>>>>>>>>>>>>>>> incoming message >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > sipXBridge:"Read SIP Message :\n----Remote Host:1.2.3.4---- Port: > 5060----\nINVITE sip:01512331...@sip.q-ip.net SIP/2.0\r\nRoute: > <sip:1.2.3.4:5090;lr>\r\nRecord-Route: > <sip:1.2.3.4:5060;lr;sipXecs-rs=%2Aauth%7E.%2Afrom%7ENmI0ZTFjNTY%60%2197 > b97e73b91bb5a6d2fa37689c4c2a72>\r\nVia: SIP/2.0/TCP > 1.2.3.4;branch=z9hG4bK-sipXecs-0013a5d12f3649a46f2a9ddc03e918c40921;rpor > t=5060\r\nVia: SIP/2.0/TCP > 1.2.3.4;branch=z9hG4bK-sipXecs-00102668420f28f46b483720ca912a943f2d~efa4 > 02b241fc107a2307c5b592dd1d72\r\nVia: SIP/2.0/TCP > 1.2.3.4;branch=z9hG4bK-sipXecs-000b46f39bac4bb459e70ee0e7697e41a234~1d96 > 174de3581a625f637269548298f2\r\nVia: SIP/2.0/UDP > 1.2.3.40:61728;branch=z9hG4bK-d87543-da33351f846b3f46-1--d87543-;rport=6 > 1728\r\nMax-Forwards: 16\r\nContact: > <sip:2...@1.2.3.40:61728;x-sipX-nonat>\r\nTo: "001512331119" > <sip:001512331...@1.2.3.4>\r\nFrom: "Test" > <sip:2...@1.2.3.4>;tag=6b4e1c56\r\nCall-ID: > YjMxMGNiYTNiZGRhN2UzZTE0OTRmM2U5ZDZhZjczYzM.\r\nCSeq: 2 INVITE\r\nAllow: > INVITE,ACK,CANCEL,OPTIONS,BYE,REFER,NOTIFY,MESSAGE,SUBSCRIBE,INFO\r\nCon > tent-Type: application/sdp\r\nProxy-Authorization: Digest > username="219",realm="mbx.eltaxdom.local",nonce="d3ac98ec7e3ffe62080ea87 > da0403cfb4a13cf15",uri="sip:001512331...@1.2.3.4 > ",response="094de234e1de6b324e03d740dce7f521",algorithm=MD5\r\nUser-Agen > t: X-Lite release 1011s stamp 41150\r\nDate: Wed, 20 May 2009 09:36:21 > GMT\r\nContent-Length: 420\r\n\r\nv=0\r\no=- 7 2 IN IP4 > 1.2.3.40\r\ns=CounterPath X-Lite 3.0\r\nc=IN IP4 1.2.3.40\r\nt=0 > 0\r\nm=audio 59350 RTP/AVP 107 119 100 106 0 105 98 8 101\r\na=alt:1 1 : > gUuKYeG5 VgrEikMQ 1.2.3.40 59350\r\na=fmtp:101 0-15\r\na=rtpmap:107 > BV32/16000\r\na=rtpmap:119 BV32-FEC/16000\r\na=rtpmap:100 > SPEEX/16000\r\na=rtpmap:106 SPEEX-FEC/16000\r\na=rtpmap:105 > SPEEX-FEC/8000\r\na=rtpmap:98 iLBC/8000\r\na=rtpmap:101 > telephone-event/8000\r\na=sendrecv\r\n > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> outgoing message >>>>>>>>>>>>>>>>>>>>>>>> > > sipXBridge:"Sent SIP Message :\n----Remote Host:40.30.20.10---- Port: > 5060----\nINVITE sip:01512331...@sip.q-ip.net;user=phone;transport=udp > SIP/2.0\r\nCall-ID: > YjMxMGNiYTNiZGRhN2UzZTE0OTRmM2U5ZDZhZjczYzM..0\r\nCSeq: 1 > INVITE\r\nFrom: "Test" <sip:2...@1.2.3.4>;tag=8893503391530831099\r\nTo: > <sip:01512331...@sip.q-ip.net;user=phone>\r\nVia: SIP/2.0/UDP > 10.20.30.40:5080;branch=z9hG4bK4c7adbca429b78667064e9eb33ab694d\r\nMax-F > orwards: 70\r\nUser-Agent: sipXecs/3.11.12 sipXecs/sipxbridge > (Linux)\r\nP-Asserted-Identity: > <sip:6500002...@sip.q-ip.net>\r\nContact: > <sip:6500002...@10.20.30.40:5080;transport=udp>\r\nRoute: > <sip:sip.q-ip.net:5060;lr>\r\nAllow: > INVITE,BYE,ACK,CANCEL,OPTIONS,PRACK\r\nSupported: > 100rel\r\nContent-Type: application/sdp\r\nContent-Length: > 449\r\n\r\nv=0\r\no=sipxbridge 5376573537938969642 1 IN IP4 > 1.2.3.4\r\ns=CounterPath X-Lite 3.0\r\nc=IN IP4 1.2.3.4\r\nt=0 > 0\r\nm=audio 30000 RTP/AVP 107 119 100 106 0 105 98 8 101\r\na=alt:1 1 : > gUuKYeG5 VgrEikMQ 1.2.3.40 59350\r\na=fmtp:101 0-15\r\na=rtpmap:107 > BV32/16000\r\na=rtpmap:119 BV32-FEC/16000\r\na=rtpmap:100 > SPEEX/16000\r\na=rtpmap:106 SPEEX-FEC/16000\r\na=rtpmap:105 > SPEEX-FEC/8000\r\na=rtpmap:98 iLBC/8000\r\na=rtpmap:101 > telephone-event/8000\r\na=sendrecv\r\n > _______________________________________________ > sipx-users mailing list > sipx-users@list.sipfoundry.org > List Archive: http://list.sipfoundry.org/archive/sipx-users > Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users >
Do you have remote nat traversal tunred on or just server behind NAT? If you have both on, you should have your ITSP send to a port other than 5060 (like 5080). Xlite looks weirrd to me here. xlite should have ulaw and alaw as the first codecs being offered, and I dont see then in the map from xlite. if xlite is on the same subnet as sipx, topology should be 'use local address', no ICE, STUN shoud be discover server (essentially unused). I might be wrong on this, but this is only what I think I see. Typically I would enable only ulaw and alaw codecs with sipx. Anyone else see it differently than what I see? _______________________________________________ sipx-users mailing list sipx-users@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipx-users Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users
