[Serusers] Modifying "From" header field of an INVITE message

[Mindaugas Kuprys]

Hi,

I'm also working on this issue. I have users registered like 
emailusername at company.com and I want to forward this to pstn gw like 
telNo at company.com. As I understood  this could be done by adding rpid to 
a user one direction and alias other direction. I'm I right?
Could anyone give a link to rpid description?

Alberto Cruz wrote:
> Hi Jan I found this response from you where you explain is possible to 
> modify any header field in SER.
>
> I have exactly the same issue like SCM. My service provider is asking 
> me to send a fixed user part at From URI header for all my calls for 
> billing purpose.
> For example If I have 4 users registered at SER like the following
> user1 at sipserver.mydomain.com
> user2 at sipserver.mydomain.com
> user3 at sipserver.mydomain.com
> user4 at sipserver.mydomain.com
>
> I should translate all the user part before to forward their calls to 
> the Service Provider by the following:
> 2102456787 at sipserver.mydomain.com
>
> Where could I find information related to the command(s)/funcion(s) 
> that make this possible?
>
> If I change the From header, what should I do to keep the original 
> value in order to avoid loosing the call flow? Is it enough with the 
> "Contact:" field?
>
> Regards
>
> Alberto Cruz
> Jan Janak wrote:
>> On 06-02 08:44, John Todd wrote:
>>   
>>> Asterisk Operational Note:
>>>   From Asterisk, try something similar to this:
>>>
>>> exten => _1XXXXXXXXXX.,1,SetCIDNum(+1${CALLERIDNUM})
>>> exten => _1XXXXXXXXXX.,n,Dial(SIP/+${EXTEN}@ser.mydomain.com)
>>>
>>>   This assumes you have ten digit North American caller ID digits, 
>>> and that you need to hand numbers to Level3 like "+13015551212" for 
>>> both ANI and DNIS.
>>>
>>>
>>> SER Development/Usage Note:
>>>   While I agree that changing the "From:" is generally a bad idea, 
>>> there certainly are instances in which is is a desirable thing for a 
>>> SIP proxy to do.  The instance below is a good example.  Other 
>>> examples are when the recommended privacy options are not used, so 
>>> despite privacy settings elsewhere in the headers the "true" Caller 
>>> ID is shown on the remote side.  The only way to avoid this would be 
>>> to not include the origin AOR on the outbound call.  Of course, to 
>>> process replies correctly, it may be necessary to mangle the headers 
>>> in the inverse manner on the way back in... but that level of voodoo 
>>> is left to the administrator.
>>>
>>>   I agree that a b2bua is a way to do this - it may be necessary to 
>>> keep state in that manner.  (specific note: Asterisk _is_ a glorified 
>>> b2bua.)  However, it seems natural that all headers should be subject 
>>> to modification if required within the proxy - not always is it 
>>> required to keep state, as in this case.  Is it truly the case that 
>>> SER does not allow re-formatting of the From: header in any way?
>>>     
>>  
>>   It does require you to keep state -- you have to restore the original
>>   value on the way back, and not just in replies, but in subsequent
>>   mid-dialog requests (BYE, for example) as well.
>>
>>   You can do it statelessly only if you know that no user agent uses the
>>   From/To URI for dialog matching. Suprisingly many implementations do,
>>   Cisco is one well-known example.
>>
>>   Another option would be encoding the original value into the
>>   Record-Route header field generated by SER, that way SER could restore
>>   the original value from the Route header field later. It will be the
>>   user agents in this case who would keep the state.
>>
>>   You can rewrite any header field in SER, even From/To but
>>   expect interoperability problems if you do so statelessly. Unless you 
>>   are sure that all SIP implementations behave exactly as described in 
>>   RFC3261, you need a B2BUA that would keep state during calls.
>>
>>     Jan.
>>
>> _______________________________________________
>> Serusers mailing list
>> serusers at lists.iptel.org
>> http://lists.iptel.org/mailman/listinfo/serusers
>>
>>
>>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> Serusers mailing list
> serusers at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers
>