Re: [Iptel] How To Give Suggestions

[Gautam Yadav <[e-mail]>]

Hi Vijay,

thanks for your response. Please allow me to try one more time to explain my
point with help of an example. I have attached a call flow for your
reference.

"A" party is the subscriber of Switch-1 and has taken a service called
"Caller Identity Delivery Supression" (CIDS). "B" party is the subscriber of
Switch-2. Switch-1 and Switch-2 are connected through SIP trunk. Also we
need to transport the trunk group parameters in the contact header of the
INVITE message when A places the call to B. This is how the INVITE from
Switch-1 to Switch-2 looks like:


INVITE sip:5746064748@192.168.10.10:5060;user=phone SIP/2.0

Via: SIP/2.0/UDP  192.168.10.20:5060;branch=z9hG4bK_1103250270916482186

From: "Anonymous"<sip:[e-mail]
>;tag=1_1103_f25027_yt52_CtkM381990

To: <sip:[e-mail];user=phone>

Call-ID: 0793308353@192.168.10.20

CSeq: 1       INVITE

Max-Forwards: 70

Supported: 100rel,timer,replaces,unknown

*Contact: <sip:Anonymous;tgrp=1000;trunk- context=context-1;transport=udp> *

Allow:
INVITE,ACK,BYE,CANCEL,OPTIONS,REGISTER,INFO,PRACK,SUBSCRIBE,NOTIFY,REFER,UPDATE

Min-SE: 900

Session-Expires: 1800;refresher=uac

Privacy: id

Content-Length:    246

Content-Type: application/sdp

The Switch-1 has constructed this INVITE message by refering to RFC 4904 for
encoding trunk group parameters and RFC 3323 for hiding the A
party's (Caller's) identity and ecnoded the "Anonymous" in the contact
header.

Now, on receiving this INVITE the Switch-2 is rejecting the call because it
is saying that it expects a tel URI in the contact header if it contains the
tgrp parameters as mentioned in RFC 4904. Switch-2 guys are also saying that
any locally generated number at Switch-1 can be placed in contact header if
the Caller's identity is to be hidden so that they can convert It into a tel
uri.

Now the problem is that both the switches are from different vendors and
they have there respective arguments. Switch-1 guys are saying since RFC
3323 says that you can use "Anonymous" in case caller id is to be hidden
which makes it a SIP uri and Switch-2 guys are saying that since tgrp
parameters are present in contact header they expect a tel uri in it.
Switch-2 guys are basing there argument on the fact that RFC 4904 says
that tgrp parameters must be in tel uri. RFC 4904 tallks about tel uri
because it talks about the SS7 trunks. But I am talking about SIP trunks in
my case. That's why I had said that is it possible to include SIP trunks in
rfc 4904 and allow the use of SIP uri along with tgrp parameters.

Thanks,
Gautam



On Mon, Aug 8, 2011 at 7:10 PM, Vijay K. Gurbani <[e-mail]> wrote:

> Please see inline.
>
>
> On 08/08/2011 07:26 AM, Gautam Yadav wrote:
>
>> Hi Vijay, Cullen,
>>
>> Sorry for the delayed response as I was busy with some other activities.
>> My suggestion is with regards to the rfc 4904 and it comes from on of
>> the inter-operational that I faced. I am starting by quoting the aim of
>> the rfc 4904 to begin with followed by problem statement and suggestion.
>>  From Section 2:
>>
>> The aim of this specification is to outline how to structure and
>>
>> represent the trunk group parameters as an extension to the tel URI
>>
>> [4] in a standardized manner.
>>
>> My Understanding: I believe the rfc 4904 talks about the extension to
>> the tel URI only because it specifically talks about the
>> inter-operational issues for the scenarios where SIP to SS7 gateways
>> come into picture.
>>
>> Problem Statement: We have the call scenario of MGCP to MGCP call where
>> A and B parties are on different soft-switches. Topology: A àSwitch-1
>> --- SIP Trunk --àSwitch-2 --àB. We need to transport the trunk group
>>
>> parameters in the Contact Header and called ID needs to be hidden
>> because of the privacy concerns. Our contact header looks like: Contact:
>> SIP:Anonymous;tgrp=1000;trunk-**context=context-1@192.168.10.**20<context-1@192.168.10.20>
>> <sip:Anonymous;tgrp=1000;**trunk-context=context-1@192.**168.10.20<context-1@192.168.10.20>>.
>> We are
>>
>> facing an inter-operational issue because of this contact header.
>> Switch-1 is referring to the rfc 3323 and encoding “Anonymous” but the
>> switch-2 is referring the rfc 4904 and expects tel URI and “557” in its
>> user part.
>>
>
> As far as I can tell, you appear to be having the problem because
> Switch-1 is encoding an anonymous identifier whereas Switch-2 is
> expecting an identity of some sort (probably a telephone extension)
> in the Contact header.
>
>
> My Suggestion/Query: Is it possible to increase the scope of the rfc
>> 4904 and consider the SIP trunks also and not just the SS7 trunks and by
>> implication allow the SIP URI also and not just tel URI.
>>
>
> I can't see how increasing the scope of rfc4904 will help you here.
> You need to impart the identity to Switch-2 by some means, if that is
> what it wants.  Doing so will be outside the scope of rfc4904.
>
> That said, there are ways around this but at the philosophical level,
> if the sender has decided to stay anonymous and you can still correlate
> that sender to a specific identity, then the assumed anonymity of the
> system is not of much help.
>
> You could be wanting to anonymise the caller ID during transit only, and
> not to provide a complete anonymity service.  If that is the case, then
> you could correlate the identity at Switch-2, but again, doing so is
> outside the scope of rfc4904 as far as I can see it.
>
> Thanks,
>
>
> - vijay
> --
> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
> 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
> Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.**com<[e-mail]>
> Web:   http://ect.bell-labs.com/who/**vkg/<http://ect.bell-labs.com/who/vkg/>
>