Subject: [Sip] Record-Route and 1xx

From: Jay Morris <[email-masked]>
Date: Tue, 1 Apr 2003 22:37:02 -0800 (PST)

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?

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

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?

Thanks,
Jay.

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

---

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

How do you change the whole route set when you use the remote-target uri to populate the request-uri? You must know the route set before hand or have to break the rule where you place the remote-target in the request-URI for requests within dialogs.

You could simply build an application that moves you into a new call but does not result in breaking your media.

/Hisham

> -----Original Message-----
> From: ext Juha Heinanen [mailto:[email-masked]]
> Sent: Thursday, April 03, 2003 2:14 PM
> To: Jonathan Rosenberg
> Cc: Khartabil Hisham (NMP/Helsinki); [email-masked];
> [email-masked]
> Subject: Re: [Sip] Record-Route and 1xx
> 
> 
> Jonathan Rosenberg writes:
>                                                               
>                   
>  > 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.
> 
> 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
> _______________________________________________
> 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
> 
_______________________________________________
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: Thu, 3 Apr 2003 18:06:55 +0300

Hi Juha,

 > From: ext [email-masked] [mailto:[email-masked]]
 > Sent: 03 April, 2003 17:00
 > To: Christer Holmberg
 > Cc: Jonathan Rosenberg; Khartabil Hisham (NMP/Helsinki);
 > [email-masked]; [email-masked]
 > 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.

Not necessarily. There are no guarantees that the proxies route the request to the exact same UA. For example, there may have been a CPL script in place that takes time of day into account.

 > 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.

There is a contradiction within that requirement. A route set is inherent to a dialog, hence it cannot be changed without replacing the rest of the dialog, i.e., making a completely new INVITE instead of a re-INVITE.

Cheers,
Aki