Hi, >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 ?
Well, if the re-INVITE is not sent to multiple locations in parallel it is guranteed not to happen. If the DNS lookup returns multiple IP addresses, the forking proxy should not send the re-INVITE to another address until it is sure that the re-INVITE sent to another address doesn't reach the user. >target as the UA instance ...... whats that ? IP not FQDN, >FQDN may may get multiple contacts from REGISTRAR. I don't think one is supposed to look at the REGISTRAR when forwarding a re-INVITE. The re-INVITE (and any other mid-dialog request) is routed using normal SIP routing rules. Regards, Christer > 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
