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

Anca Vamanu anca at voice-system.ro
Tue Mar 4 18:23:39 CET 2008


Hi,

The investigations in RFC3261 revealed that the remote target should be 
updated by the Contact header of subsequent in dialog requests for 
presence messages also. Therefore, I have made the changes in presence 
and pua module to fix this.
Testing and feedback is appreciated.

regards,
Anca Vamanu

Bogdan-Andrei Iancu wrote:
> 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
>>>>>>
>>>>>>           
>>>>>>             
>
>
> _______________________________________________
> Devel mailing list
> Devel at lists.openser.org
> http://lists.openser.org/cgi-bin/mailman/listinfo/devel
>
>   




More information about the Devel mailing list