Subject: [Sipping] Dialog event packages

From: "Dale Worley" <[email-masked]>
Date: Fri, 10 Jun 2005 15:10:38 -0400

We've started implementing call-control features that depend on the dialog
event package, and it looks like some clarification and amendments are
needed to the current I-D.  I'm circulating a draft of my observations to
see if anyone has any comments on them.

Thanks,

Dale
----------------------------------------------------------------------------
----
    Further clarifications needed regarding dialog event packages

		  draft-ietf-sipping-dialog-package

This is a discussion of some practical problems we have had
implementing call control features in the sipX SIP PBX system, and
improvements in the specification of dialog event packages that would
help.

1. Local and remote elements

Section 4.1.6 specifies that the event package shall contain "local"
and "remote" elements containing identification of the endpoints of
the dialog.  E.g.,

        <local>
          <identity display="Alice">sip:[email-masked]</identity>
          <target uri="sip:[email-masked]"/>
        </local>
        <remote>
          <identity display="Bob">sip:[email-masked]</identity>
          <target uri="sip:[email-masked]"/>
        </remote>

A little though shows that the sensible way to populate these fields
is:

	Field		Value when		Value when
			direction=initiator	direction=recipient

	local identity	From: value		To: value
			in INVITE		in INVITE

	local target	Contact: value		Contact: value
			in INVITE		in 200

	remote identity	To: value		From: value
			in INVITE		in INVITE

	remote target	Contact: value		Contact: value
			in 200			in INVITE

However, of the phone models we have tested, none provide all four of
these values.  One or more fields is either missing or duplicates
another field.

In order to make the dialog event package a useful source of
information for call control processing, we need to standardize the
use of these fields.

2. Meaning of request URI, or "resource", of SUBSCRIBE.

The theory is that the request URI of the SUBSCRIBE request describes
the "resource" to which the subscription applies.  RFC 3265 discusses
this in very general terms, but draft-ietf-sipping-dialog-package
gives very little additional information.

It seems intuitive that a subscription provides dialog event packages
for dialogs to/from the same user as the request URI of the SUBSCRIBE.
But the situation is probably more complicated than it seems -- what
URI, exactly, is a dialog "to"?

It seems in practice that phones pay attention to the user part of the
resource URI, and match it with the user part of an incoming dialog's
request URI, or with the an outgoing dialog's line identification.
(And since most phones accept any incoming INVITE regardless of the
user part, there is another case when the user part doesn't match any
known line identification in the phone -- Most phones report those
dialogs for any SUBSCRIBE.)

(And should a SUBSCRIBE with no user part in its URI get information
on all dialogs at that device?  Does this really matter, since such a
SUBSCRIBE cannot have been routed via a registration?  OTOH, it could
have been made using a contact URI from a dialog the phone
participated in.)

3. The <param> element.

Section 4.1.6.2 defines the <param> element of the <target> element.
It specifies that field-parameters from the target URIs should be
split out and represented using <param> elements separate from the
URI:

   It can contain a list of Contact header parameters in param
   sub-elements (such as those defined in [10]).  The param element
   contains two required attributes, pname and pval.  Boolean parameters
   are represented by the explicit pval values "true" and "false" (for
   example when a feature parameter is explicitly negated).

This method seems to me to be less desirable than an alternative
scheme:

   It can contain a list of Contact header parameters in param
   sub-elements (such as those defined in [10]).  The param element
   contains required attributes, pname, which gives the parameter
   name.  If the parameter is present and has a value given, the pval
   attribute gives that value.  If the parameter is present but has no
   "=value" part, the pval attribute is absent.

For example,

   Contact: <sip:[email-masked]>;isfocus;class=personal;+sip.newparam

would be represented:

   <target uri="sip:[email-masked]">
     <param pname="isfocus"/>
     <param pname="class" pval="personal"/>
     <param pname="+sip.newparam"/>
   </target>

The advantage of this convention is that the UA that generates the
dialog event package does not need to be aware of which parameters
have Boolean type.  And the list of parameters is extensible, so the
UA cannot know that.

We also need a clear statement of whether and how escaping is removed
from the parameters.  The only escaping mechanism available is if the
parameter value (a "gen-value" in the grammar of RFC 3261) is a
"quoted-string", which allows most characters to be escaped with "\".
I would suggest that the pval attribute contains the un-escaped, un-quoted
parameter value.

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 10 Jun 2005 19:32:48 -0400

> see if anyone has any comments on them.

[snip]

> dialogs for any SUBSCRIBE.)

I think there are two separate issues being mixed here:

- what do deployed devices currently do. This is important if you
   want to get something working right now with existing stuff

- how *should* this work - how was it intended to work.

Ideally the answers would be the same, but the world is rarely ideal.

I think on sipping we should be concerned with how it *should* work.

IMO UAs should only accept requests addressed to URIs that the UA has 
explicitly advertised for use. This includes contact addresses placed in 
REGISTER messages, in published PIDF documents, in 3xx responses, and in 
the contact headers of dialog establishing requests and their responses. 
(I am sure there are others as well, but in all cases the address 
originates with the UA in question and is explicitly distributed to others.

When an INVITE is sent to an AoR and then forwarded to the UA, the UA 
perceives (from the R-URI) this as having been addressed to the contact 
that had been registered for that AoR. That is the target of the dialog 
that is established.

When a subscription for the dialog event is addressed to the AoR, it too 
is forwarded to the corresponding registered contact address and the UA 
perceives this as the resource to which the subscription is addressed. 
It is then easy to associate to that resource the dialogs that had been 
established via incoming requests.

For dialogs that were initiated in the outgoing direction, the obvious 
resource to associate with is the contact that was included in the 
outgoing INVITE. If the goal is that both incoming and outgoing calls be 
associated with AoRs (a reasonable expectation), then outgoing calls 
should carry the same contact that was used to register with an AoR. 
This will then work for watchers that subscribe to the AoR, and to those 
who are in a call and subscribe within the dialog to track what the peer 
is doing.

I'm not sure I fully understood what you were suggesting. But it sounded 
like you were proposing that if phone.foo.com registers with AoR 
sip:[email-masked] then it should consider all references to sip:abc@* to 
be for the same resource. This can be made to work in certain cases, but 
there are lots of counterexamples, so it is a really bad general 
recommendation.

> have been made using a contact URI from a dialog the phone

*If* the UA advertised a contact with no user part then subscriptions to 
that should get info on precisely those dialogs associated with that, 
per the above.

If it didn't advertise that address then it should reject the subscription.

Note that just recently requirements for sip devices were being 
discussed. One of the requirements was around devices being selective 
about the addresses on which they receive requests. I believe the 
purpose was to reduce the exposure to being attacked by hackers guessing 
addresses.

	Paul

---

From: "Dale Worley" <[email-masked]>
Date: Tue, 14 Jun 2005 18:23:28 -0400

> From: Paul Kyzivat [mailto:[email-masked]]
>
recommendation.

At the least, we have to take note that all phones I've seen, when a
connection is made to AoR "[email-masked]" will use a Contact address like
"[email-masked]".  And it probably has to.  Of course, that is an address
that it advertises.  But at the least, let's be aware that phones
ubiquitously use addresses that aren't AoRs, and will have to accept
subscriptions for them.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 14 Jun 2005 19:10:09 -0400

Dale Worley wrote:
> "[email-masked]". 

They are free to do so if they wish, but are under no obligation to do 
so. I have been on a campaign for a long time to abolish examples like 
that precisely because such examples encourage implementors to believe 
it must be that way.

Consider the plight of a phone that is supposed to support two "lines", 
with AoRs sip:[email-masked] and sip:[email-masked]. If it uses 
[email-masked] as the contact for both it won't be able to tell which 
line was called.

> And it probably has to. 

Why would it have to? Because the phone is implemented that way, or 
because the registrar requires it?

For the time being it is conforming for the phone to be built with such 
a constraint, though that will impose limitations such as I just 
mentioned. It may however not be able to conform to the kind of 
requirements Henry is putting together for endpoints, which might 
require the ability to do exactly that.

It is definitely incorrect for a registrar to require such behavior.

> Of course, that is an address

Yup.

	Paul

---

From: "Dale Worley" <[email-masked]>
Date: Wed, 15 Jun 2005 15:04:01 -0400

> that precisely because such examples encourage implementors 

I'm new here -- What have you been proposing as an alternative?

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 15 Jun 2005 18:51:36 -0400

Dale - comments inline.

	Paul

Dale Worley wrote:
>>>connection is made to AoR "[email-masked]" will use a Contact 
>>
>>address like
>>
>>>"[email-masked]". 
>>
> I'm new here

Yeah, I thought you were a new name, but then I though maybe my memory 
was just bad. :-)

You know an awful lot for a newbie. How is that?

> -- What have you been proposing as an alternative?

That the endpoint put whatever they want. For example purposes I am 
inclined to use something pseudo-random like

	sip:xyzzy@@10.1.1.254

or something that correlates differently, such as:

	sip:[email-masked]
	sip:[email-masked]

E.g.

	REGISTER sip:atlanta.com
	To: sip:[email-masked]
	From: sip:[email-masked]
	Contact: sip:[email-masked]

	REGISTER sip:biloxi.com
	To: sip:[email-masked]
	From: sip:[email-masked]
	Contact: sip:[email-masked]

---

From: "Dale Worley" <[email-masked]>
Date: Thu, 16 Jun 2005 09:08:43 -0400

> Yeah, I thought you were a new name, but then I though maybe
> my memory was just bad. :-)
>

I like to hear myself talk, so I have to learn stuff to have something to
talk about.  ;-)

But seriously, my employer has me working on SIP, so I have to learn it.

> or something that correlates differently, such as:

A lot of SIP phones seem to use URIs like "sip:[email-masked];line=xuoslslk".

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 16 Jun 2005 11:49:13 -0400

> A lot of SIP phones seem to use URIs like "sip:[email-masked];line=xuoslslk".

And that too is fine. The point is that they can indeed put whatever 
they want. Nobody else should make any assumptions about how an endpoint 
names its contacts.

	Paul