Interesting question


This one is for 1.8 asterisk, … forwarding

When the calls are forwarded using database CFIM method, the RPID is not proper as I am getting ,

Remote-Party-ID: “919322273640” sip:%2B919322273640@

I dont know from where “%2B” this comes from and i need this to be stripped and asterisk to be sending just

Remote-Party-ID: “919322273640” sip:919322273640@

how this could be possible ?

Also I would like to change the from header From: “asterisk” sip:1000112@ to
From: “919322273640” sip:1000112@


%2B is correct for international format numbers; it is the URL encoding of +

If you don’t want the + substring it out. If you want a literal +, you are trying to violate the protocol.

I’m not sure if you can change the From header when not using it for CLID, although I know that some service providers are abusing it to provider remote party IDs.

Can we just put + instead of %2B , how it should be done.

Like Remote-Party-ID: “919322273640” sip:+919322273640@

Firstly report it as a bug to your service provider. They should be interpreting a bare + as a space, not as an international number prefix.

With the current version of Asterisk, I believe you may have to patch the source code to introduce this protocol violation. Earlier versions had a strict and non-strict SIP mode. You might just find they have retained the option, but reversed the default, so that it now defaults to the correct behaviour.

how can i convert the sip uri from

From: “1919323043570” sip:+1919323043570@


From: “1919323043570” sip:1919323043570@ without +

I tried Set(CALLERID(num)=${CALLERID(num):1}@ but it is not working .

any other way ?


CALLERID() never contains the domain part or the @.

but is there any way to change sip:+1919323043570@
and remove + sign ?

Try this:


by using Set(CALLERID(num)=${CALLERID(num):1})

this is not getting effected


I think we need the relavant parts of your dialplan, sip configuration and a verbose console trace, to find out what is going on.

I manage to strip + , but why asterisk donot use e.164 format , the same used to work on asterisk without striping + on 1.4 asterisk ?


As I commented early in this thread, the bug appears to be with your service provider. Asterisk used not (by default at least) to send valid SIP URLs. It now is (by default at least) sending them. The service provider appears to be unable to parse valid SIP URLs - maybe they are using an older version of Asterisk?


I have this below below parameters from the provider, ->
INVITE sip:+16468xxxxxx@;transport=udp SIP/2.0…Record-Route: sip:;lr;ftag=gK0856c835…Record-Route: sip:;lr=on;ftag=gK0856c835…Via: SIP/2.0/UDP;branch=z9hG4bK65f3.4b5121
16.0…Via: SIP/2.0/UDP;branch=z9hG4bK65f3.341b4806.0…Via: SIP/2.0/UDP;branch=z9hG4bK08B71492aa839fd9036…From: sip:+912267287006@;tag=gK0856c835…To: sip:+16468xxxxxx@…Cal
l-ID: 1325950504_47189420@…CSeq: 5675 INVITE…Max-Forwards: 54…Contact: sip:+912267287006@…Content-Length: 328…Content-Disposition: session; handling=required…Content-Type: application/sdp…Rem
ote-Party-ID: sip:+912267287006@;privacy=off…P-Asserted-Identity: sip:+912267287006@…v=0…o=Sonus_UAC 7600 17488 IN IP4…s=SIP Media Capabilities…c=IN IP4…t=
0 0…m=audio 15354 RTP/AVP 0 18 96 101…a=rtpmap:0 PCMU/8000…a=rtpmap:18 G729/8000…a=fmtp:18 annexb=no…a=rtpmap:96 iLBC/8000…a=fmtp:96 mode=30…a=rtpmap:101 telephone-event/8000…a=fmtp:101 0-15…a=sendrecv…a=maxptime:30…

With the same parameters the 1.4 asterisk passes the CLI but not the 1.8 asterisk, if this parameters are in E.164 standards then it has to be passed right ?