> What you can still to is setting the port on the phone to port 5060 - just
> as a little dirty workaround until there is a better solution available.
Would that be the sip_port settings entry? It is documented as "for internal
use", though I suppose it shouldn't cause any harm if I change it.
Incidentally, this problem may have been addressed in the development
sources. Perhaps I should obtain and build an svn checkout.
From the svn log:
Revision 77616
Modified Sat Jul 28 07:44:16 2007 UTC (3 months ago) by rizzo
File length: 681368 byte(s)
Diff to previous 77538
make use of received= and rport= fields in sip replies.
In a nutshell, these fields are used to tell a sip entity
the address and port its request came from, and are extremely
useful in the presence of NATs, especially with symmetric NATs
where STUN is totally ineffective.
This patch stores the address and port in the 'ourip' field of
the dialog descriptor, so they can be reused in subsequent transactions.
As it is, it works well for things like REGISTER requiring authentication,
because the second REGISTER request (with auth credentials) will carry
the correct address. Maybe it can also be useful, in case of an address
change, to do one or both of the following:
+ propagate the new address to the parent user/peer descriptor so that new
dialogs will use the correct address from the beginning.
This is trivial to implement, I am just waiting for feedback on this.
+ re-issue a request in case of an address change. This a lot less trivial,
maybe unnecessary, and probably covered by the previous item.
I would seriously consider this patch for addition to 1.4 and 1.2.
The code is very little intrusive, and it would solve in a correct
way the nat traversal problems for which externip/externaddr/stunaddr
are only a partial and expensive workaround.
__________________________________________________________________
_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
No comments:
Post a Comment