Michael Procter wrote:
Hi,
When a re-INVITE arrives at a proxy, the request-uri will not indicate a domain that the proxy is responsible for. This is
because, unlike the initial INVITE, the request-uri would
contain the 'Contact:' address of the callee, not its AoR. As a result, it will never do a lookup.
I generally agree with this. In normal usage this probably what would happen.
This is not entirely true. Consider a user agent using GRUUs. These are likely to refer to the proxy (or some other entity that behaves in a similar manner).
Yes, that may be. But in that case the proxy that manages the gruu must understand the gruu. The meaning of gruu is Globally Routable Unique URI. The Unique part of that means that it designates a particular endpoint, and so will not cause forking.
The key point here is that it is a requirement of dialog establishing requests that they negotiate contacts with the GRUU property, which are used for all the subsequent messages in the dialog. So there is no forking issue.
The way to distinguish between initial INVITEs and reINVITEs is to examine the 'tag' on the To header. An initial INVITE will not have a tag (as it has not established a dialog yet) whilst a reINVITE will have a tag (as the transaction is part of an existing dialog).
This is true, but should be irrelevant to the proxy.
Paul
Regards,
Michael Procter
_______________________________________________ Sip-implementors mailing list Sip-implementors@cs.columbia.edu http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________ Sip-implementors mailing list Sip-implementors@cs.columbia.edu http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
