[OpenSER-Devel] pua module - R-URI of requests within a dialog

[Bogdan-Andrei Iancu]

Hi Marco,

Actually the proper section from RFC3261 that really nails down my 
previous statement is this one:

<SNAP>

12.2 Requests within a Dialog

   Once a dialog has been established between two UAs, either of them
   MAY initiate new transactions as needed within the dialog.  The UA
   sending the request will take the UAC role for the transaction.  The
   UA receiving the request will take the UAS role.  Note that these may
   be different roles than the UAs held during the transaction that
   established the dialog.

   Requests within a dialog MAY contain Record-Route and Contact header
   fields.  However, these requests do not cause the dialog's route set
   to be modified, although they may modify the remote target URI.
   Specifically, requests that are not target refresh requests do not
   modify the dialog's remote target URI, and requests that are target
   refresh requests do.  For dialogs that have been established with an
   INVITE, the only target refresh request defined is re-INVITE (see
   Section 14).  Other extensions may define different target refresh
   requests for dialogs established in other ways.

      Note that an ACK is NOT a target refresh request.

   Target refresh requests only update the dialog's remote target URI,
   and not the route set formed from the Record-Route.  Updating the
   latter would introduce severe backwards compatibility problems with
   RFC 2543-compliant systems.

</SNAP>


So, shortly, re-INVITEs may change the targets (via new contact). This 
actually have a deep implication of several openser modules that deal 
with dialogs:
    presence / pua
    dialog

Best regards,
Bogdan


Marco Happenhofer wrote:
> Hi Bogdan,
>
> I can not agree with your interpretation. Because the route header does not contain the final destination. 
> And the last hop could not be able to resolve the destination.
>
> The Contact header in the SIP Messages is the remote target URI, to which the sender has to address his message.
>
> According to section 8.1.1.8 of RFC3261:
>    The Contact header field provides a SIP or SIPS URI that can be used
>    to contact that specific instance of the UA for subsequent requests.
>
>
> According to section 12.2.1.1 of RFC3261:
>    The UAC uses the remote target and route set to build the Request-URI
>    and Route header field of the request.
>
> I think both parties of a dialog have to learn the remote target URI (from the Contact header) and use them for further requests
> as Request URI.
>
>
>
>
> Bogdan-Andrei Iancu schrieb:
>   
>> Hi Reinhold,
>>
>> But the first SUBSCRIBE establish the route set (RRs + contacts) which 
>> do not change across a dialog. So all NOTIFYs and SUBSCRIBEs within 
>> that dialog must follow the initial route set and not to try to change 
>> it.
>>
>> If for whatever reasons the route set needs to be changed, a new 
>> dialog must be created.
>>
>> Regards,
>> Bogdan
>>
>> Reinhold Buchinger wrote:
>>     
>>> But the API of the pua module does not provide a possibility to 
>>> update the contact. Can this be changed?
>>>
>>> Regards,
>>> Reinhold
>>>
>>> Klaus Darilion schrieb:
>>>  
>>>       
>>>> Yes it should
>>>>
>>>> Reinhold Buchinger schrieb:
>>>>    
>>>>         
>>>>> Hi,
>>>>>
>>>>> The pua module takes care of refreshing subscriptions. But 
>>>>> shouldn't the R-URI of the SUBSCRIBE request within a dialog
>>>>> be set to the URI provided in the Contact header filed of received 
>>>>> NOTIFY requests (as EyeBeam does, for instance)?
>>>>>
>>>>> Thank you.
>>>>>
>>>>> Best regards,
>>>>> Reinhold
>>>>>
>>>>>