Subject: [Sip] Comments :draft-ietf-sip-replaces-02.txt

From: "Arunachalam Venkatraman" <[email-masked]>
Date: Tue, 19 Nov 2002 00:08:25 -0600

Rohan
I have a few comments on this draft.

1. Section 3 -
	If the Replaces header field matches more than one dialog, the UA must act
s if no match is found.

    When is this possible? Since dialog id is made up of 3 globally unique
items, how can this occur? Is this statement inserted for completeness or is
there such a possibility in SIP compliant User Agents?

2. Section 3 -
	If the Replaces header field matches a dialog which has already terminated,
the UA SHOULD decline the request with a 603 Declined response.

	Since the purpose of the Replaces header is to replace a call so that the
user agent may accept a new call, it seems somewhat at cross-purposes to
decline the incoming call when the call to be replaced has terminated.
Of course, without this rule, it would be impossible to ensure that only the
user agent which has the call replaces it and not a different user agent in
another tine of the fork. But this imposes the rule that the user agent in a
consultation hold must stay on hold until the referred call arrives, to
ensure the transfer is successful. This is not a bad thing but I would
appreciate an affirmation that I have understood this correctly.
It may not hurt to discuss this for the benefit of others who may face a
similar doubt.

3. I am a little puzzled in the differentiation between the case of "match
not found" and "dialog terminated".
When a dialog is terminated, the state for that dialog will be uninstalled
and so it will not be found to be matched with a Replaces header.
	So, is this intended to cover the case where a dialog survives a BYE
because a subscription is pending (like, from an implicit Refer)?

4. Section 7.1
	I think the Replaces header in Message *3 is incorrect and has the tags
reversed. Since the Call Center plays the role of a UAS in both contexts,
the Replaces header must have its local tag (To-tag 6472 from the first
call), specified as the To-tag in the Replaces header of the second call.

5. Since the draft has expired, when is the next revision coming?

Thanks,
Venkat

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

---

From: Rohan Mahy <[email-masked]>
Date: Tue, 26 Nov 2002 13:30:38 -0800

On Tuesday, November 19, 2002, at 01:08 AM, Arunachalam Venkatraman 

> there such a possibility in SIP compliant User Agents?

this is for robustness/completeness

> It may not hurt to discuss this for the benefit of others who may face 

it does not require the user interface show that a call is on hold, it 
just requires that the dialog to replace is still up.

> because a subscription is pending (like, from an implicit Refer)?

in which section did you see this

> call), specified as the To-tag in the Replaces header of the second 

no, the example is correct.  A calls B.  Tags in a Replaces are 
compared from the perspective of the UAS receiving the INVITE with 
Replaces. You may want to check the description of remote-tag and 
local-tag in Section 12 of RFC3261.

I have received this question at least 4 times now, so I will certainly 
try to clarify this in the next rev of the document.

> 5. Since the draft has expired, when is the next revision coming?

as soon as I get review comments back from our Area Director.

many thanks,
-rohan

---

From: "Arunachalam Venkatraman" <[email-masked]>
Date: Tue, 26 Nov 2002 16:16:22 -0600

Rohan
Regarding your question on Item 3, refer to Section 3. It says that if no
match is found, a 481 must be sent. If it matches a dialog which has already
terminated, then a 603 must be sent.
What does the latter mean? If a dialog is terminated, then its state will be
deleted and it won't be found, will it?

Regarding item 4,
The Call Center's local tag on the Call being replaced was 6472 (TO tag in
message*2)
Therefore, the To-Tag on the Replaces header it receives must be 6472.
(To-Tag must be compared to local tag, as if they were present in an
incoming request, per Section 3.)
What am I missing?

Thanks
Venkat

-----Original Message-----
From: Rohan Mahy [mailto:[email-masked]]
Sent: Tuesday, November 26, 2002 3:31 PM
To: Arunachalam Venkatraman
Cc: [email-masked]
Subject: Re: Comments :draft-ietf-sip-replaces-02.txt

>       Since the purpose of the Replaces header is to replace a call so
that
> the

many thanks,
-rohan

---

From: Rohan Mahy <[email-masked]>
Date: Tue, 26 Nov 2002 15:32:16 -0800

On Tuesday, November 26, 2002, at 02:16 PM, Arunachalam Venkatraman 

> deleted and it won't be found, will it?

You need to keep the dialog state around anyway (in the case of UDP) 
for (typically) 32 secs.

> incoming request, per Section 3.)

attached is a flow from section 3.1 of 
draft-ietf-sipping-basic-call-flows-01.txt
i have removed all headers/bodies except to/from/callid/cseq

    User A                  User B
      |                        |
      |       INVITE F1        |
      |----------------------->|
      |    180 Ringing F2      |
      |<-----------------------|
      |                        |
      |       200 OK F3        |
      |<-----------------------|
      |         ACK F4         |
      |----------------------->|
      |   Both Way RTP Media   |
      |<======================>|
      |                        |
      |         BYE F5         |
      |<-----------------------|
      |       200 OK F6        |
      |----------------------->|
      |                        |

    F1 INVITE User A -> User B

    INVITE sip:[email-masked] SIP/2.0
    From: BigGuy <sip:[email-masked]>;tag=9fxced76sl
    To: LittleGuy <sip:[email-masked]>
    Call-ID: [email-masked]
    CSeq: 1 INVITE

    F2 180 Ringing User B -> User A

    SIP/2.0 180 Ringing
    From: BigGuy <sip:[email-masked]>;tag=9fxced76sl
    To: LittleGuy <sip:[email-masked]>;tag=8321234356
    Call-ID: [email-masked]
    CSeq: 1 INVITE

    F3 200 OK User B -> User A

    SIP/2.0 200 OK
    From: BigGuy <sip:[email-masked]>;tag=9fxced76sl
    To: LittleGuy <sip:[email-masked]>;tag=8321234356
    Call-ID: [email-masked]
    CSeq: 1 INVITE

    F4 ACK User A -> User B

    ACK sip:[email-masked] SIP/2.0
    From: BigGuy <sip:[email-masked]>;tag=9fxced76sl
    To: LittleGuy <sip:[email-masked]>;tag=8321234356
    Call-ID: [email-masked]
    CSeq: 1 ACK

Note in the BYE (F5 below) that from User A's perspective, the local 
tag for this dialog is 9fxced76sl, and the remote tag is 8321234356. 
(From the perspective of User B, the tags are reversed.  the local tag 
is 8321234356 and the remote tag is 9fxced76sl).

If User A received an INVITE with a Replaces header,

	Replaces: 
[email-masked];to-tag=9fxced76sl;from-tag=8321234356

it will compare the to-tag with *User A's* local tag (9fxced76sl), and 
the from-tag with *User A's* remote tag (8321234356).  while to-tag and 
from-tag are confusing, the text in section 3.1 of replaces is 
accurate.  the tags are matched as if they had been in the BYE below.

    F5 BYE User B -> User A

    BYE sip:[email-masked] SIP/2.0
    From: LittleGuy <sip:[email-masked]>;tag=8321234356
    To: BigGuy <sip:[email-masked]>;tag=9fxced76sl
    Call-ID: [email-masked]
    CSeq: 1 BYE

    F6 200 OK User A -> User B

    SIP/2.0 200 OK
    From: LittleGuy <sip:[email-masked]>;tag=8321234356
    To: BigGuy <sip:[email-masked]>;tag=9fxced76sl
    Call-ID: [email-masked]
    CSeq: 1 BYE

hope this clarifies things.
thanks,
-rohan

>>       If the Replaces header field matches more than one dialog, the 
>> UA
>> must act
>> s if no match is found.
>>
>>       I think the Replaces header in Message *3 is incorrect and has 
>> the
>> tags