[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