4 May
2006
4 May
'06
11:51 a.m.
Hi,
I'm also working on this issue. I have users registered like
emailusername(a)company.com and I want to forward this to pstn gw like
telNo(a)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(a)sipserver.mydomain.com
user2(a)sipserver.mydomain.com
user3(a)sipserver.mydomain.com
user4(a)sipserver.mydomain.com
I should translate all the user part before to forward their calls to
the Service Provider by the following:
2102456787(a)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:
------------------------------------------------------------------------
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
Asterisk Operational Note:
From Asterisk, try something similar to this:
exten => _1XXXXXXXXXX.,1,SetCIDNum(+1${CALLERIDNUM})
exten => _1XXXXXXXXXX.,n,Dial(SIP/+${EXTEN}(a)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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers