Iñaki Baz Castillo wrote:
El Miércoles, 3 de Febrero de 2010, Alex Balashov escribió:
What about using add_rr_param() to indicate NAT somehow so that this flag can be fished later out of the Record-Route header / Route set on sequential requests and replies?
This is exactly what I use to determine if rtpproxy must be added for a re- INVITE and its response (I add ";rtpproxy=yes" in Record-Route of the initial INVITE).
However this trick is not needed at all to fix just the signalling as the "Contact" URI (so the dialog target uri) was already replaced in the initial INVITE/200, and it cannot change within a dialog.
Are you sure? IIRC the contact may change (the Route set must not change).
They call them target-refreshing requests:
12.2: ... Requests within a dialog MAY contain Record-Route and Contact header fields. However, these requests do not cause the dialog's route set to be modified, although they may modify the remote target URI. Specifically, requests that are not target refresh requests do not modify the dialog's remote target URI, and requests that are target refresh requests do.
regards klaus