Subject: Re: [Sip] (no subject)

From: "Keith Robinson" <[email-masked]>
Date: Wed, 13 Feb 2002 13:55:48 +0000

---------------------- Forwarded by Keith Robinson/MAIN/MC1 on 02/13/2002
01:53 PM ---------------------------

(Embedded image moved to file: pic09961.pcx)
From: Keith Robinson On: 02/13/2002 12:30:52 PM

To:   "Bob Penfield" <[email-masked]> @ MCEXT
cc:   <sip" <[email-masked]>@MCEXT

Subject:  Re: [Sip] (no subject)  (Document link: Keith Robinson)

The concern I have is the original R-URI that a proxy sees is not the same
as subsequent R-URI within the same dialog.

Below is the scenario I have in mind.

Say we have a terminating proxy, term-p1.new-domain.com,  that receives the
following INVITE: (some fields missing for brevity)

INVITE sip:[email-masked]
To:         sip:[email-masked]
From:  sip:[email-masked]
Contact: sip:[email-masked]
Record-Route: <sip:[email-masked];maddr=192.168.64.201>

In this case, the proxy at called-domain.com, which, for this situation is
a strict router,  has determined that [email-masked] is
contactable as [email-masked], has sent the INVITE on and
Record-Routed, using the maddr parameter to direct subsequent messages to
itself while preserving the original R-URI.

term-p1new-domain.com has the ability to execute scripts on set up  and
tear down, dependant on such variables as To, From and R-URI.   So, term-p1
requires the ability to save the original values of these fields so that
consistent scripts (correct user and context) can be invoked on set up and
clear down. To do this, it Record-Routes the same way as the strict routing
proxy above. The  following INVITE is sent to new-callee

INVITE sip:[email-masked]
To:         sip:[email-masked]
From:  sip:[email-masked]
Contact: sip:[email-masked]
Record-Route: <sip:[email-masked];maddr=170.60.50.200;lr>
Record-Route: <sip:[email-masked];maddr=192.168.64.201>

The response from the terminating user agent looks like

SIP/2.0 200 OK
Contact: <sip:170.60.50.100>
Record-Route: <sip:[email-masked];maddr=170.60.50.200;lr>
Record-Route: <sip:[email-masked];maddr=192.168.64.201>

Eventually, term-p1 wil get a BYE message; bearing in mind that the proxy
at called-domain.com is a strict router, the message will be as follows

BYE sip:[email-masked];maddr=170.60.50.200;lr
To:         sip:[email-masked]
From:  sip:[email-masked]
Route:  <sip:170.60.50.100>

Now following the rules given in bis07:

16.3 - Validate request OK
16.4  - Inspect the R-URI to see if it is one that would have been placed
in  a  Record-Route by this proxy; evidently it is so this is overwritten
with the last parameter in the Route header. The subsequent message looks
like:

BYE sip:170.60.50.100
To:         sip:[email-masked]
From:  sip:[email-masked]

The text now says that the proxy MUST process this modified request as
though  it was the original  received request. In which case, the original
R-URI is lost and the proxy will not be able  to invoke the correct sript,
unless it was written as a call stateful proxy and saved the original
R-URI.  So this specification  has the effect of requiring proxies to be
written call statefully thereby increasing complexity.

"Bob Penfield" <[email-masked]>@ietf.org on 02/12/2002 01:42:49
PM

Sent by:  [email-masked]

To:   "Keith Robinson" <[email-masked]>
cc:   "<sip" <[email-masked]>

Subject:  Re: [Sip] (no subject)

For subsequent requests in a dialog, the contact provided by the UA in a
200
OK is what the UAC wants to use for the target URI (last hop in the route).
If there are no route headers, the target URI is used as the R-URI.

If this is a new request with a pre-loaded route, the UA will put the
target
URI (usually the same at the To header) as the last route header. This has
always been to only way to guarantee that the last hop in the route would
receive the R-URI the UAC intended.

----- Original Message -----
From: "Keith Robinson" <[email-masked]>
To: <[email-masked]>
Cc: "<sip" <[email-masked]>
Sent: Tuesday, February 12, 2002 4:09 AM
Subject: Re: [Sip] (no subject)

>
> Hello,
>
> I see a problem here.
>
> The contact address that the UAC would put at the end of the route
headers
> is the contact address that was supplied by the terminating UA in a 200
OK
> response; this is not necessarily the same as the original R-URI that was
> sent in the original INVITE, it may simply be an IP address. I think it
is
> the original R-URI that the loose routing proxies are interested in,
either
> for resolving to the correct internal state machine (along  with the from
> and to headers) or deciding which terminating services to execute.
>
> Regards,
>
> K. Robinson
>
>
>
>
> "Bob Penfield" <[email-masked]> on 02/11/2002 07:02:22 PM
>
> To:   <[email-masked]>, "Keith Robinson" <[email-masked]>
> cc:
>
> Subject:  Re: [Sip] (no subject)
>
>
> ----- Original Message -----
> From: "Keith Robinson" <[email-masked]>
>
> > Hello,
> >
> >      This question may already have been dealt with, so my apologies if
> it
> > has.
> >
> > Anyway, in 16.4 (Making A Routing Decision) the text states that when a
> > bis07 proxy detects that the received R-URI is one that it would have
> > written into the Record-Route header then it must replace it with that
> last
> > entry of the Route header and continue as if this was the received
R-URI.
> > It also says that this will only happen if the previous element was a
> > strict router. If all the preceding elements were strict routers then
the
> > last entry in the Route header would not be the target URI as none of
the
> > previous element would have appended it; indeed there may not be a last
> > entry as the list may be empty.  How is this situation handled, or am I
> > missing something ?
> >
>
> In this case, the UAC will construct the route headers the same way
whether
> it understands loose routing or not. A pre-bis-06 UA would put the route
> set
> plus the contact address (the real/target Request-URI) in the route
header.
> A bis-06/07 compliant UA will add the contact address to the route
headers
> when it recognizes that the first route entry is a strict-router.
>
>
>
>
>
>
>
> ------------
> This e-mail and any attachments are confidential.  If you are not the
intended recipient, please notify us immediately by reply e-mail and then
delete this message from your system. Do not copy this e-mail or any
attachments, use the contents for any purpose, or disclose the contents to
any other person: to do so could be a breach of confidence.

_______________________________________________
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

------------
This e-mail and any attachments are confidential.  If you are not the intended recipient, please notify us immediately by reply e-mail and then delete this message from your system. Do not copy this e-mail or any attachments, use the contents for any purpose, or disclose the contents to any other person: to do so could be a breach of confidence.