Subject: Re: [Simple] Question on RFC 5438

From: Christer Holmberg <[email-masked]>
Date: Thu, 1 Apr 2010 12:24:10 +0200

Hi, 

>Record-route only affects a dialog.

Is that really true? As far as I understand, Record-Route is used to create a route set. For INVITEs, that route set is valid for the duration of the dialog, but is there actually text saying that it would always be the case?

Anyway, my issue isn't about IMDN-Record-Route, because only supporting entities need to support that. My issue is about IMDN-Route, and whether also non-supporting entities (proxies etc) would have to support that in order to correctly route the IMDN MESSAGE request. Route would not have that problem, since any SIP entity is supposed to support it.

>MESSAGE is typically out-of-dialog. Also, these "intermediaries" are not typically proxies. They are acting as endpoints (aka b2buas), and we're probably talking about a series of SIP 
>transactions between the devices, not one end-to-end transaction. 

I am not sure I understand.

So, when the UAS sends the IMDN MESSAGE, it is going to insert the next IMDN hop in the Request-URI, instead of the remote UA?

Regards,

Christer

	Hi,
	 
	I have a question on RFC 5438.
	 
	The RFC defines a mechanism, where the receiver of a MESSAGE request can send a "receipt", using another MESSAGE request (IMDN MESSAGE), to the sender to the initial MESSAGE to indicate that it has been received. There is similar functionality in e-mail.
	 
	For this, the RFC defines new CPIM header fields, including IMDN-Record-Route and IMDN-Route, to establish a "route" for the IMDN MESSAGE, so that interested intermediaries can also receive it. Intermediaries can insert IMDN-R-R in the initial MESSAGE, and the receiver then use the value to create an IMDN-Route in the associated IMDN MESSAGE. Intermediaries are then supposed to route the IMDN MESSAGE using IMDN-Route.
	 
	Now, the RFC seems to assume that the only intermediaries that will insert IMDN-Record-Route is certain application servers, and I guess that is ok.
	 
	Section 12.2 says:
	 
	"In this context, intermediaries include application servers
	(including URI-List and store-and-forward servers) and gateways.  SIP
	Proxies MUST NOT generate IMDNs but MUST forward them like any other
	SIP request."
	 
	BUT, if an AS has inserted IMDN-Record-Route, and there are also other proxies, aren't there cases when proxies are supposed to route based on the IMDN-Route? Otherwise the IMDN MESSAGE may never reach the AS that inserted IMDN-R-R. If so, that would require proxies to also support the IMDN extension, but how can one ensure that (there is no Proxy-Require option-tag defined)?
	 
	Now, I assume a reason for defining IMDN-Record-Route was because MESSAGE does not allow Record-Route.
	 
	But, MESSAGE does allow Route, so my question is why Route can not be used instead of IMDN-Route? Then there would be no issues with intermediaries not supporting the extension.
	 
	So, unless I have missunderstood something, I think we would need to fix this.
	 
	Regards,
	 
	Christer
	 
	_______________________________________________
	Simple mailing list
	[email-masked]
	https://www.ietf.org/mailman/listinfo/simple

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 1 Apr 2010 12:54:33 +0200

> Is that really true? As far as I understand, Record-Route is used to create a route set. For INVITEs, that route set is valid for the duration of the dialog, but is there actually text saying that…

Record-Route is inserted in the initial INVITE/SUBscrIbE/REFER by a
proxy which wants to remain in the dialog path for the duration of the
dialog. This is called loose-route mechanism (introduced in RFC 3261).

An initial request can also contain a Route header, but this is out of
the scope of the loose-routing mechanism.

> So, when the UAS sends the IMDN MESSAGE, it is going to insert the next IMDN hop in the Request-URI, instead of the remote UA?

If so, that looks like the deprecated strict routing defined in the
obsoleted RFC 2543.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 1 Apr 2010 13:05:56 +0200

Hi, 

>>Is that really true? As far as I understand, Record-Route 
>>is used to create a route set. For INVITEs, that route set is 
>>valid for the duration of the dialog, but is there actually 
>>text saying that it would always be the case?
> 
>Record-Route is inserted in the initial 
>INVITE/SUBscrIbE/REFER by a proxy which wants to remain in 
>the dialog path for the duration of the dialog. This is 
>called loose-route mechanism (introduced in RFC 3261).

I know that. My point was that I can not find text saying that a route set always need to be used for a dialog.

However, that is not my main issue, so we don't need to discuss that.

>An initial request can also contain a Route header, but this is out of the scope of the loose-routing mechanism.
> 
>>Anyway, my issue isn't about IMDN-Record-Route, because 
>>only supporting entities need to support that. My issue is 
>>about IMDN-Route, and whether also non-supporting entities 
>>(proxies etc) would have to support that in order to 
>>correctly route the IMDN MESSAGE request. Route would not 
>>have that problem, since any SIP entity is supposed to support it.
>>
>>>MESSAGE is typically out-of-dialog. Also, these "intermediaries" are 
>>>not typically proxies. They are acting as endpoints (aka 
>>>b2buas), and we're probably talking about a series of SIP 
>>So, when the UAS sends the IMDN MESSAGE, it is going to 
>>insert the next IMDN hop in the Request-URI, instead of the remote UA?
> 
>If so, that looks like the deprecated strict routing defined in the obsoleted RFC 2543.

So, then help me understand how it will look like, so that non-aware intermediaries don't need to understand IMDN-Route :)

Regards,

Christer

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 1 Apr 2010 13:09:15 +0200

> If so, that looks like the deprecated strict routing defined in the

But it's not the case, it's more like the normal loose-routing:

   An IM may contain an IMDN-Record-Route header field (see Section 8
   for details).  If IMDN-Record-Route header fields appear in the IM,
   the IM Recipient constructing the IMDN MUST copy the contents of the
   IMDN-Record-Route header fields into IMDN-Route header fields in the
   IMDN and maintain their order.  The IMDN is then sent to the URI in
   the top IMDN-Route header field.  IMDN-Record-Route header fields do
   not make sense in an IMDN and therefore MUST NOT be placed in an
   IMDN.  IMDN Recipients MUST ignore it if present.

So this just means that an intermediary could insert a
IMDN-Record-Route i nthe original MESSAGE. Then the recipient
constructing the IMDN copies the values of IMDN-Record-Route into
IMDN-Route header (mantaining the order). I expect the RURI of the
IMDN request is still the From of the original IM, but the recipient
must send the IMDN to the top value of the IMDN-Route header it has
build.

Then, this means that the request will arrive to an intermediary which
previously added a IMDN-Record-Route, so IMHO it MUST support routing
based on IMDN-Route. This is exactly the original question, right?

And as I understand by reading section 8 the intermediary inserting
IMDN-Record-Route must be able to route based on IMDN-Route:

   For the reasons stated above, an intermediary MAY choose to remain on
   the path of IMDNs for a specific IM.  It can do so by adding a CPIM
   IMDN-Record-Route header field as the top IMDN-Record-Route header
   field.  The value of this field MUST be the intermediary's own
   address.  An intermediary that does not support this extension will
   obviously not add the IMDN-Record-Route header field.  This allows
   IMDNs to traverse directly from the IM Recipient to the IM Sender
   even if the IM traversed an intermediary not supporting this
   extension.

   An intermediary receiving an IMDN checks the top IMDN-Route header
   field.  If that header field carries the intermediary address, the
   intermediary removes that value and forwards the IMDN to the address
   indicated in the new top IMDN-Route header field.  If no additional
   IMDN-Route header fields are present, the IMDN is forwarded to the
   address in the CPIM To header field.

So, yes, it would be really easier if the recipient uses normal Route
rather than IMDN-Route, so any SIP proxy could just add the
IMDN-Record-Route without having to deal with routing based on
IMDN-Route. But this would introduce two problems:

1) Usually proxies just allow Route headers for in-dialog requests (as
a security protection).

2) It's cooler for the RFC authors to create two new headers rather
than just one.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 1 Apr 2010 13:11:37 +0200

> So, then help me understand how it will look like, so that non-aware intermediaries don't need to understand IMDN-Route :)

As I've just replied in other mail, IMHO an intermediary not
implementing routing based on IMDN-Route should not add a
IMDN-Record-Route header.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 1 Apr 2010 13:20:08 +0200

Hi, 

>    the IM Recipient constructing the IMDN MUST copy the 
>    contents of the IMDN-Record-Route header fields into IMDN-Route header 
>    fields in the IMDN and maintain their order.  The IMDN is then sent to the URI in
>constructing the IMDN copies the values of IMDN-Record-Route 
>into IMDN-Route header (mantaining the order). I expect the 
>RURI of the IMDN request is still the From of the original 
>IM, but the recipient must send the IMDN to the top value of 
>the IMDN-Route header it has build.
> 
>Then, this means that the request will arrive to an 
>intermediary which previously added a IMDN-Record-Route, so 
>IMHO it MUST support routing based on IMDN-Route. This is 
>exactly the original question, right?

Yes, that is the question.

But, what if the UA e.g. routes all messages via some IMDN-unaware default outbound proxy?

This is normally done by adding a Route header pointing towards the outbound proxy. Yes, the UA can do it also now, but the problem is that the outbound proxy is then not able to forward the request, since it does not understand IMDN-Route.

>And as I understand by reading section 8 the intermediary inserting IMDN-Record-Route must be able to route based on IMDN-Route:

Yes.
 
>intermediary removes that value and forwards the IMDN to 
>the address indicated in the new top IMDN-Route header field. If no additional

...which is also a little strange. Why not route to the address in the R-URI?

>So, yes, it would be really easier if the recipient uses 
>normal Route rather than IMDN-Route, so any SIP proxy could 
>just add the IMDN-Record-Route without having to deal with 
>routing based on IMDN-Route. But this would introduce two problems:
> 
>1) Usually proxies just allow Route headers for in-dialog 
>requests (as a security protection).

I have seen numerous of cases where non-in-dialog requests (dialog establishment requests, registration requests etc) have been sent with pre-defined routes.

>2) It's cooler for the RFC authors to create two new headers rather than just one.

Sure. It's more sexy to re-new rather than re-use :)

Regards,

Christer

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 1 Apr 2010 13:29:41 +0200

> This is normally done by adding a Route header pointing towards the outbound proxy. Yes, the UA can do it also now, but the problem is that the outbound proxy is then not able to forward the reques…

Right :(

> ...which is also a little strange. Why not route to the address in the R-URI?

Ops, I didn't realize that "If no additional IMDN-Route header fields
are present, the IMDN is forwarded to the address in the CPIM To
header field". This is really annoying.

> I have seen numerous of cases where non-in-dialog requests (dialog establishment requests, registration requests etc) have been sent with pre-defined routes.

Yes, there are cases but as they introduce some security risks in some
environments they are not allowed.

> Sure. It's more sexy to re-new rather than re-use :)

So we end with an unusable specification (again)  :(

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Ben Campbell <[email-masked]>
Date: Thu, 1 Apr 2010 09:00:06 -0500

Let's back up a little bit. IMDN-route has nothing to do with SIP proxies, and doesn't affect routing at the SIP layer in any way. It's  is a CPIM header, not a SIP header, and is theoretically not even available to a SIP proxy. It could conceivably be encrypted. It might even be carried in non-SIP protocols for one or more steps along the way.

These IMDN-Record-Route and IMDN-Route intermediaries are devices like message list exploders and store-and-forward servers. These devices were UASs in the original MESSAGE request, and likely act as UAC's to forward the message somewhere else in an entirely new SIP transaction.

If a endpoint or intermediary wants to send an IMDN that contains IMDN-Route, it sends the IMDN to the first IMDN-Route entry. In SIP terms, that means the R-URI will be the first IMDN-Route entry.

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 6 Apr 2010 19:21:26 +0200

Hi,

>Let's back up a little bit. IMDN-route has nothing to do with SIP proxies, and doesn't affect routing at the SIP layer in any way. It's  is a CPIM header, not a SIP header, and is theoretically not even available to a SIP proxy. It could conceivably be encrypted. It might 
>even be carried in non-SIP protocols for one or more steps along the way.
>

I guess that would work, but could you please tell we where in the RFC that is described? In my opinion it is not clear, but I may of course have missed something.

Regards,

Christer

---

From: Ben Campbell <[email-masked]>
Date: Tue, 6 Apr 2010 13:32:56 -0500

> I guess that would work, but could you please tell we where in the RFC that is described? In my opinion it is not clear, but I may of course have missed something.

Section 7.1.1, paragraph 4, and section 8 paragraph 5 each say that the IMDN is sent to the topmost IMDN-Route header. It doesn't go into details on how one constructs the R-URI. But that's pretty much what "send to a URI" means in SIP.

Section 12.1, paragraph 1 says that SIP proxies MUST NOT generate IMDNs but MUST forward them like they would any other SIP request.