[OpenSIPS-Users] replace_from restore redundant from

Bogdan-Andrei Iancu bogdan at voice-system.ro
Wed Apr 22 14:18:34 CEST 2009


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