See minutes/slides from IETF 72 concerning parameter delivery: 
http://tools.ietf.org/wg/sip/minutes

Christer and Jonathan had separate proposals for IETF 71; however a new 
parameter for History-Info was the chosen solution as of IETF 72.
 

> -----Original Message-----
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On 
> Behalf Of Iñaki Baz Castillo
> Sent: Thursday, August 28, 2008 4:30 PM
> To: [email protected]
> Subject: [Sip-implementors] Something as "P-E.164" header?
> 
> Hi, I wonder if there is some standarized header/parameter to 
> get the behaviour I tell now:
> 
> Imagine a SIP user  sip:[EMAIL PROTECTED]  registers 
> itselfto a proxy that routes him calls from a PSTN gateway 
> and others proxies.
> 
> sip:[EMAIL PROTECTED] has assigned two PSTN numbers:
>   +111111
>   +222222
> 
> sip:[EMAIL PROTECTED] registers the address:
>   sip:[EMAIL PROTECTED]:5060
> 
> When the proxy receives a call from the PSTN gateway for 
> +111111 it will generate an INVITE as:
>   INVITE sip:[EMAIL PROTECTED]:5060 SIP/2.0
>   From: <tel:+10003345>
>   To: <+tel:+111111>
> 
> So bob phone can know the PSTN dialed number by examining the 
> To header.
> 
> But imagine that the proxy receives an INVITE from other 
> proxy with peering relationship, and this INVITE was diverted 
> by the original destination
> (+333333) to +111111.
> This is, the INVITE arriving to bob phone will be:
>   INVITE sip:[EMAIL PROTECTED]:5060 SIP/2.0
>   From: <sip:[EMAIL PROTECTED]>
>   To: <+tel:+333333>
>   P-Asserted-Identity: <tel:+92390923>
> 
> So in this case bob has no way to know that the real PSTN 
> destination was 
> +111111.
> 
> 
> Well, I solve this issue by adding a custom header "P-E.164" 
> added by the proxy responsible of "bob", so the above INVITE would be:
>   INVITE sip:[EMAIL PROTECTED]:5060 SIP/2.0
>   From: <sip:[EMAIL PROTECTED]>
>   To: <+tel:+333333>
>   P-Asserted-Identity: <tel:+92390923>
>   P-E.164: <tel:+111111>
> 
> This is, the only SIP node that must add (or replace) this 
> header is the proxy responsible of the final user. In this 
> way, bob will know that a call originally to +333333 was 
> diverted to him number +111111 (not +222222).
> 
> 
> I wonder if it exists a standar way to do this (not very 
> complex please). As you see, in my custom solution the final 
> device just must inspect the header "P-E.164", no more.
> 
> 
> Thanks a lot.
> 
> 
> --
> Iñaki Baz Castillo
> 
> _______________________________________________
> Sip-implementors mailing list
> [email protected]
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
> 

_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Reply via email to