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

Jan Janak jan at iptel.org
Mon Feb 7 12:30:21 CET 2005


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.




More information about the sr-users mailing list