" You may want to play with that media keepalive setting ( make it replay-last-sent-packet ) as your ITSP seems to do HNC."
Many thanks, Ranga, this was the solution for this HNC issue. For the record, the replay-last-sent-packet setting is at Devices/Gateways/<trunk name>/ITSP account/ Method to use for RTP keepalive. Regards, Gabor -----Original Message----- From: M. Ranganathan [mailto:[email protected]] Sent: 20 May 2009 15:55 To: Gabor Paller Cc: Tony Graziano; [email protected] Subject: Re: [sipx-users] sipXbridge+firewall On Wed, May 20, 2009 at 10:12 AM, Gabor Paller <[email protected]> wrote: > " remote nat traversal" > > What do you mean by remote NAT traversal? I mean, I have a good > knowledge of NAT traversal techniques, I just want to make sure that we > use the same terminology. :-) > > Why is the c= in the outgoing SDP set to 1.2.3.4? That address is not > visible from the 40.30.20.10 SIP address trunk address. I can't imagine > how the media gets through. There are two flavors of iTSPs one does "Hosted NAT Compensation" and another does not. HNC is the less troublesome of the two to configure. HNC is kicked off by looking at the addresses in your signaling to the iTSP. If it sees private addresses there, it ignores the contact information and via in the sip signaling and ignores the address of the SDP C line. It assumes that you are behind a symmetric NAT and uses the remote address of the inbound signaling to infer these addresses. When the first RTP packet comes in ( this is where it gets limited -- your RTP follows your signaling path which is contrary to the SIP religion ), it looks at the remote address of that inbound RTP packet to determine where to send outbound media -- i.e. it infers the c= line of the SDP. Hence your usage of private address there is not affecting it. It will not transmit in other words, unless it sees an inbound packet. Now life gets interesting when you deal with call forwarding. You can see that a deadlock situation arises. In the call forwarding on no response case, there is no RTP packet originated from the remote end until the party to whom the call is forwarded picks up. If that party is a PSTN phone on the same ITSP , a deadlock arises. This explains why sipx always relays media and also has a media keepalive. You may want to play with that media keepalive setting ( make it replay-last-sent-packet ) as your ITSP seems to do HNC. Regards Ranga > > Regards, > Gabor > > -----Original Message----- > From: Tony Graziano [mailto:[email protected]] > Sent: 20 May 2009 15:07 > To: [email protected]; Gabor Paller > Subject: Re: [sipx-users] sipXbridge+firewall > >>>> On 5/20/2009 at 9:55 AM, in message > <c5d7630b5adb7744adfebc167bc04a43647...@lonsbs-onrel01.onrelay.local>, > "Gabor > Paller" <[email protected]> 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:[email protected] 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:[email protected]:61728;x-sipX-nonat>\r\nTo: "001512331119" >> <sip:[email protected]>\r\nFrom: "Test" >> <sip:[email protected]>;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:[email protected] >> > ",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:[email protected];user=phone;transport=udp > >> SIP/2.0\r\nCall-ID: >> YjMxMGNiYTNiZGRhN2UzZTE0OTRmM2U5ZDZhZjczYzM..0\r\nCSeq: 1 >> INVITE\r\nFrom: "Test" > <sip:[email protected]>;tag=8893503391530831099\r\nTo: >> <sip:[email protected];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:[email protected]>\r\nContact: >> <sip:[email protected]: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 >> [email protected] >> 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 > [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-users > Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users > -- M. Ranganathan _______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users
