3 Feb
2010
3 Feb
'10
5:43 p.m.
Iñaki Baz Castillo wrote:
El Miércoles, 3 de Febrero de 2010, Alex Balashov
escribió:
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
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.