FreeSWITCH

Replace the userpart within the sofia_contact() api function

Details

  • Type: New Feature New Feature
  • Status: Closed Closed
  • Priority: Patch Patch
  • Resolution: Incomplete
  • Affects Version/s: None
  • Fix Version/s: 1.3.0
  • Component/s: mod_sofia
  • Labels:
    None
  • Platform:
    Linux x86/gcc
  • FreeSWITCH GIT Revision:
    HEAD, Fri Nov 5 20:24:31 2010
  • Reproduced with GIT HEAD?:
    yes

Description

setup:
<action application="set" data="sip_replace_userpart=222"/>
<action application="bridge" data="${sofia_contact(internal/100@sys.local)}" />


The patch does do the following:

The sofia_contact function will search for a user 100 but will replace the 100 with the value of the variable sip_replace_userpart = 222. This is useful if you have trunk registration on FS and you want to make a outgoing call with the same parameter as the trunk registration (IP, Port, ...) but with a different userpart.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Anthony Minessale II added a comment -
Have you seen the existing:

<action application="bridge" data="${sofia_contact(internal/100@sys.local)}^222" />
and
<action application="bridge" data="{sip_route_uri=222}${sofia_contact(internal/100@sys.local)}" />
 
Show
Anthony Minessale II added a comment - Have you seen the existing: <action application="bridge" data="${sofia_contact(internal/100@sys.local)}^222" /> and <action application="bridge" data="{sip_route_uri=222}${sofia_contact(internal/100@sys.local)}" />  
Hide
Permalink
Bernhard Suttner added a comment -
This will replace the ROUTE URI but not the FROM User Part.

What should the ^222 should do?
Show
Bernhard Suttner added a comment - This will replace the ROUTE URI but not the FROM User Part. What should the ^222 should do?
Hide
Permalink
Anthony Minessale II added a comment -
^222 is equivalent to form an request uri to somewhere different.
{sip_from_user=222}

if you really want to change the sip from user.
Show
Anthony Minessale II added a comment - ^222 is equivalent to form an request uri to somewhere different. {sip_from_user=222} if you really want to change the sip from user.
Hide
Permalink
Bernhard Suttner added a comment -

I tried to set it with ^222 and sip_route_uri. I made a mistake within my explanation. sofia_contact with replace_userpart does replace the sip-to-user part and not something on the from number.

sofia_contact with replace_userpart will generate the following invite:

08:45:05.444586 IP 10.10.10.21.5060 > 10.10.10.30.5060: SIP, length: 1180
E.......@.....P...P.........INVITE sip:222@10.10.10.40 SIP/2.0
Via: SIP/2.0/UDP 172.19.80.169;rport;branch=z9hG4bKjrv85F9e8F0ve
Route: <sip:10.10.10.30;lr>
Max-Forwards: 67
From: "400" <sip:400@10.10.10.21>;tag=F8FpNS1pXQj5p
To: <sip:222@10.10.10.40>
Call-ID: 1be1dbc0-6678-122e-ffb6-0800278fbc7b
CSeq: 4308288 INVITE
Contact: <sip:mod_sofia@10.10.10.21:5060>
User-Agent: FreeSWITCH-mod_sofia/1.0.head-git-
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
Supported: timer, precondition, path, replaces
Allow-Events: talk, hold, presence, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 205
X-To-Trunk: true
X-FS-Support: update_display
Remote-Party-ID: "400" <sip:400@10.10.10.21>;party=calling;screen=yes;privacy=off

v=0
o=FreeSWITCH 1289270558 1289270559 IN IP4 10.10.10.21
s=FreeSWITCH
c=IN IP4 10.10.10.21
t=0 0
m=audio 20538 RTP/AVP 0 8 101 13
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20

If I try it with sip_route_uri or sip_to_user it will not replace all the required fields.
Show
Bernhard Suttner added a comment - I tried to set it with ^222 and sip_route_uri. I made a mistake within my explanation. sofia_contact with replace_userpart does replace the sip-to-user part and not something on the from number. sofia_contact with replace_userpart will generate the following invite: 08:45:05.444586 IP 10.10.10.21.5060 > 10.10.10.30.5060: SIP, length: 1180 E.......@.....P...P.........INVITE sip: 222@10.10.10.40 SIP/2.0 Via: SIP/2.0/UDP 172.19.80.169;rport;branch=z9hG4bKjrv85F9e8F0ve Route: <sip:10.10.10.30;lr> Max-Forwards: 67 From: "400" <sip: 400@10.10.10.21 >;tag=F8FpNS1pXQj5p To: <sip: 222@10.10.10.40 > Call-ID: 1be1dbc0-6678-122e-ffb6-0800278fbc7b CSeq: 4308288 INVITE Contact: <sip: mod_sofia@10.10.10.21 :5060> User-Agent: FreeSWITCH-mod_sofia/1.0.head-git- Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE Supported: timer, precondition, path, replaces Allow-Events: talk, hold, presence, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer Content-Type: application/sdp Content-Disposition: session Content-Length: 205 X-To-Trunk: true X-FS-Support: update_display Remote-Party-ID: "400" <sip: 400@10.10.10.21 >;party=calling;screen=yes;privacy=off v=0 o=FreeSWITCH 1289270558 1289270559 IN IP4 10.10.10.21 s=FreeSWITCH c=IN IP4 10.10.10.21 t=0 0 m=audio 20538 RTP/AVP 0 8 101 13 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20 If I try it with sip_route_uri or sip_to_user it will not replace all the required fields.
Hide
Permalink
Bernhard Suttner added a comment -
Could you add this patch to FreeSWITCH? It would be much easier to replace the user part in the SIP-TO within the outgoing SIP INVITE. The patch should not change anything else. I will write the wiki documentation of this feature, of course :-)
Show
Bernhard Suttner added a comment - Could you add this patch to FreeSWITCH? It would be much easier to replace the user part in the SIP-TO within the outgoing SIP INVITE. The patch should not change anything else. I will write the wiki documentation of this feature, of course :-)
Hide
Permalink
Marc Olivier Chouinard added a comment -
I'm really confused on what your really tryign to do.
Show
Marc Olivier Chouinard added a comment - I'm really confused on what your really tryign to do.
Hide
Permalink
Ken Rice added a comment -
Is this really even a problem? The To: field is really supposed to be the original dialed digits anyway... if you are routing off the To: field you are asking for issues anyway.
Show
Ken Rice added a comment - Is this really even a problem? The To: field is really supposed to be the original dialed digits anyway... if you are routing off the To: field you are asking for issues anyway.
Hide
Permalink
Anthony Minessale II added a comment -
Do I understand right that you are trying to do something like the following?

    <extension name="pstn">
      <condition field="destination_number" expression="^(\d+)$">
        <action application="bridge" data="sofia/default/$1${regex(${sofia_contact(regidl@$${domain})}|^[^\@]+(.*)|%1)};transport=udp"/>
        <action application="hangup" data="user_busy"/>
      </condition>
    </extension>



Show
Anthony Minessale II added a comment - Do I understand right that you are trying to do something like the following?     <extension name="pstn">       <condition field="destination_number" expression="^(\d+)$">         <action application="bridge" data="sofia/default/$1${regex(${sofia_contact(regidl@$${domain})}|^[^\@]+(.*)|%1)};transport=udp"/>         <action application="hangup" data="user_busy"/>       </condition>     </extension>
Hide
Permalink
Bernhard Suttner added a comment -
No, the patch does a different thing.

It will replace the user part. In the example above, the sofia contact does look up for the sip user with the number 100. If the user was found, the call to 100 will be made BUT the 100 will be replaced with 222. Therefore the call will be made to 222 but with the same parameter as the user 100 has.

We had the scenario:
- Asterisk A has a trunk registration (with 100@asteriskip) on FS
- FS does "know" that there are many different users on Asterisk A like the user 222.
- If someone tries to call 222 FS does first lookup the trunk registration (100@asteriskip).
- After that, the 100 will be replaced with 222. Therefore the call will be made to 222@asteriskip
Show
Bernhard Suttner added a comment - No, the patch does a different thing. It will replace the user part. In the example above, the sofia contact does look up for the sip user with the number 100. If the user was found, the call to 100 will be made BUT the 100 will be replaced with 222. Therefore the call will be made to 222 but with the same parameter as the user 100 has. We had the scenario: - Asterisk A has a trunk registration (with 100@asteriskip ) on FS - FS does "know" that there are many different users on Asterisk A like the user 222. - If someone tries to call 222 FS does first lookup the trunk registration ( 100@asteriskip ). - After that, the 100 will be replaced with 222. Therefore the call will be made to 222@asteriskip
Hide
Permalink
Ken Rice added a comment -
how is this different then the above example, you just described what Tony asked in his 10/Apr/12 6:31 post. in his example this is the same thing as doing a dial(sip/100/222) in asterisk where 100 is the registered user and 222 is the user part of the destination you want to send...
Show
Ken Rice added a comment - how is this different then the above example, you just described what Tony asked in his 10/Apr/12 6:31 post. in his example this is the same thing as doing a dial(sip/100/222) in asterisk where 100 is the registered user and 222 is the user part of the destination you want to send...
Hide
Permalink
Anthony Minessale II added a comment -
The reason I ask is that I agree we could do something to solve it but I would like to make sure we are talking about the same problem first.
Show
Anthony Minessale II added a comment - The reason I ask is that I agree we could do something to solve it but I would like to make sure we are talking about the same problem first.
Hide
Permalink
Bernhard Suttner added a comment -
Does sip/100/XXX call XXX over the incoming registration from 100? I thought, that sip/100/XXX would mean, that the number XXX is called over the profile 100.

In my example, the call will be made over a incoming registration from the e.g. asterisk to FS. So, with the attached patch to sofia_contact it would be possible to have one single registration from asterisk and handle many "known" number from FS over this registration to Asterisk. If this is possible with the regexp, I'm happy, too (but I could not test it because I don't have the test environment).
Show
Bernhard Suttner added a comment - Does sip/100/XXX call XXX over the incoming registration from 100? I thought, that sip/100/XXX would mean, that the number XXX is called over the profile 100. In my example, the call will be made over a incoming registration from the e.g. asterisk to FS. So, with the attached patch to sofia_contact it would be possible to have one single registration from asterisk and handle many "known" number from FS over this registration to Asterisk. If this is possible with the regexp, I'm happy, too (but I could not test it because I don't have the test environment).
Hide
Permalink
Peter Olsson added a comment -
Shouldn't sip_invite_to_uri work in this case, I have a few registrations like that. Looking into my dialplan it looks like this;

<action application="bridge" data="{sip_invite_to_uri=<sip:to_number@${domain_name}>}user/reged_user@${domain_name}"/>

More information here: http://wiki.freeswitch.org/wiki/Variable_sip_invite_to_uri.

It also mentions Tony's trick with ^1234.

I might understand this wrong, but from the descriptions this seems to be the case.

/Peter
Show
Peter Olsson added a comment - Shouldn't sip_invite_to_uri work in this case, I have a few registrations like that. Looking into my dialplan it looks like this; <action application="bridge" data="{sip_invite_to_uri=<sip:to_number@${domain_name}>}user/reged_user@${domain_name}"/> More information here: http://wiki.freeswitch.org/wiki/Variable_sip_invite_to_uri . It also mentions Tony's trick with ^1234. I might understand this wrong, but from the descriptions this seems to be the case. /Peter
Hide
Permalink
Bernhard Suttner added a comment -
@ Peter: This will work maybe, but all the parameters, which are maybe necessary are thrown away (like the transport parameter or other required parameters which are saved to the contact).
Show
Bernhard Suttner added a comment - @ Peter: This will work maybe, but all the parameters, which are maybe necessary are thrown away (like the transport parameter or other required parameters which are saved to the contact).
Hide
Permalink
Peter Olsson added a comment -
According to te wiki, ^222 should do just that, change the user part only, and change nothing else.
Show
Peter Olsson added a comment - According to te wiki, ^222 should do just that, change the user part only, and change nothing else.
Hide
Permalink
Ken Rice added a comment -
bernhard can you join us on IRC at some point to discuss this issue?
Show
Ken Rice added a comment - bernhard can you join us on IRC at some point to discuss this issue?
Hide
Permalink
Mike Jerris added a comment -
from the notes it does look like ^xxx syntax does what you need. If this is not the case, please re-open with answers to the outstanding questions. Thanks
Show
Mike Jerris added a comment - from the notes it does look like ^xxx syntax does what you need. If this is not the case, please re-open with answers to the outstanding questions. Thanks
Mike Jerris made changes -
Field Original Value New Value
Status Open [ 1 ] Closed [ 6 ]
Resolution Incomplete [ 4 ]
Mike Jerris made changes -
Fix Version/s 1.3.0 [ 10003 ]

People

  • Assignee:
    Anthony Minessale II
    Reporter:
    Bernhard Suttner
Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: