[SIPForum-discussion] Remote Party ID and p-asserted-identity.

Pranav Damele pranavdamele at gmail.com
Thu Sep 26 04:38:20 UTC 2013


Hi Badri,

Nodes/end points, operating on Draft-01 support, uses RPID header (along
with Proxy-Require header).
However nodes/eps supporting RFC 3325 privacy standard operates with
PPID/PAID headers (along with Privacy header).

SBCs are capable of conversion between draft-01 and RFC 3325 for
ingress/egress end points.

@Pankaj:
Diversion headers are now becoming obsolete and hence they are now mapped
to History-Info headers (RFC 6044)

Regards,

Pranav Damele
Associate Consultant - Engineering, Product Engineering and Development
*Mobile:* +91-9818-92-4466
*Email:* pranavdamele at gmail.com
*IM:* pranavdamele (Skype)
 *http://in.linkedin.com/in/pranavdamele*


On 24 September 2013 15:19, Badri Ranganathan <badri at arcatech.com> wrote:

> Hi all,****
>
> ** **
>
> Is the Remote-party-ID in use still? I have read from the link below that
> this header should not be used and that there are still some trunk
> providers who are using this. Is the P-Asserted-Identity an alternative for
> Remote-Party-ID ? or is there any other alternative. I want to know if the
> same trunk providers will support alternative options for this outdated
> header?****
>
> ** **
>
>
> http://www.voip-info.org/wiki/view/P-Asserted-Identity+and+Remote-Party-ID+header
> ****
>
> ** **
>
> If anyone has worked with SIP trunking providers and know anything in this
> regard, please help. ****
>
> ** **
>
> Thanks,****
>
> Badri.****
>
> ** **
>
> *From:* discussion-bounces at sipforum.org [mailto:
> discussion-bounces at sipforum.org] *On Behalf Of *Vikas Singhal (vsinghal)
> *Sent:* 15 January 2013 04:39
> *To:* pankaj singh; discussion at sipforum.org
> *Subject:* Re: [SIPForum-discussion] Diversion & Remote Party ID****
>
> ** **
>
> Hi Pankaj,****
>
> ** **
>
> Diversion Header and Remote Party id are different headers.****
>
> ** **
>
> Remote Party id:  Identifies a party and is added by the trusted network entities.  ****
>
>    Different types of party information can be provided, e.g., calling, ****
>
>    or called party, and for each type of party, different types of ****
>
>    identity information, e.g. subscriber, or terminal, can be provided. ****
>
>    Since a party may not wish to reveal some or all of this information ****
>
>    to an untrusted entity, the party can request a specific level of ****
>
>    privacy for each. The intermediary also has the ability to specify a ****
>
>    required level of privacy.  ****
>
> ** **
>
> ** **
>
> Diversion header : The Diversion header allows implementation of feature logic****
>
> based on from whom the call was diverted.****
>
> ** **
>
> ** **
>
> Role of “reason” in diversion header to convey why message is diverted
> e.g. user-busy, no-answer etc.****
>
> ** **
>
> It is recommended to include reason in diversion header. But it may work
> without “reason”. Check diversion header RFC :
> http://tools.ietf.org/id/draft-levy-sip-diversion-08.txt.****
>
> ** **
>
> Regards,****
>
> Vikas****
>
> ** **
>
> *From:* discussion-bounces at sipforum.org [
> mailto:discussion-bounces at sipforum.org <discussion-bounces at sipforum.org>]
> *On Behalf Of *pankaj singh
> *Sent:* Sunday, January 13, 2013 11:02 AM
> *To:* discussion at sipforum.org
> *Subject:* [SIPForum-discussion] Diversion & Remote Party ID****
>
> ** **
>
> Hi,****
>
> ** **
>
> I Am wondering, is Diversion and Remote Party ID are Same? In Diversion
> Header what is role of Branch "reason", Can Diversion Header works with-out
> "reason" branch? Need you suggestion here.****
>
> ** **
>
> Thanks,****
>
> ** **
>
> _______________________________________________
> This is the SIP Forum discussion mailing list
> TO UNSUBSCRIBE, or edit your delivery options, please visit
> http://sipforum.org/mailman/listinfo/discussion
> Post to the list at discussion at sipforum.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sipforum.org/pipermail/discussion/attachments/20130926/134968dd/attachment-0002.html>


More information about the discussion mailing list