Hi Ivar, >>The re-INVITE is sent within a dialog, and is routed (like any other >>mid-dialog request) using the dialog route set. >UA1(Contact: [EMAIL PROTECTED]) -> proxy registrar(For example >2 contacts for UA2) -> UA2 (Contact: [EMAIL PROTECTED]) >Now if UA1 sends re-INVITE to UA2 ([EMAIL PROTECTED]), what >uarantees that proxy won't fork. >If UA2 Contact is IP, not a problem, like [EMAIL PROTECTED] > >For there i assumed that contact may not be domain name and >must be IP ? >Or i miss something what orders proxy to forward re-INVITE to >right contact.
I am not sure whether a Contact (or Route/R-R) MUST be an IP address (I have never seen something else, though). So, I guess your issus is that if the value is a domain name, and the sender performs a DNS lookup, he may end up sending the re-INVITE to another address than where the initial INVITE was sent? Now, that itself is not forking, but I guess the issue is if the DNS lookup returns multiple addresses and the sender starts sending the re-INVITE to multiple locations in a parallel manner. >>I am not sure I understand your question... >For example b2bua server behind NAT, it needs to report >public IP Contact: to it's requests. It doesn't need to need to know, if the B2BUA handles the mapping. Regards, Christer > > > > > Christer Holmberg (JO/LMF) wrote: > > Hi, > > > > > >> re-INVITE never forks says rfc. What ensures that ? > >> Does that mean Contact: header must always have IP in host > portion of > >> URI ? > >> (I assume that Record-Routing is enabled, so all goes to that path) > >> > >> If it has AOR, then proxy may fork it. > >> > > > > The re-INVITE is sent within a dialog, and is routed (like > any other > > mid-dialog request) using the dialog route set. > > > > > >> Another related question, if server runs behind NAT, how usually > >> contact address is detected ? > >> (Using a STUN ? or is option in settings ?) > >> > > > > I am not sure I understand your question... > > > > Regards, > > > > Christer > > > > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
