[OpenSIPS-Users] replace_from restore redundant from

kaiser kaiser at gentrice.net
Wed Apr 22 15:00:39 CEST 2009


Bogdan,


For test, I do a simple script, get the same result ( 2 from hdr)


There are several UA register in proxy, 40009,40010,40011,40012 ....
When on-net call fail, serial call start ...
Don't answer first shoot, I answer the 2nd shoot and get 2 from hdr



modparam("uac","from_restore_mode","auto")
       
modparam("tm", "fr_inv_timer", 6)


route { 
           $var(c)=0;
           if (method=="INVITE") {
                                lookup("location");
                                t_on_failure("3");
                                t_relay();
                                exit;
           }

}


failure_route[3]
{
log(1,"******* I'm failure_route[3] *******\n");
       if ($var(c)<5)
        {
              #  append_branch();
           switch($var(c))
         {
            case 0:
                  rewriteuser("40009");
                  break;
            case 1:
                 rewriteuser("40011");
                  break;
            case 2:
                 rewriteuser("40012");
                 break;
            case 3:
                rewriteuser("40013");
            break;
            default:
                log("process other requests here\n");
       }
           $var(c)=$var(c)+1;
                lookup("location");
                append_branch();
                t_on_failure("3");
                route(31);
                t_relay();
                #exit;
        }
}

route[31]
{
       xlog("change from sip:$tU@$fd\n");
        uac_replace_from("sip:9999@$fd"); # A call B, than forking to C, 
C will got B callerid.
}



the incoming  200 ok looks ok

        To: "40010"<sip:40010 at 63.26.2.2>;tag=411c5202
            SIP Display info: "40010"
            SIP to address: sip:40010 at 63.26.2.2
            SIP tag: 411c5202
        From: "kaiser"<sip:9999 at 63.26.2.2>;tag=4894c61e
            SIP Display info: "kaiser"
            SIP from address: sip:9999 at 63.26.2.2
            SIP tag: 4894c61e
        Call-ID: MWJmOTM0MTM4ZjY4NzlkNDEyM2U2NzE0YzIyZjlhNGI.
        CSeq: 1 INVITE
            Sequence Number: 1



reply after restore from:
<replace from works , but additional from is there> 

        To: "40010"<sip:40010 at 63.26.2.2>;tag=411c5202
            SIP Display info: "40010"
            SIP to address: sip:40010 at 63.26.2.2
            SIP tag: 411c5202
        From: "kaiser"<sip:40010 at 63.26.2.2>;tag=4894c61e
            SIP Display info: "kaiser"
            SIP from address: sip:40010 at 63.26.2.2
            SIP tag: 4894c61e
        From: "kaiser"<sip:40010 at 63.26.2.2>;tag=4894c61e
            SIP Display info: "kaiser"
            SIP from address: sip:40010 at 63.26.2.2
            SIP tag: 4894c61e
        Call-ID: MWJmOTM0MTM4ZjY4NzlkNDEyM2U2NzE0YzIyZjlhNGI.
        CSeq: 1 INVITE
            Sequence Number: 1




kaiser



Bogdan-Andrei Iancu 提到:
> Hi Kaiser,
>
> kaiser wrote:
>> Bogdan,
>>
>> We call the uac_replace_from() in failure_route(none in request route),
>> and this failure_route will call itself again if the t_relay() in 
>> failure_route fail again.
> Ok, correct
>>
>> If line 10 t_relay() fail, opensips will raise a failure_route(3) 
>> again to get next serial call target.
>> the new branch will be added for next call (line 6), so the 
>> uac_replace_from will be called again but in different branch.
>> It means line 8 will be run many time, but in different branch
> right - logically speaking is ok - let me try this scenario to see 
> what I get.
>
> Regards,
> Bogdan
>>
>>
>> 1 failure_route[3]
>> 2 {
>> 3 log(1,"******* I'm failure_route[3] *******\n");
>>
>> 4 if (avp_pushto("$ru", "$avp(forward)"))
>> 5 {
>> 6 append_branch();
>> 7 avp_delete("$avp(forward)");
>> 8 uac_replace_from("sip:1234@$fd"); # change from header
>> 9 t_on_failure("3"); # try next , recursive
>>
>> 10 t_relay();
>>
>> 11 }
>>
>> 12 }
>>
>>
>> call flow summary,
>> caller make a call to proxy, proxy try called party 40012, 
>> 40010,10011 in serial if no answer.
>> called party 3 answer the call, and opensips restore from hdr in 200 
>> OK with 2 from header
>>
>>
>> caller to proxy Request: INVITE sip:40012 at 63.26.2.3, with session 
>> description
>> proxy to caller Status: 100 Trying..
>> proxy to caller Status: 180 Ringing
>> *** called party timer out , no answer, proxy cancel the call
>> proxy to called1 Request: CANCEL 
>> sip:40012 at 59.10.208.208:9805;rinstance=c2b3a16f215cf07e
>>
>> *** proxy run to failure route send a new call to a new number with 
>> uac_replace_from
>> proxy to called2 SIP/SDP Request: INVITE sip:40010 at 63.26.2.3, with 
>> session description
>> called2 to proxy SIP Status: 100 Giving a try
>> called2 to proxy SIP Status: 180 Ringing
>>
>> *** called party timer out , no answer, proxy cancel the call
>> proxy to caller Request: CANCEL sip:40010 at 63.26.2.3
>>
>> **** run failure_route again, send the other call to called3 , change 
>> from again
>> proxy to called3 Request: INVITE sip:40011 at 63.26.2.3, with session 
>> description
>> called3 to proxy Status: 180 Ringing
>> proxy to caller SIP Status: 180 Ringing
>>
>> *** called party answer the call , 200 OK return from called party
>> called3 to proxy SIP/SDP Status: 200 OK, with session description
>> proxy to caller SIP/SDP Status: 200 OK, with session description
>>
>>
>> the 200 OK looks like this
>> Status-Line: SIP/2.0 200 OK
>>
>> Via: SIP/2.0/UDP 
>> 63.28.2.7:5060;branch=z9hG4bK58da20a7bfb4a3161fe339136a58343d
>> Record-Route: 
>> <sip:63.26.2.3;lr=on;ftag=3449301004-70991;did=246.22c92a05>
>> From: "k100" <sip:99910009 at 63.28.2.7:5060>;tag=3449301004-70991
>> From: "k100" <sip:99910009 at 63.28.2.7:5060>;tag=3449301004-70991
>> To: <sip:92140011 at 63.28.2.7:5060;transport=udp>;tag=as7b56bdb1
>> Call-ID: 214351-3449301004-70984 at msx1.mydomain.com
>> CSeq: 1 INVITE
>> User-Agent: IPPBX
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Bogdan-Andrei Iancu 提到:
>>> Hi Kaiser,
>>>
>>> you mean you call twice the uac_replace_from() in failure_route for 
>>> the same request? or for different ones?
>>>
>>> because for a request/branch, you must call only once the 
>>> uac_replace_from() function.
>>>
>>> Regards,
>>> Bogdan
>>>
>>> kaiser wrote:
>>>> Bogdan,
>>>>
>>>> After calling twice uac_replace_from() in failure route
>>>>
>>>>
>>>> the 200 OK reply restores the from header as
>>>>
>>>> Status-Line: SIP/2.0 200 OK
>>>>
>>>> Via: SIP/2.0/UDP 
>>>> 63.28.2.7:5060;branch=z9hG4bK58da20a7bfb4a3161fe339136a58343d
>>>> Record-Route: 
>>>> <sip:63.26.2.3;lr=on;ftag=3449301004-70991;did=246.22c92a05>
>>>> From: "k100" <sip:99910009 at 63.28.2.7:5060>;tag=3449301004-70991
>>>> From: "k100" <sip:99910009 at 63.28.2.7:5060>;tag=3449301004-70991
>>>> To: <sip:92140011 at 63.28.2.7:5060;transport=udp>;tag=as7b56bdb1
>>>> Call-ID: 214351-3449301004-70984 at msx1.mydomain.com
>>>> CSeq: 1 INVITE
>>>> User-Agent: IPPBX
>>>>
>>>>
>>>> There are 2 FROM hd in this message which from hdr restored.
>>>>
>>>> I try to find a way to output a trace in a compact format, it's 
>>>> long...
>>>>
>>>> best regards
>>>> kaiser
>>>>
>>>>
>>>> Bogdan-Andrei Iancu 提到:
>>>>> Hi Kaiser,
>>>>>
>>>>> kaiser wrote:
>>>>>> Bogdan,
>>>>>>
>>>>>> We have tested several ways:
>>>>>>
>>>>>> 1. use uac_replace_from in failure route only:
>>>>>> this make redundant "from" header in reply 200 OK.
>>>>> so you use it only in failure_route, this should be ok - what do 
>>>>> you mean by redundant FROM hdr? can you post a trace ?
>>>>>>
>>>>>> 2. use uac_replace_from in request route and failure route:
>>>>>> It makes outgoping INVITE with strange from header.
>>>>> yes, this is is not correct. When doing uac_replace_from from 
>>>>> request route, you do the change for all future branches.
>>>>>
>>>>> Regards,
>>>>> Bogdan
>>>>>>
>>>>>> br
>>>>>> kk
>>>>>>
>>>>>>
>>>>>> Bogdan-Andrei Iancu 提到:
>>>>>>> Hi KK,
>>>>>>>
>>>>>>> do you do uac_replace_from() in other routes than 
>>>>>>> failure_route() ? like in request route when you process the 
>>>>>>> request for the first time?
>>>>>>>
>>>>>>> Regards,
>>>>>>> Bogdan
>>>>>>>
>>>>>>> Gentrice's kaiser wrote:
>>>>>>>> Dear Sir:
>>>>>>>>
>>>>>>>>
>>>>>>>> I wrote a failure route for serial call mechanism, it help for 
>>>>>>>> no answer call ...
>>>>>>>> but all these serial calls need to have a new CallerID,
>>>>>>>> so I use replace_from for this purpose.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> modparam("uac","from_restore_mode","auto")
>>>>>>>>
>>>>>>>>
>>>>>>>> failure_route[3]
>>>>>>>> {
>>>>>>>> log(1,"******* I'm failure_route[3] *******\n");
>>>>>>>>
>>>>>>>> if (avp_pushto("$ru", "$avp(forward)"))
>>>>>>>> {
>>>>>>>> append_branch();
>>>>>>>> avp_delete("$avp(forward)");
>>>>>>>> uac_replace_from("sip:1234@$fd"); # change from header
>>>>>>>> t_on_failure("3"); # try next , recursive
>>>>>>>>
>>>>>>>> t_relay();
>>>>>>>>
>>>>>>>> }
>>>>>>>>
>>>>>>>> }
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> If only one forward number in AVP array , this code working fine,
>>>>>>>> the issue will happen if multiple forward number trying, ( 
>>>>>>>> forward 2nd,3rd ...number)
>>>>>>>> the UAC module will restore from header in 200 OK of its 
>>>>>>>> following message when a UA answered,
>>>>>>>> we will have a duplicated "from header" in 200 OK (sending out 
>>>>>>>> opensips).
>>>>>>>> It means we will have 2 "from" headers (in 200 OK) to caller, 
>>>>>>>> if 2nd forwarded callee answer.
>>>>>>>>
>>>>>>>> Caller ---> Invite ---> opensips ----> UA 0, no answer
>>>>>>>> ----> UA 1, no answer
>>>>>>>> ---->UA 2, answer
>>>>>>>> <----200 OK
>>>>>>>> <---200OK<---
>>>>>>>>
>>>>>>>> this 200ok will have 2 "from" header.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Most of UA just ignore redundant from header, but some can not.
>>>>>>>> I think it should be UAC modules issue, anyone can help me?
>>>>>>>>
>>>>>>>> best regards
>>>>>>>> KK
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Users mailing list
>>>>>>>> Users at lists.opensips.org
>>>>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>



More information about the Users mailing list