Subject: RE: [Sipping] Target Refresh Request, reINVITE

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Tue, 18 Jul 2006 23:08:51 +0200

Hi,

>I forgot to state what I think should happen when this is clarified.
>IMO the new contact addresses from the reinvite should be abandoned and
the old ones remain active for the dialog.

What if you receive a new remote Contact in a reliable 18x, before the
re-INVITE is rejected?

>and what address should be used for any PRACKs or INFO requests sent
before the reinvite fails.

If the entity that sent the re-INVITE also sends the PRACK/INFOs, he
should use the current active remote Contact. But, again, if you receive
a reliable 18x with a new remote Contact, and then 4xx, are the new
Contacts in effect?

>Also, what address should be used for any in-dialog requests for other
dialog usages or non-usages.
>
>I think the prudent thing to do would be to state that the change of
contact address only takes place at the UAC upon 
>receipt of a 2xx response, and at the UAS upon receipt of an ACK to
that 2xx. (The ACK being delivered to the new 
>address.)

In the offer-answer-draft thread we indicated that it would be good to
be able to reject an SDP offer without having to reject the request.
This is a scenario where it would be useful: you can reject the SDP
offer, but still accept the new Contact.

Regards,

Christer

Paul Kyzivat wrote:
> This came up in the sipping meeting today. This seems to be ambiguous 
> at the moment and needs to be clarified.
> 
>     Paul
> 
> Nina Garaca wrote:
>> Hi,
>>
>> I was thinking a little more about a reINVITE as a target refresh 
>> request.
>>
>> Assume the following:
>>
>> The UAC sends a re-INVITE with a new local target (i.e. a new Contact

>> header value) with a new SDP offer. Suppose that the UAC has sent 
>> that offer within the target refresh request (so within the existing 
>> dialog), because of the offer nature, i.e., because the offer's 
>> "demanded" using an other device, and as a consequence, a new Contact

>> header field value in the reINVITE request.
>>
>> My question is what is happening if the UAS reject a reINVITE because

>> of the offer, it couldn't accept. Should the remote URI update be 
>> cancelled or not?
>>
>> RFC3261 12.2.2 12.2.2
>>
>> "Requests sent within a dialog, as any other request are atomic. If a

>> particular request is accepted by a UAS, all the state changes 
>> associated with it are performed. If the request is rejected, none of

>> the state changes are performed."
>> "When a UAS receives a target refresh request, it MUST replace the 
>> dialog's remote target URI with the URI from the Contact header field

>> in that request, if present."
>>
>> Regards, Nina  Garaca.
>>
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> ---
>>
>> Internal Virus Database is out-of-date.
>> Checked by AVG Anti-Virus.
>> Version: 7.0.300 / Virus Database: 265.6.5 - Release Date: 12/26/2004
>>
>>
>> ---------------------------------------------------------------------
>> ---
>>
>> _______________________________________________
>> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
>> This list is for NEW development of the application of SIP Use 
>> [email-masked] for questions on current sip Use 
>> [email-masked] for new developments of core SIP
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP Use 
> [email-masked] for questions on current sip Use 
> [email-masked] for new developments of core SIP
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP Use
[email-masked] for questions on current sip Use
[email-masked] for new developments of core SIP

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Juha Heinanen <[email-masked]>
Date: Wed, 19 Jul 2006 09:13:05 +0300

> What if you receive a new remote Contact in a reliable 18x, before the

again 18x problems.  how about making SIP simpler by allowing sdp only
in invite and ok?  would we only miss early media that doesn't work
anyhow?

-- juha

---

From: [email-masked]
Date: Wed, 19 Jul 2006 13:04:50 -0400

From: Juha Heinanen <[email-masked]>

There's a general problem that is unavoidable -- between when a dialog
change (like a new Contact, or new SDP) has been "proposed" and when
it has been irrevocably accepted by both endpoints, both endpoints
need to be able to receive packets according to both the "old" and the
"new" specifications.

Dale

---

From: Dean Willis <[email-masked]>
Date: Wed, 19 Jul 2006 12:05:52 -0500

> in invite and ok?  would we only miss early media that doesn't work

Well, we'd lose the entire preconditions model of RFC 4032.  Both the  
cable and 3gpp architectures rely on this, for good technical reasons  
having to do with broken transport networks.

However, one could construct an alternative model using a two-phase  
INVITE/reINVITE approach that would have the properties you describe.  
This was proposed during the 1999 interim meeting with PacketCable  
and rejected at that time in favor of the approach that later became  
RFC 4032, but I'll admit, I like that approach better now than I did  
then.

--
dean

---

From: Jiri Kuthan <[email-masked]>
Date: Fri, 21 Jul 2006 02:41:43 +0200

>need to be able to receive packets according to both the "old" and the

Hi Dale,

The behvioural description seems correct to me, I just don't understand
yet why that's actually a problem -- could you ellaborate on that for me?

Thanks,

-jiri

--
Jiri Kuthan            http://iptel.org/~jiri/