Subject: [sipcore] About RFC3911(Join header)'s potential error: //Join header in REFER?

From: [email-masked]
Date: Mon, 11 Oct 2010 11:32:37 +0800

Paul,

By RFC3911, only INVITE is allowed to have the Join header. But I 
considered the use case, such as A want ask B to Join a current session, 
there might be the requirement for the Join header in REFER request. How 
do you think about it?

Thanks,

Gao

===================================
 Zip    : 210012
 Tel    : 87211
 Tel2   :(+86)-025-52877211
 e_mail : [email-masked]
===================================

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Mon, 11 Oct 2010 16:14:31 -0400

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of [email-masked] [[email-masked]]

By RFC3911, only INVITE is allowed to have the Join header. But I considered the use case, such as A want ask B to Join a current session, there might be the requirement for the Join header in REFER request. How do you think about it?
________________________________________

You do not use the Join header in the REFER request itself.  However, the Refer-To URI will have a 'header' specifying that the INVITE to be generated will have a Join header:

REFER sip:aaa SIP/2.0
Refer-To:  sip:bbb?Join=ccc

The recipient of this REFER will generate an INVITE:

INVITE sip:bbb SIP/2.0
Join: ccc

Dale

---

From: [email-masked]
Date: Tue, 12 Oct 2010 08:36:00 +0800

> You do not use the Join header in the REFER request itself. 
> However, the Refer-To URI will have a 'header' specifying that the 
> INVITE to be generated will have a Join header:
> 
> REFER sip:aaa SIP/2.0

This is similar to Replaces semantics in REFER(Refer-To) as defined in 
RFC3515 as:

Refer-To: <sip:[email-masked]?Replaces=12345%40192.168.118.3%3B
          to-tag%3D12345%3Bfrom-tag%3D5FFE-3994>

But I really did not see any normative defintion for Join semantics in 
REFER(Refer-To). If you saw it, please tell me the RFCs and relating 
sections.

Thanks,

Gao

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 12 Oct 2010 08:51:27 -0400

> REFER(Refer-To). If you saw it, please tell me the RFCs and relating

Its because there are none.

The semantics of Join apply to INVITE.

If you use a REFER, with a Refer-To URI that has an embedded Join 
header, then the resulting INVITE will have a Join header. That's all.

	Thanks,
	Paul

---

From: [email-masked]
Date: Tue, 12 Oct 2010 21:10:40 +0800

> header, then the resulting INVITE will have a Join header. That's all.

OK. And I admit that it's working in pure audio systems.

But there's still two questions behind it:

1. Is this way(with a Refer-To URI that has an embedded Join header) 
normative?
I admit that it looks like normative. But our system met interworking 
issue about this way.

2. Is this way has enough expression?
Please refer to my comments in the previous mail:
"the instruction of the which media streams should be in the 
INVITE_with_Join from the Refer-By party to the Refer-To party" 
It is quit important.

And after I evaluated the second point, I doubt the first point more.

Thanks,

Gao

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 12 Oct 2010 10:09:20 -0400

> 1. Is this way(with a Refer-To URI that has an embedded Join header)

I don't know what you mean - "is it normative?".
Its a mechanism you can use if you think it serves your needs.

Or maybe you are asking if honoring the embedded headers in an R-URI is 
normative. Its not. And *that* is indeed a potential limitation to using 
Join with REFER. If the referred party doesn't honor the embedded Join 
header, then it will end up replacing the call rather than joining it.

	Thanks,
	Paul

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Tue, 12 Oct 2010 10:45:02 -0400

________________________________________
From: [email-masked] [[email-masked]]

This is similar to Replaces semantics in REFER(Refer-To) as defined in RFC3515 as:

But I really did not see any normative defintion for Join semantics in REFER(Refer-To). If you saw it, please tell me the RFCs and relating sections.
________________________________________

The use of '?Join=...' and '?Replaces=...' in the Refer-To URI isn't defined in the REFER RFC because the semantics are a consequence of a general rule about how 'headers' in a URI are to be interpreted when a request is generated "to a URI".  That is defined in RFC 3261 section 19.1.1.

Dale

---

From: [email-masked]
Date: Tue, 12 Oct 2010 23:32:30 +0800

> But I really did not see any normative defintion for Join semantics 
> in REFER(Refer-To). If you saw it, please tell me the RFCs and 
> relating sections.
> The use of '?Join=...' and '?Replaces=...' in the Refer-To URI isn't
> defined in the REFER RFC because the semantics are a consequence of 
> a general rule about how 'headers' in a URI are to be interpreted 
> when a request is generated "to a URI".  That is defined in RFC 3261
> section 19.1.1.
> 

As we know, RFC3261 section 19.1.1 just define the basic format and syntax 
of embedded headers for URI. In other words, the sematics of the embedded 
headers and the behavior defintion should be defined in other RFCs 
clearly.

About Replaces header embedded in URI, there's no detailed defintion for 
it. But a example in RFC3515 section 2.1.

IMO, this could be treated as *some level* normative definition, or at 
least guidelines.

But there's nothing about Join header embedded in URL, in any of RFCs. So, 
I can just treated it as something like a private extension, just like one 
vendor put a "XXX" header embedded.

And the UAS's vendor would ask you how should they behaving and where is 
the specification/rule? (And this is usual in interworking testing).

Thanks,

Gao

---

From: [email-masked]
Date: Tue, 12 Oct 2010 23:40:05 +0800

> Its a mechanism you can use if you think it serves your needs.

As you can see, the header syntax(such as Join header with CallID and 
From/To Tags), semantics, behavior for UAS should be defined clearly. 
Otherwise, there would be no meaning in interworking for UAs from 
different vendors.

In fact, this is not like any private sip extension. So, I think it should 
be defined in one RFC, at least as BCP.

> > And after I evaluated the second point, I doubt the first point more.

What about the second one?

Thanks,

Gao

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 12 Oct 2010 17:49:43 +0200

Hi,

>From a SIP protocol perspective, I don't think embedded headers have any semtantics - until they become "real headers" in the request triggered by the REFER.

Regards,

Christer

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 12. lokakuuta 2010 18:33
To: Worley, Dale R (Dale)
Cc: [email-masked]
Subject: Re: [sipcore] About RFC3911(Join header)'s potential error: //Join header in REFER?

> in REFER(Refer-To). If you saw it, please tell me the RFCs and

As we know, RFC3261 section 19.1.1 just define the basic format and syntax of embedded headers for URI. In other words, the sematics of the embedded headers and the behavior defintion should be defined in other RFCs clearly.

About Replaces header embedded in URI, there's no detailed defintion for it. But a example in RFC3515 section 2.1.

IMO, this could be treated as *some level* normative definition, or at least guidelines.

But there's nothing about Join header embedded in URL, in any of RFCs. So, I can just treated it as something like a private extension, just like one vendor put a "XXX" header embedded.

And the UAS's vendor would ask you how should they behaving and where is the specification/rule? (And this is usual in interworking testing).

Thanks,

Gao

---

From: [email-masked]
Date: Wed, 13 Oct 2010 00:56:31 +0800

> From a SIP protocol perspective, I don't think embedded headers have
> any semtantics - until they become "real headers" in the request 
> triggered by the REFER.

Could one specific header be used as embedded header in the Refer-To 
header and the REFER method? 
Might we need something more than just character transformation(such as 
?/=)?  //please see my sencond point for streams type, streams direction 
indication.

These things could be thought as the semantics for the embedded headers.

To make thing clear, I'd like to split the question:

1. Do we need a Draft to define/clarify the Join header's embedded usage 
in Refer-To?

2. Does the Join header's embedded usage need extension, for streams type, 
streams direction indication?

Thanks,

Gao

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 12 Oct 2010 19:10:30 +0200

Hi, 

>Could one specific header be used as embedded header in the Refer-To header and the REFER method?

As far as I know, there are no explicit restrictions.

One could, however, ask whether it's allowed to include headers that are not to be used in the triggered INVITE, but in later associated requests.

For example, could I include an embedded RAck header, which will not be used by the triggered INVITE, but later for a PRACK associated with that INVITE?

>Might we need something more than just character transformation(such as ?/=)?  //please see my sencond point for streams type, streams direction 
>indication. 

You CAN also embed SDP information.

Regards,

Christer

>1. Do we need a Draft to define/clarify the Join header's embedded usage in Refer-To? 
>	
>2. Does the Join header's embedded usage need extension, for streams type, streams direction indication? 

	Thanks, 
	
	Gao

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 12 Oct 2010 19:19:17 +0200

Ok, RAck was a bad example, because it's genereated based on the RSeq in the provisional response. 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Christer Holmberg
> Sent: 12. lokakuuta 2010 20:11
> To: [email-masked]
> Cc: Worley, Dale R (Dale); [email-masked]
> One could, however, ask whether it's allowed to include 
> headers that are not to be used in the triggered INVITE, but 
> in later associated requests.
> 
> For example, could I include an embedded RAck header, which 
> will not be used by the triggered INVITE, but later for a 
> PRACK associated with that INVITE?
> 
> >?/=)?  //please see my sencond point for streams type, 
> streams direction indication.
> 
> >2. Does the Join header's embedded usage need extension, for 
> streams type, streams direction indication? 
> 
> 
> 	
> 	Thanks, 
> 	
> 	Gao
> 	
> 	ZTE Information Security Notice: The information 
> contained in this mail is solely property of the sender's 
> organization. This mail communication is confidential. 
> Recipients named above are obligated to maintain secrecy and 
> are not permitted to disclose the contents of this 
> communication to others.
> 	This email and any files transmitted with it are 
> confidential and intended solely for the use of the 
> individual or entity to whom they are addressed. If you have 
> received this email in error please notify the originator of 
> the message. Any views expressed in this message are those of 
> the individual sender.
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 12 Oct 2010 15:14:16 -0400

> One could, however, ask whether it's allowed to include headers that are not to be used in the triggered INVITE, but in later associated requests.

The semantics of headers embedded in a URI is defined by 3261, and only 
defined when the URI is used as an R-URI of a request. In that case they 
get added to the request.

If you have some header you want used in a different way, I don't know 
how you would accomplish that.

	Thanks,
	Paul

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Tue, 12 Oct 2010 15:23:10 -0400

In regard to how the recipient of the REFER is expected to see the embedded header, the semantics are extremely well defined:  The recipient is to use the text provided to construct a Replaces header (or a Join header, or whatever).  The recipient is *not* to have any other understanding of the embedded header.  If additional information is to be conveyed to the recipient of the REFER, some other method must be found for conveying that information.

Of course, the recipient of the generated INVITE processes the Replaces header in the manner provided in the definition of Replaces...

----

In regard to how an INVITE with Replaces or Join is to manipulate the various media streams that are involved, if we pay attention to the protocol layering of SIP vs. SDP, it's clear that any specification of handling the media streams must be provided by the SDP (or some other contained protocol) rather than SIP itself, because the definition of the media streams is not visible to SIP.  From SIP's point of view, it transports the bodies of INVITEs and does not care what those bodies mean.  Indeed, one can use SIP without creating media streams at all.

Dale

---

From: [email-masked]
Date: Wed, 13 Oct 2010 16:08:34 +0800

> One could, however, ask whether it's allowed to include headers that
> are not to be used in the triggered INVITE, but in later associated 
requests.

RFC3261 section 19.1.5

An implementation MUST include any provided transport, maddr, ttl, or
   user parameter in the Request-URI of the formed request.  If the URI
   contains a method parameter, its value MUST be used as the method of
   the request.  The method parameter MUST NOT be placed in the
   Request-URI.  Unknown URI parameters MUST be placed in the message's
   Request-URI.

   An implementation SHOULD treat the presence of any headers or body
   parts in the URI as a desire to include them in the message, and
   choose to honor the request on a per-component basis.

An implementation SHOULD NOT honor these obviously dangerous header
   fields: From, Call-ID, CSeq, Via, and Record-Route.

>From the above text, it seams that the rules for embedded headers is not 
as emphatic as transport, maddr, ttl and user parameter. So, I suggest 
that one specific embedded headers could have a specific usage guidelines, 
especially these headers with dangerous header fields.

I'd like to point out that I am not going to say that people's 
understanding of embedded headers(for pure audio usage) is not correct.

> You CAN also embed SDP information.

Are there any defined rules for such embedded SDP information? If there 
are, could you show me.

Thanks,

Gao

---

From: [email-masked]
Date: Wed, 13 Oct 2010 16:31:35 +0800

> In regard to how the recipient of the REFER is expected to see the 
> embedded header, the semantics are extremely well defined:  The 
> recipient is to use the text provided to construct a Replaces header
> (or a Join header, or whatever).  The recipient is *not* to have any
> other understanding of the embedded header.  If additional 
> information is to be conveyed to the recipient of the REFER, some 
> other method must be found for conveying that information.

Please refer to my response to Christer. It seams that the rules for 
embedded headers is not as emphatic as transport, maddr, ttl and user 
parameter. 

Thanks,

Gao

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 13 Oct 2010 08:35:33 -0400

Gao,

Some of us have talked from time to time about issues with REFER.
(I think Dale wrote a draft about it once.)

Specifically, there is an element of "do what I mean" to it that 
requires the recipient to be psychic about what is intended.

E.g. I can send a REFER ... method=FOO to you. You may have no clue what 
method FOO is. Should you just construct a generic FOO method and send 
it? Or I could send an embedded header that says "Supported:BAR", when 
in fact you don't know about option BAR.

Hence the latitude for the referred UA to pick and choose what it wants 
to honor. At least that way it can have some assurance that it 
understands how to process the resulting request. But of course that 
means the referring party doesn't know if the request followed its 
intentions.

I don't have a good answer for that. Something that comes to mind is for 
a copy of the resulting request to be sent to the referring UA as part 
of the refer subscription. But it would be difficult to make good use of 
that.

	Thanks,
	Paul

On 10/13/2010 4:08 AM, [email-masked] wrote:
>  From the above text, it seams that the rules for embedded headers is
> not as emphatic as transport, maddr, ttl and user parameter. So, I
> suggest that one specific embedded headers could have a specific usage
> guidelines, especially these headers with dangerous header fields.
>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 13 Oct 2010 14:41:57 +0200

Hi,

IF one wants to define specific behavior for the receiver of the REFER, I guess one could define an option-tag, associated with that behavior, which is inserted in the Require/Supported header field of the REFER request.

Regards,

Christer

> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: 13. lokakuuta 2010 15:36
> To: [email-masked]
> Specifically, there is an element of "do what I mean" to it 
> that requires the recipient to be psychic about what is intended.
> 
> E.g. I can send a REFER ... method=FOO to you. You may have 
> no clue what method FOO is. Should you just construct a 
> generic FOO method and send it? Or I could send an embedded 
> header that says "Supported:BAR", when in fact you don't know 
> about option BAR.
> 
> Hence the latitude for the referred UA to pick and choose 
> what it wants to honor. At least that way it can have some 
> assurance that it understands how to process the resulting 
> request. But of course that means the referring party doesn't 
> know if the request followed its intentions.
> 
> I don't have a good answer for that. Something that comes to 
> mind is for a copy of the resulting request to be sent to the 
> referring UA as part of the refer subscription. But it would 
> be difficult to make good use of that.
> 
> 	Thanks,
> 	Paul
> 
> >  > One could, however, ask whether it's allowed to include headers 
> > that  > are not to be used in the triggered INVITE, but in later 
> > associated requests.
> >
> > RFC3261 section 19.1.5
> >
> > Are there any defined rules for such embedded SDP information? If 
> > there are, could you show me.
> >
> > Thanks,
> >
> > Gao
> >
> contained  in  this  mail  is  solely  property  of  the  
> sender's  organization.  This  mail  communication  is  
> confidential.  Recipients  named  above  are  obligated  to  
> maintain  secrecy  and  are  not  permitted  to  disclose  
> the  contents  of  this  communication  to  others.
> individual  or  entity  to  whom  they  are  addressed.  If  
> you  have  received  this  email  in  error  please  notify  
> the  originator  of  the  message.  Any  views  expressed  in 
>  this  message  are  those  of  the  individual  sender.

---

From: [email-masked]
Date: Thu, 14 Oct 2010 17:21:11 +0800

Christer,
 
> IF one wants to define specific behavior for the receiver of the 
> REFER, I guess one could define an option-tag, associated with that 
> behavior, which is inserted in the Require/Supported header field of
> the REFER request.

IMO, the UAC of REFER should show its function level demand for the 
session, which would be created by the UAS of REFER. If the function level 
demand have the inferation in signalling level, such as require/support 
some headers, the UAS could do it by it's judgement. 

Thanks,

Gao

---

From: [email-masked]
Date: Thu, 14 Oct 2010 23:38:24 +0800

Paul,

> that.

I have the same feeling as you for it, though we have opposite 
understanding(I think the UAS should do *semantic* check and *may* have 
the right to choose the headers to be honored, while you think it is just 
copy).

But for the pure audio usage, the copy way is working. And there's no 
explicit use case to sustain more detailed discussion/analysis. So, I 
think that this issue can be closed, at least for now.

While, there's another issue about indication for streams in the 
REFER_with_embedded_Join request. Dale and Christer suggested on it. And I 
will think it for details, and choose a proper WG to continue.

Thanks,

Gao

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 15 Oct 2010 08:49:40 -0400

Gao,

I presume you will be attending the meeting in Beijing?

This might be a good topic for a hallway discussion.

	Thanks,
	Paul

On 10/14/2010 11:38 AM, [email-masked] wrote:
> the right to choose the headers to be honored, while you think it is
> just copy).
>
> REFER_with_embedded_Join request. Dale and Christer suggested on it. And
> I will think it for details, and choose a proper WG to continue.
>
> Thanks,
>
> Gao
>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 15 Oct 2010 14:53:06 +0200

Hi,

I think such discussion would be good, and I would like to participate.

Regards,

Christer

> Sent: 15. lokakuuta 2010 15:50
> To: [email-masked]
> Cc: [email-masked]
> >  > I don't have a good answer for that. Something that 
> comes to mind 
> > is for  > a copy of the resulting request to be sent to the 
> referring 
> > UA as part  > of the refer subscription. But it would be 
> difficult to 
> > make good use of  > that.
> >
> > understanding(I think the UAS should do *semantic* check and *may* 
> > have the right to choose the headers to be honored, while 
> you think it 
> > is just copy).
> >
> > REFER_with_embedded_Join request. Dale and Christer 
> suggested on it. 
> > And I will think it for details, and choose a proper WG to continue.
> >
> > Thanks,
> >
> > Gao
> >