re-IUNVITE and forking

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.

Another related question, if server runs behind NAT, how
usually contact 
address is detected ?
(Using a STUN ? or is option in settings ?)

Thanks,
_______________________________________________
Sip-implementors mailing list
Sip-implementorscs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinf
o/sip-implementors

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-implementorscs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinf
o/sip-implementors

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: ua1domain.com)  -> proxy
registrar(For example 
>> 2 contacts for UA2)  ->   UA2 (Contact: ua2domain.com)
>> Now if UA1 sends re-INVITE to UA2 (ua2domain.com), what 
>> uarantees that proxy won't fork.
>> If UA2 Contact is IP, not a problem, like ua210.0.0.1.
>>
>> 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-implementorscs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinf
o/sip-implementors

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: ua1domain.com)  -> proxy
registrar(For example 
> >> 2 contacts for UA2)  ->   UA2 (Contact:
ua2domain.com)
> >> Now if UA1 sends re-INVITE to UA2 (ua2domain.com), what uarantees 
> >> that proxy won't fork.
> >> If UA2 Contact is IP, not a problem, like
ua210.0.0.1.
> >>
> >> 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-implementorscs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinf
o/sip-implementors