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

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 26 Jun 2001 01:40:10 -0400

This belongs on sip.

-----Original Message-----
From: Mathieu, Marie-Noelle [mailto:[email-masked]]
Sent: Monday, June 25, 2001 5:42 AM
To: [email-masked]'
Subject: [Sipping] Call and call-id
>
>
>Hello,
>
>I have a doubt concerning the definition of a call-id.
>I read that a call "consists of all participants in a session invited by a 
>common source".
>
>I understand that one INVITE request (and so one call-id) may result with 
>several call-legs due to forking.
>
>My question is :  
>
> Is it possible to use the same call-id in 2 differents INVITE requests to
2 
>differents User Agents ? 
>
>
>Let say User Agent A invites User Agent B and user Agent C. Will it use the

>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?

-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                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sip mailing list  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: "Sean Olson (EUS)" <[email-masked]>
Date: Tue, 26 Jun 2001 09:28:25 -0500

>should reflect it. Comments?

Given that the notion of a "call" associated with a Call-ID
is a fiction (only call legs are really meaningful), re-use
of the Call-ID seems acceptable. 

/sean

---

From: "Zmolek, Andrew (Andrew)" <[email-masked]>
Date: Tue, 26 Jun 2001 10:35:12 -0600

> 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). 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.

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

            [email-masked]
              +1 720 444 4001

---

From: Michael Hammer <[email-masked]>
Date: Tue, 26 Jun 2001 14:48:47 -0400

Andy,

It would appear that an independent "call ID" attribute not used as part of 
the key to the call-leg identity would be needed, unless you do a re-Invite 
backwards and use the same Call ID and replace the incoming session.  But, 
there are no guarantees that the backward session will succeed.  It's also 
not very elegant to hang up on one line while the call jumps to a second 
"line" as a new call, which I observed happening to someone once.  There 
could also be billing implications related to who placed the call and pays.

If the party called someone, then transferred that call separately from the 
held call or conference, then I would not expect the same Call ID.  If the 
incoming call was answered (other party on hold) and then transferred, that 
would also use additional Call IDs.

As for joining additional incoming calls into a conference, I too would be 
interested.

Mike

At 10:35 AM 6/26/2001 -0600, Zmolek, Andrew (Andrew) wrote:

>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, 
>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.
>
>--Andy Zmolek

---

From: "Zmolek, Andrew (Andrew)" <[email-masked]>
Date: Wed, 27 Jun 2001 08:54:43 -0600

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

            [email-masked]
              +1 720 444 4001

 
 -----Original Message-----
From: Chris Hogg [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]> ] 
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]> ] 
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 

>> >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 
>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-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>
PHONE: (973) 952-5000 
http://www.dynamicsoft.com <http://www.dynamicsoft.com>  

<http://www.ietf.org/mailman/listinfo/sip>

---

From: "Zmolek, Andrew (Andrew)" <[email-masked]>
Date: Wed, 27 Jun 2001 10:57:08 -0600

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]]
Sent: Wednesday, June 27, 2001 9:19 AM
To: Zmolek, Andrew (Andrew); Chris Hogg; Jonathan Rosenberg; Mathieu,

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> 
 
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]]
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

 
--Andy Zmolek

            [email-masked]
              +1 720 444 4001

 
 -----Original Message-----
From: Chris Hogg [mailto:[email-masked]]
Sent: Wednesday, June 27, 2001 4:03 AM
To: 'Jonathan Rosenberg'; Zmolek, Andrew (Andrew); Mathieu,

Hi Jonathan, 

convey 
call 
the leg 
we 

if 
selected 

Comments? 

Regards, 

Chris Hogg 
Nortel Networks. 

  
-----Original Message----- 

reused 
for 
the 
same 

those 
shouldn't 
be 
the 
spec 
the 
especially 
attempting 

to 
about 

-Jonathan R. 
---

---

From: William Marshall <[email-masked]>
Date: Wed, 27 Jun 2001 13:59:04 -0400 (EDT)

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]>

--Andy

-----Original Message-----
From: Sean Olson (EUS) [mailto:[email-masked]]
Sent: Wednesday, June 27, 2001 9:19 AM
To: Zmolek, Andrew (Andrew); Chris Hogg; Jonathan Rosenberg; Mathieu,

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>

/sean

-----Original Message-----
From: Zmolek, Andrew (Andrew) [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

 
--Andy Zmolek

            [email-masked]
              +1 720 444 4001

 
 -----Original Message-----
From: Chris Hogg [mailto:[email-masked]]
Sent: Wednesday, June 27, 2001 4:03 AM
To: 'Jonathan Rosenberg'; Zmolek, Andrew (Andrew); Mathieu,

Hi Jonathan, 

Jonathan Rosenberg wrote: 

>Careful; I am not proposing that two call legs with the same Call-ID convey 
>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 

>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. 

Comments? 

Regards, 

Chris Hogg 
Nortel Networks. 

  
-----Original Message----- 

>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 

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. 

>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>

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

-Jonathan R. 
---

---

From: "Zmolek, Andrew (Andrew)" <[email-masked]>
Date: Wed, 27 Jun 2001 15:27:11 -0600

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]]
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]>

--Andy

-----Original Message-----
From: Sean Olson (EUS) [mailto:[email-masked]]
Sent: Wednesday, June 27, 2001 9:19 AM
To: Zmolek, Andrew (Andrew); Chris Hogg; Jonathan Rosenberg; Mathieu,

/sean

-----Original Message-----
From: Zmolek, Andrew (Andrew) [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

 
--Andy Zmolek

            [email-masked]
              +1 720 444 4001

 
 -----Original Message-----
From: Chris Hogg [mailto:[email-masked]]
Sent: Wednesday, June 27, 2001 4:03 AM
To: 'Jonathan Rosenberg'; Zmolek, Andrew (Andrew); Mathieu,

Hi Jonathan, 

convey 
call 
the leg 
we 

if 
selected 

Comments? 

Regards, 

Chris Hogg 
Nortel Networks. 

  
-----Original Message----- 

>> >The callid MUST be a globally unique identifier and MUST NOT be
reused for 
>> However, I recall some discussion at an IETF that people were using
the same
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
the 
especially 
attempting 

to 
about 

-Jonathan R. 
---

---

From: "Chris Hogg" <[email-masked]>
Date: Thu, 28 Jun 2001 09:34:20 +0100

Reposted to list due to mail problems. Apologies to anyone who receives this
twice.

Hi Jonathan, 

leg 
>desired, but that it has NO semantics outside of the entity that selected 
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.

---

From: "Sean Olson (EUS)" <[email-masked]>
Date: Wed, 27 Jun 2001 17:43:16 -0500

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 

            [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]; 

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]> 

--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, 

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 

  
--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, 

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 

>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-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> > 

-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>

---

From: "Zmolek, Andrew (Andrew)" <[email-masked]>
Date: Fri, 29 Jun 2001 16:11:29 -0600

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];

--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 

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----- 

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, 

convey 
call 
the leg 
we 

if 
selected 

Comments? 

Regards, 

Chris Hogg 
Nortel Networks. 

-----Original Message----- 
<mailto:[email-masked]>  

-----Original Message----- 
<mailto:[email-masked]>  

reused for 
the same 
those 
shouldn't be 
the spec 
the 
especially 
attempting 

to 
about 

<
0.txt> > 

-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