El Martes, 17 de Noviembre de 2009, Brez Borland escribió: > Hi all, > > Below I assume using tcp transport for registrations. > > As I understand, while using a reliable transport for dialogs the > connection between UAC and the next hop is active until the dialog is > terminated by one party sending BYE and another party responding back. > The connections on both sides are then closed. > > I am looking at the REGISTER method, and I see that it does not > establish a dialog [RFC3261: 10.2 Constructing the REGISTER Request]. > So as I understand, the UAC registers itself(sends a REGISTER request) > with the location service, and closes the connection. And then opens a > connection every now and then to update the registration so it would > not expire. > > Say the UAC is behind the NAT. And after sending a REGISTER request > through my proxy, I want this connection to stay open, so that others > could reach this UAC through the proxy. > > Please correct me if my understanding of a dialog is wrong. That the > dialog enforces the connections to stay open. Where REGISTER, is a set > of transactions that do not require connection to stay active.
Read RFC 5256 "Managing Client-Initiated Connections" (previously "sip-outboud draft"). It is the new way to handle those situations. However SIP TCP and NAT is not defined AT ALL in RFC 3261, and the fact is that, using RFC 3261 as it is, a client behind NAT would never work using TCP if the proxy/registrar is in the public network. A common used approach is: - The client sends a REGISTER TCP and leaves the connection open forever. - The proxy/registrar detects NAT and also leaves that conenction open. - When the proxy must route an incoming call to that UA it uses the TCP connection used by the reigstration. - The client uses a new connection for its outgoin calls. Note that this means that the UA must listen for incoming calls on the random TCP port open by the REGISTER request, which "violates" the RFC 3261 since the UA should only listen in the port 5060 (or any other port indicated in Via and Contact, but this port has nothing to do with the random port used by the REGISTER). RFC 5256 "fixes" this problem with a new and complex specification. Regards. > > Thank you, > > Brez > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > -- Iñaki Baz Castillo <i...@aliax.net> _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
