Subject: [Sip] Re: Contents of Sip digest

From: "Marco Pissarello" <[email-masked]>
Date: Thu, 5 Feb 2004 07:43:34 +0100

Ing. Marco Pissarello

mobile: +39 3484786881
mobile: +39 3486090637
phone:  +39 0454856103
mail:   [email-masked]

-----Messaggio originale-----
Da: [email-masked] [mailto:[email-masked]] Per conto di
[email-masked]
Inviato: mercoledì 4 febbraio 2004 18.00
A: [email-masked]
Oggetto: Sip digest, Vol 1 #1250 - 9 msgs

Send Sip mailing list submissions to
	[email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
	https://www1.ietf.org/mailman/listinfo/sip
or, via email, send a message with subject or body 'help' to
	[email-masked]

You can reach the person managing the list at
	[email-masked]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Sip digest..."

Today's Topics:

   1. draft-ietf-sip-gruu-00 (Orit Levin)
   2. Re: draft-ietf-sip-gruu-00 (Dean Willis)
   3. Re: I-D ACTION:draft-ietf-sip-publish-02.txt (Jonathan Rosenberg)
   4. Re: draft-ietf-sip-gruu-00 (Jonathan Rosenberg)
   5. Call transfer using SIP ([email-masked])
   6. Re: Call transfer using SIP (Paul Kyzivat)
   7. Re: Call transfer using SIP (Conroy, Lawrence (SMTP))
   8. RE: Call transfer using SIP ([email-masked])
   9. RE: Call transfer using SIP (Chris Boulton)

--__--__--

Message: 1
Date: Tue, 3 Feb 2004 14:58:25 -0800
From: "Orit Levin" <[email-masked]>
To: "Jonathan Rosenberg" <[email-masked]>, <[email-masked]>
Subject: [Sip] draft-ietf-sip-gruu-00

I have the following remarks regarding the GRUU draft:

1. The draft states that one of the GRUU properties is =20
"   o It MUST NOT be possible, based on inspection of the URI, to
determine the associated Contact URI or Address of Record."

It MUST be possible to achieve such a property for a GRUU (if the
Registrar wants to enforce such a policy for its domain), but it is not
part of the requirements for the GRUU concept to always enforce such a
policy.

2. It is expressed throughout the draft that=20
"This extension allows a UA to obtain a GRUU, and to use a GRUU. These
two mechanisms are separate, in that a UA can obtain a GRUU in any way
it likes, and use the mechanisms in this specification to use them.
Similarly, a UA can obtain a GRUU but never use it."

For consistency, I suggest in section "6.2 Using the GRUU" change the
first sentence from

   "A UA first obtains a GRUU using the procedures of Section 6.1."
to=20
   "A UA first obtains a GRUU using the procedures of Section 6.1 or by
other means".

Thanks,
Orit.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Jonathan Rosenberg
Sent: Monday, February 02, 2004 10:54 PM
To: Christian Jansson
Cc: Paul Kyzivat; [email-masked];
[email-masked]; [email-masked]; [email-masked]
Subject: Re: GRUU and UA instances, was: Re: [Sip] Subscribe dialog and
target refresh request

Christian Jansson wrote:

> Perhaps a little late, and hopefully not off topic. Comments inline.

Not too late, not off topic.

>=20
>=20
>>Jonathan R. wrote
>>This, however, leads me into thinking a bit on the lifecycle
>>management for GRUUs. Currently, GRUU is bound to a single=20
>>registration, where the registration is defined by the Contact URI. If
>=20
>=20
>>the UA should "move", in the sense that it acquires a new IP address,=20
>>this will be a new Contact URI, and therefore, a new GRUU. It would be
>>nice if, instead, the GRUU were truly bound to the UA instance, and=20
>>that even if the UA instance changed IP addresses, the GRUU could=20
>>remain unchanged. In such a case, if the UA moves, there is actually=20
>>no need to issue any target refresh requests. The UA would simply=20
>>re-register, update the binding of its GRUU to its new IP=20
>>address, and=20
>>existing calls would be correctly routed.
>=20
>=20
> But if the ip actually changes, it would be necessary to send an
updated
> SDP with the new ip in the c=3D line.

Yes, that is true. If media relays are used (i.e., TURN), it might be=20
possible to avoid even this, but lets leave that aside for now.

> So your idea won't save you from
> having to send a SIP request to the other end every time the ip
changes
> in an INVITE session.=20

Right. However, it does solve the problem that, previously, if both=20
endpoints moved at the same time, the call would fail - neither side=20
could signal the other.

> For a non-INVITE session though the idea would
> save a lot of request from being sent if the session only contains
> signaling.

Right, in particular, a long lived presence subscription, for example.

-Jonathan R.

--=20
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
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

--__--__--

Message: 2
Date: Tue, 03 Feb 2004 17:58:47 -0600
From: Dean Willis <[email-masked]>
To: Orit Levin <[email-masked]>,
        Jonathan Rosenberg <[email-masked]>, [email-masked]
Subject: Re: [Sip] draft-ietf-sip-gruu-00

Orit Levin wrote:
> I have the following remarks regarding the GRUU draft:
> 
> 1. The draft states that one of the GRUU properties is  
> "   o It MUST NOT be possible, based on inspection of the URI, to
> determine the associated Contact URI or Address of Record."
> 
> It MUST be possible to achieve such a property for a GRUU (if the
> Registrar wants to enforce such a policy for its domain), but it is not
> part of the requirements for the GRUU concept to always enforce such a
> policy.

I have to admit I concur with this position. There might be very useful 
situations where the anonymity aspect of the GRUU would be undesirable.

I can even envision models where the GRUU is cryptographically 
validatable as representing an instance associated with a specific AOR, 
including variations where the validation can or cannot be done without 
prior knowledge of the associated AOR.

As far as I can tell, reversibility does not impact the given rationale 
for the requirements, that:

    With these rules, it is possible, though not required, to construct a
    GRUU without requiring the maintenance of any additional state. To do
    that, the URI would be constructed in the following fashion:

So I believe I would support making this a SHOULD strength requirement. 
Conceivably some discussion of the security implications of NOT meeting 
this requirement would be appropriate.

--
Dean

--__--__--

Message: 3
Date: Wed, 04 Feb 2004 00:54:24 -0500
From: Jonathan Rosenberg <[email-masked]>
Organization: dynamicsoft
To: [email-masked]
CC: [email-masked]
Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-publish-02.txt

[email-masked] wrote:

> Hi Jonathan,
> 
> Thanks a lot for the excellent comments. Most of them I will directly
> fold into -03. Few clarifications below.
> 
> Cheers, Aki
> 
> Jonathan Rosenberg wrote:
> 
> <snip />
> 
>> * section 3, paragraph 3:
>> 
>>> That is, the steady-state of this event package in the absence
>>> of, or in addition
>> to, soft state
>>> provided through the PUBLISH mechanism
>> 
>> this makes it sound like steady state is a function of the event 
>> packae only. the hard state is a function of the resource uRI and 
>> event package. Indeed, one may think of an event package as merely
>>  sub-resource within the full resource. I wonder if it wouldn't be
>>  useful to come up with a term for this - for example, "scoped 
>> resource" is a combination of a URI and event package, and 
>> identifies a particular piece of event state.
> 
> I don't quite follow,  but I agree the quoted text is rather vague.
> To me the hard state, or "preconfigured" state is just another source
> of event state to the composer. The mechanism to set that state might
> be other than PUBLISH.

Right. I agree with that. Let me try again. Requoting the paragraph:

    PUBLISH requests create soft state in the ESC. This state has a
    defined lifetime and will expire after a negotiated amount of time,
    requiring the publication to be refreshed by subsequent PUBLISH
    requests. Local policy at the compositor may in turn define hard
    state for a particular event package. That is, the steady-state of
    this event package in the absence of, or in addition to, soft state
    provided through the PUBLISH mechanism. Setting this hard state or
    configuring the composer policy is out of the scope of this
    specification.

The words "hard state for a particular event package" read to me like it 
meant that hard state was defined on a package by package basis. But, 
its not. There would be hard state generally for a particular 
URI/package basis. So, I'd suggest:

     There may also be hard state provisioned for each resource for
     a particular event package. This hard state represents the resource
     state that is present at all times, and does not expire.

My other comment was that the concept of "for each resource for each 
package" is a common concept, for which I was looking for a term to define.

> 
> <snip />
> 
>> * section 5.1:
>> 
>>> As with any other SIP message, the PUBLISH mechanism MAY use the 
>>> content indirection mechanism defined in [10].
>> 
>> this statement makes [10] a normative reference, I believe. It is 
>> listed as informative in the references section.
> 
> I'm not sure I agree. I've understood the RFC editor's policy so that
> an informative reference is not required for implementing the RFC.
> It's an interesting question as to how this relates to RFC 2119
> terminology. But I think a MAY makes the feature optional so that it
> fits the informative reference definition.

No - Keith is right in his note. Think of it this way - would the 
feature interop if, one day, the referenced I-D evaporated and people 
implemented it differently? In this case, no. If they chose to implement 
the content indirection, and there was no spec, they would do it 
differently and there would be no interop.

I would just drop the text to avoid the dependency.

> 
> <snip />
> 
>> * section 5.3 is out of place. Section 5 is about generating 
>> requests. the subsections for the most part deal with the specific
>> 4 sub-cases you identified in 5.1. However, 5.3 talks about setting
>> expirations, which is something that is actually done for the cases
>> in 5.2, 5.4, 5.5 and 5.6. I would suggest that eaech of those four
>>  sections rather describe how the Expires header field is
>> constructed for each case. That is consistent with having a column
>> in table 1 on expires. Indeed, each section should also talk about
>> bodies and etag. Along those lines, section 5.2 does not actually
>> say that a body has to be present; it shouold be stated given the
>> importance of this fact from table 1.
> 
> I think the reason for this is that I envisioned a PUBLISH carrying
> state in some other place than the body. However, I don't know if
> such a case would ever exist, and other people have also commented on
> this. I think it is safe to assume that the state is always carried
> in the body, as opposed to "typically".

Yes.

>> * the steps in section 6 omit handling for the case where there was
>> no SIP-If-Match header field. step 6 says to check for it, and all
>> the following steps assume it was there. I would suggest adding a
>> bullet to step 6 which says, if there was no SIP-If-Match header
>> field, the ESC creates a new etag, and associates it with as-yet
>> empty event state. Processing continues in the steps below. This
>> way, you always exit step 6 with an etag.
> 
> The attempt was to make etag generation part of step 9. This way, an
> entity-tag is generated for each successful publication and returned
> in 2xx, irrespective of whether the publication was an initial
> publication, a refresh, or a modification. Indeed, a 2xx to a removal
> could be treated the same, although such an entity-tag is useless at
> that point.
> 
> So I think it is ok to exit step 6 without an entity tag, as long as
> step 9 is clear that entity-tags are generated for all successful
> publications.
> 

Step 8 requires an entity tag to be defined, however.

>> * sectiton 11.1:
>> 
>>> Authentication issues are discussed in SIP [2]. The exact
>> methods for
>>> creation and manipulation of the ESC authorization policies are 
>>> outside the scope of this document.
>> 
>> you will get dinged on this by Bellovin, guaranteed. He wants to
>> see statements about baseline mandtory to implement mechahnisms. 
>> Its fine to say that this mechanism is digest, as mandated by
>> rfc3261.
>> 
>>> To prevent replay attacks, implementations SHOULD require 
>>> authentication with anti-replay protection.
>> Authentication issues are
>>> discussed in SIP [2].
>> 
>> as above.... does this mean digest with next-nonce or are you
>> talking sips?
>> 
>> and section 11.4:
>> 
>>> To prevent such attacks, implementations SHOULD, at a minimum, 
>>> provide integrity protection across the To, From, Event, 
>>> SIP-If-Match, Route, and Expires headers and the bodies
>> of PUBLISH
>>> requests.
>> 
>> as above, he will ask for a mechanism. This requiurement makes the
>>  choice sips.
>> 
>> Same in 11.5.
> 
> I see what you are saying. But is it really so that each new method
> that gets added to SIP needs to explicitly mandate certain security
> mechanisms? At least going beyond the security considerations in RFC
> 3261 seems unnecessary, since the properties of PUBLISH are very
> similar to, say, REGISTER.

I have made this same comment in past discussions of specs going through 
iesg. However, the security ADs believe strongly in reptition of 
security requirements in specifications. Trust me, you WILL get dinged 
on this. It is much easier to just add text stating the same normative 
requiremetns as in rfc3261, then to get a discuss during iesg evaluation.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

--__--__--

Message: 4
Date: Wed, 04 Feb 2004 01:03:16 -0500
From: Jonathan Rosenberg <[email-masked]>
Organization: dynamicsoft
To: Dean Willis <[email-masked]>
CC: Orit Levin <[email-masked]>, [email-masked]
Subject: Re: [Sip] draft-ietf-sip-gruu-00

inline.

Dean Willis wrote:

> Orit Levin wrote:
> 
>> I have the following remarks regarding the GRUU draft:
>>
>> 1. The draft states that one of the GRUU properties is  "   o It MUST 
>> NOT be possible, based on inspection of the URI, to
>> determine the associated Contact URI or Address of Record."
>>
>> It MUST be possible to achieve such a property for a GRUU (if the
>> Registrar wants to enforce such a policy for its domain), but it is not
>> part of the requirements for the GRUU concept to always enforce such a
>> policy.
> 
> 
> I have to admit I concur with this position. There might be very useful 
> situations where the anonymity aspect of the GRUU would be undesirable.
> 
> I can even envision models where the GRUU is cryptographically 
> validatable as representing an instance associated with a specific AOR, 
> including variations where the validation can or cannot be done without 
> prior knowledge of the associated AOR.
> 
> As far as I can tell, reversibility does not impact the given rationale 
> for the requirements, that:
> 
>    With these rules, it is possible, though not required, to construct a
>    GRUU without requiring the maintenance of any additional state. To do
>    that, the URI would be constructed in the following fashion:
> 
> So I believe I would support making this a SHOULD strength requirement. 
> Conceivably some discussion of the security implications of NOT meeting 
> this requirement would be appropriate.

I am ok to lessen the requirement.

The question becomes, do we want a way to allow the client to signal 
that a randomized gruu is desired, or is it up to the server? I would 
much prefer to leave it up to the server, in which case the only thing 
that we need to change is the requirement, above. I changed the text to 
read:

<t>In many cases, it will be desirable to construct the GRUU in such a
way that it will not be possible, based on inspection of the URI, to
determine the associated Contact URI or Address of Record. Whether or
not a GRUU should be constructed with this property is a local policy
decision of the administrator.
</t>

Orit writes:
> 2. It is expressed throughout the draft that 
> "This extension allows a UA to obtain a GRUU, and to use a GRUU. These
> two mechanisms are separate, in that a UA can obtain a GRUU in any way
> it likes, and use the mechanisms in this specification to use them.
> Similarly, a UA can obtain a GRUU but never use it."
> 
> For consistency, I suggest in section "6.2 Using the GRUU" change the
> first sentence from
> 
>    "A UA first obtains a GRUU using the procedures of Section 6.1."
> to 
>    "A UA first obtains a GRUU using the procedures of Section 6.1 or by
> other means".

OK, with the addition of "outside the scope of this specification.".

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

--__--__--

Message: 5
From: [email-masked]
To: [email-masked]
Date: Wed, 4 Feb 2004 10:04:49 -0000 
Subject: [Sip] Call transfer using SIP

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C3EB06.531F57C0
Content-Type: text/plain;
	charset="iso-8859-1"

Could somebody please confirm that if I am writing a call control
application offering call hold and transfer then the definitive document to
follow is draft-ietf-sipping-service-examples-05.txt?

Matthew Gardiner
Software Engineer
Aculab 
Tel: +44 (0) 1908 273 911
Fax: +44 (0) 1908 273 801
Email: mailto:[email-masked]
Website: <http://www.aculab.com>

For Aculab's privacy policy and E-Mail disclaimer, Click Here :
http://www.aculab.com/company/legal_notice.htm. 

------_=_NextPart_001_01C3EB06.531F57C0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>Call transfer using SIP</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">Could somebody please confirm that if =
I am writing a call control application offering call hold and transfer =
then the definitive document to follow is =
draft-ietf-sipping-service-examples-05.txt?</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Matthew Gardiner</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Software Engineer<BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">Aculab</FONT><FONT SIZE=3D2 =
FACE=3D"Times New Roman"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">Tel: +44 (0) 1908 273 =
911</FONT><BR>
<FONT SIZE=3D2 FACE=3D"Arial">Fax: +44 (0) 1908 273 801</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Email: <A =
HREF=3D"mailto:[email-masked]">mailto:matthew.gardiner@acul=
ab.com</A></FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Website:<U> </U></FONT><U><FONT =
COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">&lt;<A =
HREF=3D"http://www.aculab.com" =
TARGET=3D"_blank">http://www.aculab.com</A>&gt;</FONT></U>
</P>
<BR>
<BR>
<BR>

<P><B><FONT SIZE=3D1 FACE=3D"Arial">For Aculab's privacy policy and =
E-Mail disclaimer, Click Here : <A =
HREF=3D"http://www.aculab.com/company/legal_notice.htm" =
TARGET=3D"_blank">http://www.aculab.com/company/legal_notice.htm</A>. =
</FONT></B>
</P>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C3EB06.531F57C0--

--__--__--

Message: 6
Date: Wed, 04 Feb 2004 10:07:14 -0500
From: Paul Kyzivat <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: [Sip] Call transfer using SIP

[email-masked] wrote:
> Could somebody please confirm that if I am writing a call control 
> application offering call hold and transfer then the definitive document 
> to follow is draft-ietf-sipping-service-examples-05.txt?

No. The *definitive* document is RFC3261 and related documents. The 
details of call control are derivative from that in somewhat the same 
way the much of physics is derivative from F=MA.

Draft-ietf-sipping-service-examples-05.txt is (not surprisingly) an 
*example*. It is not normative.

However, that draft is certainly helpful and educational. You would do 
well to understand what is in there before completing your task.

	Paul

--__--__--

Message: 7
From: "Conroy, Lawrence (SMTP)" <[email-masked]>
To: Paul Kyzivat <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [Sip] Call transfer using SIP
Date: Wed, 4 Feb 2004 16:09:52 +0000

Hi folks,
   It's an interesting point.
Paul's comment seems to be "there are many different ways of skinning a 
cat, and the
only normative definition is of the knife".
The IETF defines the details of knife behaviour, and it's up to 
everyone else to sort
out how to use it for their purpose.

My understanding is that the IETF (and the SIP WG in particular) will 
not produce normative
definitions of these (or any other) teleservices, only definitions of 
protocol elements that
might be used for these (or other) purposes.
SIPPING will consider such services and decide on the protocol elements 
they think are needed
(that don't exist already) and then SIP grinds through the details.

Thus the only teleservice examples are in the service-examples document 
(collected together
as a convenience), these are non-normative, and there will never BE 
normative teleservice
definitions produced by these groups. Is this correct?

all the best,
   Lawrence

On 4 Feb 2004, at 3:07 pm, Paul Kyzivat wrote:

>
>
> [email-masked] wrote:
>> Could somebody please confirm that if I am writing a call control 
>> application offering call hold and transfer then the definitive 
>> document to follow is draft-ietf-sipping-service-examples-05.txt?
>
> No. The *definitive* document is RFC3261 and related documents. The 
> details of call control are derivative from that in somewhat the same 
> way the much of physics is derivative from F=MA.
>
> Draft-ietf-sipping-service-examples-05.txt is (not surprisingly) an 
> *example*. It is not normative.
>
> However, that draft is certainly helpful and educational. You would do 
> well to understand what is in there before completing your task.
>
> 	Paul
>
>
> _______________________________________________
> 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
>

--__--__--

Message: 8
From: [email-masked]
To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: RE: [Sip] Call transfer using SIP
Date: Wed, 4 Feb 2004 16:24:01 -0000 

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C3EB3B.4C9F6C20
Content-Type: text/plain;
	charset="iso-8859-1"

This vagueness makes it very difficult to engineer a telephony solution
which interoperates with other vendors equipment. In the telephony arena
getting call transfer right is of fundamental importance. A simple document
titled "Call transfer in SIP" would suffice in de-mystifying this area.

-----Original Message-----
From: Conroy, Lawrence (SMTP) [mailto:[email-masked]]
Sent: 04 February 2004 16:10
To: Paul Kyzivat
Cc: [email-masked]; [email-masked]
Subject: Re: [Sip] Call transfer using SIP

Hi folks,
   It's an interesting point.
Paul's comment seems to be "there are many different ways of skinning a 
cat, and the
only normative definition is of the knife".
The IETF defines the details of knife behaviour, and it's up to 
everyone else to sort
out how to use it for their purpose.

My understanding is that the IETF (and the SIP WG in particular) will 
not produce normative
definitions of these (or any other) teleservices, only definitions of 
protocol elements that
might be used for these (or other) purposes.
SIPPING will consider such services and decide on the protocol elements 
they think are needed
(that don't exist already) and then SIP grinds through the details.

Thus the only teleservice examples are in the service-examples document 
(collected together
as a convenience), these are non-normative, and there will never BE 
normative teleservice
definitions produced by these groups. Is this correct?

all the best,
   Lawrence

On 4 Feb 2004, at 3:07 pm, Paul Kyzivat wrote:

>
>
> [email-masked] wrote:
>> Could somebody please confirm that if I am writing a call control 
>> application offering call hold and transfer then the definitive 
>> document to follow is draft-ietf-sipping-service-examples-05.txt?
>
> No. The *definitive* document is RFC3261 and related documents. The 
> details of call control are derivative from that in somewhat the same 
> way the much of physics is derivative from F=MA.
>
> Draft-ietf-sipping-service-examples-05.txt is (not surprisingly) an 
> *example*. It is not normative.
>
> However, that draft is certainly helpful and educational. You would do 
> well to understand what is in there before completing your task.
>
> 	Paul
>
>
> _______________________________________________
> 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
>

-- 
Registered Office: Roke Manor Research Ltd, Siemens House, Oldbury,
Bracknell,
Berkshire. RG12 8FZ

The information contained in this e-mail and any attachments is confidential
to
Roke Manor Research Ltd and must not be passed to any third party without
permission. This communication is for information only and shall not create
or
change any contractual relationship.

For Aculab's privacy policy and E-Mail disclaimer, Click Here :
http://www.aculab.com/company/legal_notice.htm. 

------_=_NextPart_001_01C3EB3B.4C9F6C20
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: [Sip] Call transfer using SIP</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>This vagueness makes it very difficult to engineer a =
telephony solution which interoperates with other vendors equipment. In =
the telephony arena getting call transfer right is of fundamental =
importance. A simple document titled &quot;Call transfer in SIP&quot; =
would suffice in de-mystifying this area.</FONT></P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Conroy, Lawrence (SMTP) [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: 04 February 2004 16:10</FONT>
<BR><FONT SIZE=3D2>To: Paul Kyzivat</FONT>
<BR><FONT SIZE=3D2>Cc: [email-masked]; [email-masked]</FONT>
<BR><FONT SIZE=3D2>Subject: Re: [Sip] Call transfer using SIP</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Hi folks,</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; It's an interesting point.</FONT>
<BR><FONT SIZE=3D2>Paul's comment seems to be &quot;there are many =
different ways of skinning a </FONT>
<BR><FONT SIZE=3D2>cat, and the</FONT>
<BR><FONT SIZE=3D2>only normative definition is of the =
knife&quot;.</FONT>
<BR><FONT SIZE=3D2>The IETF defines the details of knife behaviour, and =
it's up to </FONT>
<BR><FONT SIZE=3D2>everyone else to sort</FONT>
<BR><FONT SIZE=3D2>out how to use it for their purpose.</FONT>
</P>

<P><FONT SIZE=3D2>My understanding is that the IETF (and the SIP WG in =
particular) will </FONT>
<BR><FONT SIZE=3D2>not produce normative</FONT>
<BR><FONT SIZE=3D2>definitions of these (or any other) teleservices, =
only definitions of </FONT>
<BR><FONT SIZE=3D2>protocol elements that</FONT>
<BR><FONT SIZE=3D2>might be used for these (or other) purposes.</FONT>
<BR><FONT SIZE=3D2>SIPPING will consider such services and decide on =
the protocol elements </FONT>
<BR><FONT SIZE=3D2>they think are needed</FONT>
<BR><FONT SIZE=3D2>(that don't exist already) and then SIP grinds =
through the details.</FONT>
</P>

<P><FONT SIZE=3D2>Thus the only teleservice examples are in the =
service-examples document </FONT>
<BR><FONT SIZE=3D2>(collected together</FONT>
<BR><FONT SIZE=3D2>as a convenience), these are non-normative, and =
there will never BE </FONT>
<BR><FONT SIZE=3D2>normative teleservice</FONT>
<BR><FONT SIZE=3D2>definitions produced by these groups. Is this =
correct?</FONT>
</P>

<P><FONT SIZE=3D2>all the best,</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; Lawrence</FONT>
</P>

<P><FONT SIZE=3D2>On 4 Feb 2004, at 3:07 pm, Paul Kyzivat wrote:</FONT>
</P>

<P><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; [email-masked] wrote:</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; Could somebody please confirm that if I am =
writing a call control </FONT>
<BR><FONT SIZE=3D2>&gt;&gt; application offering call hold and transfer =
then the definitive </FONT>
<BR><FONT SIZE=3D2>&gt;&gt; document to follow is =
draft-ietf-sipping-service-examples-05.txt?</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; No. The *definitive* document is RFC3261 and =
related documents. The </FONT>
<BR><FONT SIZE=3D2>&gt; details of call control are derivative from =
that in somewhat the same </FONT>
<BR><FONT SIZE=3D2>&gt; way the much of physics is derivative from =
F=3DMA.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Draft-ietf-sipping-service-examples-05.txt is =
(not surprisingly) an </FONT>
<BR><FONT SIZE=3D2>&gt; *example*. It is not normative.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; However, that draft is certainly helpful and =
educational. You would do </FONT>
<BR><FONT SIZE=3D2>&gt; well to understand what is in there before =
completing your task.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Paul</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; Sip mailing list&nbsp; <A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/sip" =
TARGET=3D"_blank">https://www1.ietf.org/mailman/listinfo/sip</A></FONT>
<BR><FONT SIZE=3D2>&gt; This list is for NEW development of the core =
SIP Protocol</FONT>
<BR><FONT SIZE=3D2>&gt; Use [email-masked] for =
questions on current sip</FONT>
<BR><FONT SIZE=3D2>&gt; Use [email-masked] for new developments on =
the application of sip</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
</P>

<P><FONT SIZE=3D2>-- </FONT>
<BR><FONT SIZE=3D2>Registered Office: Roke Manor Research Ltd, Siemens =
House, Oldbury, Bracknell,</FONT>
<BR><FONT SIZE=3D2>Berkshire. RG12 8FZ</FONT>
</P>

<P><FONT SIZE=3D2>The information contained in this e-mail and any =
attachments is confidential to</FONT>
<BR><FONT SIZE=3D2>Roke Manor Research Ltd and must not be passed to =
any third party without</FONT>
<BR><FONT SIZE=3D2>permission. This communication is for information =
only and shall not create or</FONT>
<BR><FONT SIZE=3D2>change any contractual relationship.</FONT>
</P>
<BR>

<P><B><FONT SIZE=3D1>For Aculab's privacy policy and E-Mail disclaimer, =
Click Here : <A HREF=3D"http://www.aculab.com/company/legal_notice.htm" =
TARGET=3D"_blank">http://www.aculab.com/company/legal_notice.htm</A>. =
</FONT></B>
</P>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C3EB3B.4C9F6C20--

--__--__--

Message: 9
Subject: RE: [Sip] Call transfer using SIP
Date: Wed, 4 Feb 2004 16:35:00 -0000
From: "Chris Boulton" <[email-masked]>
To: "Conroy, Lawrence (SMTP)" <[email-masked]>,
        "Paul Kyzivat" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

Lawrence - remember that SIP is a transport protocol which allows an
objective to be reached in many differing ways.  There is no correct
behavior in many scenarios as long as they fall between the guidelines
set out.  It would be wrong to define normative behavior for such
scenarios and so a push in the right direction towards preferred methods
is the best approach.

Chris.

>-----Original Message-----
>From: Conroy, Lawrence (SMTP) [mailto:[email-masked]]
>Sent: 04 February 2004 16:10
>To: Paul Kyzivat
>Cc: [email-masked]; [email-masked]
>Subject: Re: [Sip] Call transfer using SIP
>
>Hi folks,
>   It's an interesting point.
>Paul's comment seems to be "there are many different ways of skinning a
>cat, and the
>only normative definition is of the knife".
>The IETF defines the details of knife behaviour, and it's up to
>everyone else to sort
>out how to use it for their purpose.
>
>My understanding is that the IETF (and the SIP WG in particular) will
>not produce normative
>definitions of these (or any other) teleservices, only definitions of
>protocol elements that
>might be used for these (or other) purposes.
>SIPPING will consider such services and decide on the protocol elements
>they think are needed
>(that don't exist already) and then SIP grinds through the details.
>
>Thus the only teleservice examples are in the service-examples document
>(collected together
>as a convenience), these are non-normative, and there will never BE
>normative teleservice
>definitions produced by these groups. Is this correct?
>
>all the best,
>   Lawrence
>
>On 4 Feb 2004, at 3:07 pm, Paul Kyzivat wrote:
>
>>
>>
>> [email-masked] wrote:
>>> Could somebody please confirm that if I am writing a call control
>>> application offering call hold and transfer then the definitive
>>> document to follow is draft-ietf-sipping-service-examples-05.txt?
>>
>> No. The *definitive* document is RFC3261 and related documents. The
>> details of call control are derivative from that in somewhat the same
>> way the much of physics is derivative from F=3DMA.
>>
>> Draft-ietf-sipping-service-examples-05.txt is (not surprisingly) an
>> *example*. It is not normative.
>>
>> However, that draft is certainly helpful and educational. You would
do
>> well to understand what is in there before completing your task.
>>
>> 	Paul
>>
>>
>> _______________________________________________
>> 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

This message has been scanned for viruses by MailControl - www.mailcontrol.=
com

--__--__--

_______________________________________________
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

End of Sip Digest

_______________________________________________
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