Subject: [Sip] Re: Comments :draft-ietf-sip-replaces-01.txt (Re-post)

From: Rohan Mahy <[email-masked]>
Date: Sun, 17 Nov 2002 08:18:01 -0800

Hello,

I think I may have responded to this email already, but I don't see in 
record of it in my archive.  In case I did not, I'd like to apologize 
for overlooking this message, and taking so long to respond to these 
comments.

thanks,
-rohan

On Monday, May 13, 2002, at 01:04 PM, Sriram Parameswar wrote:

> Hi,
>
> I had sent these comments prior to the Las Vegas Ad-Hoc, have not seen 
> any of discussion on this draft on the list. Just re-posting one more 
> time.
>
> Regards,
>
> Sriram
>
> __________________________________________
> Sriram Parameswar              Phone: 972-685-8540
> Nortel Networks
>
> Rohan,
>
> Some comments:
>
> (1)Section 4.1 says "In other words the to-tag is compared to the 
> local tag, and the from-tag is compared to the remote tag." However in 
> section 5.2 INV/200 estalish from-tag (operator) = 7743 and to-tag 
> (Call Center) = 6472. However the call from the customer to Call 
> Center has 
> Replaces:[email-masked];to-tag=7743;from-tag=6472, thus the 
> Call Center will _not_ be able to match correctly based on sections 
> 4.1 rule.

(These rules are now in Section 3). This situation is a bit confusing, 
but the example is correct. Since the rules above apply to the UAS, the 
local tag from the perspective of the UAS is "7743" and the remote tag 
is "6472". If you can think of a textual way to make this clearer, 
please send me some proposed text.

> (2) Section 5.2 the NOTIFY sent to from Customer to Operator when the 
> Customer receives 182 (Queued). Then this transaction is BYE'd. Now we 
> _cannot_ send another NOTIFY/200 from Customer to Operator as shown - 
> it will result in a 481.
> (3) Same for section 5.7 (and section 5.8) - once Bob gets a 687, he 
> BYE's the call with Alice. Then at the bottom of call Flow, Alice 
> tries to send a NOTIFY for the REFER, this will result in a 481.

Your comment applies now to the example in Section 7.1.  The BYE in 
this example doesn't terminate the dialog started with INVITE.  Since 
the REFER created a subscription, the dialog doesn't end until both a 
NOTIFY with Subscription-State: terminated, and a BYE have been 
received.

> (3) Section 5.8 Invite from Proxy (forking Alice) INVITE (2a) and (2b) 
> goes to C1. I think INVITE (2b) should go to C2.

These examples were removed for the sake of brevity. thankfully!

> (4) Section 5.6, just for grins, how does Alice get the Replaces 
> information to replace the dialog between Bob and Old Timer :).

Bob might be a normal user agent that support the dialog package for 
example.  In any case, this example was likewise removed for the sake 
of brevity.

hope this helps.  hopefully the examples in cc-transfer will make these 
concepts clearer for everyone.
thanks,
-rohan

> Thats what I have from my initial reading.
>
> Sriram
>
> __________________________________________
> Sriram Parameswar              Phone: 972-685-8540
> Interactive Multimedia Server (IMS) Fax: 972-684-3986
> Nortel Networks, Richardson USA  Email: [email-masked]
>