Subject: RE: [Sip] RE: [Sipping] Call and call-id

From: "Sean Olson (EUS)" <[email-masked]>
Date: Sat, 30 Jun 2001 11:53:59 -0500

The current state draft is intended to establish a "cookie" that lasts at
least for the duration of a call leg. The cookie is tied to a call leg based
on To/From/Call-ID. Furthermore cookies are returned based on the 
host/port in the State: header. If the Request-URI matches or any
of the Route: headers match this host/port, the State: header (cookie)
is returned.
 
There is the following text in the draft as well:

  4.      Additional rules MAY be defined by other extensions that specify
     when a State header is to be included in a request. An example of
     this would be extensions that handle call transfers and other
     features that would specify State header processing at the UAC.

This leaves open the possibility to define an extension that uses the
State: header in the manner you describe. However, I think what you
want to do is a bit at odds with the original intention of the draft. Having
a cookie that spans call legs would require a different set of rules defining
when a UAC should return a cookie in subsequent requests or a UAS in
the 1xx responses. 
 
I would like a more generic cookie mechanism, but I think the State: header
mechanism is a reasonable compromise in terms of processing at the UA.
The alternative would be to provide additional information in the State: header
which indicated when the State: header should be returned; similar to the
path that is included in HTTP cookies.
 
e.g.
State: host/port; call-id="...";from="..."; value
 
/sean

-----Original Message-----
From: Zmolek, Andrew (Andrew) [mailto:[email-masked]]
Sent: Friday, June 29, 2001 5:11 PM
To: Sean Olson (EUS); William Marshall; Zmolek, Andrew (Andrew)
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Sip] RE: [Sipping] Call and call-id

Would the re-use of a state header as a means of tying together multiple call legs cause problems with anything in the state draft as written? By persistence, I'm thinking more about using the token to re-establish some value-added context of a session terminated perhaps even days earlier, but even without that concept, I need any cookie replacement to not preclude token use across multiple call legs.
 
--Andy

-----Original Message-----
From: Sean Olson (EUS) [mailto:[email-masked]]
Sent: Wednesday, June 27, 2001 4:43 PM
To: Zmolek, Andrew (Andrew); William Marshall; [email-masked]
Cc: Sean Olson (EUS); [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Sip] RE: [Sipping] Call and call-id

The State: header is a SIP extension. I believe it can be used independently
of the other DCS extensions. The real issue is how widespread will the
extension be -- can you depend on "most" clients to support it. 
 
I'm not sure what you mean by "token persistence". Do you mean
a State: header that spans multiple call legs? 
 
/sean

-----Original Message-----
From: Zmolek, Andrew (Andrew) [mailto:[email-masked]]
Sent: Wednesday, June 27, 2001 4:27 PM
To: William Marshall; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Sip] RE: [Sipping] Call and call-id

Sounds like the State header may accomplish what we are considering with cookies; there may be no need to re-invent this. How tightly coupled is the State header and the DCS call model?  In other words, to support the State header will a device have to fully conform to DCS? Or is this required only to generate state? 

Moreover, how problematic would the introduction of token persistence be to the State header? Would this cause problems with DCS implementation? Another worry: If the State header and DCS are joined at the hip, then this might be too much for simple implementations to swallow even if our own products were to comply. How much support does this proposal have in the community right now?

--Andy Zmolek 
    Technology & Standards Engineer 
      CTO Standards 
        Avaya Inc. 

            [email-masked] 
              +1 720 444 4001 

-----Original Message----- 
From: William Marshall [ mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: Wednesday, June 27, 2001 11:59 AM 
To: [email-masked] 
Cc: [email-masked]; [email-masked]; 
[email-masked]; [email-masked]; 
[email-masked]; [email-masked]; [email-masked] 
Subject: RE: [Sip] RE: [Sipping] Call and call-id 

State headers operate in both directions.  A UAC that inserts a State header 
in the INVITE will see the contents returned in every provisional and final 
response, as well as any re-INVITE initiated by the UAS.  A UAS that 
inserts a State header into a provisional or final response will see 
the contents returned in every re-INVITE from the UAC, as well as 
provisional and final responses to requests initiated by the UAS. 
The State header is documented in draft-ietf-sip-state-01. 

Rules for handling of State headers with future extensions will need 
to be specified in the draft defining that extension. In particular, 
a REFER that is attempting to replace an existing call leg may need 
the State headers from the previous call leg attached to the new 
INVITE, along with the From/To/Call-ID.  This is all still to-be-defined. 

Bill Marshall 
[email-masked] 

-----original messaage----- 
Subject: RE: [Sip] RE: [Sipping] Call and call-id 
Date: Wed, 27 Jun 2001 10:57:08 -0600 
From: "Zmolek, Andrew (Andrew)" <[email-masked]> 
To: "Sean Olson (EUS)" <[email-masked]>, 
        "Chris Hogg" <[email-masked]>, 
        "Jonathan Rosenberg" <[email-masked]>, 
        "Mathieu, Marie-Noelle" <[email-masked]>, 
        <[email-masked]> 
Cc: "Boyle, Frank J (Duffy)" <[email-masked]>, 
        "Freundlich, Glen G (Glen)" <[email-masked]> 

Does DCS state only operate in one direction (ie.only from the SIP 
transaction initiator)? If so, it would need to be extended to provide 
equivalent information when two endpoints have hundreds or thousands of 
individual call legs in hundreds of sessions and either end might 
initiate any given SIP transaction. 

Also, what are the rules for passing DCS state with respect in the REFER 
case? 

If DCS state is extensible to provide an equivalent session identifier 
at both ends of any given call, then I agree that there isn't any need 
for bi-directional cookies to be grantable and remittable by either end. 
But given the current draft's focus on proxies and what appears to be a 
unidirectional call state, I'm not sure that it's complete enough to 
solve the whole problem. Please correct me if I've missed something... 

--Andy 

-----Original Message----- 
From: Sean Olson (EUS) [ mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: Wednesday, June 27, 2001 9:19 AM 
To: Zmolek, Andrew (Andrew); Chris Hogg; Jonathan Rosenberg; Mathieu, 
Marie-Noelle; [email-masked] 
Subject: RE: [Sip] RE: [Sipping] Call and call-id 

Have you considered the DCS State: draft for this mechanism?  See 
http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-state-01.txt <http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-state-01.txt>  
< http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-state-01.txt <http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-state-01.txt> > 

IMHO, I don't see a need for such a use of a Cookie. Correlating 
messages to calls is not that difficult. The key thing to note, as you 
have, is that Call-ID is not necessarily useful for tying multiple call 
legs together. 

/sean 

-----Original Message----- 
From: Zmolek, Andrew (Andrew) [ mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: Wednesday, June 27, 2001 9:55 AM 
To: Chris Hogg; Jonathan Rosenberg; Mathieu, Marie-Noelle; [email-masked] 
Subject: RE: [Sip] RE: [Sipping] Call and call-id 

I think it would be good to clarify our terminology, particularly since 
we sometimes forget SIP does not provide directly for a call with 
multiple active call legs (i.e. B2BUA is needed to rationalize each 
individual SIP call with the overall session). I propose we define 
"call" to mean the two participants in any given transaction and 
"session" to be some collection of calls associated within a given UA 
(note that "invited by a common source" is not a complete description 
since some or all of the invites could have originated outside the UA). 
  
This thread brings out several reasons why Call-ID should not be used to 
define a "session" of multiple "calls" as defined above. Mainly because 
of this, I'm preparing an I-D to address this need through the use of 
header extensions for cookies, which each UA can independently grant and 
accept in order to correlate call legs and potentially provide 
additional context for a given call. The alternative is vendor-specific 
headers and a walled garden approach to many features available in 
conventional PBXes today, and I don't think that's beneficial for SIP in 
the long run. 
  
--Andy Zmolek 
    Technology & Standards Engineer 
      CTO Standards 
        Avaya Inc. 

            [email-masked] 
              +1 720 444 4001 

 -----Original Message----- 
From: Chris Hogg [ mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: Wednesday, June 27, 2001 4:03 AM 
To: 'Jonathan Rosenberg'; Zmolek, Andrew (Andrew); Mathieu, 
Marie-Noelle; [email-masked] 
Subject: RE: [Sip] RE: [Sipping] Call and call-id 

Hi Jonathan, 

Jonathan Rosenberg wrote: 

>Careful; I am not proposing that two call legs with the same Call-ID convey 
>any semantics. Specifically, receiving an INVITE from A, while in a call 
>with B, where the call-id in the INVITE from A equals the call-id in the leg 
>with B, does NOT imply that this is a consultative transfer. For that, we 
>have Replaces, which lists the replaced leg explicitly. 

>All I am saying is that a Call-ID may be reused for local convenience, if 
>desired, but that it has NO semantics outside of the entity that selected 
>that call-id. 

Given, what you are proposing will this not mean that the definition of 
a call needs to be altered?  The reason I ask is that bis-03 defines a 
call as "identified by a globally unique callID" and "all participants 
invited by a common source".  In the case you describe under the current 
definition of a call this would mean that we would have two calls (under 
the "all participants invited by a common source" rule) but with the 
same callID (hence contravening the "globally unique callID" part).    

Comments? 

Regards, 

Chris Hogg 
Nortel Networks. 

-----Original Message----- 
From: Jonathan Rosenberg [ mailto:[email-masked] <mailto:[email-masked]>  
< mailto:[email-masked] <mailto:[email-masked]> > ] 
Sent: 26 June 2001 22:51 
To: 'Zmolek, Andrew (Andrew)'; Jonathan Rosenberg; Mathieu, 
Marie-Noelle; [email-masked] 
Subject: RE: [Sip] RE: [Sipping] Call and call-id 

-----Original Message----- 
From: Zmolek, Andrew (Andrew) [ mailto:[email-masked] <mailto:[email-masked]>  
< mailto:[email-masked] <mailto:[email-masked]> > ] 
Sent: Tuesday, June 26, 2001 12:35 PM 
To: Jonathan Rosenberg; Mathieu, Marie-Noelle; [email-masked] 
Subject: RE: [Sip] RE: [Sipping] Call and call-id 

>> >same call-id in the 2 INVITE requests, is this allowed ? 
>> 
>> Well, the current spec would indicate that you shouldn't do this: 
>> 
>> >The callid MUST be a globally unique identifier and MUST NOT be reused for 
>> >later calls. 
>> 
>> However, I recall some discussion at an IETF that people were using the same 
>> call-id across different call legs as a local identifier to correlate those 
>> call legs. With unique From tags and From fields, there really shouldn't be 
>> a problem, so I think its OK. However, if we are going to allow it, the spec 
>> should reflect it. Comments? 
> 
>If that's the proper way to solve this problem, then let's put that in the 
>spec. But I'm not convinced that this alone will solve all cases, especially 
>when this correlated information needs to be presented by a call leg attempting 
>to join (as in the consultative transfer case). 

Careful; I am not proposing that two call legs with the same Call-ID convey 
any semantics. Specifically, receiving an INVITE from A, while in a call 
with B, where the call-id in the INVITE from A equals the call-id in the leg 
with B, does NOT imply that this is a consultative transfer. For that, we 
have Replaces, which lists the replaced leg explicitly. 

All I am saying is that a Call-ID may be reused for local convenience, if 
desired, but that it has NO semantics outside of the entity that selected 
that call-id. 

> It only seems to work when the 
>correlating entity initiates all the calls. If there's a reliable way to 
>correlate an incoming call leg with an existing call, I'd love to hear about 
>it. 

http://www.softarmor.com/sipwg/drafts/morgue/draft-biggs-sip-replaces-00.txt <http://www.softarmor.com/sipwg/drafts/morgue/draft-biggs-sip-replaces-00.txt>  
< http://www.softarmor.com/sipwg/drafts/morgue/draft-biggs-sip-replaces-00.txt <http://www.softarmor.com/sipwg/drafts/morgue/draft-biggs-sip-replaces-00.txt> > 

needs updating and adoption though, if we plan to move forward with it. As 
you can see, its currently in the morgue. 

-Jonathan R. 
--- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave. 
Chief Scientist                             First Floor 
dynamicsoft                                 East Hanover, NJ 07936 
[email-masked]                     FAX:   (973) 952-5050 
http://www.jdrosen.net <http://www.jdrosen.net>  < http://www.jdrosen.net <http://www.jdrosen.net> > 
PHONE: (973) 952-5000 
http://www.dynamicsoft.com <http://www.dynamicsoft.com>  < http://www.dynamicsoft.com <http://www.dynamicsoft.com> >  

_______________________________________________ 
Sip mailing list  http://www.ietf.org/mailman/listinfo/sip <http://www.ietf.org/mailman/listinfo/sip>  
< http://www.ietf.org/mailman/listinfo/sip <http://www.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  http://www.ietf.org/mailman/listinfo/sip <http://www.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

---

From: "Zmolek, Andrew (Andrew)" <[email-masked]>
Date: Mon, 2 Jul 2001 07:22:37 -0600

The state draft indicates that when both sides set cookies, the
direction of a cookie must be deduced. Is there no explicit means for
indicating whether a header is creating a cookie or returning one?
 
--Andy

-----Original Message-----
From: Sean Olson (EUS) [mailto:[email-masked]]
Sent: Saturday, June 30, 2001 10:54 AM
To: Zmolek, Andrew (Andrew); William Marshall
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: RE: [Sip] RE: [Sipping] Call and call-id

The current state draft is intended to establish a "cookie" that lasts
at
least for the duration of a call leg. The cookie is tied to a call leg
based
on To/From/Call-ID. Furthermore cookies are returned based on the 
host/port in the State: header. If the Request-URI matches or any
of the Route: headers match this host/port, the State: header (cookie)
is returned.

  4.      Additional rules MAY be defined by other extensions that
specify
     when a State header is to be included in a request. An example of
     this would be extensions that handle call transfers and other
     features that would specify State header processing at the UAC.

This leaves open the possibility to define an extension that uses the
State: header in the manner you describe. However, I think what you
want to do is a bit at odds with the original intention of the draft.
Having
a cookie that spans call legs would require a different set of rules
defining
when a UAC should return a cookie in subsequent requests or a UAS in
the 1xx responses. 
 
I would like a more generic cookie mechanism, but I think the State:
header
mechanism is a reasonable compromise in terms of processing at the UA.
The alternative would be to provide additional information in the State:
header
which indicated when the State: header should be returned; similar to
the
path that is included in HTTP cookies.
 
e.g.
 
/sean

-----Original Message-----
From: Zmolek, Andrew (Andrew) [mailto:[email-masked]]
Sent: Friday, June 29, 2001 5:11 PM
To: Sean Olson (EUS); William Marshall; Zmolek, Andrew (Andrew)
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: RE: [Sip] RE: [Sipping] Call and call-id

Would the re-use of a state header as a means of tying together multiple
call legs cause problems with anything in the state draft as written? By
persistence, I'm thinking more about using the token to re-establish
some value-added context of a session terminated perhaps even days
earlier, but even without that concept, I need any cookie replacement to
not preclude token use across multiple call legs.
 
--Andy

-----Original Message-----
From: Sean Olson (EUS) [mailto:[email-masked]]
Sent: Wednesday, June 27, 2001 4:43 PM
To: Zmolek, Andrew (Andrew); William Marshall;
[email-masked]
Cc: Sean Olson (EUS); [email-masked]; [email-masked];
[email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: RE: [Sip] RE: [Sipping] Call and call-id

The State: header is a SIP extension. I believe it can be used
independently
of the other DCS extensions. The real issue is how widespread will the
extension be -- can you depend on "most" clients to support it. 

/sean

-----Original Message-----
From: Zmolek, Andrew (Andrew) [mailto:[email-masked]]
Sent: Wednesday, June 27, 2001 4:27 PM
To: William Marshall; [email-masked]
Cc: [email-masked]; [email-masked];

Sounds like the State header may accomplish what we are considering with
cookies; there may be no need to re-invent this. How tightly coupled is
the State header and the DCS call model?  In other words, to support the
State header will a device have to fully conform to DCS? Or is this
required only to generate state? 

Moreover, how problematic would the introduction of token persistence be
to the State header? Would this cause problems with DCS implementation?
Another worry: If the State header and DCS are joined at the hip, then
this might be too much for simple implementations to swallow even if our
own products were to comply. How much support does this proposal have in
the community right now?

--Andy Zmolek 

            [email-masked] 
              +1 720 444 4001 

-----Original Message----- 
From: William Marshall [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Wednesday, June 27, 2001 11:59 AM 
To: [email-masked] 
Cc: [email-masked]; [email-masked]; 
[email-masked]; [email-masked]; 
[email-masked]; [email-masked]; [email-masked] 
Subject: RE: [Sip] RE: [Sipping] Call and call-id 

State headers operate in both directions.  A UAC that inserts a State
header 
in the INVITE will see the contents returned in every provisional and
final 
response, as well as any re-INVITE initiated by the UAS.  A UAS that 
inserts a State header into a provisional or final response will see 
the contents returned in every re-INVITE from the UAC, as well as 
provisional and final responses to requests initiated by the UAS. 
The State header is documented in draft-ietf-sip-state-01. 

INVITE, along with the From/To/Call-ID.  This is all still
to-be-defined. 

Bill Marshall 
[email-masked] 

-----original messaage----- 
Subject: RE: [Sip] RE: [Sipping] Call and call-id 
Date: Wed, 27 Jun 2001 10:57:08 -0600 
From: "Zmolek, Andrew (Andrew)" <[email-masked]> 
To: "Sean Olson (EUS)" <[email-masked]>, 
        "Chris Hogg" <[email-masked]>, 
        "Jonathan Rosenberg" <[email-masked]>, 
        "Mathieu, Marie-Noelle" <[email-masked]>, 
        <[email-masked]> 
Cc: "Boyle, Frank J (Duffy)" <[email-masked]>, 
        "Freundlich, Glen G (Glen)" <[email-masked]> 

case? 

--Andy 

-----Original Message----- 
From: Sean Olson (EUS) [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Wednesday, June 27, 2001 9:19 AM 
To: Zmolek, Andrew (Andrew); Chris Hogg; Jonathan Rosenberg; Mathieu, 
Marie-Noelle; [email-masked] 
Subject: RE: [Sip] RE: [Sipping] Call and call-id 

Have you considered the DCS State: draft for this mechanism?  See 
http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-state-01.txt
<http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-state-01.txt>  
< http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-state-01.txt
<http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-state-01.txt> > 

/sean 

-----Original Message----- 
From: Zmolek, Andrew (Andrew) [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Wednesday, June 27, 2001 9:55 AM 
To: Chris Hogg; Jonathan Rosenberg; Mathieu, Marie-Noelle; [email-masked] 
Subject: RE: [Sip] RE: [Sipping] Call and call-id 

the long run. 
  
--Andy Zmolek 

            [email-masked] 
              +1 720 444 4001 

 -----Original Message----- 
From: Chris Hogg [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Wednesday, June 27, 2001 4:03 AM 
To: 'Jonathan Rosenberg'; Zmolek, Andrew (Andrew); Mathieu, 
Marie-Noelle; [email-masked] 
Subject: RE: [Sip] RE: [Sipping] Call and call-id 

Hi Jonathan, 

Comments? 

Regards, 

Chris Hogg 
Nortel Networks. 

-----Original Message----- 
From: Jonathan Rosenberg [ mailto:[email-masked]
<mailto:[email-masked]>  
< mailto:[email-masked] <mailto:[email-masked]> > ] 
Sent: 26 June 2001 22:51 
To: 'Zmolek, Andrew (Andrew)'; Jonathan Rosenberg; Mathieu, 
Marie-Noelle; [email-masked] 
Subject: RE: [Sip] RE: [Sipping] Call and call-id 

-----Original Message----- 
From: Zmolek, Andrew (Andrew) [ mailto:[email-masked]
<mailto:[email-masked]>  
< mailto:[email-masked] <mailto:[email-masked]> > ] 
Sent: Tuesday, June 26, 2001 12:35 PM 
To: Jonathan Rosenberg; Mathieu, Marie-Noelle; [email-masked] 
Subject: RE: [Sip] RE: [Sipping] Call and call-id 

>to join (as in the consultative transfer case). 

Careful; I am not proposing that two call legs with the same Call-ID
convey 
any semantics. Specifically, receiving an INVITE from A, while in a call

with B, where the call-id in the INVITE from A equals the call-id in the
leg 
with B, does NOT imply that this is a consultative transfer. For that,
we 
have Replaces, which lists the replaced leg explicitly. 

All I am saying is that a Call-ID may be reused for local convenience,
if 
desired, but that it has NO semantics outside of the entity that
selected 
that call-id. 

>correlate an incoming call leg with an existing call, I'd love to hear
about 

http://www.softarmor.com/sipwg/drafts/morgue/draft-biggs-sip-replaces-00
.txt
<http://www.softarmor.com/sipwg/drafts/morgue/draft-biggs-sip-replaces-0
0.txt>  
<
http://www.softarmor.com/sipwg/drafts/morgue/draft-biggs-sip-replaces-00
.txt
<http://www.softarmor.com/sipwg/drafts/morgue/draft-biggs-sip-replaces-0
0.txt> > 

needs updating and adoption though, if we plan to move forward with it.
As 
you can see, its currently in the morgue. 

-Jonathan R. 
--- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave. 
Chief Scientist                             First Floor 
dynamicsoft                                 East Hanover, NJ 07936 
[email-masked]                     FAX:   (973) 952-5050 
http://www.jdrosen.net <http://www.jdrosen.net>  <
http://www.jdrosen.net <http://www.jdrosen.net> > 
PHONE: (973) 952-5000 
http://www.dynamicsoft.com <http://www.dynamicsoft.com>  <
http://www.dynamicsoft.com <http://www.dynamicsoft.com> >  

_______________________________________________ 
Sip mailing list  http://www.ietf.org/mailman/listinfo/sip
<http://www.ietf.org/mailman/listinfo/sip>  
< http://www.ietf.org/mailman/listinfo/sip
<http://www.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  http://www.ietf.org/mailman/listinfo/sip
<http://www.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

---

From: Michael Hammer <[email-masked]>
Date: Mon, 02 Jul 2001 11:06:24 -0400

Andy,

I had the impression that the nature of the cookie was such that only the 
creator new what was encoded.  The suggestion about setting direction was 
to enable that node to determine whether the cookie was being returned by 
whichever side.

Also, in response to the previous email, While the description was targeted 
to a simple 2-way communication, I was not under the impression that there 
was any guidance concerning multi-way calls.  I would presume that it would 
be an implementation detail, unless explicitly defined.

Mike

At 07:22 AM 7/2/2001 -0600, Zmolek, Andrew (Andrew) wrote:
>The state draft indicates that when both sides set cookies, the direction 
>of a cookie must be deduced. Is there no explicit means for indicating 
>whether a header is creating a cookie or returning one?
>
>--Andy
>>persistence, I'm thinking more about using the token to re-establish some 
>>value-added context of a session terminated perhaps even days earlier, 
>>but even without that concept, I need any cookie replacement to not 
>>preclude token use across multiple call legs.
>>
>>--Andy
>>>From: William Marshall 
>>>[<mailto:[email-masked]>mailto:[email-masked]]
>>>From: Sean Olson (EUS) 
>>>[<mailto:[email-masked]>mailto:[email-masked]]
>>><http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-state-01.txt>http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-state-01.txt 
>>>
>>>From: Zmolek, Andrew (Andrew) 
>>>[<mailto:[email-masked]>mailto:[email-masked]]
>>>From: Chris Hogg 
>>>[<mailto:[email-masked]>mailto:[email-masked]]
>>>From: Jonathan Rosenberg [ 
>>><mailto:[email-masked]>mailto:[email-masked]
>>><mailto:[email-masked]> ]
>>>Sent: 26 June 2001 22:51
>>>From: Zmolek, Andrew (Andrew) [ 
>>><mailto:[email-masked]>mailto:[email-masked]
>>><http://www.softarmor.com/sipwg/drafts/morgue/draft-biggs-sip-replaces-00.txt>http://www.softarmor.com/sipwg/drafts/morgue/draft-biggs-sip-replaces-00.txt 
>>>
>>><http://www.softarmor.com/sipwg/drafts/morgue/draft-biggs-sip-replaces-00.txt> 
>>>
>>>
>>><http://www.jdrosen.net>http://www.jdrosen.net <http://www.jdrosen.net>
>>>PHONE: (973) 952-5000
>>><http://www.dynamicsoft.com>http://www.dynamicsoft.com 
>>><http://www.dynamicsoft.com>
>>>Sip mailing 
>>>list 
>>><http://www.ietf.org/mailman/listinfo/sip>http://www.ietf.org/mailman/listinfo/sip 
>>>
>>>Sip mailing 
>>>list 
>>><http://www.ietf.org/mailman/listinfo/sip>http://www.ietf.org/mailman/listinfo/sip 
>>>

---

From: "Adam Roach" <[email-masked]>
Date: Thu, 5 Jul 2001 21:21:59 -0500

> From: Bob Penfield [mailto:[email-masked]]
> 
> > 1. As Gonzalo indicated, overlap reuses call-id. I think 
> thats not such a
> > good idea. Lets be explicit. If they need some extra header 
> to correlate
> > those things, so be it.
> 
> I think overlap's reuse of call-id meets the "set of 
> participants invited to
> a session by a common source" definition since the 
> originating gateway is
> the "common source". 

I was going to compose a long refutation of the
contention that using Call-ID for the overlap
solution is inappropriate.

I'll forgo that, though; Bob has summed up the
key argument quite concisely. I couldn't agree
more.

/a