RE: Re: nist-sip 1.2 and NAT traversal : issue with ListeningPoint sentby field

Ranga, Jeroen,

Thanks for the info....

I'm not using stun - which I understand as a way to discover the external
NAT IP (mine is a "server" type project, so I can statically configure
things like that).

Jeroen, I assume I am 'allowed' (in the protocol sense) to fixup the From
URI as its just informational?

I'll give it a go without adding my own Via header and see if the LP accepts
that.

cheers

Brian

> -----Original Message-----
> From: Jeroen van Bemmel [mailto:[email protected]]
> Sent: Wednesday, January 16, 2008 8:39 PM
> To: [email protected]
> Cc: Brian Wyld; [email protected]
> Subject: Re: [nist-sip] Re: nist-sip 1.2 and NAT traversal : issue with
> ListeningPoint sentby field
>
>
> Hi Ranga,
>
> One could use STUN to discover the public IP address mapping, and to
> keep the binding alive towards the proxy (see SIP outbound). However, it
> still needs to be communicated to the peer somehow, and absent more
> advanced techniques such as temporary GRUUs, SIP outbound (";ob"
> parameter in Contact) or ICE, the Contact needs to be modified.
>
> In any case, for RTP routing the IP address in the SDP needs to
> be modified
>
> Regards,
> Jeroen
>
> M Ranganathan wrote:
> > Jeroen,
> >
> > If stun is used do you need to do that?
> >
> > Just curious. BTW, you may want to look at the
> > sip-servlets.dev.java.net project (runs on jain-sip given that you
> > have an interest in Servlets and are on that EG).
> >
> > Regards
> >
> > Ranga
> >
> >
> > Jeroen van Bemmel wrote:
> >> Brian,
> >>
> >> There is no need to modify the Via sentby to contain the public IP
> >> address. The receiver will fill in the 'received' parameter on the
> >> Via, and automatically route back via the public router
> >>
> >> From is not needed either, as it is only a logical address
> >>
> >> Only the Contact and SDP need to be modified
> >>
> >> Regards,
> >> Jeroen
> >>
> >> Brian Wyld wrote:
> >>> Hi,
> >>>
> >>> I've been using the NIST SIP stack, and recently updated to the latest
> >>> version (note in passing, great job guys).
> >>>
> >>> However, my code to deal with calls that are outbound thru a NAT'd
> >>> router no
> >>> longer works.... If anyone can explain what I'm doing wrong it'd be
> >>> a great
> >>> help.
> >>>
> >>> Basically, I want to make calls out (send the INVITE) to
> >>> destinations that
> >>> may be either on an 'internal' network, or 'public' ie outside of a
> >>> NATing
> >>> router.
> >>> There is no problem for the INVITE sending (using UDP), as the
> >>> destination
> >>> IP is routable in both cases. My code detects when the destination
> >>> is going
> >>> via NAT, gets the public IP of the router from a config file, and:
> >>>     - adds a Via header accordingly
> >>>     - fixes up the From, Contact etc URIs (change the local IP to
> >>> the external
> >>> IP)
> >>>     - ensures the RTP SDP IP is the external IP
> >>> This all worked fine until I updated to 1.2....
> >>>
> >>> Now, when I send to the public network, I get:
> >>> javax.sip.TransactionUnavailableException: sentBy does not match the
> >>> sentby
> >>> setting of the ListeningPoint 62.212.123.79:5060
> >>>         at
> >>>
> gov.nist.javax.sip.SipProviderImpl.getNewClientTransaction(SipProv
> iderImpl.j
> >>>
> >>> ava:304)
> >>>     ... etc
> >>> My external IP (in the Via, From, Contact etc) is 62.212.123.79 and
> >>> my local
> >>> IP (to which the ListeningPoint is bound) would have been
> 192.168.0.167
> >>> (local server).
> >>>
> >>> So, when I create the ListeningPoint at initialisation of the server
> >>> process, I tried setting the sendby using setSentBy() to  be the
> >>> external
> >>> IP...
> >>>
> >>> Now, it works when I send to an external destination, but not when I
> >>> send to
> >>> an internal one!
> >>>
> >>> Is there a way to stop the ListeningPoint checking its sentby field
> >>> against
> >>> my Via, From etc headers? Or is my basic method (fixing up the headers
> >>> myself) wrong, and I should do it another way? Or do I have to use 2
> >>> SipProvider instances, one for internal calls
> >>> (sentby=192.168.0.167:5060)
> >>> and one for externals (sentby=62.212.123.79:5060)? (this is not my
> >>> preferred
> >>> solution....)
> >>>
> >>> All ideas gratefully received....
> >>>
> >>> Brian
> >>>
> >>> [ Brian Wyld : Eloquant SA    ]
> >>> [ Directeur technique         ]
> >>> [ brian.wyld at eloquant.com  ]
> >>> [ tel: +33 476 77 69 54       ]
> >>> [ mob: +33 609 62 10 87       ]
> >>> [ fax: +33 476 77 40 65       ]
> >>
> >> _______________________________________________
> >> nist-sip mailing list
> >> [email protected]
> >> http://www-x.antd.nist.gov/mailman/listinfo/nist-sip
> >
> >
>
>