But rfc 3261 14.1 says: Unlike an INVITE, which can fork, a re-INVITE will never fork, and therefore, only ever generate a single final response. The reason a re-INVITE will never fork is that the Request-URI identifies the target as the UA instance it established the dialog with, rather than identifying an address-of-record for the user.
What guarantees it ? target as the UA instance ...... whats that ? IP not FQDN, FQDN may may get multiple contacts from REGISTRAR. Probably it meant that it puts Contact. what made dialog into Request-URI, seems simple as that, just X-lite puts wrong(AOR not X-lite instance) Contact: into INVITE request, that confused me. Christer Holmberg (JO/LMF) wrote: > 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 Sip-implementors@cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
