>>> On 5/20/2009 at 10:54 AM, in message
<[email protected]>, "M. Ranganathan"
<[email protected]> wrote:
> 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
> >
>
>
If you are using a siptrunk and have it set for "Use public address for call
setup", can it be assumed the HNC is not applicable?
_______________________________________________
sipx-users mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-users
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users
