________________________________________ From: [email protected] [[email protected]] On Behalf Of GERTSVOLF, MARK (MARK) [[email protected]]
On our 4.2.1-018680 system deployed behind a NAT RLS generates dialog subscriptions with the following "To" and "From" headers: From: <sip:[email protected]:56541>;tag=CQfe6P To: <sip:[email protected]:5060;transport=UDP;x-sipX-nonat> The "From" header has host part with the private IP address of the sipX system instead of the SIP domain. The port is ephemeral port of the TCP connection created by RLS. The "To" header contains the "contact" of the registered endpoint as derived from the reg event subscription including remote NAT parameters (such as x-sipX-nonat) appended by the NAT plugin. Is there a particular reason these headers are formatted this way? Would it be possible to drop the port from the "From" header and format the "To" and "From" to contain SIP domain of the sipX system in the hostport? _______________________________________________ I think we have quite a bit of flexibility in principle, but I'm not sure what changes would actually be improvements. The To header is a simpler issue. What you see in the To header is the URI that is the original request-URI, the URI which the RLS is subscribing to. Before the RLS establishes a 'reg' subscription for an extension, it does subscribe to <sip:[extensi...@[sip-domain]>, and that is what shows in the To header. But after the RLS gets the list of contacts for the extension, it subscribes to each contact URI individually, and the contact URIs are what show in the To header. In your case, the RLS subscribed to <sip:[email protected]:5060;transport=UDP;x-sipX-nonat>. There is not necessarily any URI in the sip-domain that has exactly the same meaning. (In theory, we don't even know that this is a contact for ext. 2675.) So there isn't anything we can do with the To URI that doesn't obscure the intention of the subscription and go against the best practices described in RFC 3261. Ideally, the From header is the "identity" of the RLS. But the outgoing subscription component of the RLS only listens at that URI; indeed, there is no URI in the SIP domain that routes to the RLS (other than to request a particular event list), and none at all that route to the outgoing SipUserAgent. And its user-part is bogus -- "sipXrls" doesn't affect the routing of any request to that host-port, and indeed there might be a user *named* "sipXrls". Dale _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
