Re: [Iptel] How To Give Suggestions

[Gautam Yadav <[e-mail]>]

Hi Vijay,

Hope your are doing good.

any thoughts on the trailing mail?

Thanks,
Gautam



On Wed, Sep 7, 2011 at 2:43 PM, Gautam Yadav <[e-mail]> wrote:

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