Sorry I never attached the messages...
-----Original Message----- From: Aisling [mailto:ashling.odriscoll@cit.ie] Sent: 16 September 2005 11:31 To: 'Greger V. Teigre'; 'serusers@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@serveraddress)
Any ideas? Many thanks, Aisling.
-----Original Message----- From: Greger V. Teigre [mailto:greger@teigre.com] Sent: 15 September 2005 18:43 To: Aisling; serusers@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@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.
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@cit.ie] Sent: 16 September 2005 11:31 To: 'Greger V. Teigre'; 'serusers@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@serveraddress)
Any ideas? Many thanks, Aisling.
-----Original Message----- From: Greger V. Teigre [mailto:greger@teigre.com] Sent: 15 September 2005 18:43 To: Aisling; serusers@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@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.
Hi Greger,
That worked...Thanks a lot for that. I simply removed consume_credentials from route[3].
Many thanks again, Aisling.
-----Original Message----- From: Greger V. Teigre [mailto:greger@teigre.com] Sent: 16 September 2005 12:08 To: Aisling; serusers@lists.iptel.org Subject: Re: [Serusers] Call forwarding Question (following issue 5)
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@cit.ie] Sent: 16 September 2005 11:31 To: 'Greger V. Teigre'; 'serusers@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@serveraddress)
Any ideas? Many thanks, Aisling.
-----Original Message----- From: Greger V. Teigre [mailto:greger@teigre.com] Sent: 15 September 2005 18:43 To: Aisling; serusers@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@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.
-------------------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.
-
Aisling -
Greger V. Teigre