Subject: [Sipping] Comments on draft-poetzl-sipping-call-completion-00

From: "Elwell, John" <[email-masked]>
Date: Mon, 03 Jul 2006 12:53:25 +0100

In general, I find this draft somewhat difficult to understand, even though
I believe I understand the TISPAN requirements for CCBS/CCNR. This is partly
a terminology issue (although I think I can follow what is intended from
that point of view). It is more a case of what appears to be a lack of
explanation of how the proposed new mechanisms will be used and the
rationale for choosing them. Just a couple of specific comments as examples:

1. The draft proposes a couple of new event packages and a new header field.
It does not seem to explain very clearly how these new components are used
together to achieve the requirements for call completion. For example, is an
INVITE request containing 'ccss' intended to indicate that the INVITE
request needs to be correlated in some way with the event package
subscription at the UAS? The examples in section 7, if they were to be
extended to show full message contents, in accordance with normal practice,
would doubtless help.

2. Section 5.1.2 defines a parameter "caller" for use in the Event header
field of a SUBSCRIBE request. It is not clear why this is needed. There are
other standard ways of indicating caller identity, e.g., From header field,
>From header field with Identity header field, P-Asserted-Identity header
field. Some discussion of the rationale for this and why existing mechanisms
do not work would be useful.
John

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

---

From: "Huelsemann, Martin" <[email-masked]>
Date: Tue, 4 Jul 2006 14:55:31 +0200

Hi John,
 
thanks for your comments. I have to admit the draft was developed very fastly in order to start the work and to be able to discuss it at the Montreal meeting. Some explaining parts are missing, for which it is important to add them in the 01 version.
 
The whole call completion topic deals mainly with queue management between application servers which are able to handle call completion requests in a sequential manner (FIFO queue), so that the first user who activates CCBS on a busy destination ist the first user who is informed that this destination is free for recall now.
 
Therefore the new CCBS/CCNR event packages are needed. These packages are not dealing with with the state of the dialog of the busy user (like the dialog event package), as those information are irrelevant for the call completion service on the originating side. The call completion event packages are used for managing the queues between application servers, which means reqests to be added to a call completion queue, indications that the request for the queue was succsessful, indications that the call completion destination is free for recall now (which not mean that a dialog just has been terminated), requests to suspend the call completion request for a certain time (e.g. because the CCBS using UA is busy), requests to resume a CCBS request, indications why a call completion request can't be fulfilled, and so on. This as a explanation why this new event packages are needed and existing packages (like the dialog event package) can't be used.
 
The 'ccss' indication is used for prioritisation of the call completion call (the call resulting from the indication that the destination is free for recall now). Calls without this indication will be blocked on the terminating side while there are active call completion requests to be processed.
 
The caller parameter is needed in case that multiple contatcs are registered at the same time for the same SIP URI, because the CCBS recall (indication that the destination is free for recall now) shall be routed to the contact that has initiated the call completion request and not to all the contacts.

 
BR, Martin

-----Ursprüngliche Nachricht-----
Von: Elwell, John [mailto:[email-masked]] 
Gesendet: Montag, 3. Juli 2006 13:53
An: Hülsemann, Martin; Pötzl, Joachim; Jesske, Roland; sipping
Betreff: [Sipping] Comments on draft-poetzl-sipping-call-completion-00

In general, I find this draft somewhat difficult to understand, even though I believe I understand the TISPAN requirements for CCBS/CCNR. This is partly a terminology issue (although I think I can follow what is intended from that point of view). It is more a case of what appears to be a lack of explanation of how the proposed new mechanisms will be used and the rationale for choosing them. Just a couple of specific comments as examples:

1. The draft proposes a couple of new event packages and a new header field. It does not seem to explain very clearly how these new components are used together to achieve the requirements for call completion. For example, is an INVITE request containing 'ccss' intended to indicate that the INVITE request needs to be correlated in some way with the event package subscription at the UAS? The examples in section 7, if they were to be extended to show full message contents, in accordance with normal practice, would doubtless help.

2. Section 5.1.2 defines a parameter "caller" for use in the Event header field of a SUBSCRIBE request. It is not clear why this is needed. There are other standard ways of indicating caller identity, e.g., From header field, From header field with Identity header field, P-Asserted-Identity header field. Some discussion of the rationale for this and why existing mechanisms do not work would be useful.

John

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 04 Jul 2006 16:35:02 +0100

Martin,

Thanks for your explanations. More below.

John 

> -----Original Message-----
> From: Huelsemann, Martin [mailto:[email-masked]] 
> Sent: 04 July 2006 13:56
> To: Elwell, John; [email-masked]
> Cc: Poetzl, Joachim; Jesske, R; Alexeitsev, D
> Subject: AW: [Sipping] Comments on 
> draft-poetzl-sipping-call-completion-00
> 
> Hi John,
>  
> thanks for your comments. I have to admit the draft was 
> developed very fastly in order to start the work and to be 
> able to discuss it at the Montreal meeting. Some explaining 
> parts are missing, for which it is important to add them in 
> the 01 version.
>  
> The whole call completion topic deals mainly with queue 
> management between application servers which are able to 
> handle call completion requests in a sequential manner (FIFO 
> queue), so that the first user who activates CCBS on a busy 
> destination ist the first user who is informed that this 
> destination is free for recall now.
>  
> Therefore the new CCBS/CCNR event packages are needed. These 
> packages are not dealing with with the state of the dialog of 
> the busy user (like the dialog event package), as those 
> information are irrelevant for the call completion service on 
> the originating side. The call completion event packages are 
> used for managing the queues between application servers,
[JRE] So are you saying that application servers act as UAs for the
SUBSCRIBE and NOTIFY requests? If so, I think more needs saying about
routing of requests. What causes a SUBSCRIBE request to arrive at the
application server rather than at a conventional UA?
 
> which means reqests to be added to a call completion queue, 
> indications that the request for the queue was succsessful, 
> indications that the call completion destination is free for 
> recall now (which not mean that a dialog just has been 
> terminated), requests to suspend the call completion request 
> for a certain time (e.g. because the CCBS using UA is busy), 
> requests to resume a CCBS request, indications why a call 
> completion request can't be fulfilled, and so on. This as a 
> explanation why this new event packages are needed and 
> existing packages (like the dialog event package) can't be used.
>  
> The 'ccss' indication is used for prioritisation of the call 
> completion call (the call resulting from the indication that 
> the destination is free for recall now). Calls without this 
> indication will be blocked on the terminating side while 
> there are active call completion requests to be processed.
[JRE] This isn't a very secure means of determining whether a call will get
through. Presumably there is a trust relationship, rather like that for
P-Asserted-Identity, which prevents this being acted on unless the sender is
trusted. More explanation is needed here.

>  
> The caller parameter is needed in case that multiple contatcs 
> are registered at the same time for the same SIP URI, because 
> the CCBS recall (indication that the destination is free for 
> recall now) shall be routed to the contact that has initiated 
> the call completion request and not to all the contacts.
[JRE] If the SUBSCRIBE request originated at the user's UA, then the Contact
header field would fulfil this function. However, it seems the request
originates at an application server acting on behalf of the caller. Isn't it
then the job of the application server at the caller end to make sure it
deals with the correct UA? Between the two application servers, different
instances of subscription dialog distinguish different CCBS/CCNR requests -
mapping these to caller UAs seems to be an internal matter for the caller's
application server.

> 	In general, I find this draft somewhat difficult to 
> understand, even though I believe I understand the TISPAN 
> requirements for CCBS/CCNR. This is partly a terminology 
> issue (although I think I can follow what is intended from 
> that point of view). It is more a case of what appears to be 
> a lack of explanation of how the proposed new mechanisms will 
> be used and the rationale for choosing them. Just a couple of 
> specific comments as examples:
> 
> 	1. The draft proposes a couple of new event packages 
> and a new header field. It does not seem to explain very 
> clearly how these new components are used together to achieve 
> the requirements for call completion. For example, is an 
> INVITE request containing 'ccss' intended to indicate that 
> the INVITE request needs to be correlated in some way with 
> the event package subscription at the UAS? The examples in 
> section 7, if they were to be extended to show full message 
> contents, in accordance with normal practice, would doubtless help.
> 
> 	2. Section 5.1.2 defines a parameter "caller" for use 
> in the Event header field of a SUBSCRIBE request. It is not 
> clear why this is needed. There are other standard ways of 
> indicating caller identity, e.g., From header field, From 
> header field with Identity header field, P-Asserted-Identity 
> header field. Some discussion of the rationale for this and 
> why existing mechanisms do not work would be useful.
> 
> 	John 
> 
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@From [email-masked] Tue Jul 04 11:50:35 2006
Content-return: allowed
Date: Tue, 04 Jul 2006 16:35:02 +0100
From: "Elwell, John" <[email-masked]>
Subject: RE: [Sipping] Comments on draft-poetzl-sipping-call-completion-00
To: "Huelsemann, Martin" <[email-masked]>, [email-masked]
Cc: "Jesske, R" <[email-masked]>, "Poetzl,
	Joachim" <[email-masked]>

Martin,

Thanks for your explanations. More below.

John 

> -----Original Message-----
> From: Huelsemann, Martin [mailto:[email-masked]] 
> Sent: 04 July 2006 13:56
> To: Elwell, John; [email-masked]
> Cc: Poetzl, Joachim; Jesske, R; Alexeitsev, D
> Subject: AW: [Sipping] Comments on 
> draft-poetzl-sipping-call-completion-00
> 
> Hi John,
>  
> thanks for your comments. I have to admit the draft was 
> developed very fastly in order to start the work and to be 
> able to discuss it at the Montreal meeting. Some explaining 
> parts are missing, for which it is important to add them in 
> the 01 version.
>  
> The whole call completion topic deals mainly with queue 
> management between application servers which are able to 
> handle call completion requests in a sequential manner (FIFO 
> queue), so that the first user who activates CCBS on a busy 
> destination ist the first user who is informed that this 
> destination is free for recall now.
>  
> Therefore the new CCBS/CCNR event packages are needed. These 
> packages are not dealing with with the state of the dialog of 
> the busy user (like the dialog event package), as those 
> information are irrelevant for the call completion service on 
> the originating side. The call completion event packages are 
> used for managing the queues between application servers,
[JRE] So are you saying that application servers act as UAs for the
SUBSCRIBE and NOTIFY requests? If so, I think more needs saying about
routing of requests. What causes a SUBSCRIBE request to arrive at the
application server rather than at a conventional UA?
 
> which means reqests to be added to a call completion queue, 
> indications that the request for the queue was succcs.columbia.edu for questions on current sip

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 04 Jul 2006 16:38:03 +0100

Martin,
 
But you could use target-dialog to correlate the call completion call with
the subscription dialog, which I believe still exists at this point in time.
This would be more secure than a binary ccss indication, because the sender
would need to know the dialog identity.
 
John

  _____  

From: Huelsemann, Martin [mailto:[email-masked]] 
Sent: 04 July 2006 15:38
To: [email-masked]
Subject: AW: [Sipping] Comments on draft-poetzl-sipping-call-completion-00

Hi all,
 
there was another comment on the draft, why not to use the Target-Dialog
header instead of the P-Service-Indication header for indicating a call
completion call (ccss indication). I think it can't be used in this case,
because at the time the call completion call is established, the original
dialog from the call resulting in the destination busy situation is already
terminated (as a result from the processing of the 486 Busy response after
the call completion request has been queued on the destination side).

BR, Martin

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 04 Jul 2006 16:38:03 +0100

Martin,

John

  _____  

Hi all,

BR, Martin

---

From: "GARCIN Sebastien RD-CORE-ISS" <[email-masked]>
Date: Tue, 4 Jul 2006 18:33:08 +0200

Hi,
 
[Regarding John's question 2.]
 
First I agree that it would be worth documenting the rational for this parameter and why choosing not to re-use existing SIP headers (From, PAID...). 
 
I believe it is better to have a specific "caller" parameter dedicated for CCB/CCNR usage embedded in the event package because the meaning of the P-Asserted-Identity is overloaded  (it is used for assert the sender of the request, for charging purposes, service triggering...). It can occur that the value of the P-Asserted-Identity is different from that of the "caller" parameter : for example in case where one is used for charging and one is used for subscribing to the queue. Also I don't think we should re-use the "From" header similarily because we should try and avoid overloading its meaning. In short this avoids causing ourselves problems in SIP. With regards to PSTN interworking I would like to point out the "callingpartynumber is optional" (it is service specific)  whereas in  and is also consistent with the PSTN service which defines a specific TCAP parameter "callingPartynumber".
 
The rational for the "caller" parameter is I believe in order for B party's application to correlate the CCBS/CCNR request with one of the earlier calls towards the same busy destination (user B). In other words, B party's application is able to determine for which previously received INVITE towards B this CCBS/CCNR request corresponds. This is optional because operator can choose only to have a single requesting party in B party's queue.
 
regards,
sébastien

________________________________

De : Huelsemann, Martin [mailto:[email-masked]] 
Envoyé : mardi 4 juillet 2006 14:56
À : [email-masked]; [email-masked]
Cc : Jesske, R; Poetzl,Joachim
Objet : AW: [Sipping] Comments on draft-poetzl-sipping-call-completion-00

Hi John,

 

 
 
BR, Martin

	-----Ursprüngliche Nachricht-----
	Von: Elwell, John [mailto:[email-masked]] 
	Gesendet: Montag, 3. Juli 2006 13:53
	An: Hülsemann, Martin; Pötzl, Joachim; Jesske, Roland; sipping
	Betreff: [Sipping] Comments on draft-poetzl-sipping-call-completion-00

	John

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 04 Jul 2006 21:48:41 +0100

Sebastien,

See below.

John 

> From: GARCIN Sebastien RD-CORE-ISS 
> [mailto:[email-masked]] 
> Sent: 04 July 2006 17:33
> To: Huelsemann, Martin; Elwell, John; [email-masked]
> Cc: Jesske, R; Poetzl,Joachim
> First I agree that it would be worth documenting the rational 
> for this parameter and why choosing not to re-use existing 
> SIP headers (From, PAID...). 
>  
> I believe it is better to have a specific "caller" parameter 
> dedicated for CCB/CCNR usage embedded in the event package 
> because the meaning of the P-Asserted-Identity is overloaded  
> (it is used for assert the sender of the request, for 
> charging purposes, service triggering...). It can occur that 
> the value of the P-Asserted-Identity is different from that 
> of the "caller" parameter : for example in case where one is 
> used for charging and one is used for subscribing to the 
> queue. Also I don't think we should re-use the "From" header 
> similarily because we should try and avoid overloading its 
> meaning. In short this avoids causing ourselves problems in 
> SIP. With regards to PSTN interworking I would like to point 
> out the "callingpartynumber is optional" (it is service 
> specific)  whereas in  and is also consistent with the PSTN 
> service which defines a specific TCAP parameter "callingPartynumber".
>  
> The rational for the "caller" parameter is I believe in order 
> for B party's application to correlate the CCBS/CCNR request 
> with one of the earlier calls towards the same busy 
> destination (user B). In other words, B party's application 
> is able to determine for which previously received INVITE 
> towards B this CCBS/CCNR request corresponds.
[JRE] Why would B party's application need to correlate a CCBS/CCNR request
with a previous INVITE towards B? I could not find any requirement in
Roland's requirements draft to back this up.

> This is 
> optional because operator can choose only to have a single 
> requesting party in B party's queue.
>  
> regards,
> sébastien
>  
>

---

From: "GARCIN Sebastien RD-CORE-ISS" <[email-masked]>
Date: Wed, 5 Jul 2006 09:19:55 +0200

Hi John,

[JRE] Why would B party's application need to correlate a CCBS/CCNR request with a previous INVITE towards B? I could not find any requirement in Roland's requirements draft to back this up.

[SG] Actually I was thinking that this correlation could have been used to make sure that the recall was done for the first INVITE message (instead of the first CCBS request). But I did some verification, and you are correct this is not the reason for this parameter. The "caller" parameter seems to be used by ISDN terminals for presentation of the identity of the "CCBS requestor" to the B party.  Therefore I think it is needed at least for PSTN/ISDN interoperability.

sébastien

-----Message d'origine-----
De : Elwell, John [mailto:[email-masked]] 
Envoyé : mardi 4 juillet 2006 22:49
À : GARCIN Sebastien RD-CORE-ISS; Huelsemann, Martin; [email-masked]
Cc : Jesske, R; Poetzl,Joachim
Objet : RE: [Sipping] Comments on draft-poetzl-sipping-call-completion-00

Sebastien,

See below.

John 

> First I agree that it would be worth documenting the rational for this 
> parameter and why choosing not to re-use existing SIP headers (From, 
> PAID...).
>  
> I believe it is better to have a specific "caller" parameter dedicated 
> for CCB/CCNR usage embedded in the event package because the meaning 
> of the P-Asserted-Identity is overloaded (it is used for assert the 
> sender of the request, for charging purposes, service triggering...). 
> It can occur that the value of the P-Asserted-Identity is different 
> from that of the "caller" parameter : for example in case where one is 
> used for charging and one is used for subscribing to the queue. Also I 
> don't think we should re-use the "From" header similarily because we 
> should try and avoid overloading its meaning. In short this avoids 
> causing ourselves problems in SIP. With regards to PSTN interworking I 
> would like to point out the "callingpartynumber is optional" (it is 
> service
> specific)  whereas in  and is also consistent with the PSTN service 
> which defines a specific TCAP parameter "callingPartynumber".
>  
> The rational for the "caller" parameter is I believe in order for B 
> party's application to correlate the CCBS/CCNR request with one of the 
> earlier calls towards the same busy destination (user B). In other 
> words, B party's application is able to determine for which previously 
> received INVITE towards B this CCBS/CCNR request corresponds.
[JRE] Why would B party's application need to correlate a CCBS/CCNR request with a previous INVITE towards B? I could not find any requirement in Roland's requirements draft to back this up.

> This is
> optional because operator can choose only to have a single requesting 
> party in B party's queue.
>  
> regards,
> sébastien
>  
> 
> À : [email-masked]; [email-masked] Cc : Jesske, R; 
> Poetzl,Joachim Objet : AW: [Sipping] Comments on 
> thanks for your comments. I have to admit the draft was developed very 
> fastly in order to start the work and to be able to discuss it at the 
> Montreal meeting. Some explaining parts are missing, for which it is 
> important to add them in the 01 version.
>  
> The whole call completion topic deals mainly with queue management 
> between application servers which are able to handle call completion 
> requests in a sequential manner (FIFO queue), so that the first user 
> who activates CCBS on a busy destination ist the first user who is 
> informed that this destination is free for recall now.
>  
> Therefore the new CCBS/CCNR event packages are needed. These packages 
> are not dealing with with the state of the dialog of the busy user 
> (like the dialog event package), as those information are irrelevant 
> for the call completion service on the originating side. The call 
> completion event packages are used for managing the queues between 
> application servers, which means reqests to be added to a call 
> completion queue, indications that the request for the queue was 
> succsessful, indications that the call completion destination is free 
> for recall now (which not mean that a dialog just has been 
> terminated), requests to suspend the call completion request for a 
> certain time (e.g. because the CCBS using UA is busy), requests to 
> resume a CCBS request, indications why a call completion request can't 
> be fulfilled, and so on. This as a explanation why this new event 
> packages are needed and existing packages (like the dialog event 
> package) can't be used.
>  
> completion call (the call resulting from the indication that the 
> destination is free for recall now). Calls without this indication 
> will be blocked on the terminating side while there are active call 
> completion requests to be processed.
>  
> The caller parameter is needed in case that multiple contatcs are 
> registered at the same time for the same SIP URI, because the CCBS 
> recall (indication that the destination is free for recall now) shall 
> be routed to the contact that has initiated the call completion 
> request and not to all the contacts.
>  
>  
>  
>  
> BR, Martin
>  
> 
> 
> 	In general, I find this draft somewhat difficult to understand, even 
> though I believe I understand the TISPAN requirements for CCBS/CCNR. 
> This is partly a terminology issue (although I think I can follow what 
> is intended from that point of view). It is more a case of what 
> appears to be a lack of explanation of how the proposed new mechanisms 
> will be used and the rationale for choosing them. Just a couple of 
> 	1. The draft proposes a couple of new event packages and a new header 
> field. It does not seem to explain very clearly how these new 
> components are used together to achieve the requirements for call 
> completion. For example, is an INVITE request containing 'ccss' 
> intended to indicate that the INVITE request needs to be correlated in 
> some way with the event package subscription at the UAS? The examples 
> in section 7, if they were to be extended to show full message 
> 	2. Section 5.1.2 defines a parameter "caller" for use in the Event 
> header field of a SUBSCRIBE request. It is not clear why this is 
> needed. There are other standard ways of indicating caller identity, 
> e.g., From header field, From header field with Identity header field, 
> P-Asserted-Identity header field. Some discussion of the rationale for 
> this and why existing mechanisms do not work would be useful.
> 
> 	John
> 
>

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 05 Jul 2006 09:02:44 +0100

Sebastien,
 
> 
> [JRE] Why would B party's application need to correlate a 
> CCBS/CCNR request with a previous INVITE towards B? I could 
> not find any requirement in Roland's requirements draft to 
> back this up.
> 
> [SG] Actually I was thinking that this correlation could have 
> been used to make sure that the recall was done for the first 
> INVITE message (instead of the first CCBS request). But I did 
> some verification, and you are correct this is not the reason 
> for this parameter. The "caller" parameter seems to be used 
> by ISDN terminals for presentation of the identity of the 
> "CCBS requestor" to the B party.  Therefore I think it is 
> needed at least for PSTN/ISDN interoperability.
> 
[JRE] If it is for identity presentation to the B-party, then existing SIP
mechanisms will achieve this. I don't understand your earlier argument about
overloading these mechanisms.

John

---

From: "Huelsemann, Martin" <[email-masked]>
Date: Wed, 5 Jul 2006 10:58:16 +0200

Hi John,

the routing would be part of the service logic in the AS, the adresses can be partly preconfigured, and the originating side of course can resolve the address from the destination side by evaluating the SIP answers from the destination side, e.g. the Via header.

As you said, for the 'ccss' indication there has to be a trust relationship between the UAs using this parameter, in this case the ASs. I personly am open for the suggestion with the Target header, of course we have to check if it works and all requirements are fulfilled. But there might be other points of view.

Also for the caller parameter, if there are existing SIP means that work and sipping would prefer to use, I'm also open for suggestions. Of course like Sebastien said the service itself will not become easier to handle, especialy regarding a possible PSTN interworking.

BR, Martin

-----Ursprüngliche Nachricht-----
Von: Elwell, John [mailto:[email-masked]] 
Gesendet: Dienstag, 4. Juli 2006 17:35
An: Hülsemann, Martin; [email-masked]
Cc: Pötzl, Joachim; Jesske, Roland; Alexeitsev, Denis
Betreff: RE: [Sipping] Comments on draft-poetzl-sipping-call-completion-00

Martin,

John

---

From: "GARCIN Sebastien RD-CORE-ISS" <[email-masked]>
Date: Wed, 5 Jul 2006 11:11:51 +0200

John,
 
Correlating the call completion call with the subscription dialog would not work.
 
Consider a PSTN interworking case (call from PSTN to SIP). In this case the CCBS recall coming from the PSTN will not necessarily be routed to the same gateway that received the TCAP CCBS request. In other words, the PSTN gateway receiving the CCBS request will not have Target-dialog information corresponding to the subsciption dialog.
 
I don't believe that binary ccss indication has security-related issues. This CCBS service is only to be used between trusted domain at NNI interface.
 
sébastien

De : Elwell, John [mailto:[email-masked]] 
Envoyé : mardi 4 juillet 2006 17:38
À : Huelsemann, Martin; [email-masked]
Objet : RE: [Sipping] Comments on draft-poetzl-sipping-call-completion-00

Martin,
 
But you could use target-dialog to correlate the call completion call with the subscription dialog, which I believe still exists at this point in time. This would be more secure than a binary ccss indication, because the sender would need to know the dialog identity.
 
John

	Hi all,
	 
	there was another comment on the draft, why not to use the Target-Dialog header instead of the P-Service-Indication header for indicating a call completion call (ccss indication). I think it can't be used in this case, because at the time the call completion call is established, the original dialog from the call resulting in the destination busy situation is already terminated (as a result from the processing of the 486 Busy response after the call completion request has been queued on the destination side).

	BR, Martin

---

From: "GARCIN Sebastien RD-CORE-ISS" <[email-masked]>
Date: Wed, 5 Jul 2006 10:23:32 +0200

This parameter is optional in the PSTN/ISDN so it is likely that this parameter will not be present in some situations. Currently I believe that this might work with the P-Asserted-Identity header but it seems good practice to keep all the CCBS-related data embedded within the Event package parameters, this simplifies interworking and avoid potential problem we might not have though off. Other views are welcome, I don't have a big problem with your suggestion.

sébastien

-----Message d'origine-----
De : Elwell, John [mailto:[email-masked]] 
Envoyé : mercredi 5 juillet 2006 10:03
À : GARCIN Sebastien RD-CORE-ISS; Huelsemann, Martin; [email-masked]
Cc : Jesske, R; Poetzl,Joachim
Objet : RE: [Sipping] Comments on draft-poetzl-sipping-call-completion-00

Sebastien,
 
> 
> [JRE] Why would B party's application need to correlate a CCBS/CCNR 
> request with a previous INVITE towards B? I could not find any 
> requirement in Roland's requirements draft to back this up.
> 
> [SG] Actually I was thinking that this correlation could have been 
> used to make sure that the recall was done for the first INVITE 
> message (instead of the first CCBS request). But I did some 
> verification, and you are correct this is not the reason for this 
> parameter. The "caller" parameter seems to be used by ISDN terminals 
> for presentation of the identity of the "CCBS requestor" to the B 
> party.  Therefore I think it is needed at least for PSTN/ISDN 
> interoperability.
> 
[JRE] If it is for identity presentation to the B-party, then existing SIP mechanisms will achieve this. I don't understand your earlier argument about overloading these mechanisms.

John

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 05 Jul 2006 12:23:18 +0100

Sebastien,

John 

> Sent: 05 July 2006 10:12
> To: Elwell, John; Huelsemann, Martin; [email-masked]
> Consider a PSTN interworking case (call from PSTN to SIP). In 
> this case the CCBS recall 
[JRE] I thought a CCBS recall was an indication from the caller's
application server to the caller that he can now complete his call, if he
wishes. I did not think it was something signalled between application
servers or to/from the PSTN. However, perhaps this misunderstanding arose
from the use of the undefined term "network" in the definition of CCBS
recall.

> coming from the PSTN will not 
> necessarily be routed to the same gateway that received the 
> TCAP CCBS request. In other words, the PSTN gateway receiving 
> the CCBS request will not have Target-dialog information 
> corresponding to the subsciption dialog.
[JRE] So are you also implying that the CCBS call might reach a PSTN gateway
that is different from the one the original CCBS request went to? If so,
then I agree that correlation is not possible. Presumably correlation would
need to be done within the PSTN in this case, so any SIP-specific
correlation would not work.

>  
> I don't believe that binary ccss indication has 
> security-related issues. This CCBS service is only to be used 
> between trusted domain at NNI interface.
>  
> sébastien
> 
> But you could use target-dialog to correlate the call 
> completion call with the subscription dialog, which I believe 
> still exists at this point in time. This would be more secure 
> than a binary ccss indication, because the sender would need 
> to know the dialog identity.
>  
> John
> 
> 
> 	there was another comment on the draft, why not to use 
> the Target-Dialog header instead of the P-Service-Indication 
> header for indicating a call completion call (ccss 
> indication). I think it can't be used in this case, because 
> at the time the call completion call is established, the 
> original dialog from the call resulting in the destination 
> busy situation is already terminated (as a result from the 
> processing of the 486 Busy response after the call completion 
> request has been queued on the destination side).
> 	 
> 	 
> 	BR, Martin
> 	 
> 	 
> 
>

---

From: "Huelsemann, Martin" <[email-masked]>
Date: Wed, 5 Jul 2006 13:45:57 +0200

John,

you're right, the CCBS recall is the indication to the originating user that the call completion target is free for recall now. The CCBS call then is the call establishment to the terminating side. So it is the CCBS call for which it is not shure that it is routed to the correct gateway on the PSTN side.
So like Sebastien said the Target-dialog will not work in all cases, we need a special 'ccss' indication which can be mapped.

Martin

Mit freundlichem Gruß,

Martin Hülsemann

_______________________________________________________ 
Deutsche Telekom AG
T-Com Zentrale 
Martin Hülsemann 
Section TE332-1; Signalling, Gateways and Switching Systems
P.O. Box 10 00 03
64307 Darmstadt, Germany
Phone: +49 6151 83-18742
Fax: +49 6151 83-4577
eMail: [email-masked]
_______________________________________________________ 

-----Ursprüngliche Nachricht-----
Von: Elwell, John [mailto:[email-masked]] 
Gesendet: Mittwoch, 5. Juli 2006 13:23
An: GARCIN Sebastien RD-CORE-ISS; Hülsemann, Martin; [email-masked]
Betreff: RE: [Sipping] Comments on draft-poetzl-sipping-call-completion-00

Sebastien,

John