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

Jeroen van Bemmel <[email protected]> Wed, 16 Jan 2008 20:39:25 +0100
Newsgroups gmane.comp.voip.nist-sip
Message-ID <[email protected]>
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(SipProviderImpl.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
>
>