Subject: Re: [BLISS] Call-completion design question: End-to-end parameters

From: [email-masked]
Date: Mon, 3 Mar 2008 16:58:09 -0500

From: Paul Kyzivat <[email-masked]>

   > So the 'm' parameter is a way to ensure that SS7 interworking works
   > well now, as well as being available for expansion, and allowing for
   > applying hueristics where they work better than the obvious rigid
   > rules.

   OK. Its still a bunch of crap, but I understand the interop issues.

Yeah, interoperability problems alway generate crap.

   Can you put some weasle words in indicating that this datum may be 
   ignored by the callee if it can determine presence without it?

I think there is already, but if not, we will add it.

   >    > An alternative to all of the above is that we could define new
   >    > header(s) to carry the required information.
   >    > 
   >    > Advantage:  It would work.
   >    > 
   >    > Disadvantage:  Defining a new header just for this one feature.
   > 
   >    How about Call-Info?
   > 
   >    It is however disheartening to find that the same information has to be
   >    carried in different ways in the subscribe and the invite.
   > 
   > Yes, the lack of symmetry is a negative.

   How do you feel about call-info for this purpose?

It's probably as good as anything, except that its syntax demands a
URI, and in some of the cases, there is no URI to be transmitted.  (I
checked, and there doesn't seem to be any "null URI" to use as a
place-holder.)

Dale
_______________________________________________
BLISS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/bliss

---

From: [email-masked]
Date: Mon, 3 Mar 2008 17:01:12 -0500

From: "Elwell, John" <[email-masked]>

   I still don't get this call-ID stuff. If there is an intermediate B2BUA
   that maps call-IDs between the upstream side and the downstream side and
   it is not CC-stateful, how can it ensure that it performs the same
   mapping on a call-ID in the Event header field of a SUBSCRIBE request
   that it carried out on the original INVITE request? Without such
   mapping, the callee's monitor will receive a different call-ID and will
   be unable to match.

   Even with a CC-stateful B2BUA there, what if the SUBSCRIBE request gets
   routed differently and passes through a different B2BUA?

I haven't given it much thought, but one choice would be to hash the
incoming call-ID with a 64-bit key (shared among the constellation of
B2BUAs/gateways) to generate the outgoing 'identifier'.  (As the
protocol is defined now, the B2BUA can choose the Call-Id freely, and
apply the generated 'identifier'.)

Dale

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 04 Mar 2008 11:39:26 +0000

Dale,

I am not sure I understand your proposal. I had assumed that the B2BUAs
concerned would not be CC-aware, so would simply use there own internal
algorithms for generating call-IDs.

What I had in mind for solving the problem is that the call-ID (or some
other value unique to the monitor) be returned in the response to the
initial INVITE request, e.g., as part of the URI in Call-Info. We would
then be completely independent of any unwanted treatment of Call-IDs by
intervening B2BUAs.

John

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of [email-masked]
> Sent: 03 March 2008 22:01
> To: [email-masked]
> Subject: Re: [BLISS] Call-completion design question: 
> End-to-end parameters
> 
>

---

From: "Huelsemann, Martin" <[email-masked]>
Date: Wed, 5 Mar 2008 15:40:04 +0100

Dear colleagues,

I'm just trying to summarize your discussion for myself:

- the CC subscription and the CC call have to be correlated to the original call somehow, psoposed is to use a 'id' parameter for this purpose

- the callid from the original call could be used as value for the 'id' parameter (for the PSTN interworking also a fallback procedure to generate the 'id' parameter from caller and callee id is proposed, as gateways are not able to store callids)

- the problem with the usage of the callid is, that proxies can change the callid, and because of this a correlation of original callid and the callid delivered in the 'id' parameter might not be possible

- it is unclear to which header the 'id' parameter should be added: From-header might be changed by forking proxies; Call Info header demands a URI which is not always available

So if this summary is correct, there seem to be 2 questions:

Is there a end-to-end unchanged identification of the original call which can be used to fill the 'id' parameter?

To which end-to-end unchanged header of the CC subscription or the CC call can the 'id' parameter be added?

BR, Martin

---

From: [email-masked]
Date: Wed, 5 Mar 2008 17:48:18 -0500

Perhaps I'm not understanding the situation that you are operating in.

You wrote:

I think the question is how to arrange for the original call, the
SUBSCRIBE (CC activation), and the CC recall to be correlated.  The
restriction is that the original call goes through a B2BUA that cannot
carry state to the later two operations.

It seems to me that a solution is that when the B2BUA generates the
downstream call, it carries the 'id' of the upstream call, or the
Call-Id if the 'id' is missing, into the 'id' of the downstream call.
(The Call-Id could be chosen by any method.)

Dale

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 06 Mar 2008 08:02:03 +0000

Martin,

If we are considering using Call-Info in an INVITE response to convey a
contact URI to be used as the Request-URI in a SUBSCRIBE request, that
URI could not only identify the monitor but also the particular call.
Problem solved?

John

> From: Huelsemann, Martin [mailto:[email-masked]] 
> Sent: 05 March 2008 14:40
> To: [email-masked]
> Cc: [email-masked]; Elwell, John; 
> [email-masked]; Alexeitsev, D
> Subject: AW: [BLISS] Call-completion design question: 
> End-to-end parameters
> 
> Dear colleagues,
> 
> - the CC subscription and the CC call have to be correlated 
> to the original call somehow, psoposed is to use a 'id' 
> parameter for this purpose
> 
> - the callid from the original call could be used as value 
> for the 'id' parameter (for the PSTN interworking also a 
> fallback procedure to generate the 'id' parameter from caller 
> and callee id is proposed, as gateways are not able to store callids)
> 
> - the problem with the usage of the callid is, that proxies 
> can change the callid, and because of this a correlation of 
> original callid and the callid delivered in the 'id' 
> parameter might not be possible
> 
> - it is unclear to which header the 'id' parameter should be 
> added: From-header might be changed by forking proxies; Call 
> Info header demands a URI which is not always available
> 
> 
> 
> Is there a end-to-end unchanged identification of the 
> original call which can be used to fill the 'id' parameter?
> 
> To which end-to-end unchanged header of the CC subscription 
> or the CC call can the 'id' parameter be added?
> 
> 
> 
> BR, Martin
> 
> 
>  
>

---

From: "Huelsemann, Martin" <[email-masked]>
Date: Thu, 6 Mar 2008 10:08:05 +0100

Surely this would be conveyed unchanged from the callee CC monitor to the caller CC agent.

But how to use this for the subscription/recall? As Dale indicated the request URI is very like to be changed in a forking scenario.

BR, Martin

> -----Ursprüngliche Nachricht-----
> Von: Elwell, John [mailto:[email-masked]] 
> Gesendet: Donnerstag, 6. März 2008 09:02
> An: Hülsemann, Martin; [email-masked]
> Cc: [email-masked]; [email-masked]; Alexeitsev, Denis
> Betreff: RE: [BLISS] Call-completion design question: 
> End-to-end parameters
> 
> Martin,
>

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 06 Mar 2008 10:01:29 +0000

Martin,

I don't see forking as a problem. A monitor generates a URI that uniquely identifies itself and the call and places it in the Call-Info header field of the response to the original INVITE request. For example, it can ask a registrar for a temporary GRUU if it doesn't have its own host name. If this URI is used in the SUBSCRIBE request or in the final INVITE request, it will cause it to be routed to the same monitor and allow that monitor to identify the call.

Of course, a different solution will be needed for PSTN interworking - I have not thought that one through.

John

> Sent: 06 March 2008 09:08
> To: Elwell, John; [email-masked]
> Cc: [email-masked]; [email-masked]; Alexeitsev, D
> But how to use this for the subscription/recall? As Dale 
> indicated the request URI is very like to be changed in a 
> forking scenario.
> 
> BR, Martin
> 
>  
>

---

From: "Huelsemann, Martin" <[email-masked]>
Date: Thu, 6 Mar 2008 12:07:08 +0100

Hi John,

this could be of course a solution, too.

As you said, the PSTN interworking would need some new consideration. Perhaps a mechanism similar to that Dale proposed for the 'id' parameter would be possible. This would be to have the possibility for a fallback to form the user portion from caller id and callee id, encrypted in the way Dale proposed.

BR, Martin

> Gesendet: Donnerstag, 6. März 2008 11:01
> I don't see forking as a problem. A monitor generates a URI 
> that uniquely identifies itself and the call and places it in 
> the Call-Info header field of the response to the original 
> INVITE request. For example, it can ask a registrar for a 
> temporary GRUU if it doesn't have its own host name. If this 
> URI is used in the SUBSCRIBE request or in the final INVITE 
> request, it will cause it to be routed to the same monitor 
> and allow that monitor to identify the call.
> 
> Of course, a different solution will be needed for PSTN 
> interworking - I have not thought that one through.
> 
> John
>

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 06 Mar 2008 17:03:46 +0000

Dale,

Let me illustrate:

Agent                  B2BUA                     Monitor
    INVITE call-ID 1            INVITE call-ID 2
    ---------------->           ---------------->
         186                         186
    <----------------           <----------------

   SUBSCRIBE call-ID 3         SUBSCRIBE call-ID 4
  Event:...target-call-ID 1  Event:...target-call-ID 1
    ---------------->           ---------------->

If the B2BUA does not also translate the referenced call-ID within the
SUBSCRIBE request (in the Event header, I believe), the monitor will
receive a target call-ID that it does not recognise. This assumes the
B2BUA is not CC-aware, and therefore does not translate the target
call-ID.

Even if the B2BUA is CC-aware, it would need to retain state concerning
the original call-IDs after the call has finished.

The problem is even worse if the INVITE request and the SUBSCRIBE
request traverse different B2BUAs.

John

> Sent: 05 March 2008 22:48
> To: [email-masked]

---

From: [email-masked]
Date: Thu, 6 Mar 2008 16:23:43 -0500

The difficulty is the nearly memory-less nature of a constellation of
gateways from SS7 to SIP -- the only information retained from the
failure of the original call to the CC activation is the "mode", CCBS
vs. CCNR.  So we cannot make it an essential part of the protocol for
the caller's end to retain a token that was sent from the callee's
end.

The current design avoids requiring memory, but does a fairly good job
(IMHO) of letting a caller with memory improve the behavior of the
protocol.

Dale

---

From: [email-masked]
Date: Thu, 6 Mar 2008 16:26:09 -0500

In the current scheme, the natural approach to this situation would
be:

   Agent                  B2BUA                     Monitor
                                   id="call-ID 1"

At the monitor, the original call would be indexed by the 'id'
parameter, which is "call-ID 1".  This allows matching with the
subsequent SUBSCRIBE.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 06 Mar 2008 18:05:14 -0500

Dale,

Some problems with this:

- it only works for B2BUAs that work this way. Currently there are none. 
And of course there can be several, including ones that have no 
particular desire to make this feature work.

- removing the callid is considered by some to be required to hide node 
names (which are often part of the callid). If that it thought to be 
important then copying the callid to another field will defeat the intent.

	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 11 Mar 2008 14:20:26 +0000

Yes, I agree with the points Paul makes.

John 

> On Behalf Of Paul Kyzivat
> Sent: 06 March 2008 23:05
> To: [email-masked]
> Cc: [email-masked]

---

From: [email-masked]
Date: Tue, 11 Mar 2008 13:23:56 -0500

Well, getting call-completion to get through a B2BUA is going to
require *some* assumptions about what the B2BUA does.  What
assumptions can be safely made?

The advantage of using Call-Id to identify calls is that all calls
already have Call-Ids.  Without using Call-Id as the default
identifier, every call originator has to be revised to add another
identifier to every call.

What do you propose?

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 12 Mar 2008 15:31:28 -0400

> assumptions can be safely made?

Given that we don't standardize them, pretty much nothing.

If we need to start making some assumptions about them, then I hope the 
requirements are not highly specialized to particular features.

> identifier to every call.

Perhaps one could make the case that if you are trying to anonymize your 
call then call completion *shouldn't* work. If so, then we only need 
deal with cases where it isn't anonymized. Then this would become yet 
another requirement on B2BUAs - that they not mess with callids.

> What do you propose?

That we ban B2BUAs?

Lets get Hadriel to tell us what we can count on from B2BUAs.

	Paul

---

From: [email-masked]
Date: Wed, 12 Mar 2008 14:48:22 -0500

Perhaps one could make the case that if you are trying to anonymize your 
   call then call completion *shouldn't* work. If so, then we only need 
   deal with cases where it isn't anonymized.

I think that John's case happens in non-anonymized calls as well.

   Then this would become yet another requirement on B2BUAs - that
   they not mess with callids.

The irony is that one of the few RFC 3261 restrictions on B2BUAs is
that they don't use the same Call-Id on the outgoing leg that was used
on the incoming leg.  And many B2BUAs violate that.  But the violaters
do not cause a problem for the CC design; it's the conformant B2BUAs
that are the problem.

Dale

---

From: "Hans Erik van Elburg" <[email-masked]>
Date: Wed, 12 Mar 2008 23:56:10 +0100

Any solution that will not work through conformant (:-) B2BUA's will be
useless in practice. It is the same kind of thing as ignoring NATs.

/Hans Erik

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: Wednesday, March 12, 2008 3:48 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [BLISS] Call-completion design question: End-to-end
parameters

   > identifier to every call.

   Perhaps one could make the case that if you are trying to anonymize
your 
   call then call completion *shouldn't* work. If so, then we only need 
   deal with cases where it isn't anonymized.

The irony is that one of the few RFC 3261 restrictions on B2BUAs is that
they don't use the same Call-Id on the outgoing leg that was used on the
incoming leg.  And many B2BUAs violate that.  But the violaters do not
cause a problem for the CC design; it's the conformant B2BUAs that are
the problem.

Dale