Hi Ray,
use avp_print() after the load_gw() to see what avps were loaded and
again just before next_gw() to see the available avp.
this will help to see if it's a problem at the load or search part.
regards,
bogdan
Raymond Chen wrote:
>Hi Daniel,
>
>The problem we have is not about next_gw forward to
>userbusy(a)xxx.xxx.xxx.xxx. We have no problem with load_gw, it loads two
>gateways against ruri_user correctly. but when next_gw called, it saids
>
>next_gw(): No ruri_user AVP
>
>looks like ruri_user avp is not saved when load_gw was called. So next_gw
>can't find the ruri_user avp.
>
>Thanks
>
>Ray
>
>
>-----Original Message-----
>From: Daniel-Constantin Mierla [mailto:daniel@voice-system.ro]
>Sent: Tuesday, February 14, 2006 1:44 AM
>To: Raymond Chen
>Cc: Users(a)openser.org
>Subject: Re: [Users] next_gw(): No ruri_user AVP
>
>Hello,
>
>On 02/14/06 13:43, Raymond Chen wrote:
>
>
>>[...]
>> if (!next_gw()) {
>> rewriteuri("sip:userbusy@211.102.91.134:443");
>>
>>
>>
>here you must call append_branch() so the rewriteuri() has the desired
>effect.
>
>Cheers,
>Daniel
>
>
>
>> t_relay();
>> return;
>> };
>>
>> ...........
>>
>>
>>
>>
>>
>
>
>
>
>_______________________________________________
>Users mailing list
>Users(a)openser.org
>http://openser.org/cgi-bin/mailman/listinfo/users
>
>
>
Thanks! But I don't really understand why there is a mismatch between
487and ACK. Below is a part of sip message pair of 487 and ACK.
Below is the complete log from ngrep. (From line 290, openser creates
487 and line 304 UA1 ACK. After that, multiple 487 are created by
openser)
http://meerkat.no-ip.com/openser/cancel_normal.log
Below is my openser.cfg for reference
http://meerkat.no-ip.com/openser/openser.cfg
290 U 203.193.26.226:5060 -> 210.184.23.31:5060
291 SIP/2.0 487 Request Cancelled.
292 Via: SIP/2.0/UDP
10.0.0.46:5060;rport=5060;received=210.184.23.31;branch=z9hG4bKdUyOnG9Zel82UECI.
293 From: "sip:36418488@o01.ol.com"<sip:871966806561@o01.ol.com>;tag=xLTdFs7yGkeXq3wn.
294 To: "34163634" <sip:34163634@o01.ol.com>;tag=A81AFED4-21D7.
295 Date: Tue, 15 Feb 2005 01:52:57 GMT.
296 Call-ID: Z0wcK4WwdTU6mH00(a)10.0.0.46.
297 Server: Cisco-SIPGateway/IOS-12.x.
298 CSeq: 1 INVITE.
299 Allow-Events: telephone-event.
300 Content-Length: 0.
301 .
302
303 #
304 U 210.184.23.31:5060 -> 203.193.26.226:5060
305 ACK sip:34163634@o01.ol.com SIP/2.0.
306 Via: SIP/2.0/UDP 10.0.0.46:5060;branch=z9hG4bKdUyOnG9Zel82UECI.
307 Route: <sip:34163634@203.193.26.226:5060;nat=yes;ftag=xLTdFs7yGkeXq3wn;lr=on>.
308 Max-Forwards: 70.
309 User-Agent: Koncept KE10XX v4.32.10 00-09-45-0a-fc-2d.
310 From: "871966806561" <sip:871966806561@o01.ol.com>;tag=xLTdFs7yGkeXq3wn.
311 To: "34163634" <sip:34163634@o01.ol.com>;tag=A81AFED4-21D7.
312 Call-ID: Z0wcK4WwdTU6mH00(a)10.0.0.46.
313 Contact: <sip:871966806561@10.0.0.46:5060>.
314 CSeq: 1 ACK.
315 Content-Length: 0.
In my openser.cfg line 184-187, it is remarked. Do you mean it should
un-remarked for handling ACK according to your point 2?
On 2/15/06, Klaus Darilion <klaus.mailinglists(a)pernau.at> wrote:
> This means that openser does not receive the ACK or is not able to match
> the ACK to the canceled transaction. Thus it is re-transmitting the 487.
>
> Increas the debug level and take a look at the syslog to find out if:
> 1. the ACK to the 487 is received by openser
> 2. if it is received, check if there is a problem during handling of the
> ACK. (for these kind of ACKs just t_relay()).
>
> klaus
>
> On Wed, February 15, 2006 5:13, unplug said:
> > For the normal cancel situation.
> >
> > UA1 OPENSER UA2
> > --------INVITE----------------->
> > <-----------100-----------------
> > --------------------INVITE---------->
> > <---------------100-------------------
> > ----------CANCEL---------->
> > --------------CANCEL------------->
> > <--------------200------------------
> > <------------487-------------------
> > --------------ACK----------------->
> > <---------487---------------
> > -------------ACK------------>
> >
> > But in my case, I found that there are many 487 created from openser
> > to UA1. The multiple 487 may cause a call drop in the following call.
> > Why does openser create so many 487 for UA1? How can I prevent it?
> >
> > UA1 OPENSER UA2
> > --------INVITE----------------->
> > <-----------100-----------------
> > --------------------INVITE---------->
> > <---------------100-------------------
> > ----------CANCEL---------->
> > --------------CANCEL------------->
> > <--------------200------------------
> > <------------487-------------------
> > --------------ACK----------------->
> > <---------487---------------
> > -------------ACK------------>
> > <---------487-------------
> > -------------ACK------------>
> > <---------487---------------
> > -------------ACK------------>
> > <---------487-------------
> > -------------ACK------------>
> > <---------487-------------
> > -------------ACK------------>
> > <---------487-------------
> > -------------ACK------------>
> > <---------487-------------
> > -------------ACK------------>
> > ...
> >
> > _______________________________________________
> > Users mailing list
> > Users(a)openser.org
> > http://openser.org/cgi-bin/mailman/listinfo/users
> >
>
>
>
Hi ,
that's not correct - you shouldn't route sequential request based on
user location, but based on Route headers. Roughly :
if (is_method("REFER")) {
loose_route();
t_relay();
exit;
}
regards,
bogdan
Frogger wrote:
>Thanks for the quick response,
>
>So basically its as simple as:
>
>if (method=="REFER") {
>
> #routing code here or
>
> if (lookup("location")) {
>
> # or routing code here
>
> }
>
>}
>
>Does that sound right?
>
>
>Rock
>
>
>--- Bogdan-Andrei Iancu <bogdan(a)voice-system.ro>
>wrote:
>
>
>
>>Hi,
>>
>>you need to process the REFER as an within the
>>dialog request - it has
>>to tag so you have to route it based on Route
>>headers (via loose_route).
>>
>>regards,
>>bogdan
>>
>>Frogger wrote:
>>
>>
>>
>>>I have a successful implementation of openser 0.9.5
>>>and its been working very nicely.
>>>
>>>I am faced with transferring of calls from pstn to
>>>userC by way of userB and I am struggling.
>>>
>>>path:
>>>
>>>PSTN=>GW=>SBC=>openser=>uB
>>>
>>>uB transfers call to uC
>>>
>>>Call is failing to transfer as "refer" message is
>>>
>>>
>>not
>>
>>
>>>properly handled by my openser script.
>>>
>>>Any guidance would be appreciated.
>>>
>>>Transfer works when all legs are from registered
>>>clients. Only when the initial call leg is from
>>>
>>>
>>the
>>
>>
>>>PSTN does it not work.
>>>
>>>Thanks, Rock
>>>
>>>
>>>__________________________________________________
>>>Do You Yahoo!?
>>>Tired of spam? Yahoo! Mail has the best spam
>>>
>>>
>>protection around
>>
>>
>>>http://mail.yahoo.com
>>>
>>>_______________________________________________
>>>Users mailing list
>>>Users(a)openser.org
>>>http://openser.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>>>
>>>
>>>
>>
>>
>
>
>__________________________________________________
>Do You Yahoo!?
>Tired of spam? Yahoo! Mail has the best spam protection around
>http://mail.yahoo.com
>
>
This means that openser does not receive the ACK or is not able to match
the ACK to the canceled transaction. Thus it is re-transmitting the 487.
Increas the debug level and take a look at the syslog to find out if: 1.
the ACK to the 487 is received by openser
2. if it is received, check if there is a problem during handling of the
ACK. (for these kind of ACKs just t_relay()).
klaus
On Wed, February 15, 2006 5:13, unplug said:
> For the normal cancel situation.
>
> UA1 OPENSER UA2
> --------INVITE----------------->
> <-----------100-----------------
> --------------------INVITE---------->
> <---------------100-------------------
> ----------CANCEL---------->
> --------------CANCEL------------->
> <--------------200------------------
> <------------487-------------------
> --------------ACK----------------->
> <---------487---------------
> -------------ACK------------>
>
> But in my case, I found that there are many 487 created from openser to
UA1. The multiple 487 may cause a call drop in the following call.
> Why does openser create so many 487 for UA1? How can I prevent it?
>
> UA1 OPENSER UA2
> --------INVITE----------------->
> <-----------100-----------------
> --------------------INVITE---------->
> <---------------100-------------------
> ----------CANCEL---------->
> --------------CANCEL------------->
> <--------------200------------------
> <------------487-------------------
> --------------ACK----------------->
> <---------487---------------
> -------------ACK------------>
> <---------487-------------
> -------------ACK------------>
> <---------487---------------
> -------------ACK------------>
> <---------487-------------
> -------------ACK------------>
> <---------487-------------
> -------------ACK------------>
> <---------487-------------
> -------------ACK------------>
> <---------487-------------
> -------------ACK------------>
> ...
>
> _______________________________________________
> Users mailing list
> Users(a)openser.org
> http://openser.org/cgi-bin/mailman/listinfo/users
>
You also have to make sure that the Content-Length: header will be adopted
when changing the size of the SDP.
regards
klaus
On Tue, February 14, 2006 21:08, S G said:
> Hi,
>
> Can psuedo variables and avpops be enhanced to include the headers in
the SDP message body?
>
> v=0.
> o=2139869454 25762964 25762964 IN IP4 192.168.1.133.
> s=SDP Session For C&S MoIP.
> c=IN IP4 64.xx.xxx.xxx
> t=0 0.
> m=audio 40000 RTP/AVP 4 0 97.
> a=rtpmap:4 G723/8000.
> a=ptime:30.
> a=rtpmap:0 PCMU/8000.
> a=ptime:20.
> a=rtpmap:97 telephone-event/8000.
> m=video 40002 RTP/AVP 34.
> a=rtpmap:34 H263/90000.
>
> Example, what if i wanted to take the local IP of a SIP phone in the
'o=' line and subst it in the 'c=' line for 2 stun enabled clients
residing behind the same NAT? Currently I can sort of do this by
grabbing the local IP off the call-id header in REGISTER and storing it
in the database then regex'ing the IP out of the header with avp_subst.
Though this still does not seem to work even with the output from ngrep
looking proper. What is cuasing this? I dont see why i should have to
store this value in the DB. Subst doenst work multiline so i cant do
this in one textops subst call either.
>
> ## In REGISTER
> ## Save to DB the private IP parsed out of call-id header
avp_write("$hdr[call-id]","i:222");
> avp_subst("i:222", "/.*(a)(.*)$/\1/");
> avp_db_store("$from","i:222");
>
> #In INVITE
> #restore pre-stun IP
> if( !nat_uac_test("8") ) {
> avp_db_load("$from","i:222");
> subst( '/^c=(.*)IP4 (.*)/c=\1IP4 $avp(i:222)\r/' );
> };
>
>
> Thanks,
> Sumeet
>
> _________________________________________________________________ FREE
pop-up blocking with the new MSN Toolbar get it now!
> http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/
>
>
> _______________________________________________
> Devel mailing list
> Devel(a)openser.org
> http://openser.org/cgi-bin/mailman/listinfo/devel
>
Thanks for the reply.
I added setflag(1) statement also but even then "acc" table of ser is empty. I
have mysql 3.23 version, is that creating the problem? I am attaching my
ser.cfg again, please check it and help me know where I am going wrong?
Quoting Ramin NIkaeen <Rnikaeen(a)goldline.net>:
> I think you should have a "setflag(1)" for the accounting to work!
>
> ramin
>
>
> -----Original Message-----
> From: mkumar(a)mantragroup.com [mailto:mkumar@mantragroup.com]
> Sent: Thursday, February 09, 2006 1:07 PM
> To: serusers(a)lists.iptel.org
> Subject: [Serusers] Problem with SER Accounting
>
> Hi All,
>
> I was able to install SER and call out successfully. I configured
> ser.cfg after
> seeing some examples in voip-info.org, almost all worked except
> accounting. I
> am using stable ser 0.9.4 version and followed instructions in
> http://www.voip-info.org/tiki-index.php?page=SER+example+accounting.
> When I
> check the database for records related tables are empty. I did not
> install
> radius, is this required to enable accounting? I am attaching my
> ser.cfg,
> please check it and guide me.
>
> Any help will be sincerely appreciated.
>
> Thanks,
> Manoj.
>
Dear Greger V. Teigre,
I've tried t_on_failure("2").
failure_route[2] {
#when caller cancel, terminate the call
if (t_check_status("487")) {
log(1,"cancel received\n");
t_reply("487", "Request Terminated");
break;
}
}
There are similar lines in failure_route[1]. When ua2 is ringing and ua1 cancel the call, the value of "t_check_status("487")" in failure_route[1] will be true. However, When ua3 is ringing and ua1 cancel the call, the value of "t_check_status("487")" in failure_route[2] will be false. This time, t_check_status() returns "408". I don't know why SER generates "408" under this circumstance. My ser's version is 0.9.3 and I just run update_from_cvs. And I found similar description here:
http://bugs.sip-router.org/browse/SER-63
Is it an unsolved problem?
>Do some logging, what happens in the failure route? To me, it looks like
>your config appends a branch. BTW, run update_from_cvs in your SER source
>dir top make sure you get the latest bug fixes!
>g-)
>
>----- Original Message -----
>From: "zhangshuai" <zhangshuai(a)goldentek.biz>
>To: "serusers" <serusers(a)lists.iptel.org>
>Cc: "wuyuan" <wuyuan(a)goldentek.biz>
>Sent: Tuesday, February 14, 2006 3:49 AM
>Subject: Re: Re: [Serusers] a question about "cancel" in forwarding scenario
>
>
>> Dear Greger V. Teigre,
>>
>>
>>
>> Thanks for your quick reply.
>>
>> I have read the sergettingstarted05.pdf (Based upon SER version 0.9.3) and
>> tested the onr.cfg in
>> ser-0.9.3.GettingStarted.1.3.tar.gz/ser-0.9.3/examples many times. SER
>> sent out "408" to caller immediately after received "486" from ua3. I
>> don't know how does ser's failure route deal with this kind of "cancel"
>> when the invite has been forwarded. Any ideas will help me a lot. Thanks!
>>
>> Here is the onr.cfg:
>>
>> # ------------------ module loading ----------------------------------
>> loadmodule "/usr/local/lib/ser/modules/sl.so"
>> loadmodule "/usr/local/lib/ser/modules/tm.so"
>> # ----------------- setting module-specific parameters ---------------
>>
>> # -- tm params --
>> # set time for which ser will be waiting for a final response;
>> # fr_inv_timer sets value for INVITE transactions, fr_timer
>> # for all others
>> modparam("tm", "fr_inv_timer", 15 )
>> modparam("tm", "fr_timer", 10 )
>>
>> # ------------------------- request routing logic -------------------
>>
>> # main routing logic
>>
>> route{
>> # for testing purposes, simply okay all REGISTERs
>> if (method=="REGISTER") {
>> log("REGISTER");
>> sl_send_reply("200", "ok");
>> break;
>> };
>> # try these two destinations first in parallel; the second
>> # destination is targeted to sink port -- that will make ser
>> # wait until timer hits
>> seturi("sip:200@218.97.252.35:5060");
>> #append_branch("sip:300@218.97.252.36:5060");
>> # if we do not get a positive reply, continue at reply_route[1]
>> t_on_failure("1");
>> # forward the request to all destinations in destination set now
>> t_relay();
>> }
>>
>> failure_route[1] {
>> #when caller cancel, terminate the call
>> if (t_check_status("487")) {
>> t_reply("487", "Request Terminated");
>> break;
>> };
>> # forwarding failed -- try again at another destination
>> append_branch("sip:300@218.97.252.44:5060");
>> log(1,"first redirection\n");
>> # if this alternative destination fails too, proceed to
>> reply_route[2]
>> #t_on_failure("2");
>> t_relay();
>> }
>>
>>
>> Thanks in advance.
>>
>> Have a good day!
>>
>>
>>
>> Shuai
>>
>>
>>>The internal SER timer hits and the request times out (the request is not
>>>terminated).
>>>See SER-GettingStarted doc at ONsip.org for a full example of call
>>>features
>>>like forwarding.
>>>g-)
>>>----- Original Message -----
>>>From: "zhangshuai" <zhangshuai(a)goldentek.biz>
>>>To: "serusers" <serusers(a)lists.iptel.org>
>>>Cc: "wuyuan" <wuyuan(a)goldentek.biz>
>>>Sent: Friday, February 10, 2006 11:18 AM
>>>Subject: [Serusers] a question about "cancel" in forwarding scenario
>>>
>>>
>>>> Dear All,
>>>>
>>>>
>>>> I want to make use of avpops module to achieve forward on-no-reply. When
>>>> ua1 calls ua2 and ua2 is off-line, or busy, or doesn't answer the phone,
>>>> the invite should be forwarded to ua3 and ua3 begins ringing.
>>>>
>>>> In my tests, first, ua1 sends "cancel" when ua2 is ringing. Ua1 receives
>>>> "487 Request Terminated" from SER. Second, ua1 sends "cancel" when ua3
>>>> is
>>>> ringing. So, theoretically, ua1 should receive "487 Request Terminated"
>>>> after "200 canceling" from SER, right? But, ua1 received "408 Request
>>>> Timeout" instead. So strange. How come?
>>>>
>>>> I think something is wrong with my ser.cfg. Could anyone help me about
>>>> this? Thanks in advance.
>>>>
>>>> Here is my ser.cfg:
>>>>
>>>> # ------------------ module loading ----------------------------------
>>>>
>>>> loadmodule "/usr/local/lib/ser/modules/sl.so"
>>>> loadmodule "/usr/local/lib/ser/modules/tm.so"
>>>> loadmodule "/usr/local/lib/ser/modules/rr.so"
>>>> loadmodule "/usr/local/lib/ser/modules/maxfwd.so"
>>>> loadmodule "/usr/local/lib/ser/modules/usrloc.so"
>>>> loadmodule "/usr/local/lib/ser/modules/registrar.so"
>>>> loadmodule "/usr/local/lib/ser/modules/textops.so"
>>>> loadmodule "/usr/local/lib/ser/modules/avp.so"
>>>> loadmodule "/usr/local/lib/ser/modules/acc.so"
>>>> loadmodule "/usr/local/lib/ser/modules/mysql.so"
>>>> loadmodule "/usr/local/lib/ser/modules/dbtext.so"
>>>> loadmodule "/usr/local/lib/ser/modules/avpops.so"
>>>> #loadmodule "/usr/local/lib/ser/modules/postgres.so"
>>>> #loadmodule "/usr/local/lib/ser/modules/flatstore.so"
>>>>
>>>> # Uncomment this if you want digest authentication
>>>> # mysql.so must be loaded !
>>>> loadmodule "/usr/local/lib/ser/modules/auth.so"
>>>> #loadmodule "/usr/local/lib/ser/modules/auth_db.so"
>>>>
>>>> loadmodule "/usr/local/lib/ser/modules/auth_radius.so"
>>>> loadmodule "/usr/local/lib/ser/modules/group_radius.so"
>>>> loadmodule "/usr/local/lib/ser/modules/uri_radius.so"
>>>> # ----------------- setting module-specific parameters ---------------
>>>>
>>>> # -- usrloc params --
>>>>
>>>> #modparam("usrloc", "db_mode", 0)
>>>>
>>>> # Uncomment this if you want to use SQL database
>>>> # for persistent storage and comment the previous line
>>>> modparam("usrloc", "db_mode", 1)
>>>>
>>>> # -- auth params --
>>>> # Uncomment if you are using auth module
>>>> #
>>>> #modparam("auth_db", "calculate_ha1", yes)
>>>> #
>>>> # If you set "calculate_ha1" parameter to yes (which true in this
>>>> config),
>>>> # uncomment also the following parameter)
>>>> #
>>>> #modparam("auth_db", "password_column", "password")
>>>>
>>>> # -- rr params --
>>>> # add value to ;lr param to make some broken UAs happy
>>>>
>>>> modparam("rr", "enable_full_lr", 1)
>>>> modparam("tm", "fr_timer", 10 )
>>>> modparam("tm", "fr_inv_timer", 20)
>>>> modparam("tm", "noisy_ctimer", 1)
>>>>
>>>> modparam("auth_radius|uri_radius|group_radius", "radius_config",
>>>> "/usr/local/etc/radiusclient-ng/radiusclient.conf")
>>>>
>>>> modparam("avpops","avp_url","mysql://ser:heslo@localhost/ser")
>>>> modparam("avpops","avp_table","usr_preferences")
>>>> # ------------------------- request routing logic -------------------
>>>>
>>>> # main routing logic
>>>>
>>>> route{
>>>> # initial sanity checks -- messages with
>>>> # max_forwards==0, or excessively long requests
>>>> if (!mf_process_maxfwd_header("10")) {
>>>> sl_send_reply("483","Too Many Hops");
>>>> break;
>>>> };
>>>> if (msg:len >= 2048 ) {
>>>> sl_send_reply("513", "Message too big");
>>>> break;
>>>> };
>>>>
>>>> if (!method=="REGISTER") record_route();
>>>>
>>>> if (loose_route()) {
>>>> t_relay();
>>>> break;
>>>> };
>>>>
>>>> if (method=="INVITE") {
>>>> lookup("location");
>>>> #if (!lookup("location")) {
>>>> # sl_send_reply("404", "Not Found");
>>>> # break;
>>>> #};
>>>> }
>>>>
>>>> if (method=="REGISTER") {
>>>> log("REGISTER\n");
>>>> if (!radius_www_authorize("localhost.localdomain")) {
>>>> www_challenge("localhost.localdomain", "0");
>>>> break;
>>>> };
>>>> save("location");
>>>> break;
>>>> };
>>>>
>>>> if (method=="INVITE") {
>>>> if (!radius_proxy_authorize("localhost.localdomain")) {
>>>> proxy_challenge("localhost.localdomain", "1");
>>>> break;
>>>> };
>>>> }
>>>>
>>>> # if we do not get a positive reply, continue at failure_route[1]
>>>> t_on_failure("1");
>>>> # forward the request to all destinations in destination set now
>>>> t_relay();
>>>>
>>>> #if (!t_relay()) {
>>>> # sl_reply_error();
>>>> #};
>>>> }
>>>>
>>>> failure_route[1] {
>>>>
>>>> #when caller cancel, terminate the call
>>>> if (t_check_status("487")) {
>>>> t_reply("487", "Request Terminated");
>>>> break;
>>>> };
>>>>
>>>> if ( ( avp_db_load("$ruri","s:redirect_on_failure") &&
>>>> avp_check("redirect_on_failure","eq/i:1"))) {
>>>> # User need to forward
>>>> log(1, "User wants redirection.\n");
>>>> if ( ( avp_db_load("$ruri","s:redirectnumber") &&
>>>> !avp_check("redirectnumber","re/^$"))) {
>>>> log(1,"first redirect\n");
>>>> #avp_print();
>>>> attr2uri("redirect number");
>>>> lookup("location");
>>>> append_branch();
>>>> #t_on_failure("2");
>>>> t_relay();
>>>> }
>>>> else {
>>>> t_reply("408", "TimeOut");
>>>> break;
>>>> };
>>>> }
>>>> else {
>>>> t_reply("404", "Not Found");
>>>> break;
>>>> };
>>>> }
>>>>
>>>>
>>>> _______________________________________________
>>>> Serusers mailing list
>>>> serusers(a)lists.iptel.org
>>>> http://lists.iptel.org/mailman/listinfo/serusers
>>>>
>>>
>>>
>>
>> = = = = = = = = = = = = = = = = = = = =
>>
>>
>>
>>
>>
>> _______________________________________________
>> Serusers mailing list
>> serusers(a)lists.iptel.org
>> http://lists.iptel.org/mailman/listinfo/serusers
>>
>
>
= = = = = = = = = = = = = = = = = = = =
Hello,
On 02/14/06 13:43, Raymond Chen wrote:
> [...]
> if (!next_gw()) {
> rewriteuri("sip:userbusy@211.102.91.134:443");
>
here you must call append_branch() so the rewriteuri() has the desired
effect.
Cheers,
Daniel
> t_relay();
> return;
> };
>
> ...........
>
>
>
