headers
Dale.Worley | 1 Apr 2008 01:02
Picon

Re: draft-ietf-sipping-sbc-funcs-05.txt: multiple media streams

   From: Hendrik Scholz <hs <at> 123.org>

   What happens if the call forks and the UAC could receive multiple
   early media streams?
   From my point of view the SBC should never expose more than one
   media stream towards the UAC and terminate/supress additional
   streams where needed.

   Shouldn't this be documented as a requirement?

Why should this be a requirement?  SIP UAs are already prepared to
handle it.

Dale
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sip <at> ietf.org for new developments of core SIP
Permalink | Reply | 0 comments |
headers
Hadriel Kaplan | 1 Apr 2008 02:50
Favicon

Re: draft-ietf-sipping-sbc-funcs-05.txt: multiple media streams


> -----Original Message-----
> From: sipping-bounces <at> ietf.org [mailto:sipping-bounces <at> ietf.org] On Behalf
> Of Hendrik Scholz
>
> Section 3.2. Media Traffic Management only describes one to one
> media streams.
> One UAC sends/receives one stream which is relayed through an SBC.
>
> What happens if the call forks and the UAC could receive multiple
> early media streams?
> From my point of view the SBC should never expose more than one
> media stream towards the UAC and terminate/supress additional
> streams where needed.
>
> Shouldn't this be documented as a requirement?

A requirement for whom?  The only real requirements I am aware of in the sbc-funcs draft are the ones derived
from some SBC functions, for the purpose of documenting a few functions that there should/could be a
SIP-UA way to provide/do.  A SIP-UA can already ignore or not ignore multiple media streams as it sees fit.

For an SBC, that "requirement" is specific to the application, provider, or vendor.  Just like blocking
early media or blocking specific media codecs, for example.  Some providers want/need that, others don't.

-hadriel
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sip <at> ietf.org for new developments of core SIP
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ian Elz | 1 Apr 2008 10:58
Picon
Favicon

Re: draft-mahy-iptel-cpc

Paul,

My comments are made based upon the content of the latest draft (06).

The introduction begins:

   "SS7 ISUP [4] defines a Calling Party's Category (CPC) parameter that
   characterizes the station used to originate a call and carries other
   important state that can describe the originating party.  When
   telephone numbers are contained in URIs, such as the tel URI [2], it
   may be desirable to communicate any CPC associated with that
   telephone number or, in the context of a call, the party calling from
   it."

Based upon this the current requirement appears to be to support the
ISUP CPC/OLI.

If the requirement is greater than this then that is a discussion that
we should have before the draft is finalized.

The issue with mutual exclusivity exists in the current ISUP
implementations. If that limitation is to be overcome then that
requirement also needs to be discussed. If we are to move from mutual
exclusivity of values then we need to ensure that interworking back to
ISUP is supported. The resolution of the overlapping cases as you have
indicated may have to be at the discretion of the network operator.

Ian Elz

System Manager
(Continue reading)

Permalink | Reply | 7 comments |
headers
DOLLY, MARTIN C, ATTLABS | 1 Apr 2008 14:16
Picon
Favicon

Re: draft-mahy-iptel-cpc

Ian,

CPC: Information sent in the forward direction indicating the category
of the calling party and, in case of semiautomatic calls, the service
language to be spoken by the incoming, delay and assistance operators.
The format of the calling party's category is shown below.

OLI:  Information sent in the forward direction indicating toll class of
service. Identification of the originating line.

Martin

-----Original Message-----
From: Ian Elz [mailto:ian.elz <at> ericsson.com] 
Sent: Tuesday, April 01, 2008 4:58 AM
To: Paul Kyzivat
Cc: iptel <at> ietf.org; DOLLY, MARTIN C, ATTLABS; sipping <at> ietf.org
Subject: RE: [Sipping] draft-mahy-iptel-cpc

Paul,

My comments are made based upon the content of the latest draft (06).

The introduction begins:

   "SS7 ISUP [4] defines a Calling Party's Category (CPC) parameter that
   characterizes the station used to originate a call and carries other
   important state that can describe the originating party.  When
   telephone numbers are contained in URIs, such as the tel URI [2], it
   may be desirable to communicate any CPC associated with that
(Continue reading)

Permalink | Reply | 6 comments |
headers
Ian Elz | 1 Apr 2008 14:20
Picon
Favicon

Re: draft-mahy-iptel-cpc

Martin,

Sorry my choice of words. 'back to ISUP' was not meant to imply a
backward direction message but where the interworking from SIP -> ISUP.

ISUP -> SIP working is easy as ISUP will only contain one value but if
SIP contains multiple values as Paul has suggested then we need to be
able to map these to a single value in ISUP.

Ian Elz

System Manager
DUCI LDC UK
(Lucid Duck)

Office: + 44 24 764 35256
gsm: +44 7801723668
ian.elz <at> ericsson.com

-----Original Message-----
From: DOLLY, MARTIN C, ATTLABS [mailto:mdolly <at> att.com] 
Sent: 01 April 2008 13:16
To: Ian Elz; iptel <at> ietf.org; sipping <at> ietf.org
Subject: RE: [Sipping] draft-mahy-iptel-cpc

Ian,

CPC: Information sent in the forward direction indicating the category
of the calling party and, in case of semiautomatic calls, the service
language to be spoken by the incoming, delay and assistance operators.
(Continue reading)

Permalink | Reply | 5 comments |
headers
Francois Audet | 2 Apr 2008 00:09
Favicon

Re: draft-mahy-iptel-cpc

Keith,
 
Tel URI vs SIP URI is one issue. My guess is Tel URI is OK, and it will map into a SIP URI fine. If we believe that this concept is applicable to URIs that are not telephone numbers, then it should be a SIP URI parameter instead. Don't really care either way.
 
The other issue is "From:" header versus "P-Asserted-ID". I believe this parameter is intended to be provided by the "network" and not the UAC. So it would seem to me that it should be in P-Asserted-ID parameter header and not From header. Especially if RFC 4474 is used.
 
I think Paul Kyzivat was even proposing a P-Asserted-ID parameter. That would work too.

From: sipping-bounces <at> ietf.org [mailto:sipping-bounces <at> ietf.org] On Behalf Of DRAGE, Keith (Keith)
Sent: Saturday, March 29, 2008 16:26
To: DOLLY, MARTIN C, sbcuid; Sumit Garg; iptel <at> ietf.org; sipping <at> ietf.org
Subject: Re: [Sipping] draft-mahy-iptel-cpc

My understanding of the cpc work in iptel is that is currently held pending the approval of the internet draft defining the approval regime for tel URI parameters. I believe the current status of this is to make the approval of tel URI parameters standards track required, although that could have altered - not in a position to look it up currently.
 
Which brings us to the next issue in that I understand that at least some of the TISPAN people want to use this as a SIP URI parameter as well as a tel URI parameter. These are two distinct sets of parameters and therefore a tel URI parameter does not automatically become a SIP URI parameter.
 
Is this so? Are there any indications which we want to be able to use with SIP URIs as well as tel URIs.
 
regards
 
Keith
 
 

From: sipping-bounces <at> ietf.org [mailto:sipping-bounces <at> ietf.org] On Behalf Of DOLLY, MARTIN C, sbcuid
Sent: Friday, March 28, 2008 6:15 PM
To: Sumit Garg; iptel <at> ietf.org; sipping <at> ietf.org
Subject: Re: [Sipping] draft-mahy-iptel-cpc

Sumit,
 
For as long as the values are clear, this approach would be acceptable.
 
Martin

From: sipping-bounces <at> ietf.org [mailto:sipping-bounces <at> ietf.org] On Behalf Of Sumit Garg
Sent: Friday, March 28, 2008 2:09 PM
To: iptel <at> ietf.org; sipping <at> ietf.org
Subject: Re: [Sipping] draft-mahy-iptel-cpc

I agree with Ian, we should avoid multiple parameters.

The way a lot of stuff is done in tel-uri might be useful….

 

We would only  need 1 parameter:  i.)  user-type=<cpc/oli-values>

                Renamed to user-type as we do not necessarily tie it to originating side…..we might find other needs in the future.

 

For the current scenario, the number itself would help the implementation decide whether it is CPC/OLI.

A global number inherently has a country code which would help decide the valid values (cpc/oli)

Otherwise the phone-context could be used to decide the same.

 

For implementations which use neither..i.e. for which context is implicit…they would implicitly know whether  it is cpc/oli.

 

-Sumit

 

 

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man."
-- George Bernard Shaw

From: Ian Elz [mailto:ian.elz <at> ericsson.com]
Sent: Friday, March 28, 2008 12:10 PM
To: DOLLY, MARTIN C, sbcuid; Sumit Garg; iptel <at> ietf.org; sipping <at> ietf.org
Subject: RE: [Sipping] draft-mahy-iptel-cpc

 

Martin,

 

I saw you email with the list of values.

 

I was not proposing to remove the values but to combine them into an extended list which encompassed both OLI and CPC. ANSI does not use CPC to any extent while ETSI/CCITT uses CPC for the same purpose as ANSI uses OLI.

 

An expanded combined single parameter may be suitable for all the required values.

 

If you look at what is proposed by 3GPP you will see that it is proposed to reduce the different CCITT operator CPC values by using ‘language’ in Accept-Contact. There may be options to use similar techniques to enable all the OLI values to be handled correctly.

Ian Elz

System Manager
DUCI LDC UK
(Lucid Duck)

Office: + 44 24 764 35256
gsm: +44 7801723668
ian.elz <at> ericsson.com 

_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sip <at> ietf.org for new developments of core SIP
Permalink | Reply | 3 comments |
headers
Paul Kyzivat | 2 Apr 2008 01:44
Picon
Favicon

Re: draft-mahy-iptel-cpc


Francois Audet wrote:
> Keith,
>  
> Tel URI vs SIP URI is one issue. My guess is Tel URI is OK, and it 
> will map into a SIP URI fine. If we believe that this concept is 
> applicable to URIs that are not telephone numbers, then it should be a 
> SIP URI parameter instead. Don't really care either way.
>  
> The other issue is "From:" header versus "P-Asserted-ID". I believe this 
> parameter is intended to be provided by the "network" and not the UAC. 
> So it would seem to me that it should be in P-Asserted-ID parameter 
> header and not From header. Especially if RFC 4474 is used.
>  
> I think Paul Kyzivat was even proposing a P-Asserted-ID parameter. That 
> would work too.

To be clear, I don't have any particular ax to grind about this 
proposal. I just find it technically questionable. The semantics are 
fuzzy, and the means to convey them seems inappropriate.

Ignoring the fuzziness, the semantics are such that they must be 
asserted by some trusted party, not the UAC. And so they don't make 
sense in most places that a TEL URI might appear. About the only place 
they seem to make sense is a PAI. If that is the only place they make 
sense, then adding them to that header makes more sense. Also, there is 
no such thing as P- parameters for TEL, but this seems to be something 
with the applicability characteristics of a P- header, which is another 
reason to go for PAI.

I can see that the information conveyed by this parameter is indeed 
useful information to have, if one has a reason to believe it. And it 
would be equally useful if the request originated at a SIP UAC rather 
than in the PSTN, and also if the source had a non-numeric sip identity 
rather than a telephone number identity. (Surely you would like to know 
if the IM you just received was from somebody in a prison.)

The only reason I can see to exclude SIP originated calls and 
non-numeric URIs is because we don't know how to accurately determine 
the information or how to ascertain that it it has been conveyed 
truthfully. But that is true for telephone numbers too, as well as calls 
gatewayed from the pstn to sip. Until we know how to do that on the open 
internet this seems to fall in the realm of closed gardens and P- headers.

	Paul

>     ------------------------------------------------------------------------
>     *From:* sipping-bounces <at> ietf.org [mailto:sipping-bounces <at> ietf.org]
>     *On Behalf Of *DRAGE, Keith (Keith)
>     *Sent:* Saturday, March 29, 2008 16:26
>     *To:* DOLLY, MARTIN C, sbcuid; Sumit Garg; iptel <at> ietf.org;
>     sipping <at> ietf.org
>     *Subject:* Re: [Sipping] draft-mahy-iptel-cpc
> 
>     My understanding of the cpc work in iptel is that is currently held
>     pending the approval of the internet draft defining the approval
>     regime for tel URI parameters. I believe the current status of this
>     is to make the approval of tel URI parameters standards track
>     required, although that could have altered - not in a position to
>     look it up currently.
>      
>     Which brings us to the next issue in that I understand that at least
>     some of the TISPAN people want to use this as a SIP URI parameter as
>     well as a tel URI parameter. These are two distinct sets of
>     parameters and therefore a tel URI parameter does not automatically
>     become a SIP URI parameter.
>      
>     Is this so? Are there any indications which we want to be able to
>     use with SIP URIs as well as tel URIs.
>      
>     regards
>      
>     Keith
>      
>      
> 
>         ------------------------------------------------------------------------
>         *From:* sipping-bounces <at> ietf.org
>         [mailto:sipping-bounces <at> ietf.org] *On Behalf Of *DOLLY, MARTIN
>         C, sbcuid
>         *Sent:* Friday, March 28, 2008 6:15 PM
>         *To:* Sumit Garg; iptel <at> ietf.org; sipping <at> ietf.org
>         *Subject:* Re: [Sipping] draft-mahy-iptel-cpc
> 
>         Sumit,
>          
>         For as long as the values are clear, this approach would be
>         acceptable.
>          
>         Martin
> 
>         ------------------------------------------------------------------------
>         *From:* sipping-bounces <at> ietf.org
>         [mailto:sipping-bounces <at> ietf.org] *On Behalf Of *Sumit Garg
>         *Sent:* Friday, March 28, 2008 2:09 PM
>         *To:* iptel <at> ietf.org; sipping <at> ietf.org
>         *Subject:* Re: [Sipping] draft-mahy-iptel-cpc
> 
>         I agree with Ian, we should avoid multiple parameters.
> 
>         The way a lot of stuff is done in tel-uri might be useful….
> 
>          
> 
>         We would only  need 1 parameter:  i.)  user-type=<cpc/oli-values>
> 
>                         Renamed /to user-type as we do not necessarily
>         tie it to originating side…..we might find other needs in the
>         future./
> 
>          
> 
>         For the current scenario, the number itself would help the
>         implementation decide whether it is CPC/OLI.
> 
>         A global number inherently has a country code which would help
>         decide the valid values (cpc/oli)
> 
>         Otherwise the phone-context could be used to decide the same.
> 
>          
> 
>         For implementations which use neither..i.e. for which context is
>         implicit…they would implicitly know whether  it is cpc/oli.
> 
>          
> 
>         -Sumit
> 
>          
> 
>          
> 
>         "The reasonable man adapts himself to the world; the
>         unreasonable one persists in trying to adapt the world to
>         himself. Therefore all progress depends on the unreasonable man."
>         -- George Bernard Shaw
> 
>         *From:* Ian Elz [mailto:ian.elz <at> ericsson.com]
>         *Sent:* Friday, March 28, 2008 12:10 PM
>         *To:* DOLLY, MARTIN C, sbcuid; Sumit Garg; iptel <at> ietf.org;
>         sipping <at> ietf.org
>         *Subject:* RE: [Sipping] draft-mahy-iptel-cpc
> 
>          
> 
>         Martin,
> 
>          
> 
>         I saw you email with the list of values.
> 
>          
> 
>         I was not proposing to remove the values but to combine them
>         into an extended list which encompassed both OLI and CPC. ANSI
>         does not use CPC to any extent while ETSI/CCITT uses CPC for the
>         same purpose as ANSI uses OLI.
> 
>          
> 
>         An expanded combined single parameter may be suitable for all
>         the required values.
> 
>          
> 
>         If you look at what is proposed by 3GPP you will see that it is
>         proposed to reduce the different CCITT operator CPC values by
>         using ‘language’ in Accept-Contact. There may be options to use
>         similar techniques to enable all the OLI values to be handled
>         correctly.
> 
>         /Ian Elz/
> 
>         /System Manager/
>         /DUCI LDC UK/
>         /(Lucid Duck)/
> 
>         /Office: + 44 24 764 35256/
>         /gsm: +44 7801723668/
>         /ian.elz <at> ericsson.com/
> 
>         ------------------------------------------------------------------------
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sip <at> ietf.org for new developments of core SIP
Permalink | Reply | 2 comments |
headers
Alan Johnston | 2 Apr 2008 02:21

Re: draft-mahy-iptel-cpc

Paul Kyzivat wrote:
> Francois Audet wrote:
>   
>> Keith,
>>  
>> Tel URI vs SIP URI is one issue. My guess is Tel URI is OK, and it 
>> will map into a SIP URI fine. If we believe that this concept is 
>> applicable to URIs that are not telephone numbers, then it should be a 
>> SIP URI parameter instead. Don't really care either way.
>>  
>> The other issue is "From:" header versus "P-Asserted-ID". I believe this 
>> parameter is intended to be provided by the "network" and not the UAC. 
>> So it would seem to me that it should be in P-Asserted-ID parameter 
>> header and not From header. Especially if RFC 4474 is used.
>>  
>> I think Paul Kyzivat was even proposing a P-Asserted-ID parameter. That 
>> would work too.
>>     
>
> To be clear, I don't have any particular ax to grind about this 
> proposal. I just find it technically questionable. The semantics are 
> fuzzy, and the means to convey them seems inappropriate.
>
> Ignoring the fuzziness, the semantics are such that they must be 
> asserted by some trusted party, not the UAC. And so they don't make 
> sense in most places that a TEL URI might appear. About the only place 
> they seem to make sense is a PAI. If that is the only place they make 
> sense, then adding them to that header makes more sense. Also, there is 
> no such thing as P- parameters for TEL, but this seems to be something 
> with the applicability characteristics of a P- header, which is another 
> reason to go for PAI.
>   

A long time ago in a galaxy far, far away, I proposed CPC be added to 
the Remote-Party-ID header field (remember that?) which 
P-Asserted-Identity eventually replaced.  It was added to that I-D, but 
I don't recall why this info never made it into P-A-I.

I agree that it makes better sense there than as a tel URI parameter.

Thanks,
Alan

> I can see that the information conveyed by this parameter is indeed 
> useful information to have, if one has a reason to believe it. And it 
> would be equally useful if the request originated at a SIP UAC rather 
> than in the PSTN, and also if the source had a non-numeric sip identity 
> rather than a telephone number identity. (Surely you would like to know 
> if the IM you just received was from somebody in a prison.)
>
> The only reason I can see to exclude SIP originated calls and 
> non-numeric URIs is because we don't know how to accurately determine 
> the information or how to ascertain that it it has been conveyed 
> truthfully. But that is true for telephone numbers too, as well as calls 
> gatewayed from the pstn to sip. Until we know how to do that on the open 
> internet this seems to fall in the realm of closed gardens and P- headers.
>
> 	Paul
>
>   
>>     ------------------------------------------------------------------------
>>     *From:* sipping-bounces <at> ietf.org [mailto:sipping-bounces <at> ietf.org]
>>     *On Behalf Of *DRAGE, Keith (Keith)
>>     *Sent:* Saturday, March 29, 2008 16:26
>>     *To:* DOLLY, MARTIN C, sbcuid; Sumit Garg; iptel <at> ietf.org;
>>     sipping <at> ietf.org
>>     *Subject:* Re: [Sipping] draft-mahy-iptel-cpc
>>
>>     My understanding of the cpc work in iptel is that is currently held
>>     pending the approval of the internet draft defining the approval
>>     regime for tel URI parameters. I believe the current status of this
>>     is to make the approval of tel URI parameters standards track
>>     required, although that could have altered - not in a position to
>>     look it up currently.
>>      
>>     Which brings us to the next issue in that I understand that at least
>>     some of the TISPAN people want to use this as a SIP URI parameter as
>>     well as a tel URI parameter. These are two distinct sets of
>>     parameters and therefore a tel URI parameter does not automatically
>>     become a SIP URI parameter.
>>      
>>     Is this so? Are there any indications which we want to be able to
>>     use with SIP URIs as well as tel URIs.
>>      
>>     regards
>>      
>>     Keith
>>      
>>      
>>
>>         ------------------------------------------------------------------------
>>         *From:* sipping-bounces <at> ietf.org
>>         [mailto:sipping-bounces <at> ietf.org] *On Behalf Of *DOLLY, MARTIN
>>         C, sbcuid
>>         *Sent:* Friday, March 28, 2008 6:15 PM
>>         *To:* Sumit Garg; iptel <at> ietf.org; sipping <at> ietf.org
>>         *Subject:* Re: [Sipping] draft-mahy-iptel-cpc
>>
>>         Sumit,
>>          
>>         For as long as the values are clear, this approach would be
>>         acceptable.
>>          
>>         Martin
>>
>>         ------------------------------------------------------------------------
>>         *From:* sipping-bounces <at> ietf.org
>>         [mailto:sipping-bounces <at> ietf.org] *On Behalf Of *Sumit Garg
>>         *Sent:* Friday, March 28, 2008 2:09 PM
>>         *To:* iptel <at> ietf.org; sipping <at> ietf.org
>>         *Subject:* Re: [Sipping] draft-mahy-iptel-cpc
>>
>>         I agree with Ian, we should avoid multiple parameters.
>>
>>         The way a lot of stuff is done in tel-uri might be useful….
>>
>>          
>>
>>         We would only  need 1 parameter:  i.)  user-type=<cpc/oli-values>
>>
>>                         Renamed /to user-type as we do not necessarily
>>         tie it to originating side…..we might find other needs in the
>>         future./
>>
>>          
>>
>>         For the current scenario, the number itself would help the
>>         implementation decide whether it is CPC/OLI.
>>
>>         A global number inherently has a country code which would help
>>         decide the valid values (cpc/oli)
>>
>>         Otherwise the phone-context could be used to decide the same.
>>
>>          
>>
>>         For implementations which use neither..i.e. for which context is
>>         implicit…they would implicitly know whether  it is cpc/oli.
>>
>>          
>>
>>         -Sumit
>>
>>          
>>
>>          
>>
>>         "The reasonable man adapts himself to the world; the
>>         unreasonable one persists in trying to adapt the world to
>>         himself. Therefore all progress depends on the unreasonable man."
>>         -- George Bernard Shaw
>>
>>         *From:* Ian Elz [mailto:ian.elz <at> ericsson.com]
>>         *Sent:* Friday, March 28, 2008 12:10 PM
>>         *To:* DOLLY, MARTIN C, sbcuid; Sumit Garg; iptel <at> ietf.org;
>>         sipping <at> ietf.org
>>         *Subject:* RE: [Sipping] draft-mahy-iptel-cpc
>>
>>          
>>
>>         Martin,
>>
>>          
>>
>>         I saw you email with the list of values.
>>
>>          
>>
>>         I was not proposing to remove the values but to combine them
>>         into an extended list which encompassed both OLI and CPC. ANSI
>>         does not use CPC to any extent while ETSI/CCITT uses CPC for the
>>         same purpose as ANSI uses OLI.
>>
>>          
>>
>>         An expanded combined single parameter may be suitable for all
>>         the required values.
>>
>>          
>>
>>         If you look at what is proposed by 3GPP you will see that it is
>>         proposed to reduce the different CCITT operator CPC values by
>>         using ‘language’ in Accept-Contact. There may be options to use
>>         similar techniques to enable all the OLI values to be handled
>>         correctly.
>>
>>         /Ian Elz/
>>
>>         /System Manager/
>>         /DUCI LDC UK/
>>         /(Lucid Duck)/
>>
>>         /Office: + 44 24 764 35256/
>>         /gsm: +44 7801723668/
>>         /ian.elz <at> ericsson.com/
>>
>>         ------------------------------------------------------------------------
>>     
> _______________________________________________
> Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-implementors <at> cs.columbia.edu for questions on current sip
> Use sip <at> ietf.org for new developments of core SIP
>
>
>   

_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sip <at> ietf.org for new developments of core SIP
Permalink | Reply | 1 comment |
headers
DOLLY, MARTIN C, ATTLABS | 2 Apr 2008 02:40
Picon
Favicon

Re: draft-mahy-iptel-cpc

I agree cpc and oli should be associated with the PAI. 

-----Original Message-----
From: Alan Johnston [mailto:alan <at> sipstation.com] 
Sent: Tuesday, April 01, 2008 8:21 PM
To: Paul Kyzivat
Cc: Francois Audet; iptel <at> ietf.org; DOLLY, MARTIN C, ATTLABS;
sipping <at> ietf.org; DRAGE, Keith (Keith)
Subject: Re: [Sipping] draft-mahy-iptel-cpc

Paul Kyzivat wrote:
> Francois Audet wrote:
>   
>> Keith,
>>  
>> Tel URI vs SIP URI is one issue. My guess is Tel URI is OK, and it 
>> will map into a SIP URI fine. If we believe that this concept is 
>> applicable to URIs that are not telephone numbers, then it should be
a 
>> SIP URI parameter instead. Don't really care either way.
>>  
>> The other issue is "From:" header versus "P-Asserted-ID". I believe
this 
>> parameter is intended to be provided by the "network" and not the
UAC. 
>> So it would seem to me that it should be in P-Asserted-ID parameter 
>> header and not From header. Especially if RFC 4474 is used.
>>  
>> I think Paul Kyzivat was even proposing a P-Asserted-ID parameter.
That 
>> would work too.
>>     
>
> To be clear, I don't have any particular ax to grind about this 
> proposal. I just find it technically questionable. The semantics are 
> fuzzy, and the means to convey them seems inappropriate.
>
> Ignoring the fuzziness, the semantics are such that they must be 
> asserted by some trusted party, not the UAC. And so they don't make 
> sense in most places that a TEL URI might appear. About the only place

> they seem to make sense is a PAI. If that is the only place they make 
> sense, then adding them to that header makes more sense. Also, there
is 
> no such thing as P- parameters for TEL, but this seems to be something

> with the applicability characteristics of a P- header, which is
another 
> reason to go for PAI.
>   

A long time ago in a galaxy far, far away, I proposed CPC be added to 
the Remote-Party-ID header field (remember that?) which 
P-Asserted-Identity eventually replaced.  It was added to that I-D, but 
I don't recall why this info never made it into P-A-I.

I agree that it makes better sense there than as a tel URI parameter.

Thanks,
Alan

> I can see that the information conveyed by this parameter is indeed 
> useful information to have, if one has a reason to believe it. And it 
> would be equally useful if the request originated at a SIP UAC rather 
> than in the PSTN, and also if the source had a non-numeric sip
identity 
> rather than a telephone number identity. (Surely you would like to
know 
> if the IM you just received was from somebody in a prison.)
>
> The only reason I can see to exclude SIP originated calls and 
> non-numeric URIs is because we don't know how to accurately determine 
> the information or how to ascertain that it it has been conveyed 
> truthfully. But that is true for telephone numbers too, as well as
calls 
> gatewayed from the pstn to sip. Until we know how to do that on the
open 
> internet this seems to fall in the realm of closed gardens and P-
headers.
>
> 	Paul
>
>   
>>
------------------------------------------------------------------------
>>     *From:* sipping-bounces <at> ietf.org
[mailto:sipping-bounces <at> ietf.org]
>>     *On Behalf Of *DRAGE, Keith (Keith)
>>     *Sent:* Saturday, March 29, 2008 16:26
>>     *To:* DOLLY, MARTIN C, sbcuid; Sumit Garg; iptel <at> ietf.org;
>>     sipping <at> ietf.org
>>     *Subject:* Re: [Sipping] draft-mahy-iptel-cpc
>>
>>     My understanding of the cpc work in iptel is that is currently
held
>>     pending the approval of the internet draft defining the approval
>>     regime for tel URI parameters. I believe the current status of
this
>>     is to make the approval of tel URI parameters standards track
>>     required, although that could have altered - not in a position to
>>     look it up currently.
>>      
>>     Which brings us to the next issue in that I understand that at
least
>>     some of the TISPAN people want to use this as a SIP URI parameter
as
>>     well as a tel URI parameter. These are two distinct sets of
>>     parameters and therefore a tel URI parameter does not
automatically
>>     become a SIP URI parameter.
>>      
>>     Is this so? Are there any indications which we want to be able to
>>     use with SIP URIs as well as tel URIs.
>>      
>>     regards
>>      
>>     Keith
>>      
>>      
>>
>>
------------------------------------------------------------------------
>>         *From:* sipping-bounces <at> ietf.org
>>         [mailto:sipping-bounces <at> ietf.org] *On Behalf Of *DOLLY,
MARTIN
>>         C, sbcuid
>>         *Sent:* Friday, March 28, 2008 6:15 PM
>>         *To:* Sumit Garg; iptel <at> ietf.org; sipping <at> ietf.org
>>         *Subject:* Re: [Sipping] draft-mahy-iptel-cpc
>>
>>         Sumit,
>>          
>>         For as long as the values are clear, this approach would be
>>         acceptable.
>>          
>>         Martin
>>
>>
------------------------------------------------------------------------
>>         *From:* sipping-bounces <at> ietf.org
>>         [mailto:sipping-bounces <at> ietf.org] *On Behalf Of *Sumit Garg
>>         *Sent:* Friday, March 28, 2008 2:09 PM
>>         *To:* iptel <at> ietf.org; sipping <at> ietf.org
>>         *Subject:* Re: [Sipping] draft-mahy-iptel-cpc
>>
>>         I agree with Ian, we should avoid multiple parameters.
>>
>>         The way a lot of stuff is done in tel-uri might be useful....
>>
>>          
>>
>>         We would only  need 1 parameter:  i.)
user-type=<cpc/oli-values>
>>
>>                         Renamed /to user-type as we do not
necessarily
>>         tie it to originating side.....we might find other needs in
the
>>         future./
>>
>>          
>>
>>         For the current scenario, the number itself would help the
>>         implementation decide whether it is CPC/OLI.
>>
>>         A global number inherently has a country code which would
help
>>         decide the valid values (cpc/oli)
>>
>>         Otherwise the phone-context could be used to decide the same.
>>
>>          
>>
>>         For implementations which use neither..i.e. for which context
is
>>         implicit...they would implicitly know whether  it is cpc/oli.
>>
>>          
>>
>>         -Sumit
>>
>>          
>>
>>          
>>
>>         "The reasonable man adapts himself to the world; the
>>         unreasonable one persists in trying to adapt the world to
>>         himself. Therefore all progress depends on the unreasonable
man."
>>         -- George Bernard Shaw
>>
>>         *From:* Ian Elz [mailto:ian.elz <at> ericsson.com]
>>         *Sent:* Friday, March 28, 2008 12:10 PM
>>         *To:* DOLLY, MARTIN C, sbcuid; Sumit Garg; iptel <at> ietf.org;
>>         sipping <at> ietf.org
>>         *Subject:* RE: [Sipping] draft-mahy-iptel-cpc
>>
>>          
>>
>>         Martin,
>>
>>          
>>
>>         I saw you email with the list of values.
>>
>>          
>>
>>         I was not proposing to remove the values but to combine them
>>         into an extended list which encompassed both OLI and CPC.
ANSI
>>         does not use CPC to any extent while ETSI/CCITT uses CPC for
the
>>         same purpose as ANSI uses OLI.
>>
>>          
>>
>>         An expanded combined single parameter may be suitable for all
>>         the required values.
>>
>>          
>>
>>         If you look at what is proposed by 3GPP you will see that it
is
>>         proposed to reduce the different CCITT operator CPC values by
>>         using 'language' in Accept-Contact. There may be options to
use
>>         similar techniques to enable all the OLI values to be handled
>>         correctly.
>>
>>         /Ian Elz/
>>
>>         /System Manager/
>>         /DUCI LDC UK/
>>         /(Lucid Duck)/
>>
>>         /Office: + 44 24 764 35256/
>>         /gsm: +44 7801723668/
>>         /ian.elz <at> ericsson.com/
>>
>>
------------------------------------------------------------------------
>>     
> _______________________________________________
> Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-implementors <at> cs.columbia.edu for questions on current sip
> Use sip <at> ietf.org for new developments of core SIP
>
>
>   

_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sip <at> ietf.org for new developments of core SIP
Permalink | Reply | 0 comments |
headers
Lee, Yiu | 2 Apr 2008 02:39
Picon

Re: draft-mahy-iptel-cpc

After reading all the mails in the list, I think we agree:

1. OLI-CPC should be carried in one parameter. Exact syntax yet to be
defined.
2. This parameter should be inserted by originating network but not the
UAC (From vs. PAI).
3. This parameter is useful for both SIP-URI and TEL-URI.

We haven't agreed if we allow the parameter carries multiple values (due
to SIP->ISUP interop)

Now my question is what is next step?

-----Original Message-----
From: sipping-bounces <at> ietf.org [mailto:sipping-bounces <at> ietf.org] On
Behalf Of Ian Elz
Sent: Tuesday, April 01, 2008 8:21 AM
To: DOLLY, MARTIN C, ATTLABS; iptel <at> ietf.org; sipping <at> ietf.org
Subject: Re: [Sipping] draft-mahy-iptel-cpc

Martin,

Sorry my choice of words. 'back to ISUP' was not meant to imply a
backward direction message but where the interworking from SIP -> ISUP.

ISUP -> SIP working is easy as ISUP will only contain one value but if
SIP contains multiple values as Paul has suggested then we need to be
able to map these to a single value in ISUP.

Ian Elz

System Manager
DUCI LDC UK
(Lucid Duck)

Office: + 44 24 764 35256
gsm: +44 7801723668
ian.elz <at> ericsson.com

-----Original Message-----
From: DOLLY, MARTIN C, ATTLABS [mailto:mdolly <at> att.com]
Sent: 01 April 2008 13:16
To: Ian Elz; iptel <at> ietf.org; sipping <at> ietf.org
Subject: RE: [Sipping] draft-mahy-iptel-cpc

Ian,

CPC: Information sent in the forward direction indicating the category
of the calling party and, in case of semiautomatic calls, the service
language to be spoken by the incoming, delay and assistance operators.
The format of the calling party's category is shown below.

OLI:  Information sent in the forward direction indicating toll class of
service. Identification of the originating line.

Martin

-----Original Message-----
From: Ian Elz [mailto:ian.elz <at> ericsson.com]
Sent: Tuesday, April 01, 2008 4:58 AM
To: Paul Kyzivat
Cc: iptel <at> ietf.org; DOLLY, MARTIN C, ATTLABS; sipping <at> ietf.org
Subject: RE: [Sipping] draft-mahy-iptel-cpc

Paul,

My comments are made based upon the content of the latest draft (06).

The introduction begins:

   "SS7 ISUP [4] defines a Calling Party's Category (CPC) parameter that
   characterizes the station used to originate a call and carries other
   important state that can describe the originating party.  When
   telephone numbers are contained in URIs, such as the tel URI [2], it
   may be desirable to communicate any CPC associated with that
   telephone number or, in the context of a call, the party calling from
   it."

Based upon this the current requirement appears to be to support the
ISUP CPC/OLI.

If the requirement is greater than this then that is a discussion that
we should have before the draft is finalized.

The issue with mutual exclusivity exists in the current ISUP
implementations. If that limitation is to be overcome then that
requirement also needs to be discussed. If we are to move from mutual
exclusivity of values then we need to ensure that interworking back to
ISUP is supported. The resolution of the overlapping cases as you have
indicated may have to be at the discretion of the network operator.

Ian Elz

_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP Use
sip-implementors <at> cs.columbia.edu for questions on current sip Use
sip <at> ietf.org for new developments of core SIP
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sip <at> ietf.org for new developments of core SIP
Permalink | Reply | 4 comments |

Gmane