Please forgive my ignorance on the subject of SIP, but I am looking
for a solution to the SIP + NAT problem with a slightly twisted use
case that involves establishing connections based not on phone
numbers, but rather on unique ids of computer hosts. I am an
experienced Erlang programmer, which is what drew me to Yxa in the
first place, so making the extensions myself should not be a problem.
However, I would like your opinion on the feasibility before I start

I'd like to use UDIDs or a hash of them in place of phone numbers
because these computers do not have phone numbers. Next, in order to
short-circuit the not-so-rare case that the two computers are behind
the same firewall, I'd like to include the local/private IP addresses
in the INVITE message so that the invitee can notice a peer on an
internal network and avoid routing packets through the firewall
needlessly. Perhaps this is better done once the "call" is established
via a secondary protocol message, but it seems like adding headers is
straight forward in SIP. Am I crazy to think this?

The application is remote login from a client to a host where both
systems sit behind firewalls and know only some agreed-upon public
name such as u...@well-known-domain.net. The incoming proxy and SIP
router are good candidates for connection establishment through the
NATs, with public domain at incomingproxy.well-known-domain.net. One
more question... I noticed that STUN was added to Yxa. Do the STUN
packets and SIP packets come out through the same port of the NAT
(with respect to the internal side of the NAT)? If so, then it seems
this would be a good thing to assist with NAT traversal. If not, then
how do SIP routed messages pass into the NAT of the invitee (from
internet side to private network side) since there would not be an
open port? Or does this require opening of the SIP port (5060?) on the
NAT/firewall of the peer networks?

As I said, I am only a few hours into studying SIP and I apologize if
I'm completely off base here. Please set me in the right direction.

Cheers, Chris

P.S. The Yxa documentation is really fantastic. It's nice to see good
work and well written docs at the same time! Thank you!
Yxa-devel mailing list

Reply via email to