[Serusers] Call forwarding Question (following issue 5)

Greger V. Teigre greger at teigre.com
Fri Sep 16 13:07:52 CEST 2005


Hm. The only shot in the blind I can think of without further investigation 
is whether some command in the failure_route requires an authenticated 
INVITE and that the consume_credentials() call has already removed that. 
But I cannot see anything (only quick look).
Could you try removing consume_credentials for INVITEs and see if you still 
have the problem?
I will not be able to repond further until Monday.
g-)

Aisling wrote:
> Sorry I never attached the messages...
>
> -----Original Message-----
> From: Aisling [mailto:ashling.odriscoll at cit.ie]
> Sent: 16 September 2005 11:31
> To: 'Greger V. Teigre'; 'serusers at lists.iptel.org'
> Subject: RE: [Serusers] Call forwarding Question (following issue 5)
>
> I have attached a complete ngrep of the messages. There were no errors
> in the var/log/messages file. Originally 3500 and 5000 were on the
> same
> machine so I changed the scenario so that 3500 (Windows messenger) was
> calling 2092 (BT100 - which is busy) and should be forwarded to 2009
> (KPhone, same pc as SER). However it still doesn't forward the
> call.....Its the last two messages confuse me...I don't understand
> why a 407 Proxy Authentication required would be sent back to original
> caller....
>
> My rule in the usr_preferences table of the mysql database is:
>
> Username (2092) Attribute (fwdbusy) Value (sip:2009 at serveraddress)
>
> Any ideas?
> Many thanks,
> Aisling.
>
> -----Original Message-----
> From: Greger V. Teigre [mailto:greger at teigre.com]
> Sent: 15 September 2005 18:43
> To: Aisling; serusers at lists.iptel.org
> Subject: Re: [Serusers] Call forwarding Question (following issue 5)
>
> Yes, we have verified that the configs lack the append_branch you
> mention.
> The fix has been done (https://siprouter.onsip.org/trac/changeset/15)
> and
> new configs are available through the regular downloads at onsip.org.
>
> To your other problem: No clue, Aisling. Sounds very strange indeed.
> The
>
> config should only trigger proxy authentication on an INVITE (not
> REGISTER).
> Maybe what you are experiencing is Messenger sending a new INVITE. (It
> should not, as it should receive a 100 Trying from ser). Only a
> *complete*
> ngrep trace will help in understanding what's happening (and any error
> messages in /var/log/messages with the timestamp for matching)
> g-)
>
> Aisling wrote:
>> Hi,
>>
>> I am testing the call forwarding features demonstrated in Issue 5 of
>> the
>> onsip getting started document. I found that blind call transfer
>> worked
>> perfectly but fwdbusy & fwdnoanswer gave me errors:
>>
>> ERROR: t_forward_nonack: non branched for forwarding
>> ERROR: w_t_relay(failure mode): forwarding failed
>> ERROR: sl_reply_error used: I'm terribly sorry, server error
>> occurred.
>>
>> On the onsip site I noted that someone else had this problem and it
>> was
>> solved by putting append_branch in the fwdbusy and fwdnoanswer
>> sections in
>> the failure route.
>>
>> Thankfully that fixed those errors. However when I went to test
>> fwdbusy
>> again, it doesn't give any errors but still doesn't work. The call
>> scenario
>> was as follows:
>>
>> Windows Messenger client 3500 ring BT100 2092. 2092 is off the hook
>> (thereby
>> sending a 486 busy message) and the call should be forwarded to xlite
>> client
>> 5000.
>>
>> i.e. 3500 -> 2092(busy) -> 5000
>>
>> The message sequence showed that everything was correct up to 2092
>> sending
>> the 486 busy to SER and then SER sending an ACK back to 2092. But
>> then SER
>> sends a 407 proxy authentication required to 3500 which replies with
>> an
>> ACK....and that's it...
>>
>> Can someone explain why SER would send a 407 Proxy authentication to
>> the
>> original caller?...I thought this should only be in response to a
>> register
>> message?....
>>
>> Any help appreciated,
>> Thanks,
>> Aisling.
>>
>>
>>
>> -------------------Legal
>> Disclaimer---------------------------------------
>>
>> The above electronic mail transmission is confidential and intended
>> only for the person to whom it is addressed. Its contents may be
>> protected by legal and/or professional privilege. Should it be
>> received by you in error please contact the sender at the above
>> quoted email address. Any unauthorised form of reproduction of this
>> message is strictly prohibited. The Institute does not guarantee the
>> security of any information electronically transmitted and is not
>> liable if the information contained in this communication is not a
>> proper and complete record of the message as transmitted by the
>> sender nor for any delay in its receipt.
>>
>>
>>
>>
>>> _______________________________________________
>>> Serusers mailing list
>>> serusers at lists.iptel.org
>>> http://lists.iptel.org/mailman/listinfo/serusers
>
>
> -------------------Legal
> Disclaimer---------------------------------------
>
> The above electronic mail transmission is confidential and intended
> only
> for the person to whom it is addressed. Its contents may be protected
> by
> legal and/or professional privilege. Should it be received by you in
> error please contact the sender at the above quoted email address. Any
> unauthorised form of reproduction of this message is strictly
> prohibited. The Institute does not guarantee the security of any
> information electronically transmitted and is not liable if the
> information contained in this communication is not a proper and
> complete
> record of the message as transmitted by the sender nor for any delay
> in
> its receipt.
>
>
> -------------------Legal
> Disclaimer--------------------------------------- 
>
> The above electronic mail transmission is confidential and intended
> only for the person to whom it is addressed. Its contents may be
> protected by legal and/or professional privilege. Should it be
> received by you in error please contact the sender at the above
> quoted email address. Any unauthorised form of reproduction of this
> message is strictly prohibited. The Institute does not guarantee the
> security of any information electronically transmitted and is not
> liable if the information contained in this communication is not a
> proper and complete record of the message as transmitted by the
> sender nor for any delay in its receipt. 




More information about the sr-users mailing list