Subject: RE: [Sip] Record-Route and 1xx

From: [email-masked]
Date: Wed, 2 Apr 2003 17:28:25 +0300

> -----Original Message-----
> From: ext Jay Morris [mailto:[email-masked]]
> Sent: Wednesday, April 02, 2003 9:37 AM
> To: [email-masked]
> Subject: [Sip] Record-Route and 1xx
> 
> 
>  Hi, 
> The usage of Route and Record Route is still not clear to me when 1xx responses are used.
> 1.Should Record-Route headers be copied to any 1xx response of an early dialog?

yes

> 2. Should requests sent before the dialog is established use this Record-Route list for routing the request?

A dialog is established with 1xx (and early dialog). Your question should ask if requests are sent before the dialog is confirmed,  should they use this Record-Route list for routing the request. The answer is yes.

> 3. Should the route list be replaced for each 1xx response of an early dialog or should the UAC use only the first received Record-Route list for this
>  purpose?

Replace. Also the 2xx that confirms the dialog replaces the route set. After that, route set is not replaceable.

Regards,
Hisham

> Thanks,
> Jay.
enter - File online, calculators, forms, and more
_______________________________________________
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: [email-masked]
Date: Wed, 2 Apr 2003 18:22:44 +0300

[email-masked] writes:

 > Replace. Also the 2xx that confirms the dialog replaces the route
 > set. After that, route set is not replaceable. 

which is a bad thing and should be considered a bug.

-- juha

---

From: Jay Morris <[email-masked]>
Date: Wed, 2 Apr 2003 20:55:49 -0800 (PST)

Is this the case for any 1xx, or should the 1xx be reliable?
What about 100 response.
Jay.

yes

Regards,
Hisham

---------------------------------
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 03 Apr 2003 03:30:58 -0500

> Is this the case for any 1xx, or should the 1xx be reliable?

It is the case for any 1xx.

No:

> 12.1 Creation of a Dialog
> 
>    Dialogs are created through the generation of non-failure responses
>    to requests with specific methods.  Within this specification, only
>    2xx and 101-199 responses with a To tag, where the request was
>    INVITE, will establish a dialog.

Notice that 100 is left out of the picture.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Scientist                             Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 03 Apr 2003 03:32:49 -0500

We had long discussions on replacing the route set. It had serious 
backwards compatibility issues. We did conclude that it was possible to 
define an extension that allowed you to explicitly ask to be removed 
from the route set. So, if you feel you really need this feature, please 
go ahead and write up some reuqirements and a proposed mechanism.

-Jonathan R.

---

From: Jay Morris <[email-masked]>
Date: Thu, 3 Apr 2003 02:41:59 -0800 (PST)

Actually, my question was naive. I don’t need any special feature, I just want to do things according to the standard and now I am really confused about what I should do.
I summarize below the behavior I think is according to the standard. Please correct me if I’m wrong:

 Server behavior:

   When an Initial Invite is received take Record-Route list from message and build internal route list.
   Copy record route list to any 1xx (other then 100) response of the invite.
   Copy record route list to the Invite 2xx response.
   Use the route list for routing any outgoing request.
   After dialog is confirmed ignore any Record-Route header in refresh Invite requests.

 Client behavior

   When first 1xx response is received take Record Route list from the response message and build a temporary route set.
   Use this route set for any request sent before the dialog moves to the confirmed state.
   Ignore Record Route headers of other 1xx responses.
   When 2xx is received for the Invite replace the route set and use it for further requests.
   After dialog is confirmed ignore any Record-Route header in refresh Invite requests.

 Is that correct? Especially number 3 of the client behavior.

What does the standard say?

Thanks,

Jay.

 Jonathan Rosenberg <[email-masked]> wrote:We had long discussions on replacing the route set. It had serious 

-Jonathan R.

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 03 Apr 2003 13:59:44 +0300

Hi,

I would say number 3 for the client behaviour is correct, as long as you
remember that it is per leg (or whatever we call it nowadays...),
identified by the To header tag.

I had some issues on the changing of route set in 18x and 200, in the
"Re: [Sip] NOTIFY establishes a dialog" thread, but I haven't seen any
comments on those...

Regards,

Christer Holmberg
Ericsson Finland

Jay Morris wrote:

> Actually, my question was naive. I don’t need any special feature, I
> just want to do things according to the standard and now I am really
> confused about what I should do.
>
>   1. When an Initial Invite is received take Record-Route list from
>      message and build internal route list.
>   2. Copy record route list to any 1xx (other then 100) response of
>      the invite.
>   3. Copy record route list to the Invite 2xx response.
>   4. Use the route list for routing any outgoing request.
>   5. After dialog is confirmed ignore any Record-Route header in
>      refresh Invite requests.
>
>  Client behavior
>
>   1. When first 1xx response is received take Record Route list from
>      the response message and build a temporary route set.
>   2. Use this route set for any request sent before the dialog moves
>      to the confirmed state.
>   3. Ignore Record Route headers of other 1xx responses.
>   4. When 2xx is received for the Invite replace the route set and use
>      it for further requests.
>   5. After dialog is confirmed ignore any Record-Route header in
>      refresh Invite requests.
>
>  Jonathan Rosenberg <[email-masked]> wrote:
>
>      > Sip mailing list
>      https://www1.ietf.org/mailmaan/listinfo/sip
>      > This list is for NEW development of the core SIP Protoco!
>      l
>      [email-masked] FAX: (973) 952-5050
> -----------------------------------------------------------------------
> Do you Yahoo!?

---

From: Juha Heinanen <[email-masked]>
Date: Thu, 3 Apr 2003 14:14:21 +0300

Jonathan Rosenberg writes:
                                                                                
 > backwards compatibility issues. We did conclude that it was possible
 > to define an extension that allowed you to explicitly ask to be
 > removed from the route set. So, if you feel you really need this
 > feature, please go ahead and write up some reuqirements and a
 > proposed mechanism.

for example, if my dual mode (mobile network, wlan) UA has started a
dialog at a mobile network and then does a re-invite at a wlan hotspot,
i want that re-invite to change the ENTIRE route set. otherwise it is
highly likely (based on past experience on the behavior of mobile
operators) that they would keep on charging me for the rest of the call
per minute until their proxy sees the bye.  the same holds for things
like presence notifications.  i don't what them to keep on going back to
the proxy of the mobile operator.

my proposal is simply to change the route set and update the UAs
accordingly.

-- juha

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 03 Apr 2003 14:46:07 +0300

Hi Juha,

How can you make sure that the re-INVITE will reach the UAS, if you send it
to another proxy? Or, would you insert the WHOLE new route set in the
re-INVITE, including all the proxies between yourself and the UAS? How will
your terminal know that route set?

I am not saying it wouldn't be useful to change the route set during the
session - I am just trying to understand your example :)

What I would like to see also, is an example where it is useful to change
the route set between the 18x and 200 of the initial INVITE. In the other
mail I mentioned some issue which could came up with such behvaiour...

Regards,

Christer Holmberg
Ericsson Finland

---

From: [email-masked]
Date: Thu, 3 Apr 2003 15:15:54 +0300

> your terminal know that route set?

i guess i didn't make myself clear.  when my UA connects to the wlan, it
learns its outbound proxy (if any) via dhcp.  it then issues a normal
invite which gets record routed by the (possible) new set of proxies.
that new recorded route will then be used for subsequent request and the
mobile operators' proxies are out of the loop.

-- juha

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 03 Apr 2003 15:43:35 +0300

Hi Juha,

> mobile operators' proxies are out of the loop.

Well, then my question is, again: how can you be sure that the re-INVITE, send to
the "new" outbound proxy, will actually reach the same UAS you are currently
having a session with?

Regards,

Christer Holmberg
Ericsson Finland

---

From: [email-masked]
Date: Thu, 3 Apr 2003 16:59:55 +0300

Christer Holmberg writes:

 > Well, then my question is, again: how can you be sure that the
 > re-INVITE, send to the "new" outbound proxy, will actually reach the
 > same UAS you are currently having a session with?

the re-invite would be sent to the aor of the uas, i.e., not to its ip
address, and assuming that the uas is still registered, re-invite would
reach it.

by the way, like jonathan said, we should first discuss the requirements
and after that figure out the possible solutions.  and the requirement
is that when the ua moves to another network, a compete new route must
be recorded.

-- juha

---

From: Jay Morris <[email-masked]>
Date: Thu, 3 Apr 2003 06:22:08 -0800 (PST)

Thanks for the response. 
Lets say that I have the following scenario
     UA1                 B2B1           B2B2          UA2
     
     -----INV------->
     
     <----180 rel---
     
     -----PRACK----->
     
     <----200--------

                      -----INV------->
     
                      <----180 rel---
     
     <------180 rel--     
     
     -----PRACK-----> ---PRACK-------->
     
     <----200-------- <----200--------

   If the UA1 will not update the route set according to the second 180 response the prack will never  get to B2B2.
   Is this even possible scenario?
   
Jay.
 Christer Holmberg <[email-masked]> wrote:
Hi,

Regards,

Christer Holmberg
Ericsson Finland

Jay Morris wrote:

> Jonathan Rosenberg wrote:
>

---

From: [email-masked]
Date: Thu, 3 Apr 2003 18:04:16 +0300

may be jonathan's uri leasing stuff could be useful in getting the
re-invite to the uas.

-- juha

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 05 Apr 2003 16:12:24 -0500

Yes, this is exactly the kind of stuff it would be useful for. In fact, 
you would issue an INVITE w. Replaces to the GRUU, and it would 
effectively replace the old call leg. Handover wont exactly be smooth, 
though....

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 05 Apr 2003 16:21:36 -0500

inline.

Jay Morris wrote:
>    If the UA1 will not update the route set according to the second 180 
> response the prack will never  get to B2B2.

Sure it will. These are b2buas, not proxies. Since b2b1 is a UA, it is 
responsible for generating the PRACK to the 18x received from b2b2, and 
if it wants, it can forward the 180 upstream to ua1.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 05 Apr 2003 16:28:27 -0500

Yes, all of this is correct according to the spec. Here is the words, 
from Section 12.1.2:

    When a UAC receives a response that establishes a dialog, it
    constructs the state of the dialog.  This state MUST be maintained
    for the duration of the dialog.

Note that this means that the state is set only upon creation, which 
means the first 1xx response. THis is modified by the speific behavior 
for INVITE, from 13.2.2.4:

    If the dialog identifier in the 2xx response matches the dialog
    identifier of an existing dialog, the dialog MUST be transitioned to
    the "confirmed" state, and the route set for the dialog MUST be
    recomputed based on the 2xx response using the procedures of Section
    12.2.1.2.  Otherwise, a new dialog in the "confirmed" state MUST be
    constructed using the procedures of Section 12.1.2.

-Jonathan R.

Jay Morris wrote:
>    2. Copy record route list to any 1xx (other then 100) response of the
>       invite.
>    2. Use this route set for any request sent before the dialog moves to
>       the confirmed state.
>  */Jonathan Rosenberg <[email-masked]>/* wrote:
> 
>      > Sip mailing list https://www1.ietf.org/mailmaan/listinfo/sip
> ------------------------------------------------------------------------
> Do you Yahoo!?
> Yahoo! Tax Center 
> <http://us.rd.yahoo.com/finance/mailsig/*http://tax.yahoo.com> - File 
> online, calculators, forms, and more