Christer Holmberg (JO/LMF) wrote:
> Hi,
>
> I personally think that there should be at most one outstanding target
> refresh transaction at any point, and that the UPDATE therefor should
> not be allowed in your example.
Certain requests are classified in the spec as "target refresh
requests". (E.g. INVITE, UPDATE, SUBSCRIBE, NOTIFY.) These are
classified as such whether a particular usage actually *changes* the
target or not.
I presume you want to restrict transactions that actually *change* the
target, not ones that involve "target refresh requests". Right?
What you suggest is at least prudent behavior. Whether it should be made
normative behavior is another question.
Note that responses to target refresh requests can also change the
target contact of the responder. Final responses are in general not
confirmed (except in the case of ACK), so the responder doesn't know if
the change was received until the transaction has timed out. Would you
also ban sending a new target change in that case too? (Or entirely ban
changing of target in a response?)
There may be cases when there are few options to making a target change.
The old address may be about to go bad for one reason or another. It
might be better to try changing the target rather than pulling the plug
on the call entirely.
I have mixed feelings about this. I can see some merit in tightening up
the rules to eliminate race conditions. But it may be a can of worms we
would rather not open.
Paul
> No, I don't know whether it's said somewhere, but in that case it's
> probably also one thing we should fix in the 3261-fix.
>
> We HAVE had a discussion whether 18x should be allowed for a re-INVITE
> in the first place, regarding an offer/answer issue (what happens if the
> 18x carries an answer, but then the re-INVITE fails).
>
> Regards,
>
> Christer
>
>
>> -----Original Message-----
>> From: [EMAIL PROTECTED]
>> [mailto:[EMAIL PROTECTED] On Behalf
>> Of [EMAIL PROTECTED]
>> Sent: 12. huhtikuuta 2007 14:18
>> To: Sonja Belic
>> Cc: [EMAIL PROTECTED];
>> [EMAIL PROTECTED]
>> Subject: Re: [Sip-implementors] UPDATE and reINVITE
>>
>> Hi Sonja,
>>
>> I think that which ever request has higher C-Seq number, the
>> contact in that request should be taken as dialogs remote target.
>>
>> With Regards
>> Raghu
>>
>>
>>
>>
>> Sonja Belic <[EMAIL PROTECTED]>
>> Sent by: [EMAIL PROTECTED]
>> 04/12/2007 03:56 PM
>>
>>
>> To
>> [EMAIL PROTECTED]
>> cc
>>
>> Subject
>> [Sip-implementors] UPDATE and reINVITE
>>
>>
>>
>>
>>
>>
>>
>> Hi,
>> I have a question regarding UPDATE and reINVITE.
>>
>> A B
>>
>> INVITE (C1)
>> |-------------------------------------->| // C = Contact
>> 180
>> |<--------------------------------------|
>> 200 OK (INVITE)
>> |<--------------------------------------|
>> ACK
>> |-------------------------------------->|
>> target
>> reINVITE (C2)
>> |-------------------------------------->|
>> 1xx
>> |<--------------------------------------|
>> UPDATE (C3)
>> |-------------------------------------->|
>> 200 OK (UPDATE)
>> |<--------------------------------------|
>> 200 OK (reINVITE)
>> |<--------------------------------------|
>> ACK
>> |-------------------------------------->|
>>
>>
>> Q: Is it OK for UPDATE to be sent when reINVITE isn't actually
>> responded with the final response? And what will be the dialog remote
>> target C2 or C3? According to RFC3311, I presume that 200 OK to
>> reINVITE should have the same Contact as UPDATE or its response.
>>
>>
>>
>> Best Regards
>> Sonja
>>
>> _______________________________________________
>> Sip-implementors mailing list
>> [EMAIL PROTECTED]
>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>>
>>
>>
>> *********************** Aricent-Unclassified
>> ***********************
>> "DISCLAIMER: This message is proprietary to Aricent and is
>> intended solely for the use of
>> the individual to whom it is addressed. It may contain
>> privileged or confidential information and should not be
>> circulated or used for any purpose other than for what it is
>> intended. If you have received this message in error,
>> please notify the originator immediately. If you are not the
>> intended recipient, you are notified that you are strictly
>> prohibited from using, copying, altering, or disclosing the
>> contents of this message. Aricent accepts no responsibility for
>> loss or damage arising from the use of the information
>> transmitted by this email including damage from virus."
>> _______________________________________________
>> Sip-implementors mailing list
>> [EMAIL PROTECTED]
>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>>
>
> _______________________________________________
> Sip-implementors mailing list
> [EMAIL PROTECTED]
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
