29 jan 2009 kl. 10.02 skrev Iñaki Baz Castillo:

> El Jueves, 29 de Enero de 2009, Klaus Darilion escribió:
>
>> The enterprise has many assigned phone numbers (DIDs) which will be
>> forwarded by the service provider to the contact registered by the  
>> PBX.
>>
>> Problem: How to signal the called phone number? Usually the called  
>> phone
>> number is in the RURI, but the service provider retargets the RURI  
>> with
>> the REGISTER contact, thus this information is lost.
>>
>> We found this workarounds:
>>
>> * To: header: the called number is placed in the to header: Ugly, PBX
>> have to route based on To header, .....
>
> Never, the TO header could be the original destination of the call.  
> If a
> diversion occured then the TO still would point to the original  
> target.
> Also the TO can arrive in very exotic ways:
>
>  To: sip:001234...@xxxxx
>  To: sip:+1234...@xxxxx
>  To: sip:1234...@xxxxx
>  To: sip:01234...@xxxxx
>  ...
>
>
>> * RURI: The service provider uses only the host part of the REGISTER
>> contact and puts the phone number into userpart of the RURI when
>> retargeting. Not standard conform, ..... (I think this is was  
>> SIPConnect
>> suggests)
>
> It would break registration from normal phones which expect the same  
> RURI
> username as the user they used in the registration.
>
>
>> * RFC 3455: P-Called-Party-ID
>
> No idea.
>
>
>> * routing instead of retargeting: called number in RURI, REGISTER
>> contact in Route header
>
> I don't like.
>
>
>> Any other workarounds left?
>
> Yes:
>
> a) The PBX could register as many times as DID has assigned, using the
> appropiate DID for each registration.
>
>
> b) The provider could add a custom header containing the AoR for  
> which the
> user location was performed. I wrote sometime ago about it:
>
> https://lists.cs.columbia.edu/pipermail/sip-implementors/2008-August/020215.html
>
> I deployed a small SIP provider with OpenSer using this custom  
> mechanism to
> allow multiple DID per PBX (so the PBX needs to extract the custom  
> header
> value when receiving an INVITE from the SIP provider).

Why a custom header when RPID with party=called already exists?

Your A option would require many changes in many service providers  
networks.

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

Reply via email to